From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4374 invoked by alias); 20 Nov 2003 14:33:17 -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 4362 invoked from network); 20 Nov 2003 14:33:14 -0000 Received: from unknown (HELO acaymail.tel-pacific.com) (203.88.255.16) by sources.redhat.com with SMTP; 20 Nov 2003 14:33:14 -0000 Received: from leonardo (i022113229.rivernet.com.au [203.22.113.229]) by acaymail.tel-pacific.com (8.12.8/8.12.8) with ESMTP id hAKEWvOq004406; Fri, 21 Nov 2003 01:32:57 +1100 Received: from garrone by leonardo with local (Exim 3.35 #1 (Debian)) id 1AMq28-0000fh-00; Fri, 21 Nov 2003 01:43:48 +1100 Date: Thu, 20 Nov 2003 15:10:00 -0000 From: Peter Garrone To: Stan Shebs Cc: xconq7@sources.redhat.com Subject: Re: Xconq language thoughts Message-ID: <20031120144348.GA2078@leonardo> References: <3FBC23C2.80204@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FBC23C2.80204@apple.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2003/txt/msg00853.txt.bz2 On Wed, Nov 19, 2003 at 06:15:30PM -0800, Stan Shebs wrote: > In all the discussion of extension languages for Xconq, the one thing I look > for is "what is it for". It's always lots of fun to talk about languages and > their good/bad points, but what do the game players and designers get > for it? > > For instance, many of the games in Xconq are based on a randomly generated > world, the purpose being to provide a new and different experience each > time. > This is completely opposite to 95% of commercial game design, where > everything > is so predetermined that you can buy a printed walkthrough at the bookstore. > Random generation is harder; you can't just write a script for AI > behavior, the > AI actually has to be able to do its own analysis. In return, you get a game > where you can't win by knowing to send a full transport to 34,45 after > turn 30; > transports may even be the totally wrong strategy. Now if people want to > write > scripted scenarios for Xconq, that would be an interesting addition; but I > haven't seen very many requests for that. > > Another consideration is that there is a tension between generality and > specificity; if you generalize everything a lot, you get more flexibility, > but you also have to do more work to get something working. In the most > extreme case, you end up with one of those generic "game engines" that > amounts to little more than a poor reimplementation of event loop and > memory manager. Xconq is consciously designed to support only a very > specific class of games; in return you get lots of functionality that "just > works". For instance, there has long been an ability to write AIs customized > for a particular game design, but so far everybody has preferred to just > sponge off the generic AI instead. (Not too surprising, since AI writing > is hard, and there is no possible API that can help you with the hard > parts.) > > So when thinking about language integration, don't think about resumes > or user familiarity or whatever; think about how much Xconq machinery you > want to use as-is, vs how much you want to change. > > Stan > I find the C code in the kernel to be reasonably structured and useable. I dont see how C++ would increase its efficiency or useability significantly. I suppose there is some replicated code there, that might disappear into a base class. But to do that well would require a lot of OO design effort. I dont see how the current kernel is a developmental brick wall. When it does become one, then rewrite in a new language. I dont like the tcl/tk much. I cant get it to work well. The interface is unresponsive. I think we should stick to one language as far as possible. I am comfortable with C. I am also comfortable with GTK without special designer tools. Just work it all out in the code. I hate those interfaces where all the pixel positions are hard-coded. I would like to see development in terms of 1) integrating pathfinding into the AI, 2) setting up a combat model so that multiple units on differing adjacent hexes attack simultaneously, 3) setting up a combat/turn system so that all combats can be resolved at the end of a turn by a referee somewhere, so that play by email would be possible without cheating, and tournaments can be set up. 4) Make it easier to implement the vast existing hex-cell game library, which have been game-tested over time. e.g. russian campaign. 5) Develop the AI interface so that a wider variety of AI algorithms might be tested, with game-specific specialization, e.g. neural nets, genetic, perhaps simple parametric search might work. I havent gone into the details here. None of this development is particularly language specific, just pick good algorithms and implement them. There is no magic language bullet to fix this. I dont think this is particularly generalizing the existing functionality, just trying to extend it to its target market. Hope this is on thread. Peter