dungeonmaker-develop — Public list for developers and users of DungeonMaker

[DM-dev] Commentary on a 2D version

[<kh...@op...>]

Having made the suggestion of a 2D version, it seems that my exact intent was a little unclear.

I see a 2D version as being useful for testing the various AI algorithms and AI engin that we intend to use without the burden developing in 3D.  For example consider the following sections of a dungeon:


   |    |      +----+        |    |    
   |    |       | P |         | G |    
   |   +------+  +---------+    |
   |   +---------------------+    |
   |    |                      |     |
   | M |                     |     |

(In case my wonderful ASCII art is garbled, the image sould look like a capitol H with a small passage heading up in the center of the bar.  The `P' represents the player, the `G' represents a stationary (guard) MOB and the `M' represnets a patrolling MOB).

Lets assume that the player is standing infront of a locked door.  He has three possible options:
1) leave
2) pick the lock
3) kick the door down

Lets consider the final option.  If the player kicks the door down, there will be some sound associated with that act - and lets say the we set the sound radius to be ten units  - encompassing both of the MOB's (in a debug/test version of this we could flash a circle showing the extent of the sound so we could see which MOB's had a chance at hearing the sound, and we could change the color of the MOB's that infact detected the sound).  If a MOB detected the sound, he could possibly change state from either guard or patrol to investigate and move toward the source of the sound.

My though is that with a 2D, down-looking view we can observe the actions of the MOB's and see if they are behaving as we expect them to.  For example, if the patrolling MOB in the above example detected the noise, and changed state from patrolling to investigation, but reversed direction and moved away from the disturbance, we could conclude that there is a problem in our algorithm.  Note, that this behaviour might not be readily apparent in a 3D version since the only the MOB's in the field of view would be observable.

Hope this gives a few more details on what I was hoping to accomplish in a 2D version.

George

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/

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

[stephan b. <st...@ei...>]

On Monday 09 February 2004 17:01, Henningsen wrote:
> >         I'd forgotten this list, it's been silent for so long....
> > but it's interesting to see something happen.
>
> Yeah. I think I'm gonna write DungeonMaker 3 pretty soon.

Hi, Pete!

If you do, i wanna add support to it for my serialization layer:
  http://s11n.net
One of the major inspirations behind that library was the work i did on 
saving/loading on DM a couple years ago. i never had good code for 
loading the object tree, and that always frustrated me. That lib 
eliminates those problems. That said, it may have some requirements you 
can't live with (like a recent C++ compiler [gcc 3.2+]). Also, the 
classload itself is quite interesting, and may be useful in DM. See:
http://s11n.net/class_loader/

> 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.

If you manage to do that, i'd like a copy to run on myself ;).

-- 
----- st...@ei... - http://www.einsurance.de
"If you stopped telling people it's all sorted out after they're
dead, they might try sorting it all out while they're alive."
-- Terry Pratchet

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

[Henningsen <sh...@gl...>]

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

Yeah. I think I'm gonna write DungeonMaker 3 pretty soon.

>         As far as I recall, by approach was a little different to 
>yours.  I used the concept of a grammar for a dungeon, .....
> (snip).....  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.

Very different indeed. My dungeons are created by alife-entities that crawl
through the dungeon space laying down walls or digging tunnels. Walls,
tunnels and rooms is all the Dungeonmaker makes right now, and that's
probably not useful enough for potential users. So main objective number 1
is to include all kinds of other features like traps, lavapools, and
powerups. Objective number 2 is to see the dungeons in glorious 3D.

>>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?

Mobile Objects, also called monsters or NPCs.

>>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. 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. So my development process will be like this:
First step, port the existing DungeonMaker to the Cube engine, generating
Cube environments (which can immediately be played and explored and
evaluated). Then I'll take one step after another, implementing nice new
features that I want to see in my Cube dungeons. All the while keeping the
code such that Cube-specific and general features are in different modules.
I think this allows for a better software-design process than sticking with
2D display for starters.

>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.

Just to give all you guys on the list an idea what I'm thinking about, my
basic approach will be to create a new type of entity (call them
"Evaluators" for now), who will move through a dungeon as made by DM2, and
diagnose local environments. E.g., when they find a dead end tunnel, they
will then check for available space, and either add a door and room to it,
or place a worker with a shovel at the end of the tunnel. When they find a
place where a small side tunnel (10 Cubes high) meets a wide main tunnel
(100 Cubes high) they might widen the small tunnel at the junction for a
better look and richer tactical possibilities, or put two columns inside the
large tunnel as cover for anyone coming out of the small one. Etc. etc.
These guys will also place keys in the proper locations, test dungeons for
connectivity, and place all kinds of other objects.

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

Couldn't find anything at your website, Ian. Sounds very interesting,
though. Why don't you tell me off-list what you're up to??

Peter

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/

[DM-dev] Suggestions for work on DungeonMaker

[George H. <kh...@op...>]

first a little background,

I had email Peter with an offer to help on DungeonMaker, and as a result we
have
started a private dialog.  After a few messages, Peter suggested that we
move
the discussion to the mailing list so that others might `profit' and give
suggestions
as the work continues on DungeonMaker.  The following is the first
substantial
message in this series, an I will post the subsequent messages as replies to
this one.

George

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Peter,

I just complied the existing source, so my executable does nothing new
or different.  Except for cleaning up as many of the warnings as I
could.  One thing that I have not do yet is to see if my modified
files compile cleanly on a Linux system - probably will do that in a
day or to.

From what you described about DungeonRaid, it sounds very interesting,
and certainly lines up with my interests on several levels.  As a player
of computer RPG's I have always found the NPC to be rather stall and
static.  I have always felt that much more could be done to make the
game interesting.  Secondly, having just finished my Masters in Computer
Science with a concentration in Intelligent Interfaces (i.e. artificial
intelligence), the AI work is definatly interesting.

I have included some thoughts on how to proceed, sorry if I come of
a little `strong', but as a senior developer much of my work day is
spent evaluating risks and coming up with courses of action and the
such.

