Modern desktop PCs are very powerful. Generally, the main issue with performance is that mobile game is developed on desktop and later on there are different challenges to get your game to run perfectly smooth on phones and tablets. There is an inevitable need to test those games under development using real mobile devices.
As we’ve been highlighting it in our blogs, great graphics performance in mobile games is very closely related to good user experience. User wants to see constant progress with the game, do the smooth game-playing, and for this, graphics performance needs to adequate and work across all those different devices – and provide the very same user experience.
First and foremost, you should be able to measure the performance of your mobile game in terms of basic metrics. Frames per second (FPS) is a good basis to start and to understand how well certain implementation works on variety of different devices/platforms. We recently integrated GameBench into our Testdroid Cloud to provide you an instant way to measure real-time performance while your Android game is executed on our devices. Just check the GameBench checkbox on and you’ll get FPS results with your test run details – and all in minutes!
The first rule of any optimization is to find where the problem is – or where the performance could be easily improved. Let’s first take a look at some of the areas that typically drag down the performance of mobile games.
Few Examples of ‘Costs’ in Graphics Performance
The graphics and software implementation mainly stresses two parts of the device: CPU and GPU. The optimization techniques for both of these are actually quite different and depending on if you are using some game engine for your game. For example, some game engines (e.g. Unity3D) offer pretty neat ways to optimize those performance bottlenecks related to both CPU and GPU.
The case is very real on real devices. There are a wide variety of different devices, with different silicon, performance capabilities and characteristics that developers should be aware of. But to conclude few handy and instant ways to optimize mobile game performance across all those different devices developers should consider the following things:
Fill-rate. Thinking this through, even every pixel can be seen as a cost. When framebuffer is filled with pixels to be drawn – regardless of what color – it will increase the time spent in operations. As GPU is often limited by fill-rate you might see that the game runs faster at lower resolutions. However, screen resolutions typically tend to go hand-in-hand with the capabilities offered by GPU. Typically, one of the common source of performance problems is coming from too intensive pixel writing. And this is the first priority in order to improve the performance of your mobile game.
Draw Calls vs. Batch Counts. Every time you (or game engine you rely) call OpenGL ES to draw a buffer of vertices the call itself has a cost. Draw calls are often considered as expensive costs, with the need of graphics API doing lots of work for every call and therefore causing an overhead on the CPU side. But, this is not always the case: the expensive cost comes from resource changes accessed by GPU. For example, to reduce draw calls game engines can combine objects at runtime and then draws them along with a single draw call. The process is called “batching” and really the emphasis should be on reduction of those batch counts – both static and dynamic – rather than trying to optimize draw call counts.
Again, there is a great way to further optimize the performance by investigating how draw calls vs. batching should be used when real mobile devices are used for testing.
Lighting. Depending on how your game have been implemented to do lighting, this can be very expensive resource-wise. Realtime lighting can really burden the system and make performance awful. Something that is not computed or calculated will work always the fastest. Therefore, instead of using real lightings and set of geometries, you can try how different light-mappings would work for your game. It basically means that you calculate a static lighting once and avoid computing it for each and every frame.
Few Quick Tips and Tricks
Most importantly, make sure you test your game already during the development on real devices. You’ll get instant feedback of things that won’t work, what work sluggish and what devices/OS versions/configurations require “special attention”. Few quick tricks from old game developer’s head to make your game run smoother goes as follows:
Doing 2D? Combine all graphics assets into one atlas. This can improve the performance as you can use one picture instead of several ones – and only do one draw call.
Utilize Macrotexturing. There is a good chance you can squeeze in everything on few textures (e.g. 2048 x 2048). That size of textures can include a lot of your graphical content. The handling of these will be faster as you can batch all of the visible geometry using the same texture up into a single vertex buffer object that is then sent to GPU. Game engines can help with their optional dynamic batching options. However, macrotexturing do require some graphics skills as textures might not be that straightforward to be modified later on.
Using too many effects?. Effects are visually impressive, but not all of them are necessary – and can significant slow down the game’s performance. Furthermore, some effects – even popular ones like blur – typically have an impact on overall performance. When these effects are executed across different device (different CPU/GPU) you’ll get quickly an understanding of how well they do, what provide a slick and easiest way for GPU to process.
Batch as much as possible. The static batching can help if your objects do not move during the gameplay. For example, Unity provides a StaticBatchingUtility that can be very helpful to for performance optimization. It can significantly reduce the number of draw calls but keep amount of rendered geometry intact.
Create scalable games. Not only those display resolutions but also game design itself should take use of various different levels of devices into consideration. Something that works fine on high-end can be scaled to work on low-end as well – it is just matter of optimization and design. For example, texture and their sizes, use of different mappings and design of 2D/3D scene to be scalable can make your game playable across devices. At the end of the day – you surely want everyone to download and play your game, right?
Do you have the best practice for mobile game optimization in your mind? Please share with us on the comment section below!
Learn the importance of infrastructure and architecture aspects, as well as the improved agile process and the value of testing in mobile game development and testingDownload