[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