I have always been intrigued by video games - NES and SNES in particular. Now I am a 32 years old computer professional who has mostly done his coding in Java and C#. I recently found great inclination for Android games and posting this question to much wiser community in the field for knowledge and awareness of everyone.


NES brought an invasion of 8 bit games. Very sleek, very entertaining and surprisingly very compact in size - few hundred Kb only. Games like Mario/Contra/Ninja/Zelda and countless more.

SNES followed the suite and brought an era of much graphically appealing games in 16 bit - still the size of the games were very compact and games were very powerful.

For Android, I have been doing some research for some good game engine and found that LibGDX is very powerful, open source and written for Java developers. A plus for any Android game developer.


  1. What I am not able to understand is that how those classic game developers managed to put all those endless levels and game characters and features and goodies in just few hundred kbs! I am trying to replicate just 1 level of Mario and the size is already reaching to 300Kb, let alone adding the files code and characters sprite images!

  2. Can we implement similar principles of compact and powerful coding using Android and LibGDX? If yes, how - If no, why not!

  3. Is it possible to create a game in 8bit/16bit code and then migrate it to the Android/iOS platform?

  • 3
    \$\begingroup\$ It's definitely good to see some enthusiasm.. but I think you may misinterpret the purpose of a Stack Exchange site. You should ask separate questions, over a list of questions. As is, this looks waay to broad to be on topic. There are other reasons a question might be off topic, as well. For instance, some sites outright ban any request for tutorials. Given the context of you still being new to this, it could definitely be interpreted as "where to start" questions, which are definitely off topic. Feel free to take the tour for more information. \$\endgroup\$ – Gnemlock Sep 12 '16 at 10:09
  • \$\begingroup\$ @Gnemlock - Yes Gnemlock. I understand that I have asked few questions in one thread but the reason of asking these questions is their interlinking. Every question is interlinked with the next and vice-versa. \$\endgroup\$ – Harry Sep 12 '16 at 10:17
  • 2
    \$\begingroup\$ I see you are completely new to SE. That's generally not how it works. While each site is a bit different, generally being interlinked does not mean the questions should be posted together. You could post a separate question and link back to the original, for example. You might find multiple questions are acceptable when the derived answer would answer all of the questions, anyway, but requesting 5 answers in one question definitely flags your question as being too broad. Irregardless, I have flagged your question for mod review. It will either be closed, or I will be corrected. \$\endgroup\$ – Gnemlock Sep 12 '16 at 10:23
  • \$\begingroup\$ If this question is considered too broad and closed, might I suggest providing a suggestion for which questions would be acceptable, and which questions would be suitably linked together? This is definitely useful and salvageable, regardless. \$\endgroup\$ – Gnemlock Sep 12 '16 at 10:24
  • \$\begingroup\$ 1. By thinking about size when writing the program, and using the same graphics often. Having very low resolution and very low color depth helped, as did 8 bit sound. 2. Yes, but in context of the larger size we have available, because spending time=money to save lots of kilobytes isn't viable if you have gigabytes available. 3. Yes, using an emulator. \$\endgroup\$ – Peter Sep 12 '16 at 10:40

I surmise the OP wants to know why games designed for classical consoles and computers are so much smaller than modern games. Hopefully some of this is useful; I have just an interest in retro systems.

If you look at two main elements that make up an image we see code and data.

For the data portion if we examine graphics, one methodology may be to have a 16 colour image where the palette is stored separately to the image itself. In order to represent 16 unique values we require 4 bits per pixel, and then a palette (depends on number of colours the VDP can display) loaded onto the display processor which declares what each of those 16 colours represent (with one being transparent).

The Mega Drive for example has 4 palettes and all the pixels on screen are taken from these palettes. If on a modern system you chose to use a 24bit bitmap for your Mario sprite each pixel will need nearly 17 million bits. By changing the palette many games would reuse the same images and simply change the colour to give the impression of new enemies and environments. Games were typically also built from tile maps (e.g. 8x8 tiles) so the same levels were created from a selection of small images; this is more space efficient than creating larger images and only using them a handful of times. Systems like the Super Nintendo had scaling, rotation; etc built into the hardware which helped reduce code size as this didn’t need to be done in software, but was more useful for computational efficiency. The same sort of argument applies for the music and sound effects in games.

Games were usually written by hand in assembly which even now amongst homebrew is popular due to the small code size/efficiency that can be achieved compared to a compiler, though modern compilers are much better than some of the older ones. Object oriented languages are often not used for embedded processors due to the small overhead involved, which is not really an issue on smartphones and modern PCs. Many games are also created using interpreted languages with huge libraries (compared to the memory size of old consoles), often including a lot of code which is never even executed. I first started programming with older versions of Game Maker and even a game with just a single empty room would be well over 1MB in size, before I added anything to the game.

Hopefully the examples I’ve shown illustrate that in order to create a game for the 8/16 bit era you would have to know a great deal about the hardware you are running on (at least at the time) whereas modern frameworks or game engines abstract the hardware detail away from the user. You don’t need to know exactly how the hardware works or concern yourself with the vast amount of hardware variations that exist in Android devices; each layer of abstraction introduces inefficiency but can potentially help developers (this is especially important for large complex projects not possible on less powerful hardware).

I’m not sure on modern devices; they may need to be rooted. If you could write your own drivers to interface directly with the hardware instead of using a high level framework which in turn talks to the OS which then controls the hardware, you may be able to natively control the device using a very small end-to-end footprint. If you are only interested in reducing the size of your games using this framework you should probably start by examining the size of your image and music files, perhaps create a barebones room and check the size of the image produced and check the size difference to the Mario level you produced to see if it’s the framework you are using or your work that is introduced the bloat.

  • \$\begingroup\$ He can also try to use procedural generation, that way music and images can become even smaller by generating them only with code. But that is not for the faint of heart \$\endgroup\$ – rlam12 Sep 12 '16 at 13:26
  • 2
    \$\begingroup\$ For modern graphical software making a lot out of little space, check out Demoscene creations. They'll often challenge themselves to create rich graphics & music out of only 4-64kb, often using procedural techniques to generate content rather than storing it. \$\endgroup\$ – DMGregory Sep 12 '16 at 13:33
  • \$\begingroup\$ Great answer, and in the same vein of @DMGregory comment, you can also check the Programming Puzzles & Code Golf Stack Exchange, where users solve coding problems with the shortest possible source code. \$\endgroup\$ – Rodia Sep 14 '16 at 17:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.