Re: Xconq language thoughts

[Peter Garrone <pgarrone@acay.com.au>]

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