Tilting at Windmills

Right, back on the wagon with the CRPG!

“What about that other game?” – “Shut up!”

I’ve been stuck in a philosophical design rut when it comes to the monster encounters in my CRPG, one reason I faltered for several months. I wanted to have 2D tactical combat, but I felt wretched about the fact that I could not have some things I wanted, like:

• Monsters with varied attack types, like humanoids who are specialized in melee, ranged, or sorcery, but otherwise look alike
• Multiple monster types in one encounter

However, after my old school game, and a rather dreary 4th Edition D&D session with too many long drawn-out combats, I think I’m starting to appreciate the idea a bit more. Enough, anyway, to get back to work.

The first thing I had to do was finalize the monster data structure. This particular pattern has undergone several revisions over the years, I originally had a 64-byte record size, but I’ve cut it down to 32 bytes by diversifying the data into other areas. Monster names (and their plurals) are stored in a large Name file with other objects, and special attack data is stored as spells in a single file which contains both effects and FX data.

I also came up with a decent “level” system. My actual monster data is just raw values, so I use a spreadsheet to track what the “average” monster at a level has for attacks, defenses, and health. I also have some type data so that creatures of particular types are immune to spell effects, will or won’t flee combat, and of course, A.I. level. My plan right now for that is as follows:

• Dumb A.I. – Attacks the closest target, moves towards them if only has melee
• Low A.I. – As above, but also keeps an aggravation counter for each player so a player who does more damage is singled out
• Medium A.I. – As above, but considers ranged and spell damage more aggravating than melee damage
• High A.I. – As above, but considers healing/buffing spells as aggravation

I worked up a list of about 25 monsters for the Demo, using 16 different patterns. (Of course I’m re-using patterns. It’s a tradition!) So far, I’m liking the diversification I’m seeing, it looks like I can do some statistical changes to make each monster a little different from each other. I have to do some infrastructure work to start actually loading this data and setting it up accordingly; I was hand-waving a lot of this before to just design the interface system.

A small feature I want to add that may end up costing a bit is the encounter announcement. Instead of just saying “3 trolls” I’d like to have it be a bit more, well, dramatic. I wrote up descriptive words for 2, 3-4, and 5+ monsters like “a pair of”, “a gang of”, “a swarm of”, and then a list of adjectives like “fearsome”, “horrific”, “repugnant” and my plan is to have it randomly construct a phrase like “A mob of fearsome trolls!” The only problem I can see with this is that the compound sentence construction may burn up some bytes I could use elsewhere… but then again, it just seems more fun. At the least, it’s an easy feature to drop later.

I’m working towards the idea of implementing melee combat effects. That’s the easy one. Then ranged and spell effects can be done, which will push the creation of the spell/special attack file section. From there, hopefully things can move along into FX. Plus I can look at memory left and try and figure out if I can still do this in 32k….

And now for something related…

My brother and I have been gaming since the 80′s, when my mom and dad bought my brother the Expert rules set (the original blue box with the illustrations by Erol Otus) and he later acquired the AD&D hardcovers. Of course, we both being pretty young at the time, we couldn’t make heads or tails of those books… My brother’s character was a multi-class paladin named “Gepotalin Rudilee” (he created the name from a boggle game set of letters) who had a laundry list of magic items and generally blasted his way through every dungeon because, naturally, they weren’t really playing the rules, more engaging in fantasy make-believe with some rough guidelines.

At one point, when he was in high school (or close to it), they convinced a friend’s brother to run a game for them. The brother was not particularly keen on doing it, so he made them roll up 1st and 2nd level characters for real, following all the rules, and then proceeded to TPK the party in the first encounter. It was an epiphany for my brother though; it was the first time someone had actually ran the game in a more-or-less correct manner, and they had followed the rules as presented. Later in college, he played a lot of 2nd Edition AD&D and was introduced to alternate games like GURPS and Traveller. But we never did go back to those old hardcovers, except to read them for some entertainment at times, and bemoan the political-correctness of the 2nd Edition.

