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.
You would expect a new, coding-focused article here today. But as I just returned from a 4 days trip to Berlin and I am a bit weary. Therefore I thought I just do a little wrap-up of my Quo Vadis, Amaze and Berlin impressions.
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.
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.
After reading through the documentation I wrote for the asset, my co-founder Nick suggested to add an article what goes on behind the scenes. This also sounded like a good idea for a blog post, so I’ll just be lazy and combine those with this dev blog post 🙂
It’s time for the first real post! I’d like to give a short overview about the current projects I am working on which, so you’ll get an idea what I am doing and where my focus lies at the moment.
Even before Nick and I started Slash Games, we already had some lines of code which we used for several projects, mainly Game Jams and hobby projects. This code base was further developed over the last two years as we got more experience with component-based entity systems and framework architecture in general.
Except one work-for-hire job (which was a website), we did all our projects with this framework. It changed quite a bit in the beginning, but now it’s in quite a solid state that we think about publishing it. We already put a version online last year, but just told some friendly developers about it. There are plans to extend the documentation with tutorials and examples and to spread the word about it. It would be fantastic to see what other developers think about the architecture and get some ideas how they would further improve it.
The core of the framework forms a component-based entity system (CBES) which solves many problems that object-oriented architectures have. Especially in game development where the game structures often change quite a bit during its development, it is nice to have an architecture which is flexible enough to allow easy composition of the objects in the game without changing any/much code. If you never heard of CBES before, here are some articles about it:
- Game Models – A Different Approach (Part 1)
- Game Models – A Different Approach (Part 2)
- Game Programming Patterns – Component
- Component-based Entity Systems in Spielen (German)
If you are wondering why three out of the four articles are written by Nick: He teaches game development at some universities, so he also wrote some articles about component-based entity systems. If you like to read some other opinions about the topic, just follow the references in the articles.
Data Bind for Unity
If I’m not working on our current project, most of my coding time goes into my “Data Bind for Unity” asset which recently hit the Unity Asset Store. As our framework turned out to be pretty solid and didn’t need many adjustments anymore, I focused a bit more on the interface between the game logic and its presentation (mainly through the user interface) to the player.
MVVM and NData
We used NGUI for our user interfaces in the last years and about 1.5 years ago I bought NData from the asset store. It provides an additional layer between the logic and the user interface to draw a clean line between those two. It uses the Model-View-ViewModel (MVVM) approach which is also used in Microsoft’s Windows Presentation Foundation framework. This approach is based on capsuling the data into data properties which inform the user interface when they change. Those data properties are stored in a view model/context.
For the view you use existing UI frameworks, like NGUI or Unity UI and the models are in your game logic of course. NData provided the view model part now with its data properties, commands (so the UI can send some actions to the logic) and data bindings.
Their approach was really nice and prevented references to any NGUI scripts in most parts of the game. Instead you would create e.g. a PlayerContext for your main character which holds data properties for its name, its health, its amount of remaining ammo and so on. In your UI you reference this context on the UI root and bind the data to the particular controls e.g. the health display by using the name of the data property.
Outgrowing the 3rd party asset
NData helped me a lot to understand how a clean separation can work, but also had some shortcomings which especially complicated its extensibility. First I started writing some extensions for the asset, but soon I realized that the problems lay in its core implementation. I began to adjust some code of the asset itself, a thing I really try to avoid at all costs as it makes updating an asset really cumbersome. The good thing was that it gave me real good insights how all the tiny parts really work. NData probably started with a small set of its functionality and grew from there. That would explain some design decisions.
I proposed some changes and bugfixes to the developers on their Unity forum thread, but quickly realized that the development of the asset already stopped. This was the point when I decided that I should probably write an own data binding asset from ground up to solve the shortcomings of NData and have an asset which can be extended in the future.
The main goals for Data Bind for Unity were:
Clean separation of logic and presentation: No UI script should be required to be referenced in a game script to change the user interface.
Big collection of generic bindings: The bindings which are delivered with the package should be easy to use in a variety of projects, so all the projects have to provide would be the game-specific data contexts.
Easy extensibility: If an additional binding should be required, it should be very easy to add a new one by deriving from some existing base classes. By no means changing the core functionalities should be necessary.
Exchanging the UI system without touching any logic: The development of my asset started when Unity 4.6 with its new UI system came out, so suddenly there were two common UI systems. Data Bind for Unity makes it very easy to switch between those two (and even use both) without touching your code.
Current development status
The first version of Data Bind for Unity was released in the Unity Asset Store just 1.5 weeks ago. I also wrote some documentation with tutorials, examples and an API documentation, so new users have an easy start with the asset. I hope to get some feedback soon from the first developers who tried out the asset in the official Unity forum thread.
We are using the asset already in our current project, so I had the possibility to add a great amount of additional generic bindings to the package as well as refactor some code and add additional comfort functionalities. All in all the asset is working very well already, most of the tasks I have on my list will increase the ease of use, but the core seems to be pretty solid.
Yesterday I added another step-by-step guide for the example for a data collection, today I will upload a new version with the improvements of the last weeks. The more the asset grows, the more I’ll raise the price, so early adopters get it for the cheapest price of 10$ right now. You can easily determine if it’s worth for you if you calculate how long it would take to create the asset on yourself and multiply it with your hourly wage. If you come to the conclusion that it’s to expensive I really like to hire you 😉
You may have noticed that I’m quite into data binding at the moment (the section got a bit longer than it should be already). In the upcoming weeks I may post some in-depth articles about the topic therefore, but in the future this blog will become more diverse, containing posts about:
- Component-based entity systems
- Coding guidelines
- Unity3D best practices
- Game Jams
- Build servers
- Workflows for working in a team
If you have any wishes for topics or opinions on the post, just write a comment. I’m really looking forward to some feedback!
If you like to get some more information about me, Slash Games, Data Bind for Unity,… here are some links to read on:
I’m in the professional game industry for about 6 years now, worked for two bigger companies and founded my own game studio Slash Games two years ago. I could code quite well already when I started my studies in 2004, so I thought I knew almost everything when I finished them in 2009.
But there’s a big gap between coding and coding “with style”. As with any problem there is hardly ever only one way to solve it and so it is for coding. But there are definitively bad and there are good ways to solve them.
Almost no day passes by without me learning something new to improve my coding style and most of this knowledge was brought to me not via official documentations, but through personal blogs and tutorials.
A few days ago I stumbled upon http://simpleprogrammer.com and there was this offer for a free E-mail course on the topic of starting an own developer blog. I never saw myself as a big writer, but that changed a bit last year with a blog entry about how to run Unity3D on a server with no graphics card and two articles for the German developer magazine iX about client-side prediction in multiplayer games and an introduction to behavior trees.
So I signed up and here I go. I plan to give back some experiences about successful ways to structure your code, especially if you use Unity3D. Hopefully my initial motivation will last a bit but to be realistic: Don’t expect more than 2 articles a month, in the end my co-founder Nick and I have to use our time earning money to develop our own games!