Title Image

Part 10: Updates

Wow, been awhile since I wrote one of these... a lot's happened in the last three years. I've changed jobs a few times, gained and lost a girlfriend (really need to make THAT a more frequent occurence), and bought a very nice townhouse condo. Working on the CRPG never stopped completely though... it just took a backseat while other things were going on. I also started a blog which made it easier to put out updates than a long article like this.

In this installment, we'll take a look at the numerous changes I've made to the design and implementation over the last three years, as well as what is left to do.


The interface has changed in a few places. I'm always toying with graphics, it's a nice little diversion from some of the more banal parts of the design. One thing that's still present but is going away are map names... it's hard to be interesting and descriptive in only 15 characters, and instead I plan to use two lines there for "notifications" that pop-up in places to give a bit of verisimillitude.

I also changed the map viewer's line-of-sight algorithm. I had originally used a technique that was introduced in the non-PC versions of Ultima IV. This technique plotted paths to the center of the display from each square, using two different paths for non-cardinal/non-direct diagonal squares. Demo - Version 0.60

The problem with this technique was it had an unstable finishing time; a fully open screen would take more time to process than one that was completely opaque, because opaque squares could be skipped. It also failed to take into account the areas surrounding each tile; each was distinctly calculated. The worst-case scenario, a player in the middle of a small blocking tile area like a forest, surrounded by empty plains, was all too likely to happen.

The new technique was introduced in the PC version of Ultima IV. It would do the following:

The effect this has is interesting. It actually finishes in a more consistent amount of time, and leaves more permissible space open, while still blocking out areas.


My original design for characters was inspired by a combination of Avernum and World of Warcraft. I had ability scores like strength, dexterity and intellect, which would be adjustable with each level of experience. I had a skill system that determined what weapons and armor a class could use, what spells they could cast, and what kind of actions they could take.

In fact, the entire system was, like almost every CRPG out there, directly inspired by and copied from Dungeons & Dragons.

So what's the problem with that? Well, the main issue is that D&D was designed as a tabletop game, and not a computer game.

Tabletop games are designed as entertainment. As such, the number of calculations made during play are kept to a minimum, and are usually simplified to meet an abstract requirement. A computer game is able to do a LOT of mathematics behind the scenes that a tabletop game would be unable to do and without any loss of time.

Also, a tabletop game involves a referee (the dungeon master), who makes arbitrary rule calls and decisions in case of dispute or lack of coverage. A computer game is very limited in comparison; the system must be able to deal with every potential case of actions or it just crashes/stops working.

I also realized, when I started to crunch numbers, that a lot of tabletop games LOVE derived figures. This is likely due to a focus on simulationist mechanics, attempting to portray the game as close to a real world as possible not only in the imagination but also in the gameplay itself.


In D&D, the original ability scores (strength, dexterity, and so forth) are considered inherent attributes. Everyone has a score for them, reflecting how strong, fast, or smart they are. (Yes yes, in 3rd edition creatures like undead had no Constitution score... that came much later.)

Ability scores were also generally static; the actual score remained the same for most of the character's career, unless increased by magical items, or decreased by particularly nasty monster attacks.

Now here is where it gets interesting. Despite having a strength score, it was not directly used to determine the ability to attack or the amount of damage done. The formula in old D&D was as follows:

Your base attack score was determined by class and level. Your strength bonus was NOT your strength score, but a bonus determined on a table. Your strength score was really just used as a table index. The item bonus was from a magical item, which could also be a cursed item that reduced chance to hit. And this doesn't consider external influences, like temporary bonus/penalties from spells, weapon verses armor adjustments, cover and concealment...

So, if we were to do something like this in a programming language, we would have to have the following: On a modern computer system, this isn't a big deal. Cycles and memory to spare! But on a vintage system, every byte counts. I found that when I started to write out code to get a hit roll, it was rather like the scene in the movie Spaceballs, when they order people to "prepare" to do something before actually doing it.

