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

[Jakob Ilves <illvilja at yahoo dot com>]

Hello folks!

<disclaimer>
This is quickly written (I'm as everyone else awfully short of time, the combined curse and
blessing of having a family and a job :-).  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.  (or even have time to run
one single test game of "Bellum Aetarnum".)
</disclaimer>

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.

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).  Also,
with the risk of getting my head cut off here, I believe that this approach promotes game
definitions which is hard to maintain.

As I see it, Xconq still benifits from having a declarative framework (like GDL as of today or XML
& co) but that framework can be enhanced by adding the capacity to add procedural (Perl, Python,
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.  In a declarative
language, there is no such thing as an "infinite loop" which hangs the application or a "system()
call" which happens to wipe out a lot of files.  The worst thing that can happen is that your
Xconq game behaves strange :').

Having a full fledged procedural language as an option when creating an Xconq game is nice (even
if it is potent enough to blow off ones own and others feet).  Having such a language _forced_
upon oneself is a bad thing though.

Another aspect is how make the AI player understand the scenario if parts of it consists of
procedural code.  Of course, if the procedural code is executed only at the initial setup of the
game in order to "build the setting" then it's a breeze.  Just let the code run (perhaps
automagically setting up some parts of the scenario such as adjusting starting positions, starting
units etc, setting up unit capabilities and other "laws of nature" etc) and once that is done and
all procedural code is evaluated, the AI has all it needs to understand the picture (because once
the unit capabilities and other "laws of nature" has been defined at the start of the game they
remain fixed from then on).

However, if pieces of code in the procedural language is supposed to invoked later on in the game,
for instance in order to find out if an inactive side will suddenly decide to declare war on some
other side, then the AI will have a hard time (harder than usual ;') to find out how to act in
order to trigger (or not trigger) that declaration of war.  Or even worse, what if the victory
condition is expressed as a snippet of code in a procedural language?  Well, the AI can just
evaluate the expression in order to answer the question "Am I victorious" but the AI will have a
problem in order to answer the question "How do I get victorious" (which is the answer we REALLY
are intrested in that the AI finds out, in order to have meaningful games against it).

Another area where we don't want a full fledged procedural language is the standing orders,
especially as those are exposed to the users fingers through the GUI.  Imagine player Z trying to
setup some spiffy loop in the standing order for a unit, only to find that the standing order
loops infinitely.  Actually, a potential way to sabotage the game intentionally :'(.

One solution can be to define a small language, perhaps a subset of an existing language and then
bite the bullet and create an interpreter for that language.  How complex language do we need for
standing orders?  For adjusting the set of units a player starts with depending on the proximity
to water?  For triggering the declaration of war or the declaration of cease fire for a specific
side?  For determining if a side has won or not?

Are different languages appropriate?  I think so.  The standing orders, being exposed to the
users, should probably be defined in a way which makes them both easy enough to use but still
powerful enough for what's needed.  The other stuff like in the scenarious themselves might need
to be more powerful but don't need to be as streamlined as the standing order syntax.

Of course, one could use the interpreter of an existing full fledged language to interprete
snippets of code but prior to do so, ensure that the snippet contains nothing but the subset we
want to use and if the snippet contains code outside of the subset, then we reject it with an
error.  However, creating that test, to see if the snippet is within the accepted code subset,
will be pretty much work too, so one could as well consider writing a new parser instead.

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.  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.


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

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.  Also, as XGDL is XML, a lot of
already existing tools can be used to assist in the authoring of XGDL files or for displaying them
on a wep page in an easy to read format, generate Help files etc.

For tiny snippets of procedural code, one can use ECMAscript (aka Javascript).  Sure, not the most
fantastic language.  I don't find it suitable language for writing 10000+ lines systems but
luckily that don't matter to Xconq as only snippet is what we need.  The Mozilla project has a
ECMAscript parser called Rhino.

So what I envision is a file with XGDL, containing (or loading external files with) snippets of
ECMAscript being used in order to setup certain things like terrain/units or carrying out certain
adjustments/interpolations/extrapolations of things which would be tedious to do by hand in the
XGDL code.  Also, one can use XML events to create small triggers to be executed to test for
victory and so on.

But of course, as much power as possible should be put into the XGDL language itself, to minimize
the need for ECMAscript code.  Adding ECMAscript code to a game setup adds fragility to the
overall XGDL document and also more easily makes the AI even more confused (as discussed above).

Hm, while we are doing XML/XGDL, we have the potential of interacting with other XML languages
such as XHTML and SVG.

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 ;-).


Best regards

/IllvilJa

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.



 --- Eric McDonald <mcdonald@phy.cmich.edu> skrev:
> On Wed, 19 Nov 2003, Bruno Boettcher wrote:
> 
> > > And a scripting language is seriously preferred, because it will permit
> > > so much more stuff.
> > yah :D
> 
> And that can also be a problem. Think about the possibilities for 
> cheating. And we would have to be more cautious about security 
> too.



> > > If we add a scripting language, then I would submit that we write a
> > > simple porting script to convert GDL to that language, and drop GDL.
> > > IMHO, GDL is just a way to fill in data-structures, and any language can
> > > do that.
> > oh? that sounds like a nice idea?
> 
> Here are a few more points:
> (1) Richard mentioned to me yesterday that each additional piece 
> of external software that becomes an Xconq dependency is an 
> additional annoyance. If you build tkconq then you need Tcl/Tk, 
> and if you build sdlconq then you need SDL. Do we really want to 
> say that we also need Perl (which is fairly ubiquitous on Linux, 
> but not necessarily so on other platforms) or Python (which is 
> admittedly a nice language, but still not as widespread as Perl, 
> AFAICT)?
> (2) Richard also raised the idea of using Tcl as an Xconq 
> scripting engine. This partially eliminates the concern just 
> raised; however with the SDL interface this would still be 
> regarded as an additonal dependency.
> (3) A full-blown scripting language can open many doors for 
> cheating, as I mentioned above.
> (4) GDL actually does usefully serve an important niche: game 
> designers who are uncomfortable with a larger language. If we 
> replace GDL, then we are raising the entry barrier for some of 
> those who wish to design game modules for Xconq.
> 
> I am not against adding a scripting engine to Xconq based on 
> external software, but I do urge caution and consideration....
> 
> Eric
>  

=====
(Jakob Ilves) <illvilja@yahoo.com>
{http://www.geocities.com/illvilja}

Höstrusk och grå moln - köp en resa till solen på Yahoo! Resor på adressen http://se.docs.yahoo.com/travel/index.html