Managing the actors in a multi-player game

I am currently dabbling with some ideas for a new game and would like some feedback.

This is my first multi-player game. At this stage, I envisage four player characters. Let’s call them A, B, C and D. You start the game as A and must gather players B, C and D to join your team. You can GET <character> to join the team and DROP <character> to have them leave the team. When you move around, any players in the team automatically follow you.

You can order the other players to do things. For example:

  • and so on

You can CHANGE TO <character> or BECOME <character> at any time to become one of the other characters. Here’s where things start to become awkward. If you start the game as A and get B, C and D to follow you, what happens when you change to B? Do A, C and D then start following you or do they get left behind unless you re-gather them?

There are two possibilities here:

  • When the player gets a character, that character joins the team and the team stays together unless the current player explicitly drops a character from the team or the player leaves the team (effectively dropping everyone in the team, but the others in the team presumably stay together). In some cases, the player will need to leave the team automatically. For example, if the player climbs up a tree, the other characters are left behind on the ground. When the player climbs back down the tree, it would be nice for them to automatically regroup as a team. (This approach would require a Boolean to indicate whether or not a character is in the team.)

  • When the player gets a character to join the team, that character follows the player, not the whole team. In this way, if A gets B, C and D, then B, C and D are following A. If you change to B and B walks off, then A, C and D are left behind, as they aren’t following B. This can also get a bit messy. If B gets C, then you now have two teams consisting of A and D, and B and C, although this may be exactly what you want. (This approach would require a property to indicate which character each character is following.)

Maybe I need a combination of the two approaches.

Each character has their own strengths and weaknesses, so you may need to become a particular character to solve a particular puzzle. There are situations where the team needs to be split up. The first is where a character has to solve a puzzle by themselves in a location that the others can’t get to (such as the tree example above). The other is where a puzzle needs to be solved cooperatively with two characters in different locations.

I want to make the game as simple to play as possible, but I’m struggling with the best way to automatically manage the team. Are there any suggestions or any examples of other games where this has been done?


Suspended style? SENSA, GO TO CIRCLE CHAMBER then wait as she heads there, one room per turn, and when she gets there, you are notified. I wouldn’t recommend FOLLOW…


No, ‘Suspended’ is very different. The player is immobilised and you spend the whole game controlling other characters (the robots) and they behave somewhat autonomously. The player never actually changes character.

A search for MPC (multiple player characters) on CASA revealed 34 games. The majority of these are from the 80s and 90s, but I don’t know whether any of them do what I’m talking about. The only modern games are ‘The Lost Planet’ by @8bitAG and a couple of the Barry Basic games by @dee_cooke, but these are different to what I’m talking about. Maybe this concept hasn’t been done before, but I’m sure it has.


Exactly, but apart from the fact that the player is immobilised and can change characters wherever, the way they narrate and act is directly as if you (as the cryogenic person) aren’t there. All you have to change is that you can only swap characters with somebody in the same room as you.

1 Like

there’s the classical “two split-party proceeding along separate path/dungeon” puzzles seen in CRPG, often with cooperation (and swapping back and forth) between the splitted parts of the party.

let’s take an example of implementing split-party in a parser environment.

A and B splits from C and D and the AB party is in the great hall, and the CD party is in the left switchroom (that is, the classical “pressing the button/pushing the lever contemporary from separate rooms” puzzle) and the player currently is C:

now he switches to A:

become A (or whatever is the out-of-world command for swapping between PCs)

now the AB part goes along its path, solving some puzzles, of course, ending in the right switchroom and the player, as A (or B) gloriously press the button, pull the lever, turn the dial, whatever activates the daemon whose check the (pseudo) simultaneity then the player:

become C (or D)

and C or D press/pull/turn whatever prior to the expiring of the simultaneousty daemon, puzzle SOLVED, [your score raises by X point], fanfare, whatever gratifies the player :slight_smile:

of course, there can be variations for example, giving orders to the inactive party thru a radio, communicator, interphone, whatever…

the general mechanism seems roughly feasible, perhaps a tad :wink: more on TADS3 than Inform 7/10 but Inform library’s NPC handling is more than powerful and flexible enough for implementing this handling mechanism.