Argh! Which lead me to the thought, "Why am I doing all this derivation? Why don't I just have ONE statistic?"

So this started the boulder rolling down the hill... unlike a lot of other CRPG developers in the past who just took and used what D&D offered with only rudimentary changes, I started to question everything and why I needed it.

The first thing I did was get rid of ability scores. Factors like strength and dexterity are useful in a simulationist environment where you may have players attempting to do things in an ad-hoc manner. But the application in a computer game is not as useful.

I decided instead to identify the practical requirements for each class, so I came up with this:

They're fairly self-explanatory. Speed comes into play in the combat engine, where player actions happen in a specific order. Defense and attack are a measure of power aligned against one other. Criticals are the chance to land a much more solid blow that results in greater damage.

What about social interactions, like talking to NPC's, doing quests? Don't I need attributes for that? Well, not really. I decided that I didn't want something that required game mechanics to define. If you have a charisma or reputation score, for example, then you turn getting information into a game in itself. Truly organic uses of such skills are well beyond a vintage CRPG to do. Instead, I decided to focus on making the PLAYER think, rather than thinking through his characters.


One a side note, one thing I also abandoned was the idea of "mana" as an attribute. It was annoying to have to track mana as a null value in non-spellcasting characters, and putting a limitation on one class of attacks was very arbitrary. Instead, I decided to introduce stamina and fatigue. The idea is that spellcasting is exhausting, much like swinging a sword or firing a bow. By applying this to all combat actions, now every character gains fatigue, and combat becomes much more interesting for all the characters.


I've had a different list of classes from time to time, and I even considered dropping them entirely at one point. In the end, though, it was the cost of a custom character system that decided me.

Classes are useful because:

So after that point, it became a case of how to differentiate classes. I didn't want them to just be different base attributes and restrictions on spells and equipment. I wanted a solid reason why each character would be a good addition to the party. Absolutely no "not worth having" classes.

Originally, I had planned to use a skill system to define equipment usage, spell availability, and other factors. You can see some signs of it in my earlier demos. Then you would use points to decide how to distribute abilities, and bam, instant class balance, right?

However, I realized three things about custom skill systems: Any kind of custom system is expensive. The interfaces to choose skills, the access methods to retrieve values from them, it all adds up very fast. Custom classes are also a risk... you're not really designing a class here, but a system to make classes. Which means you open the door to a creative player creating a "tank magi". Class balance is also not as easy as that... some skills or abilities are always going to be more valuable than others. Trying to then weight them with different values should send a serious alarm bell off in your head that the system is taking up more time and space than it should.

I think the trap a lot of designers fall into is the idea of simulating reality. You want to have a system in which everything "works". But in a tight memory environment like a vintage system, the importance of being fun and interesting comes to the forefront much more quickly. Most players are going to go with whatever you decide a given class can do.

For now, my plan for classes is as follows: For example, the rogue has the abiltiy to "sense" secrets and dangers. This is also a spell that can be cast, but the rogue has this ability permanently. I haven't worked out all the other classes special abilities yet, but they'll be there.


One other changed aspect of my CRPG is how characters advance.

My original design specification called for, naturally levels and experience. If it's good enough for every other CRPG, why not here?

This system isn't perfect, though. I wanted to avoid the following:

My original plan was to have experience be affected by level differences between the players and monsters. So a very weak monster would have no exerience value. The 3rd edition of D&D introduced this with challenge ratings.

However, as I looked over options, I got more and more annoyed with the whole thing. Levels are just an abstract way to measure power. And all I was really using it for was to track health and stamina changes. And the player literally didn't have to do anything but kill things for it. You could have in-game quest rewards of experience, of course... but then again, why make it a numbers game? How important is it? The original creators of D&D considered dungeon and player levels synonimous; reaching another dungeon level was an achievement worthy of an increase in power.

