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

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…

Still not doing active development on the CRPG… My next post will be the 100th post I’ve done, so it WILL have some CRPG content of some kind!

I’m about 95% unpacked and placed now. I have a bunch of utility stuff (cleaning supplies) that still need to be organized and put away properly, and my office is still in boxes that need to be unpacked and sorted into a system. I’ve been pretty lax in the past about dealing with paperwork, having stuff stack up into huge piles. My goal with this new place was to stop that habit by not allowing myself a great deal of desk-room for such nonsense. So far, though, I seem to be able to live with growing piles of receipts and statements just fine. Drat.

My biggest annoyance is that I really have NO space for any retro computing in a permanent fashion. I could set my TI up in my office, but it will take up a lot of room next to my PC, and to be honest, I don’t fire it up often enough to justify it. In my old place, I had a side table set up for the TI and a PC. My downstairs rec room would be ideal for that, except it only has a single electrical outlet, and I would need to move out a couch before I’d have the room to make it co-exist comfortably with my gaming table. So, for now, I’m just trying to find a place I can pack my stuff in an accessible location to dig out and set up on an as-needed basis.

Anyway, having a new place, I’ve also found I have less interest in just sitting in my computer room/office and gaming… there’s a lot more to do now, and the computer will be there when I am ready.

Still here… just been really busy the last two weeks moving into a townhouse condo!

Some things I’ve learned from the moving experience:

• Don’t trust big banks to close when they say they will. Mine was one business day and weekend late, and as a result I ended up having to move during the week rather than on the weekend
• Load up or down stairs if you must, but try and unload at the same level
• When swapping locks, just put the same brand/type that’s already in there. Otherwise you may find yourself in for more of a project than you bargained for (Hole-cutting, chiseling, etc.)
• With condos, any repair work the inspector advised on should be checked to see if the Association handles it

I’ll put a photo up of the place later on this post.

It’s going to be awhile before I turn my attention back to CRPG development. I still have a ton of boxed books to unload before I feel that I can relax and actually start doing something again. I’m also uncertain as yet where my TI will go… I have a nice rec room in the garage area, but it doesn’t have a lot of plug-ins. Also, the natural gas water heater is right there, and I’m a bit nervous at the idea of having electronics so close to it…

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.