I agree that `playing' in 3D would be very cool, and I suspect it will be
a significant undertaking.  Thinking about, I see two issues,

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

While the first issue is complex, there is a good precedent on how to do
this.  In face, I am currently taking a course through "Game Institute" on
3D graphics programming, and in some of the later labs we do construct
simple dungeons and implement enough so the camera can move through
the dungeon.

The second issue is more `risky', there is not as much precedent in the
literature for developing intelligent NPC.  Of course, this make this
issue all the more interesting!

I believe that there is an intermediate step that can be made, that of
developing
proof-of-concept (or demo) systems in 2D.  The basic idea would be to have
an interface somewhat similar to what DungeonMaker currently produces, with
a various colored squares for the different types of MOB's and the player.
This
interface would allow the play to move his icon around the dungeon or
labyrinth and
have the MOB's react.  I believe this approach would have several benefits:

- the AI algorithms can be developed and tested with out the overhead of a
true
   3D environment.

- having an `birds-eye' perspective on the entire dungeon will enable us to
keep
  track of all entities and make sure they are doing what is expected.

- being a simple 2D environment, there should be no need for graphic
packages
   such as SDL or openGL.  The initial work can be done with a normal
window.
   This means that you do not need to get an improved development machine
    because we would not be pushing the graphics subsystem as hard.

I would think that the first, tentative steps here would be to imbed the
current
DungeonMaker interface into a GUI of some sort.  I can see this being a
simple application with a main window and a menu bar.  The menu bar
would have the following items:

file
   new template - allows the user to select a new design file to use to
create
                          dungeon.
   new              - clears the display and generates a new dungeon based
on
                          the currently selected design file.

edit
   view             - allows the user to view the design file in a read only
window
   edit              - allows the user to edit the design file.  This can be
invoking
                         a simple text editor or a move complex 'wizard' to
guide the
                         user through the creation of the design file.
   save             - allows the user to save the modified design back to
the
                         original file
   save as         - allows the user to save the modified design to a new
file.

This would reproduce the current ability of DungeonMaker, however by using
one of the cross-platform frameworks (QT, wxWindows, FLTK, etc.) the
interface will be the same on all platforms.  I have no real preference on
these
frameworks, having worked with them all, however FLTK does seem to be the
easiest to work with (and there is a DevPak for DevC++).  I have done a
quick
search and there seems to be precedence for embedding an SDL window into
a widget from any of the afore mentioned frameworks.

Once this is done, the next perceived task would be to add a few new
features,
most notably would be a save and open feature for dungeons.  This would be
necessary when the move to 3D is made so games could be saved and restarted.
Of course this means defining a DungeonMaker file format.  A neat extra
would
be to provide an export feature.  As a start, exporting to a bitmap and jpeg
would be great.  Because, I still play traditional pencil-and-paper
role-playing
games (e.g. Role Master or Dungeons and Dragons) I make use of a tool
called Campaign Cartographer (CC) and I would like to see a conversion
between DungeonMaker and CC.

Once this is done, we can concentrate on `playing' the dungeon in 2D,
implementing
player movement and MOB's AI algorithms.  Of course being able to reload a
dungeon allows for training of the MOB's.

At the end of this phase, all of the AI algorithms should be complete and
effort can
be applied to converting the 2D world to 3D.

How does this sound?

George

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

[George H. <kh...@op...>]

Here is Peters reply to my first message, this should bring everyone up to
data on what
we are think.


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++
Hi George,
        this sounds like we might actually be able to work together on this.
Very neat.

        I wrote you a second email 3 days after the first, in which I
basically suggest the same course of action that you propose. I attach the
text at the end of this mail in case it got lost somehow.

>I have included some thoughts on how to proceed, sorry if I come of
>a little `strong', but as a senior developer much of my work day is
>spent evaluating risks and coming up with courses of action and the
>such.

Our expertise may well match up nicely. I have a PhD in mathematics, and
maybe 5 years of experience developing games, which pose their special
challenges. One thing I have learned about game development is that it is
essential to get the game playable as soon as possible, and then to make
sure it is actually fun to play and becomes more so as development
progresses. My day-to-day tactics is to make the most essential improvement
next. This precludes doing detailed step-by-step pre-planning, and if one
gets the basic architecture wrong, one will have to do a total re-write
eventually. That's one area where I anticipate you could be of great help:-)
Anyway, that describes my style of writing code.

>I agree that `playing' in 3D would be very cool, and I suspect it will be
>a significant undertaking.  Thinking about, I see two issues,
>
>1. Converting the 2D world into a 3D world and managing movement.

Actually, this should not be all that hard. All I have to do is to output a
DM-dungeon in the internal Cube-map format, and then *<snap like magic -
through the power of using library code>* "managing movement" won't be
neccessary: not only will it be possible to play right away in there
(fighting MOBs I mean), but we can actually network and play together in the
same Dungeon. One thing that will be neccessary (and this will be quite
laborious) is to develop a whole new version of the Dungeonmaker which can
place all kinds of stuff one might want in CUBE or in PENandPAPER RPGs, such
as powerups for Health, Mana, Energy, Money, Whatnot... or Pools of Lava,
Water, Blood, Whatever... HiddenTrap Type A,B,C,... etc...etc... this will
be quite a job, but I want to do that because I think acceptance of DM may
be low because this last step (parts of which must be done specifically for
a specific graphics engine) has not been implemented. So that's where I want
to go first.

However, this potentially meshes very well with what you have suggested.
We'd both be providing different "views" of the virtual world, I the
3D-view, and you the Data-Editor-view. The 2D-map-view already exists (in
rather rudimentary form but fully functional really) in the current
Dungeon-display.

The program I want to work on will have data structures of growing (with
later versions) complexity, and allow for an arbitrary number of views into
this virtual world, each view in its own window, managed by the underlying
windowing system. So there's no need (in fact it would be counterproductive)
to encapsulate the current SDL-map in another widget or window frame - all
the user needs is an option to open this "2D-map-view" from other windows
(like the Data-Editor and the 3D-view) - and admittedly the SDL-window must
be improved so it can be resized and scrolled and has its own icons (e.g.
for opening the data view and dynamically centering the map).

>2. Developing the AI for the MOB's.

