Not logged in, Join Here! or Log In Below:  
News Articles Search    

Submitted by Lars Andersson, posted on November 29, 2004

Image Description, by Lars Andersson

This is a screenshot from the game "Roketz3D" that was created by me and a friend as our contribution to the 3D game coding competition in the course "Advanced Computer Graphics" at Chalmers University of Technology. It was an experiment and it's not even remotely close to being a finished game (but it did win the competition :)

The game is supposed to be a 3D version of the good old gravity/thrust based games which have been around more or less since the birth of home computers. The name comes from the Amiga game Roketz, which I enjoyed alot when I was younger.

When it comes to the controls, going from two to three dimensions adds quite a bit of complexity. We have tried to come up with a reasonable control system, but the result is... hmmm, less than intuitive. To be honest, it's more or less unplayable for newbie pilots, and something should definitively be done about it. After hours of practice though, it's possible to fly pretty well, and the feeling is quite nice. And after all, who said flying a rocket should be easy? :)

Stuff implemented:
  • Descent3 D3L level file loader.
  • Wavefront OBJ loader.
  • Bounding sphere frustum culling.
  • Portal culling.
  • Static world lighting by lightmaps.
  • Axis aligned BSP tree for collision detection and lighting.
  • Dynamic world lighting.
  • Collision detection and response.
  • Animated billboards.
  • Particle systems.
  • Advanced camera movement.
  • Dynamic cube mapping.
  • Definitively nothing fancy by todays standards... But it all came together quite nicely in the end.

    A bit more information is available on the project webpage:

    Image of the Day Gallery


    Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
    Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.

    November 29, 2004, 05:22 PM

    Nice game - feels quite polished - good job.

    Only major problem, as u stated, is the control system which is pretty bad tbh. I think if the control system was less 3D, and if the camera was better - hard to see where going when direction changes dramatically - the game would be a lot more fun!

    Still an excellent effort though guys - well done!


    November 30, 2004, 10:14 AM

    I can't read Swedish, but is your professor Tomas Akenine-Möller? (If so, that is very neat)


    November 30, 2004, 04:17 PM

    man, good work. youve inspired me.


    November 30, 2004, 06:56 PM

    Tomas used to teach the course I was taking, but left Chalmers for another university just before it started this spring. His companion Ulf Assarsson took over where he left... You know Tomas?

    Rui Martins

    December 01, 2004, 01:53 AM

    Well, nicelly done !
    And Nice music too, taking into account the genre !

    But the Controls are insane or buggy.

    And you don't even provide an explanation of How it should be controled.
    It is NOT Relative To Camera View !
    It is NOT Relative to Rocket Orientation !

    It seems that we control a tilt Relative to the Vertical (Y Vector) from the Global Reference Coords. But I'm Not sure.

    In this case, I think the best solution is to make controls relative to the Object (Rocket), which in fact is what happens in reality, but then to be effective, the camera must be ON the Object, or at least fixed to it's coordinate axis, so that you don't loose your reference.

    If you really want to keep the camera free (as it is now), then you should make the control relative to it.
    And you should also hide the mouse cursor.

    Currently it's impossible to control, because you have to know exactly where you are in the world and in what direction, but you loose your perception of the world, as soon as you move the mouse a litle bit too much; camera goes wild, and you are essentially lost.

    Also, It has some problems when firing, check this screen grab.

    And you can also see, that "Warning" Texture (Yellow Strips) is very badly used, they don't match arround the base platform.


    December 01, 2004, 02:21 AM

    Not personally, but only as one of the authors of the almighty Real-Time Rendering book :)

    Nice game anyway, nice ambience, insane controls (which make the game even better;)

    Pierre Terdiman

    December 01, 2004, 02:49 AM

    Err... that's a creative use of Kefrens' Desert Dream module :)


    December 01, 2004, 03:33 AM

    Yep... The Desert Dream was my very favourite demo back in the Amiga days. I was just completely stunned the first time I saw it. I hope no one minds that I've recycled this great tune a bit. Kudos to Laxity of Kefrens!


    December 01, 2004, 04:12 AM

    Hm, I'd say the controls are more insane than buggy. In short, they work like this:

    * The camera tries to put iself a fixed distance behind the rocket... That is, a fixed distance in the opposite direction of the rocket's current velocity vector. However, to avoid too rapid changes of the viewpoint the camera moves with a limited velocity from it's current location towards the wanted location.

    * The camera orientation is then set up to look straight at the rocket from it's current viewpoint, with the static positive y axis as the "up" direction.

    * The rocket is then rotated to point "forward" (or in the camera "look at" direction) with regards to the current camera orientation.

    * After this, the actual mouse controls kicks in. If you keep the pointer exactly in the middle of the screen, the rocket will continue to point "forward". If you now move the pointer up and down while keeping it at the center of screen horizontally the rocket will rotate -180->180 degres around the camera's current x axis. The same goes for moving the pointer left and right while keeping it in the center vertically. It will rotate the rocket around the camera's current y axis. It's when starting to combine both rotations that things get messy.

    We know this system is really really unintuitive... But it also allows for pretty unlimited control once you get the mapping from mouse pointer position to rocket orientation working automagically in the brain. It IS possible to fly very well, but it takes alot of practice. So sure, if this was ment to be more than an experiment, we would definitively have to do something about it.

    Anyway, thanks for the feedback!

    Joakim Hårsman

    December 01, 2004, 08:25 AM

    Nice game!

    There was a commercial game similar to this years ago, called "Lander 3D" IIRC. You could look at that for inspiration on controls, from what I remember it worked pretty well.


    December 01, 2004, 08:32 AM

    I m trying to accomplish somehting similar , so can i ask how do you combine
    diffuse texture ,lightmaps and real time lighting ?


    December 01, 2004, 08:55 AM

    I was going to say the same thing.

    IIRC in Lander 3d the mouse controls were relative to the camera.
    That is, pushing the mouse away from you tilted the rocket (or lander) away from the camera, pulling the mouse towards you tilted the rocket towards you, etc.


    December 01, 2004, 12:10 PM

    Sure. The Descent 3 level files that we use contain lightmap textures for the static world, calculated using radiosity by the editor. When rendering a new frame, the lightmaps are the first thing drawn, using normal GL_DECAL texturing.

    After this dynamic light polygons are blended on top of the light map textures using GL_MODULATE texturing and alpha values depending on the distance from the light to the polygons being lit. Dynamic lighting works by mapping a circular light texture to the environment polygons. The advantage of this method is that we can use large polygons for walls and stuff, and still get fine grained lighing. Of course, this is sort of 1995 technology, but it works quite ok. A short description of the method can be found at:

    An axis aligned BSP tree is used to quickly locate the polygons that need to be considered for dynamic lighting, ie to locate the world polygons that are close enough to a specific lightsource.

    After static and dynamic lightmaps has been rendered, the actual diffuse texture maps are simply blended on top of it all. Doing this using standard blending easily makes the level too dark and gloomy. After some experimentation we settled on blending the textures using "glBlendFunc(GL_DST_COLOR, GL_SRC_ALPHA)", with a constant src alpha value of 0.5. The DST_COLOR component in our case is the combined static and dynamic lightmaps already drawn. In effect, the final pixel value becomes 0.5 * t + l * t, where t is the texture color and l is the static+dynamic lightmap color.

    For object lighting a set of "light" objects representing normal OpenGL point light sources are placed in each room and used to light the objects in that room. A problem with this is that we get an ugly "snap" of lighting when an object passes from one room to another. Careful placement of the light objects may improve this, but a better way would probably be to put the lights in some spatial structure and always draw the lights that are closest to each object.

    The source code along with a Linux/i386 binary is available at

    Beware though, it's a mess! If you run into any problems getting something like this to work just let me know and I'll try to give you a hand.


    This thread contains 13 messages.
    Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.