d12

Combat in Runebearer

2011-11-08T07:21:00.000-08:00

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

2011-11-02T19:06:00.000-07:00

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?

2011-10-24T11:02:00.000-07:00

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?

2011-10-20T12:34:00.000-07:00

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

2010-06-23T12:42:00.000-07:00

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.

D&D 4th Edition the next great supers game?

2010-06-21T13:15:00.000-07:00

As I was chatting with a friend about the pros and cons of 4th edition D&D and how I could not possibly run a fantasy campaign with it (I will get into that later), an interesting thought struck me. Out of the box, 4th is remarkably close to a superhero game! All of the trappings are there. You have tons of powers, all of which are very mechanically similar, but with lots of status effects to differentiate them -- thereby simulating guns, lasers, claws and mutant powers with the same set of rules. With healing surges, you have very resilient characters (though you would have to find some way to activate them without a healer archetype). You have minions!

Heck, if you just renamed the classes and powers, you might be able to pass 4th Ed as written as a superhero game.

I wouldn't do that though. I think some modifications are in order to truly complete the transformation. I would likely ditch the concept of a single class/character and go for some kind of dual-spec system for a more mix and match approach to characters. So you would not be a "Fighter". You would be a Superstrong/Fire Blaster. I think this would allow more flexability and synergy in character builds. I think a slick way to handle super stats would be in order as well... not sure on that one though.

Otherwise, most of the rules would work as written. Sounds like a side project!!!

Doppelganger

2010-04-19T05:24:00.000-07:00

I have a guilty habit of occasionally Googling my name... probably a bit out of narcissism (though as I near middle-age man, I am not sure there is much left to be narcissistic about), but also due to a morbid curiosity about the intellectual debris I have left in cyberspace, especially because I generally use my real name in my posts. Indeed, there are posts and questions on technical forums and gaming forums that strike up a twinge of embarrassment today.

Now keep in mind, my name isn't all that common. There just aren't that many Magouns in the world. So, I was a little surprised to find that there is in fact another Chris Magoun out there, living out west and working in various capacities in the gaming industry.

I was amused until it dawned on me: this dude is in his 20s, is single, living in California and working as a game designer... My God, my namesake has my ideal life!!! Stranger still is the fact that at this very moment, the other Chris Magoun is writing a blog post about how his namesake, the 40-year old programmer with four kids, is dragging him down!

Or not.

But that would be pretty funny, wouldn't it?

What is Wrong with The New X-Com?

2010-04-16T09:06:00.000-07:00

Recently, 2K Games announced that they would be releasing a new X-Com game. At first, this sounds like great news. X-Com is a beloved franchise and its mix of base building and turn-based man-to-man combat has never truly been matched. Certainly, in a market filled with sports games and first-person shooters, a modern version of one of the best turn-based tactical games ever made will be an exciting release.

Except that it seems that the modernized version of the best turn-based tactical game in history would just happen to be a first person shooter!!?! Huh?

Yeah, the new XCOM game (hyphens and lower case are soooooo 1990s, or British, not sure which) will be a heavily story-drive FPS, along the lines of 2K Marin's last title, Bioshock.

Now, of course, this news tweaked the old, crotchety gamer in me and elicited the usual rants about "ruining the franchise", "dumbing down" and an old standby, "kids these days". But then I thought, "Well, Bioshock was an ok game, maybe a good game with the X-Com label, whatever the genre, will be neat."

Then I thought about X-Com Interceptor and Enforcer and threw up a little into my mouth...

Seriously though, there is nothing inherently wrong with a top-notch game maker scooping up an old franchise and reimagining it. If you think about it, the highly enjoyable hit, Borderlands, is pretty much Diablo skinned as an FPS. It is a great game because it is an FPS, written by a dev studio that specializes in FPS games, and it adds other elements that twist the formula just enough (looting and character development) to put the game over the top. So ultimately, it is ok for 2K to rethink XCOM and the result might be a pleasant surprise.

On the other hand, to those of us who know this venerable classic, the announcement of the new genre is still disappointing and part of me can't get over the fact that this seems like a cynical attempt slap a known franchise on a game that would otherwise have a hard time competing in a glutted market with the likes of Gears of War and Modern Warfare. Certainly the buzz of the licensing announcement... good and bad... cannot hurt the future sales of this game.

