Tilting at Windmills

And once again I miss a milestone… Drat. On the plus side, I’m definitely working on it.

I’ve decided the dark backgrounds made my main site a bit too hard to read, though, so I’ve gone with a light background, and added some spiffier graphics.

I also changed the title of the site to “Crafting a Vintage CRPG”… a bit of a different project from just making any old regular CRPG. (And yes, I’ve had friends ask me why I don’t just use RPGToolkit or something.)

Crafting a Vintage CRPG

Happy post-holidays everyone. Well, except for New Year’s, which is this week.

Working on specs for the combat engine… a large part of this is reworking some of my original designs. I’m trying to keep math as simple as possible; single adds or subtracts rather than complex abstract multiplication.

For example, a basic attack is player level plus the hit modifier of a weapon, plus any hit bonuses granted by other items or temporary buffs granted by spells. A random value of 0-31 is added to this, and this is the “hit” value that must equal or exceed a defensive value of the target.

A more significant change was the removal of “item count” from the item structures. My original plan was to have two bytes for each item; one was an item number (0-255) and the other was the item count.

This caused issues, though, because it would mean that a player could carry a huge number of items, like healing potions, that only consume one item slot. It also meant that it would be difficult to have unknown items like “untried potion”. I also was unhappy with the 256 item limit, because it would make expanding item count impossible later, if I was to do an expansion or something.

So I decided to change the count byte to a type byte instead. This lets me have up to 256 of any one item type (swords, potions, etc), and I can have untested items as either a separate type category or use a bit in the item # to indicate it’s untried. To index the items in a larger file, I’ll just have an offset value for each item type; such a table would be very small and easily stored in CPU memory.

This only had one drawback… what to do with ammunition, the one thing in the game I needed to have an item count for.

My original plan was to have ranged weapon damage determined by the ammunition used, and have different types and levels of ammo. Each was a separate item.

I’ve had to change this so that instead, ranged weapons determine damage, and ammo is static; bows use arrows, guns use shot, etc. Instead of storing ammo counts in item form, each player just has four counters for each ammo type, and I’ll hack in buying ammunition so that it just increases the ammo counts.

Why have ammo at all? Well, there’s the issue of limitations. If you’ve played Tunnels of Doom or the old Ultima games, ranged weapons were by far the superior choice in 2D tactical combat. They let you hit the monsters without being in melee range yourself. In Tunnels of Doom, a great tactic was to take an ordinary sling and use a weapon honing ability to increase it’s damage. With “unlimited” ammunition, it quickly would become the weapon of choice. So having limited ammo is important for balance reasons.

Once I’m done with the spec revisions, I’ll be getting a combat engine propped up so that I have a skeleton to add some meat to…

Still working on combat engine stuff…

I got to thinking about something with classic CRPG’s. In particular, the party system, or the solo system, and how they are implemented in CRPG’s and what their value really is.

When me and my brother first played Tunnels of Doom, we each selected one of the characters for our own. We’d take turns moving them around, using abilities, etc. Navigation and other things was done through mutual agreement, one person doing the driving while another sat back and gave advice.

Is this how other people played? I don’t know. When I think about it, it seems like a precursor to the MMO’s of today. My brother and I still game together that way, using Teamspeak to talk to each other while we play our individual characters in World of Warcraft.

The early tabletop RPG’s were really just tactical war games, where they cut the number of units down from whole armies to a handful of combatants, all controlled by one person. This is essentially what party-based CRPG’s are. And that’s a good reason why you should have tactical combat; why else do you want multiple people to control otherwise? It’s more work to code, test, and balance.

The solo-CRPG has its benefits and penalties as well. The player only has to focus on developing one character, and the story and plot can focus more exclusively on him. There’s a reason most stories only have one protagonist; it’s easier to identify with. However, this usually results in the solo character becoming an “super man”, a master of everything.

I’m committed to doing a party-based CRPG right now, because it’s the kind of game I’d want to play. But I don’t want the game to become mired in the combat tactics to the point that the rest of it suffers. In particular, I want the game to have meaning beyond the numbers.

Reports of my being consumed by an ogre are greatly exaggerated… Well, unless you count World of Warcraft as a big nasty ogre. Not a hard thing to imagine…

Aside from the latest expansion being released, another factor has been the renewed and surprisingly sustained interest of my two favorite playing partners, my brother and his wife, in the game. Normally my brother loses interest in the game after a few weeks and I’m left on my own… which usually means I play half-heartedly for a few weeks then quit. The game is fun when you’re with other people, but by yourself it gets dull very fast.

My new job is also worth my time to focus on during work hours, so that means I should not (and don’t want to) do anything more than idle musing on game design while on task.

Some of those musings did include some thought on unit placement for combat. In particular, how to arrange them in a pleasing random fashion. I want orientation to be random, so you may have your party start on any side of the screen opposite the monsters, and in the case of an ambush, start in the middle surrounded by them.

This is harder to do than it sounds; it requires plotting a rough square on the screen, check each location for occupancy, and then skip one square each time you place a unit so that they’re not all clustered up next to each other.

However, at least for the initial skeletal combat engine, I’ll start with set positions. My goal is to fill out the smaller features later, and just have a working engine first that encompasses player actions and the basic flow of combat.

Anyway, I’ll set myself a short goal; to have that skeletal engine completed by end of year. That should be doable, I just have to force myself to take a day or two of free time away from online gaming to work on it.