The year 2017 is already quite old, but this post goes back into 2016 one last time. That year was a real exciting one and one that changed quite a lot for me. So let’s go back to April 2016.
It’s been about a year when I started this blog. I tried to write a post every 2 weeks, which worked out most of the time 🙂 Time for a short résumé and some good and bad news.
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.
From time to time working on your main project might feel a bit too much like work instead of fun. This might be the moment to participate in a game jam to get your head free from your daily stuff and blow the cobwebs away. Chances are pretty big that there is one near you soon, if you don’t find one check out http://www.indiegamejams.com/.
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.