Blogging.. I've never really paid much attention to them, I got the idea to start blogging, from my brother, as a way to clarify my thoughts about the tech, patterns and architecture.. techs that I create and use in my framework for games. The tech is heavily based on open standards, with plattform independency in mind..

The long term goal is to create a rpg game, loosely based on Kalevala, but also taking heavy influence from modern fantasy literature, games and modern fantasy culture.. So even though, Kalevala describes people as village peons, without any glorious kingdoms, I think, that kingdoms et al will be added..

The currently used tech in Bolt framework is:

• OpenGL (3.1+, preferrably going to use gl4.x)
• OpenAL
• glew
• glfw 
• C++11 (std::thread, templates, stl)

So.. without any further bullsh*t.. I am about to try to describe the Component/entity/pipeline system..

All of the system revolves around Entity concept, an entity is just a thing, a key to be precise, to describe something. The rest of the system handles these entities, by attaching individual entities to Properties and Controllers, to give the entities some meaning.

http://icegem.net/bolt/lib/core/entity.hpp

Properties are almost like the Model from MVC pattern, when an entity attaches to a Property, the property creates datastructures for the entity, by using the entity as the key. This Property, is almost like a 'Component' from the component system architecture. The entitys real data will be accessed through the Property, so the Property can actually be just somesort of fence or delegate, if such patterns are needed.
http://icegem.net/bolt/lib/core/component/property.hpp
http://icegem.net/bolt/lib/core/component/property/cameraproperty.hpp
http://icegem.net/bolt/lib/core/component/property/nameproperty.hpp
http://icegem.net/bolt/lib/core/component/property/positionproperty.hpp

Controllers are almost like the Controller from MVC pattern. Entities can be attached to Controller, to add some functionality or features to entities. Controllers can also attach properties or other controllers to entities. Also, they carry important information, about the order of executable controllers, "what controllers must be executed before this controller" type of information, aswell as, whether the Controller uses workers to launch work packages (is the controller multithreaded). Controllers have a 'start()' method, that will be called, upon when the controller should be run.
http://icegem.net/bolt/lib/core/pipeline/controller.hpp 
http://icegem.net/bolt/lib/core/pipeline/controller/graphicsbackgroundcontroller.hpp 
http://icegem.net/bolt/lib/core/pipeline/controller/graphicsdebugcontroller.hpp 
http://icegem.net/bolt/game/testapp/states/testapplicationgame.hpp 




Pipeline tries to resolve the issue of main loop, and controller organization, by using the information, from Controllers, and creating a tree hierarchy of dependencies. Once the controllers are attached to the Pipeline, run() method handles updating/calling of Controllers update methods, it waits for the dependencies to finish running, before executing the controllers, futher down the call tree, aswell as running things singlethreaded, on main thread. ( the current pipeline implementation, is, in all likelihood sub optimal, it is the first iteration of this design ).
http://icegem.net/bolt/lib/core/pipeline/pipeline.hpp








So, what can we do with these?
Well the Idea is to get the data as much as possible, decoupled, from the logic, and from eachother (though, the granularity is very important, maybe storing scenegraph data with position data is good idea, for speed, and locality). Once we have PositionProperty, we can write PhysicsProperty, PhysicsController, BulletPhysicsController, and choose either one fo the physicscontrollers, to update specific entities.. We can even have both physicscontrollers running at the same time, updating different entities.
Another nice idea would be to create LowEndGraphicsController and HighEndGraphicsController, and choose on runtime, what kinda graphics controller deals all the graphical rendering, on this particular device. Also, as nothing forces the Controllers to be attached to entities, they can be used as part of high level game logic, as LoaderController, that displays and updates loading animation on the screen, while monitoring worker threads.. and once the workers are all done, the LoadController, can pop itself out of the pipeline, and attach the next Controller (GamePlayController) into the pipeline.

Currently, I am concerned about whether how fast/how much overhead the Entity creation/destruction cycle will cause.. and what kinda granularity will be optimal. But these questions I will find an answer later on.. once I get some real use done on this system.