Making Games in the Age of Superintelligence: A First Playable Plan

An idea can now pass through several agents before a player ever sees it. One agent may sketch a level, another may write code, and a third may test a build. That makes it easy to produce more files. It does not tell you whether the game works or whether anyone wants to play another round.

The practical starting point is a small agreement about what to build and how to check it. The free brief builder on this page asks for the player action, goal, end condition, view, controls, and first platform. It gives you a Markdown brief to share and a JSON plan to use in other tools. Neither file is a game.

What “superintelligence” means here

Superintelligence is a future possibility. It should not be confused with an AI assistant or agent working in a game project today. Calling a product an “SI game engine” does not establish that it can design, build, test, and ship a good game on its own. Ask what the current tool can read, change, run, and show you after each change.

Those capabilities vary. Godot documents command-line project runs and exports, which can support a repeatable build check. Unity documents an Assistant package with a read-only Ask mode and an Agent mode that can act on scene objects and assets, subject to permissions. Epic documents Unreal MCP as an experimental editor feature that exposes tools to compatible agents; Epic also warns that features and APIs can change. These are specific present-day workflows, not evidence of superintelligence.

Define the first playable version

Write the first build as one round, not a list of every feature the final game might have. State who the player is, what they do with the controls, what success looks like, what ends a run, and how to restart. Choose one space and one target platform. Leave shops, multiple levels, accounts, multiplayer, and a large story outside this first check unless one is essential to the core action.

Use a sentence a builder can act on: “Move through one street, collect three sparks, and reach the door before touching a cart.” Then add the missing decisions: side view, keyboard controls, browser build, success feedback, failure feedback, and restart. A visual direction can guide the work, but a beautiful still image cannot replace a playable round.

Example: Lantern Run

Imagine Lantern Run, a small side-view game about a courier crossing a rainy street. The player uses a keyboard to move around puddles and collect three sparks. Reaching the door with all three sparks wins. Touching a moving cart ends the run. The first build needs one street, one courier, three sparks, one cart, a visible spark count, and a restart action. It does not need a city map or a second level.

The handoff should include checks a person can observe:

1. Open the browser build. The first playable space loads without a blocking error.
2. Use the keyboard. The courier moves, avoids puddles, and collects sparks; the count changes.
3. Reach the door with fewer than three sparks. The game does not report a win.
4. Reach the door with three sparks. The game shows a clear success state.
5. Touch the cart. The run ends with clear feedback. Restart and play a fresh round.
6. Open the exported build outside the editor and ask a new player to finish one round without instructions.

These checks do not dictate code or engine. They say what must be true in the running game. If a result is missing, the builder has a concrete next change to make.

Choose an engine for the build

Choose from the requirements of this first game: view, input, target platform, export path, and access to project files. Test a tiny export before you commit to a long project. A browser target and a desktop target can have different setup and input needs. Confirm the current export instructions for the engine version you actually use.

If you want to build with Summer, read the AI game engine guide, the Godot AI agent guide, and the MCP setup page. Those pages explain Summer's workflow; the brief on this page is engine-neutral. Keep the original project and the exported package in the handoff so another person can inspect what was built.

Hand off work an agent can verify

Give an agent the brief, one task at a time, with a result it can show you. “Make the courier move with the keyboard and show a running scene” is easier to review than “finish Lantern Run.” Ask for the changed files, the run or build result, and a short note about what remains broken. Play after each meaningful change. Do not accept “done” as evidence when the build has not been opened.

Keep an asset list beside the brief. For every image, model, sound, and font added to the project, record its source and the license or terms you relied on. If you cannot identify the source or permitted use, replace the asset before release. The same habit applies whether a person made the asset, you bought it, or a tool generated it.

Test, then ship the build you tested

Run the acceptance checks in the editor, then repeat the round in the exported package on the target platform. Look for input that fails, missing files, unreadable feedback, audio problems, and a restart that keeps old state. Watch one new player without explaining the rules. Note what they try first and where they stop.

If the build fails, narrow the next task to one observable fix and test again. If it passes, you have a first playable game and a clear basis for deciding what to add. Future AI may change how much an agent can build. The check that matters now is still simple: a person can open the game, understand the action, finish a round, and choose to play again.