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

[DM-dev] license include

[Stephan B. <ste...@ei...>]

FYI:

You can now include the GPL license and alife copyright into your code=20
with:

#include <dm/License.h>

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Belief makes a hollow place. Something has to roll in to fill it."
-- Terry Pratchet

[DM-dev] design decision question:

[Stephan B. <ste...@ei...>]

Good morning, all!

Question for Peter:

There a couple of ways of managing the Rooms/Walls/Dungeon=20
relationship, and I'd like to detail what I see as the differences and=20
get your idea on which one to choose:

As we discussed once, we could get rid of Dungeon, and make everything=20
a Room. This has the advantage of simplification of the API and=20
heirarchy, but it may not be compatible with the crawlers. Rooms could=20
contain any number of other rooms, just like a UI does with it's=20
widgets. A dungeon is just a big room, after all.

I started on the Walls last night and came up with the following=20
parameters for each wall: x, y, length and orientation (horiz or=20
vertical). This keeps the user (and us) from having to check for=20
(x1=3D=3Dx2 || y1=3D=3Dy2, i.e., for enforcing non-diagonal walls), and=20
simplifies the API further.

The question, though, is about the x/y: should they be relative to the=20
dungeon or to the containing room? It could be done either way.=20
Room-relative _seems_ to make more sense to me, but I'm not sure if=20
that's the best approach for this project.

I think the answer lies in the Crawlers' behaviour: do they navigate=20
the dungeon based on the values of the map grid, or do they interact=20
with the Rooms objects in a more complex manner? If they navigate the=20
grid directly, then I think it's safe to make the x/y ROOM-relative,=20
because we will render the rooms, then let the crawlers lose. If they=20
navigate the rooms in some other way (by interacting with the Rooms=20
objects), then I'll need a much clearer understanding of this=20
relationship before I start so I don't break the crawlers.
Room-relative is a higher-level approach than making them=20
Dungeon-relative (but if the Dungeon was just a room, "stray" walls=20
could be placed in the Dungeon with the same API). The main advantage=20
of this approach, I think, is that it's consistent with UI-building=20
techniques: you always give coordinates of child objects based off of=20
their parent. It also allows easily creating heirarchies of rooms and=20
walls and them dumping them into the Dungeons (or removing them). This=20
also means that in config files, users don't have to change a room's=20
walls if they move the room - they simply change the x/y coords of the=20
room itself and all child walls move with it.

The disadvantage, though, is that I'm not sure if that internal=20
representation is compatible with the crawlers. If a crawler breaks=20
through a wall of a room, for example, that "hole" won't be stored in=20
the room itself (because the crawler is working off of a rendering of=20
the room, and not the room itself, so the room never sees the hole), so=20
regenerating the dungeon won't be as simple. I don't think that's=20
_such_ a concern because we can regenerate the dungeon as long as we=20
have all the rooms intact and the random seed, I think.

If you'll tell me that the crawlers simply analyze the grid after the=20
rooms have been rendered to it, I'll continue with this more=20
heirarchical approach.

I've got save/load of data working, so now I just need to get the=20
objects done so I can save them ;).

Your opinion(s)?

See ya!

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Belief makes a hollow place. Something has to roll in to fill it."
-- Terry Pratchet

[DM-dev] Properties object status

[Stephan B. <st...@wa...>]

The DMProperties object (replaces 'config object') is now in CVS and can load 
and save itself to/from text or to/from another DMProperties object. What 
this means, is, we can have an ini file like this one:

andthisone=is at the front of the list
bool_true=false
bool_words=yesireebob
double=2.315680
eat=this
one=1
string=hey
xxx=in the middle
;comment
foostr=bar
fooint=42
;comment2
#comment3
crawler.prop1=yes
crawler.foostr=bar
crawler.fooint=42

And then read it in into two different properties objects, like this:
(assume for a moment that Crawler subclass DMProperties!)

int
main (int argc, char *argv[])
{

    string filename = argv[1] ? argv[1] : "my.dungeoninfo";
    DMProperties file( filename, true );
    if( ! file.load() ) exit( 666 );
    //file.toCerr();
    DMProperties crawler( "crawler" );
    crawler.loadFromProperties( file );
    crawler.toCerr( false );
    exit( 0 );
}

This prints out the following:
<<< crawler: >>>
fuckoff=yes maza
foostr=bar
fooint=42
>>> :crawler <<<

Notice how it only contains keys from our config file which started with this 
object's name ("crawler"). This alllows us to store any number of objects in 
the object. Their file output could look like this:

crawler.1.prop1=yes
crawler.1.foostr=bar
crawler.1.fooint=42
crawler.2.prop1=eat this
crawler.2.foostr=hello, world
crawler.2.fooint=21

These could be programatically created with this code:

DMProperties c;
c = DMProperties( "crawler.1" );
c.set( "foostr", "hello, world" );
...

One good question is:
How do you read them back, if you don't know what their names are?

There are two options:

First:
We cheat a little: we have the user tell us:

crawlers=1 2
or:
crawlers=bill, ted, 1-10

Then we create DMProperties objects with those names and populate them. Items 
not listed like this are effectively "commented out" of the config data. But 
the config reader still keeps them in pure text form, and they will be 
written back out to the file when it is saved, so no data is lost. This gives 
a lot of room for flexibility in testing out changes to your config files. 
But, yes, it is a slight hassle if you're creating them by hand.

Second:

We make some rules regarding the naming of objects, and then do something 
like this with the naming:

objectype.name.property=val

Then, when someone calls:
DMPropertiesList *DMProperties::getObjects( "objecttype" );
we will instantiate all objects of that type (they're all just DMProperties 
with different names, after all), set all of it's properties, and give back a 
list of them. That function is not yet implemented by the way.

Number 2 sounds like the way to go, so that's what I'm gonna work on next. 
Tomorrow night, anyway.


----- Stephan Beal - st...@wa...
http://qub.sourceforge.net  -  http://stephan.rootonfire.org
http://dungeonmaker.sourceforge.net
"Now I'm not normally the kind of person who likes to trespass, but
sometimes you just find yourself over the line." -- Bob Dylan

