Combat in Runebearer

I wrote Runebearer over 13 years ago, and though it was never particularly successful in terms of the number of people reading/playing it (and frankly nowadays, it is almost unknown), from a personal standpoint, I think it turned out pretty well. I like the game. A handful of other folks like the game, and over the course of the past decade or so, the amount of enjoyment the game has brought me and my friends has been considerable.

And hopefully a few people outside of my various gaming circles have found it to be to their liking as well.

Looking at the rules as they stand today, one of the things I am pleased with is Runebearer's combat system. Runebearer started as an attempt to take the simplicity of an AD&D style hit point system, but still capture many of the interesting effects of games like HERO, Rolemaster and Aftermath. Ultimately, through many reviews, play sessions, arguments and revisions, I think I got it about 90% right.

The big thing I enjoy about Runebearer's combat is the fact that it is a positional combat system, meaning that one of the main determinants of a party's success in a fight is how the PCs position themselves on the battlefield in relation to their allies, enemies and terrain features. The fact that defenses degrade against multiple attackers, the engagement rules, and the rules for obstructions all ensure that groups who position their characters to support one another and use the battlefield will fare better than those that charge in carelessly.

Another thing that I think works well in Runebearer is its pace of decision is good. Combats are often decided in about 6-8 rounds. Combats aren't often decided on the first salvo, and they usually don't drag on beyond the point where everyone has lost interest. Because of the positional nature of the game, one side's position will crumble before all of their combatants are defeated, leading them to run, surrender, or fall back. This keeps combats fast-paced and exciting.

Finally, I like the mix of control and randomness that the game has. Combat is deadly -- every wound can drop you. However, most blows won't incapacitate you, and with talents, equipment, maneuvers and tactical skill, you can minimize your chances of injury. Still, that chance for an incredible shot (both for and against the PCs) is there and I think that adds a bit of spice to battles.

Are You Having Fun Yet? Part 2 -- Hook Your Character

Last post I claimed that the best RPGs came about when the players were taking responsibility for their fun. By that I mean players need to take responsibility for the quality of the game in general, thus ensuring that they and their fellow players have fun.

You can start taking responsibility right at character creation by making sure that you hook your character to the game world. This means that you take some time to understand the campaign setting and then you build your character so that he has some ties to that setting -- some purpose to his adventuring; something that he cares about; a reason to be. Understand what the GM is going for and make sure that your new character can be a part of that. When the GM is setting his game in a fantasy Age of Sail, complete with galleons, cannons, pirate queens, swashbucklers and pistoleers, maybe the dark, foreign, loner mage who uses magic no one has ever heard of and is deathly afraid of water of isn't a good fit.

In addition to making sure your character fits in the game setting, make sure you also hook your character to the rest of the group. Talk to your fellow players and make sure you fit into the party. Does that group already have a rogue? Then please don't make another rogue with all your skills one better. Is everyone else playing a member of an extremely strict temple? Your dual-classed hedonist-thief might not be the best fit. You want to play the dark, mysterious loner in a group of 8 PCs? Errr... maybe you should talk to the group and see what they think...

Oh, and the character who took the limitation pathological liar? Never OK. No matter how many build points you got. Never. O. K.

Ask the rest of the players about their characters and use that to help you get ideas for your character. Maybe you can even take it a step further and see if another player would like to hook your two characters together in some way -- perhaps you are siblings, classmates, or rivals.

The main point is to make it easy for the GM to give you cool stuff to do. You might think being a grumpy loner with no reason to live is awesome, but to everyone else at the table, that is a dull character. You have no ties to the world, so the GM has nothing with which to motivate you -- no Auntie May to kidnap, no liege lords to send you on a quest, no religions to fight for. Hell, you don't even like kittens!! At this point, don't be surprised when you find yourself complaining that the GM isn't making the game compelling enough for you. You have made a character who refuses to be compelled.

My regular game setting is a fairly small, religious, human-centric land and I have one player who plays a non-human, pagan, foreigner from a clan-based society. So he is an outsider in the normal campaign world. However, in his homeland he... well, he took the limitation "Clanless" which makes him something of a persona non grata in his home territory as well. He is an outsider everywhere and that means I have to work extra hard to get him screen time. Without some character modifications, or some serious suspension of disbelief, he is where plotlines go to die.

