And back to CRPG stuff…
I was at a remote forested area which had a beautiful viewpoint from a forested hill of a waterfall across from it. I realized such an awesome view would be impossible to do in my current engine because the forests would automatically block your sight. That got me thinking about the concept of elevation in my CRPG.
If every tile on a given map had an elevation value, you could automatically consider anything lower than the current location’s elevation as view-able, and anything higher as not view-able. That way you could create canyons and depressions that limit visibility while hills or lookout points improve it! I’d only need to use about 3-bits (0-7) to get a good amount of range too. Tiles like forests would continue to block line of sight at the same elevation, unless you were above it.
As I pondered the implementations of it, I realized I had one small problem; I’d need more memory to support an elevation map in the game. Right now I have a 4k buffer for maps; I would need to either shrink it to support an elevation map, or find more memory somewhere. (I’m thinking I could use about 3k for tiles and 1.5k for elevation/light mapping… I’m sure I can dig up 512 bytes somewhere.)
Why don’t I compress the maps with something like RLE (Run Length Encoding)? Well, that’s mainly to save disk space. You still have to decompress into your local memory. And disk space isn’t an issue with this game; a primary difference from developing vintage games in the modern era is that you don’t have the concerns of manufacturing and packaging floppy disks. So you can use the biggest disks available without fear.
For now, I’m marking this idea as a P2 (Priority Two, nice to have but not strictly necessary) and shelving it. I really want to finish the combat system before I return to travel mode. And I should get the quest system and other elements done before I go around adding new things to other modes.
Combat engine work is still mostly idle; I’ve been trying to complete my spreadsheet of FX data before I go any further. This is so every spell has a combat effect that I can test and make adjustments to, as needed.
The way I handle FX in the game is essentially an engine that processes commands in 8-byte segments. There are commands to create sprites of a given pattern/color and animation style, move sprites from one point to another, create a circle, cone, or line effect, and so forth. But I have to have data to test.
One big element that will require a lot of testing is the timing. For several of my effects, I provide for a delay count so that the engine knows when to stop and move on to the next effect (if any). Sound effects are handled by the interrupts, which means they can’t really be used to time things. So I’ll need to try effects, make a judgement call on how well they look, and make adjustments as needed.
On the subject of sound effects, I’ve been doing a little redesign there too. I went back to the Tunnels of Doom sound effects to borrow a few (the monster ones are particularly good for negative effects) and I’m always impressed by them. The sounds are VERY small, only taking around 19-21 bytes of space each. Each seems to follow a pattern of three different tones, but also use the noise generator and different duration to achieve an effect. I’d like to go back and redo some of my positive sound effects (healing, curing, etc.) to match the same pattern, but that will take awhile and I have stock sounds I can use in the meantime.
Right now, my list of tasks is as follows:
- Fill in FX for all combat-oriented spells. Use placeholders if need be for some.
- Expand the action array to include direction of attack and other elements. I originally was trying to squeeze all action data into a single word (16 bytes), but now that I’m not processing sets of actions anymore, I can make this more informative and easier to use
- Fully split damage out from attack. My initial code had them closely tied together; this won’t work for area attacks, which ignore defense rolls. It also needs to consider effects, like positive/negative states.
- Make sure that area attacks that affect multiple units will process against all affected units and locations. I’m pretty sure this is set up, but it hasn’t been tested, and I may have biased it towards one unit while doing ranged attacks.
- Look into whether or not I can condense and data-orient the effects routine. Right now it’s 426 bytes of code that just changes a state array directly with addresses and instructions. Writing a data array structure that can do everything could be tricky though.
Plus I have two bugs to fix:
- When the wizard uses a wand, the wand effect pattern doesn’t appear to be changing orientation, as opposed to the arrows/quarrels used by the other party members. Could be a data issue?
- Some shots at particular angles are traveling well past screen boundaries and looping around. Smells like an overflow math issue with calculating the slope.