Re: GDL, XML and others...Re: OT Python stuff (was RE: Python inXconq)

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

On Wed, 19 Nov 2003, Jakob Ilves wrote:

>  I'm also rude 
>enough to brainstorm about Xconq in
> spite of the fact that I don't have time to implement any of my 
>ideas.

I personally don't consider this rude. You are making thoughtful 
contributions to the discussion. Thank you.

>  (or even have time to run
> one single test game of "Bellum Aetarnum".)

When you get a chance. :-)

> First of all: Be careful when dismissing the declarative 
>characteristics of GDL.  The fact that
> GDL in itself isn't a procedural language is a STRENGTH, not a 
>weakness.  Replacing the ENTIRE
> game module language with a procedural language like Python, 
>Perl, Tcl, Ficl (sp?), Javascript etc
> is overkill if all you want to achieve is the ability of doing 
>a few "if-then-else" or "foreach"
> things here and there.  It's even overkill if you want to do 
>more elaborate coding here and there
> in the Xconq game definition.

I agree.

> Sure, you can do "anything" with Procedural languages but that 
>"anything" includes shooting
> yourself in the foot in the most amazing ways, especally if the 
>procedural language is the only
> thing available for creating Xconq games (that is, if there's 
>no declarative language).  

Yes, this is true.

> Javascript etc) code.  Of course, such code is added only _if 
>needed_ by the game developer! 
> Those who don't want to do any scripting, they can stay 
>strictly declarative in their game
> development which I'm bound to believe will greatly simplify 
>their task.

I agree.

> call" which happens to wipe out a lot of files.  The worst 
>thing that can happen is that your
> Xconq game behaves strange :').

Been there. Done that. :-)

Actually, I have been able to create crashes with GDL. Setting a 
certain value to 0, for example, and then finding out that Xconq 
divides by that value somewhere without checking to see if it is 0 
first. But this is rare.

> Another aspect is how make the AI player understand the 
>scenario if parts of it consists of
> procedural code.  

Yes. Stan alludes to this in his recent comments. Also, this is 
discussed in the "GDL Design Decisions" section of the Xconq 
Hacking Manual:
  http://sources.redhat.com/xconq/manual/hacking_9.html#SEC9

> other side, then the AI will have a hard time (harder than 
>usual ;') 

:-)

> loops infinitely.  Actually, a potential way to sabotage the 
>game intentionally :'(.

Yes. I have also expressed this concern.

> bite the bullet and create an interpreter for that language.  
>How complex language do we need for
> standing orders?

Not very. That is why I suggested merely extending the standing 
orders syntax.

> Are different languages appropriate?  I think so.  The standing 

As do I.

> Also, what about those small additions which can help a lot.  
>We don't need to add full procedural
> capacity to GDL for removing several issues for game creators.  

Absolutely. And this is the development path I certainly favor.

>For instance, the ability to use
> more primitive stuff like arithmetic expressions, if-then-else, 
>case expressions etc and so on
> might go a long way.

Yes. And if one incorporates certain arithmetic expressions into 
GDL, the AI need not get confused, because the expression would be 
evaluated when it was interpreted and the underlying data 
structure would be manipulated accordingly....

All I really had in mind would perhaps look something like this:
(table fire-hit-chance
  (u* u* :hit-chance:*50%)
)
which would reference all entries in the hit-chance table and 
multiply them by 0.5, and store the results in the corresponding 
fire-hit-chance entries.

> Even if I like Perl and find it highly productive and useful I 
>would NOT like to have it replace
> GDL!

I don't think I would either.

> However, there is XML.  What GDL do today can be carried out by XML tomorrow or rather, we can
> defined an XML language called XGDL, eXtensible Game Design Language.  Given the immense support
> for XML in the industry, there's plenty of open source tools and libraries etc one can use to to
> create an XML parser for XGDL so it can read scenarious in XML.  

The section I cited above:
  http://sources.redhat.com/xconq/manual/hacking_9.html#SEC9
also demonstrates how GDL is less cumbersome to deal with.

> For tiny snippets of procedural code, one can use ECMAscript 
>(aka Javascript).  Sure, not the most
> fantastic language. 

I will look at it. Thanks for the suggestion.
(I now have quite a bit of reading to do this weekend.)

> Oh, anyone for using SVG to define the graphics...  I swear, SVG is the coolest thing since sliced
> bread.  Antialiazed vectored graphics, in XML.  Imagine scaling the units to different sizes in
> that (works LOVELY :-) and even changing their different orientations.
> 
> Ok, enough on this thread, I'm getting carried away...  (Should not have mentioned SVG.  Oh,
> fantastic SVG ;-).

I will look at it. Thanks for the suggestion.
(I now have even more reading this weekend.)

> aka Jakob Ilves, who don't have time to develop Xconq a bit but 
>in spite of that insists on having
> ideas and opinions ;-D.

That is not a crime, especially if you have a family. And to be 
honest, there are some days that I don't feel like working on 
Xconq, so I just play it. ;-)

Thanks again for your thoughts; I think you have the right idea 
(IMO) about many things.

  Best regards,
   Eric