Describe a game mechanic. Define how it should be tested. Codoken's peer-to-peer network generates and verifies the GDScript in a real headless Godot process.
Rather than prompting for an entire scene or system, you isolate each piece of game logic into an atom — a pure function with a clear contract. The network generates it, Godot runs your tests headless, and you get back code that is provably correct before it touches your project.
Extract one pure function from your design — movement, damage calculation, pathfinding heuristic, inventory math. No scene dependencies, no Node references.
Define exact inputs and expected outputs using plain assert statements. The harness runs inside a real Godot headless process — no mocks, no emulation.
A distributed worker generates the GDScript. Independent validators verify it. You receive a function that passed real Godot execution — not just a plausible code snippet.
Paste the verified function into your script. Because it was written and tested as a pure function, it slots in without surprising you with scene-tree side effects.
Give your local coding agent a one-time system prompt describing Codoken. From there it can decompose any game system into atoms, submit each one to the network, collect the verified GDScript, and assemble the final script — all without leaving your IDE.
# Codoken — verified GDScript generation (MCP) You have the codoken MCP server available as a set of tools. Use it whenever you need to implement a pure GDScript function — no Node, no scene tree, no @onready — just typed inputs and outputs. ## Tools submit_atom(task_id, language, prompt, test_code, timeout=120) Submits one atom and blocks until APPROVED or REJECTED. Returns the generated code on APPROVED. submit_manifest(task_id, language, atoms, timeout=300) Submits multiple atoms in one call (max 16). Each atom needs: id, prompt, test_code. Use for a batch of related functions. get_balance() — current credit balance list_languages() — all supported languages ## Rules 1. One function per atom. Pure — no globals, no scene references. 2. prompt must state the exact typed signature and every edge case. 3. test_code: plain assert statements + print("ALL TESTS PASSED"). No test frameworks, no imports. 4. On APPROVED, paste only the returned code. Discard the test harness. 5. On REJECTED, revise the prompt (add a missing constraint) and retry. ## Example submit_atom( task_id = "knockback", language = "gdscript", prompt = """Write a pure GDScript function named apply_knockback( velocity: Vector2, direction: Vector2, force: float, friction: float) -> Vector2. Returns velocity + direction.normalized() * force, multiplied by (1.0 - clamp(friction, 0.0, 1.0)). Return only the function definition, no extends, no class_name.""", test_code = """var v = apply_knockback(Vector2.ZERO, Vector2.RIGHT, 100.0, 0.0) assert v.x == 100.0 var v2 = apply_knockback(Vector2.ZERO, Vector2.RIGHT, 100.0, 0.5) assert abs(v2.x - 50.0) < 0.001 print("ALL TESTS PASSED")""" )
Ask your agent to list every pure function a new game system needs — movement math, damage formula, loot roll, pathfinding heuristic. Each becomes its own atom.
The agent writes the typed signature, behavioural contract, and concrete assert values before any code exists. The contract is the spec.
The agent posts each atom, polls until resolved, and retries rejected ones with a revised description. No human in the loop unless it fails twice.
With all pure functions verified, the agent writes only the scene-level glue — the small part that actually needs Node references and signal connections.