Not every challenge needs a map (or equivalent) to work well. Often the challenge revolves around something large and amorphous which can be engaged by any character at any time. However, maps make challenges more interesting.

It’s possible that’s backwards. It may be more accurate to say that challenges with different fronts, which allow different courses of action, are more interesting, and it’s simply that those challenges also tend to want maps. But that gets enough into chicken and egg territory that I’ll stick with the simpler version: Maps are a way to make a challenge more awesome.

There are two things a map is going to do, in a purely abstract way, which drive play. A map reveals what elements of a challenge are in play at the moment, and it creates a geography of use. That is to say, if there are two seperate parts of the challenge, then that is roughly akin to there being two separate “rooms” for characters to enter, depending upon which part they wish to engage.

Implicit in both of these is the idea that there’s more than one element to a challenge. Mechanically, the GM has used the SP pool to buy one ore more problems (what I’ll call these sub-challenges) to harass the players. It’s important to be aware that the GM rarely _has_ to buy problems to run a challenge, but doing so keeps the challenge from being too abstract.

To illustrate all these ideas, let’s use a ship passing through dangerous waters. This is easy to model as a challenge – the ship has hit points which the storm attacks, player actions try to run out or weather the storm. However, this is kind of a dull challenge on its face. The level of engagement is kind of abstract, and when played at a high level, the fact that there’s no sailing skill (or equivalent) in 4e introduces a lot of skill confusion. If we want to make this a more exciting challenge, we want to make the actions more diverse and personal.

So, let’s say I take the SP I budgeted for that storm and I start dividing it off into problems. Thinking about it, there are three big issues on the ship: navigation, keeping the rigging intact, and manning the bilges. Right off the bat, I could use those to create three “zones” where players would need to choose to array themselves (The rigging, the wheel and the hold), so they can attack the problem tied to that area. From the players perspective, this calls for an allocation of resources because even if the rules for moving between zones are simple (change zones instead of making an attack against the challenge) you don’t want to waste time on that when things get tense.

From the GM’s perspective, this allows me to threaten different things in different ways. For example, let’s assume I’m designing the problem that the navigators are facing the same way I would a monster. Sure, it’s got a basic attack (storms buffet the ship, do some damage) but I can also give it other attacks that threaten other things. How about a rechargeable “Waves smash over the side of the ship” attack that threatens the players directly rather than the ship? Does some damage and forces them to spend some time (an important resource) tying themselves down, something that may cause complications later. With that, the guys manning the wheel and trying to keep the ship on course have concrete things to do and deal with which are anything but abstract.

That illustrates the separation that the map allows, but there’s also the element of the reveal. In my game, each of these “zones” would be represented by an index card or post-it for players to put their minis near to indicate where they are. After they’ve beaten one of them, I would then place another note on the table: “The Sea Monster” (because I love the classics).[1]

As GM, I know this sea monster has always been part of the challenge, but if I’d laid it out with the other problems at the outset, it would have changed the nature of the scene into “Fight, and also this other stuff”. By breaking the challenge into problems, I can control the sequencing, and only after the players are already invested in this “other stuff” to I roll out the monster, so that they’re facing a very real choice between keeping the ship safe from the storm and keeping the people on the ship safe from the thing grabbing people off the deck.

Obviously, you can get much more sophisticated than this illustration. A challenge might have lots and lots of small problems, with the problems scattered around the map or coming in waves, but the basic structure is easy to achieve.

Implicitly, problems also end up simplifying the issue of initiative. If problems act on their turn, like monsters, then multiple problems means multiple actions. This spares us needing to do any initiative tricks to maintain a sense of pacing, since that will just happen organically.

Now, I want to reiterate that not every challenge needs a map – the trap from yesterday, for example, can do fine without one – but if you expect the challenge to be large and engaging, then building ti as a map of problems is going to make things a lot more engaging than just build one big lump of trouble.

1 – Conceptually, you might also think of the challenge as a dungeon. It opens with doors into 3 rooms (Navigation, rigging and bilge) which all exit onto the large “sea monster” room, which you get to by beating the “monster” in the room you went through. You could, if you particularly like the idea, build entire challenges as abstract dungeons (because dungeon is just another word for flowchart).