5 weeks
We’re about five weeks away from wrapping up development and playtesting the game. Before we move on to the next step, we wanted to take a moment to look back and reflect on what’s happened so far. Five weeks is not a short time, and it’s been a long and arduous process, but we know in our heads that we’re just getting started. Having worked on a lot of incredibly colorful, complex, and fun games in the past, there’s a big gap between what we know as a “good and beautiful game” and what we’re making. This is where the pain comes in, and I’ve been told time and time again that the game I’m making is a step towards the ideal. I believe that painful repetition and training will bring us closer to the ideal. The five weeks were a valuable experience for me.
This is my second game developed with Unity. The first one was a Unity course I took on Udemy, and three people, including myself, who had never made a game before, decided to adapt it and launch it. However, since all three of us were inexperienced and had day jobs, progress was quite slow, and almost half a year later, we still haven’t launched.
The longer it goes on, the more energy you lose and the slower it gets, because the ideals you had at the beginning change. I think it’s the same with anything you do with a goal, whether it’s a game or a service. So this time, I set myself a goal of having a product within a month and started developing a new game. I started fleshing out the new game based on the ideas I had while making the first game.
Game Ideas
The ideas for the game came from the elements of the games I played in the past that gave me an enjoyable playing experience, as well as the elements that came from the games I frequently watch on YouTube.
The former was the smelting skill from the game <Mabinogi> from Nexon. Nowadays, it seems to be easier to level up this skill, but in the past, it was quite difficult to level up and it was a challenge for players to maximize the level of this skill. You had to spend money to buy minerals to practice the smelting skill, mine minerals in dungeons or get minerals by metallurgy on the beach to get minerals to smelt and train, and then you could make weapons and tools with the smelting results, which was a new and enjoyable experience for me personally. Usually in games, you have to kill monsters to get resources and use those resources to buy weapons or armor, but through smelting and blacksmithing skills, I was able to make my own equipment from the items I got in the dungeon. I had a lot of fun imagining myself supplying other players with the products they needed through a crafting class instead of a combat-focused class like warrior, archer, or mage. This was a fantasy because the game’s mechanics didn’t allow me to advance my character through crafting alone. Still, I thought it would be interesting to have a crafting-focused profession at some point.
The latter is a <Starcraft> usemap where you catch mobs on the map through probabilities and enhancements like Maple Random Defense, and I don’t know if it’s because BJ is having fun talking about it, but the game looks simple, but it’s full of tension and urgency. So, I thought that if we could take the probability and reinforcement elements from this game, we could make a game with a simple structure but similarly suspenseful.
Organize game structure
Based on this abstract idea, we organized the big game structure. I didn’t organize details such as specific algorithms, but I organized how the game cycle works, what elements are in the game and how they relate to each other, and how the player interacts with the system. At the time of writing, the only regrettable part of the process was that some of the fun elements that I felt during the idea gathering phase were lost or changed as I organized the game structure. In particular, there was very little fleshing out of how the game structure would challenge the player, and even though I’m not playtesting it yet, the game feels boring and loose when I play it alone.
I also wish there was a way to verify that the challenges would have the fun and emotional impact on the player that I thought they would. If I had thought of a simpler game structure to verify that, I could have prototyped it in a shorter period of time than a month and verified its playability. What I think I did well was that I was able to clarify the game cycle, so the structure didn’t change much during the actual development, and secondly, I did a good job of pruning. We were able to finish the development within a month because we refined and organized only the parts of the game that we thought were really important. I created a section called “Ideas” in the documentation for the parts of the game that I thought would be better if I had something like this.
Wireframes
Next, to implement the game logic, I created a wireframe based on the game structure that I had fleshed out in the previous step. As I was drawing, I realized that I had missed some things in the previous refinement phase. Also, as the idea became more and more visible, I realized that the wireframe felt different from what I thought at first. I think it’s helpful to sketch out artwork that reflects the feel of what you envisioned during this process. I think it’s important to translate your initial game idea so that it comes to life.
Game Development
For this game architecture, I heavily relied on Unity Open Projects. I thought I would get a good reference because the code was written by people with more experience in Unity development than me, and I was able to learn a lot. In the first project, I wrote the main logic based on Singleton, but this time I wrote the logic based on Event. I think the biggest advantage over Singleton is modularity. The Manager class rarely references other classes directly, which makes it much more testable and reusable. In fact, I wrote the code this time with the intention of making sure that features like Sound, EventChannel, InputSystem, and DialogueSystem could be easily imported into other games. I spent quite a bit of time writing this boilerplate code, and I think I’ll be able to save those resources for my next game. One of the things I experienced in my previous game development is that the logic is constantly changing, and whenever there is a change in the code, I have to test it several times to make sure everything works well. Or if I want to test the logic related to the game ending, I have to spend a lot of time playing and testing each case, which I think is very time-consuming. So in the next development, I think I will write automation tests for the main game logic to avoid critical bugs. Another advantage of designing a structure based on events is that the main classes are decoupled by events, making them easier to test. I only wrote tests for the main classes because it would be too inefficient to write code to cover all cases.
When I was developing, I kept thinking that development was not the point. Since I’m a developer by profession, I kept thinking about how to make my code more structured and cleaner. It’s important to organize the code in advance so that it’s easy to change it, but more importantly, it’s important to finish development quickly and verify gameability.
So when I needed a feature, I’d buy it from the Asset Store if it was available, and when I needed to make a compromise in the code structure, I’d do so with a generous amount of TODO comments. The main thing I paid attention to in the structure was to keep common modules separate to make the next game development faster, as mentioned above.
UI & Artwork & Sound
Artwork was a new challenge for me in this project, as I’ve only ever done development, and I found a different side of myself in the process of drawing. It took me about a week to draw and apply the artwork. I sketched in Photoshop and drew the images that would be applied in Aseprite. Around the time I started the project, I started taking tablet drawing classes. What I realized while taking the drawing class, and while drawing and sketching for the game, is that I quite enjoy drawing. It’s really fun to be able to immerse myself while drawing and visualize something that was only in my imagination. I’m really happy that I was able to get the colors and drawings that I wanted in this game. The Netflix anime Arcane and the games Inscryption and Don’t Starve were the closest to the feel I had in mind, so I used a lot of references here. I thought it would be a good idea to do some colored sketches as a way to gather ideas or as a first step in fleshing out the game. For the UI, I used some things from the Asset Store and hand-drew what I needed.
I realized again that sound is really important. The sound fills in the gaps where the artwork alone was lacking. Once the sound was applied, the feeling that I had in my head came to life. The sounds were purchased from the Asset Store. It took me half a day to choose the sounds and a day to apply them.
Data Cleanup & QA
Towards the end, I added items, NPCs, and organized the necessary specs in a Google Sheet. I then played through the game as if I were the player and cleaned up any issues I found and fixed any critical issues.
Where to improve
The next time I make a game, I’ll try to start the first playtest sooner. A month is a long time. It’s a long time for things to get fuzzy and for the picture to look different than what you initially envisioned. If I were to do this project again, I would think about the underlying game mechanics before wireframing, and then make a physical prototype of that part and play it by myself. At first, I thought that a physical prototype would not be very useful because the experience is very different from the software experience, but when I re-read the Game Design Workshop book and thought about making a physical prototype of the game after five weeks of work, I realized that I could feel the emotional elements of the game similarly, such as the fun of the game. Through this, I would double-check the game structure and make sure that the underlying mechanics are stable during the development process.