This isn't to say you shouldn't play what you want, or that campaigns shouldn't include offbeat characters, or that GMs shouldn't work at integrating all types of PCs into their games. But, it is a reminder that the player bears some portion of the responsibility for how his character fits into a given game. If you are wondering why your character isn't getting any interesting plots, ask yourself if you have given the GM any hooks. If none of the other players seem interested in your character, ask yourself if your character is interesting.

Take responsibility for tying yourself to the campaign world and your group, and you should find yourself having more fun.

Are You Having Fun Yet?

I do most of my gaming at my local game store and while there are several good games down there, there are also a bunch of failing games, filled with misery, griping and drama. These games start, play out and fizzle all in the span of a couple months. The entire time the players are griping about how crappy the GM is. The GM is moaning about how the players don't get his intricate plots. The players are sniping at the other players -- about how such-and-such is a spotlight whore, or a power gamer.

There are any number of reasons why these games fail... a downright dizzying amount. There are so many ways a game can go wrong that sometimes I am amazed that so many games actually work since statistically, it would seem that the odds are stacked against sitting down to a good, fun game.

I have played in and run both good and bad games and though there are many tips and tricks that I could talk about to push a game into the "good" zone, I would like to focus on one specific idea that I often see overlooked in gaming advice articles. Namely, the fact that in every good game in which I have ever taken part, all of the players were there to have fun.


Ok, I can hear it now, "Well of course we're there to have fun! We are gaming after all. That doesn't change the fact that the GM is a boring blowhard trying to railroad us into following his uninspired J.R.R. Salvatore Martin rip-off plot."

You may have a point, the GM has a big part to play in making a game fun or not, but I do think that the role of the players is overlooked. Too often, we talk about how it is the GM's responsibility to make sure everyone is having fun. But, looking back on the best games, I would say the players have as much, if not more, impact than the GM on whether a game is fun or not. Which brings me to the point of the post:

The best games are ones in which the players take responsibility for their own fun.


What does it mean for a player to "take responsibility for his own fun?" It means actively participating at the table, working with the GM and getting into his story, being funny when it is appropriate, being quiet when it is appropriate, letting everyone participate in decisions, understanding the pacing of the game and moving things along when they slow down...

It means a heck of a lot of things... Let's get into more detail in the coming posts.

Build vs. Buy ... Again?

I didn't anticipate talking about work on this blog. Mostly because of some vague fear brought about by those "Privacy in the Facebook Age" articles. Of course, I have always used my real name on the Internet since the days of Usenet groups. So, if any potential employer does happen to search for my name, they will likely learn all of my darkest secrets. Namely, that I am a D&D nerd, that I once wrote an amazingly unknown PnP RPG many years ago (which I still play) and that I have an unseemly attraction to video games.

I can live with that. Being a D&D nerd is one thing. Ranting about your company's business practices, or your boss, or co-workers in a public forum is another.

So, this isn't a rant or complaint, but there is an issue that regularly comes up for discussion in my company (and I am sure it does in many companies) and it tweaks me enough to feel the need to comment. That issue is the age-old question of Build vs. Buy. When you need a new system for data cleansing, or tracking shipments, or maintaining contact lists, do you buy a "turnkey" system, or do you get your developers started on a new project?

From my perspective as a software developer, I fall heavily into the "Build" camp. I am a developer and I want to develop software, not install, configure, customize and nanny software someone else wrote. On the other hand, software development is fraught with peril and the lore is littered with stories of companies spending years and millions of dollars on failed "enterprise" software projects... So if you are an exec, I can see the allure of buying a package off the shelf and it "just running".

I've noticed that when I talk to folks (in my company and others) about their buy decisions, they often say things like... "We had to have a product NOW, not in 8 months" or "We simply don't have the development staff to deal with a project this big" or "The cost of developing that software would have been to high."

How expensive is the package being considered? How fast do we have to get to market? How complex is the problem we are trying to solve? Are our developers up to the task of producing this software? Do we even have enough developers to produce the software?

Obviously, there is no single correct answer. Every case is complex. However, from years of experience watching how these decisions play out, I have come to this conclusion:

If the system you are considering is part of your core business competency, or is part of a package you want to sell or present to the public, then 9 times out of 10, you should start with the idea of building that system, and fall back on buying as a last resort. Here's why:

Turnkey Solutions Usually Aren't -- One of the big draws of buying pieces of a mission-critical solution is that you can get it up and running more quickly than if you spent the time building it. Sometimes this is true; you install the new package, do a couple quick configuration tweaks and it is producing worthwhile results.

Unfortunately, more often than not the story is install the package, do a couple of quick configuration tweaks, have problems with the security settings on your network, do some more tweaks, call customer support, they blame Microsoft, call Microsoft, they blame the software vendor, post on a forum, retweak the configuration, things seem to be working, but the results aren't as useful as you originally thought, now you have to customize the package, in some goofy proprietary scripting language, why couldn't they just allowed you to write a C# assembly, oh well, customization is done, results are good, users are complaining that system is slow, do some profiling, it is the package's weird batching system, call software vendor, they send consultant out...

Whether you build or buy, there is almost never instant gratification in the software world. You might balk at the idea of giving a team of developers 4 months to deliver a piece of functionality that you need today, but keep in mind that most off-the-shelf packages require lots of setup, configuration, and often outright customization before they can deliver useful results. I call this the "hidden work" of buying, because while you might meticulously track the time your developers take to build in-house solutions, few companies give the same level of scrutiny to the fact that Bob from the data team spent 6 months playing nursemaid to that QuikSolv package you bought expecting instant results.

Obviously, if there's hidden work associated with turning the key on your spiffy new solution, there must also be hidden costs. Whether it is the $250/hour consulting you have to purchase to get the solution customized enough to work in your environment, ongoing support costs, or the fact that years later, your Senior Developer still has to babysit the thing when it is at peak load, you're going to pay a heck of a lot more than sticker price for packages you buy.

You Are Buying What Someone Else Needs -- Another thing to consider when buying a software package is that you are just one customer out of many and your co-customers have different needs than you. You are splitting the development costs with these co-customers, but you are also splitting the development resources and paying for features that they need, but you don't.

In my experience, this is evidenced in two main ways. The first is the "Everything to Everyone" package. You just needed a sleek, web-based grid, so your company purchases "Ulti-Grid" based on a demo page and a quick trial. Once you start digging deeper into Ulti-Grid, you realize that it has this horrible, 100-page API and a host of features you will never use... and that ultimately make the features you will use more fragile. Whereas you just needed a web-based, grid with some shift/ctrl click capabilities, you got the titanic AJAX-enabled, super-scripty, WPF, WCF and WTF-capable grid from Hell.

Oh yeah, and when they update the package, all of your code breaks :P

The other issue is when you need support, or a hotfix, or would just like to see a set of features implemented, you aren't at the top of the queue. To be fair, most companies are pretty good at handling critical issues quickly when dealing with production systems, but if you find an issue during development, especially if it is a subtle issue, or is performance-related as opposed to just an outright exception... good luck.

Even Worse, You Aren't Buying What You Need -- If buying a package that has too many features doesn't bother you, then how do you feel about buying a package that fails to meet your needs? Software development is often a moving target. The business' needs change and our understanding of the problem changes. When that happens, don't be surprised if your plug and play package is all of a sudden lacking key features needed to integrate it with the rest of the system and then you are stuck waiting for a new feature release, adding complexity to the parts of the software you ARE building, and/or customizing the package... which is great business for the $250/hr consultants, but stinks for you.

Sometimes You Need To Know How To Make a Wheel -- The old saying goes, "Don't reinvent the wheel." Obviously, there are a lot of cases where this makes sense. Reusing code is the prime example and purchasing a package as opposed to building one is just another form of code reuse.

However, Jeff Atwood had an interesting take on this on his blog which was, "Don't reinvent the wheel unless you want to learn about wheels." To me, this makes a lot of sense, even in a cost and time-conscious business environment, there are skills and techniques your programmers need to have and they can't get those skills by taking classes, or reading, or implementing someone else's solution -- they need to build software. So if you want your software to have a nicer UI, you better start letting your developers build UI. If you want better data processing, you should give them a chance to build the data process and so on.

The decision to build or buy a piece of software is hard and it is often much easier for a non-technical manager to understand the benefits of buying a package (and the risks of building) as opposed to the converse. Do I believe you should build everything? No -- there truly isn't enough time or money to build every component in a large software project. However, the next time your company is faced with this decision, I hope that the hidden pitfalls of "buy" are exposed and "build" gets a fair shake.