Saturday, August 14, 2004

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

Monday, August 9, 2004

Goo for STEW...

So, I've really decided to gut my existing attack-related logic. I'm headed toward the capacity for true creature-specific attack logic.

Now, this really appears outlandish for traditional Rogue-types of games. Namely, the classic BSD Rogue only has one type of attack, and one type of damage. It has special functions which may be done in addition to the attack, but basically one type of attack.

There is one true exception to the rule, and that is fire-breathing dragons. They have a genuine ranged attack. It also has another odd type of attack, in that there is a (stationary) plant with an odd progressive attack. (It does more damage the more times it hits you.)

However, those two oddities are patched in to a structure which is extremely straight-forward. It has only one way to determine if you are hit. It has only one true form of damage. It is very centered on hand-to-hand combat.

Allowing STEW to support true creature-specific attack logic means that I'll be able to deal with things like the progressive attack without splicing logic in places it doesn't belong.

It also means that I'll easily be able to support things like the race-based defense advantages of the D20 system. Additionally, only with the flexability of true per-instance attack logic (where potentially every player and NPC could have their own attack logic) can I handle the sort of customization found in games like Silver Age Sentinals, and BESM.

In any case, this is a change of structure from what I was doing before. The change-over should go smoothly enough. it's pretty straight-forward.

Wednesday, August 4, 2004

Booga...

STEW is doing well. I'm hashing out some changes to the combat logic now. (Yeah, I decided to incorporate some of the new verb logic.) The big thing missing in STEW at this point is multiple levels and stairways. It's just one teeny little thing I've not gotten around to doing. It'll be the last step before saving/restoring can really be worked on. (There are some internal features that are inter-related between these two tasks.)

Internally, there's an issue in that the internal structure needs to be such that multiple levels can be loaded and run simultainiously. This will allow good multicharacter support, as well as provide the basis for multiuser support. (Multicharacter support is simple 'party'-based play, where the player controls a group of characters that have different advantages and disadvantages. Support for this allows for much more interesting class logic.) I have a clear idea of what I want, I just need to impliment it.