Nullpunkt – A development review
Some weeks ago, I released my recent project: Nullpunkt. It was a two-dimensional space shooter aimed at a dense atmosphere and game experience. If you want to test it yourself, you will find the download below the linked trailer. I’m now and on the verge of beginning something new, so it seems to be just about the right time to take a look back and evaluate what went right – and what wrong.
Positive things first: It was my first project involving a significant amount of teamwork and it went pretty good. There was a sound artist doing some of the music, one guy doing QA and a hobbyist voice acting crew. Depending on the work of others and being a “real” project leader were experiences I didn’t have yet. We put together a short-but-polished piece of work which is, in my eyes, something to be at least a little bit proud of. Keeping in mind that Nullpunkt is a pure 2D game, it achieved a very dense atmosphere utilizing very direct user input, strong soundtrack and consistent visuals.
The tutorial is a game level and lets the player try every new concept himself just as he learns about it. At the same time it is used to auto-adjust the games difficulty based on how good he performs. While being implemented here as a very rough concept, the idea of auto-adjusting difficulty is something I really like and might keep track of in future projects as well.
Of course, there are also a lot of things I’d rather not repeat in future projects. Let’s get to the negative part: As in most hobby projects, there wasn’t really a concept right from start. I had this idea of a 2D space game and some thought like “but it has to be awesome“, coupled with a few sketchy images in my mind. Me and two other guys talked about a lot of gamedesign stuff – only to at first discard one of them due to some differences and then the whole concept we’ve been working on. We were making up a whole universe without a thought on how to actually do the content for it. This is why I decided to wrap it down to its essence and do a polished 20-minute game instead of having 8 hours of rough, raw playtime. However, the descision came too late for all the concept work that it rendered useless.
Another aspect of “lack of concept”-related flaws in the project is the infamous feature creep. That’s right. Creeping, filthy little features, disguised as essential or just promising to make everything “so much cooler”. There is actually a full-fledged equipment system in the game engine that is never used. At all.
Why the hell did I implement this? Well, at the time I did, it seemed like it could be of a real use; because I pictured the player bathing in all those awesome RPG elements in the future game that some cranky part of my mind just assumed. If I’ve had a clear concept, I would have been able to tell that part of mine: Nope, no rpg stuff, no complex equipment system needed. How would you earn and actually use lots of new items in a total playtime of 20 minutes anyway?
Another really stupid thing was reinventing the wheel. While learning a lot doing that on a problem, it usually leads to a solution that is a lot less usable than the one that already has been there in third party libraries for years. Also, you invest a lot of time into implementation details, code design, usage analysis and all that stuff. If you are in a hurry or just want to get the job done, this is one thing that should be avoided. In almost any case, existing solutions for common problems will do the work just fine. Trust them. I didn’t.
Let’s conclude this: Next time, I should really do a concept and stick to it from start to end. And use stuff that already exists instead of rewriting it all – even if the existing API might not be as “perfect” as I want it to be. Give it a chance, at least.