>The second issue is more `risky', there is not as much precedent in the
>literature for developing intelligent NPC.  Of course, this make this
>issue all the more interesting!

I am very interested in artificial life, and will be implementing AI as
evolving alife entities. However, for the start I plan to implement a
"smart-map", where much intelligent info is contained in the map (this will
be part of the next version DM-data structure, with precomputed paths to
exits, "chokepoints", social hubs, etc). The attempt to develop
"intelligent" AI will then start from this relatively high base line. This
strategy is also the reason I want to go with grid-based maps, because on
such maps pathfinding is so cheap that it is relatively easy to implement
"intelligent-looking" behavior.

My own "milestone map" btw has always been as follows:
1. MazeRunner, a Pacman-type labyrinth-traversal where one has to avoid
being hit by MOBs. This was planned to be 2D, and would be proof-of concept
for the SmartMap, also really an essential tool to make SmartMap design
decisions.
2. DungeonHack, pure fighting in Dungeons, then develop MOB AI in top of
that, later develop code for levelling skills, etc.
3. DungeonRaid after that, going through series of Dungeons/Labyrinths with
the possibility that one may revisit Dungeons that already had human parties
in them, or encounter other adventurer parties in a dungeon. Also
implementing a Diablo-type treasure system with "Einstein's Sword of
Hacking" (Einstein = +6 Intell, +2 Dex, Quick Wit; "of Hacking = +3 to
strength, +4 to hit, +3 to wisdom(because hackers are cool dudes:-)" etc etc
However, now that I want to do "DungeonMaker 3D" next, MazeRunner might not
get released as its own game (might suck in 3D). However, if you want to
mess with the 2D-SDL-view, we could do that, I'd actually like that. Would
also be a very good tool to test Dungeon-designs by test-playing them
quickly.

>I would think that the first, tentative steps here would be to imbed the
>current
>DungeonMaker interface into a GUI of some sort.  I can see this being a
>simple application with a main window and a menu bar.

Yeah, but make it a separate window from the existing map-view.

I would suggest the following capabilities (all the while keeping in mind
that the "data-editor" should in the future also be able to work with
AI-files or trap-script-files and other types of files, not just the current
design-files).

Allow access to all design-files in a specific folder/directory.
Select one of these files -> choose to open in modes
* Execute = construct a dungeon with this design, show in *2D or in *3D or
in whatever...
* File-content - Read-only
* File-content - Edit-mode (normal text-editor functions dropped in)
make it possible to display any set of selected lines, not just adjacent
ones (important for design process)
In the last two modes *"Help-mode" is available as follows:
When a line in the design file is selected (or cursor is in that line) and a
*button is clicked, a new help window opens with an extensive commentary
explaining that lines data and their use.
Also possible: Short data explanation in pop-up window when *right-click on
line.
Or two buttons for the short/long data version.

I could certainly write the explanations...

One thing that is in the current Linux version (which uses the command line
interface in a second window) is the option to display the number of the
current Builder/Crawler-generation during dungeon construction. This is
absolutely essential for dungeon design (you have to know what generation
has what effect to sensibly edit the files), so that will also have to be
available in the editor-view.

>This would reproduce the current ability of DungeonMaker, however by using
>one of the cross-platform frameworks (QT, wxWindows, FLTK, etc.) the
>interface will be the same on all platforms.  I have no real preference on
>these
>frameworks, having worked with them all, however FLTK does seem to be the
>easiest to work with (and there is a DevPak for DevC++).  I have done a
>quick
>search and there seems to be precedence for embedding an SDL window into
>a widget from any of the afore mentioned frameworks.

I've only worked with Qt, and while it is a pleasure to work with, it is
expensive to use on Windows, so your choice of FLTK seems astute. I have one
point to consider here though, I want to keep the option open of eventually
releasing a commercial, closed-code, data-encrypted version of the project,
and therefore cannot mix the code with aggressive OS-licenses like the GPL.
All has to be LGPL or similarly unencumbered. Is that the case for FLTK??
BTW, what's your take on DevC++? Is it any good? Or do you recommend another
gcc-based development environment for Windows?

>Once this is done, the next perceived task would be to add a few new
>features,
>most notably would be a save and open feature for dungeons.  This would be
>necessary when the move to 3D is made so games could be saved and
restarted.
>Of course this means defining a DungeonMaker file format.

The DM-dungeon data is already in a single data structure which is made from
STL-components, so saving/loading it is straightforward. Whatever we do when
new data gets added (MOBs, powerups, traps, lavapools, etc) must be well
thought out, and as general as possible. I count on you as an experienced
Pen-and-paper-RPG dude to come up with ideas on what-all we will want.
Hopefully we can define a file format that covers all map elements once and
for (all/the next 5 years).

>A neat extra
>would
>be to provide an export feature.  As a start, exporting to a bitmap and
jpeg
>would be great.  Because, I still play traditional pencil-and-paper
>role-playing
>games (e.g. Role Master or Dungeons and Dragons) I make use of a tool
>called Campaign Cartographer (CC) and I would like to see a conversion
>between DungeonMaker and CC.

That would be lovely, and I think I can leave that totally up to you.
Anyway, I don't see how it would impact other parts of the project. You
should proceed so that things will be easy when new map-items like
lava-pools appear on the DM-maps.

>Once this is done, we can concentrate on `playing' the dungeon in 2D,
>implementing
>player movement and MOB's AI algorithms.  Of course being able to reload a
>dungeon allows for training of the MOB's.

We can play it in 2D or in 3D, whatever becomes playable first, and then in
both simultaneously. I want the game to be such that the player will use the
2D-map for strategical planning and moves (possibly for fast runs), and the
3D-map for tactical encounters/fights, and just to go sightseeing.