It goes without saying we loved 3rd Edition. In fact, we played it until we were sick of it, almost literally. While we all disliked the ridiculous class/race restrictions of the old editions, and hated the ludicrous level limitations for non-humans, 3rd edition had obviously not been play-tested to see what the effect of removing these restrictions would have. Prestige classes were absolute killers of balance. Wizards and clerics were still far too powerful and necessary; ironically clerics ended up being the best magic-item creators because they were not reliant upon spellbooks. Magic item production became a dreary power-gaming bonanza, with players mass-producing wands of healing, magic missiles, and other effects to circumvent the spell-casting limitations. Finally, pretty much like every edition of D&D, the game started to break down balance-wise once the players got close to epic levels… sometimes well before then.

I’ve been running a 4th Edition D&D game off and on for the last two years. I do like 4th Edition; it went much further than 3rd did to fix some core issues to the game. But I really felt like trying to run a real old-school session for a bit, so I asked my players (none of whom have ever played the older editions, except one who was absent) and they all agreed to give it a try. My brother and sister-in-law even drove over the mountains (a 100 mile drive) to play!

Given I had several players who had never played before, and my brother suggested higher-level characters for a single session, I went ahead and designed a pre-gen party with an average of 5th level. I also gave them some decent magical gear, nothing too powerful, but enough so they felt like they were an experienced party. The party was balanced as well, with a ranger, paladin, cleric, fighter/thief and illusionist. I actually decided to use the random dungeon generator for a bit of fun and inspiration; it worked out all right, because I could use some of the ideas to make a more interesting dungeon, and discard the silly ones. (“ANOTHER elevator? Nah, I don’t think so.”)

So, we played for about four hours this Saturday, and the result was a lot of fun. (Although my sister-in-law was a little bored as the cleric; she didn’t get to hit much and she didn’t have to use any spells to heal anyone.) Here’s some of the highlights:

• Rangers in 1st edition are absurdly over-powered. They get their level as a bonus to attack and damage against giants and humanoids, which includes orcs, goblins, hobgoblins, etc. Against these enemies they deal sick amounts of damage. They also reduce the chance for the party to be surprised to a 1 in 6.
• Surprise was pretty lethal in the game; the unsurprised side got up to 5 rounds of free attacks/spell-castings/missile fire with no penalties. My players were never surprised though. (See above)
• Poison is very bad in 1st Edition. It was basically a “save or die” situation. The idea was that IF the player made the save, he lost no hit points. However, this works out to be pretty crappy in gameplay. 2nd Edition revised it so poisons that kill instantly are much more rare, and more likely to be encountered after the party has access to slow/neutralize poison spells
• Combats are much more quick than in 4th. I hadn’t realized how bogged down encounters had gotten, really. It’s like every fight is with a minion… but even one lucky strike can seriously debilitate or kill a player. It feels a lot more… heroic and risky
• The DMG is an absolute horror to try to find anything in. Plus it has a lot of material that makes no sense at all to include in a heroic role-playing game, like the effects of a urinary tract infection.
• Money in the game is pretty silly. Magical items like spellbooks cost thousands of gold pieces. If the DM is not giving it out like Monty Haul, the players won’t even be able to pay for training up to the next level. Also, 10 coins per pound? SERIOUSLY?
• Just to really make things weird, you get experience for magic items kept, magic items sold (usually twice what you would get for keeping it), and gold, at a direct ratio of 1gp to 1xp. However, training costs are exponential, so a player by 2nd or 3rd level would likely have the XP to train up, but not the money to pay for it. And getting more money would just make it worse!
• Thieving skills are kind of lame. As my brother discovered in the book, the DM rolls ALL of them. What fun is that? For things like trap detection, I could understand a hidden roll, but for climb walls? And don’t get me started on backstabbing…

