During my first week with Gem Forge Idle, the game was not being built by an AI working inside Unity. ChatGPT and Unity were two completely separate worlds, and I was the bridge between them—one copied script, one error message and one small decision at a time.
Project journal · The first week
Before Codex could work inside the project
In the first part of this story, I explained why I returned to an idea I had abandoned and how a moving sphere eventually led me toward a 2D idle game. This part is about what happened next: the repetitive but strangely effective first week in which every change travelled manually between ChatGPT and Unity.
Two windows and no direct connection
At that stage, ChatGPT could not see my Unity project, inspect the scene or edit a file for me. I could describe what I wanted, and it could produce code or instructions, but nothing moved automatically from the conversation into the game. If a script had to be created, I created it. If code had to be replaced, I opened the file and replaced it. If a Unity component needed a reference in the Inspector, I had to find the correct object and connect it.
My working method became a loop:
- I explained the next behaviour or change I wanted.
- ChatGPT gave me code and instructions.
- I copied them into the appropriate Unity script or object.
- I pressed Play and watched what happened.
- If Unity produced an error—or the result simply was not what I meant—I copied the code, message or explanation back into ChatGPT.
- I received a revised version and started the cycle again.
There was nothing elegant about it. A single change could travel between the two windows several times before it behaved properly. However, this process gave me something extremely useful: immediate evidence. I could see whether an instruction had created a visible result, and that result helped me explain the next step more clearly.

I was learning how to ask for the next piece
I was not learning game development in a conventional order. I did not complete a programming course and then begin a project. The project itself decided what I needed to learn next. One moment I needed a button to trigger an action. The next I needed a number to update on screen, a manager to remember a value or a save system that could restore progress after the game closed.
I did not always know the technical name for what I wanted. I described the behaviour in ordinary language: what should happen when I pressed something, what should remain after a reset, what felt too slow or what information I wanted the player to see. ChatGPT translated those intentions into scripts and Unity instructions. I then had to turn those instructions into an actual scene.
This also meant that my wording mattered. When I described a feature poorly, the code could be perfectly reasonable and still produce the wrong result. The correction was not always “fix the code.” Sometimes it was “I did not explain what I meant.” That first week taught me that working with AI is not simply giving orders. It is a process of making an idea precise enough that another system can act on it.
A recognisable game appeared inside the mess
The preserved screenshots from that period are not polished promotional images. They show the Unity editor, the hierarchy, the Inspector, the Console and a narrow portrait game view crowded with temporary controls. Text overlaps. Buttons look unfinished. Some information is there mainly so I can check that a system is doing something.
But the screenshots also show how much had started to exist. The project hierarchy contains mining, inventory, loot, prestige and save-related objects. The game view already has a mine, rock health, resources, upgrades, navigation and early reset ideas. These were not final systems, and the interface was far from ready, but the project had crossed an important line: it was no longer a blank Unity scene or a disconnected experiment. It was becoming recognisable as the game I had in mind.

Errors became part of the conversation
Before this project, an error message would have looked like the end of the road. During that first week, it became material for the next message. I copied the error, explained what I had just changed and asked what to do. Sometimes the answer corrected the script. Sometimes it revealed that I had missed a Unity step, attached something to the wrong object or failed to connect a reference.
The conversations themselves were not permanent, perfect project records. As they became longer, they could become harder to continue usefully. At times I had to begin a new chat and explain the project again from its current state. I also deleted many early conversations because, at the time, I had no reason to imagine that I would later document this process. What survived most reliably was the Unity project and the screenshots I happened to keep.
That is why these images matter. They do not reconstruct every exact prompt or every failed attempt, but they preserve the honest condition of the game: complicated, untidy and advancing.
The first week was not one long breakthrough. It was a chain of small instructions, visible results, misunderstandings, corrections and another press of the Play button.
The cost of building everything by copy and paste
The method worked, but the project was already becoming too large for it. Each new system depended on scripts and objects created earlier. ChatGPT only knew the material I brought into the conversation, while Unity contained the real state of the game. I had to decide which file, error or piece of context to copy back. If I missed something important, the answer could not account for it.
Even a small visual change could involve finding the correct object in the hierarchy, selecting the right component, adjusting a value, testing it and then returning to the conversation if the result was wrong. The more Gem Forge Idle grew, the more time I spent transporting context instead of describing the game I wanted.

What the first week proved to me
By the end of this stage, I still would not have called myself a programmer. I was beginning to understand Unity, but I was not independently writing the systems that appeared in the project. My role was different: I chose what the game should do, tested every result, rejected what did not fit and kept the process moving.
Most importantly, the first week proved that the idea could survive contact with reality. The game did not need to arrive fully formed from one brilliant prompt. It could grow through hundreds of ordinary exchanges. Copying and pasting was slow, but it turned an idea that had once lasted only an hour into a real Unity project with enough structure to continue.
It also prepared the next major change in the story. Once Codex entered the Unity project directly, the relationship between the AI, the files and me changed. I no longer had to carry every piece of code between two separate windows. That did not remove the need for decisions, testing or corrections—but it changed where the work happened.
Gem Forge Idle is now on Google Play
The game is publicly available. Visit the permanent project page for the complete story, current mechanics, screenshots, release milestones and the official Google Play link.

Comments
One response to “Before Codex: Building Gem Forge Idle Between ChatGPT and Unity”
[…] the previous part of this story, every script, error and revision travelled through me. ChatGPT produced code, I pasted it into […]