Why to use a custom CBES architecture within Unity

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.

Continue reading Why to use a custom CBES architecture within Unity

Creating a component-based game (Part IV: Blueprints)

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.

Continue reading Creating a component-based game (Part IV: Blueprints)

CBES: Creating a component-based game

During the last weeks I wrote several posts about our approach of a component-based entity system:

I’d like to wrap it up with the next posts, connecting all the single parts to a working game.

Continue reading CBES: Creating a component-based game

Component-based entity systems: Event-driven systems to implement the logic

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.

Continue reading Component-based entity systems: Event-driven systems to implement the logic

CBES – Entity Manager and Co.

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.

Component-based Entity Systems: Project Setup

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

Which topics can you expect from this blog?

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.

Slash Framework

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:

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

MVVM overview
Overview Model-View-ViewModel (from http://www.codeproject.com/Articles/100175/Model-View-ViewModel-MVVM-Explained)

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

Logo Data BindNData 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 😉

Upcoming posts

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
  • Git
  • 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: