So I decided to switch things up a notch, and move over into monster A.I.

Why? Well, the FX spell system is now definitely working, the only tasks remaining are to implement and test out each spell individually. This won’t actually take too long. The only real complicated bit left is the alteration spells that cause battlefield changes, like creating a wall of fire.

I’m more concerned right now with removing a lot of the short-cuts and implementing the full pipeline for combat. This means actually checking for victory conditions, determining treasure, and returning back to travel mode cleanly. And as part of that… monsters actually doing stuff!

So my original architecture for monsters was, well… very ambitious. I had four different intelligence levels, the highest of which would consider spell casting as a “high threat” and target that character specifically. Every monster would have “aggravation” counters to determine who pissed it off the most. Spells would include at least two offensive and defensive spells: a ranged attack, a close attack, a self defense and an ally defense. And finally every potential action a monster would take would be weighted on priority and the best one selected each turn.

Then I realized how much code space it would take up to implement all this. I currently have around 8k of space left for code, and I still have a LOT of other stuff to implement. Creating the simplest and easiest monster A.I. to start with and then adding to it and updating it later when all the major pieces are done makes a lot more sense.

Plus, on screen, all a player is going to see is a monster take a step towards them. All that cleverness will be invisible and undetectable. Is there really a difference between a monster making a ranged attack on a character because it was the most properly weighed action, or just at random?

Plus, I don’t really want the combats to take a long time. Playing Ultima IV made me realize that when you have an awkward interface and no way to skip a lot of things, the combat can really become a hassle. (Get into a battle with reapers. You’ll see what I mean.)

And finally, it’s very VERY possible to make the monster A.I. just too damn good. If monsters all target the character who just threw a fireball at them with ranged attacks, that character won’t be alive long. It’s a general truth in most computer games that it’s pretty easy to write artificial intelligence that’s TOO good. You want it fun and challenging, not bone-grinding difficult to impossible. (Unless you’re playing Wizardry of course…)

The new simplified A.I. is pretty simple. A monster finds the closest target enemy unit and either moves towards them, targets them with a ranged attack, or targets them (or their location) with a special attack/spell. The one thing I need to add in and figure out is when a monster should use a close attack. A dragon breathing fire, for example, will want to have the player very close, and preferably none of its companions in the way!

I’m in a frame of mind now that before I release another demo, I should have as much of the game implemented as possible. That means not just the A.I. but also all the town services and everything needed to actually play the game. I really want to FINISH the game engine and start focusing in earnest on actually writing the story and designing the game itself.

It’s amazing how much effort went into getting only a few seconds of action on the screen, but wow it’s beautiful!

As part of my efforts, I also am making a few changes to how orientation is determined… I originally was going to have it random, but I realized that would be a disconnection from on screen, where you may move your party into a mob, or get attacked in turn from a particular direction. So I altered things a bit so the direction is determined that way.

Another aspect is the ambush. I realized belatedly that the Ultima mob methodology (where you see them and they move towards you) doesn’t work with ambushes because, well, you SEE them. How can they surprise you? So I’m redesigning it so that at times, hidden monsters are placed on the map and if you trigger them, it’s an ambush situation.

Work continues on the next set of spell effects, which includes a cone effect and a wall effect… I’ll want to test out all 64 spells individually to make sure they’re all satisfactory.

Yeesh… I’ve been working on this project for 10 years now… I seriously need to just get it done!

I’ve been pretty busy since late December moving into the new home, and getting things organized and put away. You accumulate a lot of stuff when you stay in one place awhile… and the fact I’m a bit of a pack rat doesn’t help matters. I found to my surprise that I had seven, SEVEN, TI-99/4a consoles in my garage. I’m not sure how that happened! I don’t need that many, really two is enough, so I’ll be looking to find new homes for some vintage hardware.

On the CRPG side of things, digging back into my code base meant figuring out where I had left off… as part of that, I also started to wonder how much more space I had for the game and when I’d need to start moving code into different areas.