As for the 2D-view, the map can already be zoomed to any degree i.e. we can
determine how large each square is on the screen. Players and MOBs should be
circles with different colors, and their size should reflect the fact that
most entities will be able to walk 2 abreast in even the narrowest tunnels.
(Otherwise it's too easy to block the player which is no fun).

I have in fact a whole book with design ideas, so I will probably have
answers to most anything you come up with. It would be supercool if you
liked the alifegames-project and would want to participate.

Take care,
Peter

What follows is the second email I sent you, in case it got lost:

Hi there,
        I had an idea what you could do if you wanted to help the
DungeonMaker along. This would be a fairly easy and straightforward bit of
programming: As you may or may not know, the Linux version has a nice
command-line interface, where one can choose to run a new version of the
same design, or go on to the next demo-design. In the Windows version, one
must manually rename the design file to see different demo-designs. If you'd
like to, you could write a windowed interface that runs the user through the
different designs in similar fashion. All you'd have to do is write a new
main()-function - the Linux main()-function could be simplified quite a bit,
it is only so complicated because it is possible to show the design during
or after the dungeon-creation-process. Also possible if you want to get into
it some more would be to expand the interface so that the user could
interactively edit the design files and run the program again with modified
design data. (Of course this is already possible by opening the design file
in a text editor, so that's not really that useful. But it would be more
elegant...)

Take care,
Peter

[DM-dev] Introduction

[Aaron D. <aa...@fi...>]

I see this list doesn't get much traffic, but I thought I'd at least let
you know I am using the software.

I am developing a fantasy tactical combat game and am starting with the
dungeon aspect of play.  Because I stink at from-scratch map design, I
looked and found this project.  It was simple to integrate it with my Perl
code and it has been working great.  I'll probably have a question or 2
about the design file in a while as I start to fiddle with it, but so far
so good =)

Thanks for the great system!  I'll be sure to let you see what we've done
with it once my project gets a little further.

Cheers!

-- 
Aaron Dalton
aa...@fi...
http://aaron.finch.st

[DM-dev] DungeonMaker 2 released

[Henningsen <al...@gl...>]

The DungeonMaker v.2 is now available on SourceForge at 
http://dungeonmaker.sourceforge.net (click on "manual" for the download link)

Enjoy!
Peter

[DM-dev] DungeonMaker2 ready for release

[Henningsen <al...@gl...>]

Hello all,

        it looks like the Dungeonmaker version 2 is now ready for release
under GPL. The code is much improved, and the program now makes dungeons
(with tunnels and rooms) as well as labyrinths. Of course, something may be
wrong, a bug or the documentation may such that things are unneccessarily
hard to understand. So if you guys would be willing to unwrap my tarball,
compile and run the code, and check out the documentation, that would be great.

Let me know if you're interested,
Peter Henningsen
alifegames.com

[DM-dev] Plonkers

[Henningsen <pe...@al...>]

I've changed my mind and decided to implement Plonkers after all for version
2. For those not in the know, Plonkers are agents that plonk down treasure
and MOBs (mobile objects, formerly known as "monsters"). I already have a
vector containing all Room-objects ordered by size, so I can put the biggest
treasure and the most MOBs in the largest rooms. The problem with all this
is that I'd really have to know what specific MOBs are in a game in order to
intelligently place them (like in, "always have a healer with any group of
fighters"). So this will just be a generic implementation, but hopefully it
will be useful for actual concrete implementations later. To ensure that it
is I ask for feedback on my ideas.

I'm thinking to put the following data into the design file and use it to
plonk down stuff:
6 vectors of integers, open-ended as to length, as follows:

index      0  1  2  3  4  5  6  ...
MOBinLR    n0 n1 n2 n3 n4 n5 n6 ... (MOB's in labyrinth rooms)
MOBinLO    m0 m1 m2 m3 m4 m5 ...    (MOB's in labyrinth open)
(the same as above for inside the dungeon part)
TreasInLab t0 t1 t2 t3 t4 ...       (treasure in labyrinth)
TreasInDun d0 d1 d2 ...             (all treasure is in rooms)

The index will be used as a generic "level", with lower indices used for
less powerful MOBs, and less valuable treasure. Of course an implementation
could have many different level 1 MOBs use indices 0 up to 10 or whatever
for them, just not put higher level MOBs on lower indices than their inferiors.

For each of the six vectors, I intend to use two more integer variables,
groupSize and groupVariance.
If for instance groupSize=5, groupVariance=3, groups of MOBs (or treasure
items in one chest) would be randomly chosen to have a size between 3 and 8.
I'll also allow the following case,
groupSize=0, groupVariance=10,
which will give groups of size -10 to 10, with every "group size" under 2
interpreted as group size 1. This would allow the designer to place many
solitary MOBs or single treasure items.

I intend to enforce that the biggest treasures go in the largest rooms, and
that the groups of MOBs guarding them will be at the top of their allowable
group range, i.e. group size for the largest rooms will not be chosen randomly.

How's that sound? Any ideas how this should be made better?

Peter

Re: [DM-dev] Dungeonmaker going on version 2 ...

[stephan b. <st...@wa...>]

good morning! Sorry for my delayed response - i've been skipping work and 
staying offline the past couple of days.

On Saturday 16 February 2002 22:12 pm, Henningsen wrote:
> >as i said, yours is certainly the most unique approach to dungeon creation
> > in the world.
>
> Yeah, but does it make good dungeons? That's really the big question.

They look great to me.

> >Keep sending it...
>
> I'm sending a bunch of dungeon designs together with the latest DM.cpp by
> separate mail, for your inspection. And then, please let me know what you
> think... any ideas how to make these dungeons better? Anything in Tunneler
> behavior that you find irritating?

i'll take a look this evening. We changed our office layout and now 4 people 
have a direct view over my shoulder at all times. While looking at source 
code is no problem (few people here know C++), playing with the dungeons is 
;).


----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862 Handy:  +49 (179) 211 97 67
"People might not think that was much of a position of power, but 
then they'd never been minutes secretary to a meeting of slightly 
deaf old men." -- Terry Pratchet

Re: [DM-dev] Dungeonmaker going on version 2 ...

[Henningsen <pe...@al...>]

>> >no, i just changed the first one i saw:
>> >  unsigned int tT = 13;   //tickTime, makes movie speed
>>
>> Is that a good speed? I can't really test it on my box here.
>
>It looks okay to me. It's not terribly much slower than the original, but 
>lets me view the big colored rooms for a second before the black lines start 
>filling in.

Actually, the time the design is displayed at the start is hardcoded at 3
seconds I think... or was, anyway. Since tickTime is in 1000/th of a second,
you've just slowed to a framerate of 76 fps, and I bet you don't see that
but even on your machine it takes longer than that to make an iteration of
the dungeonmaking process.

>> However, the variation with
>> different random numbers is tremendous, particularly with dungeons. Later
>> we can make some parameters evolvable, maybe. Still not sure whether I want
>> to do that, and whether it's worth the trouble.
>
>Which objects can take advantage of "evolutionary data" now?

I just use the term for data that *could* be changed through evolutionary
processes, as opposed to data that must be specifically designed (e.g.
starting positions of Tunnelers, which usually are on a (room- or dungeon-)
entrance, and where changing them by random amounts would wreck the
dungeon). I don't actually evolve any parameters yet.

>as i said, yours is certainly the most unique approach to dungeon creation in 
>the world.

Yeah, but does it make good dungeons? That's really the big question.

>Keep sending it...

I'm sending a bunch of dungeon designs together with the latest DM.cpp by
separate mail, for your inspection. And then, please let me know what you
think... any ideas how to make these dungeons better? Anything in Tunneler
behavior that you find irritating?

Peter

Re: [DM-dev] Dungeonmaker going on version 2 ...

[stephan b. <st...@ei...>]

On Monday 11 February 2002 23:05 pm, Henningsen wrote:
> I just spent some time on SourceForge trying to change the default behavior
> of this list so that posters reply to the list instead of to the previous
> poster, but alas, that is not possible. 

in my mail client (kmail) i have to click Reply to All to get the list name 
to go into the To field (and then have to manually remove the sender's 
address, so avoid him getting it twice). Give that a try.

> So I guess we'll keep going private
> by forgetting to paste the list address in the address field, like Stephan
> has done. So here I'm responding to a mail you haven't seen.
>
> >no, i just changed the first one i saw:
> >  unsigned int tT = 13;   //tickTime, makes movie speed
>
> Is that a good speed? I can't really test it on my box here.

It looks okay to me. It's not terribly much slower than the original, but 
lets me view the big colored rooms for a second before the black lines start 
filling in.

> We could save output to text or whatever files directly from the
> Dungeonmaker if we want to have other formats. Maybe the easiest output to
> the web would be like we had it at first, with X's and O's and other
> letters?

that's what i'm thinking.

> >Another, more portable but also Much slower method, is to use write a
> > small Perl script which can read in an ascii dungeon and create the shell
> > script code needed to use the 'convert' tool to build the graphical
> > dungeon. This is much slower because using 'convert' to append many
> > images together can be very slow, but it's also portable to any system
> > which can run bash and 'convert' (which should include cygwin).
>
> I think I've seen that done, and I think it's way too slow.

it could be useful in batch jobs (to "imortalize" a dungeon), but it's not 
suitable for interactive use.

> >> I will make other simpler ways of initializing the Config-object though,
> >> because this design file is rather daunting I think.
> >
> >Amen ;).
>
> Snicker, snicker... but hey man, I followed the design philosophy to not
> have any numbers hardcoded, so i threw them all in that one file, whether
> they were likely to be changed in a design or not. 

Actually, as i was looking through DungeonMaker.cpp, i thought to myself, 
"wow! i don't see anything hard-coded in here!" :)