Best regards from Italy,
dott. Piergiorgio.


I probably should have said that I’m using Inform 6 (but using the PunyInform library, which doesn’t support any of this by default) and I’ve already implemented this and it all works quite well. The only thing I’m concerned about is the group dynamics, specifically the manual and automatic joining and breaking away from the group.


Quickly digressing… there’s some variety in approaches in that list on CASA as well.

The simplest examples of MPC just involve basically moving between what are intrinsically two different adventures taking place to different main characters, with their own inventories, in different places. You switch between two characters at will but there’s not much overlap in game worlds; although there is often a mechanic to pass items from one character’s adventure to the other, or do things as one character that affects the adventure for the other. The simpler games on the list like Desmond and Gertrude and The Lost Planet are like that.

Having different skills for each character isn’t unusual and do help give a reason for having multiple player characters in the same game space in the first place. Sometimes the whole following and party system is pretty automatic, such as in The Lord of the Rings Game One (one of the earliest examples). In those sorts of games your party members follow you along and can carry stuff for you. Often you’ll need to utilise their separate skills but becoming each character isn’t strictly necessary. The other characters are almost like tools in an inventory in these cases; and indeed that’s one way to implement things in simplistic writing systems. (I’ve even seen games where you GET and DROP other playable/NPC characters from your inventory… edit: I see this is similar to how you’ve got your system working)

Some of the examples are more complex. In Mark Cantrell’s 1988 PAWed opus Diablo! unless you tell them to follow you, the characters all move around independently and you can control each one. I can’t recall if the characters have different abilities but you definitely needed to keep two alive to solve certain puzzles. The problem with having independent characters is that they can run off and get themselves killed leaving the game unwinnable (which was a frequent problem in the Hobbit). There’s a lot of instruction characters with COME and STAY in Diablo.

In The Famous Five the character’s skills (such as Timmy’s ability to dig; although you can’t control him directly) and their personal inventories come into play a lot more. You can become different characters in that game but just as easily tell them to do things as well. Like in The Lord of the Rings, the characters follow whoever you are controlling automatically. You split them up by telling them to go somewhere, for example TELL ANNE GO SOUTH. If I remember correctly, Anne will remain in that location until the character your controlling meets up with her. After that she will start to follow the party again. If you didn’t want your character Julian to be in the “party”, you could say TELL ANNE GO SOUTH and TELL DICK GO SOUTH then BECOME ANNE to basically have control of Anne with Dick following along (and Julian left in the original location). It’s a little cumbersome, but the way it works is at least clear and consistent.

I’m not sure I’ve got any really decent solutions to the main issue you’ve identified here… that managing the actors, especially if you want multiple parties at any one time, is actually always going to be pretty cumbersome. I think you just have to clearly define whichever system you choose so the player understands how it works.

[Edit: I took so long writing my reply that I forgot your initial post! So re-reading it (after I posted this!) I can see that you’re doing the actual party-forming differently. Rather than edit this extensively I still think the comments below apply, but would need to be tweaked slightly for your system.]

What is the most elegant way to do things if you don’t want automatic following? I guess maybe the command PARTY WITH or GROUP WITH might be best? Even with the party system, I think I’d go for the approach that the party automatically stays together when you move, regardless of which of the characters in it you control. It saves a lot of faffing about with FOLLOWs and STAYs.

So if you BECOME A, as that character you can type PARTY WITH B AND C [if they are present] and then it is listed as “You are now travelling in a party with B and C.”. They will automatically move when you do so. If you BECOME B then B will still be part of that previously defined party (“You are in a party with A and C”) and all the other members will automatically now follow what you’re doing as B. You could LEAVE PARTY to split up. One options would be to have A and C continue to be paired together. Or maybe it would be better that the game responds by disbanding the party completely.

(For a two word parser I’d probably go for a very simplistic FORM PARTY, which just groups together any characters present, and LEAVE PARTY which splits up the entire group. Or go for the Famous Five approach).

