Tilting at Windmills

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…

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.

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

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.

I’m working on the combat option system. So far, it’s not quite done, but debugging all the code I’ve written over the last week or so hasn’t been as bad as I feared. Generally, writing code is like building a house of cards… one bad one at the bottom causes the whole thing to come tumbling down.

The first bug I ran into was a regression; the statistic screen for player spells caused the VDP to go “wild”, switching modes and going into psychedelic colors. When this happens, it’s usually means you have a runaway video write going on, usually with a totally illegal value. The top two bits of a word are used to indicate VDP write modes, so even a negative value can cause it to go off quite spectacularly. An investigation quickly showed that I was using an archaic method to generate the spell lists, and I was able to leverage some new routines to do the job quicker and faster.

The other problem was the command going back to travel mode while still on the combat screen, among other bugs… this I traced to having subroutine returns in the wrong places. I use a stack tracked by a static register to store return addresses, allowing me to branch and link in multiple layers rather than just one. This works pretty well, but it’s easy to lose track of where you’re at. Then I found a bunch of problems with the sprites, such as them not being in 16×16 size mode. This was occurring because the contents of VDP register 1 are set to the value in the scratchpad at address >83D4. Every time you call the ROM routine to scan the keyboard, it does this replacement. Why I don’t know… fortunately it only needs to be done once.

Chosing a target

As you can see on the screenshot, I finally have a working target cursor. You can’t see it, but it is blinking, courtesy of a sprite animation routine I have in the system. Unlike Tunnels of Doom, you do not move the cursor around until you are on an enemy; instead it lets you cycle through the targets. Only area-effect spells allow free targeting anywhere on the screen.

Right now, I’m still debugging each command one at a time until it’s perfect. I added a cancel routine so you could remove the last order given, or all of them. Unfortunately, I can’t provide much in the way of tracking what each order was; I don’t have the icons to really show a complicated command with only one or two letters. Attack or move in a direction, easy. Attacking THIS unit or casting THIS specific spell is quite another. For now, I use single letters, like ‘M’ for move or ‘C’ for cast spell. It will be up to the player to remember what he ordered.

Why so much trouble, tracking actions? Well, my goal here is to not have your actions occur in a sequential order by player. Instead, each individual action will be given a speed, based on the action taken and a bit of randomness. Monsters actions are determined in a similar fashion. This means that you’re not certain most of the time WHEN your actions will occur.

I got the idea for this from a reading of the old AD&D 1st edition books. In that rules system, combat was divided into strict segments. Initiative wasn’t the only determination for when things happened. Weapons speeds were a factor, and spells never went off quickly. This allowed things like interruptions and granted advantages to faster weapons. As far as I know, very few people actually played the rules this stringently… AD&D was notorious for being over-complicated, and most players house-ruled a lot of things in, or ignored what didn’t work well. (For example, critical hits are NOT in the original rules, but most players add them anyway.)

I don’t know yet how fun this system will turn out to be. I’ve reduced the randomness quite a bit from my first design; I realized that since players would be blind to the exact numbers most of the time, too much randomness would make it seem arbitrary and chaotic. Hopefully it makes the tactical system more interesting than frustrating.

Latest Combat Screen

Well, the new year is here… I didn’t quite get to my combat milestone, but I have been working on it today, er, yesterday.

Right now, I’m working on adding the interaction menus and controls for the combat system. This also extends to spell and item selection, which will be used both in travel and combat modes. I’m not writing effects yet, just the controls for the user to indicate what they want to do.

It’s always a lot harder than you think… I wrote up the code to just display the text on the screen for the different menus, then I realized that actually projecting a cursor to move around is going to be even MORE work… wow. And controls always burn up the most code space. At this stage, I’m ready to use a SuperCart to finish the job, because I’m not all that inclined to start cutting yet.

Unfortunately, I’ve been sidetracked by a regression… while I was checking that the combat screen rendered correctly, I noticed going to the stat screens for characters produced gibberish for the items, and my video memory appears to be garbled up, projecting sprites on screen as well as mucking up other screens… Drat. Looks like a runaway video write somewhere is wrecking havoc.

In other news, I received Dragon Age: Origins as a Christmas gift. This has been lauded as an “excellent” CRPG, built and delivered with Bioware’s usual level of quality and value.

Well, my experience so far with it hasn’t been so stellar… it’s a decent game, and it reminds me of Bioware’s past titles such as Jade Empire and Mass Effect. However, I find the following flaws with it:

• The blood. The graphics designers clearly had been reading Conan, but there’s a world of difference between a pulp swords & sorcery story and something you can actually see… I found the gratuitous blood really quite disturbing… not for kids at all. The fact that your characters and others continue to talk to one another SPLATTERED IN BLOOD like nothing is amiss is even worse. You can turn this off in the options, fortunately.
• The graphics. They’re all right, but I can definitely see the textures are artificial. The leather looks rather plastic, and the clothing doesn’t move independently on the models. This is a bit much to ask even for a high-end 3D game, but since you spend a LOT of time looking at the models close-up during dialogue, it really becomes obvious.
• The color palette. These guys are in love with grey and brown shading. Everything in the game has a dull and lifeless look. I suppose this is to make the blood really stand out, but it doesn’t really make me all that interested in learning more about the world when it looks so bleh.
• The combat. Man, where to begin… very inspired by D&D, unfortunately, they made the serious error of making combat real-time. Oh sure, they threw in a pause option, but what they don’t get is that if you have real-time, you have to have combat that is fairly quick and easy to make decisions in. The system they have is far more suitable for turn-based.
• The companion AI. Well, as far as combat goes, the game provides a quasi-scripting engine to determine what they do in combat. They do NOT provide fully scripted settings for each companion. I don’t consider writing these up fun or interesting. It’s like deck design in trading card games… you’re not playing, you’re preparing to play.
• The quests and story. So far, I’ve had my character betrayed twice by supposedly “loyal” people. If I was playing in a tabletop game, I’d start killing every NPC after this point because “they’ll just betray me later”. One of the quests I did just sort of ended with a choice… kill a child, kill his mother, or go do another long quest chain to avoid the first two. The game is having me go around too much and not accomplish much of anything.

I’ll probably keep playing it, but I can already see a lot in a modern CRPG that I would do differently… and perhaps I will some day. I don’t intend to stick with vintage projects forever.

I’ve had combat code written for several months, back when I was going to split it off into its own engine for development. So it was quick to port it into the travel engine. I created a stationary “monster” mob that I could tag, and ran it to see how my code worked.

Not surprisingly, I got a screen full of garbage. Going back to the source, I found a multitude of problems:

• A copy routine I was using to generate a “grass only” battlemap for simplicity wasn’t copying words but bytes, finishing too early.
• The unit array structure had two different expected structures, one 4 bytes and the other 6 bytes in two different places.
• Display constants were wrong for several of the right rail elements
• Monster data files didn’t exist, and the creation source I had for them had flaws that created bad files.

Anyway, you get the idea. The code was totally untested, so I figured I’d have plenty to work out. With most programming, having something work the first time is not celebrated, it’s in fact rather creepy and unsettling…

After a hour or so of work, though I got all the issues sorted or clipped (for now) and it finished building the combat display. Voila!

Combat Screen

There’s a number of small details, like monster colors, battlemap loading, ambush determination, unit placement, that’s being faked with constants. I’m not concerned with that stuff right now because the main focus first is to get the controls for player actions done.

The main reason is player interaction code is by far the most expensive in space and time to write. I have to find out if I’ll have room for special effects and everything left in the other portion of the game, namely, dialogue, shopping, questing, etc.

So, the next step is the basic controls, so the player can move his units about on screen, designate targets, and so forth.

Exploring with the new LOS algorithm

Well, I’ve been working on various things, off and on… here’s a short list:

• Mob movement. I used a clock value to keep them from moving about too frequently. I still need to add collision with other mobs to this part, as well as a chase algorithm for monsters.
• Special terrain effects. I have four possible effects: wounding, fatiguing, poison, and slowing. They also have severity and occurrence values. Using a spell can negate all special terrain penalties.
• Option display. Most commands still need to be fleshed out, but it’s building the display at least.

The option code is also used with the combat engine, so I’m working that into the design now. I have introduced some regressions I’ll have to fix later… boarding a boat causes a status screen to pop up, which signifies a pretty nasty sedge-way in code somewhere…

This isn’t a new problem with assembly programming, really. Regression bugs are really easy to create, unless you pre-plan your code paths to an absolute degree. I haven’t done this, so there’s bound to be some oddball side-effects as I add more functionality. Fortunately, Classic99 is a good platform for quick and dirty programming, and frankly, I make a lot more progress this way.

I really want to have the total engine finished by the end of the year… the actual game contents will take more time, but will be a lot more fun and interesting.

A new way of not viewing things

I decided to overhaul the LOS (line-of-sight) algorithm in my game. I decided to use the alternate algorithm that was introduced in Ultima IV for the PC.

The results are very pleasing. It’s more permissive (more viewable squares) and it doesn’t have serious slow-downs when you’re close to or near opaque tiles. It also does less calculations overall so it doesn’t drag down the rest of the game engine. You can see in the screenshot that it has some interesting effects, allowing you to see around blocks of opaque areas in some cases.

How does it work? Well, instead of tracing paths from each tile to the center, it traces from the center outward. It first does the cardinals, which are easy, checking for opaque tiles on the way out. Diagonals are a little trickier; here it has to check three squares around the target one, and if any are open it opens that one as well. I suspect I could have a “minimum number of open tiles required” here if I want to make it more demanding, but I think the current effect is fine.

The original algorithm in C is pretty simple, a set of four loops with a bunch of IF conditions. Replicating this in assembly was not so simple, but I managed it… mainly it’s trying to do it in a compact way that recycles code. I also used a data array to indicate direction and vectors.

Now that that’s done, I can move on to the command/control system, which will also be needed for combat, inventory management, and so forth.