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

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

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

>You mentioned using diffs earlier. Crawler movement is calcuable given their 
>positions, random seed and the current state of the grid, isn't it?

Yes, you can produce the same dungeon twice by entering the random seed
manually. There is currently no way to get an "intermediate" random seed,
say after 5 Crawler steps, but that could be done if need be. Then you could
restart the Crawler process somewhere in the middle. I just don't see the
benefit of that.

The thing I want the growth process of the dungeon to be available for is to
show a little slow movie of dungeon generation in one thread while another
thread initializes the graphics engine and everything that is needed to
actually play the game (that uses the dungeon). This would give the illusion
that the computer generates the dungeon (and keep the player interested)
while actually initialization work is being done (which normally is dead
time). For this I want to just produce one data structure that contains the
entire dungeon growth process in the smallest memory footprint. So I'd start
with the initial configuration and a set of diffs off that until finished.

I think if you can get that data structure, there's no need for stopping and
restarting the dungeon generation process, because every intermediate step
could easier be gotten from this structure. Or what would you want the
capability to run the Crawlers through k steps for?

>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 need 
>to save the crawler starting positions! It's been bugging the hell out of me 
>to not be able to re-load generated data, and it was because I was trying to 
>figure out how to get around the crawler trails. They're not stored, anyway!

Indeed! I think you never tried the option in the 1.0 version where you can
enter a random seed manually. The program always prints which rooms and
stats files and which random seed it used. Write those down, and make it run
again with those same data, and you get the exact same dungeon. Been there,
done that;-)

>I just found my project for tonight...

And that is???

Peter

Re: [DM-dev] dungeonmaker as a web application :)

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

>> Using Qt is OK. But I seem to remember that that big graphic took forever
> to load on my browser. You'll have to keep an eye on load time;-(
>
>and even longer on mine ;)
>the problem was that it was made of hundreds (dungeon width x dungeon height) 
>smaller images, so the browser had to render all of them. With the Qt code 
>I've got I can compile one single (however, quite large) image out of it. It 
>would be no big deal to offer the image in various sizes, too (Qt's image 
>classes have functions for resizing images).

Actually, if you want a dungeon to load really fast, I think you should try
a table. You'd have very few, very small graphics (say for just 2 for wall
and open for starters), and the html-text for tables should load much faster
than a lot of Graphics. Though I never used a 100 x 100 table in practise;-)
For it to load fast you'd have to explicitly state all sizes in pixels.

Peter

[DM-dev] "stepping through" crawler movement

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

Pete,

You mentioned using diffs earlier. Crawler movement is calcuable given their 
positions, random seed and the current state of the grid, isn't it?

Is there a need to save anything but the "raw", unrendered dungeon, the 
random seed (and other config data), the crawler starting positions? If you 
then tell the application you want to see the dungeon at step 5 of the 
crawlers' work, you render the raw dungeon, place the crawlers, and run them 
through 5 iterations. Of course, that would be one function call:

Dungeon::render( int howManySteps = -1 ); // -1 == all the way, baby

The internal rendering process is fast enough that it's not a problem to 
re-crawl a dungeon each time this call is made we needed to. The dungeon 
would be crawled in the exact same way every time, assuming the dungeon 
configuration (random seed, width, etc.) doesn't change.

A dungeon can be calculated from a formula. We simply store the formula, and 
generate the dungeon on-demand. This means that the internal format of the 
dungeon, for programming purposes, can be the semi-heirarchical 
DungeonElement classes as they are now, with only a bit of additional load 
support. That solves the whole problem of re-loading saved data, because we 
don't have the "cluttering up" done by the crawler in our data. The ability 
to save, load, and dynamically edit a dungeon's structure has been a big 
point for me, but the flat model appeared to break that. But since the flat 
data can be easily generated at any time from a hierarchical data set...

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 need 
to save the crawler starting positions! It's been bugging the hell out of me 
to not be able to re-load generated data, and it was because I was trying to 
figure out how to get around the crawler trails. They're not stored, anyway!

This also means that the dungeon can again be edited on-the-fly, and I don't 
have to render-as-we-load (as I once proposed)! Because "there is no 
dungeon." We only store the recipe for it, and the recipe can be changed, 
then rendered very quickly. Wanna move a room? Go ahead. Re-render if you 
want to see the changes (that's a client app responsibility, not an automatic 
response to a change in the dungeon. Perhaps add an autoRender flag to toggle 
that on or off...). That was the original intention of the heirarchical 
DungeonElement approach, but that didn't fit in well with the thinking of 
dealing with the crawler trails (which implies a gridded data structure). I 
now have no clue why I thought that those were a problem.

Cool. 
I should think more often. 

Excellent. That solves that lingering problem.

Or am I just over-hyping myself?

I just found my project for tonight...

----- 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] dungeonmaker as a web application :)

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

hit send too quickly...

