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

[DM-dev] Compile question

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

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.

Eric

_______________________________________________________

[DM-dev] "DungeonMaker - the Movie" is out! (v.1.2)

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

Here it is, "DungeonMaker, the Movie". Check it out. Watch the dungeon
creation process... this is interesting. Play around some, using roomsA with
statsB where A != B and see what you get.

While you need SDL-devel (I used 1.08) to build the executable, I have
included a Linux executable in the archive, and I'm pretty sure (99% until
someone actually tries it and gives me feedback) that SDL is statically
bound, and you can run the new Dungeonmaker without having SDL installed on
your machine. 

If any of you design some dungeons, send me the files. I'd be pleased to try
them out and see what other people come up with.

Enjoy,
Peter Henningsen
alifegames.com

[DM-dev] DungeonMaker v 1.1 released

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

Hello everyone,

        I am pleased to announce that I'm back to coding and have released a
new version of the DungeonMaker. The only difference to version 1.0 is that
dungeons are not rendered to text files any more, but graphically to an
SDL-surface. That means you need SDL installed to run the new DungeonMaker,
but you'll get a much better view of how the dungeons look. I'm using SDL
1.08, but try whichever version you have, I only make a few very basic
SDL-calls.

        Version 1.2 is almost ready to go too, and shows the dungeon
creation process as a movie. This gives very good insight into the
intricacies of dungeon creation, and is a great help for dungeon design. You
might want to wait for that, it is really very cool to watch the dungeons
grow. 1.1 has mostly been put on the net for the record, to document the
switchover to SDL with the minimum amount of other code. The online manual
includes a tutorial on the changeover from 1.0 to 1.1, focusing on SDL. 

        After version 1.2 I will probably re-write the program from scratch,
incorporating all the ideas I've had over the summer. I'm very enthusiastic,
and hungry for coding after a long summer as a home builder.

Take care,
Peter Henningsen
alifegames.com
        

[DM-dev] hex map generation code

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

http://www.diac.com/~tqr/mapmaker/mm.html

WOW!!!!!!!!
:)

----- stephan

Re: [DM-dev] More on data interface and object model

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

whew, gosh, what a week it's been here. product launches, Oktoberfest AND 
Einheitstag all in one week! It's a nightmare!

On Tuesday 02 October 2001 14:12, you wrote:
> I don't think so. The client apps would all use the data model used by the
> Dungeonmaker, which could be "everything is a Wall object". Of course the
> *developer* of the client app would have to use the design program to
> produce his dungeon files, which would use a much more complex data
> interface, but whose output to the Dungeonmaker would - again - be "just
> Walls".

sounds fair enough.

> Design parameters are for me all the data in the 2 files the Dungeonmaker
> reads to make a dungeon, plus the random seed. I'm mostly concerned about
> the "Rooms-"file, which IMO should have just Walls, not Rooms in it. Plus
> of course Crawler start locations... What are the "design parameters" for
> you?

i was taking "design parms" one step further, to include rooms, etc. There's 
no reason it has to be so, though, so i'll switch over to your definition.

> Hmm.. that last bit with the higher level interface sounds about right to
> me. 

:)

> But I still think we should have more concrete discussions centered
> around the actual interface functions you plan to introduce... on the other
> hand, as i said, as long as I can use your interface to do my stuff, things
> should be OK...

i need to sit down and draw it all out on paper so i understand it myself 
clearly, then i'll get that passed on to the list. My ideas have changed a 
dozen times, and mentally i've currently got a mix of these different 
approaches, which i think i'll only be able to clarify by physically mapping 
it out on paper.

> Glad you crawled out from under 2 weeks of TV. 

it was a pretty horrible 2 weeks, though. i normally almost never watch TV - 
hadn't turned the thing on since February or so, i think. But i was glued to 
it for a while. Now i just refer to cnn.com or foxnews.com a couple times a 
day.

> Sorry to hear your
> year-end-rush at work is already on. Can get only worse for 3 months, I
> guess. 

Through about mid-December it'll be hectic. My actual workload isn't so bad - 
the problem is that i'm the generic sysadmin and support guy, so as everyone 
else rushes to get their products online, i've got to be available to do the 
server-side installation, plus stand by to do updates and such as they work 
out their bugs. i'm very glad i'm not involved with the actual product 
development at the moment, though.

> I'm in carpenter mode, and hope to switch to programming by maybe
> December, if I get my project done until then. Today I'm actually in
> electrician mode... scary stuff...

Sounds like we'll line up at the same time, then :). From Christmas on it's 
generally really slow, as far as hecticness goes.

:)