And the name XCOM sure beats Yet Another Shooter as far as titles go.

Perhaps someday the tables will be turned and someone will buy the rights to the name Modern Warfare and remake it as a puzzle RPG. Until then, it seems someone IS creating an honest-to-goodness remake of X-Com. Check out http://www.xenonauts.com/ and hope they make their release date of Christmas of this year.

After Action Report (PCs at War Part 3)

2010-04-08T07:25:00.000-07:00

I spent last Thursday night running through some tests on my Risk-like battle system and we ran the game the next night. How did it go?

Well, the playtest went OK. I printed out some hex paper and cut-and-pasted two sheets together to make a map of the battlefield. I grabbed some color counters from my old copy of Stellar Conquest and started moving pieces and rolling dice.

The first lesson is that if you are going to use minis, you need BIG hexes. I printed 1" and 1.5" hexes and neither of these could deal with the number of units on the board. Ultimately, I went with counters and that worked fine on a 1" hex.

I played the first 6 or so turns over and over again, trying to get a turn sequence that worked. What I came up with was this:

Alert Phase -- In my particular scenario, the defenders are unprepared for the attack and are generally undisciplined. I divided the city into zones and every turn, I rolled to alert a different zone. For each hex in the zone to be alerted, I rolled a d6. On a 3+, the hex got a unit. When all zones had rolled to be alerted (after about 4-5 turns in), the palace would alert and the King and his guards would head out to battle.
Initiative -- Both sides roll a d6 and the highest roll can move its units first.
Move/Pin -- Each side can move all of its units one hex. The advantage to having initiative is that if you are in a hex with an enemy, or move into an enemy hex, you can choose to pin that enemy stack and they would be unable to move that turn.
Combat -- Any contested hex has a combat round. The combat is resolved in a Risk-like fashion. Each side gets a number of dice and then you compare dice highest to lowest. Maximum number of casualties in a round is 2.
Reinforcements -- If your side is eligible for reinforcements, you roll a number of d6 and on a 4+, you get a unit. For instance, if the allied forces attack through the main gate, they would be eligible for 4 dice and up to 4 new units each turn.

PCs could move and resolve an encounter any time during stages 2-4. Thus, they could wait and see how things progressed before moving, or they could preempt the larger units and move first. Each hex, I would also roll on a random encounter chart to see if they encountered anything "special" during the battle.

Thinking about it now, I think that pinning is a little too powerful, since a single unit can pin a whole stack. Also, there is a tendency for the forces to blob up a little too much. The most effective tactic would be to gather your forces into a single hex and just pound through your opponents' separate stacks. I think both of these issues could be tweaked out with a few small changes.

Friday's game, I have to admit being a little hesitant about my system, but decided to go with it in any case. The players decided to attack the harbor and the allied forces took two stacks -- one went straight toward the palace and the other protected the flank and the way back to the harbor.

The PCs traveled ahead of the flank protecting stack and hunted lone enemy patrols, each patrol we played a little battle using the Pathfinder rules. To scale the battles, I determined that the first enemy unit would be 1d4+2 enemies and that each additional unit would add 1d6 to that number. The PCs stuck to lone units (remember the enemies were alerting piecemeal) and moved from hex to hex, killing them... but using valuable spells and healing bursts in the process.

One thing that I like about this simple mini-game is that it does produce interesting situations. In our battle, the main force heading to the palace got stalled and bogged down, forcing the players to consider how best to support that stack and protect it from being overwhelmed.

Ultimately, the King and his cohort stormed out of the palace and forced the allied forces to pull back and regroup before throwing everyone into an epic final battle. We broke up before resolving that battle and we will resolve it next session in a giant Pathfinder battle...

Enemy Force

Admetus the Corrupt -- 4th level fighter, riding a chariot drawn by 2 Shadow Hounds
2x Commander -- 2nd level fighter
Commander -- 2nd level mage
46 troops

Allied Force

5 PCs
Peter -- 2nd level cleric
Orc Commander -- 3rd level fighter
55 troops

We are playing this man-to-man scale... should be fun.

Ultimately, I was happy with how it went. I think the weakest part was the individual encounters had by the PCs. The fights with the patrols were quick, but not very compelling and not enough interesting random encounters really appeared.