On Monday 20 August 2001 16:54, Stephan Beal wrote:
> > You could be having fun. Web-app-wise, do whatever you like, I have no
> > stake in that. And no knowledge of PHP.
>
> PHP's a breeze.

it's a lot like Perl and C, with some features of Java. If you know C, then 
PHP is very simple to pick up. If you know Perl it's even easier. I had it 
down in about 3 days, really.

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

Re: [DM-dev] dungeonmaker as a web application :)

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

On Monday 20 August 2001 15:56, you wrote:
> I'm planning to make modifications that allow the output of a "movie" that
> shows the dungeon growth. Actually that will not be such a big thing, the
> data is of course all in there already, I'll just have to extract it and
> output it properly. Probably use diff's to keep the data size in check.

I'm thinking that a way to move this into the API in a backwards-compatible 
way is to add a method to the crawlers: crawl( int steps ). The current 
functions which control the crawling would simply call this with 'steps' 
increments of 1, until the job is complete. API users could use the crawl() 
function to step through the crawling and output during each step of the way 
if they want to.


> You could be having fun. Web-app-wise, do whatever you like, I have no
> stake in that. And no knowledge of PHP.

PHP's a breeze.

>
> Peter
>
>
> _______________________________________________
> Dungeonmaker-develop mailing list
> Dun...@li...
> http://lists.sourceforge.net/lists/listinfo/dungeonmaker-develop

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

Re: [DM-dev] dungeonmaker as a web application :)

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

On Monday 20 August 2001 15:56, you wrote:

> Using Qt is OK. But I seem to remember that that big graphic took forever
 to load on my browser. You'll have to keep an eye on load time;-(

and even longer on mine ;)
the problem was that it was made of hundreds (dungeon width x dungeon height) 
smaller images, so the browser had to render all of them. With the Qt code 
I've got I can compile one single (however, quite large) image out of it. It 
would be no big deal to offer the image in various sizes, too (Qt's image 
classes have functions for resizing images).

> That would be an STL "Map" type. Actually, that appears very attractive to
> me. Hope I'll be able to use that when I do my next round of programming.

exactly. In stl it's called a map, in Perl an "associative array" and in PHP 
it's just a plain ol' array (which happens to also work like a hashtable). 

> I'm planning to make modifications that allow the output of a "movie" that
> shows the dungeon growth. Actually that will not be such a big thing, the
> data is of course all in there already, I'll just have to extract it and
> output it properly. Probably use diff's to keep the data size in check.

I've got some ideas on this, but a server just went down and I've gotta 
run... more later.


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

Re: [DM-dev] dungeonmaker as a web application :)

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

>Could be both. If they can see the dungeons they can print them out. I don't 
>know what I did with it, but I could re-create that perl script which makes 
>graphical versions of the dungeons. Or, even better, I could do it in Qt and 
>re-use my code which turns the dm text files into one big graphic. That would 
>limit it to running on servers which have Qt installed, but the web server I 
>admin does ;).

Using Qt is OK. But I seem to remember that that big graphic took forever to
load on my browser. You'll have to keep an eye on load time;-(
...
>Basically, provide them with a way to input the dungeon parameters over the 
>web, instead of providing an input file. This was the idea behind using a 
>hashtable-like object to store a dungeon's config data - then entering the 
>data is the same no matter what the source (a key=value scheme, which is 
>easily parsable, no matter what language the front-end is written in). The 
>front-end would be written in PHP, so couldn't start up c-based DM objects 
>directly. It'd have to write the parameters to a temp file, run the dungeon, 
>and then offer the user the option of editing it.

That would be an STL "Map" type. Actually, that appears very attractive to
me. Hope I'll be able to use that when I do my next round of programming.

>it would certainly be interesting to see what the crawlers do if started in 
>different positions. (It would be even cooler to see them step through it, of 
>course, but that's not something I'm shooting for soon.)

I'm planning to make modifications that allow the output of a "movie" that
shows the dungeon growth. Actually that will not be such a big thing, the
data is of course all in there already, I'll just have to extract it and
output it properly. Probably use diff's to keep the data size in check.

>I think it is "mostly possible". I mean we can't re-use 100% of the code 
>across all user interfaces. But we can re-use the data i/o mechanics. If we 
>use a key=value scheme for storing the dungeon/crawler/etc data, that format 
>is very easy to parse, write, and store internally in Qt and PHP (and std C++ 
>and Perl for that matter). Thus any app which could write a key=val file 
>could do so, then launch dm with the name of that file.

Sounds good.

>I'm thinking now that a web-based app would even be better than a local one, 
>for this purpose, provided that it's easy enough to save/restore your 
>configuration options. I can imagine a site which provides tweakable dungeon 
>templates, and the ability to save/load your own templates. I've been getting 
>back more and more into PHP lately for this work project, so that would be 
>something I'd enjoy doing. As a side-project of the work project, I've been 
>developing a very simplistic web application framework in PHP. "WebDM" would 
>make a nice playground for that development, as well. Working on that would 
>also help me finally decide on a final format for the save/load data, since I 
>could see it from another perspective and possibly find "portability 
>problems" with it sooner.

