No Time To Play

Memory management and game performance

by on Jul.16, 2013, under Gamedev

memory-management

I’ve spent the better part of a morning reading this article titled Why mobile web apps are slow. It’s a fantastic read, with citations, benchmarks and thoughtful arguments, and the tl;dr version is that mobile devices simply can’t be as powerful as desktop machines, and if you want performance then you need control over things such as memory management. And certain languages simply don’t give you any.

Now, don’t take everything written there as gospel. As a commenter pointed out, Python uses reference counting, so the argument doesn’t apply to that particular language. Also, this isn’t about ARM versus Intel, but mobile versus desktop. Remember Intel’s Atom line? I have the original Asus Eee PC 701, and believe me, it’s much slower than the 900MHz frequency would suggest. My game Buzz Grid stutters on it, and that’s a game I was able to port just fine to Java ME.

Speaking of which, if you think avoiding memory allocations in Java helps with performance, think again. The Java class library does so many allocations of its own, behind your back and outside of your control, that you might as well go with the flow. I don’t know if it’s the same on Android, and Javascript is another language entirely, but it’s not like you can avoid memory allocations in a language where almost everything goes on the heap.

Which, of course, only strengthens the point: if you want performance, use a language that lets you choose how memory is managed, and statically allocate everything you can. Even Python and Javascript have had fixed-length byte arrays for years now, which are both faster to access and far more compact than pointers to pointers to pointers…

But, but! Isn’t manual memory management unsafe? Of course, if you have to use the heap a lot. But often you don’t have to. I recently wrote a couple of roguelikes, and didn’t have to use malloc at all! You might think you can’t avoid it for a game such as, say, Square Shooter (and indeed, in my experimental C++ port I used STL vectors), but look at it this way: the furthest I ever made it was level 13, and I wrote the game. If I capped the level count at 25 — an insanely high figure — the most bubbles you could have on screen at any one time would be 100. I could keep a static array of them and treat it like a memory pool. Ta-daa! No more pointers to worry about.

Of course, none of that helps you if you want (or have) to make a browser game. And for better or worse, right now that means Javascript. The aforementioned Square Shooter, which positively flies on the desktop, is unplayable on my Android tablet (though a few friends say it works on their phones). What can you do then?

  1. Reduce scope. Yes, yes, I know. You have tons of great ideas, and the more the merrier. How else are you going to differentiate yourself from the competition? But keep in mind that the fastest possible code is the code that doesn’t run at all. Simplify, short-circuit and just plain trim down anything that requires too many resources. It’s no use making the most complex game ever if nobody can run it.
  2. Cut down on the fluff. Lots of pretty animations may catch the eye, but in the end players will stay for the meat of the game. If fluff causes trouble for part of your target audience, go with something less fancy. A few well-placed pixels can make more of an impression than millions of polygons.
  3. If all else fails, make a turn-based game. No, seriously. Most of the gaming population nowadays is over thirty (if not forty), with dwindling reflexes and besieged by distractions. They’ll thank you for not making them twitch, and your poor mobile CPU will have half a second to update the screen, instead of a few milliseconds.

By this point you may be wondering if I have a point. I wonder myself. Oh wait, I know: stop blaming the hardware. It’s time to get used to the idea that this is it. Moore’s law has plateaued. Computers won’t be getting more powerful, not without a technological revolution. It’s time to re-learn how to optimize and keep things simple. Can you write a game for the ZX Spectrum? No? Some people still develop for the Atari 2600, you know.

On the other hand, stop blaming dynamic languages. Certainly, they’re slower than their statically typed brethren, but the biggest speed gains always come from better algorithms, or simply avoiding unneeded work. So focus on that. Sure, it helps being able to give the machine optimization hints (the final keyword in Java is very effective), but relying on tricks can only get you so far. Learn the real stuff.

But most importantly, learn to know computers well. Stop treating them like these magical artifacts of infinite power. Details matter; pay attention, and you’ll be surprised how far you can go with very little.

It beats never getting anywhere because you want too much in the first place.

Creative Commons License
Memory management and game performance by Felix Pleșoianu is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

:, , , , ,

Comments are closed.

Posts by date

July 2013
M T W T F S S
« Jun   Aug »
1234567
891011121314
15161718192021
22232425262728
293031  

Posts by month