I was asked at one point by someone why I didn’t run in 2nd Edition instead. My answer: specialty priests. They are the BANE of that edition, and a wise DM will absolutely forbid anything from the “Faiths & Avatars” handbook. They totally destroy any semblance of class balance, since instead of playing a given class, you just play a cleric of a god associated with that class, and get most of the benefits with none of the penalties! Fortunately, if you stick with the original 1st printing, and stay away from the Forgotten Realms, you can avoid this curse. Looking over 2nd Edition core rules, they did address and fix many issues I saw with AD&D… the next time I want to go Old School, I’ll definitely give that a try.

Been awhile since an update… and yes, it’s update #100! And I do have something to share, although not about the CRPG…

I’ve decided to work on a smaller side project. It’s another game for the TI-99/4a, of course, but it’s a bit smaller scale than my CRPG. I got into playing Legend of Zelda on a NES emulator, and I realized that a lot of the gameplay should be easy to reproduce on the TI. And I figured, why not write my own action/adventure style game that was original, but inspired by games like Zelda and Atari Adventure?

There’s a method to the madness as well. A game like this will make very heavy use of sprites. I may even have to consider designing a sprite rotation system to overcome the 4-sprites-per-line limitation inherent in the TI’s video chip. (That means the system will detect overlap and rotate sprites in and out of the visible positions in order to keep all of them visible for at least a portion of the time. This creates the ‘flicker’ effect often seen on old 8-bit systems.)

My combat engine in the CRPG also has a lot of sprite usage for special effects, but I’ve been hand-waving a lot of that complexity aside. While I could push on and figure it out as I go along, I’d much rather do a more sprite-oriented game where things are in real time. I’d solve a lot of the timing issues and difficulties that way, and then leverage that knowledge into the CRPG design.

My working title for the game is “KnightQuest”. You can see a mocked-up screenshot on the left.

It will be much like Zelda in behavior, with a scrolling chamber map style. I’m going to really try and make the graphics “anime super-deformed” style so it matches an old Konami game in style. The main character is a knight in armor, my plan is to use 2-color sprites with animation for him. Monsters will probably be single-colored; I have to keep in mind that if I use the “half-bitmap” hybrid mode, I’m limited to 8 sprites maximum due to a strange hardware limitation. I really want music in the game as well, but I’ll have to find somebody to help me out with that, given I have the musical ability of a deaf muskrat…

The game will use the disk system of course… the TI cartridge system is incredibly nasty to work in, mostly because you have almost no CPU RAM for buffer space. It’s no wonder a lot of 3rd party developers balked at doing games for Texas Instruments.

This game should take a lot less time to develop than the CRPG. I plan on writing up a prototype map loader/scrolling routine to make sure you can move a sprite around and have it contact stuff on screen and do clean transitions from one map to another. A lot of the work will be in sprite interactions, which is what I really want to focus on. That and generating all the graphical content, of course…

Ah, busy busy… anyone who’s bought a home, especially a condo, knows the confusion and frustration with the complexities of it. Insurance in particular is a hassle… even though a full home costs a LOT more for the owner to insure, at least it’s all on him… there’s no master policies to consider. Also, half my apartment is packed away now, with more to come in the next weekend. All my TI books are safely packed… fortunately all the knowledge is up here (taps head) or on the Internet.

I had a great idea on how to manage multiple targeting a week or so ago, and I’m working on implementing it now. I’m actually leveraging some code I had taken out long ago that was part of the animation system, so it’s back in! Good thing I saved it elsewhere just in case…

The battlemap is an 8×8 sized grid. Interestingly, character patterns on the TI are also an 8×8 grid. So, why not use an 8×8 pattern to store affected areas for different attack types, and then use the rotation code for animation to orient it and map it onto the battlemap?

Let’s look at an example. You can see on the left two patterns. The first one is the battlemap, with friendly units in black and enemy units in gray. The second is the blast pattern for a spell. The default direction is down. The topmost ally unit intends to cast the spell forward. So the process here is:

• Rotate the pattern twice clock-wise to change direction. Each rotation is also accompanied with a shift upwards to keep the center pixel in the same position
• Using the unit’s position offset from the center pixel, map the affected squares of the battlemap
• Scan all unit positions, check if they are within the effected squares. If so, add them to a stack of affected units

