Building Impostor: a party game designed around hidden information

A round of Impostor starts with several people in the same room, each holding an iPhone or iPad. Most players receive one question. One player receives a related but different question without being told explicitly that they are the impostor. Everyone answers privately, the group reveals the answers, the conversation moves back into the room, and then each person votes.

The premise fits into a sentence. Building it as a nearby multiplayer app does not.

The central development problem was not how to draw the voting screen or animate a result. It was how to define an information boundary across several devices: who may know which question, at what moment, and what must still be absent when a device reconnects. That decision shaped the game engine, networking protocol, interface, content model, and tests.

The mechanic became an information contract

Hidden information is the source of the tension. If the app reveals too little, players cannot discuss the answers. If it reveals one detail too early, the round collapses.

We translated the social rules into a precise contract for every phase:

• during answering, regular players receive the group question while the impostor receives the related alternative;
• during reveal, everyone may see the group question and the attributed answers, but not the impostor question or identity;
• during voting, that same boundary remains in place while votes stay private;
• results is the first phase allowed to disclose the impostor, both questions, vote totals, awards, and updated scores.

This is stronger than hiding a label in the interface. Information that a player is not allowed to know should not be present in that player’s state at all. Otherwise a future screen, log statement, reconnect path, or debugging shortcut can expose it by accident.

The Host coordinates play without seeing every secret

One participant creates the session and becomes the Host. The Host controls pacing: starting the game, moving from answers to reveal, opening the vote, showing the result, and advancing the next round. The Host is still a normal player and should not gain privileged access to the secret.

Impostor therefore separates the authoritative game from what each participant can see. A deterministic GameEngine owns the rules and validates actions. A GameSession coordinates the Host, players, transport, and lifecycle. Before a snapshot is sent to a device, the full state is projected into a recipient-specific PlayerVisibleState.

That projection runs for the Host too. If the Host is a regular player, it does not receive the impostor’s question. If the Host is the impostor, it does not receive an early explicit identity signal. Reconnection uses the same projection instead of sending a convenient full-state snapshot. The architecture follows the game rule rather than treating the Host as an exception.

Nearby play without a gameplay server

Every participant uses their own Apple device on the same local Wi-Fi network. Local discovery and connections let players find a named host and join the game. Typed Codable messages carry actions and snapshots through a versioned protocol.

The game logic does not depend directly on the connection mechanism. It talks through a GameTransport boundary with production and mock implementations. That separation lets the same GameSession run against deterministic simulated peers during development while the normal Create and Join flows use nearby connections.

Gameplay remains local and in memory. There is no gameplay backend, account, database, cloud save, advertising, analytics, or tracking service. Questions ship inside the app. Free gameplay can run without an internet connection; App Store operations such as loading an offer, purchasing, restoring, or managing Impostor+ can still require connectivity.

Keeping the system local reduces unnecessary data collection and infrastructure, but it does not make networking effortless. Discovery, confirmation, interruption, retry, and resynchronisation still need explicit states. Testing the intended combinations on physical devices is a separate requirement from simulator and automated checks.

Turn a conversation into explicit round states

The social flow became a finite sequence: Lobby, round setup, answering, reveal, voting, and results. The Host advances the round, but every transition is checked by the engine. Reveal cannot begin before all active players have answered. Results cannot appear before the active votes are complete. A player cannot vote for themselves or submit a second answer.

Each device may have only one answer or vote awaiting confirmation. After someone submits, the corresponding control stays pending until a Host snapshot confirms or rejects the action, or until a reconnect or phase change ends the pending state. That prevents rapid taps from becoming conflicting commands and makes uncertainty visible instead of pretending an action has completed.

There are deliberately no gameplay timers. Impostor is a face-to-face conversation, and different groups need different amounts of time to read the room. The Host controls the pace while the app protects the order of events.

Make the phone part of the game, not the whole game

The best moment in a round happens when players stop looking at their screens and start defending an answer. The interface therefore has to deliver private information quickly, confirm a short action clearly, and return attention to the group.

The native SwiftUI interface uses familiar controls and a restrained visual hierarchy. iPhone play is portrait-first, while iPad is treated as a full participant in portrait and landscape. Semantic surfaces support Light and Dark appearances; layouts account for Dynamic Type, increased contrast, reduced transparency, and reduced motion. The purple identity and original character artwork make the private states recognisable without turning every transition into decoration.

Accessibility is part of the implementation contract, but implementation and final acceptance are different things. Structural labels and adaptive layouts can be tested automatically and visually. A complete spoken VoiceOver review on physical devices is also needed to assess the experience beyond its labels and layout.

Questions are product infrastructure

A social game can have sound networking and still fail because its prompts produce obvious or uninteresting answers. The Romanian question library is organised by theme. Each pair combines a group question with an impostor question, giving the group a shared subject and a difference to uncover.

The editorial rule is not “write two sentences that look similar.” The two questions need high overlap in plausible answers, so the impostor can blend in, and a meaningful difference in intent, so the group has evidence to debate. Content is stored as structured, stable resources rather than being embedded across screens. Categories reference production question identifiers for their previews, and the same library supplies gameplay.

The app is Romanian-first. Its bilingual product website explains the concept in Romanian and English, but that does not imply that the native interface is already localised into both languages.

Test the invisible rules first

Many of the most important failures are not visible in a happy-path screenshot. A reconnect could return too much state. The Host could see information intended only for another player. Random selection could repeat an impostor or question incorrectly. A delayed confirmation could allow a duplicate action.

The engine therefore uses controllable randomness and deterministic identifiers in tests. Recipient-specific projections are checked for regular players, the impostor, a regular Host, and an impostor Host across every phase. Mock transports exercise session coordination without pretending to validate the physical radio. At the pinned tested revision, focused interface tests cover the updated category and question-browser paths, while targeted simulator review covers iPhone and iPad, Light and Dark appearances, larger text, increased contrast, and reduced motion.

That distinction matters. Automated coverage can prove the game rules against a named source revision. It cannot prove that every real group, room, or supported device combination will behave perfectly.

Keep implementation, testing and availability distinct

Building the product, validating it and making it publicly available are separate parts of the work. A release process needs checks against the code being distributed, complete games on physical devices, group playtesting in Romanian, VoiceOver review and Apple’s distribution requirements. The product website is the place to check current availability and device requirements.

Keeping those distinctions clear helps us describe the work accurately. A successful simulator build cannot establish physical-network reliability, and implementing a purchase flow does not by itself make a subscription commercially available.

The lasting lesson from Impostor is simple: architecture should follow the information promise made to the player. Once we defined exactly what each person may know, the right engine boundaries, network messages, screens, and tests became much clearer.

You can visit the Impostor product website or tell us about a digital product you want to build.