Re: [DM-dev] Re: Suggestions for work on DungeonMaker (Peters reply)

[Ian B. <ian...@ya...>]

Hi,
         I'd forgotten this list, it's been silent for so long.... but it's 
interesting to see something happen.

         I ran some projects on automatic dungeon creation in collaboration 
with the University of  Sheffield:

         A google search for:
                 site:www.dcs.shef.ac.uk dungeon

         Finds the documents which are left, if anybody wants to look.

         Those projects never went quite the way I planned, but my original 
planning document doesn't seem to be there anymore...

...I'll search for my own copy and see if anything fits for you.

         As far as I recall, by approach was a little different to 
yours.  I used the concept of a grammar for a dungeon, e.g.  Such a grammar 
is a bit complicated over your language grammar, because a dungeon is 
inherently more "branchy".  The first project got hung up on this point but 
afterwards it became obvious that you can side-step it easily if you are 
aware of it form the start.

Thus, a typical piece of "grammar" might be (fix-width font required):

Trap(47) = <In-Connector> -> Junction[Switch] -> Door -> <Out-Connector>
                                                \
                                                  -----> SecretDoor -> 
MonsterRoom[Switch]

This is a crude drawing but it represents an old, traditional doom-like 
trap where there's a switch and a door, but the switch doesn't open the 
door you see, it opens another door with monsters behind it.  A high-level 
piece of grammar would then use this by having points where "any trap" was 
specified.  A random choice would then choose between this and other trap 
rules.

There are some complexities w.r.t <In-Connector> and <Out-Connector>, e.g. 
a rule can have 3 or more connectors (this is where it stops being like a 
language grammar) and connectors need properties (like 
PlayerCanCrossForwards, PlayerCanCrossBackwards, PlayerCanSeeAcross) as do 
the "->" arrows within each rule.  These properties, enable dungeons with 
topologically complex features (e.g. keys behind doors behind doors behind 
teleports) to be randomly created with the guarantee that they remain possible.

>1. Converting the 2D world into a 3D world and managing movement.
>2. Developing the AI for the MOB's.

I probably knew what a "MOB" was back when I first signed up but now I 
forgot.  What is it?

>I believe that there is an intermediate step that can be made, that of
>developing
>proof-of-concept (or demo) systems in 2D.

On general principles, this is a very good idea.

< snip >

>How does this sound?

I'll jump in here as somebody totally new but, did you consider having it 
write DOOM WAD files as the output (or some such similar "standard" 
format).  That's a bit further away from pen and paper games, but you might 
be able to hook into an existing community...

And also, for the already exist...

Of course, you cannot plug your own AI into DOOM.  OTOH isn't DOOM source 
freely available now, in fact, isn't Quake?

         Ian Badcoe




Living@Home - Open Source Evolving Organisms - 
http://livingathome.sourceforge.net/