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