Time Travel for Role Playing Games : The Basics

TimeTunnelThere are plenty of time travel films and TV series, Back to the Future, Looper, X-Men Days of Future Past, The Time Tunnel, Doctor Who and so on. Physics doesn’t look too kindly on most of these. The reality appears to be pretty dull so, for the sake of adventure we are going to redefine the physics. On the other hand the film and TV adventures don’t postulate time travel physics that are very helpful for producing an engaging time travel campaign. There’s too much in the way of “instant” changes from past to future, eliminating threats by getting to their past and unrestricted travel to everywhere and everywhen. This series of articles is about the mechanics that a time travel role playing game could use to make for a sound and exciting adventure.

So how would you design Time Travel physics so that it is cool to adventure through? We need a few things.

  1. Players in “the past” must be free to do anything they could normally do, including intentionally causing changes to past events.

  2. There is only one time line despite players being able to change the past.

  3. Changes do not propagate all the way through to the distant future immediately. After all the game master needs to be able to manage history changes by tracking them slowly as they propagate forward in time. We need to give the GM some real time with which to think about how such changes may play out, in small, bite size chunks of history.

  4. Changes being tracked through time need to be kept to a minimum for the GM. This means that some changes should peter out. They leave the future unchanged from some point onward because the differences being propagated merged back to the same situation after a while, just with a small set of different details in the past that ultimately make no difference. When multiple changes are being tracked, ones further in the past should propagate faster, eventually catching up with ones in the future and overriding them. That leaves fewer “change waves” for the GM to track. This also can produce some strategic opportunities for our time travelling heroes and their enemies.

  5. The tendency for changes to peter out is also important in that it allows existing future events to be slightly sticky, so they are worth shaping by characters that want things a certain way, even though changes may be made in the past to try and alter them.

  6. Similar to the changes problem you also need a way to allow characters to meet their past selves, but have some way of damping down the number of alternate copies that you can end up with from repeated travels to their own past or taking their past selves with them (like in all those Dr Who episodes with multiple versions of the Doctor helping one another out).

  7. Player’s movements through time and space need to be constrained in the same way that in a normal game they tend not to travel anywhere instantly at will. There needs to be some costs in energy and “time” taken to get from A to B in the space-time matrix (don’t you just love sci-fi jargon?).

  8. Characters in different time periods should all be able to communicate across time and “move through time” at the same speed when they are not time travelling.

So, how do we put together a time-scape that feels like “the real thing” but delivers our stated needs to allow manageable and exciting adventures? Let’s start with the basics.

Welcome to Meta Time


The above image shows time progressing from left to right, like frames of a movie. In each frame a pawn moves from one space to another leaving behind a trail of where it has been. By the time we get to the frame on the right the pawn has moved three times, leaving three arrows on the board showing the pawn’s path through space. That’s a fairly simple way of seeing time. Its a pretty normal way of thinking about it. But it doesn’t work if you introduce time travel. The pawn has to be able to shift from one frame to another, altering that frame and erasing what it used to be like and then propagating “back to the future” (I just sooo wanted to say that), and it can get terribly unclear what is going.

So lets introduce a new axis. We already have time going from left (the past) to right (the future). Now we need a vertical axis for our movie, meta time going from the top (the meta past) to the bottom (the meta future). Here is what that looks like.


Now you will notice some features of this diagram that are going to be very important for our time travelling players. First the boards marked with a blue and a red glow. The blue glows are the meta past boundary. For all intents and purposes there are no frames to be considered further left (the time axis “past”) than these. The ultimate for our local expansion of the universe would be the big bang. But the blue edge can advance through time. We will get to that in another article. The red haloes are the meta future boundary. Time in each row of meta time has not moved forward any further than the meta future boundary. There is nowhere to go further to the right. Notice that if you start at the top left frame and work your way to the bottom right you see the same sequence of events as you do when you go left to right on the bottom row. Neat, huh? Until you start time travelling that is.

So what is important about the meta future boundary, why the red glows? Well, that is the only place where time travel can begin. That may seem, to the astute, somewhat limiting to game play. However when a thing, a person, a time machine or a time travelling photon, moves backward in time from the boundary they take a piece of it with them. They contaminate the past with some of the meta future bounds. A contaminated frame is thus a place where time travel can begin and the traveller can move backward or forward from such a location and will contaminate a new frame when they do so.

Let’s take a look at what that looks like.

Postcards From The Edge


Yahoo! In Time 3 (counting left to right) and meta time 3 (counting from the top down) our intrepid pawn discovers time travel and decides to visit the past. Since frame (3,3) is on the meta future boundary that can happen there, no problem. Now, although our hero is travelling into the past (right to left) the pawn is still inexorably moving forward (or down) in meta time. So our arrow shows the pawn moving from (3,3) to (2,4) i.e. to time 3 – 1, and meta time 3 + 1. And frame (2,4) now has a red halo because it has become part of the meta future boundary, only there is stuff to the right of it. What gives?

First notice that the new boundary glow continues down and right just like the main boundary. (In another article we will see that it is going to accelerate so that it ultimately merges back with the meta future boundary). Also notice that on each row, to the left of the boundary, are a sequence of events that now include our time traveller arriving and interacting with its past self. To the right of that boundary are the elements of the old sequence of events where the pawn had moved one space and then disappeared into the past. Those empty frames are gradually being overwritten by the new boundary.

You will also notice that the past version of the pawn has been convinced to do something different to the original actions that the future version of the pawn remembers. And though there is an event in time frame (2,4), and down, of the future pawn arriving at time 2, eventually if you trace the arrow of the time jump back to its source it no longer comes from a version of history where the pawn ever time travelled in the first place. So in meta time frame (2,6) the time trajectory traces back to meta time frame (3,5) but if you look there is no pawn leaving at that time to go time travelling. The future pawn now remembers a chunk of history that doesn’t exist anywhere in the bottom row of meta time.

The bottom row of meta time, by the way, is known as the Meta Now and is as low as the time-scape extends. The meta now grows down at 1 meta second per meta second. So if a row is a meta second, and a game board is a time second, then the future boundary would be growing 1 time second per meta second. I’ll show in another article why the future boundary should grow at faster rate than that.

To properly appreciate this imagine the diagram as a movie with each frame of the movie showing a new row being added to the bottom, a new meta now. Also the past and future boundaries and contaminations should only really glow on whatever row is currently the meta now. The ones in the meta past are inert.

Another feature of the diagram is that either pawn, the past one or the future one, can now time travel from the new boundary made by the contamination. However, you will notice that the past version of the pawn is not glowing red. It should, in fact be rendered slightly differently. I will discuss that in another article when we talk about the advanced topic of Time Ghosts!

Next Article : Time Travel for Role Playing Games : Propagating Changes


2 thoughts on “Time Travel for Role Playing Games : The Basics

  1. dandare2050

    A recently released time travel RPG certainly doesn’t follow my basic advice. Its in it for a more messy but “damn the mechanics full speed ahead” sort of romp.

    One of its adventure supplements shows what great fun the game design is. I would like to take those adventures and remix them for my approach. If I do I’ll be sure to share.

    Here is the the adventure write up for “behind Enemy Times” : https://rpggeek.com/rpgitem/205266/behind-enemy-times

    And the core rule book description : https://rpggeek.com/rpgitem/205265/timewatch


  2. Pingback: Time Travel for Role Playing Games : Propagating Changes – Strange Flight

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s