Eidos

The game design doc that keeps up with the game.

Not a hundred-page bible: one page per mechanic, level, and character, each judged against your pillars and kept beside the build. Draw the core loop, keep the reason the double jump was cut, and point every playtest task at the page it changes.

Free for macOS, Windows, and Linux. No account, no subscription.

A mechanic page for a demo game, Lanternfall, open in Eidos: Lantern Oil, in the build, serving two pillars, with why it is in the game, what is still to decide, and its playtest tasks beside the page.
Lanternfall, a demo game: one mechanic, one page, the pillars it serves, and the work that changes it.

Sound familiar?

Nobody reads the GDD, and it was out of date at the first line of code.

Every game should have a design doc. Almost nobody keeps one true.

  1. Nobody reads it

    One long document, read once. People stop after the pillars, and the mechanic they’re building is somewhere on page forty.

  2. It falls behind the build

    Values change in every playtest. Soon the build becomes the reference and the doc collects dust.

  3. It is everywhere

    A doc for ideas, a sheet for numbers, stickies for level flow, and notes you texted yourself. Asking a teammate is faster than finding the answer.

How it fits

One page per mechanic, kept beside the game.

Every part of the game gets a short page with the same sections: why it’s in the game, how it should feel, its rules and numbers, and what it will never do. The pages are plain markdown in your project folder, next to your Godot or Unity project if you like.

The Game
Five pages: pillars, player, platform, scope, and market. Everything else is judged against them.
Mechanics
One page each, grouped by system: intent, feel, rules, tuning, and out of scope.
Levels
Grouped by act: the beat, what the level teaches, and the layout.
Characters
How they read on screen at a glance, and what the player does about them. Enemies get their own page: what they test, their tells, and their numbers.
The cut list
A cut mechanic keeps its page, marked Cut, with the reason it went.
The mechanics of a demo game as a table, grouped by system (movement, light), each with a summary, a status (Idea, Prototyped, Designed, In Build, or Cut), its type, and the pillars it serves.

What you will use most

Design tools first. The rest is optional.

  • Canvas

    The loop on one page

    Mechanics, levels, and characters as cards that open their pages, joined by labelled arrows and coloured by status.

  • Backlog

    Playtest work beside the page

    Tasks on a board, each pointing at the mechanic or level it changes. The page holds the design, the board holds the work.

  • Assets

    Concept art and paper maps

    Images, PDFs, and the balance sheet live in the project, linked to their pages. Rename one and every page follows.

  • Comments

    Playtest notes on the exact rule

    A playtest note sits on the rule it’s about, signed by its writer, and closes once the page is updated.

  • AI Agent

    If you code with an agent

    Connect your own agent and ask. It reads the mechanic’s page before it writes the GDScript or C#, and changes your design only if you ask.

See the game whole

Draw the core loop

Lay out what the player spends and what gives it back, with every card a page you can open. Arrows carry labels and frames group a system. A card’s colour follows its status, so a cut mechanic turns red by itself.

A canvas titled The core loop: abilities that reach rooms, the lantern’s oil in the middle with labelled arrows, and the pickups and save points that refill it, with a sticky note saying nothing else is a currency.

Start today

Install the game framework

One command sets up the game’s folders, its five framing pages, and the one-pager, cut list, playtest log, and art bible, named in Title Case. Then give your first mechanic a page in its system. In the app, pick Game when you start a new project.

$ eidos install @The-Virtual-Panda/game --naming "Title Case"
✓ installed @The-Virtual-Panda/game → Blueprints (Eidos 5.5.0, naming Title Case)
  collections: The Game, Mechanics, Levels, Characters, Items
$ eidos new Mechanics "Wall Cling" --group Movement
✓ Mechanics/Movement/Wall Cling.md  (Mechanics, mechanic.one-pager, id B-7X1Z)

Start here

Start from the game framework.

Game is in the Registry: five pages for the whole game, mechanics and items by system, levels by act, and characters, with a page type for enemies. Every page moves from Idea to Shipped, and a cut one keeps its reason. A playtester role sees only what’s in the build. If your game is built on its setting, add Places and Factions from World.

A video game, a mechanic at a time

Game@The-Virtual-Panda/game

Mechanics and items by system, levels by act, characters and enemies, a cut list, a playtest log, and a playtester role that sees only what is in the build.

  • The Game
  • Mechanics
  • Levels
  • Characters
  • Items
$ eidos install @The-Virtual-Panda/game

In the app: New Project, then pick it from the list.

See it in the Registry

A fictional world, for a series or a table

World@The-Virtual-Panda/world

Places by region, factions, characters, arcs by campaign, a history, and a player role that sees only what is revealed.

  • The World
  • Places
  • Factions
  • Characters
  • Arcs
$ eidos install @The-Virtual-Panda/world

In the app: New Project, then pick it from the list.

See it in the Registry

Write the first one-pager tonight.

Download Eidos MD, start from the game framework, and give your core mechanic its own page. It’s free, and your pages stay in your project.

Free for macOS, Windows, and Linux. Your files stay plain text in a folder you own.