Green - Day 3

2013-03-27

Well, I must confess, this is actually the post for two "half" days. With sickness, social obligations and the release of Hart of the Swarm and BioShock Infinite it is really hard to get work done. But that is the bane of the hobby developers.

First I got the Scene / Entity concept implemented. I implemented a TestScene object, that should contain a smallish physic test scene. To exit the engine in full screen mode, I implemented the logic in the TestScene. But I don't know if it even belongs there.

There are some issues that are nagging me about this design. How do you implement logic that is not bound to one scene and transport (store) the data from one to the other? I think a "cloud" of entities in the engine may make sense, the scene is just a special entity. This allows for special entities to live longer then the scene.

I think Unreal uses that design. In that case they have a Game entity, that refers to a special entities, such as the scene type, the pawn (player avatar) and the player controller. This design is geared towards FPS, but not a bad idea in principle.

The other issue I have with my current design is that the InputSystem / GraphicSystem abstractions are, in my opinion, premature abstractions. Wrapping OGRE and OIS in a layer of abstraction classes, reduces coupling but significantly increases workload. I tried to throw the system concept fully overboard and take the basic design from the ExampleApplication. But that was a major mess. I can't see me adding Bullet, an audio library and a networking package and retain my sanity with this design.

So, I have decided to keep the basic System idea, but have very concrete systems, such as OgreSystem and OisSystem and let the implementation details shine through. This isolates code but keeps the systems exposed and does not delve in premature abstraction. Finally I can add an extra level of abstraction if it makes more sense, then the holy grail of dependency inversion.

For example, the GraphicSystem would have a MeshVisual that represents a 3D mesh in the scene. The OGRE counterpart are the two classes Node and Entity. Common code to put a mesh into the scene, that would have been embedded in MeshVisaul can still be abstracted in the OgreSystem, such as in a method create_mesh_view. The main difference is that it returns a Node class.