Tilting at Windmills

So, I wrote up my attack routines for melee, ranged, and sorcery attacks. The source file size was considerable; the only larger one in my directory was the one for display functions. In the end, it clocked in at 1168 bytes of code.

Yeow. That’s gotta come down. It’s a large chunk of logic, to be sure, but I should be able to cut that in half.

The main source of bloat is the fact I have three separate routines for each attack type, each of which has a lot of the same pattern of code. Check for this state, check for that state, do miss check, do critical check… this could and should all be in one monolithic function that just has data stored to indicate which state, which values, etc. to use for calculations.

I got a suggestion to just alter the attack/defense bonuses and other factors when states are active directly, so that no “updates” are needed in combat. A nice idea, but then I just end up moving this logic from the combat routines into the “state check” routine that occurs round by round. All they do right now is decrement counters, and they’re only for the players, not any monsters, since it also operates in travel mode. Finally, this data is stored in a VDP data array, which means accessing it is slow; not something to do bit by bit.

Also, every attack is unique. If a defender has a spell that increases the attacker’s chance to miss, for example, this affects the attacker, not the defender. That means  you can’t pre-process values in, because they are dependent upon who is attacking whom, and what states they have active.

So, I decided to do several things:

• Expand the player array to include fatigue costs for all actions (move, melee, ranged, sorcery) and critical ranges. This reduces the amount of dynamic checking needed
• Alter some of the more problematic spell effects to be easier to manage. For example, one spell granted a bonus to melee attack and speed and a penalty to melee defense. Instead, I’m going to have it increase critical range and melee fatigue cost. This keeps the spirit of the spell I had in mind, and makes it less problematic to track as it only affects attack
• Express the different states and their effects in data format instead of in code. That way my attack routine becomes a data-driven engine instead of a bunch of linear IF/THEN type statements
• One minor change is to make the light counter and tracker a party-based one instead of individual character-based. My original envision was that the party had to have a “torchbearer” who had to sacrifice an offhand slot to carry a light source. This is way too much trouble, though, so I’ll just have light sources get “used” and it grants N rounds of R radius light to the party

These changes will increase the size of the player array which is no big deal. The save file is presently 512 bytes, and a good portion of it was unused, for future use in party quest tracking. I’ll have to make a ton of regression changes, though, to accommodate moving around values in the array. And redo my statistic screens again…

I’ve got the changes to the stat screens done. I moved equipment off to the second page so I had more room for stats on the main page. I thought about just not displaying some values, but I’m already concerned about the lack of feedback being too frustrating, so I’ll err on the side of caution for now.

Now I’m back to regression programming and testing for a bit.. then I’ll tackle Attack Routine 2 : Faster, Better, and hopefully Smaller…

This entry was posted on Monday, March 8th, 2010 at 1:37 pm and is filed under CRPG, Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.