The Megagame Control Team (Part 1)

The key part of any megagame is the group of people that facilitate the whole thing.

In some games this role is called ‘umpire’ or ‘GM’ but we tend to use the term ‘Control’.
We call them ‘Control’ because the term ‘Umpire’ tends to give the impression that they are impartial arbiters of a set of generally agreed-on rules as might be a tennis umpire or a football referee.
This might be a part of Control’s role, but the facilitation aspect of the Control function means they have a role to play in addition to this. It is especially important in megagames where often they are closed games, both in terms of ‘fog of war’ but also in that the game rules themselves are not available in their entirety to the players.

The term ‘Control’ implies some responsibility for the progress of the game – acting like a ‘control rod’ in an nuclear reactor – which moves to speed up or slow down the fission reaction. Similarly Control might make injects into the game to influence or moderate game flow.


A megagame is not a passive process, like a board game, which would typically be set up and run to a conclusion with all the player interactions being clearly defined and regulated by a set of (usually) immutable written rules.   A megagame is a more dynamic process of multi-player interaction, that might (and often does) involve the use of fixed rules to moderate some aspects of the activity – but also re-quires facilitation and interactive moderation to ensure that the maximum gain to the largest number of players. A good control team will manage this facilitation process invisibly, ensuring that they do not damage the key narratives of the game by appearing to be arbitrary.

So in a very real sense the Control team controls the game on many levels.

As a result, individual members of the Control team have a degree of leeway to develop the game themselves in their particular area. This can, and does, require some quick thinking, imagination and excellent communication skills. In some games we can even see Control developing ad-hoc rules to cover some creative idea brought up by players. This works very successfully where players come up with a wizard wheeze that is perfectly reasonable but falls outside whatever base game system the megagame is operating on. There have even been experiments with dispensing with a base game systems and mechanisms altogether and rely on Control to manage all game interactions and adjudicate results based on their judgement alone. Such ‘free kriegsspiel’ methods are risky and require a high standard of consistency between the various members of the control team, and it utterly depends on a tight, experienced, team all having very similar views on what constitutes reasonable outcomes for the narrative. Generally we have found it more reliable to have a mixed economy of a base game system with can be embellished by the Control Team as necessary – effectively like improvisation within a theme.

Team Control

It is in the operational games that Team Control – the member of the control team that interfaces between the Master Map and one particular player team – a sort of liaison role – where some of the most interesting facilitation occurs.
In games using the Player Team ↔ Team Control ↔ Master Map approach, Team Control has a great deal of responsibility for the quality of the experience of the game that their players have. It is very like the responsibility a dungeonmaster has with their group of players in a conventional role playing game.