-- 
----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862 Handy:  +49 (179) 211 97 67
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts

[DM-dev] More on data interface and object model

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

>> >b) add objects (rooms, walls, doors, etc.) to the dungeon. I would want
>> > this done in a way such that I can add Rooms within Rooms. The current
>> > model doesn't allow this. The big advantage to this approach is that it
>> > allows "embedding" of any data in a room: a chair, a bed, etc. and you do
>> > not have to move the extra data if you move the room (because they are
>> > contained in the room).
>>
>> I think this should be done in a design program, not in the Dungeonmaker.
>
>The only problem with that is that then every client app (almost all of which 
>would provide some sort of design info, I think) needs to implement it's own 
>data structures and all, to do something which I anticipate all/most client 
>apps would need.

I don't think so. The client apps would all use the data model used by the
Dungeonmaker, which could be "everything is a Wall object". Of course the
*developer* of the client app would have to use the design program to
produce his dungeon files, which would use a much more complex data
interface, but whose output to the Dungeonmaker would - again - be "just Walls".

>> Obviously our main point of disagreement is in whether to make the
>> Dungeonmaker a design program or not. I want the design program to be a
>> separate layer, so that people who want to make a game using dungeons by
>> Dungeonmaker do not have to compile/link all that functionality into their
>> program. You think differently about this? Care to give some reasons?
>
>I agree on the point of disagreement, and I also think that part of it has 
>been a conflict of definitions: what I am calling design parameters are not 
>what you are calling them, I think. As I understand now, you mean design 
>params to mean the low-level data? I have taken it to mean everything which 
>goes into the "dungeon stew." In that sense, I agree that they (dungeon 
>inputs, including rooms/walls/etc) should be different layers, but also part 
>of the library. Provide the low-level object, as you have done, then provide 
>a higher-level interface to it.

Design parameters are for me all the data in the 2 files the Dungeonmaker
reads to make a dungeon, plus the random seed. I'm mostly concerned about
the "Rooms-"file, which IMO should have just Walls, not Rooms in it. Plus of
course Crawler start locations... What are the "design parameters" for you?

Hmm.. that last bit with the higher level interface sounds about right to
me. But I still think we should have more concrete discussions centered
around the actual interface functions you plan to introduce... on the other
hand, as i said, as long as I can use your interface to do my stuff, things
should be OK...

Glad you crawled out from under 2 weeks of TV. Sorry to hear your
year-end-rush at work is already on. Can get only worse for 3 months, I
guess. I'm in carpenter mode, and hope to switch to programming by maybe
December, if I get my project done until then. Today I'm actually in
electrician mode... scary stuff...

C'ya,
Peter

[DM-dev] sorry i've been out of touch!

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

Greetings again!

just a quick note to say i'm sorry i've been out of touch the past few weeks. 
The two weeks following the 11th i largely spent in front of the TV, and at 
the moment work is hell because in Germany people can (normally) only change 
insurance at the end of the year, so it's our high season (with about 5x the 
normal traffic, and associated maintenance and upgrade work). Also... 
Oktoberfest is going on about a 15-minute walk from here and won't be over 
until next Sunday ;).

i hope to be back in full working order within two weeks or so.

take care, people,

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862 Handy:  +49 (179) 211 97 67
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts

Re: [DM-dev] Data Management and new API

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

sorry I haven't responded to last night's mail. I've been wiped out with the 
flu, and wasn't up to it....

On Tuesday 11 September 2001 15:11, Henningsen wrote:
> I've got this thought: As long as you (Stephan) commit to staying with the
> project and helping people who want to work with your code, it should be OK
> to me if I don't understand your data management code (just as you don't
> understand some of the inner workings of the Crawler engine). 

Sounds completely fair. I can, with absolute confidence, say that I will be 
100% available for any type of support on "my code" for as long as needed, 
regardless of my association with the project, barring any physical 
circumstance which keeps me from it. It just seems like the right thing to do 
- support one's code.

> What's really
> important is the API. 

yeah!

> When I do my next programming session on the
> DungeonMaker, I should just be able to call methods from the API you make
> for data management, without neccessarily having to understand the
> internals.

exactly!

> I have anyway been thinking that when I extend the DungeonMaker to become
...
> However, let's discuss the API first. What do you think it should include?

At a high level, this is what I think I would "need" from the library. The 
exactly layout within the library (breaking up of the objects) is not done 
here:

a) set generic dungeon parameters (random seed, size, etc.) via set-methods.
This should be done in a generic way so that command-line apps could easily 
translate something like:
mydungeonapp -size 80x120
could easily be "translated" into dungeon code. I'm not suggesting that libDM 
do the translation, but if it offers a simple setSize()/resize() method, that 
would be enough.