A little hardware background first…

The TI-99/4a has a 16-bit addressing space, so it can address 64k of memory maximum. Most of this isn’t RAM; a lot of the address space is consumed by ROM’s, cartridge drivers, and other system peripherals. The console itself actually only has 256 bytes (!) of actual CPU RAM.

The only other RAM in the system is the 16K used by the video display processor. This RAM is not included in the addressing; there’s a memory-mapped ports in that very small CPU space (nicknamed “the scratchpad”) to read and write bytes to and from VDP memory. Yes, it is an eclectic computer indeed…

A fully upgraded TI-99/4a includes a memory expansion card, which adds 32k to the system. It adds 8k in one spot of memory (called “low memory”) and 24k in another (called “high memory”). When you wrote assembly language programs with the Editor/Assembler, you typically only have the 24k available, because the loaders used to load your program occupy the low memory, along with some other utilities. There IS space there, around 6k worth, but it’s tricky to get into.

Most assembly programmers on the TI write their programs to load as “memory image files”, which are just raw assembly code loaded as 8k segments directly into memory, chained together with a common file name structure. In order to convert your assembled program INTO memory image files, you used a a utility that occupied the low RAM. Which meant you still couldn’t quite use that whole space.

My solution to this problem is to reserve the entire low memory section as pure RAM for the program. I’m actually using that much RAM (or more) for the game; the maps alone consume half of it. After the program finishes loading, the entire space of memory is mine to use as I see fit, and I don’t have to worry about loaders.

But… my program is going to exceed 24k in size. I’ve known this for awhile, so I planned for it by obtaining a handy cartridge called the Super Cart. It’s basically an Editor/Assembler cartridge, but with 8K of RAM at the cartridge port address. This extra space will be enough to finish the game easily, and for those users who want to run on an actual TI, the cartridges aren’t hard to come by.

Figuring out how to create the memory image files for this proved to be a challenge, though. There are compiler directives to redirect code into different addresses, which I used, but I found out that I was unable to use any utility, in the emulator or on the TI itself, to actually create the files!

My final solution is a bit of a hack… literally. I do a memory dump out of the emulator after fully loading the assembled file into memory. I then hand-create the memory image files and copy and paste the data from the dump into files using a hex editor. It’s a bit slower than the old method, but it works, and now I have freed up plenty of space in high memory to finish the job!

On the CRPG code itself, I’m working to get at least ONE spell, fireball, working. The effect on screen should be spectacular, a ball of flame streaking towards a location and exploding, sending clouds of fire and dust in a slow spiral outwards. Implementing this has proven to be trickier than expected though…

Aside from writing the code to achieve the effect, I’ve discovered that my code to determine attack results with melee and ranged weapons got somewhat mixed into my actual effects code. I need to unravel it and clearly separate the effects on screen from the actual logic to determine WHAT effects to show and when… This also means I’ll have to do regression testing of melee and ranged combat when I’m finished…

My latest code effort was rather amusing… instead of a fireball streaking out to the targeted location, a fireball flew towards another party member and struck them causing damage! Not QUITE what I was going for…

Hello all! Wow, it’s been a year since I last updated… it’s been a busy one!

I had some major big things happen this year. I left my current job and got a new much better one. I started commuting by bus instead of driving, which proved to be far less of a problem than I thought it would be. This lead to my next move… to buy a house!

I’ve lived in a townhouse condo for nearly 5 years, and the time has come to move on to better accommodations! In particular, a place that is much closer to my girlfriend and that will be much easier for her to move into with me. Also, a LOT more storage space for all the things I love, like vintage computers, gaming books, etc.

So, for the rest of this year, I’ll be working hard at packing up stuff, cleaning out things I don’t need, and getting relocated to my new home! Then I have to clean and get my condo in shape to sell, very quickly… the market right now is very good for it, but that’s a bit of anxiety that needs to be quelled as quickly as possible.