Team Control is often also the person calculating combat results and updating the position on the main map. This is sometimes tricky, especially for those new to it because it can feel like playing a board game – in fact we identified early on the problem of Team Controls ‘going native’ and playing as if they were a partisan member of their player team. To a degree this is reasonable and to be expected, in that we expect Team Controls to be advocates for the orders the players have written – but they are neutral advocates rather than players. At the map table, the Team Control also generally takes low level decisions on behalf of the team on issues that cannot be covered in the written (or verbal) orders given by the players – this is to simulate the initiative taken by junior commanders who we imagine would be in charge of the units the players are ordering about. These low level decisions will aim to reflect their understanding of the players’ intentions (and because the Team Control spends the day communicating with the player team they generally get a good idea of what the players really want, even if they didn’t write it down with military precision (or even if they did!). This is a key example of how Team Control injects that all-important ‘colour’ to the game experience. Players are encouraged to develop their sense of the story unfolding by this sort of independent action. Their subordinate units are no longer merely counters to be pushed around a board, but begin to feel as though they are ‘real’ (or a bit more real, at least).

All this adjudication at the Master Map is usually done in conversation with the other Team Controls who might be handling ‘opposing’ units, and the discussion there will reflect an informed consensus of what is ‘really going on’ at that stage of the battle. The Control team gathered round the master map create the overall narrative of what has happened in a game turn, greatly influenced by the base rules or mechanisms but also by their own knowledge of the historical period and the boundaries of possibility.

I think it is important, however, to make sure that there is a common understanding of the philosophy underpinning the base mechanisms because this provides a sound foundation for any extemporising or judgement calls the Team Controls might need to make. Wherever possible we try to explain the thinking in separate briefings for Control – but it often helps to have a brief face-to-face session with all of the Control Team in the first half-hour of so of the game, while the players are sorting themselves out in preparation for the first game turn.
Where a situation arises that isn’t covered by a specific rule or mechanism it is easy, with experience, to quickly reach a consensus as to what had ‘really happened’.

So, Team Controls establish a rapport with their team early on – and aim tell the story of the division or corps or whatever it is the team is commanding. It is this storytelling aspect which is very important and wherever possible a report back on the outcome of the orders each turn is in the form of a ‘report from junior officers’. So a Team Control might say something like “The commander of 4th Brigade reports that his attack on the town of Kempshott went in as planned, except that the hoped-for air support from the Air Force unfortunately didn’t arrive due to a communications foul-up. The Germans put up a stiffer resistance than we expected and losses were heavy. Fortunately he was able to flank them with some of his tanks2 and eventually the enemy retreated to the east towards Tankerville. The brigade commander says his troops are very tired and worn down and probably only have enough energy for one more attack like that”. This would be in contrast to what might have actually happened at the master map, where under the game mechanisms the air support didn’t arrive because the air force player team forgot to issue an order for it that turn and the attacking brigade had a marginal victory on the combat results table and lost 3 strength points out of 8 and smaller German unit lost 1 strength point and had a forced retreat. Control will avoid using any terminology that is ‘gamey’ or abstract because we believe this detracts from the flavour of the experience and the narrative. It can be entertaining too as unusual events do crop up and can be turned into anecdotes, and control can impart some character into the non-played subordinate units if necessary. For example in this case Team Control might well role play the junior brigade commander offering his (player) commander a few choice words as to his opinion of the (absent) Air Force.

In one example the player team had a very successful operation and had captured many prisoners from a low-quality enemy unit. They asked if they could interrogate prisoners, and Team Control went into a long and boring feedback from disgruntled enemy soldiers complaining about their own high command, the poor quality of the food, how their feet hurt, how they’d had no sleep and so on. This was more colourful that “…you have captured many men from a low quality unit”. And the players didn’t spend too long asking detailed military questions of the prisoners because they (rightly) deduced that these prisoners really had nothing useful to impart.

All of this said, speed is also very important. Megagames operate to strict timetables, and all members of the Control Team have a responsibility to ensure that the game keeps up its required pace. So sometimes the time pressure means reporting back might not be the full dramatic discourse one would like. But the principles remain.

However much we try to avoid it, it is inevitable that a mistake or two will be made on the map at some point, there can sometimes be a lot to work out and the interplay of different units and orders sometimes complex – but we will not normally go back and undo results once adjudicated. To do so would undermine the narrative flow. We might explain to players if a gross error has occurred but otherwise mistakes tend to stay in the Black Box of the master map and can usually be rationalised as fog of war or the friction of command, or simply a subordinate commander making a mistake.

In general I would always recommend to Team Controls that they are honest about major errors and try to agree with the players on a post-hoc rationalisation if possible. However it can be tough on players who have actually being doing well to have their successes ruined by a Control error. With experience and practice, fortunately, this sort of error is rare.

[Next Week – Megagame Control Team (Part 2) : Game, Map, Political, Non-played Controls, plus the relationship between the Designer and the control team.]


Being Control

Megagame Control is extremely important. A poor or under-prepared Control Team is an order of magnitude more damaging to a megagame’s narrative than poor players1.

Control subtlety influences the game by ensuring the players have the right sort of information at the right time. One might think that megagame Control attracts control-freaks who like to feeling of power and the ability to say what happens. Control freaks generally make poor megagame control team members for exactly that reason. Control is a first and foremost a facilitative role – and it is important that in this role we do not lead the players or take over their game by making decisions for them or by railroading them into choices we think they should make. It is always the players’ game, not Control’s. Control’s role is to make the whole experience feel as open ended and real-world as possible and that players have the opportunity to make mistakes as well as stunning successes.


This is not to say that Control should never offer advice – it can be very important, especially where the player team is inexperienced, to offer options perhaps in the form of “advice from your junior staff”. But this must be done carefully and subtly, and in the form of several realistic and genuine choices and not just the one option you think they should be taking. Sometimes players just run out of ideas and feel stuck. This is an area where Control can really help.

If, as Control, you find yourself making decisions for the players or unable to resist the temptation to put them right when they are going wrong. Or you find yourself inevitably trying to ‘win’ against the other Team Controls at the Master Map table – then being Control might not be for you.

Another key element of the control role is to look out for player problems and this is an important part of facilitation.
Control is on particular lookout for players not getting involved, or seeming out of their depth because this might be an indication of some other game problems. In the case of Team Control it will be obvious if one of the team members is particularly passive (or reading their book / newspaper / laptop).

Lack of involvement on the part of a player might indicate one of the following:

They are feeling out of their depth. This can be a concern, especial with inexperienced or new players. Someone of the control team will do what they can to involve the player and help them with hints on how to engage, some ideas of who to talk to or hints on game-play to encourage them.

Their game role is not holding their attention. This might be a design flaw that the game designer didn’t anticipate – perhaps the role simply doesn’t have enough for a player to do or maybe that particular player finds they’re just not into being the Queen of Naples all day after all. There may or may not be a fix – sometimes its possible to re-role people on the day. Control has a role in acknowledging this and doing what is possible to re-engage the player if possible.

There is some interpersonal problem within their team or with another player or even with a member of the Control Team. These can be very tricky. Sometimes emotions run high, especially if the game is engaging people a lot or where there is a high degree of role playing. Control often has to manage this sensitively and openly, perhaps with brief time-outs. We also have to remember that we’re not relationship counsellors, however, and to some extent we expect adult and mature interpersonal behaviour from all participants and this can helpfully be made explicit, either in the game briefing or in a face to face conversation at the time.

They are having a bad day/year/life in general. Not much control can do about this! Except to acknowledge it. Sometime players in this position just like it that someone noticed that things are rough.

They are fine but had a late night last night and just need a nap. Sympathy is all Control can offer. And not too much of that.

Like so many things, preparation is important for members of the Control Team. Ideally, reading the game materials supplied by the game designer will be enough to get you started – however I always encourage members of the Control Team to get in touch in advance of the game with any queries or to ask for some explanations of any parts that are not clear or seem ambiguous. This can save a lot of time on the day, and is very helpful for the designer.


On the day, the issues Control confront will be extremely varied – no two megagame experiences are the same. Control issues I’ve seen would include:

1. Players have not read their briefings and want you to tell them how the game works on the day as they are playing. Refer them to their briefing. Of course, help where they may not have understood what they have read, but it is not helpful to do everything for them.

2. Players who do ‘decision shopping’ (see above). As time goes on you get to know players who do this regularly. However, if anyone in Control spots it, it can help to pass the word to the other members of Control, if possible.

3. Player – player personal conflicts. Sometimes people don’t get on. We don;t have the skills, time or resources to solve that. However, giving players some down time to calm down if tempers are frayed can help. As can de-roling2.

4. Player – Control conflicts. This can be tricky. If a member of the Control team has so upset players that it is getting in the way of the game, then Game Control needs to intervene. Most often these conflicts are as a result of mis-communication on both sides. Generally, briefly involving another member of Control to mediate solves the problem.

5. Unpopular game results. Players naturally hate it when things go wrong for their side. Sometimes things can go catastrophically wrong, and this will cause perfectly natural feelings of dismay or annoyance. Players can often take a ‘shoot the messenger’ approach at this point. Defeat takes very sensitive handling by Control – and it can sometimes help to point out the positives in the situation, to offer some neutral advice as to options, and sympathy. If a team has been utterly crushed then this is an issue that Game Control and/or the game designer needs to be involved in. In a good game design this possibility will have been anticipated and the game designer will have a ready a pre-prepared new command or team role for the team to renew their part in the game.

6. Pedantic rule-mongers & Optimisers. The briefings for megagames are not like board games or wargame rules. They are never written to be more than a set of guidelines. Control can find itself engaging with players who argue about the precise interpretation of the exact wording of the game briefing (usually to try and gain a technical advantage of some sort). Fortunately this kind of behaviour is rare because it lies outside the spirit of megagames. But where it does occur there needs to be some careful explanation that in the end, Control’s interpretation is what counts, regardless of a player opinion of the legalistic wording of the game briefing. The clue is often where a player asks lots of closed questions in a row in an effort to ‘catch out’ Control. Like ‘shoppers’ if this looks like its happening too much, Game Control might need to explain to the player that this is unlikely to help them get the best out of the game.

This sounds tough – why be on the Control Team at all?

All the above might look like it requires some pretty major skills to do successfully.

And to a degree this is true, but it is by no means a barrier to contributing to a megagame successfully as a member of the Control Team.


So what does it take to be a good control?  5 Features of Good Controls

1. Like to tell stories about what happens in a game – many gamers already do this. Think about the last time you described a game you have played to someone who wasn’t there. Did you give a blow by blow account of each die roll, or did you embellish it into a story of bravery, daring and genius? If the latter you have the basic narrative skills needed for control.

2. Are you a good listener? Listening, especially active listening is a skill that not everyone has practised but which everyone can learn fairly easily. If you know what I mean by ‘active listening’ then you’re there already. (See annex on Active Listening).

3. Emotional intelligence. More tricky ground here. By this I mean, in the megagame context and from the control team point of view, having some empathy for the players and their in-game problems. Again, not everyone might practice this but it is learn-able.

4. Sense of humour. Yes we’ve all got one, but it is important to be able to interact with players with a sense of the ridiculous and a sense of fun. Playfulness is also important – remember that no matter how serious the game subject, there is always a element of entertainment – people do this for fun. Constructive use of humour can also help reduce tensions for players who might be feeling that things are not going well. Mocking players, on the other hand, (tempting though it might be sometimes) is neither helpful nor constructive, and can damage their relationship with the game – especially coming from Control who have an unequal power relationship with the players.

5. Background historical or thematic knowledge. Actually this isn’t essential for every type of Control role. It is very helpful to know something before you start – though often the game briefings will contain a wealth of background information on the historical period. Political Control generally need a good working knowledge of the historical period. Team Control or Specialist Control probably less so.


Is this me?

Anyone who has been a role-playing Dungeon Master or Game Master for a while and run role-playing games has generally already practised all the core competences that are needed for a good megagame control team member. We have found that experienced role-players have a bit of a head-start over conventional mainstream wargamers when it comes to learning to be an effective member of the Control Team.

There are all sorts of reasons people give me for liking a Control role. For some it is the enjoyment they get from seeing the whole process play out and work. For others is it the interaction with players and a sense of helping them have a good time.

And being on the control team has one very big plus to it. You get the god-like ability to see and know what is going on and watch the story unfold before you. You see the drama of the player teams struggling against difficult odds, you see the full genius of that bold move that turns the course of the campaign you see the consequences of gross player incompetence. You also participate in a very central way in the act of collaborative storytelling that is a megagame, with an opportunity to be creative and imaginative within that framework.

 NEXT WEEK : Megagame Control Team (Part 1)

Briefing for megagames, what to include and why

Game Handbook

This is a collection of all the common information about the game, along the lines discussed above. It is intended to be given to all participants and the following are generally included:

  • The main assumptions underpinning how the game will go. Some of these might be very general, some very explicit. So, in an operational megagame you might give some information on what you think are the key combat assumptions – maybe that the game assumes that tanks are really ineffective in built-up areas, or that infantry attacks unsupported by artillery are very likely to fail. In a political game you might outline the limits the players are working under – for example you might explain that even though the player is playing the role of President, she might not have absolute power and will need to remember the importance of keeping the electorate happy.
  • A brief summary of the thematic background to the game – time, place, circumstances at the start of the game. If this is a lot (as it might be for an SF or Fantasy game) it can be worth creating a separate background briefing, or point to some really good material online.
  • A description of the main teams and player roles and how they are supposed to interact with each other. You might think this is obvious – and in some cases it might be, but not everyone will be as well read on the background to the megagame as you, as the designer, will be. Don’t be afraid to state the obvious.
  • The timetable for the day. This might not be in the game handbook, but you will certainly need to be clear when the day starts and how the day will be structured.
  • The timescales – how long each part of the game will take, what it represents in real life. So you might say, for example, that each ‘game turn’ represents 4 days of real time, and will take 30 minutes to resolve. Sometimes a more explicit timetable will be helpful, giving start and end times.
  • Guidance on how to play. Including the mood you want to set. This might contain cultural guidance to set the scene for the game. If there are lots of new players it might contain more general guidance on the megagame experience and what to expect.
  • Descriptions of the important game components, the game rules and those parts of the game system that the player will be expecting to interact with. This might not be all the rules, there might be separate playsheets available on the day in the case of very simple rulesets. And of course there may be special rules that only the control team know about.
  • Include a map of the venue layout so that players have a sense of where they need to go when they arrive, and where the other player teams are in the venue.


Game rules

Not every megagame shares all the game rules and mechanisms with the players, but where it does, these should be explained, ideally with worked examples.
Personally I hate writing the worked examples, but participants tell us they find them really helpful and are really essential, especially for a new game.
I will talk more about the detail of writing game mechanisms and rules another time.

Historical or Scenario Background

Personally I prefer to avoid long historical articles within the game materials, partly out of a wish to keep things simple and also to keep the situation open for players. Too much emphasis on historical prototypes can lead players to mistake the game for a re-enactment and rely too heavily on hindsight than is entirely good for them. A megagame is not a re-enactment. It is an exercise in emerging gameplay and player interaction built around a theme. The game designer sets of the pre-conditions mut has little or no control over the game narrative – that is the job of the players. So a game in an historical or very well known fictional environment does not, should not, and cannot expect to, replicate the events of history or the fictional prototype.
Sometimes a game will have a wealth of background detail that, if included in the Game Handbook would make it large and unmanageable. In the past separate briefings have been used for things like a Gazetteer of places in the game, or a summary of demographic, political and geographical data. Generally this is seen as an optional reference document – though it is worth considering whether such a briefing is necessary if it not going to be used widely in the game. Many players can become overwhelmed by too much briefing material so it is important to find a balance between accessibility and completeness.


Team Briefings

These contain information specific to the player teams. It is important to ensure that different teams have different information, perhaps a different perspective on the situation and that these perspectives are not always clear to the other teams.
So in a game about a zombie apocalypse, the Police team briefing might focus on protecting the uninfected whilst at the same time ensuring important parts of the city are not infested, whereas the National Guard are focusses on destroying zombies and are unconcerned with civilian ‘collateral’ casualties or the impact of property damage. In a megagame the tensions between team (or player) perspectives is a very important driver of player interaction.

In some cases the differences and distinctions are obvious and know to all. For example, in a megagame about World War 2 everyone would be aware that there are important idealogical differences between the USA, Nazi Germany and Soviet Russia.
In addition to something about the team or player’s attitudes and perspectives, there is often important game information to found in the team briefing.

In an operational megagame, for example this might include:

  • the detailed order of battle of the team’s forces (something that their enemy would not have in anything other than outline)
  • intelligence summary of what is known about enemy forces and their location.
  • Information on the overall command structure and how the team fits into it.
    overall instructions from High Command – the objectives of the team in the game.

In a political game it might include:

  • secret agendas – things the player team is planning that nobody knows about.
    unique information – perhaps some information on the resources or intentions of other teams
  • obvious team objectives, such as ‘get re-elected’ or ‘gain more money than another team’.
  • likes and dislikes. This is very helpful in political games, especially when they theme is not very familiar to the players. Examples: “The Communists are evil and cannot be negotiated with”. “The English can never be trusted”. “President Faart of Silvania is an old friend and a thoroughly splendid fellow”.

The content of the team or player briefing is highly dependent on the game, of course, but there are some things that are useful in all briefings:

  • Thematic background (where needed)
  • Who they are and how they got to be here.
  • Team objectives. These need to be written carefully and should be realistic and achievable. Generally have at least three objectives (more if possible) and at least one of them must be easily achievable.
  • Humour helps too if you can manage it.


Personal Briefings

In some games, individual players might have their own, personalised brief for the role they are playing. This is especially common in games with a high role-playing element. These briefings will usually have some very specialised objectives, as well as items of information known only to that one player. The principles discussed above apply here too. However, it is important when developing multiple personal briefings to make sure they are internally and externally consistent. A simple example would be if a player briefing says “Your nemesis is Professor Peabody” then Professor Peabody’s briefing should mention the fact too. Or if some key bit of information such as “You have learnt that the political activist Dave Spart is being held in Police HQ” is matched with information on Dave Spart and his whereabouts in the Police briefing. It is easy to miss these things. I have found that using tools like spreadsheets can be very useful in collating and cross-checking player briefing information, as a planning tool before writing starts.

Control Briefing

This will usually contain guidance to Control from the Game Designer on how the game is envisioned, as well as game mechanisms and rules that are opaque to the players.
In this briefing one might include

  • description of the different types of control team member with a short ‘job description’ and an outline of how they interact with players and the other control team members.
  • special rules that only control know about.
  • (where the control team is inexperienced) advice on ‘how to be control’
  • key points of pressure in the game, or areas you think might prove difficult for players with advice on how the game designer want that to be handled.
  • errata, corrections or additional explanations that didn’t make their way into the game handbook.


Victory, Defeat and Endings

One of the things that does not feature in our megagame briefings are explicit victory or win conditions.
Many people comment on the absence of victory points (or similar) from megagames.
This is a common mechanism in board games and wargames and it intended to tell people who ‘won’ at the end.

Of course with a megagame there are no winners and losers – such an idea would be absurd in a game with 100 participants all aiming to create and emerging gameplay narrative. ‘Winning’ in meaningless outside the broader framework of general objectives and role motivations. And megagames aim, to a greater or lesser extent, to contain an element of consistent real world ‘feel’. Whether that real world is 21st Century Earth or a far distant space colony of the future. And in real worlds nobody counts up the points to see who ‘won’ at the end.

As a megagame designer, the objectives go wider. The designer is creating an entertainment for an audience. How would you feel if, at the end of watching a movie, the movie theatre owner announced that the audience member in Row G, Seat 10 had ‘won the movie’ on points. Telling the majority of players in the game at the end of a day of intense, immersive gameplay that they had ‘lost’ and someone else had ‘won’ because of their arbitrary collection of victory points does not, and cannot, ever feel like any meaningful reflection of the day’s experience.  The person who ‘won the megagame’ might feel good – but what about the 99 who ‘lost’?

Of course for abstract ‘mere games’ this is not a problem, and I will write more in a later post on how all megagames that are in any way a simulation of meaningful interaction must, by definition, contain an element of role playing.

There is another, very practical objection to victory points and that is their strong encouragement of rules-based metagaming. Players look at what earns them points, rather than using their imaginations and the megagame’s context and themes to expand the narrative of the game. Meta-gaming is the enemy of good megagaming. And in any case unless the victory point schedule is exceptionally well crafted they also tend to lead to unintended outcomes – player doing things utterly inconsistent with the theme and narrative in order to maximise victory points through some loophole in the tariff. This has massive negative effects on other players. Creating a coherent and stable VP system that does not encourage aberrant behaviours is hard enough in a six-player board game – it is orders of magnitude more difficult in a 50 player megagame, even if it were desirable.

NEXT WEEK : Being Control

Time & Project Management

One of the biggest issues faced by new megagame designers (and indeed, some old megagame designers) is the project management aspect of preparing for the game.

It is easy (and common) to underestimate the time needed and for many the time pressure is exacerbated by the order in which different parts of the game are prepared. Often megagame design, development and production do not take place completely linearly – we all are capable of parallel processing things (depending on the time available). Many of us thrive on fast-approaching deadline, however, the scale and volume of preparation needed for a new megagame design will be larger than most other game-related project you may have been involved in (unless you regularly organise events like 300-player zombie LARPS). The risk of running out of time is non-trivial because it impacts on the experience of the game for the 50-100 participants eagerly looking forward to an excellent new megagame experience.dscf4834

What follows is my take of the project plan for a megagame.

Concept stage : The Game Outline.

At the point you have decided to do a megagame having an outline is really important. Megagame Makers usually look for some key design and structure elements in an outline, and that really helps subsequent stages. It also really helps to circulate the outline amongst your game designer friends (or even on the MM facebook page) for feedback. Filter the feedback for experience – many game players do not have the experience of design to offer meaningful feedback and will sometime give you ‘helpful’ advice that (consciously or unconsciously) leads you back to their favourite type of game. Listen to their thoughts and suggestions but filter them critically to see if they are relevant to your game concept. Feedback from people who have designed games, regularly run games or who play a large number of different types for games or who played in a large number of megagames can be listened to more closely. Finally other megagame designers are the most helpful to first-timers. Listen carefully to what they have to say because their experiences are directly relevant. Still filter and appraise the comments, of course – but the experience of running a megagame is still not so widespread that their thoughts and suggestions can be readily ignored.
Then – be self-critical. It might be that the feedback is negative – perhaps suggesting the game is not a megagame, or that the theme or stucture not a viable one for the megagame format. Be honest with yourself and take it on board. There may be a perfectly good game idea in there for another format (boardgame for example). It might be that the feedback means that some cherished aspect of the megagame isn’t viable. Look carefully and objectively. We all hold on to cherished ideas way beyond what is reasonable. This is fine in the small scale, but if you are asking 100 people to part with their time and money then you need to be really sure you are not merely being self-indulgent.

Concept Stage : The Game Description.

A key part of marketing and popularising your game is the game description. This is what you put on your website, or in flyers or emailed to gamers. It needs to have a description of the theme, as well as a guide to the type of game and what players can expect in terms of gameplay.

It also needs to have a list of the sorts of player roles that will be in the game, and possibly what they will be doing. This is especially important for an obscure historical, fantasy or science fiction theme where the background is not immediately recognisable. For, say, a World War Two game you might say ‘Players are military commanders at division and corps level’ – and most people will know that these players are doing wargame-type things involving moving troops around. On the other hand for a game about Venusian politics in the 23rd Century you would need to explain exactly what the Supreme Zubelgrop’s role is in the game and what she will be doing and how the roles and teams relate to each other.

Game preparation : Outline Materials.

You will, of course be wanting to playtest aspects of the game (as noted elsewhere, play testing an entire megagame is called ‘playing a megagame‘).
To do this you will be doing draft versions of the map (if there is a map) or sections of it, prototype game materials such as counters etc. and outline game briefings. This is an important stage that should not be skipped. Time spent now really helps later when you are firming up the game.
In fact for your first game it is really important to do this small scale playtesting. Many designers will extensively playtest or try out their game ideas long before announcing a game. It takes a special type of confidence to announce a game before any of the design, concept or testing stuff has been done. This can work – but it is supremely risky.dscf4967

Game preparation : Player Handbook / Guidelines

The game handbook, players’ guide– or whatever you call your core set of rules and procedures for the game is the key document for a megagame. It is possible to have rules and procedures distributed over several documents or split up into functional pieces for different players, but this is best done after the core rules have been put together. This should be done before all the player briefings and before finally producing game materials. It might be that the handbook is written then adjusted as other parts of the megagame are completed – but it really is important to have this core document and have the bulk of your rules and game structures as early as possible. This is where your Game Outline really helps to remind you what aspects of the game are important and need to be included. It is the scaffolding that the handbook is built on.

The game handbook is the key component of the game and it is vitally important that players get it at least 2 weeks before the day of the game. Although many people read their game materials on the train on the morning of the game, many others do not. Also circulating the game handbook in good time is an important psychological milestone that tells your participants that the game is real and is going to happen shortly. Do not underestimate the importance of that.

Game Preparation : Player Briefings

There can often be long and extensive briefings for teams or even individual players. Much depends on how much you like writing. If writing a lot is daunting, then restrict your briefing to one briefing per team. If you love filling out backgrounds and/or want to demonstrate your depth of knowledge of your theme, then personal briefings for each individual player can be the way to go. Do not under-estimate the time needed to write 100 personal briefings. It will take longer than you think.
The team / player briefings are important. However, they do not always need to be sent out to players ahead of the game. In many cases – especially when some key roles are vulnerable to a last-minute drop out – it makes sense to distribute personal briefings on the day.

On the other hand, team briefings can more easily be sent out earlier – often with the game handbook.

Game Preparation : Control Briefing

This contains guidance for your control team only. Leave this as late as possible to complete because this is where you collect all the errata, modifications and explanation that you may have missed in the game handbook. This needs to go out no later than a week before the main game – but ideally it should go out at the same time as the game handbook.

Game Preparation : Game Components.
The final versions of maps, counters, cards, toy soldiers, hats – whatever you are using are the last thing to be produced, and come after your game handbook and team briefings. The two weeks between sending out the game handbook and the day of the game is the Golden Time for game materials preparation. Getting the game handbook out on time is always a higher priority than anything else.dscf3394


D Minus 3 months (or more) :
1. Write the game outline and circulate for feedback.  Be prepared to abandon or mutate your project. Better early than too late.

2. Prepare initial materials and draft rules

3. Initial concept testing / playtesting.  This step is VITAL. It might lead to a re-think of step 1.

D Minus 2 months (or more)
4. Announce / Publicise the game.  Avoid doing this before the steps above. Only go to this step when you are satisfied you have a demonstrably working game.

D Minus 1 month
5. Start writing game handbook (at the latest)

D Minus 2 weeks
6. Complete and send out final version of the Game handbook.  This should be an absolute deadline.

7. Finish final versions of map, counters, game materials.  If possible take this time off work. There will always be MUCH more to do than you think.

D Minus 7 days
8. Complete and send out final version of the Control briefing.  The game design is LOCKED. Change nothing from now on.

D Minus 1 day
9. Prepare final version of gate list and player name badges.  Collect your game materials together.

10. Turn up early with the stuff.  It is all over now – there is, pactically speaking, nothing you can do to influence the game design once the players start playing.  Your work is done… And breathe.

NEXT WEEK : Megagame Briefings


5 Tips on Repeating Your Megagame

There is always a range of responses from megagame designers after their game is over.
Generally, there is an initial feeling of anticlimax – not surprisingly really, as there is a lot of work in the build up to the game, much to think about, prepare and plan for.

Then there are the anxieties before the day of the game, and the pressure to ensure it goes as well as possible on the day.
It comes as no surprise that the day after can often feel a little ‘flat’.


Then there is the response to the analysis of the critique questionnaires and post-game feedback. Generally speaking it is a good idea to give the critique sheets handed in to a friend to analyse – it can be traumatic reading through all the comments the day after. Of course, if the game is universally hailed as the best game ever, then reading the feedback will be great! But there is a tendency to concentrate on the negative and critical for some designers. This is normal, but criticism, constructive or otherwise, has to be looked in context.

Often designers experiencing the post-game come-down, especially first time designers, wonder why they went to all that trouble, work, anxiety and heartache for just one day’s gaming.
Obviously, the answer will vary from designer to designer – one or two will stop there and never do it again. Most get ‘bitten’ and do end up doing another game at some point. The most enthusiastic will be planning their second game even before the first is completed.

So, lets imagine that you do want to run your megagame again. It might be several months or even years later – what needs to be considered?

Here are some tips that might be helpful.

Tip 1: Its Not As Easy As You Might Think

Never, ever, assume that repeating a game will be necessarily easier than the first time. I realise that is counter-intuitive – but it is so often true. It is true that you don’t necessarily have to repeat the game design research. And you don’t have to come up with new game mechanisms and basic structure. But, especially if it has been a long time between games, its a good idea to check whether there is any new research on the game subject area. And you will almost certainly have aspects of the game that you want to improve on, or modify in response to he feedback.
And, of course, all the administration, preparation, production of game materials and so on still have to be done. The very well organised designer might have constructed very durable game components for the game so that it can be played ‘out of the box’ – but this isn’t always possible, practical or economic.

Tip 2 : Allow Time

Give yourself plenty of time. Administration and production will take time. And it is easy to become over-relaxed for the second run of a game – it seems as though you have plenty of time, and suddenly…you don’t!

Tip 3 : Use the Feedback

Read through the comments and criticisms (and plaudits ) of the first game as they appear in the critique sheets. Megagames are notoriously difficult to test (we’ve discussed this in the design chapters earlier). In many ways, the first run of the game is the first full-scale game test. So try to make sure you benefit fully, use the feedback to improve the game. Players who are coming back to the second run of the game who took part in the first run will be looking to see if you’ve fixed the obvious ‘bugs’, and will be appreciative of improvements you have made. It is also important to understand what went well for players, and try to understand why it worked if you can.

Tip 4 : Make Sure You Want To

There is often pressure from players for you to repeat a successful game design. This is both gratifying and flattering. But. As with any run of a megagame you need to be fully behind running the game. If you have any doubts about your enthusiasm for running the game again, no matter how simple it might be to run a repeat, think hard. Low levels of enthusiasm will make the project much harder and your un-enthusiam will leak out into the game itself – players will sense it and it does have an impact much greater than you might think.
So if your heart is not fully into running a repeat then don’t. It might be that your enthusiasm for another megagame is better engaged by that new game project you were talking about in the pub last night. Always follow the enthusiasm!

Tip 5 : Tweaking – We All Do It

Related to Tip 1 above. It might be that you have a lot of tweaks, adjustments and new ideas you want to try out in your re-run of the game. This is great, it is showing you are activity developing your game design and improving and developing. There are down sides that are not always obvious.
You might be fixing something that isn’t broken. Usually you get feedback on what has not worked. A system, mechanism or part of your structure that is actually working well will rarely get any comment. You might have thought of a better way of doing it, and that is good, but I would always advise caution over making too many changes.
You might be unnecessarily adding complication. We talk earlier about how megagames really need simple, elegant and fast moving game mechanisms and systems. Resist the urge to add things because you can – it can have unintended consequences and, worse, slow down the game.
Your mates will always have suggestions along the lines of “…you could add in a thing for [insert cool thing here]…”. Sometimes that is brilliant, but most of the time, unless they have been closely involved in the game design and really understand how it all fits together, it is not necessarily a good thing for the game. We all like to be nice to our friends, but do not be pressured into adding a second dragon.



There is a lot to be said in favour of repeating successful games. Players who come again get a chance to experience different roles and re-connect with those they met in the previous game. New strategies and tactics can be explored, new deals made and the game will always go in a different direction. By repeating a game you can really see how megagames encourage emerging game play – no two runs of a megagame are (or can be) the same.

Megagame Design – Using Inspiration

Many megagame designers have used existing board game or computer games as an inspiration or framework or basis for a megagame idea. This can be an extremely good way of getting into designing your own games.
There are some advantages and also some pitfalls for the the unwary new megagame designers.
It is important to remember at this stage that a megagame is superficially like many types of games but its characteristics mean that its design is not like designing a role-playing game, a board game, a LARP or a wargame.
At this stage lets look at the similarities and differences in game types.

Board games :

Are designed to be played in a few hours and their mechanisms are optimised for that. Some very complex board games such as Twilight Imperium, Europa Universalis and their ilk require very long playing times closer to 10 hours, but these are generally an exception.
They can have simple or complex rules and processes. In general board games that aim to simulate something (in the same way megagames contain a simulation) have reasonably complex rules and procedures which might take some time to learn and a while to work through.
The vast majority or board games operate on an ‘I Go, You Go’ (IGYG) principle. This is a major distinction with megagames which simply cannot operate in that way because of the constraints of time, space and numbers of participants. It would be unacceptable for 40 players to be waiting around while one team of players have their ‘go’.pic00022

Mainstream wargame rules:

Wargames often aspire to be a simulation of real historical military operations and as such are designed to contain complex simulations requiring rules for different circumstances, weapons, abilities and so on.
Complex rules and procedures mean that wargames can often take many hours to play just a few game turns.
Like the board game, many of the current generation of mainstream wargames operate on the IGYG principle, creating a lot of player inactivity. Older wargames, utilising order-writing and simultaneous movement and action are closer to the needs of megagames.imgp0609

Role Playing Games:

Often characterised by in-depth character development and statistics for each individual player. In megagames there might be elements of character development, but there are generally simpler because of the need to apply time pressure. In some cases character development is not relevant, for example where someone is role playing as real historical role (King of France, or some such).
They need careful adjudication by a skilled Game Master (GM) who manages the narrative and injects situational updates to challenge or assist the players. This has a lot in common with the way the Control Team operate in megagames – though in a megagame there is a need for the emerging narrative to work within an overarching theme and structure.
The RPG has a wealth of tactical detail about individual player actions. This often requires a considerable expenditure of time and attention.dscf1497

Live Action Role Playing (LARP)

LARP place a heavy emphasis on role immersion and role playing on a personal level. In the most developed form it requires what is, in effect, improvisational acting skills. In fact it is these improvisation skills which form the core of the experience. Megagames contain elements of this, but more often players are role playing a role rather than a character – they are themselves being a Prime Minister, not role playing an actual prime minister.
There is an absolute requirement for dressing up in role. Whilst in megagames there is some fun to be had with a bit of dressing up, it has never been a requirement, as megagames attract gamers with a much wider field of interest, not all of whom are comfortable with dressing up and it is not necessary because megagames are not LARPS.
In some games there are physical interaction rules – rules for hitting one another with rubber swords etc. The physical and environmental aspects for a LARP are important even if there is no combat.
Many LARP games often have a highly structured narrative which has a clear denouement, which many be scripted or at least ‘nudged’ to create an exciting end-game. This is very distinct from a megagame which is fundamentally open-ended – the principle of following the emerging game-play makes it impossible (and undesirable) to have a dramatic ending.dscf2098

What becomes clear is that merely ‘porting’ an existing game from an existing genre, adding more players and calling it a megagame does not work very well. And this has been our experience.
However, that does not mean that concepts and some of the mechanisms from other game genres might not be usefully used in the megagame context, obviously with some important adjustments. This is an especially attractive route, particularly where the designer is new to megagame design and maybe does not have to confidence or experience to develop all the systems and mechanisms needs for a game from scratch.
That said, even the most experienced designers will draw on their own personal ‘toolbox’ of systems, structures and procedures that they have developed in earlier games or borrowed from other designer’s games.
Many of our most successful games started with inspiration from another game.

BUT when drawing on another game design remember to allow for the unique dynamics of the megagame.

Describing Typical Megagames (2)

In addition to the inter-communication problems and the hierarchical nature of the player team structure, in many games there is a representation of the situation using what is known as the closed ‘double blind’ system. Players only have the information that would realistically be known to them about the location of their enemies (or even of their own troops). The Control team (of which much more later) keeps a master map updated, and this master map is hidden from the players. Team Control report back each turn of how their orders have turned out and collect orders for the next turn. This method is very common in both operational megagames and political/military megagames.


Here we see a simple example of a military operational megagame which shows how the simplest of hierarchies are represented in a megagame format. And this doesn’t have to be historical – one could just as easily use command hierarchies to represent Steampunk armies, or fantasy armies or space fleets and star empires.

Hierarchies can be represented in other ways, for example there might be a political game in which the teams represent different parts of a government – with a Cabinet Team and teams representing government departments. Or you might have teams representing samurai clans who owe allegiance to their overlord. There are many ways this playing into game structures.


Some megagames have political as well as operational elements – some are wholly political, some have very key elements of role playing. In the more political and role playing games, hierarchies might not be so important. A game like Washington Conference by Dave Boundy has no hierarchies of teams, each team being a national delegation in an arms control conference. However in these cases the key element is team intra- and inter-communication. A megagame like this, one of pure negotiation, has the important elements of requiring complex player to player communication. The dynamic created by a megagame with virtually a 1 to 1 representation of key historical roles is where megagames are at their most LARP-like.

It is the combination of all of these elements that make each megagame slightly different to every other megagame.
Each megagame is unique in its own way – depending on the size, structure and theme – there is no ‘official’ set of ‘Rules of Megagame’ as a whole because each game must be designed to suit the theme and the interactions required (though some games might share some elements with other games – simple things like combat resolution methods are often re-used or adapted). In fact the creation of a set of standard rules would be antithetical to the whole megagame approach.


Intercommunication, interaction, teams and hierarchies – with the additional challenge of `player management’ makes the megagame unique as a gaming experience. It is this aspect that regular mega gamers tell me, time and time again, is the element that brings them back to play again.

I have often remarked that all that is really necessary is to put 40 regular megagamers into a hall with some paper, pens, tables and chairs and maybe a die or two, and a game would emerge of its own accord. Well, perhaps I exaggerate to make a point – but it is true that megagamers carry away anecdotal stories of their activities and interaction in a way that does not happen nearly so frequently in other areas of gaming.

On the subject of game size – there is a distinction between the megagame and merely a game with a lot of players. Big open miniature games, whilst providing an impressive visual spectacle are rarely structured into a hierarchy of teams, but more often as a two rows of players facing each other in a ‘multiple two player game’. Such a game would not, in our terms, be a megagame because it would lack, teams, sufficient hierarchy and meaningful interaction.  There is a big difference between a “100 player game” and 50 x 2-player games.