A facilitated team game works beautifully on a table: cards, tokens, a timer and a facilitator who keeps everyone honest. Moving it onto phones is where most attempts break. This article shares what we learned turning a facilitator-led workshop game into Before Mars, a live co-operative strategy game that 3–4 teams play at the same time from their own devices.
From a Printed Guide to a Live Game
The game started as a workshop format with a written facilitator and participant guide. Teams manage resources, build projects, trade with each other and deal with shared crises while trying to send people to a Mars colony. A full game runs over four quarters of five rounds each — twenty rounds, typically about ninety minutes.
The goal of the digital version was clear: keep the workshop experience, remove the paperwork, and let the facilitator focus on people instead of bookkeeping.
Three Screens, Three Jobs
A single interface for everyone is the first mistake to avoid. Before Mars has three views of the same live session:
- The facilitator console on a laptop: start the game, move to the next round, trigger crises and see every team's state.
- The team screen, designed for phones first: the team's resources, available actions, trade offers and the round timer.
- The public board on the projector: the shared picture everyone discusses, including a 3D view of Mars.
Each screen shows only what its audience needs. Teams do not need the facilitator's controls; the room does not need a team's private trade negotiations on the wall.
Why the Server Must Own the Rules
An earlier prototype let each device calculate its own outcomes. It worked in a demo and felt like a single-player game in a real room: two teams could see different numbers, and nobody trusted the result.
In Before Mars the devices only display the state and send commands — "bid on this project", "propose this trade". All calculation happens in one authoritative place. Resources, bids, limits and the timer are resolved centrally, and every client shows the same truth a moment later. For a game that decides a winner in front of a room, this is not an optimisation; it is the product.
Rules as a Specification, Not Folklore
Workshop games survive on the facilitator's memory. Software cannot. Every rule was written into a specification with its own identifier and acceptance criteria, and implemented as a pure, deterministic rules engine with automated tests. When a question came up — does a limit apply per quarter or per game, who wins a tie — the answer was a rule ID and a test, not a debate.
Where the guide was ambiguous, the default was recorded explicitly and marked as an open decision for the game owner to confirm.
Simultaneous Moves Without Conflicts
In a live room, two teams will press the same button in the same second. Project bids and trades are therefore applied as atomic transactions on the shared session: a trade is proposed and then accepted or rejected as a single step, and when two bids arrive together only one can succeed. The rule "first valid bid wins" only means something if the system can guarantee what "first" is.
The Facilitator Needs an Override
Real sessions do not follow the script. A team mis-taps, a phone dies, a facilitator decides to make a point. The console includes an override panel: choose a team, adjust its status or resources, cancel a bid. Without it, the facilitator is at the mercy of the software; with it, they stay in charge of the room.
Everything Is Logged for the Debrief
Every action — including every override — is written to an event log. That serves two purposes. It makes disputes easy to settle, and it gives the debrief material: when did cooperation break down, which trade changed the game, which crisis caught which team unprepared. A serious game is only as good as the conversation afterwards.
Fidelity Beats Features
We had ideas for extras: AI-generated chance cards, additional crisis stories, automatic debrief summaries. The game owner's answer was simple — they wanted the game in the guide, exactly as designed. They were right. The guide had been tested with real groups; our additions had not. The extras were removed, and the energy went into making the designed game run flawlessly.
Phones, Not Apps
Participants join with a four-letter room code in the browser. Nobody installs anything, creates an account or waits for IT approval. In corporate training rooms, every extra step before the first round costs minutes and goodwill.
A Checklist for Your Own Multiplayer Training Game
- Separate facilitator, team and public views from the start.
- Keep one authoritative game state; clients display and send commands.
- Turn every rule into an identified, testable specification.
- Make bids and trades atomic so simultaneous actions cannot both succeed.
- Give the facilitator an override, and log it.
- Log every action for the debrief.
- Stay faithful to the tested workshop design before adding features.
- Join by room code in the browser; no installs, no accounts.
Read what the game is about in Before Mars for corporate teams, and how we design and run training games on our serious games & training simulations page.
Frequently Asked Questions
How many teams can play a facilitated multiplayer training game?
Before Mars is designed for 3–4 teams playing at the same time, with each player on their own phone and a facilitator running the session.
Why is a server-authoritative design necessary?
Because every team must see the same result. If each device calculates outcomes itself, numbers drift apart and players stop trusting the game. Central calculation keeps one shared truth.
Do participants need to install an app?
No. They join in the browser with a room code, which removes installation and account steps in corporate settings.
What does the facilitator see during the game?
The facilitator console shows every team's state and controls rounds and crises, and it includes an override panel for adjusting status, resources or bids when a session needs it.
