[MUD-Dev] AI in gauntlet (was: Natural Language Generation)

ceo ceo at grexengine.com
Wed Jun 9 13:35:49 CEST 2004


> On Thu, 03 Jun 2004 22:26:54 -0700
> Sean Middleditch <elanthis at awesomeplay.com> wrote:
>> On Thu, 2004-06-03 at 02:09, Michael "Flury" Chui wrote:

>> AI has a lot of potential for all players, depending on which
>> parts of the AI you're focusing on.  Even in simple games with
>> little to no direct interaction (information interchange) with
>> NPCs a decent AI in terms of reactions to environment or life
>> conditions can be very entertaining and bring the world to life.
>> Seeing towns people mass when someone starts shouting religious
>> statements in town square, seeing forest animals run on site, and
>> so on.

>> Games like Gauntlet (probably the least AI in any game there is
>> that actually has AI; it's just "move in straight line towards
>> player and attack when in range" for the vast majority of
>> monsters) get boring very, very, very quickly.

  [ this is a bit of a tangent, since it's about AI for realtime
  monsters in an arcade game, which is of course a different field
  from AI for conversational creatures. But as the Sims showed,
  conversations don't necessarily need conversational AI, and
  perhaps the conclusions from "arcade" AI are more useful for NPC's
  than we might expect? ]

Co-incidentally, myself and a couple of friends have just finished
writing a game which is very similar to Gauntlet; only, with the
power of modern machines, we aimed to put in some rather more
interesting AI. Try it, and I think you'll agree that the AI is far
from boring; if you had a look at the source code, you'd find that
it's only half an hour's programming-time more complex than Gauntlet
- which I think illustrates the very complex mapping between the
spaces "algorithm complexity / intelligence" and "perceived
enjoyment / believability": a few small moves in one space has given
us some big ones in the other (at least IMO).

For instance, our main AI is a simple flocking system (a la
Reynolds' Boids) - although the scripting language we're using for
AI (beanshell) has some monumental performance failure on loops, and
the flocking algorithm is O(N*N) (...unless you use funky data
structures to make it easy to get at the "X closest monsters" and
iterate over them in time less than O(Y) for Y = the total number of
monsters - which we haven't had time to try), so the current build
dispenses with half of the flocking, giving us a "sort of" flocking
algo :) which is actually very simple.

If you have Java installed correctly, you can try it out by clicking
here:

  http://www.cokeandcode.com/survivor/webstart/survivor.jnlp

This was a free-time project done over 4 weeks by people working on
the south, west, and east coasts of the UK (so everything was done
online) to enter a short competition being run by Sun; so the above
link is really an early playable alpha (we were working right up to
the deadline) - don't expect much.

But the AI is quite interesting to play against, since it can be
extremely deadly even in it's current emasculated form, yet is still
quick enough to handle upwards of 50 monsters at a time in an
interpreted, un-optimized scripting language (...which has big
problems with loops :)). There are one or two little unexpected
things the AI does which I won't explain so as to preserve the
surprise, but the total AI code is less than 50 lines long,
including comments.

FYI I think total time for the AI development was something like 10
hours, not including many more hours spent trying to understand
beanshell (the AI programmer had never done AI programming before,
and never used beanshell before :)).

PS there's a simplistic website with instructions at

  http://grexengine.com/sections/games/survivor/

Adam M
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list