Four memory problems you should look for during game development
- Jun 29, 2015
- By admin
- In Guest Posts
- Share on
From a sales point of view, your cool new mobile game should work on most of the devices used by people today. The term ‘most of the devices’ evokes a ‘yikes’ by a developer. As of Jan 2015, the number of unique mobile users was 3.6 Billion. It’s the job of the developer to make the game/application work within the hardware constraints of a lot of those devices. Developers need to put a lot of thought while developing memory intensive software like games. By writing this article, I hope to help a non-tech person understand some of the memory problems that should be taken into account when developing 2D game projects.
1) Memory Leak: A memory leak can be defined as an allocated memory block which has not been released.
Analogy: Let’s imagine a cabinet that you find in a locker room having a total of 3 perfectly square lockers.
1) John and Danny ‘need’ to store their equipment for which a single locker suffices for each of them. So we now have 2 lockers that have been used and 1 unused locker which has free space for storage.
2) John needs to store his helmet at this point and no longer needs the old equipment that he stored before. Now ideally, he should be taking out the older equipment and putting his helmet in it’s place. But he asks for another locker from the manager and decides to put the helmet in the new locker. Logically, all the lockers are used up after this. Having been gifted with the memory of a warthog, John forgets about the equipment that he had stored in the first locker.
3) Danny needs to store 2 helmets now and needs 2 lockers, so he decides to remove his older equipment and frees up 1 locker. He now asks for an extra locker from the manager, but is refused since all the lockers have been used up.
Here, Danny would not be able to utilize the storage space that would actually be available if John had removed the unused equipment from the locker.
2) Multiple instances of the same texture: A texture takes up width*height*4 (1 byte each for red, green, blue and alpha) of memory space. So an image of size 512×512 will take up 1.05 MB of memory. The same texture used 3 times would then take 3.15 MB of memory. So we would be using 3 times more memory if we used those many instances of the image as a texture.
Analogy: Consider a square sticker which shows your favourite character, ‘buttman ‘and can be reused for an infinite number of times.
You need to show this cool new character to 3 different people. So you can either:
- Get 2 more stickers which are exactly the same, get 3 wooden frames on which you plan to stick the stickers and send the wooden frames to those 3 people.
- Ask the 3 people to get their own wooden frames and just let them put the sticker on their wooden frames to see how it looks.
Case 2 works for us since we can just reuse the same sticker multiple times. It actually works in parallel in case of a software program, so all of them can look at buttman at the exact same time. Magic, yeah.
3) Unnecessary Iterations: Calling a for/while loop once is easier on the resources than calling it multiple times. Batch multiple tasks in one loop if you can.
Analogy: You are a spy assigned to deliver packages to 3 different, far off locations in tropical heat. You have also been asked to get top secret info by a different boss from the same 3 locations above.
Since both the tasks have been assigned to you by different bosses, you can either:
- Group your mission according to the boss i.e. You would drive over to all 3 locations to complete the task given by Boss A first, then drive over again to the same 3 locations to complete the task given by Boss B. Or vice versa.
- Group your mission according to the locations. i.e. You would drive to the first location, deliver the package and get information, then move on to the next location.
You would be a damn stupid spy if your mission plan was Case 1 due to the simple fact that it takes a longer time and more resources to complete the same set of tasks.
4) Keeping unused objects in memory: At any given point in time, only a definite number of objects will be used and / or shown on the screen. Since we have limitations on the memory that can be used, any additional objects still in memory are a drain on resources and should be released.
Analogy: You need to push a cart from point A to point B. Let’s assume that the task at hand would be easier if the load on the cart is non-existent or lighter at the very least. Since you love beer, you load up the cart with a barrel of beer anyway, which just makes the task at hand harder, you alcoholic nitwit.
So the best solution would be to not load up the barrel even if your emotions say otherwise.
The list of problems is definitely more than I could write about in a single article. As a developer, you should be able to identify these problems quickly and apply the needed solution. Shipping the product after overcoming these challenges is what makes game development exciting. Everyone has 24 hours in a day. For us, it’s the idea of other human beings spending and enjoying some of those precious hours of their lives on something that we create, that pushes us to develop games for the populace to consume.
About the Author:
Aditya Kulkarni holds the position of Founder and Chief Lunatic at loongames.com, which is a mobile game development studio for Brands and Consumers. They have worked with notable companies on a variety of video game genres. Their team is well experienced at creating games from conception, design and prototyping to the deployment stage.”