One year with Unity

In the Bolibompa team, about one year ago, we started an evaluation of the Unity game engine & development tool in order to verify if it could be an alternative for building native apps for Bolibompa. This is a recap of our experiences so far.
But first a short background: We are building a Bolibompa world, an app with both a video player and mini-games/interactions. We did that with web technologies, mainly with the javascript framework pixi.js.  To make a long story short, we came to the conclusion that we had to many performance problems and a feeling that we never would be able to get the experience we aimed for.

Why Unity?

Well, first of all google it and you will at least conclude that it’s a huge player in the game dev field. But to summarize, it’s a strong game engine and development platform with it’s root in 3d development. It’s one of the market leaders with a large community and an also an “Asset store” with a lots of pre build components and solutions.

It provides a lot of flexibility (and challanges for that matter) with the mixture of gui editing and code. The possibility to visually build scenes and import models,  animations and apply logic through the code editor. Code can be written in JavaScript or c#, where we choose the latter.

Our challenges

  • Unity built in strengths: There are a lots of stuff ready to use. For example, if we look at the picture below that shows our “balloon-game” we started out that development by coding most of the logic in C#. We moved the balloons by using code and to show a pop-balloon (when the kids smashed them) we changed from a solid balloon to a pop-balloon sprite. Well… that worked…  but we soon realised that we should’ve used the physics engine in Unity together with the particle system…  These things that are integrated into Unity are there for a reason and they are really well designed and great to use. After using the physics engine we got balloons that moved more naturally and also got better and cleaner code.
  • Architecture: Unity’s “default way of doing things” is to have a very tight relationship between “game objects” (created in the editor) and code. We wanted to find out what kind of different strategies and patterns other team used and tried to google game developments patterns / architecture for Unity and ended up a little bit disappointed. With a team of developers with long experience in more traditional system development we wanted some kind of structure. We did find a dependency-injection framework called strange-ioc but we wanted to start out with a more lightweight approach. The solution was to have our own mvc-style framework. In it we have controller and model objects that dosen’t inherit Unitys default parent class MonoBehaviour and the controllers are bound to the view from a “application loader” rather than bound directly in the Unity editor. This gives us a more flexible design and we could also do the controllers as singletons. E.g. we can instantiate several game objects (views) that share the same controller.
  • Modules: We build modules containing our different “mini-games” within the app. E.g. The balloon game is one module and “Hide and seek”. We aim to build these modules so that they are self-contained.
  • Communication: We have overused Signals – events between our modules. Everyone talks with everyone. A problem that we identified quite early, that we thought was manageable but turned out to be a pitfall in our code that by time growed too deep. Now we talk about how to solve this. Perhaps we need some kind of application manager that knows to handle different scenarios. E.g. if we start “the balloon game”, every other mini-game should be deactivated or perhaps non inter-actable.  

Future

Right now we are in a discussion on how to take the next step in both our conceptual journey and with the technical challenges that come alongside. We learned a lot but we have still lots to learn…as always!