I do think the overall system is worthwhile as an easy way to put characters in a war situation without having it overwhelm the game. I will put together a copy of the rules and post them soon.

Where D&D Meets Risk (PCs at War Part 2)

2010-04-01T11:03:00.000-07:00

Yesterday, I talked about the difficulties of putting PCs in the middle of a larger battle. I have such a situation coming up during this week's game and ideally, I'd like to give the players the feel that they are part of a large, chaotic battle involving hundreds of combatants, but still keep the game focussed on their characters.

This is not necessarily an easy task. My Pathfinder players are not interested in a wargame scenario and I am not excited about a "Covert Ops" scenario. I am hoping that somewhere in the middle of those two ideas is the right solution.

What I intend to try is to merge the concept of a super-light, Risk-style boardgame with a string of encounters for the PCs. So, this gives the players an idea of how the battle is progressing, where they are in relation to the fighting and where they are in relation to the major NPCs in the scenario. However, the underlying mechanics of the battle at large will be highly abstracted and the game will play out just like a series of encounters in a module.

As I write that, it strikes me as either a very cool idea, or a horrible failure waiting to happen... So, onto some specifics.

The map of the battlefield will be divided into 16 hexes. The allied forces can enter the board at one of three spaces, each one having certain advantages and disadvantages and each one requiring different levels of PC intervention. For instance:

Main Gate -- Requires PCs to sneak into town, have an encounter with the gate guards and open the gate for the main force. This approach is the best from the standpoint of getting the most troops on the board quickly, but is farthest from the main goal, the Palace.
Scale the Wall -- Requires PCs to fight a "Protect the Ladders" encounter with guards on the wall. This approach puts the allies in a tough starting position, but is very close to the Palace.
Sea Approach -- Requires no PC intervention, and puts a number of allied troops on the board, but also alerts the enemy and gives them the ability to react to the allies very early.

Each turn, both forces place reinforcement units and move units on the board one hex. All special units and the PCs (which are represented by a single figure) can then move. The PCs draw or roll a random encounter and resolve it and then all other combat is resolved.

The random encounters are the meat of the scenario. They are based on whether the PCs are in allied, enemy or contested territory and they have the potential to change the disposition of the battle by adding or removing units from the map. PCs might ambush an enemy patrol and thus remove a unit from the board, or they might come across civilians willing to take up arms against the corrupt king, adding an allied unit.

I am going to write up encounters this evening and do a quick run through to see how it works out. Unfortunately, I have given myself only a single night to determine how this is going to play. We'll see...

When The Caissons Go Rolling Along (PCs at war)

2010-03-31T10:30:00.000-07:00

In my Friday Pathfinder game, my PCs are working with a group of priests and mercenaries to liberate a small island from the clutches of its evil and corrupted king. The culmination of this part of the campaign is going to be the battle for the main city on the island and hopefully the destruction of the Cannibal King, Admetus.

It certainly looks like it is going to be a great conclusion to the opening storyline in my new campaign. I am excited and I think the players are as well. Not only are they going to participate in a huge battle, but the outcome will determine the fate of an island kingdom and will have big repercussions on the game world.

For me though, episodes like this always bring up the same question: How do you deal with a party of PCs participating in the context of a larger battle?

In our Friday game, there will be hundreds of combatants fighting throughout an entire city. How do you capture the ebb and flow of such a battle? How do you make the PCs' actions central to the game, but maintain that feeling of being part of a larger conflict? Over the years, I have GMed lots of these "mass combat" sessions and I have tried many methods of bringing PCs into the midst of a large conflict. Let's talk about some of these.

Shutting Down the Generator -- I always call this the "Covert Op" or the "Special Forces Adventure". In this method, there is a huge battle raging near or around the PCs, but they are not really a part of it. Instead, they are a small group of specialists with a mission. The outcome of the battle hinges on the success of this mission, but is somehow separate from the bulk of the fighting.

So while the forces of good engage the orc menace, the PCs have to sneak through the front line and recover the Lost Sword from the Wizard's Tower. If the PCs can recover the sword, then the Orc Champion can be vanquished, otherwise the forces of good will surely lose.

