unity-codex-POC-harness

Inspiration

I originally entered the hackathon intending to build a game.

My goal was to create a polished and fully realized game experience. However, while working on it, I ran into a problem that I had repeatedly experienced during game development: a large amount of code, artwork, content, and polish could be required before answering the most important question.

Is the core interaction actually fun?

A game’s unique edge, originality, and core loop often begin as a feeling in the developer’s head:

“This will probably be fun.”

However, once the idea is implemented, the result may feel as though an important ingredient is missing. Studying similar games, redesigning their mechanics, and combining different inspirations can improve an idea, but it is still difficult to know whether the complete concept will work before investing significant development time.

This led me to change the direction of my hackathon project. Instead of continuing to build a single game that might remain unfinished or fail to prove its central idea, I began creating a reusable harness for producing small gameplay proofs of concept.

Game POC Studio was created to turn a game idea into the smallest complete Unity prototype that can test one gameplay hypothesis before the developer commits to full production.

The goal is not to create a polished vertical slice. It is to build one simple, repeatable game loop and determine whether its actions, decisions, feedback, tension, and rewards are interesting enough to justify further development.

I also learned that a useful POC cannot always ignore art completely. Some game concepts receive much of their appeal from the appearance, movement, scale, silhouette, or transformation of an object.

For those concepts, the prototype must reproduce not only the mechanical interaction, but also the minimum visual hook required to experience the idea as intended.

What it does

Game POC Studio is a Codex-based harness for planning, building, and validating small Unity game prototypes.

Each POC targets one complete playable loop:

The player enters the game.
The player performs the core action.
The game responds with clear feedback.
The player reaches a simple success or failure state.
The loop can be restarted and tested again.

The harness separates the process into connected planning, development, art, coordination, and validation workflows.

The planning workflow can capture an existing game idea, develop it through a short and natural game-design conversation, or begin with blank-slate brainstorming.

It breaks the game down into individual elements such as:

Objects
Player actions
Rules
Spaces
Resources
Rewards
Failure conditions
Feedback

This makes it easier to change, replace, or remove individual elements without losing track of the central gameplay hypothesis.

The planning workflow also distinguishes between confirmed facts, preferences, candidate ideas, unresolved questions, recurring motifs, and discarded ideas. This prevents an unfinished suggestion from being treated as an approved requirement.

Once the central idea is sufficiently defined, the harness reduces it to the smallest testable scope and transfers only the necessary requirements to the development workflow.

The art workflow does not aim to produce final production artwork. Its default approach is to use Unity primitives, basic materials, simple colors, minimal UI, and placeholder effects.

It focuses on readability, timing, visual hierarchy, and gameplay feedback while keeping development time centered on testing the mechanic.

However, placeholder art is not always sufficient. When the appeal of a concept depends on a distinctive object, character, silhouette, animation, or visual transformation, the minimum visual hook must also be represented accurately enough for the POC to test the intended experience.

After implementation, the prototype is reviewed against the original gameplay hypothesis rather than judged by the amount of content it contains.

The final review asks:

Is the complete gameplay loop playable?
Is the player’s goal understandable?
Does the game provide clear feedback?
Are the success and failure conditions meaningful?
Is the core interaction interesting enough to repeat?
Does the minimum visual presentation communicate the intended hook?
Is there enough evidence to justify further development?

How we built it

Game POC Studio was built as a repository-scoped Codex workflow that can be placed inside a Unity project.

Before the implementation workflow can begin, the Unity project requires preparation for a Unity MCP connection.

The required Unity MCP components must be installed, configured, and verified in advance so that Codex can communicate with the Unity Editor and perform implementation tasks inside the project.

Game POC Studio assumes that this connection is available. The harness does not replace Unity MCP. Instead, it controls what Codex should build through that connection, in what order it should work, what information should be preserved, and where user approval is required.

The harness contains:

A portable AGENTS.md workflow agreement
A reusable Codex Skill
16 specialized planning, development, art, review, and coordination agents
Planning and session protocols
Workflow checklists and validation gates
Blank project-state templates
Structured handoff formats between departments

The main Codex task acts as the studio manager.

It communicates with the user, tracks the current project stage, manages approval boundaries, preserves important decisions, and assigns bounded tasks to specialized agents.

