Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Get the latest Education e-news
  • Four Memory Problems to Watch Out for in Game Development

    - Aditya Kulkarni
  • [Aditya Kulkarni outlines some common memory problems that trip up fledgling developers, and explains how you can avoid them in this feature. Aditya is the Chief Lunatic at Loon Games Studio. All art work used in this blog is created and owned by the studio.]

    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 have actually been 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 512x512 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:

    1. 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.
    2. 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.


comments powered by Disqus