So we got our window management system in a nice, generic state already during part 1 and part 2 of this blog post series. This (final?) part adds our asset Data Bind for Unity to the equation. This makes sure that not only our UI setup is capsuled in its own scene, but the data the window expects is passed to it when it is opened. This way each window becomes very modular: It can be tested independent from the rest of the game and you can put it in and out of your project pretty easy with just a few lines of code. Check out the source code of the fully functional example.
Time for part 2 of how you could manage your UI windows in Unity 5.3! Part 1 brought up some questions that I like to deal with first. Things like having only one root canvas for all windows, preloading windows to not have a lag when opening one and animations when opening/closing a window.
If your game contains at least some user interfaces, you will quickly run into the need of manage them in a central place. In our past games we developed a generic window manager that can be used in any project. It takes over the all the loading/unloading of windows and makes sure windows are not opened multiple times.
In the last post I gave a quick overview over the new event system that was introduced with Unity 4.6. Following up on those basics I’d like to give you some insights about the customizations I made to fully utilize the possibilities of the event system in our current project. The first big change I made was adding a generic Drag & Drop system by using an own input module derived from the existing PointerInputModule.
In version 4.6 Unity introduced a new powerful event system which takes care about how input is routed through the game. It allows a clear order which elements get the inputs before others.
Every now and then there comes a time in a project when it would be nice to be able to write a unit test for a new or already existing feature. The reason could be that the feature is quite complex and we like to make sure to get the basics bug-free before going on creating all the stuff around it. Or you have an existing feature that doesn’t really work the way it should work and it is pretty tedious to find the bug in the running game.
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.
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 🙂