Planning agents develop and organize the gameplay hypothesis.

Development agents turn the approved scope into a playable Unity implementation.

Art agents define the minimum primitive-based presentation required for readable gameplay and identify situations where a more specific visual representation may be necessary.

Review agents check whether the result satisfies the intended gameplay loop, visual communication requirements, and validation criteria.

The workflow uses structured handoffs so that each department receives only the information required for its task. This reduces unnecessary context, prevents unapproved ideas from entering implementation, and makes it clearer which agent owns each decision.

In automatic recording mode, planning decisions are periodically written into project documents.

This allows a natural design conversation to continue without losing important mechanics, preferences, unresolved questions, rejected ideas, or changes in direction.

Challenges we ran into

The first major challenge was the change in project direction.

I initially intended to submit a game to the hackathon. However, I realized that I was spending a large amount of development time building content before proving whether the central interaction was enjoyable.

Instead of continuing to develop one game based mainly on the assumption that it would eventually become fun, I redirected the project toward a reusable POC validation harness.

The second challenge was communicating the visual concept I had in mind.

It was difficult to describe the intended composition of the game screen, the appearance of individual objects, and the relationships between those objects. I created rough reference images using a basic paint program, but translating those sketches and descriptions into the intended Unity scene was still unreliable.

Using Codex to implement specific game-art elements—including 3D objects, 2D sprites, and visual compositions—often produced results that did not match what I had imagined.

I had to repeat the request, revise the description, inspect the result, and try again several times. These repeated attempts consumed a significant number of tokens and delayed the implementation of the actual gameplay test.

This revealed that “create the art for this prototype” is too broad to be a reliable task.

A Unity primitive, a 2D sprite, a custom 3D model, a UI element, and a gameplay effect require different instructions, different tools, and different review processes.

The harness therefore needs a stronger art-classification stage before an implementation task is assigned.

For example, if the required asset is a 2D sprite, the workflow should first define its intended gameplay purpose, silhouette, visual style, scale, viewing direction, animation requirements, and how it will be displayed in Unity.

If the required asset is a custom 3D model, Codex should not immediately begin detailed implementation.

It should first produce a rough design proposal or blockout plan describing:

The object’s gameplay purpose
Its overall silhouette
Its proportions and scale
Its major components
Important viewing angles
Moving or interactive parts
The elements that create its visual identity

That rough proposal should be reviewed before detailed modeling begins.

Only after confirming that Codex has understood the intended shape should the workflow continue to the actual 3D implementation.

This additional approval stage could reduce incorrect generations, repeated revisions, unnecessary token consumption, and delays.

It also revealed a more fundamental design issue: art is not always separate from the gameplay hypothesis.

Some mechanics are appealing partly because of how an object looks, moves, transforms, breaks, grows, combines, or reacts.

If the POC tests only the functional mechanic while removing the visual element that creates its appeal, the test may produce an incomplete or misleading result.

The challenge is therefore not simply to remove art from a prototype. It is to identify which visual elements are unnecessary production work and which visual elements are part of the concept’s central hook.

Another challenge was balancing natural conversation with reliable documentation.

Game ideas often emerge through unfinished thoughts, jokes, comparisons, and changing preferences. The harness needed to preserve meaningful decisions without treating every suggestion as a confirmed requirement.

To solve this, the workflow separates confirmed facts, preferences, candidate ideas, unresolved questions, recurring motifs, and discarded ideas. It also uses periodic checkpoints to preserve meaningful changes without interrupting every part of the conversation.

The final major challenge was controlling prototype scope.

A small gameplay test can easily grow into a full game project. I added explicit gates that continually reduce the design to one complete playable loop and reject features that are unnecessary for the current gameplay hypothesis.

The same rule applies to visual work. Art should be included only when it improves player understanding, gameplay feedback, test accuracy, or the minimum visual hook of the concept.

Accomplishments that we're proud of

The largest accomplishment was successfully changing the project from a single game into a reusable Unity prototyping workflow.

Instead of producing one isolated game implementation, Game POC Studio provides a structure that can be reused to test multiple ideas and genres.

I am also proud of creating a workflow that treats the POC as a decision-making tool rather than a smaller version of a finished game.

