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

["Brandon J. Van Every" <vanevery@indiegamedesign.com>]

Jakob Ilves wrote:
>
> this [procedural language] approach promotes game
> definitions which is hard to maintain.

But the tradeoff is that the widely used scripting languages are
procedural.  You get more people who already know the language, more
volunteers, and thus something to actually maintain.  ;-)  "I want to
tweak games in Python / Perl" is not the same sentiment as "I want to
tweak games in GDL for Xconq."  One is a wider net than the other.

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

Ok, some reality checking here.  Are a great many people developing
Xconq games in GDL?  If not, then we have to face the fact that no
matter what theoretical merits it may have as a declarative language,
people don't use it.   So you need a language that is more popular, and
in theory we could pick either a procedural or a declarative one.  The
list of likely suspects in the procedural camp is obvious.  What about
the declarative camp?  Name me a wildly popular declarative language.

> 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 :').

This is a sandboxing issue, not a procedural vs. declarative issue.  If
you can find any bug that causes the declarative language to hang, or
you can alter any game resources to achieve the same effect, you can
have denial-of-service attacks.

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

AIs are going to get written by whomever in their favorite language.
Trying to force procedural vs. declarative languages on an AI programmer
is irrelevant.  It's a huge amount of work, the programmer will
inevitably choose the language he likes, or find a different project to
contribute to.

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

Of course, you didn't volunteer to implement any of your brainstorms, so
that's quite a primrose path you're laying out for others.  Solving
perceived problems by writing scripting languages from scratch is utter
foolishness.

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

I can't comment, I'm not a XML guy.  I think your vision is flawed in
that you're not volunteering to implement it, and it sounds like a lot
of work.

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

Might be a good web-oriented approach.  When I last looked at SVG it
wasn't ready for prime time, but I can't remember if that was 1 or 2
years ago.  I'm not up on it lately.  I'm also not a web-oriented
developer.  You'd need to scare those up to do those kinds of things.

> Ok, enough on this thread, I'm getting carried away...
>
> 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.

Indeed!  Back to Earth, flyboy. ;-D


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.