Green - Day 1

2013-03-12

Today I worked through half of the basic tutorial track of OGRE. Yes OGRE still has odd architechtural decisions built in. What rubbs me the wrong way is that on the one hand they try to work in the problem domain and hide implementation details, which is very good inded, but on the other hand in many places you are forced to make decisions about implementation details. I don't mind implementation details and working in the solution domain, but it is either problem domain or solution domain not a little bit of both.

Part of getting ready for the turorials, you need to go though the setting up process. Even though I know how to get Visual Studio to build and link against third party libraries, that level of hand holding felt good. At least the tutorial writers know what they do. The only odd bit is that they want you to copy the executable to the OGRE bin directory. This may be a nice convivinece for tutorials sake, but it ought to go the other way around, copy the dependencies into the project. I worked with the compromise that I just changed the working directory to the OGRE directory.

One insightfull bit was the way they solved the integration into Visual Studio. This is a bit that I was/am struggling about. Their solution is simple and straight forward, use an environment variable. Considering the other two options, adding the binaries to the repository and hardcoding paths, this seems to balance configurability and reliance quite well.

The OGRE SDK comes bundled with OIS and boost. I will use OIS and boost from this SDK. Not that I am a big fan of boost. One thing you need to hand it to them, the level of professionality really improved over the years. This SDK is well build and could be from a well funded development shop. The only quiver I have with it is a self extracting archive; but at least it is not an installer, like openAL.

Let's talk architechture. Although a little bit over the top, I will take the paper Designing the Framework of a Parallel Game Engine as a baseline for the basic architechure.

The basic architechture is simple. The core object is the Engine. The Engine itsself is useleass and is augmented by Systems which do the actual work. Each system covers one "topic", such as graphic, input, sound or physic. The high level game logic is located in the Scene and Entity clases. Concrete and game specific classes are derived from the base class Scene and Entity and use systems to get things done.

In contrast to Intel's paper there is no explicit 1:1 relationship between entities and objects in systems. The interaction between systems, if any, is explicitly coded in the entity. So for example, to react to a colision, the entity registers a callback on the ridgid body of the physic system. If a collision ocurs, the callback will then for example tell the sound system to play a bump sound at a specific location.

The part that makes this architechture very malable, is that entities should be coded in a way that allows a system to not be present. This allows to one codebase to run as client, server and standalone.