Orxonox

Well, the main loop has to be generated first thing, so the students have something to work with.

It wasn't too easy to actually find the main loop in the old Orxonox, because it hides in the gameworld.cc, but I got a pretty good look at it now.

Orxonox loads stuff and then it loads the standard campaign from the data. There every level is started one after another (and the data loaded into the ressource manager) and this level starts a gameworld which runs on a while(true) until the player or a script event breaks out.

The gameworld checks the input, network, collision detection/reaction every time and does process time calculation, update of the PNodeSystem and display of everything.

My question is now: What can be improved on a conceptual base and what are mistakes and problems not really solved in this system?

You placed your question very well. I think we did one mayor error: we didn't separate the game data carefully from the process itself.

There is the GameWorld and GameWorldData, which tried to resolve this problem. Try to imagine a dvd-player and the dvd itself. In our case the dvd would be the game content (world, models, scripts, everything) and there is the dvd-player which should be the main loop.

You can play everything with the player but the dvd can never play itself (which it did in the case of Orxonox V1). Be sure to draw an UML diagram before starting any serious codings, Bensch and I can take a look at it. Perhaps we will be able to give you some helpful advice.

Alright, thanks for the advice and metaphor

I almost forgot: You may think about adding multithreading possibilities as early as possible. Work that can be parallelizeable:
- Network handling (getting data, sending data)
- Collision detection: each thread handles a set of objects
- Physics

I'm sure there are some papers on the internet that propose some separation of modules such that they can run in parallel. I encourage you to think about it. You don't need to implement it but it's worth taking it into account.

I've had a closer look at the insides of ogre as far as I can do that.
According to what I've seen, it should be easy to implement our own main loop. The root object in Ogre has a renderOneFrame() methode, so we don't have to implement any FrameListeners.
The only thing the continuous loop in Ogre does, is pumping window messages (?), which seems to be very platform specific. Although the ogre programmers don't really consider that an ogre user could implement its own loop except for non-continuous purposes.
Have a look at OgreRoot.h and its source file (specifically lines 722 to 754).

Something about starting ogre on your own:
Tutorial Number 6 on the Ogre Wiki tutorial page 9 covers neccessary steps to fire up the engine (resources, renderwindow, etc.) and it doesn't seem to be that difficult (not that I could do that without many hours of work since I haven't yet programmed any graphics).

I hope I can set up an application that 'uses' Ogre is not 'used by' it, or at least I'm trying to get rid of the FrameListeners, since they don't provide any obvious advantages.