STEW-pendous news!

I have the first glimmer of multi-level support. This involved more changes than I'd really like to admit. Partly because I opted for a design decision that allows for multiple concurrent map levels to be running.

Basically, I've decided that infinite depth should be handled just like infinite bredth. I have a system of map-based triggers so that I can offload significant amounts of data when areas have become boring. (I don't yet have logic in place to do the off-loading, nor do I have the logic in place to determine the boringness of a location, but...)

Any system allowing for any sort of infinite map height or width (collectively refered to as infinite bredth) must have logic in place for not only off-loading object data, but also for off-loading internal map data.

Convieniantly for me, while the internal map data has a bit of an ordered stack structure, the map the user sees is 2D. That is to say, if an area is boring, the spot can a still be on-screen and I can offload everything about it except the visual glyph. (If it is off-screen, I can even off-load that.)

However, as multiple levels of the dungeon can be loaded and running at the same time, my object registry is truly unified. All objects in the game are in the same list. This leads to several issues in its own right. First off, it is currently a grow-only list. While I could create a 'free-pool' and recycle the old IDs, I'd prefer to reserve that to a formalized 'list compression' where I could remove references to the invalid IDs.

Even assuming 32-bit numbers are big enough that I'll never wrap, most people would end up running out of memory with just the list over-head for empty entries if it is a plain list. If I had a mutlithreaded database with decent transparent caching, it would probably solve most issues. (However, there would likely be a portability issue, so I'd need a decent generic solution as well.)

The design of the UOR (Unified Object Registry) seems very database-friendly, so some form of underlying database may be used. If lists are used, we need to have multilists, with runs of the list either not there (because the object(s) were destroyed) or off-loaded on to disk somewhere.

Anyway, I'm sleepy for now...