The main advantage of this method is that you are just running another standard adventure. You don't need to consider the effects of the battle on the PCs' situation because the battle is merely a bit of flavor text designed to get the PCs to the real action -- the dungeon. This type of war-time scenario is easy to prepare and run and both the players and GM should be familiar with it. It's just that this time, instead of the old wizard in a tavern giving the PCs their marching orders, it is the General of the Armies of Man.

Of course, this familiarity is also the main disadvantage of this style of adventure as well. I don't know about you, but to me the whole, "trudging to Mordor to drop the One Ring into Mount Doom whilst being trailed by some homeless guy, and having my manservant cast longing glances my way" was the boring part of Lord of the Rings. Given a choice, I'd rather be at Helm's Deep fighting off hordes of orcs beside those bad-assed (and impeccably coiffed) elves.

There is something epic about a huge battle and so given the chance, I'd like to get the PCs involved directly in that battle. Avoiding the battle seems a tiny bit like a cop out, or at least a missed opportunity.

Leading the Charge (maybe) -- Another option is to put the players directly in charge of the battle by using some sort of mass combat system. You use a game like Warhammer, or Battlesystem, or you use mass combat rules tailored to your rpg of choice, or you write your own. The players split the forces of the good guys and the GM takes over the bad guys and you battle it out old-school-hex-and-counter-style.

The advantage here is that the entire battle unfolds in front of the players and their input affects the outcome directly. I've seen players get very invested in these battles, groaning when their last unit of spearmen gets routed and their carefully crafted lines begin to crumble... and cheering when their cavalry makes that decisive charge throwing the armies of the Dark Lord into disarray. These sessions can be a great change of pace from your normal, weekly rpg games.

Of course, that is also the problem. Presumably, if your players were into Warhammer, they would actually spend their evenings playing that game. Not everyone likes wargames, and in today's gaming climate, I would imagine most GMs have at least one player at their table that would be unhappy giving up their gaming night for a rousing evening of Advanced Squad Leader.

Another issue is the fact that unless your wargame of choice accounts for it, it might be hard to get the player characters involved in the battle. Few PCs in most campaigns have a lot of skills relating to the command of armies and few games account for the actions of a single individual among hundreds of soldiers. If this is the case, your players might feel cheated because their characters really aren't doing much to alter the fortunes of their allies.

And what if your players just plain suck at wargames...?

String of Encounters -- Many years ago, a British gaming mag published a set of light rpg rules and adventures for those rules. I remember that at least two of these adventures had some sort of mass combat aspect. To resolve these combats, they used something they called the "Quick and Dirty" method.

Essentially, the Q&D method consisted of drawing cards, or rolling dice and consulting a table of random encounters. In the course of the overall battle, PCs would come across these situations and play them out, one after the other. Based on the outcome of each scene, players would earn points moving them closer to that final, climactic outcome, or they would lose points, bringing them to the brink of defeat.

The beauty of this method is that it is as simple to prepare and run as the covert op, but it gives the players more of a feel of being part of a larger battle because in this method, the battle is the dungeon.

The key here is writing good, compelling encounters. Each encounter card not only has to give the PCs a task, but it also has to give them the feel for the conflict of which they are a part. Think of all the misery and chaos that would fill site of a battle. Your PCs would stumble onto ongoing battles between their forces and the enemy. They would save civilians from a burning house. They might come across looters, or injured soldiers, confused and looking for their unit.

In general, this is a nice method, because it is easy to prep, it stays firmly on the rpg side of gaming and keeps the PCs as the center of attention. However, you still aren't representing the battle in any interesting way. The battle is some blurry, abstract thing going on around the players and the individual encounters are just filler until you can get to the big bad guy at the end. There is no chance that a daring charge will break the line of orcs. There is no chance that one squad can hold a guard tower until help arrives. Unless, of course, these events are scripted into your encounter tables.

I use this method a lot to represent PCs in larger battles and it works fairly well. I recommend it. Still, there are times when I want a little clearer picture of the battlefield and the PCs' place in it.

Friday, I am going mix it up a little bit... my players don't seem interested in a wargaming night and I don't want to do the "you are on a special mission" route. So, I am going to mix a very, very light, risk-like wargame with a string of random encounters and see how that goes... I will try to publish the "rules" for this battle tomorrow.