If you spend time designing monster for 4e you will quickly discover that while some parts of the design are pretty standardized, like hit points and defenses, others are much more art than science. Specifically, monster abilities follow few hard and fast guidelines, and are instead something you come up with by mixing your ideas with a rough overview of the abilities of monsters at a similar level.
This is important because “combat-izing” challenges requires a similar mindset. The simple reality is every challenge will be a little bit different. In many ways, creating a challenge is more akin to creating a monster (where elements must be created from scratch) than creating an encounter (where existing elements must be arranged cleverly). This may seems like a very fine distinction, but it’s a critical one.
We’ve already got some of the most important elements of making challenges feel more like combat – tools for pacing, acting and determining victory – but those are all from the perspective of the actor (in this case, the PCs). To handle the rest of the model we need three more tools to round things out: Sequencing, Situation and Consequence.
In combat, these handled by initiative, the battle mat, and the various monster attacks and actions. Ideally, we want some equivalency with these ideas (because they’re familiar and comfortable to players) but we don’t need to adhere so closely to them that we trip ourselves up.
Sequencing is the easiest to get out of the way: initiative is a very flexible concept since it’s ultimately just the order things happen in. There are basically 3 possible models here:
1. Roll initiative as normal (possibly for each challenge element)
2. Go around the table, then the challenge acts
3. Challenge acts after each player acts.
These are pretty self explanatory, especially the fact that #3 is much more dangerous from the player’s perspective. I’m not going to dwell on this for the moment because I think this is the easiest element to handle, but may also be the most situational. If nothing else, it’s just not going to make sense until we have the rest of the model in place.
Situation, on the other hand, is pretty critical. In combat, the map serves as a passive answer to a lot of critical questions. Yes, there’s range and counting squares and stuff, but there are also broader situational things like who’s in play or what areas are threatened (and by what threats). We probably would not want a literal battlemat, but at the same time, we want to provide enough ambient information to keep things clear for the players. That suggests that a more abstract model, such as diagram mapping or a card-game model might be in order.
Lastly, consequences are probably the most nuanced of these, in part because of their role. While we’re streamlining sequencing and initiative, we’re actually _enhancing_ consequences. Combat consequences are generally limited to hit points and death. In a challenge, the consequences are far more wide ranging. Certainly, the personal health and safety of the characters may be at risk, but many challenges will threaten other things entirely. Whatever it is the challenge threatens, there needs to be a way to express it, probably through the depletion of some sort of currency (of which hit points are an example). So that introduces two issues: representing the currency at risk and then representing _how_ to threaten it (that is to say, how to damage it).
So, the next step is to break those elements out, and run through how to handle them.
1 – This is also fairly early thinking on this idea. If this gets some traction and use and there is ever a substantial body of example to reference (akin to a monster manual) then the dynamic will change, as challenges can be built out of various “problems” which have been used and documented.
2 – Statuses occupy an interesting niche here, in that they are consequences, but only in a very short term sense. They don’t get taken away from the fight, though they may have a profound impact on the ultimate outcome of the fight. Curiously, that’s more akin to a situational element – a status is not a piece of geography, but its impact on the fight is very similar. It forces decisions and drives the direction of action. I think there’s a place for statuses (and status-equivalents) in challenges, but for this reason I think it belongs under situation, not consequences. That said, games like Mouseguard have done a great job of illustrating ways to handle long term status-like effects, but that may be a bit too far out on a limb for this.
Using something more akin to combat is one of the big changes I made to skill challenges in my 4e game, and it was a big hit at the table.
There’s a few key ideas that I found there.
1. The challenge can’t feel passive; it needs to change based on what the characters do. It helps if the challenge rules have NPCs who are actively opposing the players.
2. The challenge requires the PCs to make interesting choices. Not simply whether they win, but how they win and what the consequences of their choices are.
3. The challenge needs to push the PCs out of the comfort zone of sailing through the challenge; there need to be new complications that arise.
I’m enjoying this series of articles a lot. Even though I do not play D&D, I cannot help but appreciate some fine design principles in action. By seeing things for what they really are — abstract mechanics concerned with gameplay itself, instead of “fantasy physics” — you’re able to flesh out a non-combat conflict system that really seems promising.
I’d also like to ask your permission to translate the articles from this series to portuguese. I write to a Brazilian RPG blog and one of my goals is to raise awareness towards ‘design matter’ issues. Many readers enjoyed the way FATE handles non-combat conflicts, and I think your approach of doing something similar to a more traditional game system can be quite inspiring.
@remo Absolutely feel free. And let me know in the comments when you do so I can link it!
Translated to Russian.
Link – http://mycampaigns.blogspot.com/2011/01/blog-post_23.html