You could be having fun. Web-app-wise, do whatever you like, I have no stake
in that. And no knowledge of PHP. 

Peter

Re: [DM-dev] dungeonmaker as a web application :)

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

On Sunday 19 August 2001 14:12, you wrote:
> >I've was toying around with some ideas and I think I've decided to make
> >a web-runnable version of dungeonmaker.
>
> Would this be for pen-and-paper players to print out? Or just to show the
> DungeonMaker to people without the need to download code?

Could be both. If they can see the dungeons they can print them out. I don't 
know what I did with it, but I could re-create that perl script which makes 
graphical versions of the dungeons. Or, even better, I could do it in Qt and 
re-use my code which turns the dm text files into one big graphic. That would 
limit it to running on servers which have Qt installed, but the web server I 
admin does ;).

> >Actually... DM doesn't really care where the dungeon grid comes from,
> >so I could even generate that in PHP using user-given parameters, then
> >feed it to DM when I call it (by saving it to a temp file, or sending
> >it in via stdin).
>
> You mean letting the user position wall tiles (and by implication rooms and
> whatever they desire) before the WallCrawlers are let loose? 

Basically, provide them with a way to input the dungeon parameters over the 
web, instead of providing an input file. This was the idea behind using a 
hashtable-like object to store a dungeon's config data - then entering the 
data is the same no matter what the source (a key=value scheme, which is 
easily parsable, no matter what language the front-end is written in). The 
front-end would be written in PHP, so couldn't start up c-based DM objects 
directly. It'd have to write the parameters to a temp file, run the dungeon, 
and then offer the user the option of editing it.

> That would be
> pretty cool I think. But if you did that, why stop there, why not let the
> user also place the design Crawlers? 

no reason not to.

> That would actually be an interesting
> interactive game all by itself. 

it would certainly be interesting to see what the crawlers do if started in 
different positions. (It would be even cooler to see them step through it, of 
course, but that's not something I'm shooting for soon.)

> And writing that as a web app should also
> make it easier to write a DungeonDesigner. I wonder: Would it be possible
> to design an interface that could work with a PHP-web-frontend for one-shot
> dungeon design and a QUB-frontend for interactive dungeon design? That
> would be way cool, I think.


I think it is "mostly possible". I mean we can't re-use 100% of the code 
across all user interfaces. But we can re-use the data i/o mechanics. If we 
use a key=value scheme for storing the dungeon/crawler/etc data, that format 
is very easy to parse, write, and store internally in Qt and PHP (and std C++ 
and Perl for that matter). Thus any app which could write a key=val file 
could do so, then launch dm with the name of that file. DM's output comes 
back via stdin or via another output file, if the execution command redirects 
stdin to a file. QUB, being C++, can even use the exact same config object as 
DM (except that I'll need to rename one or use namespaces, since they have 
the same name, but completely different code). For a PHP app I could pick up 
one of the many freely-available config-file objects laying around the net.

I'm thinking now that a web-based app would even be better than a local one, 
for this purpose, provided that it's easy enough to save/restore your 
configuration options. I can imagine a site which provides tweakable dungeon 
templates, and the ability to save/load your own templates. I've been getting 
back more and more into PHP lately for this work project, so that would be 
something I'd enjoy doing. As a side-project of the work project, I've been 
developing a very simplistic web application framework in PHP. "WebDM" would 
make a nice playground for that development, as well. Working on that would 
also help me finally decide on a final format for the save/load data, since I 
could see it from another perspective and possibly find "portability 
problems" with it sooner.

If someone had access to that they wouldn't need to build any sources unless 
they wanted to mass-produce dungeons as I did for QUB's DungeonCrawler set.

I'm glad you're back!

----- 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] dungeonmaker as a web application :)

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

>I've was toying around with some ideas and I think I've decided to make 
>a web-runnable version of dungeonmaker.

Would this be for pen-and-paper players to print out? Or just to show the
DungeonMaker to people without the need to download code?

>Actually... DM doesn't really care where the dungeon grid comes from, 
>so I could even generate that in PHP using user-given parameters, then 
>feed it to DM when I call it (by saving it to a temp file, or sending 
>it in via stdin).

You mean letting the user position wall tiles (and by implication rooms and
whatever they desire) before the WallCrawlers are let loose? That would be
pretty cool I think. But if you did that, why stop there, why not let the
user also place the design Crawlers? That would actually be an interesting
interactive game all by itself. And writing that as a web app should also
make it easier to write a DungeonDesigner. I wonder: Would it be possible to
design an interface that could work with a PHP-web-frontend for one-shot
dungeon design and a QUB-frontend for interactive dungeon design? That would
be way cool, I think.