[DM-dev] idea!

[Stephan B. <st...@wa...>]

I just started working on the Rooms/Walls combos and came up with some ideas 
I'd like to throw by you and see if they sound as useful to you as they do to 
me:

Current DM holds it's own array of ints for the map. I'd like to split that 
into a DMGrid object, which does the same thing but in it's own object. The 
reason is simple:

bool Room::render( DMGrid & );

lets the room "draw" it's contents onto the target grid. Returns false if 
there is some error (out of bounds, etc., though the item would still be 
rendered as much as it could.

Even better would be to make a Renderable interface and have Room and Wall 
subclass that, then we have:

DMGrid::render( Renderable * );

But I'm not sure what the Renderable API would have to look like (it would 
have to be generic enough to allow the DMGrid to handle drawing for all types 
of objects, and this seems a bit complex). I'd appreciate any ideas on a 
Renderable API which would allow DMGrid to handle all the rendering. That 
would allow a single point of operations for all drawing activity - we could 
add any number of Renderable objects without changing the drawing code. But 
we do have to make a flexible and not-too-much-work-for-the-coder way of 
representing the render data to the DMGrid. I can only think of providing a 
list of coordinates. Something like this:

DMGrid::render( Renderable *rendit )
{

// Point == pair<int,int>
// CoordsList == list<Point>;
...
CoordsList cl = rendit->GetRenderCoords();

// now iterate through cl, take out the x/y coors, and call
// this on each iteration:
{
    DungeonMaker::SquareTypes sq = rendit->GetSquareType( x,y );
    SetSquare( x, y, sq );
}
...
} // end render()

The problem, though, is that rendit->GetSquareType() has to have a way of 
returning that data which does not overburden the maintainer of the 
Renderable class which we are working with. If it's too much work for the 
coder for each new class, I don't wanna do it. If we can, though, then any 
item which is Renderable can be drawn onto the map easily and painlessly with 
very little coding.

For now I'll go with the first option (much simpler, though not as 
watertight).

Either way, it abstracts our data representation and allows non-DungeonMaker 
objects access using a simple interface.

Does this sound okay? It would also mean simplification of the DungeonMaker 
class internals and API (plus adding Set/GetGrid() methods).



----- Stephan Beal - st...@wa...
http://qub.sourceforge.net  -  http://stephan.rootonfire.org
http://dungeonmaker.sourceforge.net
"Now I'm not normally the kind of person who likes to trespass, but
sometimes you just find yourself over the line." -- Bob Dylan

[DM-dev] fyi: KDevelop project file is in CVS

[Stephan B. <ste...@ei...>]

The Project-->Options-->'binary' isn't set to anything useful, but it=20
currently has all files which are in the project. If you update this,=20
PLEASE make sure to UNCHECK the 'Modify Makefiles' option in KDevelop=20
(in the Project ---> Options dialog). If this is checked KDevelop will=20
rape the makefiles, bastardizing them completely. Ideally, KDevelop=20
should NOT be used to update the project - update the Makefiles and=20
then use KDev's "Generate Project" command (after doing this, UNCHECK=20
that box, as it will be re-checked). Not that if you have the project=20
open, you MUST close it before running Project -> Generate Project=20
File, or your view will NOT reflect reality (KDev bug since at least=20
1.2).

I will update this proj file as I add classes to the project. Of=20
course, anyone else is welcome to do the same.

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Belief makes a hollow place. Something has to roll in to fill it."
-- Terry Pratchet

[DM-dev] CVS: did you know?

[Stephan B. <ste...@ei...>]

You can have multiple CVS trees in the DungeonMaker project on=20
SourceForge. We could use this to keep DM1 and DM2 in separate trees,=20
if you like (this would be ideal, I think). If you'll send me a tar/gz=20
of what you want for the DM1 tree, I'll do that for you.

You can see a sample of this in QUB's CVS tree:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/qub/

Each of the dirs you see there is independently "check-outable." I just=20
realized, to, that we can edit the data in the CVSROOT dir (an=20
administrative dir used by CVS). With this we could make CVS email=20
someone (or a group of people) for every CVS commit. We do that here in=20
the office, and it's sometimes very helpful. I'll experiment with that=20
on QUB and see if it works from the SF cvs repositories.

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Belief makes a hollow place. Something has to roll in to fill it."
-- Terry Pratchet

[DM-dev] explanation of config object, plus sample

[Stephan B. <ste...@ei...>]

I've put together the first go at the config object and it's=20
interaction with other objects. It works something like this:


class Configable:
  virtual void saveToConfig( DMConfigFile &conf,=20
=09const char *prefix =3D 0 );
  virtual void loadFromConfig( DMConfigFile &conf,=20
=09const char *prefix =3D 0 );
  static string key( const char * prefix,=20
=09const char *suffix ); // util function. Forget it for now.

Any classes which want to save to or load from a DMConfigFile must=20
inherit this class and implement save...() and load...(). A sample=20
implementation is here:

-------------------------------------------------
SimpleConfigable::SimpleConfigable() : Configable()
{}

SimpleConfigable::~SimpleConfigable()
{}
void
SimpleConfigable::saveToConfig( DMConfigFile &conf,=20
const char *prefix =3D 0 )=20
{
  conf.set( key(prefix,"foostr"), string("bar") );
  conf.set( key(prefix,"fooint"), 42 );
}

void
SimpleConfigable::loadFromConfig( DMConfigFile &conf,=20
const char *prefix =3D 0 )=20
{
    myString =3D conf.getString( key(prefix,"foostr"),=20
=09=09"error - not found" );
    myInt =3D conf.getString( key(prefix,"fooint"), -1 );
}
-------------------------------------------------
That's it!

The usage of the 'prefix' variable becomes necesarry when multiple=20
objects of the same type are stored in the same data stream, or when we=20
want to break it down more heirarchically. It can be used, for example,=20
to store multiple crawlers, by prefixing each one with "crawler.N.",=20
where N is some number which uniquely identifies that crawler. The call=20
to key() simply combines prefix with the user's key, into something=20
like "crawler.1.foostr". If prefix is empty, key simply returns the=20
user's plain key, like "foostr".

