There is no better way to raise your productivity than using good tools during your development. This way you can concentrate on developing the things that make your game special instead of reinventing the wheel for a lot of already solved development problems.
I’d like to give you a list of the most important tools, middleware and assets I have used in my past projects. See if one catches your eyes and check if it saves you as much time as it saved me 🙂
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:
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
Unity3D best practices
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: