Rapid Prototyping and Optimizing Shoot To Kill
Over the holidays I spent a lot of time optimizing and tweaking our mini phone game, Shoot to Kill. Since I had never developed a phone game before it was a great learning experience in Unity's underlying engine as well as common game optimization techniques.
Our initial release of the game ran badly, on pretty much every phone we tried it on. My Samsung G3 could barely churn out 30 FPS, and there were only 4 elements on screen! Needless to say there was quite a lot of work to do.
The first step was getting the Unity debugger to work on an android phone. This took a bit of work since my phone does not run the default Samsung software, but a homebrew version of Cyanogen mod. Apparently, debugging drivers are per firmware, not per hardware like I had originally thought. It turns out the driver for Cyanogen is the same as the default Google debugging driver, but with a modified info file. You can find that here:
https://codeload.github.com/gu1dry/android_winusb/legacy.zip/master
Once I got the debugger working, the first thing I noticed was that our scripts where taking up at least a good 20% of frame time, about 16ms. Also, a reading in the profiler, "Overhead", was taking up a lot of time. After eliminating enough elements from the scene it appeared that the movement and arm script were causing the lag. Turns out that constantly setting position or rotation of transforms can really screw with Unity's batching system - updating the scripts so that they only update positions and transforms when something changes saved 10ms a frame!
On phones, I noticed that the render time was massive - but the reasons varied from phone to phone. On Samsung phones, the profiler reported that the longest element was 'transparent VBOs', on Google phones the profiler reported 'clearing screen' etc. There was no consistency except that it was evident drawing was too slow. I pretty much just hammered at everything to make bring the time down. Harriet also helped me with these. In the end we shaved off another 10ms from draw time. Some changes included:
Removing all post effects
Using forward rendering
Removing all custom shaders and replacing them with default & built-in shaders
Flattening the scene & removing most of it's cutout shaders
Removing most cutout shaders
Only clearing depth from the framebuffer
Using static batching
I realized after doing all this work that making phone games are a hell of a lot harder than they appear, just because of the amount of effort required to optimize and tailor a game for a mobile platform. After meeting with the rest of the team, we agreed to abandon any mobile projects we had for the rest of the year. Optimizing would take up valuable time that could be spent elsewhere making the game better.
Below are some screenshots from the development of the game, took about a week to make in total.
Jessica Bull (artist) on creating Shoot To Kill
This weeks game is called "Shoot to kill" a simple but effective 2D game.
It is 2 player for android and PC. The idea of the game is to get all the top hats from the other player. To do this you must shoot the other player before he shoots you.
We had many issues with this game as it was the first time trying to build for mobile devices. After a bit of research and optimising we managed to get it working for most android devices, PC and Mac computers.