After I get settled in, I’ll have time to look at my programming projects anew…

I have worked on the CRPG off and on over this year, but made no significant updates I could share… when I last left off I was trying to get spells working in combat, which will open up a HUGE amount of testing work to do.

I’ve also been lured by the ease of Extended BASIC into other TI projects as well…

I completed a conversion of an old favorite TRS-80 Color Computer game, “Space Trek” to the TI, and have several other small coding projects in the works, including re-creating Aardvark Software’s “Quest” and “Wizard’s Tower” titles on the TI (which were commercially released but copies are impossible to find now) and my own personal project, “Kingdoms”, a turn-based strategy game similar to the titles put out by Not-Polyoptics.

Christmas is in two days, and I wanted to take a moment to reflect on something personal…

I’ve met a very special and awesome girl. She is both a very good friend and the love of my life. I’ve been spending all of my free time with her, and honestly, it’s not enough for me.

Her list of virtues is endless. She’s pretty, sweet, funny, she loves to read, watch movies and TV shows, we have endless fun shopping together, exploring new places, and just being together. Maybe some of you know what I mean… when you have that special someone that just holding their hand and looking into their eyes… you just know.

She also loves that I’m a geek and she thinks my programming hobby is very cool. It goes without saying that she will be in the CRPG…

Everyone needs someone to love and love them, inspire and inspire them, and make them feel good about themselves and the world with all of its possibilities. I’ve found her, and I’m not going to let her go…

Long long hiatus indeed… Life’s been keeping me busy lately, namely a wonderful awesome girl. I’m turning my attention back to the CRPG…

When I last left off, I was doing a lot of prep work for spell casting in combat. I had to redesign the damage system to account for non-damage effects, compress effects code, redo a lot of my spell data, plug in test values for every spell to experiment with… you get the idea.

Now, it’s time to start actually writing the interface! For the record, combat in general has NOT been thoroughly tested in all edge cases… There’s going to be a lot of QA work involved there later.

I first fired up the current code and tried casting a spell. I found several glitches in the interface I had to fix, and I changed my basic spell data so I could validate that it was grabbing the right spells and populating the lists correctly. I have to be careful here because in game, there’s a theoretical maximum of 16 spells in a spellbook… so I don’t want to exceed that because it will overwrite other areas of memory. I still have some interface bugs to fix (Fireball wanted to target party members?) but I’m feeling good about the setup.

Naturally, when I looked at my code for spells actually doing something,I found to my amusement that I had NOTHING written in the action section… no wire-up at all. This actually reminds me of a recent interview that Richard Garriott (a.k.a. “Lord British”, the creator of the Ultima CRPG series) conducted where he admitted that he discovered AFTER he had released Ultima III that he had completely forgotten to write the code to wire up weapon damage to weapons equipped. He didn’t notice (as the ONLY tester) because the characters level also affected hit and damage and it seemed balanced enough. So if you play Ultima III, don’t bother equipping anything but slings or bare hands.

My next task will be making sure spell types and the necessary targeting interfaces are correctly wired, and then start writing the code to actually make spells happen and calculate effects AND display the FX. I probably won’t get this done before the end of the year… another New Year’s Resolution uncompleted! Oh well…

So, I finished up the changes to my effects code… although it remains to plug it in and integrate it with the main code base! I thought I would take this opportunity to show what was done and why…

Effects in the CRPG are, essentially, things that alter the status of a player, a monster, or the party in itself. This includes dealing wound damage, setting a counter for a spell effect, increasing the party’s rations, and so forth. There are around 40 effects in the game in total.

Originally, the code I wrote to process the effects was linear; each effect was a separate routine, and it used a passed register for the “address” to update, as well as values in a few extra registers. (For party effects, no passed register is needed, since there’s only one party ever.) Here’s a sample of how it looked:

