[VIVE Coding AI Game Development Diary ②] A Liberal Arts Student with Zero Coding Skills Completes a Game

STEP 2

STEP 3
The third lesson I learned was to complete the logic before adding graphics. It doesn't matter if it's clay or a block of polygons; the priority is to make the game function correctly first. (This is what I should have heard back in Part 1, when I was stuck on character appearances and went through 12 versions.)
Fortunately, the prototype game worked well. The monsters moved along the path as I intended, and the units attacked. From here, I began making detailed adjustments. How to place units on the map, how to combine units, adding new monsters, setting win/loss conditions... I refined each aspect one by one.
The process was difficult, but incredibly fun. I pondered, "What elements are needed to make this feel like a game?" and added the necessary features one by one. I added units, added monsters, incorporated background music, and then added special effects and various visual effects.
As time passed and I could see the game taking shape, I felt a sense of satisfaction and lost track of time, engrossed in coding.
What was even more impressive was that 'Claude' could understand and execute my commands, even though I, with no coding knowledge, was giving various instructions. Furthermore, when I asked 'Claude', "Suggest things that can improve the game's completeness, excluding balance aspects," it provided diverse and very useful suggestions while developing the game.
As I focused intently on development, I found myself almost believing I had become a true game developer.

The fourth step is the graphics work.
This turned out to be more challenging than I initially thought. First, I experimented with various tools and prompts to generate the desired graphics. Then, I had to manually edit them in Photoshop to achieve the exact look I wanted. I had to meticulously cut out each character and input them one by one, a process that would have been impossible without Photoshop skills.
Relying solely on image prompts wasn't effective, as the AI often misunderstood the requests. Furthermore, constantly tweaking details by using up tokens was inefficient. (This was a hard-learned lesson from the Capybara section in Part 1.)
The real difficulty began when I started integrating the graphics into the actual game. Issues like images being cut off or monster movements not aligning with their graphics began to surface. These problems could only be identified by applying the graphics within the game environment itself. I worked with Claude to address these issues one by one, and this phase also consumed a significant amount of time.
Personally, I had an interesting experience during this process. I divided the tasks, with Claude handling the coding and Gemini responsible for the graphics. The workflow was surprisingly effective. I would have Claude compile the necessary design specifications, then pass that information to Gemini for graphic generation. Finally, I'd apply the completed images back into Claude and receive feedback. At one point, I felt like a Project Manager, coordinating between the development and design teams, even though I was just switching between two chat windows alone.
Once the image work was complete, the game truly started to feel "game-like." This sense of accomplishment and reward naturally led to me spending more time on game development. Since updates were immediate and aligned with my vision, I found myself rapidly depleting my token allowance, pausing, and then resuming work more and more frequently.

The final stage was balance adjustment.
This involved level design while actually playing the game, and it was incredibly difficult to do alone. While playtesting by myself, the game had many random elements, so when it was too easy, I'd wonder if it was too simple, and when it was too hard, I'd constantly question if I had designed the balance poorly. I eventually asked some acquaintances to test it, but their game comprehension varied, and with the significant random elements in a defense game, the results were all over the place.
While adjusting the game's balance, I realized why some games are released with less-than-perfect balance. After twelve rounds of balance adjustments,
somehow, the game was completed.

A humanities student with a zero in coding created a game.
It's both surprising and satisfying that I, who knew nothing about coding, managed to create a game that actually works. I also learned that making games is incredibly fun.
I learned a lot during the process. When it came to adding graphics, I refined prompts and made repeated requests, much like a designer giving feedback in a development studio. I learned that this is by no means easy, and I also felt how arduous the task of balancing is. While I could make a game without knowing how to code, there were so many other mountains to climb in 'making a game' besides coding.
Just being able to experience all of this firsthand by creating the game myself made this a project where I gained a great deal.
And above all, the fact that I, who knew absolutely nothing about coding, was able to create a game to this extent using only 'Vibe Coding' is, in a way, a little frightening. Compared to four months ago with 'Luvable', I've been thinking complex and varied thoughts about how rapidly AI is developing, what developers in the actual industry must be feeling, and what it means to live in such a world.
Four months ago, I let go of the capybara I was desperately trying to catch, but in the end, I created a functioning game with my own hands. The reckless challenge of a humanities student with a zero in coding was made possible thanks to the advancement of AI.