From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10436 invoked by alias); 19 Nov 2003 22:44:15 -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 10426 invoked from network); 19 Nov 2003 22:44:13 -0000 Received: from unknown (HELO outbound28-2.lax.untd.com) (64.136.28.160) by sources.redhat.com with SMTP; 19 Nov 2003 22:44:13 -0000 Received: (qmail 4915 invoked from network); 19 Nov 2003 22:44:11 -0000 Received: from 66-52-250-209.sttl.dial.netzero.com (HELO vangogh) (66.52.250.209) by smtpout04.lax.untd.com with SMTP; 19 Nov 2003 22:44:11 -0000 From: "Brandon J. Van Every" To: "xconq" Subject: RE: GDL, XML and others...Re: OT Python stuff (was RE: Python in Xconq) Date: Wed, 19 Nov 2003 23:13:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal In-Reply-To: <20031119203627.74128.qmail@web40910.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-SW-Source: 2003/txt/msg00812.txt.bz2 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.