So, I dumped levels and experience from the design. Instead, I'll give the player other ways to advance his characeters. Items will be a big part of that, and what I intend to do is have "milestone" objects in the game world itself that are buried deep in the most challenging dungeons and places to reach. They'll also be integrated into the storyline of the game, but I can't talk too much about that right now... spoilers.


Inventory management is one of the more dull aspects of any CRPG... but so important to do right. A bad interface here can make a game tedious and frustrating. Demo - Version 0.60

I decided early to have individual inventories over a party inventory. Since you can have parties of varied size, there is a distinct advantage to having more people... more space to store things! I did have on paper a plan to have in-game vaults to store items in, but I had to cut it out of the design as a low priority feature.

Coming up with a good item control system wasn't easy. I had thought to have a separate page for equipting and removing items, but this is expensive to implement. I also wanted an INTELLIGENT interface that wouldn't offer options that weren't possible.

My end-design was simple, a rotating scroll of items, which includes items currently worn. If a player has a full inventory, he can't remove any items until he rectifies the situation. Trading items requires other characters to have space for them, or the option isn't offered. Discarding special and important items isn't possible. Consolidating all the options into a single entry point really makes the system easy to manage.

Ammunition is a special case. I initially had ammo as a "count" for each player, but the idea of special-coding trading for it was annoying. So instead I made adjustments so that ammo is a unique item with a count. I had to update the displays to include an ammo count, and equipting ammo means adding to existing counts, but this was a lot less trouble. I really wanted to keep ammunition in the game because otherwise, ranged weapons would be too powerful and unbalancing.


At last... combat is here! Mind you, it's still a design in progress. The interface is finished, and the basic player controls are implemented, but for now, most of them don't do anything. You can move your units around, but attacking will probably crash the game...


The question arises, why have combat? A great number of tabletop RPG's have pursued this idea, looking to break the mold created by Dungeons and Dragons. After all, combat is really a nasty bit of business. It's what happens after diplomacy fails, and someone always gets hurt or killed. Why is it even in RPG's?

Well, the simple reason is, combat is fun! Not in the sense that the player actually enjoys inflicting harm. In computer and video games, it is more a sport than an actual fight, a challenge to overcome. Also, because it's all pixels and electronics, no one really gets hurt. Those who claim that violence in games leads to violence in real life... well, they have been making the same argument about books, radio, television, and so forth for decades. The evidence is against them. In some ways, electronic violence is probably therapeutic, giving people an outlet that is far better than real life to dispense frustration.

Combat in CRPG's involves resource management, tactical thinking, and sometimes a little dumb luck. Some are more cinematic and flashy than others; this is usually a measure of the technology available at the time. Modern gamers tend to expect a lot more in presentation than earlier gamers, who were happy with a decent interface and some color graphics.

Of course, combat can be really unfun as well. It can get monotonous, especially when there's too much of it. It can get annoying, when it occurs frequently and without chance of avoidance. And it can be unrewarding, when the experience and loot doesn't match the difficulties of the battle.

So, given that CRPG's have a lot of combat, it's important that the combat engine is as fun as it can be, and balanced enough to keep it from becoming a nuisance. And sometimes having the option NOT to fight is good as well.


Every encounter in a CRPG usually starts with some kind of flashy warning... a dissolve effect into the combat engine, loud noises, something like that. For now, I've kept things simple and just had the border flash colors and a little ditty of ominious music play. (The music is from an old composer, points to anyone who can identify it!) Since going into combat involves loading a new graphics set, I have to hide the screen during the transition.

I had one late-breaking feature addition that I couldn't resist. I added a descriptive system so that monsters are identified by name at the start of the battle with some colorful adjectives included, as well as an adjective describing how many of them there are. Sure it uses up a couple dozen bytes, but I think its neat. Besides, how else are the players going to know what they're fighting?


Obviously, every right has to take place somewhere... I had always wanted tactical combat like Tunnels of Doom, but I waffled in design over whether or not to have a "large" battlemap that you could only see a portion of it at a time, or a fully visible map. My end decision was "If 8x8 is good enough for chess, it's good enough for me."

