Indie ARG development methodology

How an ARG gets built here: concept design, puzzle sequencing, implementation and narrative structure, plus the pre-release review checklist.

How an independent ARG gets made: the full process from concept to launch

ARG development methodology

Every ARG puzzle game here went through a complete design and build process. This page sets out the methodology GameStrategists uses for independent ARG development — concept design, puzzle sequencing, technical implementation and narrative construction. It comes out of actual projects, in the hope it is useful to other solo creators.

1. Concept design: from a spark to a workable story frame

• An ARG does not start from a mechanic, it starts from a secret worth investigating. The core job of concept design is turning a vague idea into a story frame you can actually build.
• The seed idea — Every ARG project begins with a seed: an unsettling premise, an unsolved mystery, a conspiracy sitting under the surface. "Room 404" began from the plain thought "if you moved into a new flat and found the previous tenant had vanished, how would you investigate?" "Rust River" began from "under a town poisoned by industry, what is the factory secretly doing?"
• The narrative triangle — Fix the three points of the story: the protagonist (who the player plays), the central conflict (the truth that must be uncovered), and the antagonist or mystery (the force keeping it hidden). Those three create the tension. In an ARG the player is usually not a hero but an investigator — driven by curiosity rather than duty.
• Scene and medium planning — Decide which media the story will run through. The distinctive advantage of a web ARG is that it can imitate any online service: a news site, a corporate homepage, a personal profile page, a public database, a forum thread. Concept design has to work out which of those scenes the story actually needs, and price the technical cost of each.

2. Puzzle design: balancing difficulty, fairness and story value

• Puzzles are the core interaction of an ARG. Designing them means balancing three things at once: findability, solvability, and narrative necessity.
• Findability — Players cannot guess an answer out of thin air. Every clue has to exist somewhere in the game world — in an HTML comment, in image metadata, buried in a line of dialogue that looks irrelevant. The governing rule is that a clue must have a plausible reason to exist inside the story. If it has no in-world justification, it is a puzzle for the puzzle's sake.
• Solvability — The difficulty curve needs deliberate shaping. My rule of thumb: the first two puzzles should be easy enough to build confidence, the middle ones require combining information already gathered (that is where the "aha" happens), and the final one asks for a complete understanding of the story, so finishing feels like the last piece of a jigsaw clicking in. I have to be honest about one thing: there is no outside test team, so "where exactly is this hard" is my own judgement — and the person who wrote the puzzle always knows where the clue is buried. That is the weakest link in this whole method, and the only way I make up for it is after release, from the emails players send me.
• Narrative necessity — Every puzzle must advance the plot or deepen the world. If removing a puzzle leaves the story intact, the puzzle should not be there. The Morse-code puzzle in "Midnight Frequency" is a good example: it is not only a puzzle, it is what establishes "Linwan" as the key location, and it sets up the game's central theme of signal and decoding.

3. Technical implementation: building convincing simulations on web tech

• The technical heart of a web ARG is simulation — making invented websites look real. Every implementation detail serves that immersion.
• A visual identity per simulated site — Each fake website needs its own design language. A rental listing site uses orange and rounded cards; a government portal uses restrained blue-and-white and formal type; dark-web pages sit in low-saturation near-black. These are not arbitrary choices — they build, below conscious attention, the sense that this is a real internet.
• Faithful interaction detail — A search box has to give real search feedback, including a genuine "no results" state. Form submissions need believable processing latency. The mail system needs plausible server response times. Individually these are trivial; their absence breaks the illusion instantly.
• Guiding toward hidden information — Steer the player while staying in character as a real site. A button that glows faintly on hover, a passage of text whose selection colour is slightly off — these small anomalies are the visual signals that lead players to clues. The balance is delicate: too obvious and it becomes a linear tutorial arrow, too subtle and players miss it and stall.

4. Building the narrative: environmental storytelling and fragments

• ARG narrative is environmental storytelling taken to its extreme. The plot is not delivered through cutscenes or dialogue trees but assembled from fragments — emails, blog posts, news reports, lab records, chat logs.
• Three layers of fragmentary storytelling — Layer one: surface information, easy to reach from any page. Layer two: connective information, a conclusion you can only draw by combining several pages. Layer three: hidden information, buried deepest and gated behind a puzzle. A good ARG keeps these three layers clearly structured so that players investing different amounts of effort each get something out of it.
• Connections across the shared universe — The name Tide Protocol is still written into the text of Midnight Frequency and Room 404. The corporation called Xinyuan appears in the text of Rust River alone; no second work mentions it. The design rule for a shared universe is that each game must be complete and self-consistent on its own; but for a returning player who knows the names, a familiar phrase flashing past in the background, or a second ledger for the same kind of equipment, is an extra discovery on top.

5. The pre-release checklist

• Before any ARG ships I check it against the list below. One person runs this list — there is no separate QA and no outside testers — so it covers the parts I can check objectively. The real difficulty of a puzzle only shows up after release, in the feedback players send me.
• That is the GameStrategists ARG methodology. As an independent developer every game is a fresh adventure from zero. These methods came out of practice and keep being tested and revised in practice. They are a guide, not doctrine — what actually matters is caring about the story and being stubborn about puzzle design.
• If ARG development interests you, the long-form articles go into much more specific implementation detail and development logs. Try the ARG beginner guide or browse the game list on the homepage.

Are the answer, the trigger and the clue entry of every core puzzle written into the game data files, rather than living only in my head?

Does every clue have a plausible reason to exist inside the game world?

Playing through the whole flow without any outside hint, is extra guidance still needed to move forward?

Is each simulated site internally consistent in its visual style?

Is mobile support complete — do the key interactions work on a phone?

Are the two languages accurate and consistent, and are English puzzle hints comprehensible?

Are there any accidental plot holes or unnoticed contradictions in the story?

Are the trigger conditions for multiple endings clearly defined, including hidden endings and epilogues?