> I think we can easily make fully automated dungeons now, though we probably
> would use standard design files with that. 

Sounds like a fair restriction to me.

> However, the variation with
> different random numbers is tremendous, particularly with dungeons. Later
> we can make some parameters evolvable, maybe. Still not sure whether I want
> to do that, and whether it's worth the trouble.

Which objects can take advantage of "evolutionary data" now?

> Right now there's two things users can choose about RandCrawlers (note the
> clever mixing of German and English in the term??) 

Actually, i didn't. i just asked a colleague what Rand means in German, and 
he says "edge" or "rim", so now it makes perfect sense. That is very clever 
:). If i had thought about it, my toilet cleaning liquid has this word on the 
package... "bis unter der Rand", or something like that.

...
> can also give them a fairly large corrWidth, which would imply that all of
> them that were born in too cramped quarters would never fill a single
> square, and they'd just mosey into open spaces. Many choices possible...

as i said, yours is certainly the most unique approach to dungeon creation in 
the world.

> I've made the first Dungeon design which I really like, and I wonder...
> should I send it to you? 

Of course! i could use some input for the "dungeon imortalizer" mentioned 
above, anyway ;).

> I'd also have to send the latest Dungeonmaker.cpp
> file, 'cause I don't know how this design would fare with the older code.
> Still fiddling with the code, though I may stop now. Don't know...

Keep sending it...

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862 Handy:  +49 (179) 211 97 67
"Equal treatment is sometimes a tough price to pay for equality."

Re: [DM-dev] Dungeonmaker going on version 2 ...

[Henningsen <pe...@al...>]

I just spent some time on SourceForge trying to change the default behavior
of this list so that posters reply to the list instead of to the previous
poster, but alas, that is not possible. So I guess we'll keep going private
by forgetting to paste the list address in the address field, like Stephan
has done. So here I'm responding to a mail you haven't seen.

>no, i just changed the first one i saw:
>  unsigned int tT = 13;   //tickTime, makes movie speed

Is that a good speed? I can't really test it on my box here.

>> Dungeonmaker's labyrinths - as for the dungeons, that'll come later... or
>> maybe you'll get them on the web somehow, Stephan?
>
>i was thinking about this last night. Using Qt it would be pretty trivial to 
>make an app which reads in a dungeon (from an ascii file or a dungeon object 
>directly) and outputs a graphic version of it. Similar to what QUB does not, 
>but with the output saved to a file, instead of just shown internally in QUB. 

We could save output to text or whatever files directly from the
Dungeonmaker if we want to have other formats. Maybe the easiest output to
the web would be like we had it at first, with X's and O's and other letters?

>Another, more portable but also Much slower method, is to use write a small 
>Perl script which can read in an ascii dungeon and create the shell script 
>code needed to use the 'convert' tool to build the graphical dungeon. This is 
>much slower because using 'convert' to append many images together can be 
>very slow, but it's also portable to any system which can run bash and 
>'convert' (which should include cygwin).

I think I've seen that done, and I think it's way too slow.

>> I will make other simpler ways of initializing the Config-object though,
>> because this design file is rather daunting I think. 
>
>Amen ;).

