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...
Saturday, August 14, 2004
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.
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.
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.
Tuesday, July 20, 2004
Sweet, sweet STEW...
It's a stew-pendous update...
I have an initial pass at line-of-sight and weapons/armor. The line-of-sight seems sound, but ranged attacks aren't in yet. (I know how I'm going to do them, though. I had been worried about the lack of modal events in my event-driven archetecture.)
I had an epiphany and I've decided on an approach to handle "objects having arbitrary verbs" which is a long-term goal of STEW, but really one I didn't expect to complete for the Rogue phase. With the help of some utility functions, arbitrary verbs can be placed on objects -- and written in Python. Yes, that's right. I'm ever so pleased.
The new verb logic is causing me to rewrite most (if not all) of the older attack logic. Yes, special attacks will soon be handled as arbitrary verbs placed upon creatures. Due to the crude nature of Rogue-style special attacks, we have a simple list containing the special attack verbs to use.
The existing armor and ring logic will also be rewritten for the new verb logic. In this case, there's a setup/tear-down structure that's only been sketched out in the new system so far.
It should allow things like a "ring of divine flame" which (1) burns every scoll in your possession when you put it on, (2) grants you immunity to fire, (3) gives any weapon you wield additional fire damage, (4) when empty-handed allows you to shoot bolts of fire at your foes, and (5) slowly gives you permanent sensitivity to water attacks. Yeah, such an artifact would be like cheating in most scenarios, but the very nature of the system is that such an artifact could be a third-party addition added specifically for cheating. (Did I mention the only way to disable cheating is for me to start on the network-based play?)
I may go so far as to actually push the normal attack logic in to verbs, but I'm thinking that may be more complicated than I might first imagine, so it may wait out for a bit. In any case, I'll need the ability to impliment removing of some of the ranged attacks so I can do "Wands of Cancellation" properly.
I have an initial pass at line-of-sight and weapons/armor. The line-of-sight seems sound, but ranged attacks aren't in yet. (I know how I'm going to do them, though. I had been worried about the lack of modal events in my event-driven archetecture.)
I had an epiphany and I've decided on an approach to handle "objects having arbitrary verbs" which is a long-term goal of STEW, but really one I didn't expect to complete for the Rogue phase. With the help of some utility functions, arbitrary verbs can be placed on objects -- and written in Python. Yes, that's right. I'm ever so pleased.
The new verb logic is causing me to rewrite most (if not all) of the older attack logic. Yes, special attacks will soon be handled as arbitrary verbs placed upon creatures. Due to the crude nature of Rogue-style special attacks, we have a simple list containing the special attack verbs to use.
The existing armor and ring logic will also be rewritten for the new verb logic. In this case, there's a setup/tear-down structure that's only been sketched out in the new system so far.
It should allow things like a "ring of divine flame" which (1) burns every scoll in your possession when you put it on, (2) grants you immunity to fire, (3) gives any weapon you wield additional fire damage, (4) when empty-handed allows you to shoot bolts of fire at your foes, and (5) slowly gives you permanent sensitivity to water attacks. Yeah, such an artifact would be like cheating in most scenarios, but the very nature of the system is that such an artifact could be a third-party addition added specifically for cheating. (Did I mention the only way to disable cheating is for me to start on the network-based play?)
I may go so far as to actually push the normal attack logic in to verbs, but I'm thinking that may be more complicated than I might first imagine, so it may wait out for a bit. In any case, I'll need the ability to impliment removing of some of the ranged attacks so I can do "Wands of Cancellation" properly.
Monday, June 28, 2004
STEW update...
It's my journal so I can pretend someone cares...
Here's what I have so far:
1. The infrastructure seems sound. I like the general design principle.
2. I have a functional visual interface. The design is to eventually allow multiple interfaces, with the capacity to add new interfaces in a piece-meal fashion. That goal isn't quite there yet. What I have now consists of multiple interface APIs and a clear separation of underlying logic and page interface. I have the start of a second interface (a dumb line-mode interface) in addition to my initial curses interface, and the curses interface fully supports the line-mode API. We'll see if any of the interface logic holds water once I start working on Tk support (which will be after my initial release).
3. The design allows for multiple games to be written from the same infrastructure. This works, and has been tested.
4. The first functional game, made primarily to test the visualization logic was Conway's Game of Life. This also brought about the testing of the remappable key logic.
5. The second functional game, a clone of the BSD Robots was also a success. This was the first test of the heightened single-player cheating facilities. It brought in to play some aspects of the system that had been brushed over with Life. With it, I started playing with some of the visual artifacts that would be needed for true rogue-like games. These included message panels and information panels attached to the main map screen.
Currently, I'l working on the third functional game. This one is a clone of the BSD Rogue game.
My monster following logic is very sound, but there appears a bug in it causing to fail to notice that a route is impossible. (At least, that's my guess as to what is going on.) In any case, the whole "follow you anywhere, even if you teleport out of sight" is excessive. Particularly when you keep in mind that some Rogue-like games can't even follow any sort of indirect route to get to you. (IIRC, Moria in particular.)
The initial set of monster was taken straight from BSD Rogue, as were the initial objects. I have sime magic items, but I've not yet implemented equip/wield, so things aren't quite as complete as they should be there.
At this point, I'm working on my line-of-sight logic. This is primarily for ranged weapons and wands and what-not. However, I've gone ahead and started work on actual visual line-of-sight. (Something BSD Rogue doesn't really have.) I may actually implement it for my Rogue, just so I don't have to implement the BSD Rogue's "room-based sight."
In any case, it is time to stop gabbering, as my honey has decided it is time for me to sleep.
Here's what I have so far:
1. The infrastructure seems sound. I like the general design principle.
2. I have a functional visual interface. The design is to eventually allow multiple interfaces, with the capacity to add new interfaces in a piece-meal fashion. That goal isn't quite there yet. What I have now consists of multiple interface APIs and a clear separation of underlying logic and page interface. I have the start of a second interface (a dumb line-mode interface) in addition to my initial curses interface, and the curses interface fully supports the line-mode API. We'll see if any of the interface logic holds water once I start working on Tk support (which will be after my initial release).
3. The design allows for multiple games to be written from the same infrastructure. This works, and has been tested.
4. The first functional game, made primarily to test the visualization logic was Conway's Game of Life. This also brought about the testing of the remappable key logic.
5. The second functional game, a clone of the BSD Robots was also a success. This was the first test of the heightened single-player cheating facilities. It brought in to play some aspects of the system that had been brushed over with Life. With it, I started playing with some of the visual artifacts that would be needed for true rogue-like games. These included message panels and information panels attached to the main map screen.
Currently, I'l working on the third functional game. This one is a clone of the BSD Rogue game.
My monster following logic is very sound, but there appears a bug in it causing to fail to notice that a route is impossible. (At least, that's my guess as to what is going on.) In any case, the whole "follow you anywhere, even if you teleport out of sight" is excessive. Particularly when you keep in mind that some Rogue-like games can't even follow any sort of indirect route to get to you. (IIRC, Moria in particular.)
The initial set of monster was taken straight from BSD Rogue, as were the initial objects. I have sime magic items, but I've not yet implemented equip/wield, so things aren't quite as complete as they should be there.
At this point, I'm working on my line-of-sight logic. This is primarily for ranged weapons and wands and what-not. However, I've gone ahead and started work on actual visual line-of-sight. (Something BSD Rogue doesn't really have.) I may actually implement it for my Rogue, just so I don't have to implement the BSD Rogue's "room-based sight."
In any case, it is time to stop gabbering, as my honey has decided it is time for me to sleep.
Subscribe to:
Posts (Atom)