The End of Runebearer (or at least the website)

Over the weekend, I let the Runebearer site expire. At this stage, no one is interested in Runebearer, but for the people who are already playing Runebearer... and I know almost all of those folks. So, instead of leaving the site open and thinking about how I really ought to be updating it on a regular basis, I decided to drop it. All of the files I am editing are in a Dropbox folder, and most everyone who needs the files can get to them.

I might work on getting the files (or links to them) up on this blog, but then I would have to kick myself monthly about not updating this (largely unread) blog... and I would be back to square one. For now, I think I will just lay the game to rest until a better idea comes to me.

I Hate My Gaming Group

A buddy of mine sent this to me... it is a repost of a blog entry I wrote a few years ago. Still makes me chuckle:

I am fortunate in that I have a regular stable of people with which I play online games. It isn't really a large enough crowd to be a guild or clan, but anywhere between 3-6 guys/women get on Teamspeak several nights a week and we get together and share our latest game... which is great. The only problem is that in the past several months, I have come to realize that I hate my gaming group.

See, recently things have not been so smooth for my gaming crowd. There have been moves, new jobs, family engagements -- the normal comings and goings of 30-40 somethings that interfere with gaming. No big deal there... we are all pretty busy, everyone has a reasonably demanding job, two of the guys are family men and those that aren't have active social schedules. I get it: real life >> gaming life.

What bugs me is this: Every so often the stars align and everyone puts the kids to bed/ditches the wife/takes the evening off or otherwise clears their schedule, grabs a drink, dons the headphones and fires up their computer. This might happen once a week or so and when it does...

We don't play together.

Have you ever "gone to lunch" with a group of friends only to find that it is 1:30pm and the only conclusion you have reached is that there are 13 restaurants within driving distance and someone in the car can find a reason to dislike every single one of them? Our Teamspeak sessions are THAT car.

L: "Let's play CoH. We all still have CoH accounts and I have another Fire/Kin I am dying to level."

C: "Umm... I let my CoH account expire."

L: "Aw.. why'd you do that?"

C: "Well, we have played CoH for years now. It's boring. And anyways, you guys have essentially
beaten the game right. I don't really want to tag along while you four-box your team of plant/storm controllers. It's not fun anymore."

L: "I only three-box."

C: "Nonetheless... let's do something else. What about WoW? I would love to dust off my WoW account and actually level my warlock."

L: "I could do that."

J: "Ugh... I HATE WoW!! The graphics suck!! Literally, they make me nauseous."

C: "Dude, who cares about the graphics? The gameplay is what counts."

J: "The art style is so cartoony... I can't stand it."

C: "That art style is deliberately designed to look like a Warcraft game. Haven't you ever played Warcraft?"

J: "And those hideous Popeye forearms... ugh... I just threw up a little in my mouth."

C: "Ok, ok... no WoW. What then?"

S: "LORTO just came out with a new expansion... I could show you guys around."

B: "How can you like that game? It feels nothing like Middle Earth."

S: "Yeah, but it's a good PvE game. Don't think of it as Middle Earth. Think of it as an MMO without shoes."

J: "I suppose the graphics are ok on that one."

B: "If you'd have read the copy of the Silmarillion I lent you..."

C: "Ok... no LORTO!!!"

S: "Huh, why not?"

C: "I have a rule: once someone mentions the Silmarillion, the argument is over... It's a lot like Hitler that way."

D: "How about EQ2? I used to have an account there."

C: "Oh I don't know. I played EQ2 at launch and frankly it was a little dull. The crafting was a pain and you had to grind 10 levels before you could even play an interesting class."

D: "Yeah, but I've played more recently than that. A lot of that crap has changed. They have really improved the game these past years."

L: "Please,  'Come back and play... the devs have really improooved the game with patch 80398-B'... If I had a quarter for every time I'd heard that..."

C: "You still wouldn't have enough to pay the monthly fee for all of your CoX accounts."

L: "Good point."

S: "Isn't EQ2 a Sony game?"

D: "How about Vanguard then?"

S: "Sony game."

B: "Are you still on about Sony and SWG?"

S: "I WILL NEVER FORGIVE THEM FOR WHAT THEY DID TO MY BEAST TAMER!!!"

(uncomfortable silence)

C: "Well... how about we try some free to plays? No risk there... just download and play."

L: "Yuck... You have fun with your Korean grind-fests. I am going to run through some player-created content on CoX."

C: "Would that be RitkiFarm#341 or CouncilSlaughter#418?"

L: "No way, my new farm is called StatesmanIsMyBitchNow. The XP flows like..."

C: "Lube?"

L: "I was going to say 'butter', but whatever."

D: "I don't even think Statesman is with CoX anymore. Isn't that guy off making Champions Online?"
(All in unision.. and with awe): "Oooooh, Champions Online."

S: "I'm really excited for Champions Online."

C: "Me too."

D: "Comes out soon, I think."

J: "I am looking at the website now. Look at those awesome graphics -- just like it was straight out of a cartoon!"

C: "Umm... what is the difference between 'cartoony' and 'straight out of a cartoon?'"

J: "Huh?"

C: "Forget it."

B: "I hope it comes out on XBox."

C: "What? Why?"

B: "My computer won't run Champs Online... no way. So they better release this thing on XBox or else Statesman will have nerfed me again."

C: "Dude..."

B: "What?"

C: "I don't think they are guaranteeing cross-platform gaming. So, even if Champs Online is the only game we can all agree on, and we all go buy it together... you STILL might not be able to play with us. You should go out and buy a new computer."

B: "No way I am buying a machine just to run a stupid game!"

C: "You just bought an XBox."

J: (obviously changing the subject) "Why don't we all try the trial for DDO?"

(laughter ensues and we all log off for the night)

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.

Turns Out I Hate The Skill Guy

3rd Edition D&D, including 3.5 and its successor Pathfinder is pretty clear on how it deliniates the focus of a character. Ignoring specific class features, each class relies on a specific part of the game mechanics to define its role in an adventuring party. For instance, fighters have the best Base Attack Bonus and are the "Feat" class; mages and clerics are the "Spell" classes and rogues are the "Skill" class.

At first glance, this seems reasonable. Of course fighters have the most options in combat. Of course, wizards and priests solve problems with spells. And of course, when it comes time to pick a lock or disarm a trap, you are going to rely on the skills of the thief. Makes sense -- each class has a role and gives up some other important abilities to excel in its role.

But, over the years, I could never shake the idea that there was something inherently wrong with this mechanical split. The first thing that struck me was the fact that if the rogue was the "Skill Guy", there wasn't much room for anyone else in the party to have skills. At 2 skill points per level (plus intelligence bonus, of course), once you take spellcraft and maybe knowledge: arcane, there isn't much room for the wizened wizard who wants to be a history buff. Priests have it even worse, since they likely won't have INT as a primary stat. Because the rogue's niche is skills, the other classes just don't have enough skill points to go around, leaving wizards and clerics among the most uneducated characters in the game.

Then there is the concept of "class skills" which seriously limit which skills can be reasonably taken. The fighter’s class skills are climb, craft, handle animal, intimidate, jump, ride, and swim. You can take other skills, of course, but only at a penalty... and as noted before, skill points are already at a premium. Good luck if you want to be a warrior who is also a diplomat.

Certainly multiclassing helps with this situation, but it too comes with its share of pitfalls. In the case of mages and clerics, taking a level of rogue for the skill points makes no sense at all. Stylistically, it does not work for many characters and mechanically, the spellcasting level is inifitely more valuable than 8 skill points... especially when you take into account that many of the rogue's skills can be made obsolete with the proper choice of spells.

But still, your party probably needs a rogue, if only to gather information and deal with trapped chests and locked doors. And let's say your party is heading into an adventure littered with stuff for the rogue to do. There are NPCs with which to negotiate. There are traps to disarm and locks to pick. There are dangerous dungeon corridors with lots of listen checks and stealthy scouting...

All of which is a lot of action for the rogue. In the meantime, everyone else sits aound and probably waits for a blundered stealth check to thrust them into combat.

I call it the Netrunner Syndrome. When cyberpunk games were popular, almost all of them had a fairly detailed set of rules for hacking virtual reality computers. Netrunning was almost its own minigame, complete with skills, gear and mechanics. It was all very cool... for the player who was playing the netrunner. Everyone else's character sat around waiting for JimmyL33t to either return from his solo adventure with the ciritcal piece of data, or for his head to explode into jelly. Either way, all but one player was bored.

Scouting and other rogue duties aren't as bad as netrunning, but they can come close. When it is the rogue bartering and the rogue scouting ahead and the rogue listening at doors and the rogue disarming the traps and the rogue searching the room... it can get boring for the other five people at the table.

So after running Pathfinder for a few months, it turns out I hate the "skill guy" as a class concept. What would happen if we got rid of the rogue (and probably ranger) class, gave everyone something like 5-6 skill points each level and got rid of the idea of class skills. Class features for rogues would become feats (possibly with a limitation on the armor worn). That way, everyone would have part of the "skill guy" job. Mages and clerics could take many of the skills and knowledges they really ought to have. Scouting, stealth, negotiation and trap duties could be more evenly distributed among the PCs in a party and those wanting to be sneaky, fast killers could still do so by taking the proper feats.

Would a rogue-less Pathfinder game work? I'm not sure, but I may certainly try it.