Optimising Your Mobile Game (Less Lag, More Awesome)

In this guest post Daniel La Rocca, Lead Designer at Evoke Method, shares his optimisation tricks for making sure their 3D destruction game Alienation runs smoothly on any smartphone, old and new.

Have you ever built your game to mobile, handed it to a high stakes reviewer and then watched helplessly as it lurched when it should have sprinted – then  slowed to an agonising crawl?

We have (it sucked) and we realised it could have been avoided. It was a combination of all our small little errors and carelessness snowballed into one massively crippling issue: lack of speed.

We must have forgot to put precognitive knowledge of the near future on our character sheets because we kept making mistakes and kept being careless.

If we’d kept going like that our game, AlieNation, would’ve become unplayable. Luckily we stopped, gathered our thoughts and hailed game optimisation as our newly crowned King of Development.

 

Why we Went 3D over 2D

 

We decided to create a 3D destruction game to fill a niche in the market – and considering the positive reception we’ve received from playtesters and local media, it’s surprising why most destruction games go 2D instead!  Sure you might have to work a bit harder to optimise your art pipeline, but 3D is the way destruction should be – it feels so much better to play.

Efficiency and optimisation make me all warm in areas that don’t even make sense, so here are just a few things that I kept in mind and constantly asked my team for to make sure our 3D destruction game kept playing smoothly.

 

When to go 3D (when to stay 2D)

 

The first critical lesson I learned as a 3d games artist is to keep everything as low poly as possible: don’t use any more vertices than you need and if you have detail in your models – keep it in the texture. Our buildings are modelled for their silhouette with every single grate and rusty detail textured in.

When we first created Professor Vogel for the in-game HUD and GUI Menu, we tried a 3D model of him, but ditched that in favour of flash art on layered planes. It ran smoother, looked better and provided a significantly better result than using a 3D model! We did this because all the detail we needed to keep Professor Vogel looking cool and matching the art style we could easily achieve with animated 2D textured planes.

I still cry tears of joy looking at this.

 

Lazy Texturing is Lazy

 

Texture sizes are where most artists fail in regards to optimisation because textures TAKE UP A LOT OF MEMORY.

Talk to a few artists, I reckon many of them create their textures in a relatively comfortable size such as 512×512. This is reasonable, and there’s nothing wrong with this, the only problem comes when the artists don’t downsize their texture to a more reasonable size before export.

A smaller efficient texture file can look just as good as a massive texture file once you get that asset in game! But if that artist did all their work at the wrong texture size, unfortunately all the beautiful detail the artist drew in and spent so much time on can get completely obliterated when it gets downsized.

To avoid this problem completely, I recommend artists either clean up their art after downsizing, or texture in the same resolution the file will be in game. That way you have control over every pixel in the texture.

 

On File Formats, Reusable Textures and Shaders

 

PNG is the lesser of many evils. It does lossless image compression compared to lossy JPEG compression, it doesn’t do alpha as great as TGA does – but it does do compression and alpha mapping good enough to make it better than the other file types.

Pretty much the lesson is:

Improper sizes +improper file formats = too much texture memory used = slower game = finding and downsizing texture = lost detail = lost time = very sad artist = very angry art lead.

Another extremely helpful thing involving textures is to re-use them whenever you can. Obviously this should be true with any asset in your game but in our personal experience on Alienation, instead of making new texture files and using up more texture memory on barely visible weapon and metal objects we re-used the building texture files on these small trivial objects! With a bit of UV tweaking you’d never know they were recycled textures.

One very important thing to note is the use of appropriate shaders. Sure the bumped specular shader looks fanfuckentastic on everything it’s put on, but there are specific mobile shaders out there that are designed for efficiency.

In our case, shaders were easy, they were already built into Unity.

 

When to Alpha Map vs Building it into the Mesh

 

The brilliant thing about alpha mapping is that it can make part of an object transparent, very easily and relatively cheaply [Editor’s Note: When we say “Cheaply” here we mean cheap in terms of processing costs. Everything pixel, polygon, shader, light, particle and bone costs your game processing power.]

However in some cases, a mesh is actually much more efficient than an alpha map! For example, when creating the wheel on our Clinker enemy it was incredibly cheaper and actually easier to model in the gap in the wheel than to have to texture it in.

I realise that I just contradicted myself  about keeping the detail in the textures,  not the mesh. But it is the ability to distinct between when to use what that makes you not just a game artist, but a great game artist.

 

Particles, draw calls and physics

 

Now, as with any game, visual feedback is absolutely critical to engaging with your player. Without feedback on their actions your game becomes boring, confusing and as interesting as a full time career as a professional paint dry watcher (yes, this is job exists, no im not shitting you, and yes this is hilarious).

Back on the topic of FEEDBACK: particles are a FANTASTIC way to convey information to the player! Ranging from spark particles from a bullet that hits a wall, to blood particles from when that bullet ricochet into a Nazi.

