Since I was actually in town this weekend, I put in a little time working on my asteroids game. First took a stab at sound, but found a minor issue with the sound driver support on my dev machine (an odd version incompatibility in Ubuntu 7.04). I didn't want to get bogged down debugging something that didn't have anything to do with what I wanted to accomplish, so screw sound, I'm moving on.
I went ahead and started on the game engine itself (position updates, collision detection, that stuff), and it was really hard. Not that the code was difficult, but writing sticking to my guns in how it should be written was difficult. I decided that the code I write for the first draft should be the absolute simplest thing that does the job. That means, for example, implementing part of the code with O(N^2) methods, even though I know how to do better. Problem is, it would take time, and paying attention to every detail like that would prevent me from ever getting to something that I could actually run, test, and play with.
So, I have the basic game engine written, modulo a few methods that still need fleshing out. A few more hours of work, hopefully next weekend, and I should have something that's (barely) playable. Yay!
As long as I stick to my guns, I should be able to go back later and implement things the way I want, as it either strikes my fancy or as it turns out to be necessary. For now, though, I need to focus on getting something that works -- a nice engine is for crap is you don't have a car to put it in.
Monday, July 02, 2007
Subscribe to:
Post Comments (Atom)

1 comment:
Ah, ok.
Well, when I write stuff, I tend to do the potentially dumb thing first to just get it to work and then I make it better. The example that comes to mind here is to keep the for loops for the rough draft and then work on vectorizing the code to make it more efficient.
Post a Comment