b) add objects (rooms, walls, doors, etc.) to the dungeon. I would want this 
done in a way such that I can add Rooms within Rooms. The current model 
doesn't allow this. The big advantage to this approach is that it allows 
"embedding" of any data in a room: a chair, a bed, etc. and you do not have 
to move the extra data if you move the room (because they are contained in 
the room).

c) Load/save my options, preferrably. Though saving is not strictly required, 
I think loading would be.

d) Generate output in some lib-specified "standard" (current ASCII output is 
fine with me).

The DungeonElement code does (a) and (b). It's saving of data is currently 
broken, and I don't see much hope for the method it currently uses. That part 
needs to be re-thought-out and rewritten.

The exact API needed to accomplish this seems to be pretty small, including 
perhaps only 3-6 objects:

1) Dungeon object - where inputs go and outputs come out.
2) Grid (could be an int[][]) - "drawing board" - where the rendering is done.
3) DungeonElement (assuming usage of current code). Some generic dungeon 
object type, in any case.
4) Crawlers

Plus a number of helper objects, like Rooms (wrapper around 4 walls, etc).

The majority of this is already done by the DungeonElement objects, but the 
save/load support there sucks, and I need to re-write some bits which I broke 
when porting it to a flatter model. Perhaps those bits are in CVS, so I 
should be able to pull them out of there.

I'm not at all saying that DungeonElement is _the_ way to do it, it's just 
that we already have that code and it does "most of it". I'd be completely 
open to a delete-all-and-rewrite as well, if we'll get an object model down 
which I can follow.

:)

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862
Handy:  +49 (179) 211 97 67
"Now I've always been the kind of person who doesn't like to trespass, 
but sometimes you just find yourself over the line." -- Bob Dylan

[DM-dev] Data Management and new API

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

Let's continue our recent private discussion on the list. We were trying to
rethink from scratch what the DungeonMaker library is supposed to be able to
do... how it does its internal data management, and what API it offers to
users...

I've got this thought: As long as you (Stephan) commit to staying with the
project and helping people who want to work with your code, it should be OK
to me if I don't understand your data management code (just as you don't
understand some of the inner workings of the Crawler engine). What's really
important is the API. When I do my next programming session on the
DungeonMaker, I should just be able to call methods from the API you make
for data management, without neccessarily having to understand the internals.

I have anyway been thinking that when I extend the DungeonMaker to become
able to create lots of closed rooms, and then break them open (with doors or
openings), I'd like to write a new class that calls the DungeonMaker class,
generates a dungeon, and then makes changes to it - as opposed to changing
the DM class itself. In concrete terms I will change some wall tiles into
doors or open spaces. Whatever you do re data management has to allow that.
Other than that, I should be able to use whatever API you wrap the old DM
class into.

However, let's discuss the API first. What do you think it should include?

Peter

[DM-dev] cool idea for an extendible file format

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

Pete, I think I just had one of the most brilliant ideas I've ever had...

I just completely solved all problems regarding file parsing and how to get 
the data to the dungeon in not only a simple way, but an extendable and 
easily maintanably way.


I can't write the code here because I don't know the syntax for function 
pointers (and too tired to look it up), but it'd go like this:

Create a map with string keys and function pointer values. The functions must 
match this signature:

  void funcname( string input_data, DMGrid *grid );

input_data == the string information parsed from the saved data. It is sent 
to the object in it's raw, unparsed format (only the value, not the key). 
This allows the registered function to do whatever it wants to. This makes 
the file format extremely extendable:

1) register and write your function.
2) add function to pointer map.
3) add lines like this in your input files:
  mynewtypeofdungeonobject=custom|parsing|is|possible

The callback function sends the parsed data, and a grid to render the object 
to. Generic rendering support is already in DungeonElement, so can be re-used 
by these callbacks.

got that?

----- st...@wa...
http://qub.sourceforge.net - http://gwm.rootonfire.org
http://byoo.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

Re: [DM-dev] web site overhaul?

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

On Friday 31 August 2001 02:27, you wrote:
> I had by coincidence just visited your new QUB website and was very
> impressed. That looks way cool. I even voted (I think it is properly
> pronounced Kju Ju Bee). Thanks for making the offer.

The pronounciation results have surprised me. I'm the only one who pronounces 
it "kub". That's not the "official" pronounciation - that's just the way I 
saw it. I put up the poll to try to determine what the "official" 
pronounciation should be.

> Right now I think the DungeonMaker does not really warrant that type of
> website, there's just not enough interest to keep it lively. However, when

