Tilting at Windmills

Happy Labor Day weekend everyone!

Work continues on getting a new demo version up and ready… I’m calling this one 0.60. Then again, versioning systems are basically a “Not done yet, come up with some number that says that” sort of excuse in software engineering. In case you’re thinking I’m not doing anything, here’s a list of the bugs and issues I’ve dealt with and fixed so far:

Regression Issues:

• Stuck on splash screen
  • Caused by moving a small block of code and not updating a label, creating a circular loop
• Still stuck on splash screen.
  • Checked debugger, was down in ROM code circling continuously
  • Caused by an attempt to use a branch command with an indexed memory address, B @MEM(R1)
  • Need to use address register format for this, like *R1
• Not all keys working properly
  • Missed some MOV instructions to copy over travel commands in sync
• Stat screen control logic odd; pages coming up in different orders
  • Keys reacting too fast because tracking repeats/held keys
    
  • Altered central key routine to check a boolean to see if it should go for repeatable or single keystrokes
• Wrong items showing up on lists
  • Updated item/name cross-reference index to latest iteration
• Ammo not displaying properly
  • Had to code a special case check into the file loader routine to prevent it from using the ammo count as an index add

Inventory Issues:

• Icons for items displaying wrong
  • Temp fix: cut off icon in name for now
  • Now loading item character set for graphics, blanking map viewer
• Wrong items displaying
  • Sort routine did not clear out targeted buffer
  • Using a data array name for a temp storage value
  • Logic for determining null items not completely closed
• Wrong options displaying for items
  • Item option building had extra instructions that messed up a key value
• Inventory display not complete; looks messy
  • Display code not reached due to bad logic
  • Fixed display logic, modified code for better display
• Item Removal resulting in huge change in values
  • Item data was out of sync with specification; corrected and updated file
• Stat screen crashed when all items unequipped, or backpack emptied
  • No null check for item counts on stat screen; added
• Item Equip did nothing, no changes to state
  • Forgot that ‘E’ was unavailable, needed for scrolling
  • Changed command to W)ield

Item Management

Right now, I’m working on the last two inventory management options, giving items to other characters and using items like potions and scrolls. The giving part is the only one I don’t predicate-determine if it’s possible to do, because I wasn’t sure I wanted to check that for each item one after the other… However, having to add an error message and check annoys me, so maybe I’ll try out just having a routine cycle through player items, determine if anyone’s got space, and just not give the option to give items if everyone’s full.

The other complication is scrolling selection methods. Player names, spells, items, all selected through a menu scroller. I should probably make that a generic function as well; currently the combat targeting systems are written solely for combat, and with a little work I could make it more generic, and reuse the same code. This means going back and doing some refactoring though. As I said, the work keeps piling up… and I haven’t even gotten to the buy/sell system yet! I’ll probably wait until the next demo release for the latter… too much is going into this already, I really should get something out so people know my website is still alive.

Another short update…

Work continues on getting a new build with item management implemented. I’ve done some code builds using A99 (Thanks, Joe!) to ensure my code isn’t too broken before I compile it on the TI emulator. So far so good… Of course, I fully expect the program to crash hard several times while I hunt down problems like this:

• Stuff I meant to implement but forgot about
• Edge case values causing catastrophic issues
• Code design going totally wrong and having to be re-written
• Word operands where I meant to use a byte operand, and vice-versa

One thing I wanted to implement was a more centralized key stroke system. I had found, to my chagrin, that I had totally forgotten to restrict key access for different menus based on built options. So a fighter, for example, could press the C key to try and cast a spell. Oops! I also needed to reduce the amount of code waste caused by replicated key scanning over and over again.

My end solution took me a little time to figure out, but I think it should work. I have a key and subroutine buffer for temporary key storage, and I also have static data lists for key sets that don’t change. Two values are used to store addresses for each, and the routine just returns to the calling instruction when it gets a key. A short build routine checks the game state to determine what set to create, and then does so. Not all routines use the key builder; if it’s a static list of keys, they can just populate the addresses directly.

One small side-effect of changing the key system was it breaks boat movement. If in a boat, you would move on rivers and waterfalls if you didn’t press a key. This is a case where in a turn-based game, adding a real-time event is difficult, because it completely goes against the nature of the game. I will probably add something back in later, and preferably at the interrupt level where it belongs. (Basically, IF you are in a boat, and on moving water, and if a timing criteria is met, THEN it moves you.)

I’ve also got some code in place to do some of the shopping mechanisms. But I’m leaning towards item usage implementation first, since it’s part of item management. I’m tired of leaving placeholders and unimplemented things behind me. Of course, items also involve spells, since scrolls can cast spells… *sigh*