Saving the object's state to the config file is now as simple as:
  DMConfigFile c( "myfile.config" );
  SimpleConfigable sc;
  sc.saveToConfig( c );=20
  bool okay =3D c.save();

If you have a completely populated DM object, you could save the whole=20
thing to a config file with:
  DMConfigFile c( "myfile.dungeonconfig" );
  dm->saveToConfig( c );=20
  bool okay =3D c.save();

dm::saveToConfig() will know how to write it's child objects into the=20
config object, as well as how to read them back via loadFromConfig().

The principal idea is that the config object doesn't know, and doesn't=20
care, about the data. The Configable objects (crawlers, walls, etc.)=20
can do this themselves - THEY'RE the ones interested in it, anyway (and=20
it's no fun to maintain another person's data for them, is it?). This=20
way changes to the Wall data format does not affect the DMConfigFile,=20
which is good.

Once the DMConfigFile can add in user-given command line args, objects=20
which load themselves via loadFromConfig() will also have access to=20
those options. That could be used like this:

=2E/myapp -dm-maxWallLength 27

main(...)
{
  DMConfigFile conf;
  conf.addArgs( argv, argc );
=2E..
}

Then the Wall class could check for this variable by using=20
conf.getInt( "-dm-maxWallLength" ), limiting it's size if it is set.=20
This is a somewhat useless and arbitrary example, but you get the idea.

Reading back the objects will be a bit more effort, but will be wrapped=20
up in helper functions in DMConfig itself, like GetWalls(). The work=20
needed by the client objects (like SimpleConfigable) is the same as it=20
is to save - one line per field we want to save or load.

The DungeonMaker object will, upon saving, call saveToConfig() for all=20
of it's Configable children, so they'll all be stored in the config=20
object. It will also read them back on load(), but that's not yet=20
implemented.

I hope to have the first loading of basic objects done tonight, but it=20
may take me until tomorrow evening. The best part is that once the=20
save/load is written in the config object, it never needs to be touched=20
when adding new object types (unless we want to add a helper function=20
for it). The class simply overrides save...() and load...() and does=20
that himself. That allows greater flexibility and modularity in=20
development at the cost of a very small amount of work to be done in=20
implementing save...() and load...() for each Configable class.

Now, I'm somewhat embarrased at the primitiveness of this approach=20
because it's a very simplified version of what QUB uses. But I was=20
forced to slim it down for several reasons:
1) no XML in DM (and QUB relies on Qt's XML support, so I couldn't port=20
it to DM without Qt-ifying DM).
2) DM doesn't have "too" complex data storage needs. I would love to be=20
able to store data more heirarchically (whole trees of objects, with=20
arbitrary tree depths, for example), but that won't be practical with=20
this approach. At some point if we need a more complex approach I can=20
work on something closer to what QUB uses (which, basically, is a=20
completely generic persistant data storage framework).
3) I'm working with standard C++ classes only, and I don't know much=20
about them (I learned C++ by using Qt).

Regardless the restrictions imposed by the environment, however, I=20
think this will suit us well, at least for a first go at DM2.

A note about binary data: If I had made this sufficiently generic, it=20
would be a relatively simple matter to extend it to writing binary data=20
with NO changes to the client objects (the only real work would be in=20
writing the binary file parser). To do that I need to add one more=20
layer of objects. I know how it would be done, but I'm not going to=20
implement that just yet. Besides, I'm not up for writing the binary=20
file parser at the moment (one must walk before one runs...). Let's get=20
this system done, and I can rewrite it later if needed (did I mention=20
that I like rewriting?).

So, I'm trudging on ahead with that. If someone doesn't like it, please=20
let me know - I'm always open for discussion on these things.

See ya!

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Belief makes a hollow place. Something has to roll in to fill it."
-- Terry Pratchet

[DM-dev] lines of communication between objects

[Stephan B. <ste...@ei...>]

Good morning!

For the upcoming changes we'll need to define some lines of=20
communication between the various objects. I mean, we'll need to decide=20
which objects know about each other, and how they interact. If we can=20
abstract this a bit (like by subclassing Rooms and Crawlers from a more=20
generic DungeonElement) they we will get the most extendability out of=20
it. These are my initial thoughts about who has to know about who=20
(denoted by arrows pointing to/from the classes):

For example:
Rooms <--- Walls
This means that Rooms need to know about walls, but walls don't need to=20
know about rooms.

Crawler <---> ???
DungeonMaker <---- Rooms
DungeonMaker <---- Crawler (??? <--- DungeonMaker)

All <---- Config (config is a bad word for this, because it implies ini=20
file, when it's really more generic than that - suggestions for a=20
better name?)

Once this is agreed upon I can start with the containers for holding=20
these objects (will use STL classes like maps, vectors, lists and=20
pairs), and the APIs for moving/copying them between objects (i.e., the=20
various AddXXX() methods).

Speaking of rooms:

The way I envision the basic Room API is something like this (of=20
course, completely up for change, though):

Remove/AddWall( Wall );=20
AddWall( int x1, int y1, int x2, int y2 )=20
// creates a Wall and calls AddWall( wall )
// must assert that x1=3D=3Dx2 OR y1=3D=3Dy2 (no diagonal walls), but thi=
s will=20
be done in Wall, and Wall will have a bool IsStraight() method which=20
returns false if the wall is not "straight".

typdef list<Wall *> WallList;
WallList GetWalls();  // DM can use this to actually lay out the room.

Various other STL-like iterator methods will also be supplied, for=20
looping through the walls.


Ideas?


----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Belief makes a hollow place. Something has to roll in to fill it."
-- Terry Pratchet

Re: [DM-dev] Plans for DungeonMaker 1.x and 2.0

[Stephan B. <ste...@ei...>]

On Wednesday 25 April 2001 00:34, you wrote:
> DungeonMaker much easier to use. I hope he will also do some other
> stuff, such as replace "design-data:Rooms" with more versatile
> "design-data:Walls".

