The Experiment

5 Minute MMORPG tries to re-contextualize one of the most frustrating and notorious elements of online gameplay – lag – to make it fun and engaging. Admittedly, the lag is only "simulated," but this also makes it more predictable and easier to deal with. The experiment asks whether a simple re-framing – a game that advertises its lag ahead of time – is enough to change player expectations and experience.

Simulated lag raises tricky but interesting design issues. New challenges arise in multiplayer games in which client and server store different representations of the same world. In precise terms: in 5 Minute MMORPG the server time cannot be mapped one-to-one with the client time (the physical time in which the player actually operates). We believe this kind of intentional server time-manipulation is pretty darn cool (or at least potentially).

An example will help explain. Assume that five players remain in the game, and that the input delay is five seconds. A player dies, leaving four players and a shorter delay of four seconds. A period of one second (five minus four) has consequently vanished from the server timeline. Because the delay has suddenly changed, the future actions that were to be carried out over the following second are all simultaneously acknowledged by the server. In server time, the one second experienced in the physical world has collapsed down to one instant. The result is that the client will see the avatars jump/teleport.

Now, consider the opposite case, in which a player joins the game (not possible in the current build) and the delay increases by one second. In server time, all actions that were about to be carried out over the following second now have to wait an additional second. As a result, all avatars will freeze for one second; because that one second never occurred in the physical world, players never even had the opportunity to register any input during that second.

Actually, these issues are exacerbated by the fact that avatar speed changes along with delay. Whenever the lag changes, the player's possible future – which they will have already specified by guiding their ghost – will be invalidated; it will turn out that the ghost had been moving at the previous speed rather than the new one. In other words, there arises the potential for the client and the server to become out-of-sync.

And because the game cannot predict when players will join or leave the game, the system cannot possibly predict when these lag changes will happen.

As Dr. Emmett Brown would say: "Great Scott!"

Of course, these kinds of server time issues already occur in most online games. It explain why lag feels "jumpy." The difference is that because the lag is our game is simulated, we can predict and control the consequences.

When we first encountered these issues, our server-centric thinking led us to assume that the server would need to somehow "correct" the clients. One possible solution is to suddenly shift the trail of ghosts (the possible future) to reflect the new future.

However, we decided that this was not a satisfying solution. For instance, your path could suddenly be changed, placing your trajectory into an opponent’s trap. Because this lag change happens frequently and outside of the player’s control, the path-changing solution frustrates players, and compromised the strategic play of the early game.

As for figuring out how to sync the "real" avatar and the player’s ghost, the trick for us was to realize that the server could give the client back some autonomy – the server could try its best to make each player’s planned future come true. Specifically, the server only changes the speed of the avatars after it waits the old delay amount of time. In other words, the server doesn’t change the lag immediately, but instead waits for the avatar to travel the remainder of its current specified future. The speed of the ghost, however, changes immediately to reflect the coming change. In this way, the rendered possible future path is always "correct" as long as the avatar isn't killed in transit. If the player is killed, their possible future path vanishes as their avatar explodes.

This solution feels more correct, partly because the difference between delays is typically much smaller than one second. In the heat of battle, it becomes difficult to even detect when those changes happen. But we do think such a server time/client time mapping could be used to interesting affect in future games, especially if different players had different degrees of lag.

As for the server timeline collapsing when the lag decreases, our solution was to ignore user input for the duration of the collapse (the difference between the new delay and the old delay). In other words, freeze input in order to allow the avatar to catch up to (or at least gain some ground on) its ghost. As long as input is ignored only for the length of the collapse, the "real" avatar will continue moving smoothly through the input freeze (remember, that window of time doesn’t exist in server time); only the ghost freezes. Again, this solution is possible because we can predict the durations of the delays.

This solution is far less noticeable then the alternative (a sudden jump in avatar movement), largely because the duration of a collapse is quite small. However, there are rare cases in which the user tries to attack or defend right within that small window, leading to confusion as to why their avatar failed to act. As a result, we would eventually like to signal this non-input window visually.

Finally, we should note that the game pushes players to adopt new modes of (or metaphors for) problem-solving. There are two major ways to conceptualize the simulated lag mechanic. First, one can think of the ghost (the semi-transparent trail of avatars that represents the delayed, yet-to-be acknowledged actions) as the present, and the rest of the game as reflecting the past. Alternatively, one can think of the ghost as moving in the future (or rather, a possible future), while the rest of the game reflects the present. Of course, it all depends on your frame of reference – client or server.

New players often focus on controlling the ghost. In other words, new players generally conceptualize the game via the first metaphor (ghost is present, world is past). This is hardly surprising, because in most games we control an avatar or set of avatars in real-time. The problem is, the player must take into account the other players’ avatars, and realize that those avatars represent the world as it was some number of seconds ago.

We have observed that, as players become more comfortable with the game, they learn to devote more attention to the state of the world as is, thinking of their ghost more peripherally, as a plan rather than as current reality. Successful players tend to adopt the second metaphor (ghost is future, world is present). This metaphor also makes more sense, because it easier to conceptualize a possible future, rather than a "possible present" (remember, the future plans you make may not actually come true if you’re killed along the way).

Well, that was a mouthful, wasn't it? The game is fun. Give it a try.