Peter

[DM-dev] dungeonmaker as a web application :)

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

I've was toying around with some ideas and I think I've decided to make=20
a web-runnable version of dungeonmaker. Since writing a CGI app in C++=20
isn't something that sounds exciting, I'll do it in PHP and run=20
dungeonmaker from there, passing it whatever arguments the user select.=20
I can imagine an editor where the user can enter values for room=20
locations, etc. Then we simply run the dungeonmaker and print the=20
output to the screen, instead of to a file. Since I could pass data via=20
PHP in almost exactly the same manner as via a config file, this will=20
be a good testing ground for that stuff, too.

I don't guess it would be too difficult to give the user some=20
pre-defined options, like:
1) Big dungeon with lots of halls.
2) Small dungeon with one center room.
etc...
Just have a dir which holds templates and show the user the name of=20
each template.

Actually... DM doesn't really care where the dungeon grid comes from,=20
so I could even generate that in PHP using user-given parameters, then=20
feed it to DM when I call it (by saving it to a temp file, or sending=20
it in via stdin).

Hmmm....

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
Student: "Master, you must teach me the way of liberation!"
Master:  "Tell me who it is that binds you."
Student: "No one binds me!"
Master:  "Then why do you seek liberation?"

[DM-dev] EnhancedDungeon class

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

I've been thinking that I'd like to get some practise with STL stuff, and
what better than to write my next contribution to the DungeonMaker. I'll
write a whole separate new class with a constructor

EnhancedDungeon(pDungeonMaker)

that calls pDungeonMaker->GetMap( , ) for initialization. Everything else is
independent from the old code. Stephan, as long as you don't change the
values/meanings of the numbers returned by GetMap, everything will mesh
nicely. I'll work from my latest code, and we can later merge.

The EnhancedDungeon will have data members called "focal points", and will
store the shortest path to all focal points right in the map, for use in AI
routines. Typical focal points will be the exit, and chokepoints like the
centers of rooms the player has to pass through, or the locations of NPC's,
what-have-you... Based on conditions (like "player close to focal point 1")
the AI can then switch the path-targets of monsters around, making them
appear smart. This is something I will need in the demo game I intend to
write, in order to orchestrate the behavior of large numbers of Pacman-like
mini-monsters. I think it will be useful in other circumstances also.

The code that finds the closest path from every point to the exit will also
identify enclosed spaces, and it is then very easy to break them open or put
a door in to make a room. So that is the second bit of functionality
EnhancedDungeon will add. This will allow the use of many
"openAtStart"-Crawlers, which have a chance of enclosing spaces, and will
even allow the introduction of "closed"-Crawlers, that are closed at the
start of their run, and leave no opening at the end of their run,
guaranteeing to create enclosed spaces and therefore rooms.

One suggestion for Stephan: In order to get lots of rooms, we need the
option to have "closed"-Crawlers. For that to function, we'd need a new
parameter in the stats (for every generation different), "closedProb", which
would be most similar to openAtStartProb and should be next to that. You
could test your flexible file handling stuff by introducing that, and I
could then implement its functionality in the core dungeon construction code
after I got my new class going. (Without the class, this will of course
totally wreck the dungeons.) You'd have to change the definition of the
stats-struct too... What do you think?

Anybody else has a thought about how to improve EnhancedDungeon? Speak up
while there's no code yet;-)

Peter

Re: [DM-dev] I've got it: the best of both models...

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

>> Will this work when we e.g. want to make a room with 2 doors of
>> different sizes? Or must that be done with multiple calls to addArea?
>
>Ah, multiple doors I hadn't thought about. 

I think an interface for arbitrary rooms (think 8 walls, 3 doors, ... or 16
walls for a fancy palace?) could easily become too complex. The object that
is most flexible is the Wall... we should be able to make walls with doors
placed anywhere within them ("within" meaning at least one closed square on
each side of the door). If you want to make arbitrary Rooms, maybe the best
thing would be to put Wall objects in their constructor, then overload the
constructor for all sensible numbers of Wall arguments.

>I know "cp" and "rm" aren't anywhere near each other on the keyboard, 
>so I'm not quite sure how my fingers managed it, but they did.

The technical term for this is "absentmindedness", I think.

>That's my plan. I wouldn't be happy if it couldn't load from a file. 
>The difference from my earlier approach is that it will render as it 
>reads, instead of building a list and rendering it later.

That makes perfect sense, looks like this will be simpler, thus better.

Peter

Re: [DM-dev] I've got it: the best of both models...

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

On Sunday 01 July 2001 17:01, Henningsen wrote:
> >addRoom( x,y,w,h, doorSide, doorX=3D-1, doorY=3D-1, doorWidth=3D2
> >)
> >// doorSide =3D N/S/E/W
> >// (-1 =3D=3D try to center it based off of the doorSide)
>
> Will this work when we e.g. want to make a room with 2 doors of
> different sizes? Or must that be done with multiple calls to addArea?

