{"id":988415,"date":"2026-09-14T14:00:00","date_gmt":"2026-09-14T14:00:00","guid":{"rendered":"https:\/\/croncodestudio.com\/en\/?post_type=croncode_post&p=988415"},"modified":"2026-09-08T22:58:41","modified_gmt":"2026-09-08T22:58:41","slug":"investigation-mechanics-in-mobile-narrative-games","status":"publish","type":"croncode_post","link":"https:\/\/croncodestudio.com\/en\/journal\/investigation-mechanics-in-mobile-narrative-games\/","title":{"rendered":"Investigation Mechanics in Mobile Games"},"content":{"rendered":"
\n

Investigation mechanics are the rules that turn reading into play. On a phone, those rules cannot hide behind a large map or a skill tree. The player has a thumb, a few minutes, and a stack of fragments. The system has to make deduction feel like a verb.<\/p>\n

\n

Mobile investigation is three jobs: collect sources, order time, and revise a theory. If a tap does not serve one of those jobs, it is decoration.<\/p>\n<\/blockquote>\n

What counts as an investigation mechanic?<\/h2>\n

A mechanic is not a visual. Highlighting text is not investigation. A mechanic is a change in the player\u2019s working model. You open a chat and now two people cannot both be telling the truth. That is a mechanic firing.<\/p>\n

In Spylie<\/a> the mechanic is the phone itself. Apps are sources. Timestamps are order. Your head holds the theory. The same loop can live in a notebook UI or a case board, but the jobs stay the same. The App Store build is Spylie: Telefon Dedektif<\/a>.<\/p>\n

How should sources, time, and theory interact?<\/h2>\n

Keep the three jobs visible. Players should always know whether they are gathering, sorting, or revising.<\/p>\n

    \n
  1. Gather:<\/strong> open a new surface. Do not resolve it yet.<\/li>\n
  2. Sort:<\/strong> place the new fact on a timeline. Conflict is more useful than confirmation.<\/li>\n
  3. Revise:<\/strong> name what the new fact breaks. If nothing broke, the source was flavor.<\/li>\n<\/ol>\n

    This is slower than a tap-to-win puzzle, and that is the point. Attention on mobile is thin, but investigation needs a pause. We wrote about shrinking attention in how mobile products should evolve as attention drops<\/a>. Investigation games answer that drop by making one screen dense, not by adding more screens.<\/p>\n

    Which systems help, and which get in the way?<\/h2>\n\n\n\n\n\n\n\n\n
    System<\/th>\nHelps when<\/th>\nHurts when<\/th>\n<\/tr>\n<\/thead>\n
    Pin or bookmark<\/td>\nPlayers mark a contradiction<\/td>\nIt becomes a collectible list<\/td>\n<\/tr>\n
    Hint<\/td>\nIt points at a surface, not a sentence<\/td>\nIt spoils the inference<\/td>\n<\/tr>\n
    Case board<\/td>\nIt shows links the player already made<\/td>\nIt auto-solves the graph<\/td>\n<\/tr>\n
    Lock or password<\/td>\nThe answer is in the world<\/td>\nIt is a random cipher<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Locks are tempting because they feel like \u201cgameplay.\u201d They are only investigation if the password is a fact you already earned. Otherwise you have built an escape room inside a story. That mix is fine if you name it. It is not fine if you promised a case.<\/p>\n

    When do you add a second system?<\/h2>\n

    Add a second system only after the first one can carry a full session. If the phone loop already works, a map or a second character phone is a new product, not a patch. Feature creep is expensive here because every extra verb dilutes the three jobs. See the hidden cost of feature creep<\/a>.<\/p>\n

    A lean studio should also ask whether the new system needs new art, new writing, and new QA. Those costs stack. Our resource split is described in how a lean studio structures engineering and design<\/a>. For story timing, use the companion piece on clues, doubt, and payoff<\/a>.<\/p>\n

    What mistakes show up in reviews?<\/h2>\n