Now on the right image, you can see the affected areas. Three of the enemy units are affected by the blast, one is just missed. Not too bad, and I can make this the single entry-point system for ALL attack types, even melee which only affect a single square. It can also help me with tracking special effect boundary limits, so that flying sprites don’t go beyond the borders.

I’m a ways off from having another “interesting” video demo of stuff in action. Right now I’m in the rather dull infrastructure design part, where a lot of pieces have to be brought into alignment for something neat to happen. I also have to go back and make sure my monsters are ready for combat, so I can make sure attacking actually works… Special effects I’m saving for after all the hard work of determining results is done.

And since I’m also moving in two weeks, I expect that will take a hit on development time. Oh, and playing Mass Effect 2. And Dwarf Fortress. *sigh* Full days…

My apologies for the lack of updates in the last week or two… stuff is going on. If all goes well, I should be moving into a very nice townhouse condo at the end of the month.

I was actually on vacation last week, but because I got into a whole “house-buying” process, that put an end to any road trips I had planned, since I needed to save money. And as anyone knows… when you’re on vacation, you tend to get less work done. A vacation means getting away from everything, including your hobbies, which are usually done as a relief from work and other processes in your normal lifestyle. I knew I probably wouldn’t do much with CRPG development that week, the motivation wasn’t there.

I have, though, finished the small bit of refactoring I was doing to add a new sound file as well as juggle some data around. Surprisingly, I managed to catch nearly all the regressions before compiling, so I didn’t have too much work to get the game back to where it was. Classic99 doesn’t give me any hint of the increased overhead that loading a new sound bank will cause, though, so I’ll have to to check that on MESS or the actual hardware.

As you can see on my latest combat screen, I have fatigue going down from doing actions like moving around. The idea here is that combat is a mix of balancing tactics; if you try and do too much in a single round, you may run your fatigue up to the point that the character can do nothing. Guarding will restore 1 fatigue, and I will probably have an “attack direction” attack convert to a guard if there is no enemy there to attack. Casting spells runs you down as much (if not more) than fighting in melee or with ranged weapons, and you won’t be allowed to do any actions that cost fatigue if you’re maxed out.

My main concern with this system, when it’s done, is whether or not it’s fun. It’s a little more involved, and since fighting monsters yields no advancement, I plan to reduce combat encounters appropriately so players don’t become bored or frustrated with endless attacks. At least in the opening stages of the game, anyway.

Slow work on the CRPG the last week or so. Got some big real life stuff going on… just put an offer down on a very nice townhouse that was accepted. You don’t own it until you close, of course, but it’s looking good so far…

What I have been doing is some re-architecture of files. In particular, I decided to have two sound files, one for travel mode and one for combat. This gives me the whole buffer (2k) I have set up to devote to combat sounds without sharing space. This means splitting the data and also identifying “overlap” sounds that are needed in both modes. I could actually store sound data in records instead of memory-images, but sound data is particularly variable-length in nature, which means I’d end up with a lot of wasted space.

Consider that a “record” would likely be 128 bytes. (Yes, some sounds can easily consume that much.) That means storing 32 sounds would take up 4k on the disk. And some sounds wouldn’t use up the whole record, which is a lot of waste. So far I’ve been able to make 2k stretch pretty well, and it’s always accessible without any disk access.

Another change was to stop storing my “mob” character graphics, the 8×8 patterns for moving units on the travel screen, in CPU memory. There were 32 patterns, for a total of 256 bytes of high memory being used. I have room in the VDP for that, so I’m moving them out there. That means modifying another memory-image file’s base address and size to include the mob graphic data. Should be easy, and the added access time for two VDP accesses (read in from VDP, write back to VDP) should be minimal compared to what it would cost pushing them out to disk. I’ve considered pushing tile data into records, which would let me have as many character sets as I have file space and file count for, but for now I’m just keeping them in a static VDP location for speed.

