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
|
