Agnostic Game Composer

Imagine making a farming game. You may need an inventory, crafting recipes, changing seasons, quests, saving, controls, sound, and a user interface. Another game may need several of the same ideas, but with different rules and technology. Agnostic Game Composer (AGC) is intended to help creators describe those parts, see how they connect, and decide what can safely be reused.

What it is

In this project, a module means one bounded part of a game: for example inventory, dialogue, saving, turn order, or a controller connection. Composing a game means choosing the parts, recording which versions belong together, and making their responsibilities and connections clear.

The long-term aim is a planning and compatibility assistant for designers and developers. It should help turn an idea such as “add blacksmithing” into a reviewable set of needs—items, recipes, costs, time, animation, feedback, and saved progress—while leaving the actual creative and technical decisions with the game.

Why it matters

Game teams repeatedly solve similar problems. Careful reuse could let an improvement to saving, input, inventory, or testing help several games. But shared code also shares bugs. A broken save upgrade or economy rule can damage every game that adopts it.

AGC therefore treats reuse as a question to prove, not a shortcut to assume. Each game keeps its own rules, feel, engine integration, tests, and release decision.

What someone could eventually make

• a puzzle game that reuses a well-tested action and undo pattern;
• a role-playing game that combines inventory, crafting, quests, dialogue, and saving while keeping its own content and balance;
• a tactics game that specializes shared ideas about turns, targeting, visibility, and outcomes;
• a studio library where several games can adopt a corrected module one at a time, with clear impact and rollback information.

The goal is not a button that manufactures a finished game. It is a clearer way to assemble, compare, test, and explain the systems from which games are built.

Where it honestly stands today

AGC is an advisory bootstrap, not a working game composer product. It can already check simplified machine-readable module descriptions, choose exact compatible versions, refuse conflicts and circular dependencies, record a repeatable review list, and compare proposed changes. Those checks currently use made-up test examples.

AGC does not yet integrate a real game engine, install or run modules, download packages, modify a game, or prove that a composition is fun, accessible, secure, fast, or ready to ship. Those claims require a real game, its own integration, and game-owned acceptance.

How we intend to work

We will grow the project in small, testable slices and publish the difference between what is imagined, what has been checked, and what a real game has accepted. Specialist projects can contribute evidence and experience, but they do not surrender ownership of their work and AGC does not gain authority over them.

The deliberately unglamorous rule is simple: a convincing plan is useful, but it is not the same thing as a working game.