mangobrain home

Sigh.... not a complete success, but fun nonetheless

Posted on 2005/09/03 23:53
Edit: Clicky!

Oh well. ACCELERATOR has been submitted. It's playable, but by no means finished. It lacks:

I've never done one of these competitions before, so please be nice. I really like the visual style of the game, and the speed and feel of the gameplay is close to what I wanted to achieve, but overall this can't really qualify as much more than a prototype.

I haven't got the time to implement any of what I know is missing before the deadline; it's less than half an hour away as I type. When I sat down to work on Friday evening, I had a semi-functional menu, and a scrolling tunnel. Since then, I have not slept (it's now 1 AM Sunday morning here), and have implemented the HUD, the first-person control method, tunnel wall collision detection, ALL the particles (and the lightning), scoring, shooting, power and shield mechanisms, and so on and so forth. I'm done.

If I ever continue this project post failing to win PyWeek, I'll be adding sound, GREATLY tidying up the particle instantiation/collision system (there is currently a *lot* of code duplication in the main game loop), adding graphical transitions between menu pages and upon loss of a life, and making better use of PyODE.

In my previous diary entry, I mentioned how much I hate collision detection. Today, I spent literally 5 or 6 hours trying to figure out how to align a cylinder in PyODE to match the "electric arcs" I have in my game. Mainly because of (poorly/un-documented) differences between ODE and OpenGL coordinate systems; partly because PyODE doesn't provide any interface to some of ODE's more useful rotation functions, such as quaternions. It also doesn't seem to provide any access to the spaceCollide or spaceCollide2 functions, and so I ended up doing all collision detection manually; hence, you'll see a lot of loops calling ode.collide() within the gameLoop class (if you dare look that far down in my code).

Also, because I started writing the first-person camera and tunnel collision code without any intention of using ODE, I've ended up using ODE *only* for collisions, not for tracking the movement of objects - hence you'll also see lots of calls to ode.GeomObject.setPosition. I have a sneaking suspicion that this might have effectively disabled ODE's ability to do swept collision tests, and hence negated one of the biggest advantages to my using it - but I'm not sure how I'd go about finding out whether or not this is the case, and certainly don't have time to go back and do things properly. Anyway, it *did* (eventually) get me my oriented cylinder/sphere collision test, and as that was the only one where orientation mattered (all other collisions are sphere-sphere), in the long run it probably didn't slow me down much more than trying to write a decent implementation myself would have. Meh, I dunno.

Please attempt to enjoy my half-finished entry. It's only the third game I've finished in my entire life, and the first 3D one that has ever even got off the ground.

Add comment
Comment by dOb on 2005-09-04 11:10

I'd really like to see a fixed version of this. It was so fun to play, but the missing bullets are annoying ;).

Comment by mangobrain on 2005-09-04 12:28

Yeah - I noticed, but too late to do anything about it. It's got to be the hackish way in which I "integrated" ODE support. Also, bullets themselves - and, in fact, most of the particle classes/generation/collision - are incredibly hackish. Basically, if you look in accelerator.py, the code starts of well with nice clean Font and Texture classes, progresses through some useful pre-packaged OpenGL routines, gets a little bit hairy around the menu stuff, gets very hackish in gameLoop and the particle classes, then gives up around the entry point and starts shoving things in globals....