I also decided to mine a few more classic TI cartridges for sound effects: Parsec, A-Maze-ing, and Alpiner. Sound data is always in the GROM for these old cartridges, but finding the data can be a bit of a hunt. You could use an emulator with a debugger (such as classic99) and check the value of the sound ISR routine’s address to find them, but you’ll still need a hex editor to extract the data out. ISR sound data follows a particular pattern: Searching for >E3 or >E7 values is always good because this is the setting to make the noise generator use the third voice’s frequency as its value. Not all games use these, though, so you also want to look for sound setting patterns and low-byte values for the count of bytes (Which is 1-12) followed by a duration byte (which is usually low). So far, most TI cartridges have been well designed and have kept all their sounds in one place, rather than scattering them about.

A few interesting things I’ve discovered:

• Parsec’s laser blast noise is nothing more than a single voice, brought from a very high to very low tone rapidly (Only 1/60 duration per change). The volume is a bell curve, louder in the middle and soft at the ends.
• The third victory tune in Alpiner is the opening of “Promenade” from Mussorgsky’s “Pictures at an Exhibition” suite
• Most of the sounds effects in Alpiner only use a single voice, probably so they don’t override the background music

After I finish the file changes, and make certain everything still works all right, it’s on with combat! I’ll admit that I’m a bit distracted into some sound crafting; it’s creative work and rather fun. I would rather have a “needs work” sound in place for combat than just a “beep” or nothing at all.

I completed the integration of the new attack code into the engine, along with all the necessary regression changes. The engine now occupies 16k of high memory with the lower 8k in CPU RAM as data space. Hopefully the program doesn’t get so large that the SAVE utility no longer works…

Latest Statistic Screen

Things left to do include:

• Combat attack, fire, spell casting, item using
• Enemy AI
• Combat FX and result feedback
• Battlemap loading and unit placement
• Ambushes
• Monster statistic screen
• Inventory management
• NPC interaction
• Quest interaction/tracking
• Mob interactions (doors, traps, etc.) and alteration

Still a lot of work ahead, but I feel a bit more confident that I’ll be able to squeeze it all into a standard TI-99/4a with a 32k expansion. I may need to go back and compress some code or re-architecture it like I did with the attack routine, or push more data off to the VDP or disk. I also uploaded it to the CF card and tried it out on the actual hardware, looks good! Although I definitely noted that the CF card is slower in disk access than Classic99. I need to be careful about that; it’s easy to forget in emulation that things aren’t as fast.

Latest Equipment Screen

Along with a new color monitor (A Magnavox Color 80, which any retro-computer type would know was one of the best of the era), I picked up the references manuals for the Commodore VIC-20 and 64 at RE-PC last week. (I was going for TI stuff, but Larry Correa from the Yahoo 99′ers group cleaned them out of everything.) I wanted to take a look at how graphics were done with the eventual idea of making a 6502 port of the game. Plus, I’ve always wanted to know more about how these systems worked.

To my surprise, the C64 in particular is rather limited in comparison to the TI. Instead of having the colors tied to the ASCII set like the TI, the C64 has a color map for the screen. This has an advantage; it’s easy to do different colored text and numbers on the screen, for example. However, it also means that for something like a scrolling window of characters, you would need to update both the screen table AND the color table to keep them in sync. Since both are located in different memory areas, two accesses are needed. Then again, the C64 also has the advantage of  memory-mapped video, so it does this much more efficiently than the TI could.

However, the TI is also capable of much better color definition. Using enhanced graphics mode (admittedly only available in assembly), the TI can display 2 different colors per line in an 8×8 block. The Commodore is  1 color and one universal background color per 8×8 block. There is a higher graphics color mode that has 3 colors and one background, but it requires raster interrupts and also reduces the screen width in half (so each pixel is 1×2 in size). I’ve heard that some c64 programmers found some cunning methods to get both the higher color count AND resolution at the same time. But I’d have to ask, myself, how practical it was to implement and if it was workable for a game, instead of a demo.

Latest Spellbook Screen

One thing both systems have in common is the use of an ASCII character set which can be redefined for graphics. This is very nice. I’m not sure how much headache an Apple II version would be yet… Apple II graphics with their 6-colors are an engineering marvel but rather confusing to those of us who didn’t grow up programming with it. I’d like to do an MSX and ZX Spectrum version as well… the latter has a chip very similar to the TMS9918A, but limited to 8×8 blocks much like the C64.

