Target Insanity
Since I got a new blog space, I’ve felt that little nudge of conscience that tells me “Hey, quit screwing around and get some work done on the CRPG!”
When I last left off, combat needed the controls defined. This is one of the scariest parts of the codebase because it could so easily burn up a ton of precious bytes I need for special effects, quest management, inventory, and so forth. Writing the controls is fast becoming a major snowball. Every time I think I’m about finished, a dependency rears its head.
For example, today while coding the targeting systems, I realized I had to go back and determine the exact code structure for item and spell selection. Depending on what item or spell you’re using, a second targeting call may be needed. So the structure must support multiple calls. (One to select the item/spell, another for the item/spell itself…) Plus for items and spells it has to mass-load all the names into memory for the scrolling menu, and then load specific spell/item data to determine their needs. Fortunately, I already had a good file support system for this.
After that part was done, I realized that in order to have a movable cursor on screen, I need to implement the sprite animation I’ve planned for awhile but not coded yet. This includes animation interrupts as well as instantiation. I’m limiting myself to a maximum of four sprites, so this helps me keep it under control. Sprites can have up to two colors and two patterns that alternate at two potential different speeds, currently. This may all change later when I get into FX development, but as a placeholder it works.
So I get that done… THEN I realized I had to create a helper function to build lists of viable unit positions for menu selection. ARGH! I’ve hard-coded that the first four units are ALWAYS players, but monsters may end up with dead units, so I have to be careful. Also, the on-map coordinate system doesn’t exactly match up to sprite locations, so some adjustment is needed. Still, I got that done too.
Of course, none of this has been compiled or run yet. It will almost certainly collapse in a pile of errors. I find that most of my bugs come from single instruction flaws, like a byte offset by one or a slightly wrong instruction. (A very bad one is a subroutine return in the wrong place; this can totally cause the program to go berserk.)
Also, I’m really starting to feel that glowering irrational hatred for the user, who can’t just “think” his options into the registers and make my job easy. 
I plan to try and wrap up controls and action storage this weekend so that I know all player actions are being dutifully recorded into an array. Correctly. Once that’s done, I can get to the slightly more fun part of the combat engine… the monster AI and the action determination.
“Plus for items and spells it has to mass-load all the names into memory for the scrolling menu, and then load specific spell/item data to determine their needs.”
How do you load the spells into memory? Together with the name list or only the one that is selected? Or do the more commonly used ones (like ‘cast light’) remain in memory? Or are spells only usable in combat so you load them in with the combat code?
With my game I’m still not anywhere near implementation but I already begin to wonder what to put permanently into RAM. While I don’t make a “traditional” FRPG I want to integrate a dozen or so spells in different strengths that can affect a lot of things besides combat (telekinesis being the most complicated so far because of map changing effects – being able to build or remove barriers for example).
I also came to the conclusion that scrolling menus are probably best for 8-bit platforms without a mouse and while I fondly remember playing the Ultima games keyboard-only modern games should offer a bit more comfort.
However, to speed up playing I consider offering shortcuts via key commands (“I” for cast spell, then the keyboard switches into “syllable mode” and pressing I and M will then generate the command “incantare illuminare maximus” or something like that – really similar to Ultima Underworld when I think about it…).
Spells and items have their names in one file, and their attributes in another. Only the user really needs the names, while in combat, the action determination will just need attributes. None of them are kept in RAM right now; since spells and items are one at a time, it makes sense to push them to disk and save data space.
I could probably simplify the control system if it came to it, but I dislike the idea of going to some “code” system in which the player has to enter a number or letter to indicate the spell he wants to cast. For one thing, I’d have to still code a more advanced input parser, since there are insufficient characters for all spells.
Also, for items, this would require the player to actually track what items he’s carrying on paper if I wanted to code it to item slots instead of a scrolling menu. Plus, it would still need to check if it was an item usable in combat, and any secondary targeting effects.
Spells are usable in both combat and in travel mode. Some can be used in either, some are exclusive. I separate them by index, so I know all spells of N or lower are combat, and N or higher are travel.
Combat and travel mode code are both in CPU memory at all times, in my current model. Code modules and loading are not really viable on the TI platform.