Designing an AI game editor for playable prototypes

When I joined the project, one developer had built a prototype that could create a simple game from a prompt. Other engineers were testing AI-focused projects such as a lightweight game engine, 3D asset generation, animated characters, and a game database. These pieces worked separately, but they did not yet work together as one creation experience. Generating a simple prototype was already possible, but the harder product problem was making the AI’s output understandable and editable enough for creators to continue working on it.

To bring these prototypes into one product, I worked closely with the CEO and engineering team to define the MVP. We focused on people who understood what they wanted to make but wanted AI to help them build faster or cover missing skills like programming, 3D, animation, or multiplayer. We saw prototyping as the clearest use case for independent creators, professional developers, and game designers.

We used three guiding product principles:

Creators could ask the AI to build a playable 3D prototype with a project structure, world, gameplay code, multiplayer, character controller, assets, and more. The world would appear in the editor while the AI worked.

Creators could then play the game, inspect its files, refine assets, debug problems, or ask for another change. Prompts could also target selected scene objects, so a request could change one object instead of the wider project.

I designed and implemented much of the interface and design system directly in the product using Claude. This let me test and improve working interactions without a separate handoff for every interface change. Engineers still owned the engine, agent infrastructure, multiplayer, and generation systems. When a change touched backend systems, I checked it with the relevant engineer.

Because the product and underlying technology were changing at the same time, I could not wait for everything to settle before designing. The product principles helped us make decisions, while continuous testing showed when an early idea, such as the asset plan, should be removed.

During development, experienced creators from HypeHype’s earlier mobile game-creation product used the private build and shared ongoing feedback. They were not studio developers, although some had earned money from their games. Their feedback appears beside the related decisions below.

I spent much of the project iterating on two areas: helping creators refine asset and character concepts before generating them in 3D, and making the AI’s work easier to follow and control.

Asset generation began as a separate technical prototype, so I worked closely with the engineer who built it to design the workflow and bring it into the main product. We identified its strengths and weaknesses, sketched a flow for creators, built it together, and tested it internally.

We saw that creators often needed a related set of assets with a consistent art style, rather than one model. Generating them separately could produce inconsistent results, and waiting for 3D generation before discovering that the visual direction was wrong also wasted time. I designed the flow to start with a project-level art direction, followed by a prompt and optional reference images.

My first version added an asset plan after the prompt. It listed the asset names and descriptions the AI had inferred so creators could check the set before generating concept images.

In internal testing, we saw creators skip the plan and move directly to the concept images. They were not concerned about the small cost of generating concepts, and the images represented what they had in mind better than text descriptions. We removed the plan and moved more control into concept review.

The AI inferred how many assets the request needed, while each concept remained independently editable. Creators could revise a concept in plain language, duplicate or delete it, add another asset to the set, create variations, regenerate it, or revert to an earlier version without changing the rest of the set.

This let creators change the direction before starting the slower 3D generation.

After approving a concept, the creator would generate a high-poly model, adjust its scale, select a quality preference, and send it for final processing with UV maps and textures. The result was a game-ready asset that could be added to their game.

I wanted this to work as an asset workspace rather than a one-shot generator. Creators could make an individual asset or a related set, keep the results aligned with the project’s art direction, and return to earlier stages to revise the result instead of starting over.

I had proposed removing the scale checkpoint to shorten the process, but generated models did not have dependable dimensions. Engineering required creators to check the scale before final processing, so we kept it as a manual checkpoint.

The same flow supported animated 3D characters. Creators used the same concept and review stages, while rigging and animation happened later in the pipeline.

During creator testing, the generation pipeline was still unstable and output quality varied. When it worked, it could produce strong game-ready assets. By the final build, we could complete the workflow end to end, but it had only recently reached that state.

A prompt to the AI could run for several minutes, touch many files, and fail or retry. A loading indicator gave too little information, while a raw technical log would have been difficult to follow.

I designed a live feed that translated technical operations into actions such as “Read Player.ts” and “Edited main.prefab.json.” It linked affected files and showed the agent’s commentary about what it was doing between actions.

When collapsed, the activity card showed the agent’s current action. When expanded, it showed the full activity history for the request. Long commentary collapsed automatically. Failures and retries remained visible, with error text creators could expand and copy while debugging.

I deliberately left out repeated start and completion rows, raw logs, and background subagent activity because they made the feed harder to scan.

I also changed how agent commentary was emitted so it appeared in sequence with file changes and other actions.

Creators could combine AI chat with direct work on the project, giving them full control of their game. They could browse hierarchy, edit objects, open the code, download and edit models, use version control, and debug through the console.

We also let creators reference selected scene objects in prompts. I extended the same pattern to the Files and Assets tabs. Creators could select several tree models, for example, and ask the AI to “create a forest with these trees.” This connected AI chat with project files and the scene editor.

One invited creator asked for more control and clearer errors in the developer console. I had seen the same problem internally when errors were mixed with large amounts of debug output.

I moved routine output into a neutral Messages filter, gave failures separate visual treatment, and moved editor status into the console. I also added an Errors only button, so creators no longer had to turn off Logs, Messages, and Warnings separately. When I watched creators use the revised console during testing the next day, they scrolled less and used fewer clicks to find the line they needed.

The activity feed showed what the AI was doing, but it did not make every generated element easy to find or edit afterward.

Some objects and UI were created only when the game ran, so creators could see them while playing but not find them in the editor hierarchy. They could edit scene objects in the inspector, but gameplay values created in code still had to be changed through AI or by opening the file.

We did not solve this gap before the project ended.

Three of the four invited creators made barebones but playable game prototypes: a tower defense game, a horror escape-room game, and an isometric combat game.

Positive feedback focused on quick prototyping, AI code generation, editing concepts before generating 3D assets, and the editor interface. One creator wrote, “It makes it very fast to prototype and create something playable.”

The main problems they reported were long generation times, bugs, inconsistent code and 3D output, and generated elements that were difficult to find or edit. One creator reported that a simple survival game took around 33 minutes to generate. We fixed reported bugs throughout the feedback period.

This was ongoing feedback from four invited creators, not a formal usability study. It showed that they could make playable prototypes with the build and speed up parts of their game development process. Because they were not studio developers, it did not tell us whether professional teams would use it. Speed, reliability, and how easily creators could edit generated content also remained unresolved.

Before a public release, HypeHype decided not to continue the standalone product.

The core flow from prompt to playable prototype worked end to end, but generation remained slow and inconsistent, and some generated content was difficult to find and edit in the editor.

The product also sat awkwardly between two audiences. Creators could generate a playable starting point, but fine-tuning sometimes required developer-oriented controls or editing TypeScript. Developers who were comfortable with those tools often preferred Claude or their existing engines instead of another editor, even inside HypeHype.

At a later external demo, the general reaction from professional developers was interest mixed with caution. Slow generation limited hands-on use. AI models were also improving quickly, which made it harder to define what our editor could add beyond Claude and existing game engines.

Showing what the AI was doing was not the same as keeping what it created visible and editable.