Single-Player Co-Op

January 17, 2008 at 2:28 pm (Brainstorming, Game Design, Game Mechanics)

I recently discovered an amusing little flash game called Cursor*10, which was described to me as a “one-player cooperative game.”  Like many other games, you control several distinct avatars that work together to complete the game, but unlike most games, you control these avatars in sequence, rather than in parallel:  after playing out the entire game with the first cursor, you move on to the second, and watch as the first cursor moves around and does all the things you did with it.  The knowledge gained and supporting actions taken by earlier cursors are critical to winning the game with the later ones.

This is not the first time I’ve seen this idea, though I think it’s the first successful implementation I’ve played.  In a talk I heard about Sly Cooper 3 (previously mentioned in this post), it was revealed that they had tried to develop levels where you’d play several characters in the same area, one at a time, with each character able to watch the actions of the characters you’ve previously played as they repeated what you’d done.  Sadly, Sucker Punch was unable to keep the replays consistent–even with extensive measures to synch up the random number generators, things just wouldn’t play out the same way.

Cursor*10 barely scratches the surface of what could be done with this idea, and I’ve already heard speculation on various ways the concept could be extended, but the failed attempt of another game to incorporate this idea raises a red flag.  What steps should future games take to avoid a similar fate?

Accuracy of Recordings

The most obvious requirement for this to work is that the replays really need to do the same things that the player did originally.  This sounds simple, on the face of it, but has profound implications for how the game is conceptualized.  For example, if you record one avatar’s action as “attack enemy X,” and then that enemy dies before you get to that point in the replay, what do you do?  You run into a similar problem if you just try to record the player’s input; pressing a button often has different results depending on the circumstances under which it is pressed, so if those circumstances change, your re-enactment might deviate from the original.

The only practical way I can see of pulling this off is if you record all of an avatar’s actions in some “circumstance-agnostic” format.  For example, instead of recording that an avatar attacked an enemy, record that it attacked a particular area.  Instead of recording that it picked up an item, record that it grabbed at a certain location.  Instead of recording that it walked through a door, record the actual points in space it moved through.

This affects not only how you format your recordings, but also how you have to define your game mechanics.  If your recording says that the player attacked an area, rather than a particular enemy, then your game needs to allow attacks at nothing, and your engine needs to be capable of determining what (if anything) in the target area can be affected by the attack.  The abstractions required for the recording place cascading requirements on the game mechanics, the implementation, and even the user interface.

Stability of Relevance

Any game of this sort is going to demand that the player do some planning ahead in order to be effective, but there are limits to what you can expect the player to plan.  The game becomes uninteresting fairly quickly if most of the actions taken by a previous avatar cease to be relevant, so what seems to make sense in one iteration needs to mostly continue to make sense in successive iterations.

For example, suppose that the second avatar closes a door that the first avatar went through, and this prevents the first avatar from passing in the replay.  From that point on, the first avatar’s actions probably no longer make sense, because they’re happening in different locations than intended; that single change has invalildated the entire rest of the replay.

If a single aberration in the context of an action renders the rest of the replay useless, then it’s going to be very hard for the player to gain any significant benefit from the earlier avatars.  The more common and the less predictable these aberrations are, the more likely the game is going to fall into degenerate behavior.

Instead, it’s better to limit the scope of the repercussions a single change has.  In Cursor*10, if you open a box with one cursor, revealing a staircase, and then open the same box earlier with your next cursor, the first cursor still goes and clicks on the box, which no longer produces any effect.  But the first cursor does not go up the staircase, which is what normally happens when you click on one.  Going up the staircase would invalidate all the rest of that cursor’s actions; ignoring the click only invalidates the one, and the rest of the things that cursor does can still be useful.

Just as you don’t want a small change in an action’s effects to send a recording out of synch with the world, you also don’t want a small change in the environment to cause cascading changes that render previously recorded actions meaningless.  For example, suppose one avatar spends a long time attacking enemies as they come through a door, preventing them from reaching other parts of the game world.  If a later avatar can cause those enemies to take a different route–say, by distracting them, or closing the door– then all of the first avatar’s attacks are just going to hit air, wasting his effort.

Having really big repercussions for a few clear, pivotal actions might make an interesting puzzle for the player, so you don’t necessarily need to entirely eliminate these sorts of things.  If the one big gimmick of the level is, say, that the avatar doing one particular task needs to avoid stepping on the toes of all the others–that might be interesting in a limited context.  But if they’re common, or easy to do by accident, then there’s a large risk that they’ll disrupt the recordings to the extent that they become almost useless.

Basically, your game mechanics should be designed so as to tend to keep replayed actions relevant, rather than to tend to render them obsolete.

Time Limit

At some point, you need to stop playing with the first avatar and move on to the second.  In order to keep the cooperative element interesting, you probably want to play about the same length of time with every avatar–if some avatars quickly “die” or otherwise stop, then they’re only relevant to a particular subsection of the game.

