Skip navigation

Category Archives: Game Development

I just read a fantastic post on AltDevBlogADay by Alex from Media Molecule. In “practice makes perfect – a ramble with bad capitalisation”, he argues to not be afraid to rewrite code. It really hits home some of the key issues I’ve been working on with my programming, namely, being overly concerned about writing the best code the first time. Not that it is a good idea to write sloppy code, but making things too generalized or too optimized too early is a bad idea. A really great read and very inspirational.

Being productive is hard when it’s your free time on the line

I want to make a game. Specifically, an indie game. Armed with nothing but Xcode and pluck, I’m going to make a game and put it on my iPad. Maybe other people’s iPads, too. For a price. Well, that’s the plan anyhow. I’m beset on all sides “obstacles”. Some of them are nice to have. I wouldn’t trade my wife or a non-stop parade of new, shiny video games for anything. (Note to wife: Do not worry, you rank higher than the games :) )

Others are more problematic. Like, constantly changing my mind on just what I want my game to be. Or refactoring some subsystem to make it better rather than done. I’m on my third iteration of my game engine and there isn’t even a game in there yet. I thought about it and I’ve come up with a more structured plan that might actually result in creating something others can see.

Four easy steps when you refuse to make up your mind

  1. Nail down the design, any design.
  2. Isolate the smallest possible part that could be considered a game. Focus on that.
  3. Implement each feature just up until it works; immediately move to the next.
  4. When all the feature are “done”, then and only then — re-evaluate and improve.

Now that might seem fairly obvious or too restrictive. My issue is I tend to get lost in the details, needing to lead with my best foot, rather than just taking the next step and actually moving forward. I just need to repeat to myself:

> It’s not going to be perfect. It will have bugs. It will have areas that need improvement. It might even suck. Fix it in the next pass, just finish this one. Better comes later; never first.

That’s not to say I plan to release my first-iteration, half-baked POS, but holding something that I can actually play and feel in my hands is an important step on the journey to a polished, App Store worthy game.

For all the world to see

I read this post on Mystery Coconut that talked about their plans for “open development”. Every little part of the game development process would be discussed out in the open where the world was allowed to comment and participate. I intend to do exactly the same. My idea isn’t so original I need to protect it so I can maximize my glory and profits. If someone wants to steal my idea and release it themselves, great! I get to play it and move on to the next project. Or if I don’t like it, I can continue to pursue my vision, my way.

I’m also a better engineer than designer, so feedback will only serve to make the game better, aid my design skills, and keep me moving forward. Additionally, at some point, I’m going to need help. At the very least, my art skills suck. Nor do I know how to make a compelling sound track. And certainly a few more engineers might help. This blog will help recruit and let others know just what they are getting into.

Oh, and the game I’m making? I’m calling it Joyride. At least, that’s my goal.