In the last post about Component-based entity systems I talked about the way you can structure your project if you are using CBES. Now it’s time to start diving into the guts of our implementation to see how it works behind the scenes.
I’ll start with some of the work horses of our framework, namely the Component, Entity and Blueprint managers.
Continue reading CBES – Entity Manager and Co.
In the last two posts I talked about data binding and an asset called Data Bind for Unity I created to use it with Unity. There are more important things in a game than a clean separation between logic and presentation though. But when we started our last work-for-hire project, I realized that our foundation for the game logic was already in a very complete state, so I could concentrate on other parts of the architecture.
At Slash Games Nick and I created a framework (called “Slash Framework” of course 😉 ) which we could use for a wide range of projects. The framework is based on an approach called Component-based Entity Systems or CBES.
Continue reading Component-based Entity Systems: Project Setup
In the first part I talked about the basics of data binding, namely the data context and the data property, which define the data that is provided from the logic for the presentation side of your game. This makes it possible to visualize the data and react on data changes.
One part is missing though: Giving the presentation side a possibility to send desired actions into the logic, e.g. when the user clicks on a button. This feature is implemented by commands.
Continue reading The “Magic” behind Data Binding (Part 2: Commands and Data Tree)