I also thought that about QUB (it's not much more lively than DM), but the 
site has helped liven it up. People are starting to interact, and we've 
gotten 20x more bug reports and feature requests since I set it up (perhaps 
that's coincidence, I don't know). Perhaps it could do the same for DM. It 
provides the users with an easy way to provide feedback, so they do it more.

> we are further along and have things of interest to gamers (and not just to
> developers as is the case now) I think it would be cool to get a site like
> that. I'm planning to write my demo game such that scores can be verified,
> and it would be possible to post a ranking of the worldwide best
> MazeRunners to the net. That would be so cool.

I've had SO much fun adding stuff to the QUB site. I've been up until 1 or 2 
every morning the past week toying with it. I've written (or ported) several 
PHP apps for that framework already (see the Generic Wargaming Maps link on 
the QUB site, left side of the page), and I've started rewriting lots of the 
internals for the phpNuke software. It's been a real blast. I've already 
started sketching out the plan for adding a dungeonmaker front-end app for 
phpNuke, too. I don't yet know if I can exec() arbitrary apps from the SF 
server's PHP installation (this is an PHP installation-specific configuration 
option, which may be turned off). If I can then I can easily write an app 
which takes the existing dungeonmaker binary (with one small change - do not 
wait for user input) and feed it info based on selections the user makes in a 
form. In fact... that would be useful for QUB, too (because it can import the 
dungeonmaker output), so I'll probably start on that tonight. Finally... 
after 7 years (my GOD, it's been that long already!) of pidding around with 
HTML I'm finally creating my first REAL web sites.


> But until then (or until you have an interactive design frontend that would
> make the program interesting to pen and paper gamers) let's just stick with
> the simple site.

No problem. Just say the word, though, and I'll be more than happy to set up 
a nuke-powered site. You could pick up PHP really quickly. It's a lot like C. 
I had it basically mastered inside of 3 days, honestly. There is no NEED to 
know PHP to set it up and maintain it, however - it's just needed if you want 
to write add-ons for it (which I do). The maintenance of the site (except for 
installation of new modules) is all done via the web interface and all but 
the basic configuration data is stored in a MySQL database.

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862
Handy:  +49 (179) 211 97 67
"Perhaps, as has often been said, the trouble with people is not so 
much with their ignorance as it is with their knowing so many things 
that are not so....." - William A. White

Re: [DM-dev] DM status update

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

On Friday 31 August 2001 02:27, you wrote:
> >Sorry, I meant when reading data from a file. For example, read one line
> >which says "room=x,y,w,h,..." and then draw it to the grid immediately.
>
> You mean the data is entered in the map-array, right? Not actually rendered
> to the screen, eh?

right - rendered to the grid. render-as-we-read saves us from having to store 
the data in a separate structure. It's the simplest approach. And, as the 
Extreme Programming book challenges me to ask, "what is the simplest thing 
which will get the job done."

> >> Saving a dungeon back to "dungeon data" format is not what we want to
> >> do.
> >
> >Yeah, I've given up on that for now.
>
> Heureka! ROFL!

You can thank the Extreme Programming book for that ;). I'm trying a new 
approach (but it's so HARD to not always think, "but what if a user wants to 
do that... I need to add this function...")

> Very smart move. According to my book, you can also use the FSF's "checker"
> program to check for memory leaks, though I hevn't tried it myself.

I downloaded some great mem leak detection code which works be replacing 
new() and delete() with custom copies to make sure you always have a delete() 
for all of your new()s. It won't work with QUB because some of it's macros 
conflict with stuff defined in Qt. Since Qt does it's own memory management 
internally, too, the leak detector code doesn't see the delete() calls, and 
therefor thinks that all Qt objects are leaking. (In Qt, at least with 
widgets, you typically create them with new(), but only delete the top-most 
one, which takes care of deleting all children).

So... until I have a great way of checking for leaks, I do it with cerr. I'm 
sure I'm missing some still, but I'll eventually get them all (I hope).

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862
Handy:  +49 (179) 211 97 67
"Perhaps, as has often been said, the trouble with people is not so 
much with their ignorance as it is with their knowing so many things 
that are not so....." - William A. White

Re: [DM-dev] DM status update

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

At 10:22 AM 8/29/01 +0200, you wrote:
>On Wednesday 29 August 2001 04:13, you wrote:
>> Render-as-we read? As I see it, we read the data in and use it to
>> initialize the DungeonMaker internals (nothing's rendered at this time).
>
>Sorry, I meant when reading data from a file. For example, read one line 
>which says "room=x,y,w,h,..." and then draw it to the grid immediately.

You mean the data is entered in the map-array, right? Not actually rendered
to the screen, eh?

>> Saving a dungeon back to "dungeon data" format is not what we want to do.
>
>Yeah, I've given up on that for now.

Heureka! ROFL!

>> Sorry to hear about the QUB leak. Hope you got the right tools to catch it.
>
>It was one I could catch with cerr, luckily. I'm still paranoid about memory 
>leaks in C++ (because my background is mostly Java, where that doesn't 
>exist), so I tend to print debug output for all objects when they die.

Very smart move. According to my book, you can also use the FSF's "checker"
program to check for memory leaks, though I hevn't tried it myself.

Cheers,
Peter

Re: [DM-dev] web site overhaul?

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

I had by coincidence just visited your new QUB website and was very
impressed. That looks way cool. I even voted (I think it is properly
pronounced Kju Ju Bee). Thanks for making the offer.

Right now I think the DungeonMaker does not really warrant that type of
website, there's just not enough interest to keep it lively. However, when
we are further along and have things of interest to gamers (and not just to
developers as is the case now) I think it would be cool to get a site like
that. I'm planning to write my demo game such that scores can be verified,
and it would be possible to post a ranking of the worldwide best MazeRunners
to the net. That would be so cool.

But until then (or until you have an interactive design frontend that would
make the program interesting to pen and paper gamers) let's just stick with
the simple site.

Thanks again,
Peter

At 02:09 PM 8/29/01 +0200, you wrote:
>Pete, et al.,
>
>Yesterday I downloaded and installed phpNuke (www.phpnuke.org) on QUB's web=
=20
>site, and I was amazed:
>a) it took only 10 minutes to set up.
>b) with about another hour or so of configuration it was fully ready.
>
>It works right out of the box (provided you have a db server and web=
 server)=20
