Words on a Screen #30: Not All Those Who Wander Are Lost


Words on a Screen

Introduction

Sometimes, the PCs will want to move from one location to another. Sometimes those two locations will be far enough apart that the questions of how the PCs move between them, what that move costs in terms of time and resources, and what might happen on the way need to be addressed. (I'm sure it's these kinds of deep revelations that keep readers coming back over 30 issues.)

It's worth discussing the circumstances under which the journey should be played out in-character and how handle those scenes.

Do we need the travel scene?

A travel scene is only worth playing out if it's worth playing out. That sounds tautological (and technically it is) but the point of the statement is to provoke some analysis by the group as to whether the travel scene is worth playing out.

Just because it's the next chronological step in whatever the group is doing doesn't necessarily mean that it deserves table time. Don't reflexively play out a journey just because it's the next thing. Skip it if it doesn't have independent value.

Notwithstanding the fact that a travel scene is - by our definition - an interstitial scene between two interesting locations, there are sometimes good reasons to play out such scenes. Let's survey some of the more common:

  • It's genre- or game-significant. This is what I like to think of as the old-school wandering monster exception. Some games and genres anticipate and/or have particular rules for travel scenes and without running such scenes occasionally, the players will be missing out on an important aspect of the game or genre experience. In this case, include such scenes often enough to check that important box, but don't overdo it.
  • Worldbuilding/traveloguing. In a game focused on exploring a setting or telling a tale about moving through a world, travel scenes take on a different significance.
  • Character spotlight. If a player has invested character resources into being good at traveling or resolving the mechanical challenges connected to traveling, be sure to give them a chance to show off and justify that investment. After all, if you weren't going to give them that chance, you should have warned them off from that investment during character creation.
  • Downtime from the plot. There may be times when significant scenes and events are coming at your players so fast that they're missing the chance for quieter character beats. Travel scenes can be good for giving the PCs some room to breathe and interact with one another or adjacent NPCs outside the pressures of whatever is happening in the game's main plot.

Travel scene best practices.

The primary driver of how to handle the travel scene is the purpose for which the scene is being played out. As discussed in the previous section, skipping travel scenes should be the default, with travel scenes only played out in the event that there are one or more specific reasons for doing so. That reason (or those reasons) therefore form the focus and inform the tone of the scene. In other words, start by designing the scene to do the thing that you're running the scene to do.

Next, viciously truncate the scene once its purpose is served. A travel scene outside of a travelogue-style game always feels a little bit like filler. A little bit of filler is fine, but the scene is liable to start dragging (and thereby costing the game momentum) quickly.

Finally, engage in out-of-character dialogue with your players about all of the above. This can be as simple as the GM asking "Does anybody have something they want to do on the way from the docks to the castle?" or a player asking "Any chance of us running into some wild animals on the way? Speak with Animals is burning a hole in my pocket." If a travel scene is happening, everyone at the electronic table should know why and work toward fulfilling the goal of the scene.

Recent Discussions

ERROR!
URL: https://forum.rpg.net/api/forums/172/threads/
POST: 1{ "errors": [ { "code": "missing_scope", "message": "This request requires access to the following scope: node:read", "params": { "scope": "node:read" } } ] }