Ah, multiple doors I hadn't thought about.=20

I've got a funny story to tell you (well, I have to think it's funny or=20
else I'll think it's sad, and then I'll cry). I was playing with the=20
new shared memory support in Linux, where you can use memory like=20
dynamically-resizable ramdisk. I wanted to see how quickly I could=20
build dungeonmaker from RAM, instead of on disk:

stephan@jareth:~/cvs/dungeonmaker > cp -R * /dev/shm
stephan@jareth:~/cvs/dungeonmaker > cd /dev/shm
stephan@jareth:/dev/shm > make
=2E..
(took about 2 seconds longer than normal, actually)
(okay, not clean up and move the compiled stuff back...)
stephan@jareth:/dev/shm > rm -R * ~/cvs/dungeonmaker

I know "cp" and "rm" aren't anywhere near each other on the keyboard,=20
so I'm not quite sure how my fingers managed it, but they did. I nuked=20
all my changed to DM. Talk about being pissed off at myself. I didn't=20
lose too much work, but enough to piss me off.

> Will there be a (text) file that saves dungeon layout, and that can
> be hand edited by users? Once one is familiar with the program, hand
> editing is probably faster than interactive (plus intercative will
> not be part of Dungeonmaker itself, so... hand editing is very
> desirable).

That's my plan. I wouldn't be happy if it couldn't load from a file.=20
The difference from my earlier approach is that it will render as it=20
reads, instead of building a list and rendering it later.

----- stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts

Re: [DM-dev] I've got it: the best of both models...

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

>addRoom( x,y,w,h, doorSide, doorX=-1, doorY=-1, doorWidth=2
>)
>// doorSide = N/S/E/W
>// (-1 == try to center it based off of the doorSide)

Will this work when we e.g. want to make a room with 2 doors of different
sizes? Or must that be done with multiple calls to addArea?

Will there be a (text) file that saves dungeon layout, and that can be hand
edited by users? Once one is familiar with the program, hand editing is
probably faster than interactive (plus intercative will not be part of
Dungeonmaker itself, so... hand editing is very desirable).

>Attachment Converted: c:\glinx95\email\attach\=
>
>Attachment Converted: c:\glinx95\email\attach\=1
>
>Attachment Converted: c:\glinx95\email\attach\=2

I think your mail program misfired and attached these (probably empty) files.

Peter

[DM-dev] I've got it: the best of both models...

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

We can have our cake and eat it, too...

DungeonElement is going to stay completely heirarchical. I
can use these objects in QUB to make a visual dungeon
editor. But...
For DM I'm adding a Dungeon object, which has methods
similar to:

addRoom( x,y,w,h, doorSide, doorX=-1, doorY=-1, doorWidth=2
)
// doorSide = N/S/E/W
// (-1 == try to center it based off of the doorSide)

addWall( x, y, w, h )
// like addRoom(), but makes a filled-in area

addArea( x, y, w, h, square_type )
// the main function which most other addXXX()'s use to do
their work.


The Dungeon object will be used as the only "gateway" into
the DungeonElement object, and the Dungeon user will never
see DungeonElement. Dungeon's structure will enforce that a
Dungeon:
a) cannot be made out of a hierarchical structure.
b) is in "auto-commit" mode. What I mean by that is that
once a user calls addRoom(), he cannot go back and delete
that room. It will render itself to a grid as the functions
are called, instead of via a render() function.

The internal implementation of Dungeon will use
DungeonElements, simply because I've already got the list
management and file output code written ;). The libDM user
won't ever know that, though. Going through the Dungeon
object enforces that there won't be a hierarchy of objects,
since those have grief when dealing with a flat input/output
source. Basically it will have to use DungeonElements unless
I also want to write the output file data as addXXX() is
called. Otherwise I won't be able to construct a list of
rooms/walls/doors to save! DungeonElement already has the
list-maintenance code needed for that, also, so there's no
reason not to use them, as long as the user is shielded from
having access to them. This is also future-compatible: in
the case that I come up with some really brilliant ;) way of
saving/loading hierarchies from flat files, I'll re-add the
hierarchy support to libDM to give it that flexibility.

:)

----- Stephan Beal - 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

[DM-dev] BugFix: "Version 1.0 does not compile"

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

On some systems, DungeonMaker 1.0 does not compile, with the compiler
complaining that 

"strlen undeclared".

This can be fixed by adding the line

#include <string.h>

at the top of the .cpp-file with the other includes.

Peter Henningsen

[DM-dev] TunnelCrawlers

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