As such, you probably want some kind of “time” limit, and you probably want that to be the only restriction on how long you can play (rather than having, say, a health bar).  Of course, game time doesn’t need to equate to wall time–the limit could be a certain numbers of turns just as easily as a certain number of seconds.

In the same vein, in order to facilitate easier cooperation between avatars, you probably want to keep the current time prominently displayed to the player, so he can keep track of when a certain thing from a previous avatar is going to happen–then again, there are also reasons you might want to keep the time a secret, as will be discussed towards the end of this post.

Restricted Randomness

One could potentially have a randomized level, that’s different each time you start an entirely new game.  Cursor*10 actually has some randomness (in the floor with all the boxes, the box containing the stairs is different each game).

However, you don’t want random differences between different iterations of a single game–that will tend to make it harder to plan and reduce stability.  So anything that’s random should be chosen randomly once, and then recorded, so that it will happen the same way for future avatars.

I wouldn’t recommend trying to use a pseudo-random number generator to regenerate the same numbers each time–one difference in the circumstances triggering the random numbers and everything thereafter is wrong.  Instead, I think it would be safer to explicitly record the random results in some way that associates them with the event for which they were generated (and not just by virtue of being in chronological order).  But that’s just an implementation detail.

So What Could You Do?

You could get a lot of mileage out of this idea just by constructing a larger game world or taking it into a different genre, but here are some more specific ideas of game mechanics that might be interesting in such a game:

Synchronized Actions.  For example, the classic two-button security door–you need to press both buttons at once to open it, so a single person can’t do it.  So you press one button with one avatar, and the other with a later avatar–but you need to have the first avatar give some sort of signal so that the second avatar can press it at the right time, like counting “one, two, three.”

The farther apart you place the buttons, the more difficult synchronization becomes, and the more tricks the player may need to come up with to get in synch (though there’s limits to how hard this will become, depending on how well the game clock serves as a synchronization device).  For two adjacent buttons, maybe the first avatar starts 3 steps away and advances at a regular pace.  For two distant buttons, maybe you need a third avatar to set off somd kind of widely-visible signal (like a flare, or an alarm) in order to syncrhonize the others.

Interleaved Actions.  Maybe two avatars need to cooperate in order to do a series of actions in the right order.  For example, one operates a crane to pick up and drop boxes while another operates conveyor belts to move them around.  The controls for the two machines are far apart, but you need to alternate between them in order to move things into the right configuration.

Of course, this could potentially require the player to do a lot of detailed planning in order to get it right, so be cautious how heavily you rely on it.

Temporary InterferenceIf one could arrange for the actions of an early avatar to be foiled in a very specific way–such that the recording is perfectly capable of accomplishing the action, if only a certain obstacle were removed–then the previously invalid actions of one avatar could be rendered effective by the actions of a later avatar.

For example, suppose you’re playing whack-a-mole, but the moles are so fast that they always duck out of the way when they see the hammer coming.  One avatar plays the game, and misses with every swing.  Another avatar comes along and somehow hinders the moles (blinds them, slows them, etc.) so that they can’t dodge.  This time, all of the first avatar’s hits connect–thereby triggering some other result the player needs to win the game.

The trick here is that you need to block the player’s actions after they’ve been performed–if you prevent them from being performed in the first place, then the recording won’t contain the right actions to accomplish them after the obstacle has been removed.

Distinctive Avatars.  There’s no rule that all the avatars need to be interchangeable–some could have unique abilities, forcing you to perform certain tasks with certain avatars.  Some abilities might work in conjunction with other avatars.

Replay Select Avatars.  If the game becomes long or complicated, then replaying every avatar every time could become frustrating.  Instead, one can envision allowing the player to play each avatar once, but then go back and replay a specific avatar of his choice, replacing its previous actions with a new set while keeping all the other avatars’ actions in tact–say, in order to correct specific errors only clear in retrospect.

However, this makes it much more likely that the player can invalidate the actions of other avatars.  For example, in Cursor*10, you probably had one cursor hold down the button that creates the stairs so all the other cursors could go up.  If you could replay just the cursor holding down the button, and do something else–all the actions of the other cursors no longer make sense.  So in order for this to work, either you need to eliminate this kind of dependency between avatars (a substantial restriction), or else replaying an old avatar is going to be considerably more complicated than playing a new one.

I’m looking forward to seeing all the interesting things that future games will do with this idea; it can accommodate a lot of different types of gameplay, and it has that strange flavor of a rule that’s natural and consistent while still being surprising.  I think it opens up a lot of possibilities still waiting to be explored…


1 Comment

  1. Duncan said,

    This idea is very similar to that found in the time loop sections of Shuggy (
    The game is a platformer, but during these levels, every x seconds, time loops back, and a version of your former self appears, following the actions you’ve performed up to now. The idea is you have to stay away from your former self (selves) “to stop a paradox”, and puzzles can only be solved by planning ahead (sitting on buttons or hiding in holes for you’re future self to go past successfully).

    I highly recommend this game (though it requires the XNA framework installed).

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: