Having written and finished Very Angry Robots, I would like to explain how I was able to finish it, because I would like to be able to repeat that success. You could call these critical success factors if you like. As I write this, I’ve become aware of Derek Yu’s post on finishing games. I couldn’t have put it better myself, but I’ll try to explain what I think worked for me.
What went right?
I used Processing. As I alluded to in my last post, Processing makes it very easy to play around with ideas. I had considered using Unity, but ruled it out as my goal was to write a 2d game using Java for an eventual port to Android. Unity doesn’t support Java and is essentially a 3d engine, so that ruled it out. I wouldn’t say that language/environment choice was the number one success factor, but it certainly helped.
My goal was achievable. I’ve written simple 2d games before in a number of languages, most notably Python, C++ and Blitz Max. Choosing to write another 2d game meant that there was nothing in what I was writing that required me to learn new technical skills. The importance of this cannot be overstated. My challenge was to get myself to finish my own projects. Additional technical challenges would have been rabbit holes down which I could have disappeared for a long time as playing with new technology and learning new technical skills is a lot of fun in its own right. However, so is applying those skills to create an end product. For a personal project, with limited time available, you have to choose, and in this case I chose to stick with technologies that I knew.
The end goal was well defined. Very Angry Robots owes a lot of its ancestry to games like Berzerk and Robotron 2084. This meant that I didn’t have to spend a lot of time designing the game as I had a very clear idea of what I was aiming for.
I was able to plan. The combination of a clear, well-defined end goal and a good understanding of the technical challenges meant that I could define some clear milestones and the steps required to achieve them. The fact that I had a plan kept me on track throughout the entire exercise. I don’t think there was a single night where I sat down at my keyboard and didn’t follow the plan. This kept me very tightly focused on delivering a game.
The graphics and sounds are simple. I knew that I’d be doing this without help, so I constrained the graphics and animations to what I could do with paint.net. The result is obviously programmer art, but it fits in well with the retro theme. Similarly, the sound effects were made with Dr Petter’s excellent sfxr, and my daughter provided the voices for the robots.
I had a deadline. I didn’t really consider this at the time, but looking back it is obvious. I started work on the game in early July, knowing that I’d be going on holiday for half of August. I’d originally planned for the development to be spread over several weeks, working at a rate of about 10 hours per week, but I must have kept that deadline in the back of my mind as I had done the bulk of the work before going away. Clearly I respond well to deadlines.
What went wrong?
The code is not clean. I tried to keep things simple, following the DRY principle (Don’t Repeat Yourself) where possible. However, I didn’t spend a lot of time keeping it tidy, and it shows. For example, I spent some time writing an Animation class for use by mobiles. Some of the mobiles use it, but others just draw images directly. I also relied on inheritance for re-use in several places, which is something I really don’t like doing, and ended up with a rather odd class hierarchy. I think a tiny part of the problem stems from not having refactoring tools in Processing, but largely it’s my own fault.
The code is fit for purpose, in that it allowed me to deliver a game, but I wouldn’t exactly call it scalable or clean. As a result, my ongoing attempts to separate the game code from the Processing-specific code are taking longer than I’d expected, which means that the Android port is likely to take a while. I’m perfectly aware that there’s a version of Processing that runs on Android, which is an achievement in itself for which those Processing boys should be congratulated, but I’ve tried it out on my Nexus One and it’s just not quick enough for my needs.
Conclusion
I’ve reached a point at which I know that I can repeat my success. What made it possible to deliver Very Angry Robots was ultimately having a clear idea of what I was doing, and not mixing learning with delivering. I’m now keen to repeat this by porting the game to Android so that I can play the game on my phone.
No comments:
Post a Comment