I've been thinking some more about the TunnelCrawlers. It would have to be
done like this: use open/closed values like now, only flip meaning after the
Crawlers have done their work. The outside wall limiting the dungeon would
have to be of the wall-type that cannot be joined to, and later discarded.
We could still pre-place rooms that users must pass through, only we'd have
to position Crawlers in front of all the doors in order to get access. The
best thing: One could add a simple little option "build room", that would
cause the Crawler to create a random room with regular dimensions like you
expect to find in dungeons. The neccessary "Look"-function to check for open
space to build in is already there, it would be very simple.

The reason I went with Wall- instead of Tunnel-Crawlers was that I wanted
fairly open dungeons for alife entities to roam around in and hunt the
player. Rooms are just a nuisance for that. But I get the feeling that for
traditional dungeoncrawls with (basically) stationary monsters, the
tunneling approach would be preferable. Of course, all tunnels would be of
uniform width 1.

I don't really want to write this myself, but I'd support anyone who wanted to.

Peter

Re: [DM-dev] finally!! how does this sound?

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

>Indeed, it does appear to be that simple! Lemme give it a whirl. Should 
>the doors center themselves on the wall by default? This means no 
>WallWithDoor less than... 4 squares, right?
>WWWWWWW
>D
>D
>WWWWWWW

I don't know... centering them by default is not always possible (what if
wall length = 5, door width = 2? No centering possible). I would go with an
offset from the wallStart, which has to be at least 1. Also, doors *can* be
width 1 if minCorrWidth is 1. Always compare with that.

BTW, I'm glad you will give it a spin without independent doors:-)

>Instead of starting with an open space, we start with a filled-in 
>space. Instead of walls we have tunnels. We basically "negate" the 
>dungeon, except that the wall crawlers would have to be changed to do 
>something tunnel-like and not wall-like. 
>Of course, I'm not talking about converting the whole lib to do this, 
>but I thought perhaps it may as simple as "inverting" the square types 
>(open == closed, etc.) and adding a TunnelCrawler class. I think it 
>would be a matter of adding classes, but no changes in API at all.
>
>What's your opinion? 

My opinion is that the Crawlers can do that, but that quite a few
modifications would have to be made in the parts of the program that call
the Crawlers: A Crawler would always have to start at the dungeon entrance,
and then how do we make sure that we get to the exit (supposing there is
one)? We'd have to start another Crawler at the exit, and make sure the two
join up somehow. Right now, that cannot totally be ensured, so we'd have to
to a second processing step, joining any disconnected parts of the dungeon.

This second step is very similar to what i will do for version 2 anyway, so
that should not stop us. But I cannot envision right now a simple change to
the program that would do this. Would probably be easiest to write a second
version that tunnels (and then later maybe merge the two).

I've thought about this myself too. I think the Crawlers make maze-like
dungeons, and tunnelers would make more dungeon-like dungeons. Of course,
the code placing rooms would be quite different in the two cases.

Peter

Re: [DM-dev] finally!! how does this sound?

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

On Monday 11 June 2001 15:42, Henningsen wrote:
> Some of the problems i see with doors that are not part of walls:
> When a room is made, (let's say rectangular), the 4 corners are
> members of 2 walls each, which overlap at that point. What if a user
> places a door so that it includes that corner? Does the Wall come
> later and erase part of the door?

Excellent observation. Yes, But if a user puts a door (a 1x1 door,=20
anyway) he couldn't use it, in any case. But a 1x1 door won't work for=20
the crawlers, in any case.

> Another problem with a door that comes to the corner, even if it
> always has priority and does not get erased, is that it may
> effectively become too narrow, like this
>
> XXXD
>    D
>    X
>    X
>
> The door has the minCorrWidth 2, but the opening only has a width of
> 1, and actors of radius 1.2 cannot pass.

How about enforcing this:
If a door is placed on a wall and cannot fit at least 2 open=20
(non-corner) spaces, we simply don't allow the door to be placed, and=20
add() returns NULL (thus alerting the coder that there's been a=20
problem).

> Frankly, i don't want to deal with all these special cases just to
> give the user the option to place a door anywhere in the dungeon. You

I agree 100%.

> can have the safety of a hierarchical model (no special case
> checking) and the ease of reading a flat file model by leaving out
> Door altogether from the object hierarchy, and having
>
> Wall  (normal, no opening), and
> WallWithDoor   (this is a Wall with a door in it, but with at least
> one Wall tile to the left and right of the Door).
>
> See? All problems vanish!

Indeed, it does appear to be that simple! Lemme give it a whirl. Should=20
the doors center themselves on the wall by default? This means no=20
WallWithDoor less than... 4 squares, right?
WWWWWWW
D
D
WWWWWWW

:)

Unrelated:=20
I was thinking last night about a slight alteration in the dungeons,=20
and don't know the crawler-side ramifications of it. How does this=20
sound:

Instead of starting with an open space, we start with a filled-in=20
space. Instead of walls we have tunnels. We basically "negate" the=20
dungeon, except that the wall crawlers would have to be changed to do=20
something tunnel-like and not wall-like.=20
Of course, I'm not talking about converting the whole lib to do this,=20
but I thought perhaps it may as simple as "inverting" the square types=20
(open =3D=3D closed, etc.) and adding a TunnelCrawler class. I think it=20
would be a matter of adding classes, but no changes in API at all.

What's your opinion?=20

----- 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] finally!! how does this sound?

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

>One of the problems with this non-hierarchical model is that we simply "throw 
>pieces into a big sandbox", and hope they are in the right place. It's then 
>up to the programmer to make sure that it "makes sense." It is 100% possible 
>for a door to end up in the middle of a wide open space with this approach. 
>If you add Doors to Walls (or to rooms), this can't happen. But then than 
>drastically complicates the file format.

Some of the problems i see with doors that are not part of walls: When a
room is made, (let's say rectangular), the 4 corners are members of 2 walls
each, which overlap at that point. What if a user places a door so that it
includes that corner? Does the Wall come later and erase part of the door?

Another problem with a door that comes to the corner, even if it always has
priority and does not get erased, is that it may effectively become too
narrow, like this

XXXD
   D
   X
   X

The door has the minCorrWidth 2, but the opening only has a width of 1, and
actors of radius 1.2 cannot pass.

Frankly, i don't want to deal with all these special cases just to give the
user the option to place a door anywhere in the dungeon. You can have the
safety of a hierarchical model (no special case checking) and the ease of
reading a flat file model by leaving out Door altogether from the object
hierarchy, and having

Wall  (normal, no opening), and
WallWithDoor   (this is a Wall with a door in it, but with at least one Wall
tile to the left and right of the Door).

See? All problems vanish!

Peter

Re: [DM-dev] finally!! how does this sound?

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

On Sunday 10 June 2001 16:50, you wrote:
> >Then we have various convenience functions in Dungeon:
> >DungeonElement * addRoom( x, y, w, h );
> >DungeonElement * addDoor( x, y, w, h );
> >DungeonElement * addWall( w, y, w, h );
> >etc.
> >These are all functionaly identical except that they set the square type,
> > so they'll all just call:
> >DungeonElement * add( x, y, w, h, squaretype )
> >which simply calls add( DungeonElement ) on the created element.
>
> Hmm, I wonder what happens when you addDoor in the middle of open space? Or
> a door that has all its wall on one side, none on the other? I think this
> could lead to problems with rooms, or make very complicated
> special-case-checking neccessary. So I'd prefer if we had two types of
> walls, walls with doors and walls without, but no doors as separate

One of the problems with this non-hierarchical model is that we simply "throw 
pieces into a big sandbox", and hope they are in the right place. It's then 
up to the programmer to make sure that it "makes sense." It is 100% possible 
for a door to end up in the middle of a wide open space with this approach. 
If you add Doors to Walls (or to rooms), this can't happen. But then than 
drastically complicates the file format. I don't have a way to reload the 
data if I use a hierarchical approach, however (without using a binary 
format, XML, or something like it, none of which I really want to use). I can 
save the heirarchy, but if I can't load it, it's useless.

> DungeonElements. The Wall without door could be the same class, just using
> a different constructor (or default values in the same constructor). And a
> higher level design program could have a function "AddDoorToWall", but in
> the dungeonmaker itself we'd only have doors as parts of walls. Would that
> mess up your plans? I'm pretty sure it would be simpler to code, and less
> error prone.

The simplest, from a generic coding perspective, IMO, is the hierarchical 
approach, but we can't save that data in a useful way by using a flat text 
format. With that approach, however, it is a simple matter to do any checks 
to see if this child really belongs here (for example, a Dungeon could 
outright reject a door added to it, but a Room would not, and a Dungeon would 
not reject a room). Also, all elements get placed relative to their parents, 
so you never need to worry about calculating the x/y of child elements. Place 
them relative to where they belong (the parent) and let object take care of 
the coordinates adjustment itself during rendering (which is what they 
currently do). 

During the rendering process, it all comes out to a flat structure, anyway, 
100% exactly like the 1.0 ASCII output format. But it will be basically 
impossible to restrict what the user does before we get to that point, unless 
we have a model where, for example, a Dungeon can only accept Room children, 
and Rooms can only accept Wall or Door children. This type of arbitrary 
restriction scares me, though: "...control is a degree of inhibition, and a 
system which is perfectly inhibited is completely frozen." -- Alan W. Watts

It's been my experience that to add arbitrary limitations to the API does 2 
things: 
1) frustrates the coder, who may not understand the need(?) for them. 
2) adds to maintenance and code complexity as you find yourself working 
around your own (arbitrary-assigned) limitations(!).

e.g., if someone places a door in the center of an open space, let them. 
Maybe it's a magical portal. It's their dungeon, after all.

:)