The tree situation? I agree that if character A climbed the tree (and B and C are unable to follow for whatever reason) then it would be nice if you rejoined the party automatically when you climbed down. But what happens to B and C in the meantime? Do B and C remain in their party group below? What happens if a player is up the tree and then swaps to BECOME B? I guess consistency is the key. So thinking of another similar example, if you’re in a group and you’re crossing a rickety bridge, which breaks, this might leave A on one side and B and C stranded on the other side. Do you keep B and C partied up then? What about if there’s a boat that will only fit two characters. If a party of A, B and C try to get in the boat does it stop the entire party in its tracks with an “only two” message?


Ignoring all that waffle above… which doesn’t really respond appropriately to your initial post… Maybe just keep things simple. If you switch characters, by BECOMing another one, then the party automatically breaks (with a clear message on screen) and would need to be reformed from the point of view of the new character. If you’re just GET and DROPping party members anyway, it’s not going to take too much time.

If you go up the tree then for consistency, just make the character have to GET the party members when he/she/they comes down again.


Thank you. This is very helpful. I think you understand what I’m on about. At the moment, I’m using the following commands for joining and leaving the group (plus some synonyms):

  • GET <character> (character follows the player)
  • FOLLOW <character> (player follows the character)
  • DROP <character> (character follows no one)
  • STOP FOLLOWING <character> (player follows no one)

As a general rule, the group sticks together unless you explicitly drop someone from the group, then they’re on their own. I perceive some issues, as I haven’t tested all possible scenarios yet. I’m not even sure what those scenarios are.


This seems like the best approach to me - by default I’d think the player would want to keep the group together to minimize the amount of potential backtracking when they realize they need person X to deal with obstacle 1. But if they drop someone from the party, presumably they’re intending to leave that person behind.

I do think an equivalent command to DROP ALL that stops all other characters from following the player would be useful for situations where you need one character to go off alone - maybe DROP PARTY or something like that?


I don’t work with I6, so my I7 suggestions are just observational and may not line up.

It shouldn’t be hard to make actions RECRUIT and DISMISS as synonyms for GET [PERSON] and DROP [PERSON].

This is totally wacky, but I would probably come up with some weird scheme like making a group conceptually a type of invisible open vehicle (again I7 so may not apply) so the player and NPCs could “enter” the group-as-vehicle and then as the player in control “drives” (in a vehicle you can just type NORTH as you would on foot) and everything in the vehicle travels along. For an NPC group they have their own separate party/vehicle that moves around elsewhere on the map or off-stage and completes their quest steps alone or the npc vehicle becomes “drivable” if the player zaps into that “group”.

Or make a “your group” a transparent open enterable portable container that NPCs enter and the leader carries around. That way you avoid fiddly following and map-traversal mechanics for NPCs. Dropping/Leaving “my group” would take the container off-stage and leave the passengers in the location. It would also line up command-wise TAKE RALPH OUT OF GROUP.


Typical videogame norms suggest that the party stays the same, but with a new party leader. This is the most common approach seen in various genres from Platformers to RPGs. With that said, you aren’t bound to precedence. Do as you will.


While you’re a team, everything a team member sees or picks up is shared with the team.

The gameplay kicks in when the team can change leader. Each leader has abilities which favour different stores of inventory.

We seem to have accumulated a load of crafting materials. Let’s elect a Siege Engineer to dig ramparts and build watch towers. When that’s all finished we’re back to Ha Ha drunken Pirates again.

It’s a similar thing to World of Warships where different classes of vessel are best served by Commanders with particular traits.

1 Like

Thanks for all the feedback so far. There have been some interesting ideas, I must say.

I have come up with a very simple and elegant solution that seems to be working. I have defined two Boolean variables called leader and follower. At the start of the game, all potential team members have leader. This means that anyone that is a follower will follow them. At the start of the game, no one has follower. When you get someone, they become a follower. When you drop someone, they stop becoming a follower. Got that?

When you change rooms, if the player is a leader, then all the followers follow them. If you want to temporarily stop the other characters following the leader (such as in the tree climbing scenario), then you temporarily remove the leader attribute from the player (leader = false), then give it back to them when they’re back on the ground (leader = true).

It’s harder to explain than it is to code.

I’ve also got GET FRIENDS working (to get all the characters), but DROP FRIENDS doesn’t work for some reason. I need to find a solution for that.


Perhaps you can add an UNFRIEND verb, to be used when they start posting distasteful memes and oversharing details of their personal lives.