A short introduction to the core concepts of Unity and our use of them.
About a year ago we published “One year with Unity” about our efforts to make the Bolibompa app with Unity. Since then we’ve managed to evolve our app with a new concept, and have also refactored our architecture.
Core concepts in Unity
The Scene is one of the fundamental concepts in Unity. It’s the place where you put all the objects (e.g. a player, images) for your game.
So, let’s take a look of our app from within Unity. This picture shows the most central scene that welcomes the user when the apps starts. We call it the playground-scene:
As you may notice we work with 2d objects (they are flat even though our designer has created a good depth look, – look at the tv) except for the dragon and our egg which are 3d models.
In Unity, these “objects” are called GameObjects. These are Unity’s “core entities” and as a programmer you decide what kind of game objects they should be by adding different components.
If we look at the 2d images in the scene they have a “Sprite renderer” component that gives that game object the ability to show a 2d image.
All game objects also have a Transform component that gives them a position, rotation and a scale.
Game objects can have all kinds of components that give them different behaviours and they can also have scripts containing the game logics.
One really important factor for us to consider when we choose technical strategy is that we constantly add new mini-games. We aim to develop these as independently from each other as possible (self contained) and in Unity this can be done by using separate scenes.
If we click on the closet in the garden, we open up the “dress dragon” game. That game has its own scene.
By doing so we are able to unload the old scene (and belonging assets) and load the new scene.
Share objects between scenes
We share some things between our scenes. We do want to keep our Dragon alive between them and we also have some more common things like sound handling.
To share common things we have game objects that are not destroyed when we switch scenes. We call our most central gameobject “Application Manager” and that holds a reference to our Dragon and a few other things that are not destroyed when we switch scenes.
There are not so many best practices for structuring code in the Unity world. We have developed our own concept of “modules”. A module contains the code that belongs to one of our mini games. The dress dragon scene has a module called “DressDragon” and in that module we use an MVC structure of our code.
The “main” controller of the dress dragon game inherits a “Module” class that we developed. By doing so we can do things like calling all our modules and getting them to be non-interactable. One example when we use this is when our timer kicks in (the timer can be used by parents to set a countdown timer for when the app should be locked) and then we must set all or modules to be non interactable.
So far we think this strategy with scenes works well and it also seems like this is a common way of structuring apps in Unity. One thing to consider is how we load our scenes. In Unity there are two ways to load scenes. Either you completely unload the scene you came from or you just load the new scene “additive”. This means that you keep your old scene in memory. One benefit of that could of course be load times between scene changes, and a disadvantage is of course the memory consumption. Perhaps we need to think more about scene handling when our app grows.
Our code structure also seem to work quite well. But of course, we always need to make things better. Hopefully we have a rather solid foundation to build on!