Battlemaps actually have a lot of complications associated with them... my current one is just an all grass map generated in code. Before I can start loading those dynamically, I have to do random unit placement. I'm also concerned that they may be a bit too "colorful" and it may become difficult to discern where units are.

Turned-Based Theory

I had originally envisoned a tactical game much like Tunnels of Doom or Ultima. The player moves each his units in order, and their actions take place immediately. Then the monsters take their turn, moving in sequence.

Sure, it works fine. But it's what everyone else is doing. Some vary it a bit by having the units move in different orders based on initiative (a temporary speed determination) or speed (a more permanent order). I was chewing over the issue when I picked up a copy of the old 1st Edition AD&D manual and started reading.

Interestingly, in both 1st and 2nd Edition, players did not take turns in order. In fact, their actions didn't apply right away at all! Instead, the DM would gather from each player their planned actions. Then he would consider what the monsters would do. Then each party would roll a group initiative; the winner would go first. There was some added complications from weapon speeds making some players go out of sequence, or to determine tie-breaking moves, but the idea was that the players had NO idea if any of their actions would be successful until afterwards.

Now, I have to say, this system isn't that tenable in a paper-and-pencil tabletop game. Maybe it's the influence of MMO's, but players prefer to see results immediately after declaring actions, not later. A DM usually has to keep reminding the players that they are telling him what they would LIKE to do. So it's no surprise to me that current editions of roleplaying games favor a more action->result approach.

But for a vintage game... well, this is an interesting concept to explore...


First, I had to decide on how many actions I want to track. Since it's a vintage system with limited memory, no way I wanted an open-ended stack arrangement. So I decided on a base value of 2 actions per unit per turn.

What can you do with an action? You can:

I originally also had "use an item" as a single-point action, but in the implementation, I realized I had to actually use two actions.. one to remove the item from inventory, and the other to actually apply the item effect. I suppose this works out, because it reflects the extra time for the character to dig the item out of his backpack... it also has the side-effect of making slow a very nasty effect, since it effectively bars the character from drinking a potion.

Players can increase the number of potential actions, through the use of spells or items. The maximum is four, though, for space reasons.


Speed is also a factor with actions. Having everyone go in order is dull. Why not mix it up a bit?

Each action has an associated speed with it. Characters in heavier armor move more slowly than characters in light armor. Some weapons are faster than others, as are spells. There's also a random factor involved just to keep things from getting too fixed.

Since some characters may have more actions than others, I use a wide spread of numbers and base values based on total potential actions. For example, a player with three actions would have his actions all occur in the same turn, but not in sequence with a player with only two actions.

So how does it work in game? Is it fun? Well, I don't know yet. One thing I do know is I have to keep the amount of chaos in it to a minimum... if players feel like they have no control over the order of actions at all, it seems arbitrary and frustrating. If he knows his character is likely to hit first because he's using a dagger and wearing light armor, then there's some tactics going on.


Like my inventory interface, I wanted to minimize the number of available actions for each character using some intelligence. An immobilized character clearly can't move, and a character with no usable items shouldn't have the option to use anything.

Targeting units was also an interesting challenge. I wanted to have targeting systems for the following:

I actually was able to build a very efficent menu system, driven by a few parameters, that reused the same code for nearly every option. I changed a few keys on the way; I noticed that having the same button for selecting a target and ending the turn was a bad design move. But all in all I'm very pleased with it.

Left to Do

Things left to do with the combat engine include:


That's it for now... please feel free to download the latest demo and try it out!

Currently, my work is focusing on finishing core engine elements like the merchantile system, which requires player input. I probably won't get around to wiring up the combat engine for actual "combat testing" until after this is finished.

Next article, I think I'll side-trek into science and fantasy fiction stories, film, and other media that has inspired the CRPG genre and myself.