Creative Drudgery
My job is a designer, director, and developer of games, and I undertake those tasks mostly alone, so they are things I am thinking about a lot.
Many of those tasks involve repetitive and tedious work. I'm taking a break from creating a certain kind of sprite for Amberspire. This involves making dozens of small images, configuring them in Unity, then referencing those sprites elsewhere so the game uses them. A lot of this process could be automated somehow, but a lot of it has to be done by hand. Today, I have to rename all of these files and slices and references by appending unique numbers to them, all by hand.
I have many more examples like this in different configurations, but you get the idea. It's repetitive and tedious. While doing this kind of work, it's worth spending some time to think about how I could save myself from doing this.
Perhaps I could write a little script that automatically renames files or metadata, or links references, or something else. My Unity editor scripting skills are modest but I could get it done if I put my mind to it. Or I could redesign the game's architecture to obviate some step in the process. This deep into Amberspire's development I have a normal amount of tech debt built up that I'm working within, so a little thought and work on that could save a lot of time elsewhere.
I've been working full time doing these tasks for nearly ten years now, and so I've encountered this question a lot. There can be a significant downside to tooling your way out of a problem: it can take a long time, it introduces failure points, it can be buggy, it can introduce different tech debt or unforeseen consequences in the future. I would say, given my constraints and skills, the majority of the time the better answer to the question is to just eat the drudgery and get it done. There is a chance that building a tool saves time, but the time savings is unpredictable and the ceiling could be much much higher than just doing the work.
In ten years I've built a decent instinct to when is the right time to build a tool and when it's a quagmire that is best avoided. Doing the tedious and repetitive work and realizing hours later that a tool would have been worth it is only something you can learn by experiencing yourself. Getting excited to build a tool and then being cursed with that tool until the end of the project is likewise only learned through experience.
The lessons learned in shipping a game help you try and avoid mistakes in the future. You'll make new mistakes, but hopefully dodge or mitigate the previous ones. The outcome of decisions can start to be a bit clearer before you make them. Understanding how to architect a videogame project, everything from code and assets and scenes takes a lot of practice to be able to do while making as few mistakes as possible.
The only way to learn is by doing it yourself and seeing the process from the inside and building the instinct to know when to improve and when to just put on a podcast and do some boring work.
This is a post about AI.