Snicker, snicker... but hey man, I followed the design philosophy to not
have any numbers hardcoded, so i threw them all in that one file, whether
they were likely to be changed in a design or not. Anyway, until the
Config-object has very much stabilized, I'll not write other file input
things, for otherwise I'd have to change several input chains every time I
need different data.

>A completely automated run would be ideal, but i understand that this may 
>pose a problem for your gentic algorithms (they must have some input, i 
>guess?). Perhaps we can come up with an object which can provide "random" 
>configuration data from a set of "working" inputs. Thus we would have the 
>interface for providing random dungeon inputs, but it wouldn't be really 
>random (at least not intitially). We could then add other "profiles" to that 
>object to provide more random dungeons without clients having to change any 
>code.

I think we can easily make fully automated dungeons now, though we probably
would use standard design files with that. However, the variation with
different random numbers is tremendous, particularly with dungeons. Later we
can make some parameters evolvable, maybe. Still not sure whether I want to
do that, and whether it's worth the trouble.

>> The "RandCrawlers", which randomly
>> start from the edge of the map are a step in that direction. You can make a
>> very good labyrinth design now that just specifies the entrance/exits to
>> the labyrinth, and leaves everything else to RandCrawlers. 
>
>Excellent :).
>
>> I'll do
>> something similar for Tunnelers (starting one Tunneler automatically at
>> every entrance/exit). Then we will be able to do another thing you
>> suggested, creating a dungeon from minimal user input.
>
>That would be ideal for most users, i think. Perhaps we can extend the 
>RandCrawlers so a user can select a more specialized one ("this one doesn't 
>create walls longer than 10 squares", as a completely arbitrary example).

Right now there's two things users can choose about RandCrawlers (note the
clever mixing of German and English in the term??) - decide how many are
started (per 1000 edge squares) in which generation, and choosing the same
identical CrawlerData for them all (the same data one can choose for design
Crawlers). This means, if you want to, you can choose them all to never make
babies (=never branch) and to stop after laying down X squares. You can also
give them a fairly large corrWidth, which would imply that all of them that
were born in too cramped quarters would never fill a single square, and
they'd just mosey into open spaces. Many choices possible...

I've made the first Dungeon design which I really like, and I wonder...
should I send it to you? I'd also have to send the latest Dungeonmaker.cpp
file, 'cause I don't know how this design would fare with the older code.
Still fiddling with the code, though I may stop now. Don't know...

Peter

Re: [DM-dev] Dungeonmaker going on version 2 ...

[Henningsen <pe...@al...>]

>The second design file you sent turns out much better than the one from last 
>week.

I haven't really put much energy into making good designs yet - I'm still
fiddling with the code. Today I worked on a design, but also changed the
code about a dozen times, all concerning the same little problem - I was
trying to make it happen less often that Tunnelers abruptly come to an end -
you know, as if the little orcs were still at work there. That was happening
very much in earlier versions, and I have reduced it to a few occurrences (0
- 3 per dungeon), and I think now it's acceptable. I don't think I can
totally eliminate it.

>i haven't been through any code yet (except to slow the movie down),

HaHa, your system must be faster than mine... I put the speed so low because
I wanted things displayed as fast as they could be computed, no waste of
time. Did you try the 3 different showMovie/storeMovie options?

>not sure how the dungeon stored. What i'd like to see is the dungeon stored 
>in an intermediary object, instead of rendered directly to the graphical 
>area, so we can make ascii dumps, etc.

Oh, it is, the Dungeon is stored in Map, and accessible through GetMap,
though only on a per-square basis. However, it would be easy as pie to pass
the entire Map as one reference (though you'd also need dimX and dimY to
make sense of the one-dimensional Map-vector). I also store the movie, and
already pass it to main() - when you set showMovie=0, storeMovie=1 the
dungeon will be generated, and *then* the movie will be shown from this
stored version. This will be useful because the Tunnelers cannot guarantee
to connect all exits from the dungeon to the entrance, and disjointed
dungeons will have to be rejected before the movie is shown. The showMovie=1
option is mostly for design, where one can see exactly which generation of
Tunnelers/Crawlers does what, an insight that is essential for modifying the
design. If you set showMovie=0, storeMovie=0 you get the finished dungeon
shown directly from the Map, and no movie-related objects are ever filled
with data.

>i'm glancing through DungeonMaker.cpp now and i don't know how you got any 
>work done on your place, with all this code! This thing is tremendous! Is it 
>all a rewrite, or how much did you salvage from 1.x?

Actually, since Christmas I've been working full time on this. I've salvaged
bits of code, in particular from the Crawler-methods, but yes, everything
was really re-written from scratch. Whereas generations were a grafted-on,
imprecise hack in version 1, they are now basic to the program design, and
thoroughly enforced, and vital in designing dungeons. That and the fact that
I made better choices as to which parameters are inherited from parents and
which are set uniformly for generations makes the Crawlers so much better
than before. 

>> ... The user interface in the main()-program consists of
>> cin-cout-code, and thus can only run where it is possible to simultaneously
>> have a console open and an SDL-window. This seems to make it impossible to
>> run the compiled program on Windows, though it may be possible to run it in
>> a debugger where one has access to cout and cin.

>You could possibly get around this by not using cout/cerr/cin directly, but 
>#defining a replacements for them, like these:

>// terminal window:
>#define COUT cout
>// no terminal window:
>#define COUT some_dummy_stream_object

>Then replace all calls like:
>cout << "...working on generation << x << endl;
>to:
>COUT << "...working on generation << x << endl;

>i use a similar method for debugging output (and send everything to a 
>different stream for "production versions"):
>#define CERR cerr << "debug: " << __FILE__ << ": " << dec << __LINE__ << ": "

