Imagine an RPG run with a thousand players. We will tackle the creation of a 'Massive RPG', or MRPG. Our goal is to run something akin to a tabletop RPG or LARP, encouraging an open-ended goal and interaction system, but with many participants.

LARP, RPG, ARG, MMORPG, CRPG

In gaming today, thousands of players can co-game in a MMORPG (Massive Multiplayer Online RPG) or in an ARG (Alternate Reality Game). Yet most LARPs (Live Action RPG) can scarcely break a hundred players, and tabletop RPGs still remain in the 2 to 12 player range.

When experiments of super-massive RPGs are done (as may be attempted at this year's PAX by Technomancer Press), they tend to mimic CRPGs. The CRPG stance is that 'RPG' means 'character levels up', and possibly (if an advanced CRPG), 'character can also go shopping'.

MMORPGs, ARGs, and CRPGs typically operate using pre-designed puzzles solved using iconic elements presented within the game universe. MMORPGs and CRPGs have one GM: the computer program. Combat and other interactions use deterministic mechanics that rigidly define their usage and scope. There's not so much drawing outside of the lines in these games.

RPGs, in converse, often thrive on non-linear solutions advocated by a player in discussion with the group. Further, they emphasize character emotional state as much as quantifiable success. This sort of RPGing is better due to-- not broken by-- the unplanned, the unexpected, and the unscripted.

Defining a MRPG

First, we can consider the difference between 'tabletop RPG' and 'LARP' to be akin to a spectrum, ranging from 'play by IRC' where all communication is pure text, through to conventional tabletop (spoken word plus handouts) down to full immersion LARPs (say, fantasy in a real castle with boffer 'steel'). They all share a common root: you are not wholly who you are, and the place you are standing is more than the sum of what your 5 senses indicate.

Our MRPG therefore can be anywhere on the spectrum from tabletop to full immersion, but by necessity will require greater physical space to place all the participants. In practice, it will be more LARP-like; the more details handled by the setting, the less work and handling required by the GM(s) managing the scenario.

Within our MRPG, we try to create an 'environmental intelligence'. RPGs have a setting that consists of "everything except the PCs"-- here, setting means staging, props, NPCs, effects, and physical space.

This setting requires a large degree of internal consistence because it is (unlike the real world) oriented towards a purpose (either the Plot or simply the Climax), and the setting is responsive to non-physical cues, generating feedback based on PC (not player) actions.

So besides 'the grass is slippery and it's hard to run', you have 'and there is fake gunfire coming towards you'. Besides 'Joe the NPC is tall', you have 'and he has an aura and will be telling you important information'. The setting must therefore be, in effect, intelligent: able to respond to non-physical stuff and give appropriate game-related feedback.

Since staging and props only go so far (even a fully immersive 'object-oriented' environment has limits), RPGs and LARPs already rely on NPCs (or GM fiat from outside/4th wall) to provide the feedback. So for our MRPG, the environmental intelligence is only as great as the project management can manage.

Roles Needed

Our goal of a MRPG will, by necessity, require more than one GM. There are three primary roles needed:

1. 'The Management', the project manager for the event.
2. 'Floor GMs', who adjudicate rules and special cases during game runtime.
3. 'NPCs' (Non-player characters), a variety of scripted and improvised roles used to better establish the setting and further the plots in the game to enhance the player experiences.

Within a small tabletop RPG, one person fulfils all 3 roles. They manage and adjudicate the overall game, adapt the scenario in concert with the players, and verbalize any necessary NPCs to flesh out the game.

As games scale larger, more people are required to fill these roles. Typically the over-arcing 'GM' takes on a pure project manager role, leaving the actual runtime dealing with the players to the floor GMs (who act outside of the game) and NPCs (who act inside the game).

Since you're using a large number of staff handling an even larger number of players, you run into scaling issues and team management issues. This is where drawing from professional domains used to scaling issues becomes relevant. MRPGs operate according to concepts also used in parallel computing and business operations.

Scaling

Tabletop RPGs and (most) LARPs require more GMs to handle more players. So our MRPG will need to figure out how many GMs are needed for our desired player base. To do this, we need to look at how our overall game is structured.

Large-scale LARPs such as the Camarilla tackle scaling by using Chapters. Each Chapter runs an encapsulated sub-game within a larger arc, at about the size of a normal LARP crowd. Between games, the results of each subgame can be interpreted by a central command, with the implications then disbursed to each subgroup. This is a very parallel approach; each game runs independently but its results are fed back into the larger system.

To truly run a single concurrent MRPG, though, you need to be able to run the entire large group simultaneously. So even if the game structure is broken into separate parallel subgames, the subgames have to be able to exchange information and interact in real time, within the game, in the absence of a central 'deciding committee'.

So, the system has to be self-managing. We are proposing a system where there is a top-level command structure ('the Management', possibly a team) using an array of field agents (the 'floor GMs') to manage the actual contact with the players. So we will steal an effective system that exists now for differentiating the high level strategic plan and goal-setting, with the actual field engagement and tactical decisions necessary.

The MRPG is best run like a military campaign. The Management is the command structure and provides planning, then oversees coordination among the field units. The floor GMs are sergeants running field units with complete autonomy scoped only by the restrictions in their orders and the rules of engagement (the game rules).

This breaks a common problem with many RPGs: the egotism of the creators. For an MRPG to work, the creator has to be willing to distance themselves from the actual runtime, and to completely trust in the many full empowered NPCs to do their job correctly. In fact, I would go so far as to suggest an effective MRPG should have the game creation staff entirely separate from the actual runtime staff, perhaps reachable (at best) via cell phone if clarifications become necessary.

Put more simply, once the game runtime starts, it is out of the hands of the creator and the top-level GMs. The game that emerges is entirely the product of players interacting with each other and with NPCs under the minimal oversight of a small number of well-briefed and empowered floor GMs

More People = More Noise

But why do I argue that you need to find your minimum staff, then not go past that? Why not just build a village of a thousand NPCs and toss a thousand players in instead? Besides simply cost effectiveness-- running the most players with the least staff-- there are problems large groups show that small groups do not.

Having determined our necessary staff size and the maximum player base they can support, we have to go beyond simple rules handling into how large groups deal with monolithic goals and plots. First, we have the Mob effect, where enough people together actually act as a Hive mind and do things that none of the individuals, taken alone, would do. Enough floor GMs interacting with each other-- instead of the players-- can create a new 'groupthink' that forces a non-player-driven game direction.

The converse would be, oh, the Hoover Dam, or the Egyptian pyramid builders. Such well-organized 'hive efforts' can do amazing things, but the overall intelligence of the hive isn't increased; the efficiency comes from a few already-intelligent individuals directing others. Since we'd prefer the 'hive' to be mostly players, this again argues that only a handful of floor GMs and NPCs are needed to ensure the game keeps going.

For such large projects, the 'agreement on mission goals and the success criteria' is pretty darn clear. Essentially, issues like morale become more important than efficient communications for large hive groups. High morale allows for inefficient or even lossy communications. If morale is low, fear/slavery can also suffice (but one could suspect that intelligent hive workers may not function well under such a system).

If only the Management provides feedback, it's serial. If NPCs provide feedback too (by their existence), it's parallel. And parallel stuff runs into the organization issues and fundamental limits given above, to wit:

1. needs organization (e.g. a hive is well organized)
2. needs morale
3. the more NPCs, the more we reach diminishing returns on their ability to provide effective feedback

I would add that more NPCs also increases the noise, by providing (even at best, mildly conflicting feedback, and thus more NPCs does not make for a better game-focused environment, even as it boosts 'realism'.

How Many Staff?

This is an inherent limit on the power of a parallel computing system. Amdahl's Law is that the speedup for parallelism is:

speedup = 1/(s + p/N), s = serial parts, p=parallel parts

So an s/p of 50%/50% would mean a maximum speedup of 2 for large N. At 10%/90%, this still gives a limit of 1/10%, or about a max speedup of 10. With N=48 -> speedup of 8.42 and N=1048 -> speedup of 9.9. So you quickly find that just throwing in more 'processors' past a certain point does not improve matters significantly.

Now, oddly enough, this is very similar to the "Mythical Man Month"'s take on how adding people to a project, at a certain point, actually increases the time it will take to finish (i.e. more people does not always add to productivity).

In an MRPG, each 'processor' is really a subgame- that section of the game being overseen by a floor GM with or without additional NPCs. So the heartening lesson from two different fields is that we can predict what sort of GM-to-player ratio is required to run our MRPG.

Figuring out the exact ratio requires actually running an MRPG. In LARP, a figure of 1 GM to 10 players is often bandied as a useful number, but boffer-style and others with self-encoded or object oriented systems (that run in real time with little interpretation or adjudication necessary) do run with more players per GM.

In team sports, in the military, in marching bands, in many contexts, a typical squad size is roughly a dozen, give or take half a dozen. If we take a single floor GM as covering a game area sufficient for a dozen players, our thousand-player game requires 83 floor GMs. And those 83 probably need 7 'advanced floor GMs' to help with communications. So we're back at a 1-to-10 run, but with the mess of having to coordinate among 100 field GMs.

Again, the issue is which parts are parallelized, and which are serial. You do need 1 GM for every 10 players that are doing the same thing at the same time: running around, conspiring, fighting each other. But you only need 1 GM for any areas that are serial-- that can only be experienced by one or a handful of players at a time. Locations like oracles, libraries, exploding engines; these are serial.

So instead of adopting the conventional RPG and LARP measurement of GM-per-player, the MRPG will need to define the necessary GMs per 'action', where an action is defined as, e.g.:

• a specific challenge, e.g. a repair situation, a bomb, a locked door
• an information source, e.g. an NPC, an oracle, a library
• a potential for large-scale player-player interaction (GM as crowd control and adjudicator)
• a plot-heavy NPC (who may be able to self-adjudicate)
• a macguffin (object coveted/needed within the game)
• et cetera

In essence, a MRPG uses a zone coverage, not a man-to-man coverage. So the top-level command staff, before a given scenario, need to survey the game terrain and define the action points that have the potential to involve many players straying beyond the basic rules system. Then, they need just add a sprinkling of floating floor GMs to handle 'the unexpected'.

This results in a drastically reduced need for manpower. You are no longer managing players directly, but managing game elements. And it was these game elements which we defined as necessary to provide the environmental intelligence for the players.

So we are back to our simply plan: the players create the game, we just provide the setting. Once you are free of the need to enforce plot, script, or goals on the runtime portion of the game, staffing and GMing becomes zone-based and greatly minimized.

Runtime

In order for a MRPG team to be effective, then, it needs to:

1. have a handful of leaders who are unified
2. have sufficient 'worker bees' to provide 'environmental intelligence',

3. ensure the worker bees have high morale and are reasonably well informed (adequate preparation and adequate communication)

We must get into the role of GMs. Breaking the fourth wall to directly introduce feedback, unfortunately, not only negatively effects the morale of the worker bees/NPCs ("gee, why are we here, then?") but also is a very inefficient process because one-on-one mentoring distracts from overall leadership. The needs of the one suddenly take precedence over the needs of the many.

What is needed in MRPGs is a more military-style organization, with high level officers (GMs) making the high level plans, then assigning Sergeant NPCs to handle the other NPCs. The Management does not actually act directly on the game, rather, they observe and then inform Sergeants of necessary changes, and let the Sergeants manage the NPCs to do this.

This requires more trust than most game writers are willing to give. To empower the run-time crew, and to not be able to tinker with "their" own game, is tricky. The advantage is it maximizes the ability to do parallel things by structuring the people into small groups, instead of the usual "GMs, plus NPC mob".

It also requires a different style of GMing. The top level GMs would, at most, issue strategic instructions like 'the game is stuck at a puzzle, please clear', then let the Sergeant floor GM or NPC decide how to resolve it. Goals and plots are no longer the responsibility of the Management or floor GMs. Their only role becomes ensuring that players are able to effectively remain in character and that artificial impediments due to the fact that RPGs are not fully simulating reality are cleared.

And, the flaw here is, in the absence of a strategic goal, the floor GMs could likely do the usual milling around and self-interaction that usually happens in games, much as soldiers not specifically on duty tend to lounge about. So again the burden is on the leadership to motivate the full staff towards the goal, much as Disneyland employees are empowered and motivated towards creating 'fun'.

Boiled down, then, I believe a thousand-person RPG can be run with minimal staff so long as the following unusual steps are taken: ditch the idea of a 'script', kick out the writers at game start, and don't meddle with player-created content.

1. Game writers divorced nearly entirely from the runtime.
2. Highly motivated floor GM staff fully empowered with no meddling from on-high.
3. Effective pre-game mapping of the game setting and interaction foci to appropriately assign floor GMs.
4. Just enough NPCs for flavor.
5. Letting the game belong to the players.

Until next month,
Sandy (sandy@rpg.net)