Unity 2017 Optimizing android games – Case study for Break It

In this article we will share how we optimized our upcoming game Break It to run smoothly on low end android devices. This is continuation of our devlog series on the game Break It. Before we talk any further, below are two videos which shows the comparison of the game before and after optimization.

 

Before reaching to a solution, it is very important to understand the problem. This is very crucial when it comes to optimizing games in unity. At first we need identify the problem. What is causing the framerate to drop? Which part of code is taking the most time? Is the problem on the rendering side or due to the physics? Or is it something else? Unity has a very handy tool called Profiler which helps us find the root cause of the problem. I must again stress that in case of optimization, finding the cause is 50% of the work done. The root cause can vary from game to game and hence it is important to use the profiler well and find out the bottleneck. Once that is done the focus shifts to solving the issue.

Optimizing “Break It”

Upon profiling, we found that it is the physics calculations of the game that is taking up the chunk of our time and hence reducing the fps. The second most expensive operation was rendering.

Profiler before optimization
Profiler before optimization
Profiler before optimization

 

 

This is how we went about fixing the issues. A big lesson that was learned over here is that there are a lot of things which we could have standardised and implemented right from the beginning. Of course there will be specific issues that one encounters only after profiling, but most of what is written below shall be incorporated in the development process right from the beginning.

Object Pooling

Initialising and destroying gameobjects can be a very expensive operation. And if a game has a lot of them, it might hamper the fps. For example creating and destroying multiple bullets. Or in this case the ball which is created when the player touches or swipes the screen and is destroyed a few seconds later. Object pooling suggests that instead of creating and destroying several gameobjects of the same type, we create a pool of them when the scene loads and set them all to inactive. And when the object is required, we just enable them from the pool and instead of destroying them, we just disable  them and put it back into the pool. This decreases the expensive operations during the gameplay as we are not required to instantiate and destroy frequently used gameobects. There is an excellent tutorial about this on the Unity website.

Device Filter

This was a bit strange but it did affect the performance of our game. Under the android player settings we have an option for device filter. We used to leave it default to FAT as we wanted it to run on as many android devices as possible. This is still possible if we create separate builds based on architecture because play store has multiple apk support. It automatically selects the apk to be downloaded based on the user’s device. So we created separate builds for Armv7 and x86 . Our low end testing device was an Asus phone of 2014 model running android 4.4 . The architecture was x86 although the instruction set supported were both x86,armv7.

So running an x86 build on this device showed an improved performance. An added benefit of this approach is that the overall build size will be less since specific code would be compiled depending on the architecture.

Mobile device info

Physics Calculations

This was the most expensive operation in our profiling. We tackled it in the following ways.

1.  Decrease the number of joints – We had a few scenes which used a lot of character joints and hinge joints. That is how our chains were made. We decided to reduce it by increasing the scale of individual links and hence using fewer links which resulted in fewer joints.

2. Mesh colliders – Mesh collider is a costly component. If the scene is using a lot of them one should try to replace it with default ones (sphere, box etc.). In our cases the broken pieces of the cubes were using mesh colliders, we decided to replace them with box colliders.

3. Static colliders – Static colliders are a big no and one should avoid them in all possible ways. To quote unity’s documentation “it’s extremely inefficient to attempt to move static colliders, as it forces the physics engine to recalculate the physical world all over again.” Game objects without a Rigidbody component are considered as static colliders, so if we plan to move a gameobject which has a collider attached, make sure it also has a Rigidbody component.

4. Layer Collision Matrix – We should always use this and set it appropriately so that the collision detection is minimised. There are often many objects in the scene which are not affected by collision, hence we should not waste the processing time on those calculations. Use of appropriate layers for gameobjects and then setting a proper collision layer matrix is very important. This is how we set it up for Break It.

Layer collision matrix

5. Particle collisions – Our game uses a lot of particle effects and to be honest we do not require all of them to have collisions in the game. One should use particle collisions only when it is necessary and provides some value to the game. Also when using the collision, we should set ‘Collides with’ to appropriate layer so that it reduces the calculation.

Particle collision settings

In this game we needed to detect collisions for water drops from the ceiling (to create a ripple when they touch the puddle on the ground). However the dust and pebbles emitting from it (when the ball hits the wall) did not require any collision.

Rendering

The game relies heavily on the post processing stack and we could not compromise on that but we did find out a few things that could be tweaked in case of Break It.

1. Disabling shadows – The theme of the game is predominantly dark with contrasting glowing cubes. The ambient is mostly dark and hence we decided to do away with the shadows for they were not very prominent and visible.

2. Baked Lighting – We disabled realtime lighting and used only baked lighting for our scenes. Again since the scenes are indoors and in most cases, the ambient light is the only light source in the scene, the changes were not too drastic. But the performance improvement of baked over realtime lighting is significant.

Miscellaneous 

There are a couple of other things we did to optimize the game.

1. Limit the target frame rate – We limited the frame rate to 30fps which works well for mobile devices and the gameplay is smooth. Also the vsync (quality settings) was set to off otherwise the vsync would override it. More info here.

2. Update – Minimise the code in the Update block. If possible loops and conditional statements should be taken out of it. And if not required one should remove the Update function altogether instead of just keeping it blank. In fact one should remove any monobehaviour methods which are not used (Start, Awake etc.).

Result Achieved

Profiler screenshots once the optimization was completed.

Profiler after optimization
Profiler after optimization
Profiler after optimization

Bonus

Decreasing the overall build size and the time taken to build is also very important. Though this does not affect the performance per se yet is an integral part of optimization of any game.

1. Uber Shader – With the new Unity post processing stack comes the Uber shader which really bumps up the look and feel of the entire scene. Break It is heavily dependent on it. We initially found the build size to be very large and it would take long time to build the game. Analysing the build logs we found that Uber.shader is taking up a lot of space. ~50% of the entire build size. The fix is to comment out the part of code for the features that are not used in the post processing profile. In our case we just used Bloom and Vignette. So we commented out the code for the rest and it drastically affected the build size as well as build time.

Non required code commented out from Uber.shader

2. LightMap settings – Mobile games generally do not require a high resolution lightmap. For most scenes the difference is negligible if we reduce the resolution and size of the lightmap. This speeds up the baking of the light drastically and a minor improvement in overall build size.

LightMap settings

I hope you found this article helpful. Your comments and suggestions are highly valued. 🙂

Suggested reading:

https://unity3d.com/learn/tutorials/topics/performance-optimization

Break It – Devlog Entry #2

Hello Everybody!

Time for another update about the progress we have made on Break It. Its been close to a month now since the first entry and with the festive season done and dusted; we would like to show you what we have been upto.

We are pretty much done designing the various levels of the game. At least the basic mechanics and much of the look. There will be around 21 levels including 3 bonus levels. Each will pose unique challenges but with the same end goal. Hit the cubes to score points. Here are a few screenshots of some of the levels.

We thought about giving the game an overall dark theme. Self illuminating cubes with the environment and other props to have a dark or slightly mellow feel to it.

There is still an awful lot to do. Most importantly optimization, both in terms of performance and build size. The video above has been recorded on an android device around three years old, running 4.4 and you can see a bit of lag and stuttering with uneven frame rate. Fixing this is our top priority in the upcoming days. It runs fine on the new android handsets but we want the game to run on as many devices as possible. Also the main player object, the ball, is yet to be finalised. Would love to hear your thoughts and suggestions on how we can go ahead creating the look and feel of the ball.

Stay tuned to find out how we took care of the lag and optimized our game to run smoothly on low end devices. The next article would be about it. Any kind of feedback is greatly appreciated.

Game Jam BYOG 2017 – From a developer’s perspective

We took part in a game jam last week. BYOG 2017 organised by Nasscom Gaming Forum. This was our first ever game jam and I will be sharing the experience we had during the course of 48 odd hours developing a game from scratch.

To be really honest with you, I have never been a fan of game jams. I thought to make a game you need time. A lot of time to think, to conceptualise, to design, to code and to make anything worth even playing. And I always told myself “All you can do in 48-72 hrs is make a crappy game devoid of any feel” . Infact I always doubted if i can ever make anything worth showing in such a small amount of time. So when BYOG 2017 was announced, I gave it a read and gave it a skip. As I was already busy working on our upcoming project HitMe . Though I did join the chat on slack out of curiosity and when the topics were announced I had a look at them later that night. One of the theme was FairyTale and instantly a few ideas started creeping in my mind. I thought lets give it a try this time.

We decided we would be making something very simple yet engaging. A game with a small scope so that we can finish it up within 48hrs. That night was spent in conceptualising the game and the overall game design. So by the time we slept off, it was decided we would be making a game on the story of Rapunzel. A vertical scrolling game, where the user will just have to climb up and reach to the top. While fighting some obstacles on the way. This solved a couple of problems.

  1. Took care of the fairy tale theme pretty well and gave us a good story to work on.
  2. Kept the design extremely simple.

So we sat down designing the game in Unity and building a basic prototype. Quickly looked up some 2D tutorials (we have never made a 2d game before). And within a few hours we had a simple cube moving up and down using arrow keys on static background.

The next day it was decided to add some fun into the game. So thought of using magic orbs as the player climbs up. The orb was made pretty quickly with the help of particle system and a couple of youtube tutorials. Our artist was in Bangalore on that day and he sent me the sprites over the mail. The prototype assets were quickly replaced with proper artwork which included the prince and his animations, the seamless tower texture, the seamless hair texture and some art for the menu and end scene of the game. The next step was to code how the magic orbs would attack the prince. We did not want to keep it just random or too predictable. Hence 12 different kind of scenarios were coded and each one of them would have a different way to survive. That provided the much needed variation at the same time keeping the gameplay simple. (Using just 4 keys. Up/down arrow keys to move. Left/Right arrow keys to attack the magic orb).