----- Stephan Beal - 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] finally!! how does this sound?

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

>Then we have various convenience functions in Dungeon:
>DungeonElement * addRoom( x, y, w, h );
>DungeonElement * addDoor( x, y, w, h );
>DungeonElement * addWall( w, y, w, h );
>etc.
>These are all functionaly identical except that they set the square type, so 
>they'll all just call:
>DungeonElement * add( x, y, w, h, squaretype )
>which simply calls add( DungeonElement ) on the created element.

Hmm, I wonder what happens when you addDoor in the middle of open space? Or
a door that has all its wall on one side, none on the other? I think this
could lead to problems with rooms, or make very complicated
special-case-checking neccessary. So I'd prefer if we had two types of
walls, walls with doors and walls without, but no doors as separate
DungeonElements. The Wall without door could be the same class, just using a
different constructor (or default values in the same constructor). And a
higher level design program could have a function "AddDoorToWall", but in
the dungeonmaker itself we'd only have doors as parts of walls. Would that
mess up your plans? I'm pretty sure it would be simpler to code, and less
error prone.

Peter

Re: [DM-dev] basic_istream

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

>Looking at the basic_istream STL class, I think this will be a better 
>replacement for all FILE operations we do. For one, we could overload the << 
>and >> operators, so we could do something like this:

I have no doubt the proper STL functions are better to use than the old
standard C library i used. But yeah, let's stay away from nested templates...

Peter

[DM-dev] finally!! how does this sound?

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

class Dungeon
DungeonElement * add( DungeonElement *de );
/***
 returns the passed object, or NULL if it refuses to add it
 for some reason. Could also use booleans, but this approach 
 allows us to chain calls:
 dungeon.add( new DungeonElement() )->doSomethingToTheDungeonElement();
 the default impl. will never return NULL. it's there for future
 functionality.
**/

Then we have various convenience functions in Dungeon:
DungeonElement * addRoom( x, y, w, h );
DungeonElement * addDoor( x, y, w, h );
DungeonElement * addWall( w, y, w, h );
etc.
These are all functionaly identical except that they set the square type, so 
they'll all just call:
DungeonElement * add( x, y, w, h, squaretype )
which simply calls add( DungeonElement ) on the created element.

I'm working on the new save/load code now. The STL does have some cool 
classes for this kind of thing, and the C++ ref I have covers them all in 
gory detail. I'm gonna try it first using sscanf(), but eventually I'd like 
to switch to overloaded << and >> operators. Perl is still better at this 
kind of thing, though ;).

See ya!

----- Stephan Beal - 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

[DM-dev] basic_istream

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

Good afternoon, all,

Looking at the basic_istream STL class, I think this will be a better 
replacement for all FILE operations we do. For one, we could overload the << 
and >> operators, so we could do something like this:

DungeonElement *de = 0;
mystream >> de; // parses out x,y,w,h, etc.

This would also allow us to use the same code for console and file i/o, by 
simply using different streams. You could even then do:

cout << "enter dungeon item parameters (x,y,w,h): ";
cinn >> de;
if( de->isValid() )... // assume it sets a 'valid' flag if this works, since 
we can't (or shouldn't, actually, per Scott Meyers) return values in the 
normal sense from an operator overload.

See:
http://stephan.rootonfire.org/.cpp/istream.html#basic_iostream

Overloading operators sounds hard, but it's not. Here's an overloaded 
operator from QUB:
declaration:
 friend ostream & operator << (ostream&, const GCom &); 
implementation:
operator<<(ostream &os, const GCom &gc)
{
    os << gc.toString().data();
    return os;
}


Some text from the docs:
The functions:basic_istream& operator>>(short& val);
basic_istream& operator>>(unsigned short& val);
basic_istream& operator>>(int& val);
basic_istream& operator>>(unsigned int& val);
basic_istream& operator>>(long& val);
basic_istream& operator>>(unsigned long& val);
basic_istream& operator>>(void *& val);

each extract a field and convert it to a numeric value by calling 
use_facet<num_get<Elem, InIt>(getloc()). get(InIt( rdbuf()), Init(0), *this, 
getloc(), val). Here, InIt is defined as istreambuf_iterator<Elem, Tr>, and 
val has type long, unsigned long, or void * as needed.

Geez, they don't make these things simple to read. The top part, fine, but:
use_facet<num_get<Elem, InIt>(getloc()). get(InIt( rdbuf()), Init(0), *this, 
getloc(), val)

Actually... that text is incorrect. They left out a > somewhere. Ah, well, I 
can't make any sense out of multiply-nested template stuff, anyway. It 
confuses me. If you think about it, to subclass a template class it to have a 
child of something which doesn't exist until the child does.


Unrelated: I've added <string.h> to DungeonMaker.cpp in the new tree so it'll 
build on Mandrake. On my system this is taken care of by <string>, it appears.

----- Stephan Beal - 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