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

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

At 12:01 09/02/2004 -0400, Henningsen wrote:
>Mobile Objects, also called monsters or NPCs.

Ah!

> >>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.
>
>On software development principles it is good not to take too large a step
>at a time, I totally agree with that. But there's a problem with developing
>dungeon creation software in a 2D view, and then switching the finished
>product over to 3D: it just might suck.

Right.  Maybe I was assuming a stage beyond what was proposed.

I assumed the idea was:

1) do a whole load of work in 2D, learning many useful lessons along the way.
2) completely scrap that and start again, applying what was learnt in 2D to 
the new, shiny 3D system.

>Plus, almost certainly I would
>immediately get all kinds of ideas on how to improve the software to get
>this or that nice 3D effect. Another problem is that I think when one
>includes things in the dungeon creation process like ornamentation around
>doors and generally "look-good"-features, these are all very specific to the
>3D graphics engine one uses.

Right, again I was assuming more than I said.  In the approaches we used, 
creation was always a two-stage process:

1) layout the topological plan of the dungeon
2) "implement" the topology as a 3D model

The nice thing about this is, if the output of stage 1 is "rich" enough 
(e.g. if two nodes can be topologically connected by such relationships as 
"PlayerCanCrossForwards", "PlayerCanSeeAcross", "CloseTo", 
"MonsterCannotCross"), then stage 1 works well for 2D or 3D output.  There 
are some augmentations you might want to make.  E.g. for 2D you can phrase 
the "grammar rules" never to cross two corridors through one-another but in 
3D you don't need to.  You can also add stylistic things in 3D which would 
not apply in 2D ("CanLookDownInto", although this is just a special case of 
CanSeeAccoss + CanNotCross).

Stage 2 is conceptually simpler that stage 1, but may involve a lot of fine 
details (like your door ornaments).

Stage 2 we usually assumed would also be in several stages:

1) layout rooms + corridors
2) set styles on regions
3) add fixed furniture (like doors) matching to style where appropriate
4) add objects (matching to style)
5) paint/texture/light (matching style)

<snip>

> >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...
>
>No, that's a community I know nothing about, and I never liked Doom or
>Quake. Cube has a community too, though small for now. My main interest is
>in alife and AI, and I really want to write the MOB-AI for an RPG-type game,
>where the MOBs don't just stand around waiting to be killed, but conduct
>their own "lives" and will respond to the players' actions in a realistic
>way. I want players to be able to be allied with groups of MOBs, and to
>evolve/engineer their own AI for "their" MOBs, and in this manner evolve
>"better" AI. So the dungeons are just a backdrop for me, but I still want
>them to be good, and useful for other game developers too.

Right, I thought "cube" was just the name of some inner-part of 
dungeonmaker, not an engine in its own right.  My doom comment (let's see 
if any virus scanners object to that :) ) is irrelevant then.

<snip>

> >         Ian Badcoe
> >Living@Home - Open Source Evolving Organisms -
> >http://livingathome.sourceforge.net/
>
>Couldn't find anything at your website, Ian. Sounds very interesting,
>though.

Did you mean it was missing or just not much on it?  It is a bit sparse.

>Why don't you tell me off-list what you're up to??

OK

>Peter

         Ian B



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