After playing it a few times we thought it lacked a bit of depth. Hence came another enemy, witch attack; which requires the player to rapidly press up button for some duration to break free and move ahead. This acted as mini boss battles during the entire gameplay. Then the sound effects was added quickly and a very basic intro screen was made. The game still lacked a lot of things, especially in the UI section, but there was not much time and we thought that the overall game has come out to be good. So after around 35 hours of work interrupted with a bit of sleep and food, we submitted our game.

          

I must admit that on multiple occasions I thought of giving up and letting it go. Whenever we were stuck in some implementation or i felt that it is coming out to be crap, I thought about just leaving it and continuing with our other work. But the will was strong and we took it up as a challenge. (This might sound ridiculous to people involved in game jams regularly. But for my first experience, yes it did take some toll on me and i needed a lot of self motivation to keep going). Another thought that kept me going was that it aint gonna last long. So just put in some rigorous effort for the next few hours and it will be done. (Done or not the game jam would be over :p ).

So what do I take away from the jam? A lot to be honest. It was a wonderful experience. Events like this help push your limits and help discover new things. They teach you a lot in a very small duration of time. And if all goes well, at the end of it you will have a game which you can build upon and release in the future. I have always spent weeks conceptualising and designing games before i  get anything worth playing. And here it took us just two days to get a complete playable version up and running. Well, okay, not complete. The graphics are still very simple. There is no parallaxing backgrounds. The hair isnt moving as it is supposed to be. The animation at time does not look very fluid. Not much of an UI. The game is very very raw. But it has given us something which we can polish, add a few effects, a bit of juice, tweak some level designs and we are ready to release it in the market. And by the way the game isn’t too bad. Its still pretty fun and challenging to play. Reaching to the top will take some doing 😉 .

Here is a small tips & tricks section which might help anyone participating in future jams.

  1. Choose the topic very carefully. As a designer we all have our strengths and weaknesses. A topic might look very interesting and with a lot of potential but choose something which is easier for you to implement.
  2. Keep the scope small and simple.
  3. Make sure the game has some meaning and an end to it.
  4. Try to make the core gameplay fun and exciting before moving on to the other aspects.
  5. Polish and juice out only if you have time.
  6. Try to reuse assets you have already created. But make sure it blends well with the game.
  7. Try to complete it even if it comes out to be a crap. Making something in 48 hrs is rewarding in itself.
  8. Do not stop once the jam is over. Implement features in the game you wanted to but could not due to time constraint. polish it, test it make it a complete game and make sure to release it. After all a lot of effort has been put to submit the game for the jam.

And yes, you can play the game we submitted for BYOG 2017 over here http://gamedev.nasscom.in/game/rapunzel . We will be working on it and releasing it in the near future. You can subscribe to the blog to stay updated with the development process .

Please feel free to comment, criticise or provide any kind of feedback. Thank you for reading. 🙂

Break It – Devlog Entry #1

Hello Everybody!

Thought about creating this Devlog series for our upcoming game Break It. I will be updating the progress of the game and look for your constant feedback during the process to improve it. Also this might be useful for anyone who would want to follow a game development process closely. I will try to keep this a mix between technical and non technical aspects. So here it goes.

After our first release Rig’s Dream, we thought about creating something casual, a no-brainer kinda game with just one touch control. And after a few brainstorming sessions, the idea of Break It was born. The core gameplay mechanics would be to hit the objects with a ball. Thats simple,huh! So we quickly got down and made a very basic prototype which was something like this.

After playing this a few times we found that it was fun to play and pretty simple with a player just tapping anywhere on the screen or just flicking to throw the ball. It was then decided that the game should contain various levels where the cubes will be governed by the laws of the physics and each level should pose different challenges to the player albeit keeping the gameplay simple. (See it; Hit it). We also decided to keep the game in a closed area. i.e the X,Y,Z will be fixed and the game will take place inside that area. Below is a very early alpha version of the game.

[WIP] Our upcoming game at a very early stage of development using placeholder assets. Its gonna be a simple no brainer hitting game with real time physics.#indiev #gamedev #unitydev

Posted by Flying Ants Studios on Tuesday, 12 September 2017

The ropes are made using line-renderer, and the cubes are primitive Cube shape from Unity. A simple sphere takes care of our ball and the throwing script is attached to the main camera. Now was the time for some actual hardwork and get the levels polished and looking good. Below is the video of couple of levels in the beta stage.

This look was achieved using PBR, Particle effects and Unity’s Post processing stack. However there is a lot more to be optimised but this got us going and we were satisfied with the look. Apart from the interactivity between the ball and the cubes, there is also some details to the environment and interactivity between non playable game objects as well.

We are now working on designing the other levels (both technical and art). The art part will get a bit easier as mostly the environment will remain the same. Lets see how it goes. I will be updating this blog regularly with the development process.

Please feel free to comment, criticize, motivate or provide any kind of feedback. You can also give your suggestions if you want to see something in the game and we will try to put it in if feasible. Stay tuned for more updates 🙂