It always amazes me about how much I’ve done, and how much I yet have to do… One very nasty debugging session lies ahead.

Short update… Still working on the items changes.

I’ve written a bunch of new code, but anytime I do this kind of thing, it’s like unraveling a tapestry… a lot of things fall apart and you have to rejoin it back together. I’ve had to restructure and reorder file data, as well as rewrite the statistic screens again, since ammo is now treated as an item and not a special case. (Except for the ammo counts). I also wanted to get the shopping system started, but I’m starting to realize there are far too many changes going in, and I have to reign it in so I don’t end up with a crasherific mess that is aggravating to debug.

I actually found a nasty bug I hadn’t realized was in there. My key tracking system was using static lists, but the display options only showed what was possible. Which was fine, but the key system accepted ANY key stroke. Whoops!

This may actually be a good opportunity for me to consolidate the key systems into a single routine, and just use a key/key subroutine set of arrays that are populated by the calling routine. I could leverage the option building portion into the same engine, so that when it determines what options to display, it also updates the keys as well. But, as I said, I’m yanking several threads there that will have to be re-woven into the whole…

I’m also considering, once I get all this done and working, posting a new demo disk release on my site. It’s been nearly three years, and the game has changed significantly.

Been a busy month… aside from re-starting my code work on the CRPG, I also had three birthdays (including my own), a camping trip, and aiding my parents in installing a french door. And I started playing World of Warcraft again.

So, I’ve decided to sidetrack and work on some other areas of the game besides combat. No, I am NOT avoiding combat. Actually, I’m interested in completing the functionality that requires user input, because:

• User input processing takes up the most code space
• It is priority 0 to the game; anything that is not needed should be cut

So there’s three areas I need to work on:

• Inventory Management
• Item Usage
• Shops

Inventory management means being able to go through your item list and trade items to other characters or drop them to make space. The trading aspect is a bit complex; I remember the rather complicated system that Tunnels of Doom used with an item passed like a hot potato until either dropped or wielded. I need a system here that is tight with memory and not complicated for the user.

Item usage includes both using items like potions and scrolls as well as wielding weapons and wearing armor. I don’t have a final vision yet of how the latter will work… A full-screen display with all equipped items and carried items so you can freely swap them in/out seems like a good idea, but it may be too much single-use code. I already have code to cycle through item lists, it may be better to re-use that. There’s one annoying edge case I have to consider: If a player has a main and offhand weapon in use, and he tries to swap out for a two-handed weapon. This means that TWO items go back into inventory, not one. If a player has full inventory, what to do?

Shops are the final aspect. In particular, buying and selling items. My plan right now is to just have a general merchant interface that allows for both buying and selling items, regardless of type. No need to force the player to sell armor at an armor shop, after all.

I expect that all these interfaces are going to burn a good portion of memory… at least 2-3k. (Of which I have about 7k left) The best way to reduce memory consumption is code re-use; don’t rewrite things or make special interfaces unless absolutely needed. I’ll be doing my best to do this, probably by driving all shopping interfaces through shared code and only differentiating at the end-point.

I haven’t included quest stuff yet, because a lot of my designs are still up in the air. I have some plans here, and a lot of it is data-driven, so it will be very cost-effective in memory to implement.

Another side-trek is the advancement system. As I stated in prior articles, I abandoned the level/experience system because I wanted a different type of game from the normal. I also wanted to avoid the “kill a  thousand rats” syndrome. My original plan was to keep most of the combat values static and have equipment be the determining factor of how strong/powerful a character is. I did have a side-plan of in-game “milestones” that would advance the entire party, probably by increasing their health and stamina a set amount for each new one discovered. That way, the advancement system is tied into game world exploration, not game mechanic exploitation.

However, when I was looking over my monster stats and crunching some raw comparison values, I realized it was a little dull to only have items influence values. But I wasn’t happy with just adding static values universally. There had to be some granular difference between classes, otherwise, what was the point?

So I’ve decided that milestones will also advance the combat statistics, with variations based on class. Using some modulus division, I can create a simple determinant of whether to increase a value or not. Each class has about 27 unique values, which I can either store in 2-bit format internally (About 61 bytes) or I can store them in an easier to process size on disk. I’m favoring disk at the moment; space is getting tight but bit-crunching is really expensive and harder to maintain.

And finally, we have a new link this week: The CRPG Addict. This site is maintained by an avid gamer who has committed himself to playing every PC-based CRPG from the beginning of the home computing era to the present day. While sadly that means my own CRPG is off the list (he simply doesn’t have time to play non-PC games), I like his style and method of measurements, especially his GIMLET ranking system for CRPG’s. Check him out!

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…