I have a history of not completing game projects. While I start out with full confidence that
this time will be different and
this time I will finish, I always stumble and end up abandoning the project. They say that insanity is repeating the same action and expecting different results, which I realize I have been doing time and time again -- just expecting things to happen naturally. I have dedicated my newest project,
Vela, to be the one I will finish. I will finish because I will do things differently.
Stumbling Blocks of the Past
My first step is to think about what has been going wrong and attempt to fix it.
Lack of artwork
After getting a decent amount of prototype code and a basic working engine down, I run into the fact that drawing squares looks really stupid. My first step is to try to find someone who wants to create 3D models. If I manage to find someone, they tend to disappear after about a month. I try to do modeling myself, only to find that I am absolutely terrible at it. After this frustration, I am greatly saddened and it leads me to abandon my work.
I think a large problem here is scope. Creating good-looking 3D art takes a ton of time and energy, which makes it quite difficult to find people who want to work on your project for no pay. Those that think they're okay with it generally lose their muster after the honeymoon period. Part of this is my fault -- by the time I search for an artist, I've already formed a decent vision of what I want the result to be, which does encourage creativity.
To fix this, I'm working on a 2D game, which means content creation can happen much more rapidly. I am also getting artist involvement significantly earlier in the project and I am not planning on asserting any creative control. I want to enable the creative vision of my artist, not the other way around.
Overgeneralization
As a habit, I tend to generalize my code. I'm quite good at this for coding constructs, but that is a result of having tons of practice. I do not have tons of practice creating video games, so I lack the vision to see which patterns I am going to re-use and which I am not. I tend to think too much about the game
framework and not enough about the game.
Since I began to work in the real world, I have learned the value of doing just enough to make the product work. I can now look at something and say: I'm not going to need that, so I should not make it.
Lack of Publicity
At some point in every project, I ask the question: Who cares about this crap? I keep expecting myself to end up with a whiz-bang neat result, but I never reach it.
I'm planning on publishing milestones -- rewarding myself and telling the world about the progress I have made. Keeping this blog as a log of the work I have accomplished is part of the change.
/r/gamedev has a very supportive community for indie game developers. I want to keep a to-do list, upload things to YouTube and keep a public repository. If nothing else, I'll be able to look back and say: Look how far I have come.
Working Alone
Working alone on things is nice, because you can set your own pace or
change huge pieces of the project at will. However, there are advantages
to having the help and participation of others. At a slight loss of
individual velocity, a good team has significantly more momentum.
Making Development Too Difficult
For almost my entire programming career, I have had an obsession with multithreaded code. This leads me to design my engine in a very multithreaded manner, which leads to overcomplication, which leads to bugs. This time, I am going to write code which is thread-aware, but rely heavily on profiling to optimize later.
Lack of Good Scripting
For whatever reason, I've always implemented everything in whatever the primary language for the project was. This brings development to a crawl when the question of "Why is that unit behaving like that?" inevitably comes up. In Vela, the core of the engine is
libvela, a shared object filled with types for consumption in Python (using
Boost.Python). Scripting is built-in from the start.