Aside from different computer versions, would be rather cool to do different language versions as well… German seems likely, I know a few 99′ers who are German. Not sure about any East Asian languages; the old character sets just aren’t large enough for the task. But, er, I’m getting WAY ahead of myself now.

Been working slowly at the extensive regression changes to accommodate my faster attack routine. After completing it, I was pleased to see it only occupy 602 bytes, including the data arrays. I’ve reworked the stat screen generation as well, so it should display the new data, such as attack fatigue. By this weekend I should have it back up and running, and I can continue my combat engine efforts. You can take a look at the two different attack routines on a post I made at AtariAge.

While I was doing this, I also created an entry for the Short but Sweet Contest on the TI-99/4a boards at AtariAge. The contest rules were quite simple:

• 30 lines maximum of code, 10 lines of data additional
• Extended BASIC or BASIC (Although you really don’t want to use BASIC)

Unlike the prior contest, which only in the end had two completed entries, there are now over a dozen completed entries on the board. And they’re all VERY impressive work.

It was interesting programming in Extended BASIC again. Much to my surprise, I remembered the programming style and tricks very quickly, and I was able to put together my game “Dark Maze” in about four hours of work. Refinement and changes took longer, of course, and the game runs VERY slow at native speed, because the GCHAR calls to uncover the map are a huge speed trap. Fortunately, in the emulator of choice, Classic99, you can select “CPU Overdrive” which speeds up the computer considerably while keeping it usable by a player. My game isn’t the only one that requires this.

It’s a good board at AtariAge, with a lot of 99′ers coming out of the wood work and just having fun programming on a computer they love.

Short and Sweet (SSGC) Contest at AtariAge

Dark Maze at AtariAge

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…

Okay, I now (hopefully) have the final form for the major components of the combat statistics done. This HAD to be done before I could go any further with actions.

I had to update my spreadsheet (Excel is VERY useful for design and tracking) to accommodate the changes to the player array structure, and also determine where I would need to make regression changes in the code. The program is large enough at this point that I don’t know quite everything that needs alteration, so I do text searches for labels to find the relevant bits. And I still miss a few.

New Statistic Screen

New Spell Screen

The ding this time came from the statistic screens. It turned out I had all of the coordinates in one place with one label, using offsets. So with all my offsets off, lots of stuff ended up in the wrong place. Whoops! Fortunately, I was able to correct these with a minimum of fuss. For now, there’s only one spellbook in the demo so it’s pretty easy to store just one set of spell data in memory for now. For the full game, I’ll put that data out to disk; there’s no need to burn 128 bytes of memory on it.

You also notice more data on the stat screen. I shortened the labels to make some room; obviously, the instruction manual will come in handy to explain what the values mean. The “M” columns indicate the failure chance of a miss with that given attack type. So Forestall here is pretty lousy with melee weapons (1/8 miss chance) but far better with spells. (1/12 miss chance).

The defense column shows the success chance of a defense against an attack that hits. They are parry, block (with shield or foci), dodge or resist. Not all are available in every situation, and a success costs the character 1 fatigue (or 2 fatigue for a dodge). Forestall, again, sucks at martial defenses, but is extremely good (1/4 success chance) at resisting hostile spells targeting him.

My original plan had been to have a limited number of defenses a character could take in a turn. But tracking these is a major hassle, requiring me to maintain and wipe data arrays each turn. And while some of the defenses can be improved with items, they’re mostly fixed. So you can’t really turn a wizard into a powerful fighter, even with the best gear. I’ll have to be careful to cap off the bonuses as well; it would not do to have divide by zero errors or negative numbers.

Now back to debugging move actions, and getting started on the “strike” code, which must determine hit/miss and damage, factoring in all spell effects.

Oh, bonus points if anyone can identify the source of the name of the “beginner’s” spellbook listed in the equipment of Forestall Grimm.