>and looks GREAT. It uses mysql for a db, which SF provides for free. It's=
=20
>really easy to manage content with it (without editing HTML files!) and to=
=20
>write additional PHP modules for it. I've done a number of small modules=
 for=20
>the QUB site already. It offers user logins, message boards, search engine,=
=20
>user polls/surveys, automatically tracks your traffic, the most-used areas=
 of=20
>your site, etc. For a sample, take a look at http://qub.sourceforge.net=
 (it's=20
>not complete, but "getting there"). That's exactly the same software as is=
=20
>running www.phpnuke.org, except that I run a different theme and have made=
=20
>some very small customizations to some of the PHP code.
>
>If you want something like that for the DM site I'll be more than happy=20
>to set it up and maintain it.
>
>----- stephan
>Generic Universal Computer Guy
>st...@ei... - http://www.einsurance.de
>Office: +49 (89) =A0552 92 862
>Handy: =A0+49 (179) 211 97 67
>"Perhaps, as has often been said, the trouble with people is not so=20
>much with their ignorance as it is with their knowing so many things=20
>that are not so....." - William A. White
>
>_______________________________________________
>Dungeonmaker-develop mailing list
>Dun...@li...
>http://lists.sourceforge.net/lists/listinfo/dungeonmaker-develop
>
>

[DM-dev] How To Write Unmaintainable Code

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

http://mindprod.com/unmain.html

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862
Handy:  +49 (179) 211 97 67
"Perhaps, as has often been said, the trouble with people is not so 
much with their ignorance as it is with their knowing so many things 
that are not so....." - William A. White

[DM-dev] web site overhaul?

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

Pete, et al.,

Yesterday I downloaded and installed phpNuke (www.phpnuke.org) on QUB's web 
site, and I was amazed:
a) it took only 10 minutes to set up.
b) with about another hour or so of configuration it was fully ready.

It works right out of the box (provided you have a db server and web server) 
and looks GREAT. It uses mysql for a db, which SF provides for free. It's 
really easy to manage content with it (without editing HTML files!) and to 
write additional PHP modules for it. I've done a number of small modules for 
the QUB site already. It offers user logins, message boards, search engine, 
user polls/surveys, automatically tracks your traffic, the most-used areas of 
your site, etc. For a sample, take a look at http://qub.sourceforge.net (it's 
not complete, but "getting there"). That's exactly the same software as is 
running www.phpnuke.org, except that I run a different theme and have made 
some very small customizations to some of the PHP code.

If you want something like that for the DM site I'll be more than happy 
to set it up and maintain it.

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862
Handy:  +49 (179) 211 97 67
"Perhaps, as has often been said, the trouble with people is not so 
much with their ignorance as it is with their knowing so many things 
that are not so....." - William A. White

Re: [DM-dev] DM status update

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

