25.02.07
Rapid Prototyping and Shooters
It seems like a slow time for indie shooters at the moment. I guess the good news there is I have a bit more time to work on some of my own projects. I’ve mentioned Kloonigames and rapid prototyping before and I’ve started on my own quick, little project.
I’d like to recommend two posts at Kloonigames, here and here. Both are a great resource to other articles and ideas on rapid prototyping. All of this has me thinking, though, about what rapid prototyping means to me.
I don’t think I can create a game in 7 days. It’s not that a week isn’t enough time, it certainly is, but I just don’t have enough spare time to commit. So I think I’ll take a little longer, certainly less than a month. So far, I’ve only spent 11 hours on my new project, but I feel it’s more than 1/2 complete. Is that the same as rapid prototyping?
I have made one concession to my programming style. I used to add a feature, and iterated it until I had the final “look” and behaviour. I’m no longer doing this, I’m adding a feature with simple graphics (yes, even simpler than my “finished” graphics
) and moving on to the next one.
I don’t want to get into a postmortem before its time, but I do have a simple observation about my experience with rapid prototyping so far. It’s something that I think might help out those wanting to get into indie game development. It’s all about your software libraries. Sounds simple, but it’s not always so apparent. I’ve been able to get something up and working very quickly because I’ve got a few other projects that I can draw code from. I’m thinking I should write another article on the basics needed for writing a shmup, or any 2D game. Here’s a hint, make sure you have a good vector class to work with.
Anyway, a rather boring post. But I want to do more articles on shooter development, in the hopes of encouraging more experimentation in them. I think this rapid prototyping is a particularily good way to get this.













Ryan said,
February 25, 2007 at 7:32 pm
I think you have a very good point about knowing your software. I would have had my next game compleatled by now if I wasn’t learning OpenGL. I can make games fast but they don’t have as much “meat” as a game I would have spent months on. Gun Ranger X took a whole summer to make, I was fighting a unfamiliar programming lanugage most of this time. I could make Gun Ranger X in about a week or two now, but back then I was fighting the language itself. Also, it’s a well known secret that rock from the 60′s to 80′s is good for the moral.
-Can one program without music in the background? I think not.
the2bears said,
February 25, 2007 at 8:01 pm
No, but then having 60s music in the background leads to creating odd physics engines and wrapping games around them
But yeah, your OpenGL point is a good one. I used to spend a ton of my programming time working out bugs in my rendering code, or working out just how to do collision detection. Even simple things like how to format the game loop, how objects become active in the game… now that’s all automatic, and I’m spending most of my time implementing the ideas. And that’s a good thing
Bill