So what’s the problem with that? Nothing… except that by the end, after crunching all the routines together along with the large reference array for each function (EFCASE), the routines take up around 426 bytes of space. Not a HUGE amount of space, even in a 32k system, but fairly significant. It also is hard to expand and maintain; I’ve had to revise effects multiple times and every time has been a hassle.

So, my new approach was to create an effects processing method. First, it’s in a separate workspace so that the registers can’t be corrupted by prior called routines. Second, all of the uniqueness of each effects is defined in a data structure, not as logic checks inside linear code. There’s more overhead writing a more “generic” processing system, but if your data is tight enough you eventually get more out of it.

Each effect is defined with a one or more 4-byte records. The first byte indicates which effect it applies to. The second is the type (adding, subtracting, checking for zero, etc.), whether to do word or byte operations, and whether it’s a player/monster or party change. The last two bytes are used for values or ranges to change, depending on the type.

The entire effects array is parsed each time a new effect is done. That is so every case is checked and every record potentially ran. In BASIC this would be a terrible waste, but for assembly language this is fairly fast. Given that the most effects calculated at any time is under a dozen, even a human user wouldn’t notice it taking much longer than a split second.

I haven’t crunched the numbers yet, but my initial calculations were very favorable for the size of the new Effects system… The data table is 240 bytes, and the instructions add around another 128 or so… It may not be much smaller than the original, but it’s VERY easy for me to maintain and add new records.

I also need to integrate it better into the combat system itself. My attack routines for melee and ranged are adding wounds directly; they should use the effects system instead. That will allow me to substitute in different effects, such as spells, within the same framework.

Been quiet awhile… I’ve had a lot of stuff going on in my real life, so the game has dropped by the wayside.

In particular, I’m going through a divorce. It was a short marriage, and quite frankly a serious mistake, but dealing with the legal and bureaucratic nonsense is enough to drain anyone of their energy. On the plus side, the house is much more quiet and easy to work on vintage gaming in.

About picking back up on the game… I was in the midst of getting the spell FX off the ground and re-writing the effects code. I also got back into World of Warcraft, though, and it’s a definite truth you can’t both play and write games at the same time.

I think I was in the middle of trying to convert the effects system to a data-driven routine… Time to blow off the dust and get the gears grinding again!

I was at a remote forested area which had a beautiful viewpoint from a forested hill of a waterfall across from it. I realized such an awesome view would be impossible to do in my current engine because the forests would automatically block your sight. That got me thinking about the concept of elevation in my CRPG.

If every tile on a given map had an elevation value, you could automatically consider anything lower than the current location’s elevation as viewable, and anything higher as not viewable. That way you could create canyons and depressions that limit visibility while hills or lookout points improve it! I’d only need to use about 3-bits (0-7) to get a good amount of range too. Tiles like forests would continue to block line of sight at the same elevation, unless you were above it.

As I pondered the implementations of it, I realized I had one small problem; I’d need more memory to support an elevation map in the game. Right now I have a 4k buffer for maps; I would need to either shrink it to support an elevation map, or find more memory somewhere. (I’m thinking I could use about 3k for tiles and 1.5k for elevation/light mapping… I’m sure I can dig up 512 bytes somewhere.)

Why don’t I compress the maps with something like RLE (Run Length Encoding)? Well, that’s mainly to save disk space. You still have to decompress into your local memory. And disk space isn’t an issue with this game; a primary difference from developing vintage games in the modern era is that you don’t have the concerns of manufacturing and packaging floppy disks. So you can use the biggest disks available without fear.

For now, I’m marking this idea as a P2 (Priority Two, nice to have but not strictly necessary) and shelving it. I really want to finish the combat system before I return to travel mode. And I should get the quest system and other elements done before I go around adding new things to other modes.

Combat engine work is still mostly idle; I’ve been trying to complete my spreadsheet of FX data before I go any further. This is so every spell has a combat effect that I can test and make adjustments to, as needed.

