In an event-driven system like our Slash framework there comes the time when a feature becomes a bit more complex and the order in which events are triggered is important so the feature works correctly. In this post I’d like to point out how which problems occurred for us during development and how we solved it.
After the last posts about our component-based entity system framework called Slash I was regularly ask why one should use a component-based framework although Unity itself is already component-based.
While it is nice that Unity itself isn’t build in an object oriented way and might be even good enough for small projects or prototypes, you should really separate your game logic completely from the Unity engine in bigger projects.
I already wrote some posts about data binding and our Unity asset Data Bind for Unity which gives you a clean way to separate your logic from the presentation of your data. The last parts were mostly about the logic side though, so let’s have a look how to combine those two.
Right now we’ve got a player character in our game who can shoot some bullets out of his weapon. Both the player and the bullets were defined in the LevelSystem, defining their components and settings hard-coded.
This is surely not what we want for a bigger game where a game designer should be able to adjust the settings without the help of a programmer and where we don’t want to recompile the game each time we change the values.
This is part III of a series where I’d like to show with the help of a practical example how to start a small game with a component-based entity framework. Hope it gives you some ideas how to structure your own games.
This one covers the reloading of the weapon, a feature that I left out on part II. Furthermore I’d like to have a look at a helpful utility class called CompoundEntities.
In my last post I started a little sample project to show you how our component-based entity framework is used in practice. The game is a little top-down shooter, but so far only movement is possible, so it’s more of a top-down walker. Time to add some shooting!
During the last weeks I wrote several posts about our approach of a component-based entity system:
- Part 1: Project Setup
- Part 2: Entity Manager and Co.
- Part 3: Event-driven systems to implement the logic
I’d like to wrap it up with the next posts, connecting all the single parts to a working game.
This post will give you another bunch of information how to implement a component-based entity system. We talked already about the way to setup a project in a clean way and the way data is stored. Now we’ll have a look where the logic of the game has its home.
On this note I’ll also explain the event-driven way of our framework. As a system is very self-contained, events are the way to communicate with other systems and the world outside a system in general.
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.
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.