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!

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

man, good work. youve inspired me.

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?

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.

http://ruimartins.net/dump/roketz000.jpg

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

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;)

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

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!

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!

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.

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

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.

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:

http://www.flipcode.com/articles/article_omnipointlights.shtml

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 http://www.dd.chalmers.se/~f99laan/roketz/roketz.tar.gz

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.

/Lars