Re: [DM-dev] Re: Suggestions for work on DungeonMaker (Peters reply)
Brought to you by:
acdalton,
henningsen
|
From: Henningsen <sh...@gl...> - 2004-02-11 01:16:26
|
At 04:25 PM 2/9/04 +0000, Ian B wrote:
>...
>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.
I don't think there's a need to completely scrap, the current DungeonMaker
lays out the general map (topology and corridor-sizes) quite nicely, though
I will modify that part to accomodate very wide "corridors" (possibly up to
hundreds of squares, have to see first how the squares will be mapped onto
the cubes of Cube). The DM code has already been re-written from scratch
after version one and starting into two. I think it's pretty useful as it is.
>...
>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
1 needs some fiddling with, but 2 is the main task at hand.
>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).
This grammar stuff is quite interesting, but I don't use that at all. My
dungeons are completely emergent from the interactions of hundreds of
Crawlers and Tunnelers. The wall-building Crawlers are implemented such that
the labyrinths they make stay always well connected, the Tunnelers must be
supervised, because it is possible that they can build dungeons that consist
of several disjunct parts.
>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)
This is quite interesting, breaking down the tasks like this, but once
again, my alife approach will be quite different. I've thought about it some
more, and will have the following new actors:
1. Evaluators, one of which is started at every dungeon entrance, and who
roam through the dungeon, analyzing the lay of the land (topologically) and
creating new Evaluators (at tunnel branchings) and Modifiers (see below) as
needed. Evaluators will also determine two new variables, floorHeight(fH)
and ceilingHeight(cH) for every tunnel. For instance, a wide hall-like
tunnel could have fH = 0; cH = 255, whereas a small side tunnel could have
fH = 80; cH = 95. Then it will be neccessary to later modify the tunnel
junction so that floor-walking entities can surmount the 80 cubes high step
at the small-tunnel entrance by e.g. making a staircase. That is one of the
jobs for Modifiers.
2. Modifiers are entities that modify the 3D layout that is left behind by
the Dungeonmaker and the Evaluators. So far, I think they will come in at
least 2 flavors:
a) Predefined algorithms for removing/adding cubes (the Cube world can be
conceptualized as consisting of nothing but stacked cubes), which can in
particular handle all possible tunnel junctions with aestetic, useable
solutions like staircases. These will also add geometrically predefined
lavapools, etc.
b) More true to the spirit of alife, but less useable with large cubes, the
second type of Modifiers will add/remove very few cubes and spawn more
Modifiers of its own kind. This process can create irregular organic shapes.
c) Then I'll also have to place objects, of course...
>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.
Cube is a playable game and a game engine you can check out at
http://cubeengine.com/
Just look at the gorgeous pictures:-)
>>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.
all I found was "under construction"-pages...
|