I was thinking about this this morning: what exactly is a wall, in our=20
context? Nothing but a set of two points, both of which must have the=20
same x or the same y. A room could basically be a collection of n walls=20
(4 would be simplest, and what I would start with, but adding support=20
for n walls would be too hard, except we would have to restrict n to=20
numbers which could make parallel-only walls (no 5-walled rooms, for=20
example). A Room then just becomes a wrapper around n Wall objects, and=20
coordinates their connections to each other.

> Since there are so few of these, we might do away with this file
> altogether, and just have an interface function that changes the
> defaults (for programmatic use of the DungeonMaker) and maybe a
> command line option for minCorrWidth.

I've started working on a way for clients to pass options like this to=20
the DM in a standardized way, using command-line options or hard-coding=20
them (it's the same method, internally, so it'll be consistent across=20
client apps). Basically it works like this:

The configuration object will have a method: parseArgs( char **argv,=20
int argc ), passed to it from main(). It will parse out any=20
command-line options and add them to the configuration. So a client=20
could do something like this:

=2E... main()....
  config.parseArgs( argv, argc );=20

// assuming the user passed -minCorrWidth X on the command line, the=20
config object will automatically pick that up and feed it to the DM.=20
Also, the setting would be saved if we save out config object to a file.
 =20
> as well as arbitrary numbers of
>         Rooms-struct's, later to be replaced by Walls-struct's

I think it would be simpler for users if we keep the rooms, for ease of=20
use, AND offer walls (for fine-tuning). Rooms, after all, are just=20
wrappers around N walls.

> Default: they are read in from file.

Using the above argument parsing option, a user could override file=20
settings on the command line:

config.load( filename )
config.parseArgs( argv, argc ); // my -minCorrWidth X will override=20
that from the file now

> Read in from pre-designed files
> If the GENETICparams and the DESIGNparams are designed together and
> kept tightly coupled, a wider variety of dungeons can be generated.

Since the config object can save itself to a file, you can always=20
recreate any dungeons created using that data (even if it was randomly=20
assigned by a client app).

> I will also write another layer on top of DungeonMaker (code-named
> DM2), which will compute paths through the generated dungeon, find
> enclosed rooms, and put doors into them to open them up according to
> a (you guessed it) new set of parameters that will open up the most
> amazing design options for the user. This will allow us to make
> dungeons with any mixture between random rooms and random mazes that
> we may desire - plus the predesigned dungeon structure that comes
> from the DESIGNparams.

As an old boss of mine used to say, "I'm moist with anticipation!" ;)

> Stephan is writing a config-object that will hold all these data, and
> make them available to the DungeonMaker, and a parser that will be
> able to read the data from a variety of files in a robust manner. If
> he's very generous he will also replace the rooms-related code with
> walls-related code, and make the Dungeonmaker more versatile that
> way.

That's the plan.

> PS: Do you want me to post my opinion on the best
> Wall-data-structure?

Yes, please! I'll be basically done with the config object Real Soon=20
(it's working, it just needs to extra bonus functionality like parsing=20
command-line options). Once that's done I will immediately start on the=20
actually deserialization of objects to/from the config file. The walls=20
would be as good place to start as any, I guess.=20
I've got some ideas which will help make this really extendable,=20
allowing new object types to be put into the config and parsed back out=20
without _any_ changes to the config object itself. I'll put together a=20
demo of that functionality by this weekend and get it into CVS so you=20
can see what I mean.

See ya!

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Belief makes a hollow place. Something has to roll in to fill it."
-- Terry Pratchet

Re: [DM-dev] Plans for DungeonMaker 1.x and 2.0

[Stephan B. <st...@wa...>]

On Wednesday 25 April 2001 00:34, Henningsen wrote:
> Hi there.
> 2. Then I will hand the hat of DungeonMaker lead developer to Stephan, at
> least for a while. Stephan will clean up the file structure and loading
> process used by DungeonMaker, and will make DungeonMaker much easier to
> use. I hope he will also do some other stuff, such as replace
> "design-data:Rooms" with more versatile "design-data:Walls".

I am honored! Thank you very much! I will certainly try to live up to your 
hopes.

> I will now lay out the data structure of the DungeonMaker as i envision it.
> consider this the first version of the design document that Stephan will
> hopefully implement with his config-object.
...
> OK, Stephan. Over to you.
> Peter
> PS: Do you want me to post my opinion on the best Wall-data-structure? Or
> anything else?

I'll comment on the rest of it tomorrow. I'm gonna get to bed in a moment. 
But, thank you very much once again. I'm shocked, but in a pleasant way. I 
the the 1.0 release and then longer-term reorg is a good idea.

More in the morning!

----- Stephan Beal - st...@wa...
http://qub.sourceforge.net  -  http://stephan.rootonfire.org
http://dungeonmaker.sourceforge.net
"Now I'm not normally the kind of person who likes to trespass, but
sometimes you just find yourself over the line." -- Bob Dylan

[DM-dev] Plans for DungeonMaker 1.x and 2.0

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

Hi there.

Stephan has been really getting into the Dungeonmaker code, producing a
sophisticated file structure and make process, and he's not done yet. I have
decided to do the following:

1. I will release version 1.0 of the DungeonMaker, which will contain few
and subtle changes from version 0.91. It will consist of 3 files, have a
very simple make process, will be easy to understand, and somewhat awkward
to use.

2. Then I will hand the hat of DungeonMaker lead developer to Stephan, at
least for a while. Stephan will clean up the file structure and loading
process used by DungeonMaker, and will make DungeonMaker much easier to use.
I hope he will also do some other stuff, such as replace "design-data:Rooms"
with more versatile "design-data:Walls".

While Stephan takes the lead in development i will still be available to
make any changes in AI-related code that might come up, and will authorize
file releases.

Probably by next fall or winter i will take a more active role in
development again, and will implement evolving dungeons and dungeons with
arbitrary percentages of randomly placed rooms (this will allow us to make
all kinds of possible dungeons, not just the maze-like structures the
Dungeonmaker excels at today).

