Poorman’s Multiplayer IF

I’ve been thinking lately about the problem of multiplayer IF. Since I am not aware of any tools that handle this already, I’m forced to consider ways to kludge a faux-multiplayer out of existing structures.

Solution: Build a single player game with the ability to add NPCs that you control. At key moments, particularly when outcomes are interdependent on both your moves and the NPC’s, you choose the NPC’s actions also. Both players download the same client and coordinate their moves somehow (text messages, chat room, IM, whatever). At those key moves, you’ll get an encoded sync string and share it with the other player. The string contains all the essential variables for the moves you made that affect the other player’s world (you got the silver key, talked to the troll, unlocked the musty treasure chest, etc) and skips the things that are irrelevant (you examined the brass door, tried opening the jar of baby dragon food, etc).

You could even personalize your character, RPG style, and share a character string that encoded all your character’s possessions, stats, and traits; and depending on the kind of game, your personal preferences (eg, my character is hetero female, no in-game flirting or violence allowed) to delimit the choices the other player can take against your character. A checksum could verify that the other person entered your character string faithfully.

Here’s how this addresses some problems of multiplayer.

  • Disconnections. If you are forced to wait for the other player’s every move, you can always proceed and choose an action for the other player. Also prevents trolls from going AFK just to annoy you.
  • Lag. For the most part, the only lag is the difference in reading speed between the players.
  • Game lobbies. This would be handled by whatever communication platform the players choose.
  • Policing unsavory online social behavior. The players can only interact within the game in ways that are predesigned. Any personal communication in the chat room or IM is outside the game’s scope.

Here are problems that are created:

  • Humans are responsible for syncing the two clients. If one player forgets, or misses the other player’s sync request, the game state of the two clients will diverge. It may be necessary to enforce a sync code exchange before certain events, eg, you can’t enter the room with the drawbridge without imputing a code (which would indicate whether the other player lowered it). Could also implement a checksum to make sure the other player entered your code; you can’t proceed until they acknowledge they’ve got your latest moves.
  • Codes would have to be verified. If game states can be changed by entering a code, you’d have to prevent players from simply using the codes without doing the work. The game would have to say, “Wait, the NPC can’t have got the crown yet. The king is alive and the brass door is locked, and the NPC is still in the starting room.” Sure, you could still game a system like that by entering the codes at the proper time, but it wouldn’t be significantly easier than just playing the game.
  • Random numbers would either have to be pregenerated or predictive, or shared in an encoded format so players don’t get to simply send the code for the desired die roll.

A possible solution for this is designing an NPC that can be autonomous or controlled - if nobody is logged in to play the role of another character, the game continues to run. I’ve always thought an interesting game (perhaps non-IF) could be designed where each player believes they are the hero defeating enemies, but the enemies are actually another player thinking they are the hero and seeing other players as enemies or NPCs.

Though it was a total simulation and not multiplayer, The Baker of Shireton kind of mimicked this - the player is controlling what would otherwise be an NPC in a MMORPG and “breaking” out of the prescribed roles and actions.

I’m actually working on a game that plays more with this type of concept.

1 Like

This is certainly one solution. It would cause a divergence in the NPC and the other player, so there might need to be a “catch-up” code to resync the absent player to the automated NPC’s choices.

“Sorry, I was in the bathroom. What did my guy do?”

“Here’s a code showing your current state.”


Boom, caught up.

Turn-based adventure? Could be something.

It’s not cool to plan and organize online game just to breeze through it in 20 minutes. The game has to be big.

The players are responsible for planning and organizing their sessions. That really limits the reach. But you don’t have to police players if they are organizing their own sessions, they’re friends already.

Lag is not a big problem: it’s not a graphical game, so 200ms is nothing. Even a whole second to wait after a click is kinda fine. Regular multiplayer in IF is much easier than in 2D.

Cheats are not a problem ever. If a player is educated and motivated enough to reverse-engineer the dir rolls and encode their own save, just let them do it.

1 Like

Two systems to look at:




I disagree on these three points.

  1. While gamers always prefer that games be bigger and more filled with content, the notion that a free game written by a volunteer must be the size of a professional MMO, or nothing at all, is silly. Yes, more the better. Yes, players should be able to feel invested in their characters. Still, it has to begin somewhere. If it is popular, it can grow (and gain more volunteer devs).

  2. The biggest lag issue is, as I said, a difference in reading speed. Unless the game consists mostly of bright, color-coded combat feedback lines (eg, “You swing at the orc and hit for 6 damage!”) then some people are going to read faster than others. You’ll be waiting on the slowest reader, all the time.

