Tilting at Windmills

Churning onward…

As part of my work coding up traps for the encounter module, I realized I had to make my damage approach consistent. There’s effectively two kinds of damage reduction, one for wounding effects and one for every other kind of effect such as poison, charm, and so forth. So I centralized damage determination in the various modules to make it so the same rules apply everywhere.

I also realized my statistic screens for players need some serious revisions. To make it similar to the monster stat screens, I’m restructuring one so you are told explicitly your stats for melee, ranged, and defense. I won’t throw away the work I did designing the item stat generation with the little blocks indicating special qualities and such. Instead I’ll move it into the examine option for inventory.

I also need to write up trading code for the encounter module. Items in combat are randomly determined and can’t be recovered later if you turn them down. So I need to make sure you can trade off items to different players and, if need be, discard an item from your backpack to make room. (No, I can’t have chests of items generate in travel mode where the combat occurred. There’s a multitude of technical reasons why that’s impossible.)

I may need to go back to the travel module and make some changes there too. My original design was built around the idea of an “active” player. Whoever was active would be the one who picked up items, used his skills for trap detection, locks, and other things. But I’m wondering if this is going to cause trouble and confusion later. I originally extended it into the manager module but I’m going to change that so it prompts you to select a player for given operations instead.

So it turns out that 12k was NOT enough for both combat encounter generation and management. I had 1K left and still a ton of things to write. So I’m splitting the encounter portion into a separate module.

Fortunately, this is easy to do. The “encounter” module will do the following:

• Load monster data from disk
• Load monster graphics from disk
• Load player graphic data from extended memory
• Determine how many monster types are present and how many of each type
• Populate the data arrays for monsters with their randomly determined health and stamina
• Determine the terrain type of the battle map and set it up
• Load all graphic data from extended memory to support battlemap
• Place all units on battlemap
• Populate all necessary maps with unit and obstruction data
• Create encounter text to display

It then immediately shifts to the Combat module.

Doing so has already freed up nearly 4K which should be enough to get the job done. It also nicely separates the encounter work (which has a large amount of influence from content) from the actual battle management.

This means I have to increase the base size of my program file to accommodate another module. I may add another 24K just so I have a little extra data space; I already load in 8K segments from disk so it doesn’t hurt to add extra for graphics space, sound data, or other data needs that may come up.

I had to restructure some basic models for how player data was stored as well, as it turned out it was better for combat determination to have the system treat players and monsters as agnostic entities. This required moving some data around, which will probably create some fun regression errors for me to fix elsewhere. 😛

Funny enough, I found myself nearly repeating the same mistake that Richard Garriott did in Ultima III, which was to forget to include weapon/armor values in attack/damage calculations! 😀 A big change from the prior design is now it adds in all the calculations dynamically rather than trying to store them in arrays ahead of time.

I’ve updated my Progress page to reflect the new module as well.

So, now that it is July, the year is more than half over. My intention was to have the game complete by the end of the year. Will I make it? We will see…

I changed tactics and stopped working on the encounter engine, which was devolving into creating graphics and other more content-related work. Instead, I went back to trying to convert existing combat code. This turned out to be a good idea; a lot of elements need to be figured out in the new design, plus I need to find out if my 12k segment for combat will be large enough for everything.

I had to make a few changes to the FX engine code to support boss monsters, as well as convert it to read FX data from CPU memory pages instead of loading them from disk. Fortunately the code beyond this is largely unchanged.

I also need to add support for new concepts, like summoned creatures by players. I realized I could just have them be new monsters added to the unit list, but with the “charm” effect enabled. One the charm clock runs out they turn hostile on the player.

On the subject of units, I redesigned my arrays to store the unit type (including if they are “dead” or not, a player or monster, etc.), unit graphics (A zero means they’re invisible, don’t render them on screen), and unit coordinates. (A -1 means they’re “off map”, which only players can do, fleeing the combat.) Hopefully the combination of these three will cover all my bases!

I may do one extra thing, which is have player data copied from their normal arrays into a block adjacent to the monster state blocks. I’m having to write a lot of “specialty” code to do considerations between player vs. monster, and it’s getting annoying.

I’m hoping by the end of this month I’ll have the bulk of the code converted and can return to encounter design/generation.