The Woodcutter's Dilemma: No Time to Improve Efficiency??

When developing games, have you ever fallen into a situation where you are so caught up in the work right in front of you that you can't spare time for new tools or efficiency measures?
This is a well-known story that applies not only to game development but is called the "Woodcutter's Dilemma."
Today, I'd like to talk about the "Woodcutter's Dilemma" in game development based on my own personal experience!

What is the Woodcutter's Dilemma?

A passerby advises a woodcutter who is struggling to cut down a tree with a dull axe, saying, "You could cut more efficiently if you sharpened your axe." However, the woodcutter angrily refuses, saying, "I don't have time for that, I have to cut the tree!" In this way, they push forward while trapped in the dilemma of, "If I just stopped for a moment to prepare or improve, the work would be much easier...".

I feel that even in actual work, there are many people who, due to being busy, put off the time to sharpen their tools. Especially in game development, there is a tendency to be chased by deadlines and just try to clear the tasks at hand. When you get caught up in this kind of situation, it often leads to a negative spiral where, as a result, rework increases and you become even busier, doesn't it?

Concrete Example: Improving the Bug Reporting System

In game development, reporting and fixing bugs is an everyday occurrence. However, if the bug reporting flow remains cumbersome, a situation arises where "it's a hassle to make detailed reports, so I put it off." Even if each element, such as the development ROM number, attaching logs, or filling in reproduction steps, is necessary, if there are many of them, they tend to be avoided.

However, if you postpone flow improvement here for the reason that "I don't have time anyway," you might end up having to process a huge accumulation of bugs all at once, or you might not be able to identify the cause due to a lack of logs. Therefore, by taking the plunge to interrupt your work and improve the bug reporting tool or task management system, you can ultimately aim for significant time savings.

In a project I was involved in previously, we made it so that by pressing just one button on the ROM, a task would be created with all the information necessary for a bug report, such as logs and the ROM version, already attached, and it could be posted directly to the task system. Thanks to this system, bug reporting within the team became more active, and investigations became much easier.

Concrete Example: Implementing Debug Features for Efficiency

For example, when testing the behavior of an enemy character, you may need to check attacks that only trigger under specific HP levels or status ailment conditions. Without any preparation, you end up repeating the verification by whittling down the HP to 10% every time, and it is not uncommon for a single test to take anywhere from several minutes to several tens of minutes.

But if you prepare debug features in advance that allow you to freely manipulate HP and attack skills, you can reproduce the relevant situation immediately. I believe this is exactly what "sharpening the axe" means. It takes a little time to build, but once implemented, you can save a lot of effort every time you test, and the final bug fixing and adjustments will likely speed up as well.

When you aren't busy, you can implement these kinds of debug features as a matter of course, but when you reach the end of development and are in a situation where "there are 10 bugs to fix today," you suddenly become unable to do the same thing.

Concrete Example: Implementing a Communication Emulator

In online multiplayer games, debugging when a program problem occurs during communication is extremely difficult. There are two reasons for this.

First, for program debugging, we usually use a "debugger" like Visual Studio. Using a debugger allows you to pause the program and execute it line by line to identify where the problem is. However, in multiplayer games, debugging with a debugger is difficult. If you stop the program on only one of the two terminals playing the match, that terminal is judged to have a significant communication delay and is treated as a communication disconnection by the other terminal. In other words, using a debugger causes a different problem.

Also, in multiplayer games, you naturally play with multiple people. In other words, you need multiple people's help to reproduce a bug. This means that if a programmer tries to investigate a bug and first tries to reproduce it, they must always have someone else help them.

That is why it is important to implement an "emulator" that allows a programmer to reproduce multiplayer matches even when alone. The emulator does not perform communication, but it performs the same processing as sending and receiving events on a single terminal, virtually realizing the same behavior as when playing a multiplayer match. Implementing an emulator is very difficult, but it has major long-term benefits. In the team I was in, it was even said, "If you're going to make a communication game, make an emulator first."

Concrete Example: Investing in New Tools

Recently, generative AI (especially large language models like ChatGPT) has been appearing one after another, and there are more tools that are compatible with game development. For example, there are tools that automatically generate code for Unity or Unreal Engine, or write miscellaneous scripts in an instant.

However, when I actually hear about it, there are many cases where people shy away, saying that their current project is too busy to introduce new tools. Previously, while talking to a developer from another company, I heard the voice, "I've heard it seems convenient, but I have so many tasks, and I need company approval, so I don't have time to try it."

However, if you take just a little time here to try out AI tools, wouldn't you expect a dramatic increase in efficiency for mass-producing code and fixing bugs?I believe that those in management or producer roles should even go so far as to forcibly assign one person to verify the potential of these new tools. I think this is highly likely to lead to a reduction in the overall delivery time.

Summary

I think the woodcutter's dilemma is a challenge that remains unchanged in every era. I feel it is important not to be chased only by immediate tasks, but to constantly keep thinking about "where can I improve efficiency?" and "how can I utilize new technologies and tools?".

Especially now, the game development environment is evolving rapidly, and updates for Unreal Engine and Unity are frequent. In addition, generative AI is developing at an astonishingly fast pace. To incorporate these new methods, I think it is necessary to make the decision to "dare to interrupt your work, even if you are busy".

I myself once dared to spend a few days creating a feature to streamline debugging work, and I realized that the speed of the subsequent testing process increased dramatically. In the end, I am keenly aware once again that preparing tools in advance can shorten the total development time in the long run.

Everyone, if you are currently working hard with a "worn-out axe," please try stopping for a moment. Even if it is just for one day, if you take the time to try out tools, advance automation, or organize your workflow, you might get surprising results that make you think, "Wait? Is it this much easier?"

I hope this is helpful, even a little!
I also share information on X, so I would be happy if you could follow me!