From Copy-Paste to Codex: A New Way to Build Gem Forge Idle

The first version of Gem Forge Idle was built by carrying code back and forth between ChatGPT and Unity. Then I bought ChatGPT Plus, tried Codex with the project files and discovered a completely different way to work.

Why I tried Codex

Not long after that first copy-and-paste stage, I heard that Codex could work with a Unity project rather than only respond to isolated pieces of code pasted into a normal chat. I bought ChatGPT Plus, officially listed at $20 per month, specifically so I could try this way of working with the project files. As the project grew, the included Codex allowance was no longer enough for the amount of work I wanted to do: usage was measured in five-hour windows, and a weekly limit could also stop the work until it reset. I later upgraded to the entry-level ChatGPT Pro plan, officially listed at $100 per month. In my own use, that plan is now enough for me to work with Codex almost continuously for at least six hours a day without running into a limit.

The attraction was obvious. Gem Forge Idle was no longer one script and one moving object. It already contained managers, interface elements, saved values and systems that depended on one another. In a normal conversation, ChatGPT knew only what I manually copied into the message. Codex could work with the project files themselves and examine more of the surrounding structure before making a change.

The important change was not that AI suddenly made the game for me. It was that I no longer had to transport every piece of the game to the AI by hand.

What “working directly in Unity” actually meant

I often describe the change by saying that Codex began working directly in Unity, but the more accurate description is that it could work directly with the Unity project files. It could inspect scripts, understand relationships between files and make the requested edits without waiting for me to paste each complete file into the conversation.

It did not replace the Unity editor, press every button for me or decide what Gem Forge Idle should become. I still opened the project, ran the game, watched the result and decided whether the change was correct. When something looked wrong, felt unbalanced or behaved differently from what I intended, I explained the problem and asked for another revision.

That distinction matters. Codex reduced the mechanical work of transferring code, but the development loop still required a human decision at both ends: first to define the goal, and then to judge the result.

From replacing one script to changing a system

Before Codex, I had to guess which part of the project mattered. If an inventory value was wrong, I needed to decide which script to copy. If a change involved saving, progression and the interface at the same time, I had to bring enough context into the conversation for ChatGPT to understand the connection.

With Codex, I could begin from the behaviour I wanted and let it inspect the relevant project files. Instead of asking for a complete replacement script every time, I could ask for a change to the existing project. That was a subtle difference in language but a large difference in practice. The project itself became the shared context.

This made broader changes possible without turning every request into a packaging exercise. I still needed to explain the rule clearly—what should reset, what should remain, what the player should see and what should happen after reopening the game—but I spent less time collecting files and more time describing the intended behaviour.

The game began to grow faster

The difference became visible in the project. Gem Forge Idle developed beyond the rough mine screen and its temporary controls. The game acquired a clearer progression structure, saved progress, inventories, discoveries, prestige ideas and specialised areas such as the faceting machine. Those systems did not appear because Codex invented a finished design in isolation. They appeared through the same cycle of idea, implementation, test and correction—but the implementation stage was no longer built around constant manual copying.

I could concentrate more on questions that belonged to the game itself. Should a resource survive a reset? When should a feature unlock? What information should a player see before making a choice? Did a gemstone feel valuable enough? Was the reward worth the time? Codex helped change the files, but those questions still needed answers from me.

Faster did not mean automatic

The new workflow removed friction, but it did not remove mistakes. A request could still be misunderstood. A technically valid change could still be wrong for the game. Something could work in one part of the project and create a problem somewhere else. The only reliable answer was to open Unity, test the build and look at what had actually changed.

Codex also depended on the quality of the direction it received. “Make this better” was less useful than explaining what felt wrong and what result I expected. As the project became larger, long conversations could also lose clarity. Sometimes the most practical solution was to begin a fresh chat, explain the current state and continue from there instead of forcing an overloaded conversation to remember everything correctly.

This was not a failure of the new method. It was part of learning how to use it. Direct access to the files solved the transport problem, but it did not automatically preserve every decision, every intention or every piece of history. I still had to keep the direction consistent.

My role changed—but it did not disappear

During the copy-and-paste stage, a large part of my work was mechanical. I moved code, created files, replaced contents and returned errors. After Codex entered the project, my role shifted toward directing, testing and choosing. I spent less time acting as a courier between two windows and more time explaining how the systems should fit together.

I still did not suddenly become an experienced Unity developer. I learned enough to navigate the project, recognise problems and communicate more precisely, but I continued to rely on AI for much of the code. The difference was that the collaboration had become closer to working on one shared project instead of exchanging disconnected fragments.

That is the real reason this stage became a turning point for Gem Forge Idle. Codex did not replace the person making the game. It reduced the distance between an idea and the files that needed to change.

The next problem was visual

Once the workflow could support larger changes, a different kind of problem became impossible to ignore: how the gemstones themselves should appear. The project experimented with a 3D direction, but what sounded attractive in theory did not produce the right result for this game. The next part of the journal follows that detour and explains why 2D eventually won.