For whatever reason, I’ve been helping people solve problems with their games for something close to 20 years. I have a particular memory from 2004, where someb

For whatever reason, I’ve been helping people solve problems with their games for something close to 20 years. I have a particular memory from 2004, where somebody sent me the source code to their game and I fixed the 3D transformation code in it and explained what was going on. It was a bit more cumbersome without GitHub, Pastebin, or Stack Overflow. Over that course you see a lot of people come into the community, have all sorts of beautiful visions and grand ideas, run face-first into the harsh reality that they are ill-equipped to realize their dream, work on arcane technical aspects of their code with the dubious goal of developing some kind of interesting skill, and eventually burn out. The thing is—I agree with the first point that “most developers will never finish their game” but I think the wrong lessons are being taken here. If you try to understand the problem, there multiple contributing factors which explain why amateur developers fail to make games, and once you start to understand these factors, you can nudge people in the right direction or at least give them a map of the territory. - Cause: The gap between skills and vision is large. Mitigation: Reduce game scope, study relevant skills, work with teammates. - Cause: The gap between skills and vision is unknown. Mitigation: Complete small projects to get a better idea of what skills you have and a better ability to estimate the size of projects. - Cause: The developer never finishes any projects. Mitigation: Game jams and short deadlines. - Cause: Projects fail to attrition—the developer’s interest wanes over time, and the project gets less fun over time. Mitigation: Shorter timelines, smaller projects. - Cause: Poor technology choices. Mitigation: Use mainstream / popular technology such as Unity, Unreal, Godot, etc, and give yourself a limited number of passes to pick a weird technology. - Cause: Deep, unexpected technical problems with the game. Mitigation: Start by making games that are more similar to existing games made by teams with similar resources and experience levels, until you have more expertise. - Cause: The game looks terrible. Mitigation: Work on a team with an artist. Or dedicate time to studying art, and find an art style that you are comfortable with that does not require too much effort. - Cause: Can’t figure out how to solve basic programming problems without a tutorial. Mitigation: Work on a team with a programmer. Or dedicate time to studying programming. - Cause: Design choices unexpectedly cause high workload. Mitigation: Make prototypes to test critical design choices. - Cause: Iteration time is too long. Mitigation: Use technology that supports faster iteration times. This stuff seems obvious and yet there are so many obvious things that typically go wrong in a failed project. “I never considered working with teammates” is common enough. “I don’t want to give up my idea of an action RPG with Metroidvania platforming segments and a massive branching storyline” is a common enough type of problem. These problems can be solved much more easily when people working on games spend time in contact with people who have the experience—professional game developers or successful amateurs are one obvious choice, but school is another good choice. You can make the same mistakes over and over again, it helps to have other people around to point it out for you. > I myself have abandoned 2 dozen games, in platforms ranging from PhaserJs to Unity to Godot. This is, frankly, a bit worrying. It reminds me of Schopenhauer’s take on will, how he calls will “blind incessant impulse without knowledge”. We feel the strong urge to make games, but these incessant impulses must somehow be tempered and refined if they are going to achieve anything.