The way I handle FX in the game is essentially an engine that processes commands in 8-byte segments. There are commands to create sprites of a given pattern/color and animation style, move sprites from one point to another, create a circle, cone, or line effect, and so forth. But I have to have data to test.

One big element that will require a lot of testing is the timing. For several of my effects, I provide for a delay count so that the engine knows when to stop and move on to the next effect (if any). Sound effects are handled by the interrupts, which means they can’t really be used to time things. So I’ll need to try effects, make a judgement call on how well they look, and make adjustments as needed.

On the subject of sound effects, I’ve been doing a little redesign there too. I went back to the Tunnels of Doom sound effects to borrow a few (the monster ones are particularly good for negative effects) and I’m always impressed by them. The sounds are VERY small, only taking around 19-21 bytes of space each. Each seems to follow a pattern of three different tones, but also use the noise generator and different durations to achieve an effect. I’d like to go back and redo some of my positive sound effects (healing, curing, etc.) to match the same pattern, but that will take awhile and I have stock sounds I can use in the meantime.

Right now, my list of tasks is as follows:

Fill in FX for all combat-oriented spells. Use placeholders if need be for some.

Expand the action array to include direction of attack and other elements. I originally was trying to squeeze all action data into a single word (16 bytes), but now that I’m not processing sets of actions anymore, I can make this more informative and easier to use

Fully split damage out from attack. My initial code had them closely tied together; this won’t work for area attacks, which ignore defense rolls. It also needs to consider effects, like positive/negative states.

Make sure that area attacks that affect multiple units will process against all affected units and locations. I’m pretty sure this is set up, but it hasn’t been tested, and I may have biased it towards one unit while doing ranged attacks.

Look into whether or not I can condense and data-orient the effects routine. Right now it’s 426 bytes of code that just changes a state array directly with addresses and instructions. Writing a data array structure that can do everything could be tricky though.

Plus I have two bugs to fix:

When the wizard uses a wand, the wand effect pattern doesn’t appear to be changing orientation, as opposed to the arrows/quarrels used by the other party members. Could be a data issue?

Some shots at particular angles are traveling well past screen boundaries and looping around. Smells like an overflow math issue with calculating the slope.

“When a Star Falls”, UK4, was the first Dungeons & Dragons module I ever purchased. It was back around 1984, when book stores were selling D&D products and occasionally dice.

I bought it because it was for levels 3-5, a low-level module. I was still playing the box set of D&D at the time, and I didn’t realize the module was for Advanced Dungeons & Dragons. Given that at age 9 I could barely follow the regular D&D rules, Advanced was quite out of my means.

As I got older, though, I began to realize what a treasure I had accidentally purchased. The UK series of D&D modules were some of the best ever written. Most of them featured intricate plots and clever adventures that were far more than just a dungeon map with a list of encounters. It’s unfortunate that TSR UK was eventually closed down in the mid-80’s. The lead writer, Graeme Morris, actually left the gaming hobby entirely and his whereabouts are unknown.

So, on to the module…

The first bit of awesomeness about this module is how it begins. While traveling across a moor, the party comes across several dead monks, encased in a strange web. The web is a living entity that absorbs memories. After killing it, the memory web releases all its stored memories, which imprint themselves into the characters. There are over a dozen memories, described both with a few lines of dialogue AND an illustration.

Oh yeah, the illustrations are incredible as well. The artist, Jeremy Goodwin, creates some incredible scenery and sinister characters with an asymmetrical style that really stands out from the U.S. D&D modules. Even his black and white illustrations rock. If I could find him and he was still a commercial artist, I would SERIOUSLY consider hiring him to do illustrations for my CRPG’s manuals.

