Last week, I rewrote the way skill upgrades work in my game. Instead of handling them with the previous approach, I switched to a custom task system that now triggers skill upgrades directly. It took a fair amount of time, but it was worth it—the code is cleaner, and task triggering is more organized. At the same time, though, I ended up falling straight into a much deeper problem: writing the actual script for the game.
When is it time to optimize code?
With a more complex system, it is almost impossible to start out with the best possible structure from day one. A lot of the time, you just keep moving forward with if else + loop traversal, and by the time everything is working, it can still feel pretty good. At that stage, elegance and design patterns usually are not the priority. The important thing is simply getting your ideas into a working form.
But as the codebase grows, some parts start getting reused again and again. Logic piles up. Traversals become harder to follow. Repeated code starts spreading everywhere, and eventually the meaning of the code becomes blurry even to the person who wrote it. That is usually the moment to stop and refactor. If you keep adding more on top of that kind of mess, later development becomes much harder than it needs to be.
That is when optimization, encapsulation, and using the right design patterns begin to matter. Still, I do not think there is any need to obsess over making everything perfectly elegant or pushing optimization to the extreme. It only needs to be good enough for the project to keep moving forward. The goal is implementation, not perfection. For a small project, performance tuning is usually not the main issue anyway. Most personal projects are not going to push modern computers hard enough for performance to become the first concern.
Getting stuck on the script
I had been blocked on the story side for a while, so while cleaning up code, I was also trying to figure out how to write the game’s script. After some time, I had to admit something pretty obvious: I simply do not have much experience with this.
So I started looking for books on the subject and found one called How to Write a Game Script. I have been reading it for two days and I am already more than halfway through. It has finally given me some direction, and a few ideas are beginning to take shape.
One of the key concepts introduced in the book is jo-ha-kyu, which is somewhat similar to the Chinese idea of a story having an opening, development, turn, and resolution. The basic idea is that a strong story or script needs three parts: jo as the beginning, ha as the section leading toward the climax, and kyu as the climax and ending. As I kept reading, I also started learning more formal elements of scriptwriting, such as the protagonist, the world, story structure, and how those parts relate to one another.
I originally thought the script for a game would just come naturally while I was making it, as if I could improvise the whole thing without much trouble. In reality, writing it has been anything but easy. It has been a clumsy, stumbling process from start to finish. But at least now I have a clearer sense of why.
The next priority: write the story first
At this point, I have realized that what I really have so far is a world and a simulation of a blogger running a blog inside that world. That is a starting point, but it is not enough to make the game feel full. To give it real substance, it still needs events, scenes, and plot developments that can enrich the overall experience.
So the most urgent task now is to get the script written. I have never really done this before, but reading has at least given me some basic knowledge and a few practical techniques. For now, I will learn by imitation and keep building from there.