On Wednesday 29 August 2001 04:13, you wrote:
> Render-as-we read? As I see it, we read the data in and use it to
> initialize the DungeonMaker internals (nothing's rendered at this time).

Sorry, I meant when reading data from a file. For example, read one line 
which says "room=x,y,w,h,..." and then draw it to the grid immediately. I had 
a reason for this, but now I'm not sure what it was. Perhaps it won't be 
needed at all. I've still got a few ideas to try out which may make this moot.

> Saving a dungeon back to "dungeon data" format is not what we want to do.

Yeah, I've given up on that for now.

> All we need is the initialization data and the random seed, and we can
> generate the dungeon in under one second flat. Calling programs will have
> their own formats, and it will be very easy for them to write code to save
> the dungeon to that format, if desired.

Sounds fair enough. I think I was gonna have to make a new file format for 
QUB, anyway, so this is no problem.

> Sorry to hear about the QUB leak. Hope you got the right tools to catch it.

It was one I could catch with cerr, luckily. I'm still paranoid about memory 
leaks in C++ (because my background is mostly Java, where that doesn't 
exist), so I tend to print debug output for all objects when they die. I just 
happened to notice that some objects didn't die when I thought they should. 
It's all fixed and online, so I'm happy. I wasn't aware of some deletion 
behaviour regarding main windows in Qt, and wasn't deleting them until the 
app closed.

Here's a handy macro for dealing with debug output:

#define CERR cerr << "debug: " << __FILE__ << ": " << dec << __LINE__ << ": " 
  
You use it just like cerr:
	CERR << "debug output!" << endl;
and you don't have to search for the debug output later, because you get the 
file/line in the output. 
That's in DM.h, by the way.

see ya!

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862
Handy:  +49 (179) 211 97 67
"Perhaps, as has often been said, the trouble with people is not so 
much with their ignorance as it is with their knowing so many things 
that are not so....." - William A. White

Re: [DM-dev] DM status update

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

>The plan is, though, as you say, a _purely_ flat model. The hierarchy's gonna 
>go completely on the back burner for now. This probably means going back to 
>the render-as-we-read approach for the dungeon grid, and it probably means 
>problems with saving a rendered dungeon back to "dungeon data" format. We'll 
>get through it, though.

Render-as-we read? As I see it, we read the data in and use it to initialize
the DungeonMaker internals (nothing's rendered at this time). The we run the
Dungeonmaker process (Crawlers crawl...), and then we have a data structure
that can be used any which way, either to render a dungeon or to initialize
another data structure used by the calling program. The second alternative
will be the norm in production use of the code, the rendering we currently
do is just for demonstration and testing.

Saving a dungeon back to "dungeon data" format is not what we want to do.
All we need is the initialization data and the random seed, and we can
generate the dungeon in under one second flat. Calling programs will have
their own formats, and it will be very easy for them to write code to save
the dungeon to that format, if desired.

Sorry to hear about the QUB leak. Hope you got the right tools to catch it.

Peter

[DM-dev] extreme programming

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

okay, okay! I've broken down! I'm gonna do it!
I was reading last night in the book "Extreme Programming Explained" and came 
across this paragraph, which I almost thought that Pete had written:

Simplicity is not easy. It is the hardest thing in the world not to look 
toward the things you'll need to implement tomorrow and next week and next 
month. But compulsively thinking ahead is listening to the fear of the 
exponential cost of change curve. Sometimes the coach has to gently remind 
the team that they are listening to their fears, "Maybe you're so much 
smarter than I am that you can make all this complicated dynamically 
balancing tree stuff work. I would naively assume a linear search would work."
-- Kent Beck


----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862
Handy:  +49 (179) 211 97 67
"Perhaps, as has often been said, the trouble with people is not so 
much with their ignorance as it is with their knowing so many things 
that are not so....." - William A. White

[DM-dev] DM status update

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

Good morning, Peter!

I didn't make any progress on DM this weekend. Friday a huge memory leak in 
QUB was brought to my attention and I spent Sunday trying to resolve that. 
The plan is, though, as you say, a _purely_ flat model. The hierarchy's gonna 
go completely on the back burner for now. This probably means going back to 
the render-as-we-read approach for the dungeon grid, and it probably means 
problems with saving a rendered dungeon back to "dungeon data" format. We'll 
get through it, though.

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862
Handy:  +49 (179) 211 97 67
"Perhaps, as has often been said, the trouble with people is not so 
much with their ignorance as it is with their knowing so many things 
that are not so....." - William A. White

[DM-dev] My ideal data model

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

What I consider the best data model for the Dungeonmaker is the simplest
possible, just one type of data, namely Walls! Walls with a lot of
parameters, like : startLocation, length, width, doorOffset, doorSize,
wallType (for graphics), decorationType, ???more???

A single column would be a wall, a room would be 4 or more walls, etc. Very
simple to work with.

Concepts like rooms (and more complicated things if someone wants them)
would only exist in the design program, not in the DungeonMaker. Maybe that
way cooperation with QUB could also be very efficient. Don't know.

But you probably don't like that, right? Sniff...

Peter

Re: [DM-dev] Hierarchical/Flat model

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

>> This looks to me like you have code that is a hybrid of two distinct
>> approaches that cannot really coexist peacefully. As far as I'm concerned,
>> I have no use for the hierarchical part, and would therefore prefer a pure
>> flat approach for simplicity reasons.
>
>I knew you'd say that! ;)

I knew you'd know that;-)

>I agree completely that the flat and H models aren't mixing well. I really 
>think I will nuke the H structure and go with something very, very flat. I 
>won't kill me, it'll just wound my sense of architecture ;). Nothing fatal, 
>certainly. ;)