The prototype is considered complete when it provides enough evidence to make a development decision, not when it contains a large amount of content.

The repository-scoped structure is another important result.

The portable AGENTS.md, reusable Codex Skill, specialized agents, planning protocols, validation gates, state templates, and handoff formats allow the workflow to travel with the Unity project.

The system also preserves a clear distinction between conversation, approval, implementation, and review.

This reduces the risk of an early idea being silently turned into a development requirement and makes it easier to understand why a feature was included or removed.

Another accomplishment was defining art as a variable that can be scaled according to the gameplay hypothesis.

The default remains fast primitive-based prototyping, but the workflow recognizes that some concepts require a minimum visual identity to be evaluated fairly.

This creates a more useful target than either extreme: producing polished final artwork too early or removing so much presentation that the intended appeal can no longer be tested.

Because each POC remains a normal Unity project, a successful experiment does not need to be discarded. It can be adjusted, improved, and potentially expanded into a larger game after its central loop has demonstrated enough value.

What we learned

I learned that effective AI agent orchestration requires more than assigning different prompts to multiple agents.

A reliable workflow also requires:

Clear ownership
Persistent project state
Approval boundaries
Structured handoff contracts
Failure handling
Scope-control rules
Measurable completion gates

I learned that natural game-design conversations also require information classification.

A confirmed mechanic, a temporary preference, an experimental candidate, an unanswered question, and a rejected idea should not be stored or implemented in the same way.

I also learned that Unity MCP and the Codex harness have different responsibilities.

Unity MCP provides the connection that allows Codex to interact with the Unity project. The harness provides the planning, control, state management, approvals, task boundaries, and validation logic required to use that connection reliably.

Another important lesson was that different asset types require different planning and review processes.

A request for a 2D sprite should not follow the same workflow as a request for a custom 3D model. A detailed asset should also not be implemented before its basic purpose, silhouette, scale, and form have been confirmed.

Reviewing a rough design before detailed implementation can reduce misunderstanding, token usage, and development time.

Most importantly, I learned that a useful game prototype does not need to represent the entire planned game.

It needs to represent the core interaction clearly enough for the developer to play it, observe the result, and make a decision.

At the same time, reducing a game to its mechanics does not always mean removing all of its visual identity.

When visual presentation contributes directly to the appeal of the mechanic, the POC must include enough of that presentation to test the intended hook.

The correct target is neither maximum polish nor zero art. It is the minimum combination of gameplay and presentation required for a meaningful evaluation.

The final question for every Game POC Studio prototype is:

Does this single playable loop, together with its minimum necessary visual hook, provide enough fun or interesting decision-making to justify further development?

What's next for unity-codex-POC-harness

The next step is to test Game POC Studio across several different game genres and compare how effectively it turns early concepts into playable Unity prototypes.

I also plan to create a clearer Unity MCP preflight process so that the harness can verify that the required connection and project configuration are ready before implementation begins.

The art workflow will be revised to explicitly classify each visual request before assigning it to an implementation agent.

The planned categories include:

Unity primitive or gameplay blockout
2D sprite
Custom 3D model
UI element
Gameplay effect
Animation

Each category will receive its own requirements, approval process, implementation instructions, and validation criteria.

For 2D sprites, the workflow should confirm the gameplay purpose, silhouette, style, scale, viewing direction, required animation frames, and Unity import requirements before production begins.

For custom 3D assets, the planned process is:

Define the gameplay purpose of the object.
Describe its silhouette, scale, proportions, and major components.
Identify important viewing angles and interactive parts.
Create a rough design reference or Unity blockout.
Review whether the proposed form matches the intended concept.
Approve or revise the design.
Continue to detailed implementation only after approval.
Test whether the completed asset contributes to the intended gameplay and visual hook.

This process should make art requests more predictable, reduce repeated Codex attempts, and keep token usage focused on meaningful iteration.

I also plan to improve the evaluation formats for:

Player feedback
Decision quality
Cognitive load
Tension
Reward timing
Replay motivation
Visual readability
Visual appeal
The strength of the game’s hook
The minimum proof of fun

The long-term goal is for Game POC Studio to answer not only whether a mechanic functions, but whether the smallest playable and visually meaningful version of that mechanic is compelling enough to become a full game.

Built With

c#
codex
unity