There are a few things that can go wrong with particles, one involves the texture file size for the particles, which, if you’re reading this blog post from top to bottom then congratulations – you’re already aware of my texture size rant and you’re a better person for it.

If you’re reading this segmented after skipping section headlines and haven’t already read my rant about texture file size, go read it. I guarantee you’ll instantly become sexy and more appealing to the opposite gender. [Editor’s note: Take that Neil Strauss!] 

Another downside to particles that most people fail to realise is that increasing the number of particles does NOT increase the amount of awesome – it just slows down the game. There are two different ways someone can make a particle effect: one way involves someone using the smallest number possible in the emitter to achieve the best result, the other way is to crank the number to 2000 and call it a day.

The only reason you don’t see 2000 particles per emitter in every game out there is because of draw calls.

A draw call is made for each separate object within the scene (each draw call made increases lag time). In the case of particles, it is very easy to overload on draw calls

Now, I love me some particles, but when I see some junior artist look at a nice efficient particle effect and think, “10 particles per emitter?? Madness! This would look much better with 2000 particles per emitter”, I feel incurable sadness and near physical pain.

I…..just..what??? Why would you even do that? Bad junior artist. No Redbull.

 

Physics (Closest Thing we Have to an Insta-Fun Button)

 

There is nothing cooler than hitting a building with a well aimed shot, watching it fall over all cool and dramatic like and you end up making stupid sounds like “fhwoar” and “Michael Bay”.

Why does this happen you ask? The thing i just said happens because of sweet and sexy physics!

I let the programmers take the reigns when it came to our physics, so everything i’m about to type came from the indecipherable language of programmer, through the translator-language-barrier to this artist and from this artist’s pixel pummeled brain to you the reader, so bear with me here.

Physics updates SO many times per frame, what they update is their position, speed and anything else relevant to their motion. The amount of times the physics is updated ties directly to how fast the game runs and a great way to get a faster speed is to reduce the amount of updates per frame.

This is a sure fire way to get your game running faster, but it may mess with the sexiness of your physics and it is very important to get this balance of updates per frame to be able to have cheapish and efficient physics.

An example we experienced was when we reduced how many times our physics updated per frame. Our ball might update infront of a wall, travel into the wall during the downtime, then update inside the wall and launch itself out either side of the wall and trust me on this, balls coming out of walls is NOT realistic…I think.

It takes our programmers a few more minutes of tweaking to get the best balance of uninterrupted and efficient physics.

 

Lights and Skyboxes

 

Two things that im going to touch on quickly (mostly because im hungry and need dinner) are lighting and your skybox.

The amazing thing about skyboxes is that you don’t have to use them for sky (I know right?!?)!

A fantastic way to use them is to include background art on them (like a matte painting in film) which is a cheap and easy way to add a huge amount of background art and atmosphere to your game.

Lighting is a harsh mistress and i’m going to say this straight out: for mobile, you better get used to directional lights, and if youre feeling like a lucky punk, maybe a few point lights. In Alienation, we put in a spotlight , but after toiling night and day researching lights (I lie, i just Googled unity lights), I found that spotlights were one of, if not THE most expensive light you can use for mobile games.

 

Wrapping Up

Taking each of these suggestions individually, your game won’t change an incredible amount.

But combine everything above and apply all of them in your optimisation: you game will transform completely from something that crashes more than a teenage driver, to something that runs so well it brings a tear to your eye. A tear of joy.

 

Evoke Method is a Sydney based startup indie game developer focusing on making fun games that satisfy on a primal level. After having a blast working together on a student hack-n-slash project named Immortalis, they decided to form up as an indie studio. They are currently working on Alienation, a 3d handheld destruction game for the iPhone, iPad and iTouch. Follow them on Twitter, like them on Facebook or check out their website!

 

[Want regular bits of indie beamed straight to your inbox or feedreader of choice? Visit the Subscribe page!]

← Previous post

Next post →

