Tilting at Windmills

Well, a lot of work the last few days…

I had to restructure the monster array into something that was actually useful. I hadn’t taken into account many of the changes made on the player side of things. In particular, to keep the attack system clean and simple, I ended up implementing fatigue for monsters as well… it’s just EASIER, because otherwise I have to special case out monsters, track which units are monsters and which aren’t, etc. Strange how that works.

I also ended up increasing the array size for monster records to… 42 bytes. I’m sure there’s a joke to be had there. 32 wasn’t enough, and 64 was too much. 42 bytes makes for 6 records in a sector, with a 4-byte loss. That means overall I would lose 120 bytes on the disk. Bleh, I can live with that.

Lots of spreadsheet work as well. I used one to generate the pattern codes for the monsters. It’s just easier that way than using a program, because I’m currently just using Hex Workshop to cut and paste hexadecimal strings into files. The only thing I do on the TI is generate blank files to populate with data. Sure, I could write an editor or two… and I have… but for development purposes, it’s just easier for me to plop the data in there.

I don’t have any actual combat mechanics in play yet, because I had to do all this prep work BEFORE I could do so. But it’s done now, so I can start trying to implement melee combat. I also implemented my “encounter announcement” system, and set it up to load random monsters so I could see how it looks. A big problem, unfortunately, is that monsters who blend into the background colors of the battlemap may get hard to see… there’s not much I can do about that, unless I want to abandon monster colors entirely and make all units white. How boring.

So, gotta have something to show for my work, right? Okay, here’s another movie:

The one little bug I have to address is that long sentences end up with a space at the start on the next line. This is a trickier thing to fix than you’d think.

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….

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…

I found the problem with movement… quite simple, really. I had byte vectors that weren’t quite accurate. A -1 applied as a word requires the whole word to be formatted as -1, not just the right byte. Otherwise you end up with units moving diagonally. A few quick fixes and my units aren’t moving over top of each other or in odd directions anymore. The code base is ready now for the actual “attack and defense” routines, which should be interesting, since there’s so many factors to account for. I also need to find a way to cleanly map area attacks to units affected… preferably with a single routine that can “map” the damage area.

For your entertainment, I recorded a video in Classic99 to show off the start of the combat engine. In particular, you can see the units don’t move in quite the expected order.

Hopefully this gets SOME comments…

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.