Anyway, the memories give the players the information they need. A star fell from the skies (a meteor) in the region, and the monks were on a journey to take a valuable tome to a sage, who would be able to tell them where it fell. The monks were going to retrieve the star for their master, the sage and oracle Shalfey, who resides at the Tower of the Heavens.

During their travels, the players also have an unwelcome visitor, the monk Sion, who serves Shalfey’s principal apprentice, Piyarz. (I also LOVE the names…) Sion has undergone a terrible ritual to become a shade, a half-shadow man that gains strength in shadows and is effectively immortal. He stalks the party, attempting to learn their intentions and, if need be, slay them.

The sage Derwyth tells the party that the star has fallen to the north along the river. You eventually discover that it has fallen directly on the lair of a tribe of derro, small blue-skinned creatures of the Underdark known for their sadistic cruelty and insanity. (The Underdark was still two years away from being introduced into D&D at this point.) Most of the derro were killed in the blast, but the survivors excavated the fallen meteor to examine it. The party must enter what remains of their lair and retrieve it.

After this, the party travels to the Tower of the Heavens. If they head north up-river, they have an interesting non-combat encounter. Tribal hunters and fishermen live on a lake there, but they’re isolationist and paranoid. Numerous derro raids have left them suspicious and hostile towards strangers. The party has to be diplomatic and careful to convince them to allow them to cross the lake. At one point in the village, while being hustled through by spearmen, a child screams from inside one of the huts, causing the party’s escort to panic and attack them. If the party manages to keep their temper, the mistake is discovered and all is well. These kind of quandaries for players to solve (preferably with no violence) are a welcome change from dungeon crawls filled with no ethical decisions to make.

At the Tower of the Heavens, the players discover the truth. Shalfey is being held prisoner by Piyarz and the other lesser sages. None of the other tower residents, including the gnomish mercenaries who guard it, know this. Piyarz desires to kill Shalfey and take over the tower, but Shalfey locked himself into the upper tower and threatened to destroy the books of prophecy, which are needed to see the future.

Again, the players face an ethical dilemma. While the lesser sages, Piyarz, and their monk guards are all fair game, the gnomish guard and the regular tower residents are all innocent and unaware. A party who charges in, slaughtering everything, will neither get very far (they’re SORELY out-numbered) or accomplish anything heroic. Pretending to be supplicants for an oracle reading and then sneaking in is the best route.

When the players deal with Piyarz and his minions, they learn the truth from Shalfey. The books of prophecy (which he just burned prior to the players coming in) were blank! Their knowledge of the future ran out, and the last clue given was that a fallen star must be taken to the nearby hills where a group of “dark smiths with a fabled library” live and exchange the meteor for a new set of books. So one final mission remains.

The dark smiths are a group of Svirfnebli, underground gnomes, who found a prismatic sphere guarding a set of books and decided to build their forge and base around it. While not evil, the inference is that the smiths are anything BUT good. They have built a number of automated minions called Maschin-I-Bozorgs that look like giant frisbees that fire darts and jets of steam. The party has to fight some before the Kagu-Svirfnebli will talk to them, and take the fallen star in exchange for the new books of prophecy. The star dispels the prismatic sphere guarding the books.

One last trick remains, though. The Svirfnebli leave the forge to return to their home in the Underdark, setting off the “self-destruct” button on the way out. The party must flee the cave before it collapses. When they reach outside, they find two red dragons waiting for them, allies of the Svirfnebli who are suspicious at the destruction of their home and angry at losing a source of treasure and food. This is the one part of the adventure I don’t like; aside from the meanness of dropping two major opponents on the party at a vulnerable time, and feeling like a cliche ending (you have to drop dragons into it, seriously?), the worst is that dragons are SOLITARY creatures and would never pair up for any long period of time.

The ending of the adventure leaves the party with questions. What was the fallen star, exactly? What are the intentions of the Kagu-Svirfnebli? Will they make a weapon of evil destruction from it? The great thing about this adventure is how it leaves an open thread for future endeavors.