10 Comments

  1. Optimisation without profiling is one of the simplest mistakes a programmer (or artist/designer for that matter) can make. Profile, profile, profile. Big textures do not necessarily slow a game down. Same goes for numerous particles, transparency, draw call numbers etc. The most important part of optimisation is learning where and when to optimise, and do so on the basis of real evidence. Every game is different, every platform, every language, every engine. Chastising a junior artist for upping the particle count should only happen if you KNOW it is slowing your game down, and even then only if the slowdown is significant. Get that low hanging fruit first! 🙂

    • Cheers Kier!
      Agreed profiling is absolutely critical for pretty much any game and it saves us majorly in a previous project. Unfortunately we’re only using basic Unity so i really, really wish we had it!
      Agreed, big textures won’t slow it down but they still do take up a significant amount of game memory which could be put to better use elsewhere. It is always good workflow to make a texture or particle system or anything the smallest it should be for the situation it’s used for since it can give you flexibility elsewhere.

      In our perspective, a safety net for optimising without the profiler is to just make everything as efficient as you can and when/if you do eventually get the profiler, you’ll feel so good because you can up the detail on your beloved art.
      This perspective is from a pure efficiency workflow which can become a happy ending from using the profiler later! 😀

  2. James Murchison

    There are a few issues you absolutely need to understand about the architecture used on mobile GPU’s, especially if you are attempting to target the original iPad or iPhone 3GS. There are many situations where using more geometry is better than using alpha mapped geometry, as these GPU’s have an incredibly fast hardware based Hidden Surface Removal stage of rendering. This means that if you don’t use alpha mapped polygons, you only render each pixel once, causing the fill rate to be REALLY low, using less of their battery. Also the fill rate on the original iPad made it almost a requirement to not use alpha mapped quads that took up much of the screen.
    So in regards to your particles component, sometimes you need a tonne of alpha mapped particles, but they should not take up a large number of pixels, as each pixel then needs to be re-rendered multiple times. This is where your performance is getting destroyed. You could alternatively look at mesh instancing instead, with opaque meshes that would then be included in the HSR part of the pipeline.

    More info on the architecture can be found here at the PowerVR website. http://www.imgtec.com/downloads.asp

  3. Great read. Definitely a good reminder of everything to consider in general to get things running well.

    A few things I’d add – the first – if (like me), you’re using Unity Indie/Basic (I don’t know what it’s like with other engines), then the best way to check on-device performance is with good old Instruments (which is part of the iOS SDK). It’s great to just give you a solid FPS counter – and for checking a lot of other details about your apps in real-time (sadly, unless you’re down on the main iOS platform itself – most of these won’t be helpful).

    You can get more details about that from the videos Apple release on their developer site.

    Also, in keeping with knowing your target platform – consider using Compressed Textures where appropriate. In my game, I’ve been enabling it for characters, backdrops & for particles – in those cases, it’s where you don’t need the exact crispness which you would need in the UI, so you can get away with the savings. The downside of course is that you do get longer build times – so you might need to factor that in as well.

    When I started out with teaching myself Unity – I found this article to be darn useful in getting a feel for what needed to be done as well – http://www.quickfingers.net/optimizing-unity-games-for-the-ipad – there’s enough there which has been reiterated here, but a few little practical things that might help as well.

    With all of that, I’ve been pretty happy with runtime performance on my game (though, I only use physics for collisions, and I’m using the 3GS as a baseline target).

    • Cheers Rob!
      Yeah we’re in the same boat as you with Unity basic haha, we’ve been testing run speed on the HTC Salsa (weird name ay) which isn’t much of a powerhouse but gives a decent reference for performance. Does that whole iOS SDK package come with the Apple Dev License? (Been meaning to get it for a while.)

      Great to hear! hope your game goes well 😉

      • Thanks Dan. Wishing you & your team all the best as well 🙂

        With the Apple dev tools – they’re available outside of the developer program (you can just visit the Mac App Store & install Xcode), but the stinger is that you won’t be able to deploy onto an actual device until you join it 🙂

        Afraid I’ve not really looked into how things behave on the Android side of the fence, so I’m unsure as to what the best approach is there to profile in the same way (as whilst I’ve been making test builds for it, I’ve been basing performance off getting it slick on iOS first – and finding it to be great on my test device).

        The fact that you’re testing on a device is still a great benefit – and I think it’s the most important factor when developing in these scenarios 🙂

        • Ahhh gotcha, only just signed up to the dev program a few hours ago so finally it’s about time we cracked out the dev kit 😉

          Same here i haven’t looked into Android profiling at all but I found a few posts saying that you need to connect via Wifi from your Mac with Unity and mess around with some system preferences, unfortunately you can’t connect via cable it has to be wifi (or so i’ve heard).

  4. Nice read. Definitely a nice switch from the business stuff.

    Personally I like using PNG files myself as the basic dev/testing format once exported out of the image editor for the reasons suggested. Though using Unity you still end up importing and setting up compression and the like — as the author has stated.

    I mention that as a designer, as I have seen programmers use BMP files that were the incorrect pixel size for a start let along just the wrong format period — I wonder if it is as common as artists tending to use TGA… Though that’s not as bad as an artist that had 20mbs for one DDS texture file when 2mbs would have been more than enough to retain detail if not a 1/4 of that — it was so large it caused the game to seize up.

    I don’t even think he had generated the mipmaps either. Though, he was rather fresh and junior.

  5. Concerning image-formats in unity i have an update for you (just came across this topic looking for optimization-tips, and here I found plenty, thank you!). In unity the format you use in the editor does not matter, as Unity compresses textures to an internal format anyway when building the game. So you can actually use layered .psd or .tga-files without regret in Unity
    . See here: http://forum.unity3d.com/threads/does-texture-file-format-matter.83311/
    I tested this myself, and changed all textures in a project from 32-bit tga to png. Result: the built game had the same size to the last bit.

Comments are closed.