So what about cin? How do Windows users, cruelly deprived of the benefits of
the console by Bill G., get their input? Remember Eric Pankoke, who compiled
the program for Windows, but it would hang when expecting cin input and he
had to CRTL-ALT-DEL it? (I guess we had the last part of that exchange
offlist, so you *don't* remember that;-) Or so I understood the situation.
Did you ever try to run it in the MSVC debugger, Eric? Does one get
cin-services there?

Anyway, I'm not that concerned with this "running on Linux only" for now.
The DungeonMaker (=everything in namespace alifegames) should run on Windows
just as well, people would only have to write a Windows-interface for it.
Pity Qt for Windows is so expensive... as for me, I plan to write MazeRunner
next, which will be a simple Pacman-inspired game (though very different),
and will not use cin/cout, and should run on Windows without a problem.
Inside that I'll amply demonstrate the beauty of the Dungeonmaker's
labyrinths - as for the dungeons, that'll come later... or maybe you'll get
them on the web somehow, Stephan?

Anyway, when you look at the code, check out the Config-object, and the fact
that it is initialized from one single file, as per your suggestions. I will
make other simpler ways of initializing the Config-object though, because
this design file is rather daunting I think. Probably I should write some
documentation about it before I forget what it's all about. I intend to
split the design file into "coreDesign" and "evolvableParams", and create
options to (totally?) automate and do away with the coreDesign-file if the
user so desireth. The "RandCrawlers", which randomly start from the edge of
the map are a step in that direction. You can make a very good labyrinth
design now that just specifies the entrance/exits to the labyrinth, and
leaves everything else to RandCrawlers. I'll do something similar for
Tunnelers (starting one Tunneler automatically at every entrance/exit). Then
we will be able to do another thing you suggested, creating a dungeon from
minimal user input.

Happy hacking,
Peter

Re: [DM-dev] Dungeonmaker going on version 2 ...

[stephan b. <st...@wa...>]

On Sunday 10 February 2002 14:53 pm, Pete wrote:
> > latest version of the DungeonMaker, and he'll hopefully post his response
> > to seeing the Tunnelers in action (and the new Crawlers, and whatever...)
> > here.

Oh, cool :)
The second design file you sent turns out much better than the one from last 
week.

i haven't been through any code yet (except to slow the movie down), so i'm 
not sure how the dungeon stored. What i'd like to see is the dungeon stored 
in an intermediary object, instead of rendered directly to the graphical 
area, so we can make ascii dumps, etc.

i'm glancing through DungeonMaker.cpp now and i don't know how you got any 
work done on your place, with all this code! This thing is tremendous! Is it 
all a rewrite, or how much did you salvage from 1.x?

Going back to your comment about assert: here's a replacement for assert 
which doesn't kill the app when the assert fails:

#define MYASSERT(ptr, msg, ret) if( ! ptr )  { cerr <<"assert failed: 
"<<__FILE__<<":"<<_LINE__<<":"<< msg << endl; return ret; }

It can be used like this in any function which returns a value:
  MYASSERT( myptr, "myptr may not be null!!!", -1 );
and from void functions like this:
  MYASSERT( myptr, "myptr is null!!!", );


----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862 Handy:  +49 (179) 211 97 67
"Wenn ich singler waere, dann waere ich Gott."

Re: [DM-dev] Dungeonmaker going on version 2 ...

[stephan b. <st...@wa...>]

On Saturday 09 February 2002 00:38 am, Henningsen wrote:
> ... and it
> will throw an uncaught exception if it runs out of memory.

Yeah, but Insufficient RAM is a hardware-level failure ;).

> ... The user interface in the main()-program consists of
> cin-cout-code, and thus can only run where it is possible to simultaneously
> have a console open and an SDL-window. This seems to make it impossible to
> run the compiled program on Windows, though it may be possible to run it in
> a debugger where one has access to cout and cin.

You could possibly get around this by not using cout/cerr/cin directly, but 
#defining a replacements for them, like these:

// terminal window:
#define COUT cout
// no terminal window:
#define COUT some_dummy_stream_object

Then replace all calls like:
cout << "...working on generation << x << endl;
to:
COUT << "...working on generation << x << endl;

i use a similar method for debugging output (and send everything to a 
different stream for "production versions"):
#define CERR cerr << "debug: " << __FILE__ << ": " << dec << __LINE__ << ": "


> But I'm quite sure that for large
> dungeons, this is far and away the best random dungeon generation program
> on the planet.

*applause* *whistles* :)
And certainly the most unique approach to dungeons as well.

> Parallel to this email, I send Stephan (who is under NDA) the

(and also under the influence of many other acronyms ;)

> latest version of the DungeonMaker, and he'll hopefully post his response
> to seeing the Tunnelers in action (and the new Crawlers, and whatever...)
> here.

i'll be building the files you sent me in the next couple of hours, and will 
send any notes here. If it's an improvement on what i saw the other day, then 
i cannot be expected to say anything more than "WOW!"

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862 Handy:  +49 (179) 211 97 67
"Wenn ich singler waere, dann waere ich Gott."

[DM-dev] Dungeonmaker going on version 2 ...

[Henningsen <pe...@al...>]

Hi everybody,
        I've been very busy lately with the DungeonMaker, and have been in
intense private communication with Stephan Beal over the project. Since I'm
entering a critical stretch, I thought I'd report to the list on what's
going on, and Stephan and I can have our discussion here for a bit, and see
if anyone wants to add to the conversation. So here goes:
        I have rewritten the entire Dungeonmaker from scratch. The
DungeonMaker class, together with a lot of new struct and enum datatypes has
been put in a namespace "alifegames". It now uses STL programming
throughout, using vectors for the map, etc... the program is not finished
yet, it will react to corrupt input files on occasion with asserts, and it
will throw an uncaught exception if it runs out of memory. 
        The program consists of 3 cpp-files , the DungeonMaker, the
SDL-Renderer, and main(). The creation of the dungeon is completely
decoupled from the rendering code, and one could easily drop in a different
renderer. The user interface in the main()-program consists of
cin-cout-code, and thus can only run where it is possible to simultaneously
have a console open and an SDL-window. This seems to make it impossible to
run the compiled program on Windows, though it may be possible to run it in
a debugger where one has access to cout and cin.
        The WallCrawlers have been totally rewritten, using the insights I
have gained from observing them a lot, and they are now much better. Also, I
have implemented Tunnelers, which make tunnels in closed areas, and Roomies,
which build rooms branching off from the tunnels. These Tunnelers have very
complex code, with lots of special cases getting special treatment, and I
expect the code to be rewritten for version3. I'll just have to observe them
for quite a while, and gain a deep understanding of their behavior. The
Tunnelers act totally different from the Crawlers, there is almost no code
reuse between the two, and the Dungeons (made by Tunnelers and Roomies) are
completely different from the Labyrinth (made by Crawlers). 
        Oh, BTW, I also have a function that makes rooms in the labyrinth.