That’s why I propose not a true multiplayer but an intertwined pair of mostly-independent narratives. The players get to the wizard’s tower, and they each choose a different way to break in. They split up. Each one has a number of independent moves on his own path. Then they meet up again, briefly. Maybe one has to raise the drawbridge for the other, or steal the key and drop it down to the other. Maybe one gets captured the other has to rescue him. It keeps the interactivity low so there isn’t much need to keep the two clients synced.

  1. For the most part, I agree; at a certain level if someone is going to cheat, you just have to say, “Yes, well done.” However, polite MUD/MUCK design is based on consent, and there shouldn’t be systems that let one player control all the outcomes for another player against their will.

In the two-client system this abuse should be impossible. If my machine is set to “no permadeath” (as an example) then there should be nothing you can do on your client to make that happen on mine. You could make it happen on yours but then our game states diverge.

Aren’t MUDs - Multi-User Dungeons - basically multiplayer IF already? You’d merely need to de-emphasize combat mechanics, which many MUDs are all about, and you’d have it.

MU* are set up for asynchronous player activity. One player can make 10 moves while the other makes 3. That’s a problem most IF engines don’t need to handle.

Also, MU* requires setting up a server, which I don’t really care to do.

1 Like

TADS 3 has networking capabilities that you could build a multiplayer system on top of - although no one else has done this yet so it would be a considerable amount of work.

1 Like

That seems like a stunning amount of work, and would probably still require a server.

I’m going to proceed with a two-client solution and see if it works well enough to go on with.

I’m getting the impression of playing chess by email. Xrisk also comes to mind. To make something work synchronously with players not all in the same room seems like the road to madness.

Nothing so tedious, I hope. It depends on how the plot for the two leads is constructed.

If the plot is like Sense and Sensibility then it would be like playing chess by email. Marianne and Elinor Dashwood are rarely apart and everything they do is highly interdependent: they attend the same party, Marianne spies Willoughby and makes a scene; Elinor forces her to withdraw. That would create a lot of choices that must be synced.

On the other hand, if the plot is structured more like Pride and Prejudice, the two characters of Elizabeth and Jane Bennet act separately for much of the plot. Jane goes to London to find Bingley; while Lizzy flirts with Wickham. Elizabeth is invited to Rosings while Jane stays home. Periodically, they exchange letters to update each other on their progress, and only occasionally are they making meaningful and interdependent choices together in the same room.

Edit: Also consider the paths of Luke and Leia in Return of the Jedi. Separately, they enter Jabba’s palace to rescue Han Solo. Luke fights the bad guys around the Sarlacc pit and Leia takes care of Jabba the Hutt inside the Sail Barge. They meet (briefly) to escape the barge, swinging on a cable. Then Luke goes to Dagobah to see Yoda, and Leia goes to the fleet to plan the attack. They meet briefly again as they scout around on Endor. Then Leia is taken by the Ewoks and Luke tries to find her; they meet again in the Ewok village. Then Luke goes to redeem Vader and fight the Emperor while Leia fights the ground army with a tribe of Ewoks. Their stories are intertwined but not continuously so.

As an example of the kind of story that could be generated with a system like this:

Players 1 and 2 are told of a caravan that is about to go through bandit country near the lair of an evil warlock. In the caravan is an important maguffin, which needs to be kept safe without drawing any attention to it.

The players are each given several options: join the caravan as a guard; protect the caravan with magic; track the caravan at a safe distance; scout ahead; rob the caravan; join the caravan in secret; or try to pull some kind of swindle on the leader. Each of these paths is pretty independent of the other up until the moment when the bandits attack. At that point the players exchange a coded string indicating what each one has been up to, and has done, in order to produce a result.

Sometimes a player will be captured, or cursed, or one is framed for the attack; maybe one goes on the run, or has to rescue the other. The point is, they’re separated again until the next link-up and sync-up meeting. Their stories intertwine like the snakes on a caduceus.

Interesting. Somewhat limited, but still offering a lot of scope. The greatest drawback is that someone would have to craft distinct arcs for each player - you can’t have both go through one.

1 Like

Yes. For this reason I think Twine is the proper platform for this; it would be easier to give the players roughly equal amounts of content in their paths.

It would also be possible to craft paths to different tastes. One action, the other stealth; one heroic, the other devious. I could see a Regency romance with different paths for gentleman and lady; or a mystery with different paths for detective and suspect. Heck, they could be in different languages.

I’ve built a preliminary method in Twine to create a single-player split screen for two separate POVs (single player mode, where you control both characters), which can be toggled to a non-split screen with 1 POV (two-player mode, where you still control both but only see one).

1 Like