I will now lay out the data structure of the DungeonMaker as i envision it.
consider this the first version of the design document that Stephan will
hopefully implement with his config-object.

DungeonMaker data structure:

1. CONSTANTs - this data is normally used per default, but can per command
line also be read from a file:

minCorrWidth
smallestRoomWidth (this will be obsolete when we go over to Walls instead of
Rooms)

Since there are so few of these, we might do away with this file altogether,
and just have an interface function that changes the defaults (for
programmatic use of the DungeonMaker) and maybe a command line option for
minCorrWidth.

2. DESIGNparams - formerly called the rooms-file

contains these params formerly formerly from the constants-file:
maxCrawlers
chDirOnStraight
joinDist

this parameter that is currently a compiled-in constant:
maxStats (the number of stats-structs that are stored - when generation >=
maxStats, the "getStats(generation)"-functions return GetStats(maxStats-1) )

and from the rooms-file:
dimX , dimY

as well as arbitrary numbers of
        Rooms-struct's, later to be replaced by Walls-struct's
        GuaranteedOpenSquare's
        Hand-Placed_Wall_Tile's
        Hand-Placed-Column's
        Design-Crawler's

DESIGNparams are the parameters that determine the structural layout of the
generated dungeon.
DESIGNparams will be used in the following fashion:

Default: they are read in from file.

Option 1: there are a few "types" of maps that the user can choose, such as
"solo traversal", "2-player-confrontation", "4-entry-point-center-quest",
... , and the program will generate DESIGNparams internally to create
strongly randomized versions of these map types. More things will vary than
just the GENETICparams (see below).

Option 2 (for version 2): We read in two sets of stored DESIGNparams, and
create one combination by "controlled crossover". "Controlled Crossover" is
a sophisticated process I'm working on that allows the combination of two
DESIGNparam-vectors in a fashion that makes sense for the specific data -
the vectors can grow, shrink and mutate. This process is controlled by its
own set of parameters (which will need their own file, and their own
defaults, or which the user might change interactively - i don't know yet,
we'll have to try things out and see how they work - maybe we'll also stick
some in the DESIGNparams-set and some in the GENETICparams-set).

3. GENETICparams - formerly called the stats-file

contains "maxStats" sets (one per generation 0 , 1 , 2 , 3 , ... ,
maxSats-1) of these params:

stepLength
corridorWidth
changeDirProb
noDirectionProb
maxAge

openStartprob
closedProb (this is new, and will be used to make closed rooms - for now
default to zero, and enable values >0 only per command line option for
people who want to manually place doors in the closed rooms that will ensue)

straightSpawnProb
doubleSpawnProb
jumperProb

skipGenerations
lateSpawn
lateSpawnProb

The GENETICparams determine the local character of the generated dungeons,
and are eminently well suited for being changed by crossover and mutation.
They will be used in the following fashion:

Read in from pre-designed files
If the GENETICparams and the DESIGNparams are designed together and kept
tightly coupled, a wider variety of dungeons can be generated.

In version 2 GENETICparams will be used in the following fashion:
There will be a binary file that keeps a number of GENETICparams-sets
stored, together with their "fitness" values. When the user wants a new
dungeon, a new GENETICparams-set is created as a baby from two "parents"
selected from this file. After playing the dungeon, the user will be able to
give a quality rating - if this is high enough, the baby (now matured and
wise beyond its years) will be entered into the parents-file. In this way,
the dungeons can dynamically adapt to the user's preferences.

For version 2, I will write an "evolutionary-engine" object that will manage
the GENETICparams-file, accept user-ratings, and return fresh
GENETICparams-sets upon request.

I will also write another layer on top of DungeonMaker (code-named DM2),
which will compute paths through the generated dungeon, find enclosed rooms,
and put doors into them to open them up according to a (you guessed it) new
set of parameters that will open up the most amazing design options for the
user. This will allow us to make dungeons with any mixture between random
rooms and random mazes that we may desire - plus the predesigned dungeon
structure that comes from the DESIGNparams.

Stephan is writing a config-object that will hold all these data, and make
them available to the DungeonMaker, and a parser that will be able to read
the data from a variety of files in a robust manner. If he's very generous
he will also replace the rooms-related code with walls-related code, and
make the Dungeonmaker more versatile that way.

OK, Stephan. Over to you.
Peter

PS: Do you want me to post my opinion on the best Wall-data-structure? Or
anything else?

[DM-dev] change to top-level makefile, etc.

[Stephan B. <ste...@ei...>]

Running 'clean' from the top-level source dir now cleans recursively.=20
To get recursive cleaning in other dirs run 'make distclean' from that=20
dir (this also works from the top-level).

After doing this, you MUST run 'make' from the top-level tree once=20
before running make in a subdir, so common.make can be created.

Also, please run 'cvs update -dP' to delete your copies of the=20
include/ini dir. It's no longer around (it was for libini stuff, which=20
doesn't exist any more).

I will remove the StringTokenizer code tonight and replace the=20
DMConfigFile's usage of that class with some slightly-less-GPL code.

See ya!

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Belief makes a hollow place. Something has to roll in to fill it."
-- Terry Pratchet

[DM-dev] Makefile documentation and such

[Stephan B. <ste...@ei...>]

I just added the following to CVS:
doc/developer/README

This explains how to use the Makefiles, more or less, and how to create=20
new ones for your subdirectories, so they'll work in the overall=20
process.

I'll edit it as I make changes to the process/structure.

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Belief makes a hollow place. Something has to roll in to fill it."
-- Terry Pratchet

Re: [DM-dev] Working on new interface

[Stephan B. <ste...@ei...>]

On Friday 20 April 2001 00:59, you wrote:
> The interface we are developing should work for all these uses -
> interactive design, dungeon evolution, ... we hope that by designing
> an interface that will work for these uses, we will get a universally
> useful interface. The program is being re-written in many places.
> Here are some points:

And if we don't get it right the first time, then we can re-write ;).=20
(Hey, I like rewriting - it shows that we're learning from our mistakes=20
:).

> As for file in/output, the Dungeonmaker will abandon its 3-file
> system and go to one unitary file, which it will be able to read and
> write. For reading, Stephan intends to implement a parser that will
> allow the most wonderful things re extendability and maintainability
> of the code.=20

It's just a simple ini-file parser, actually ;). It'll just be=20
customized to handle DM-only objects.


> The dungeon-evolver (still not the right name, suggestions,=20
> anyone?)=20

Actually... I rather like that name. Dungeon Evolver. Dungeon Evolution=20
Pit? ;)

> We are actively developing the program in CVS, but things are pretty
> chaotic at present, and the Windows build is broken. If you have any
> suggestions, we listen. Now's the time, here's the place. This will
> be the last major re-write for 2001.
>

Ah, bummer ;).

> I think, anyway.

Yeah! There's still hope!;)

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Belief makes a hollow place. Something has to roll in to fill it."
-- Terry Pratchet

[DM-dev] Working on new interface

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

I would like to let the list participants know that Stephan Beal has joined
the DungeonMaker team, and that we're very busy - exchanging about a dozen
emails daily offlist trying to come up with a better DungeonMaker interface.

Stephan is lead developer of the QUB project, a universal boardgame. We want
to get the DungeonMaker into shape as a library that can be called from QUB
to get random dungeons in there, and also to design dungeons interactively.
Right now, the DungeonMaker can only generate dungeons based on its 3 input
files, and interface functions for interactive design are missing. In fact,
a DungeonMaker object does not even contain the data that would have to be
inspected and changed for interactive design - the design data are read from
file and directly put on the map without being stored anywhere.

My initial goal with the DungeonMaker had been to be able to create high
level tools to navigate through the space of all possible dungeons. However,
I found that too many randomly generated dungeons sucked, and gave up on
this approach. Now I have been re-infested by Stephan's enthusiasm, and have
worked out a fresh approach that will hopefully allow the evolution of
dungeons based on user ratings - for this to work, several design parameters
(mostly from the rooms-file) will have to be pre-selected by the user, and
then the other parameters (mostly from the stats-file) will be treated as
genes in a genetic algorithm with fitness a quality rating that the user has
to supply. In this manner, it should be possible to adapt DungeonMaker's
dungeons to every user's individual taste.

The interface we are developing should work for all these uses - interactive
design, dungeon evolution, ... we hope that by designing an interface that
will work for these uses, we will get a universally useful interface. The
program is being re-written in many places. Here are some points:

Rooms will no longer be a low level construct used by the DungeonMaker -
instead we will be using Walls (which can have doors in them). Higher level
programs can have different types of Rooms that are all instantiated by
calling several Dungeonmaker Walls. All the Rooms code, including placement
by the division method, door ornamentation, and legality checking will be
ripped out.

The DungeonMaker object will keep a full list of all design elements that
are needed to produce (or reproduce) a dungeon as class members. These are
the random seed used, the parameters from the Constants-file, dimensions,
and then variable length arrays of class vector<Element> with Element =
OpenSpace, Column, Wall, Crawler, Stats. There will be a full complement of
functions to show, change, add and delete any of these elements. This can be
used for interactive design and also for programmatic input of dungeon
design data (without file reading).

As for file in/output, the Dungeonmaker will abandon its 3-file system and
go to one unitary file, which it will be able to read and write. For
reading, Stephan intends to implement a parser that will allow the most
wonderful things re extendability and maintainability of the code. He can
explain that better than I. The parser should also be able without much
change to work with the different filesystem that will be used by the
dungeon-evolution program (name to be determined). This will not be
implemented in the core DungeonMaker library, but will be a separate layer
on top of it. The dungeon-evolver (still not the right name, suggestions,
anyone?) will also be able to be used as a random dungeon generator with
minimal input. I intend to supply separate evolutionary paths for Dungeons
of type:
1. Solo Dungeon Traversal
2. 2 person confrontational;
3. 4 entry point center quest (for 1 - 4 competing players or 2 teams of 2)
and for small, medium and large dungeons, 9 evolutionary environments in all. 

We are actively developing the program in CVS, but things are pretty chaotic
at present, and the Windows build is broken. If you have any suggestions, we
listen. Now's the time, here's the place. This will be the last major
re-write for 2001. 

I think, anyway.

Peter Henningsen

Re: [DM-dev] brilliant :)

[Stephan B. <ste...@ei...>]

On Wednesday 11 April 2001 18:24, you wrote:
> I only got the top line of the dungeon , and that took a while - html
> wasn't meant to render huge graphics blockwise, I guess. If you can
> use the dungeon data directly instead of messing with the text output
> (which I mostly intended for designing dungeon files) I think that
> would be better. Anyway, the script *did* run, and it would be kinda
> nice to have dungeons in a html-file if that loads in a decent time
> frame.

I had the same problem: Netscape takes well over 1/2 minute to load it=20
on my (fast) machine. The Qt HTML browser is very lightweight, though,=20
and loads in in less than 5 seconds, with no lag while scrolling=20
through it. It's not terribly useful, though (see comments at the top=20
of the script). I'll make a version which outputs graphics this=20
weekend, which'll be much more useful.

--=20
----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Belief makes a hollow place. Something has to roll in to fill it."
-- Terry Pratchet

Re: [DM-dev] brilliant :)

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

>Okay, I've got a script which turns Dungeon files into HTML with 
>graphics. It's attached, just for the curious, but it needs some major 
>work before it's really usable. It has some limitations which need to 
>be cleaned up before I send it to the list, however:

I only got the top line of the dungeon , and that took a while - html wasn't
meant to render huge graphics blockwise, I guess. If you can use the dungeon
data directly instead of messing with the text output (which I mostly
intended for designing dungeon files) I think that would be better. Anyway,
the script *did* run, and it would be kinda nice to have dungeons in a
html-file if that loads in a decent time frame.

Peter

Re: [DM-dev] brilliant :)

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

>It's brilliant :). A couple of month ago I started pouring through old 
>Nethack and Moria source code in an attempt to find some code for 
>Dungeon generation, which I would like as a plugin for QUB: the Q 
>Universal Boardgame (http://qub.sourceforge.net). That code is so 
>ancient and ill-organized that it's too much work to deal with, though. 
>Two minutes with DM and I've found it!

Well, thanks. You've just made my day. I worked on this over the whole
winter, and had been afraid no one would use the DungeonMaker. Why don't you
subscribe to the list, so we can have our conversation there?

>I love that you've made the 
>output simple text. I'll be making a Perl script which takes that input 
>and makes a graphical representation of it (via HTML and <img> hrefs).

Way cool! I've never had the idea to take it in this direction. Could you
use such a representation in QUB?
 
>I'll post it to the list as soon as I'm done. I have a huge collection 
>of graphics from Nethack which can easily be used for the 
>wall/floor/column graphics.

Once I see that, maybe I'll write a Decorate()-function for that graphics
set. That would really be the cherry on the cake.

>If you would be interested in thinking 
>about doing some XML output, I would be happy to help with that. 
>...(snip code)
>That's off the top of my head, anyway. Of course it's nowhere near as 
>lightweight as text, but perhaps it would have some usefulness in 
>feeding 3rd-party apps (I can imagine a DungeonMaker server on the 
>internet, which sends XML output on request. Might have uses for any 
>number of dungeon-crawling games).

It might, but I'm not into XML, and wouldn't want to do that myself.
However, if you want to, great! I would certainly include it in future
versions as an option.

Since you actually start working with the DungeonMaker right away, be warned
that we're in beta and that things may still change. In particular, I've
written a new version which can hand-place columns, and which breaks
compatibility with rooms-files. Also, a tip: When you make a graphical
representaion of the dungeons, and decide to use different graphics for
generational walls, I suggest using 3 different wall graphics, one for
generations 0 and 1, the next for 2, 3, and 4, and another for later
generations. Finally, ...

... any suggestions or feature requests? I'm wide open for that now, but
will be much less so when I have started into a new project.

Peter

Re: [DM-dev] brilliant :)

[Stephan B. <ste...@ei...>]

Okay, I've got a script which turns Dungeon files into HTML with=20
graphics. It's attached, just for the curious, but it needs some major=20
work before it's really usable. It has some limitations which need to=20
be cleaned up before I send it to the list, however:

1) It doesn't correctly deal with NS & EW walls - they all get the same
graphic (which looks bad with the graphic I'm currently using). With a=20
proper square graphic it won't matter much, actually.

2) Needs to be able to take a graphics theme when run (this is=20
currently hard-coded). The graphics are called the same as the=20
character they represent, so X =3D graphics/<theme>/X.png, C =3D=20
graphics/<theme>/C.png, etc. (yes . =3D ..png).

3) Currently only handles X, C, ., and 0-9 characters (are there=20
others?). This support will be rewritten, though. I don't like the way=20
I've done it.

4) The graphics are lame. I grabbed the first things I found.

It should be very little problem to make a quick Qt app which can take=20
this HTML (or the original input) and make a real graphic out of it. Qt=20
has functions for taking "screen-shots" of arbitrary widgets, so I just=20
need to paint he pixmaps into the widget and Qt'll do the rest. Qt has=20
a basic HTML browser widget which can browse the output files (tested=20
already), and QUB has code to use that and to screen-shot it, so it'll=20
only take me a little while to do that tonight. Problem =3D null.

Using the attachment: unzip to your DungeonMaker source tree, then:

=2E/dungeonmaker
=2E/dng2html Dungeon.txt > foo.html

(dng2html requires Perl. If your Perl is not at /usr/bin/perl,=20
edit the first line of dng2html to the correct path.)

Browse foo.html from that dir. Netscape takes AGES to render the=20
output, but it works.

Gawd Bless Open Source.

Thanks again, Doctor!

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Belief makes a hollow place. Something has to roll in to fill it."
-- Terry Pratchet



On Wednesday 11 April 2001 14:28, Stephan Beal wrote:
> Dr. Henningsen,
>
> It's brilliant :). A couple of month ago I started pouring through
> old Nethack and Moria source code in an attempt to find some code for
> Dungeon generation, which I would like as a plugin for QUB: the Q
> Universal Boardgame (http://qub.sourceforge.net). That code is so
> ancient and ill-organized that it's too much work to deal with,
> though. Two minutes with DM and I've found it! I love that you've
> made the output simple text. I'll be making a Perl script which takes
> that input and makes a graphical representation of it (via HTML and
> <img> hrefs). I'll post it to the list as soon as I'm done. I have a
> huge collection of graphics from Nethack which can easily be used for
> the
> wall/floor/column graphics. If you would be interested in thinking
> about doing some XML output, I would be happy to help with that.
>
> Something simple like:
> <Dungeon>
>
>   <floorsquare>
> =09  <pos>#,#</pos>
> =09  <img>filename</img>
> =09  <type>some type of type info (fire, North Wall, NW corner,
> etc.)</type>
> =09  <notes>arbitrary user notes (could be implemented
> as hoverhelp in a graphical client)</notes>
>   </floorsquare>
>   <floorsquare>
> ...
>   </floorsquare>
> ...
> </Dungeon>
>
> That's off the top of my head, anyway. Of course it's nowhere near as
> lightweight as text, but perhaps it would have some usefulness in
> feeding 3rd-party apps (I can imagine a DungeonMaker server on the
> internet, which sends XML output on request. Might have uses for any
> number of dungeon-crawling games).
>
> Take care, and thanks for DungeonMaker!
>
> :)
>
> ----- Stephan Beal
> Generic Universal Computer Guy
> ste...@ei... - http://www.einsurance.de
> Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
> "Belief makes a hollow place. Something has to roll in to fill it."
> -- Terry Pratchet
>
> _______________________________________________
> Dungeonmaker-develop mailing list
> Dun...@li...
> http://lists.sourceforge.net/lists/listinfo/dungeonmaker-develop

[DM-dev] brilliant :)

[Stephan B. <ste...@ei...>]

Dr. Henningsen,

