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.

An authoritative Host that is not all-seeing

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 nearby Apple device. The current transport is built with Wi-Fi Aware, Apple’s system discovery and pairing interface, and Network.framework. Typed Codable messages carry actions and snapshots through a versioned protocol.

The game logic does not depend directly on that radio stack. 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. Physical-device acceptance across the intended combinations remains a release gate, separate from simulator and automated evidence.

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 remains work that must be performed before release.

Questions are product infrastructure

A social game can have sound networking and still fail because its prompts produce obvious or uninteresting answers. The current Romanian library contains 342 question pairs across ten categories. Each pair combines a group question with an impostor question.

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.

A development story, not a launch announcement

Impostor’s product foundation is implemented, but the app should not be described as publicly launched or App Store-ready yet. Current release work still includes full validation of the exact code intended for release, complete physical Wi-Fi Aware gameplay, native-Romanian group playtesting, spoken VoiceOver review, distribution signing, and Apple’s TestFlight and submission processes.

Keeping those boundaries visible is part of responsible product development. A successful simulator build is not physical-network evidence, and an implemented purchase flow is not the same as a commercially available subscription.

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.