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