Hey, I'm mostly against the weird mix. If you throw out the flat stuff, I
could live with that too. But my sense of architecture gets offended by ...
oh well, you know, the mixing;-)

>Just for interactive design, mainly, and because QUB already has the code 
>(XML stuff) for serializing and loading hierarchies of data, so I could store 
>dungeons in XML format extremely easily this way. If I do a flat model I've 
>got to use an intermediary format and encode/decode it along the way.

Hmm, I don't think you should put complications into the core Dungeonmaker
stuff to ease cooperation with QUB. That properly would go in an
intermediate layer. (Did you know I'd say that? Darn!)

Anyway, I'm missing something again: A flat model is also a special case of
a hierarchical model, just with no branches, children or whatever you call
'em. So I would think your QUB serializing code should be able to work on a
flat data model (== one-layer hierarchy). Not so??

In interactive design, if you have a hierarchical model, you get problems
with selecting what to move. Click somewhere to select... what? the room and
all that's attached? Or does the user just want to move the wall inside the
room? If you can get several layers (like fountains attached to walls
attached to rooms...) selecting the right object can be devilish (I know
from sad experience with the very professional Fireworks program). Much
easier in my experience to have a flat model and move several objects
independently, particularly if you can easily enter "Move right by 2, down
by 5" or something. Just remember the numbers, and the whole nested
structure is shifted in a jiffy. 

And who wants to move rooms around anyway? Only very fussy designers, no doubt.

Peter

Re: [DM-dev] Hierarchical/Flat model

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

On Wednesday 22 August 2001 03:05, you wrote:
> >I spent last night re-vamping the file output code. The DungeonElements
> >support a full hierarchical approach, but I've made a subclass, DMDungeon,
> >which enforces a flat approach, while hiding the data hierarchically.
>
> This looks to me like you have code that is a hybrid of two distinct
> approaches that cannot really coexist peacefully. As far as I'm concerned,
> I have no use for the hierarchical part, and would therefore prefer a pure
> flat approach for simplicity reasons.

I knew you'd say that! ;)
Yes, it's absolutely true, but I'm trying to make an approach which means I 
don't have to implement yet another layer in QUB, which would use a 
hierarchical model. For example, when a user is drawing a dungeon, they 
shouldn't be restricted to one flat surface and a number of primitive 
objects. I want them to be able to place a wall inside a room in such a way 
that if they move the room,the wall goes with it. That's way too much work 
with a flat model, and the programmer would have to make assumptions about 
what's on the flat board (for example, there's no longer a room, there's just 
a series of marks which represent walls). In the hierarchical model it's as 
simple as room->move(....).

> An advantage for the hierarchical model that I can see is in interactive
> design, where you could easier move around a complicated nested structure
> consisting of e.g. a room with several attached walls and Crawlers. But if
> you can move flat structures around, moving things around in several steps
> (once for the room, for each wall, etc) wouldn't be that much of a burden,
> really. Not worth the complication in the code, anyway, IMO.

Yup (if I had read that before I wrote the above paragraph I would have seen 
that you're already on the same wavelength ;)
To me it seems more work to move the flat-structured data around.

I agree completely that the flat and H models aren't mixing well. I really 
think I will nuke the H structure and go with something very, very flat. I 
won't kill me, it'll just wound my sense of architecture ;). Nothing fatal, 
certainly. ;)

> So have I missed something? What is the use of the hierarchical model for
> you?

