public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Stan Shebs <shebs@apple.com>
To: xconq <xconq7@sources.redhat.com>
Subject: Xconq language thoughts
Date: Thu, 20 Nov 2003 02:16:00 -0000	[thread overview]
Message-ID: <3FBC23C2.80204@apple.com> (raw)

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


             reply	other threads:[~2003-11-20  2:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-20  2:16 Stan Shebs [this message]
2003-11-20  2:47 ` Brandon J. Van Every
2003-11-20  3:05   ` Stan Shebs
2003-11-20  9:47     ` Brandon J. Van Every
2003-11-20 10:52       ` Bruno Boettcher
2003-11-20 15:10 ` Peter Garrone
2003-11-20 11:15 Brandon J. Van Every

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3FBC23C2.80204@apple.com \
    --to=shebs@apple.com \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).