And now introducing... Aurora Fighter!

pdallago on 2007/09/10 14:32 of Aurora Fighter

Aurora Fighter is a 3d shooter where you navigate a ship through a dangerous twisted tunnel avoiding obstacles and trying to shoot down your opposition. I don't want to reveal any details right now to avoid spoiling the surprise, but I'm sure you'll enjoy the atmospheric feel we went for as you get immersed in the action.

It was a lot of effort, but I think we came out with a really cool game and all of the team is certainly very happy with the result. We hope you'll enjoy playing this game as much as we enjoyed making it.

From the programmer side, let me tell you we had almost decided not to go 3D before the final theme came out, except for the twisted theme, where it seemed 3D could help a lot in conveying "twistedness". None of us had significant OpenGL experience, but somehow we managed to develop an engine from scratch full of interesting features that let us create really fun and challenging levels.

We also learned a lot from previous PyWeeks on how to manage the team and set our goals, and that experience is hopefully reflected in this game.

I'll try to post an updated screenshot later, as the one we have on the entry listing was taken the second day of the competition I think. And hopefully my teammates will chip in with their impressions.

Note: We tested the game and it ran fine on Linux and Windows. However, we found a problem that seems to be caused by older PyOpenGL versions not providing the right aliases.

Luckily, it's a very easy fix. Simply change line 165 of lib/tunnel.py from:

glScale(2, -2, 1)
to
glScalef(2, -2, 1)

(log in to comment)

Comments

pdallago on 2007/09/11 00:16:

I have heard from a few people experiencing crashes or low FPS. If this happens to you, check if you're using pyopengl 3.0. Downgrading to 2.0 always seems the make the game much faster and stable.

This is the latest version in Ubuntu repositories, so if you're using Ubuntu, you should be fine. Windows users should also be fine if you follow the instruction in our release notes.

From what I've gathered while browsing the web, it seems 3.0 has switched from swig to ctypes for the wrapping, and so it's not working quite as well as 2.0 yet. An excerpt from PyOpenGL's homepage:

OpenGL-ctypes is intended to become the 3.x release of "PyOpenGL", that is, it will eventually replace the 2.x stream as the "standard" PyOpenGL. However, to get there, it needs developer attention. In particular, it needs some porting work for new architectures, testing and debugging on all architectures, and lots of work on extension development.

(Many thanks to elias from #pyweek for helping us track this problem.)

ra on 2007/09/11 03:52:

also, you should use a numpy/numarray enabled opengl, it is much faster

richard on 2007/09/11 05:21:

PyOpenGL 3.x will be a little slower than the older 2.x versions, but fundamentally both versions will benefit from a little more experience with OpenGL itself (so you use more optimal OpenGL features like display lists and vertex arrays etc).

allefant on 2007/09/11 18:28:

Well, the difference for the PyOpenGL 3.0.0 in Debian Sid is between playable and not (3.0.0 got like 15 FPS, 2.x got 60+).

dmoisset on 2007/09/11 18:51:

richard: good to know, I should study more about those. We had no experience at all with OpenGL before this pyweek (well, one of the guys had used it for 2d effects), so there are surely a ton of ways to do it better than we did (The poly reduction script for blender saved the day this time :) ).

allefant: We noted something similar. Even bigger differences: you won't get more than 60FPS in aurora because we limit the framerate to that. Without the limiter, we sometimes had a difference betwen 15FPS and 120-150FPS.

pdallago on 2007/09/11 20:41:

richard: I completely agree that using more advanced features should improve performance under both versions, but I personally didn't expect the difference to be so big. In fact, using 2.0 I tested the game on machines with software rendering and it was playable. Also the crashes seem to indicate there is something dodgy going on (although that could also be our fault).