From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11585 invoked by alias); 19 Nov 2003 20:36:30 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 11574 invoked from network); 19 Nov 2003 20:36:28 -0000 Received: from unknown (HELO web40910.mail.yahoo.com) (66.218.78.207) by sources.redhat.com with SMTP; 19 Nov 2003 20:36:28 -0000 Message-ID: <20031119203627.74128.qmail@web40910.mail.yahoo.com> Received: from [217.163.5.253] by web40910.mail.yahoo.com via HTTP; Wed, 19 Nov 2003 21:36:27 CET Date: Wed, 19 Nov 2003 21:18:00 -0000 From: =?iso-8859-1?q?Jakob=20Ilves?= Subject: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq) To: Eric McDonald , bboett@adlp.org Cc: xconq7@sources.redhat.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SW-Source: 2003/txt/msg00805.txt.bz2 Hello folks! 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".) 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 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) {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