Didn't you notice that Yake doesn't have concept of level? ;) Level is surely a general thing for such a general use engine. I'll share a couple of thoughts on this… What is a level anyway? It is a (part of) world where player/user finds himself after “new_[game]→settings→begin”. It can be a creepy underground filled with monsters or sunny landscapes … again filled with monsters!! :D So what are the primary components? Say, solid ground! So many games use some kind of terrain. 4×4-car-simulation will need it, run-and-gun-on-air - definitely will! Even underwater vehicles will like to have some in ocean depths ;). FPS also likes to have some buildings with numerous rooms. That is not terrain but also a level! But what am I talking about? All of this is so obvious to anyone who ever played a computer game! :P So, let's get down to the implementation.

From the design standpoint we could have:

• Graphical level representation
• Physical level representation
• Event/trigger level representation
• Level actor concept

How could that be implemented?

• First of all - graphical level. That is like the easiest part to implement. There could be an abstract interface GraphicalLevel with concrete implementation in a form of plugin. The obvious choice for terrain is Ogre's PagingLandscape2! In case of Ogre graphical level is implemented via various scene managers…
• Physical level can be somewhat harder… Some paging solution for terrain is required. As Psy already noted on IRC there could be a physical terrain with on-demand chunks loading. It should work somehow like: if actor approaches terrain, load terrain chunk in the vicinity. Physical data could be generated from the same set of heightmaps that are used for graphical part ( PagingLandscape ).
• You already noticed actor? It is needed not only to make physical implementation easier but for another important reason… Triggers! Wouldn't it be nice to have them? No, not nice, they are required!

Putting it all together

New Yapp component yapp::level. Physics, graphics, events + actors if in short. :) I'm now thinking of actual C++ implementations for all of these. For some of them Yake is already ready, others need to be invented.

class Level
{
public:
 // create/manage graphical, physical, event representations
 // terrain, indoor, mixed
private:
 // Terrain should have some optional properties like ability to deform.
 LevelProperties properties_;
};

Use case

Underwater ROV simulator

What do I need from suggested new component? First of all - physical component with actors… Ability to acquire terrain height at given point (x,y). Visual component, for wich I already chosen PagingLandscape2.

Extra note: Collision detection

Some levels have separate collision geometry that is a simplified version of the graphics geometry. The 3D engine renders the complex graphics, and the collision detection is based on the simpler (faster) version. Should there be a 3rd “collision geometry” variable? I think so.

(This extra note brought to you by Ricky28269)