It's brilliant :). A couple of month ago I started pouring through old=20
Nethack and Moria source code in an attempt to find some code for=20
Dungeon generation, which I would like as a plugin for QUB: the Q=20
Universal Boardgame (http://qub.sourceforge.net). That code is so=20
ancient and ill-organized that it's too much work to deal with, though.=20
Two minutes with DM and I've found it! I love that you've made the=20
output simple text. I'll be making a Perl script which takes that input=20
and makes a graphical representation of it (via HTML and <img> hrefs).=20
I'll post it to the list as soon as I'm done. I have a huge collection=20
of graphics from Nethack which can easily be used for the=20
wall/floor/column graphics. If you would be interested in thinking=20
about doing some XML output, I would be happy to help with that.=20

Something simple like:
<Dungeon>
 =20
  <floorsquare>
=09  <pos>#,#</pos>
=09  <img>filename</img>
=09  <type>some type of type info (fire, North Wall, NW corner,=20
etc.)</type>
=09  <notes>arbitrary user notes (could be implemented
as hoverhelp in a graphical client)</notes>
  </floorsquare>
  <floorsquare>
=2E..
  </floorsquare>
=2E..
</Dungeon>

That's off the top of my head, anyway. Of course it's nowhere near as=20
lightweight as text, but perhaps it would have some usefulness in=20
feeding 3rd-party apps (I can imagine a DungeonMaker server on the=20
internet, which sends XML output on request. Might have uses for any=20
number of dungeon-crawling games).

Take care, and thanks for DungeonMaker!

:)

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Belief makes a hollow place. Something has to roll in to fill it."
-- Terry Pratchet

[DM-dev] Enclosed areas?

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

Jean-Luc: 
        I'm afraid I don't understand what you mean by the "source" at the
top right. The (0 , 0) origin of my coordinate system is at top left, and I
see no reason to change it, because it has no impact on the dungeons that
are generated. If you have a map with the origin in the middle, it would be
no problem to transform a DungeonMaker map to your map, and the proper place
to do it would be when assigning the map data from the DungeonMaker map to
the (newly constructed) map you will use in your own program.

Peter

[DM-dev] Enclosed Areas

[Gandalf I. <gan...@ho...>]

First of all, let me say that I just downloaded and built it and it worked!
That is nice.

Secondly, I haven't looked at the source yet and only have perused the docs
quickly, so this may be an easy question, but I thought I'd ask.

Is it possible to make DungeonMaker alter the source from the top right to
somewhere in the middle?

Jay

[DM-dev] Enclosed areas?

[Jean L. P. <jea...@us...>]

First of all, let me say that I just downloaded and built it and it =
worked!  That is nice.

Secondly, I haven't looked at the source yet and only have perused the =
docs quickly, so this may be an easy question, but I thought I'd ask.

Is it possible to make DungeonMaker alter the source from the top right =
to somewhere in the middle?

Jay

Re: [DM-dev] Decorate function, what about it?

[Selena W. <se...@al...>]

This was much clearer, now I *understand* why you didn't write Decorate()  -
but you should explain that on the webpage, probably also in the manual.

>BTW, I would look forward to someone doing a graphically fancy rendering of
>the DungeonMaker's creations. Would you maybe be interested in financing
>such a venture?

Do you think this is a good time to start financing dot.com ventures?
Considering the enthusiastic crowd has left the market... Maybe it is, but
I'd have to see a more solid proposal. You're always free to pitch it to me,
of course :-) But don't get your hopes up, there are many ventures here in
Nepal that are in more urgent need of funds than you.

Or so thinketh -:
                   Selena
________________________________________________
The void liberates you from all conceptual views
    ...but if you conceptualize the void...

Re: [DM-dev] Decorate function, what about it?

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

Celestial dancer Selena wrote:
>You write that you had intended to go through the dungeon once more
>and decorate it in a separate step, reacting to the local conditions created
>by the action of the WallCrawlers. I think that would be a very good plan,
>and I find it a bit lame that you announce your intention not to do that
>part. I mean, do you write the program or not? And if you do, why stop halfway?

You are right, I did not put that well on the webpage. There's one
overriding reason that makes it a bad idea to write the Decorate()-function
- and that's that we don't know what to decorate with. This function should
be written when we know how many graphical resources we will have - how many
different wall tiles, and corner decorations, and double-high walls, and
center pyramid decorations, and, and, and ... and when we know all that, we
can write a decorate function that beautifully distributes these
decorations. But not before. I had considered writing a function
Decorate(int numGraphics), that would implement decorations depending on the
number of different tiles the graphic artist would make. But any such
function I might write generically would be at best second rate to a
function that is written with specific knowledge of the graphical style that
will be employed, and the various resources.

>        And if you stick with the decision not to write the Decorate()
>function yourself, could you at least give your ideas on it, so that it
>would be easier for other people to implement this?

But of course. I'd go through the entire dungeon square by square, and
inspect a neighborhood (maybe 11x11) of those squares that contain a wall
tile. If the neighborhood has enough space to pad this with another wall
tile, we'd consider that. For instance, where several walls meet ( 3 or 4
converging on one square) that square would get neighbors so as to form a
little pyramid. Also, we'd identify openings (like doors) and decorate them
with nice dramatic portals.

Another thing would be wall following. The user could select a number of the
design Crawlers, and follow their wall, and make it wider (and thus higher)
if room allows. In this manner, one could follow the longest wall that
starts at the Crawler start position - often this would be first the
generation 0 wall, then it would switch over to generation 1. Distinguishing
these graphically would be of value for orientation in the dungeons. Other
walls that have lots of room around them could also be padded or decorated
in other ways.

Finally, in the last pass, we would identify whether there are any large
open spaces left, and would then fill these with decorations - probably
something like columns, only maybe 2x2 squares big? Or prefab spirals?
Should be very dramatic, anyway.

If Decorate() can do something like this, we can allow the Crawlers to make
dungeons that are sparse in some regions, which looks really cool if you
ever tried it. Much more than anything else we have so far this would allow
the creation of dungeons with different "tastes".

BTW, I would look forward to someone doing a graphically fancy rendering of
the DungeonMaker's creations. Would you maybe be interested in financing
such a venture?

Peter
alifegames.com