Xconq language thoughts

[Stan Shebs]

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