I hate tools development.
Tools are one of the few parts of game development that don’t contribute to the final experience. Sure we can all make excuses about easing development and streamlining content creation, but when all is said and done tools aren’t moving units.
Don’t get me wrong, tools are needed. How long would a platformer take to develop if every single platform, enemy and item was placed and tested via pixel number instead of crafted inside a level editor? But tools iteration is the siren calls, luring game developers away from creating and towards solving problems that didn’t need to be solved.
In fact, lots of famous SaaS companies started out as game developers that focused a little too much on internal tools. Slack is the most recent example of this, it started as an MMORPG named “Glitch” (now it has a market cap of $18 billion, sellouts). You can start off creating a simple sound effects generator and end up with an Audacity rival.
This is a very easy path to fall for. First, you have a simple problem like “I am making a shitty 2D RPG to remind me of my shitty childhood”. And with that comes “I want to just place ground tiles instead of handcrafting scenes in code”. So you start off with a simple tile editor: exports to JSON, your game scenes read JSON, everything is good in life and development. Then suddenly you get the itch, “Well, what if I want multiple layers”. So you go back, add layer support, “Of course I want my snow to blend into rock, duh”, then you compile and you have your tile editor. Next thing you know you are adding in transparency support, then expanding to object placement, A* pathfinding exports, parallax scrolling, and suddenly you find yourself creating an open source github project and begging everyone on r/gamedev to check out your new tool. Fast forward 2 years, your shitty 2D RPG is nowhere to be found and you are creating unprofessional gamedev tools for the 15 other shitty 2D RPG developers to use and complain about.
I remember reading “Masters of Doom” by David Kushner and early on it describes the clear divide at id Software, John Carmack creates the engine and John Romero creates the tools. This always struck me as interesting because everyone remembers id Software for the famous coder vs designer debates for who should drive development, but nobody mentions John Romero as the tools programmer. This distinction that Romero, before he became the front-man designer, was the other half of the engineering team and responsible for tools. If you think about it, this explains what came later on in the book; obsession over perfection, lack no development progress, restarting game development with the Quake II engine when it was already deep in development with Quake I’s engine. These are the classic signs of a tools developer. No tools developer is making me their bitch, sorry Mr. Romero.
Morale of this story: don’t be a tools developer, be a person that ships games.