And I can seed Crawlers into the Tunnels after they are done, and build a
labyrinth inside the tunnel system. It can get *very* complex. Right now the
program uses just one design file (though I plan on introducing other
options for file input in the future), and the Dungeonmaker is initialized
through one Config-object. Eventually it will be possible to pass
Config-objects in and out of the DungeonMaker, for interactive design and
other things that Stephan may want to do.
        My own assessment of the DungeonMaker is that its main weakness is
that it cannot show its virtues on small maps. It needs maps of substantial
size to really shine, and thus cannot be used for every game design that
calls for dungeons or labyrinths. But I'm quite sure that for large
dungeons, this is far and away the best random dungeon generation program on
the planet.
        Right now this version of the DungeonMaker is closed source, and
only available under NDA. I will show it to a few game companies, but I
don't really expect anyone to license it, and then I will soon make a
release under GPL, so everyone can check things out. My main thrust then
will be to develop MOB's (mobile objects) which move around in the dungeons
and give the player a challenge like it has not been seen in RPG or
DungeonHack-type games. Once I have these going, I'll seriously try to sell
a commercial license. 
        Parallel to this email, I send Stephan (who is under NDA) the latest
version of the DungeonMaker, and he'll hopefully post his response to seeing
the Tunnelers in action (and the new Crawlers, and whatever...) here. 

Happy hacking,
Peter Henningsen
alifegames.com

Re: [DM-dev] Compile question

[Eric P. <epa...@cs...>]

Well, the good news is I was able to make a compile of DungeonMaker 1.2 
under Windows with SDL 1.2.3.  The bad news is that the program doesn't 
terminate!  For some reason I have to hit CTRL-ALT-DEL and kill the 
application that way.  Looks cool other than that, though.

Eric

Re: [DM-dev] Compile question

[Henningsen <pe...@al...>]

>> I've gotten really close to compiling a Windows version with SDL.  The only
>> problem I'm having now is that when I go to make the executable I get the
>> error "undefined reference to WinMain@16".. Any thoughts?
>
>this is a guess (i've never coded under windows), but try renaming main() to 
>WinMain().

No, that wouldn't work, SDL takes care of all that (calling WinMain() etc.)
I think you're including a header file for building the program under Win16
(that would be Windows 3.1 at the latest, Windows95 is Win32) that you don't
really need - could be either with SDL or with MinGW, not with the
DungeonMaker code. I would first check whether you installed a MinGW
component for Win16 and get rid of that. Alternately you could search the
header files you include and comment out the offending references (this can
snowball...:-)

Good luck,
Peter

Re: [DM-dev] Compile question

[stephan b. <st...@wa...>]

On Saturday 29 December 2001 15:31, Eric Pankoke wrote:
> I've gotten really close to compiling a Windows version with SDL.  The only
> problem I'm having now is that when I go to make the executable I get the
> error "undefined reference to WinMain@16".. Any thoughts?

this is a guess (i've never coded under windows), but try renaming main() to 
WinMain().

----- stephan

Re: [DM-dev] Compile question

[Eric P. <epa...@cs...>]

I've gotten really close to compiling a Windows version with SDL.  The only 
problem I'm having now is that when I go to make the executable I get the 
error "undefined reference to WinMain@16".. Any thoughts?

Re: [DM-dev] Compile question

[stephan b. <st...@wa...>]

On Friday 28 December 2001 11:40, Henningsen wrote:
> Ahh, Eric, I'm a spoiled Windows developer myself, and just getting used to
> this gcc stuff. Up to version 1.0 of the DungeonMaker, I compiled it for
> Windows simply by dumping all my source files into the gcc/bin directory
> that you get when installing MinGW, and then executing make.exe. That makes
> it unneccessary to set any search paths, and works well enough for just
> plain .cpp and .h files.

Did you really? Wow!
That's actually a very clever workaround.

----- stephan

Re: [DM-dev] Compile question

[Henningsen <pe...@al...>]

>Forgive the ignorance of a spoiled Windows developer.  I'd like to compile
the latest Dungeon Maker code for Windows, and I've downloaded MinGW, but
I'm not sure what to do from there.  I tend to get lost if there's not a
.dsp file :(  Any help would be appreciated.  Thanks.

Ahh, Eric, I'm a spoiled Windows developer myself, and just getting used to
this gcc stuff. Up to version 1.0 of the DungeonMaker, I compiled it for
Windows simply by dumping all my source files into the gcc/bin directory
that you get when installing MinGW, and then executing make.exe. That makes
it unneccessary to set any search paths, and works well enough for just
plain .cpp and .h files.

However, since I've included the SDL library, I haven't tried compiling for
Windows. If you want to be the brave trailbraker who does it, there's two
options: You could get SDL-devel version 1.08 from http://libsdl.org, and
use whatever tips they give there on compiling SDL-applications on
Windows/MinGW. However, in the latest version of SDL, version 1.2, they have
apparently abandoned MinGW, and give instructions for compiling
SDL-applications in MSVC++ v6. If you have Microsoft's sleek compiler, your
best bet would be to get SDL version 1.2, and use the process described for
compiling SDL-apps on that. Someone just put a tutorial for that on the web,
not on libsdl.org, you might have to google for that, or be lucky finding a
link.

There's also a problem on Linux, because the make-file that comes with the
program links to SDL as a shared library, and you need the shared library
SDL 1.0x to run the executable I produced. It does not seem to work with the
latest SDL-version 1.2. Because of this, I'd actually prefer to link
statically to SDL, but I haven't put my mind to it yet. I much prefer to
program, and I'm deeply into re-writing the DungeonMaker code from scratch. 

By the time I get version 2.0 of the Dungeonmaker out the door, I'll try to
get it to compile with static libraries, and on Windows too. Maybe I'll even
get the latest MSVC.NET to do it. Until then, if you *do* manage to compile
it for Windows, let me know, and we can release the executable on SourceForge.

Peter