Just for interactive design, mainly, and because QUB already has the code 
(XML stuff) for serializing and loading hierarchies of data, so I could store 
dungeons in XML format extremely easily this way. If I do a flat model I've 
got to use an intermediary format and encode/decode it along the way.

No biggie, though. I'm determined to get the file i/o finished and out of the 
way as soon as possible, so I'm shooting for this weekend. If that means I 
have to nuke the hierarchy, then that's what I'll do, I guess. I can always 
rewrite later with no harm done.

See ya!

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862
Handy:  +49 (179) 211 97 67
"People say it is hard  to switch from Windows to UNIX; 
sure: but it is impossible to switch from UNIX to Windows!"

[DM-dev] Hierarchical/Flat model

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

>I spent last night re-vamping the file output code. The DungeonElements 
>support a full hierarchical approach, but I've made a subclass, DMDungeon, 
>which enforces a flat approach, while hiding the data hierarchically.

This looks to me like you have code that is a hybrid of two distinct
approaches that cannot really coexist peacefully. As far as I'm concerned, I
have no use for the hierarchical part, and would therefore prefer a pure
flat approach for simplicity reasons. 

An advantage for the hierarchical model that I can see is in interactive
design, where you could easier move around a complicated nested structure
consisting of e.g. a room with several attached walls and Crawlers. But if
you can move flat structures around, moving things around in several steps
(once for the room, for each wall, etc) wouldn't be that much of a burden,
really. Not worth the complication in the code, anyway, IMO.

So have I missed something? What is the use of the hierarchical model for you?

Peter

Re: [DM-dev] "stepping through" crawler movement

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

On Tuesday 21 August 2001 01:55, you wrote:
> >Of COURSE! <smack forehead!> I've never needed to save the dungeon in a
> >post-crawled state! I've been subconsciously assuming that I did! I only
...

> Indeed! I think you never tried the option in the 1.0 version where you can
...

> >I just found my project for tonight...
>
> And that is???

I spent last night re-vamping the file output code. The DungeonElements 
support a full hierarchical approach, but I've made a subclass, DMDungeon, 
which enforces a flat approach, while hiding the data hierarchically. It 
offers a small number of functions for adding elements of specific types 
(Walls, Rooms and Doors, so far). This approach isn't ideal, because a 
programmer would get undesired (invisible) results if he takes advantage of 
the hierachy. The plan is to just warn against that in the docs, and then 
find a workaround for it at a later point, so the user can take full 
advantage of it. It does make dungeon generation (for the user, at least room 
layout and such) much simpler.

So now (in CVS) we've got a DMDungeon with these functions:

virtual DungeonElement *add( DungeonElement *de, int x=-1, int y=-1 );
   virtual DungeonElement * addRoom( int x, int y, int w, int h );
   virtual DungeonElement * addDoor( int x, int y, int w, int h  );
   virtual DungeonElement * addWall( int x, int y, int w, int h  );
   virtual DungeonElement * add( int x, int y, int w, int h , int square_type 
);

For now you should ignore the return values. They are valid, but adding 
elements to them will not show them in the final output. The reason for this 
is that DMDungeon is going to impose a flat model, and will only print out 
it's top-most children (and not let them print their children) in the output. 
This is the only way I've found so far for using a flat text model without 
writing a more complex file parser.

Soooo... code like this:
DMDungeon dungeon;
dungeon.addRoom( 2, 4, 6, 7 );

cerr << dungeon.toString() << endl;

will print:

room=2,4,6,7

If we add walls:
dungeon.addWall( 13, 12, 14, 1 );

it'll print out:
room=2,4,6,7
wall=13.12.14.1

Here's the "problem" with DMDungeon, however:
DungeonElement *de = 0;
de = dungeon.addRoom( 4, 5, 8, 10 );
de->add( new Wall( 2,4, 5, 1 ) );

will output:
room=5,4,8,10
(no wall output!)

the reason for this is long-winded and related to the child objects having 
x/y coordinates relative to their parents. Also, if I output walls here, each 
room would print the following:

room=1,5,10,10
wall=0,0,10,1 // top wall
wall=0,0,1,10 // left wall
wall=0,9,10,1 // bottom
wall=9,0,10,1 // right wall

see the coordinates? The walls are relative to the parent room. The 
"standard" DungeonElement code would print this, but DMDungeon doesn't allow 
climbing down the tree of children.

Such is a hierarchical model. So DMDungeon is going to:
a) only have functions for adding top-level elements.
b) when printing out (i.e., saving), it will not recurse past it's first 
level of children.

that'll get around this problem until I can find a better solution.

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862
Handy:  +49 (179) 211 97 67
"'If' is a pretty big word, considering how short it is." --- Toby Pickartz