How we fit an NES game into 40 Kilobytes

[Music] [Applause] [Music] do hello everyone in this video we will show you some of the techniques we use to fit our nes game micro mages into 40 kilobytes in this day and age we are used to storage media that can hold gigabytes of data that means hours of video and many days or even weeks of music 40 kilobytes on the other hand are barely enough to store 2 seconds of music in mp3 format [Music] when the nes was conceived in the early 80s electronic storage space was severely limited and expensive only 40 kilobytes of game data are visible to the console at one time without additional hardware on the cartridge to switch between multiple banks of memory this is all the space developers could use and none of the early games could go beyond that as a result these early games were usually very limited in scope with one famous exception super mario bros its developers managed to cram in a large number of horizontally scrolling levels into the tiny space they had which was really impressive for the time fascinated by this game we just had to see if it was still possible to create a game with the same limitations nowadays going back to the roots of the nes and these were our plans a vertically scrolling platformer with a cartoonish occult theme the core mechanics are running shooting magic spells and to make traversing vertical levels fun while jumping we want to provide an adventure with many levels and boss battles that you can go on alone or with up to four people as we felt the nes library was truly lacking a multiplayer experience like this to program an nes game like this you need maximum control and speed so we need to speak the process's language directly writing all code in 6502 assembly eight kilobytes are used for graphics and another 32 kilobytes for everything else the graphics are split into two tables one for background elements the other for independently moving foreground elements which are called sprites each table holds 256 graphical 8x8 pixel tiles a single sprite on the nes can use three different colors you can combine multiple sprites to build larger objects or meta sprites as we call them the nes only supports four different sprite pellets at the same time so we reserve one pilot for each player and they have to be reused for enemies one of the most characteristic limitations of the nes is that only a maximum of 8 sprites can be rendered on the same horizontal line excess sprites simply disappear that's why a lot of games employ a flickering effect to allow more sprites to be seen so we decided to reduce the size of the players to avoid reaching this limit and save space in the sprite graphics table taking super mario bros as an example here's the space used by all of mario's graphics you can see that the choice of smaller sprites allowed us to bring diversity and fluidity into the main character's movements and ultimately left space for more content for example different bosses speaking of which we had to come up with a couple of tricks to be able to store them at all for example these are all the individual frames used for the first world's boss if we store the sprite graphics like this our dream of making this nes game will end right here so here's what we do instead first we split this big meta sprite into three parts that can be animated independently of each other let's decompose these parts into individual sprites and see if there are any graphics that are the same we only need to keep one instance of a sprite tile and can then reuse it as many times as we need to the nes is also capable of flipping sprites vertically and horizontally which allows us to reduce the number of individual sprite tiles even more as you can see we optimized the top part quite a bit from 16 individual sprite tiles down to four for the middle part let's continue in the same fashion the bottom part has five animation frames but the last two are flipped versions of the first two and again we reduce the amount of individual tiles as much as possible with these kinds of optimizations we could save a lot of graphic space which allowed us to add more content [Music] do [Music] in order to have a reasonable number of levels finding a good way of compressing level maps is crucial so let's go into that next first a background is made from many 8x8 pixel tiles at one byte per tile disregarding color information a full screen would use 960 bytes that's almost a full kilobyte which is quite a lot so we add a layer of abstraction which we call meta tiles and then we use the same trick on those again ending up with meta tiles of meta tiles with this technique a full screen will use only 60 bytes this is the graphics table where we store all the background tiles used in the game here's how we build meta tiles each world has its own tileset and tilesets do take up space on their own so there are some tricks we employed there as well but for the sake of simplicity i will not go into detail about them in this video now with these meta tiles we can build tile sets of meta meta tiles finally we can start building the background for one screen even if 60 bytes don't seem like much the total map data of the game was still relatively large so we searched for other ways to optimize it and so we thought what if the levels were symmetric okay so let's remove half of the screen and mirror the left side ending up at 30 bytes per screen unfortunately the gameplay suffered from this it quickly became clear that completely symmetrical levels were too bland and just not fun to play but wait there is a solution expanding on what was mentioned earlier one meta meta tile on the map is stored as an index into the tile set and uses one byte one byte is made up of eight bits in our meta meta tile sets we only use a limited number of tiles so as you can see the highest bit will never be used in the tile set index that means that at four meta metatals per row we can use four bits to store another value we use these four bits to enable shifting the mirror axis of individual rows of tiles breaking up the symmetry and allowing for more diverse level design while still only using 30 bytes per screen of course let's not forget that levels are much bigger than just a single screen so the cumulative savings achieved by all the aforementioned techniques are quite substantial finally all of these saved bytes allowed us to add a hard mode in those classic games that have one hard mode often means something along the lines of play the same game again but with more resilient enemies with the remaining space we wanted to provide a more unique challenge than that adding new tricks to the enemy's repertoire was possible designing completely new levels on the other hand not so much well let's see what we ended up with changing the existing levels palettes is an easy trick that does not use many bytes to make changes in the level layout we opt for updating tiles in key locations only with this method the hard mode level data ended up using roughly 7 bytes per screen on average it's a bit of a generous statement but you could say this allowed the game to have twice the amount of content at the total extra cost of only a couple hundred bytes so now you know some of the tricks we use to make this game possible we are glad to present this project to you and hope you will enjoy playing it as much as we enjoyed making it thanks for watching [Music] a you

Channel: Morphcat Games

Views: 2,852,176

Keywords: Micro Mages, NES, NROM, Making of, optimization, space saving techniques, 40 kB, Pixel Art, Retro, 8-bit, homebrew, 6502, assembler

Id: ZWQ0591PAxM

Length: 12min 4sec (724 seconds)

Published: Wed Sep 05 2018

Reddit Comments

[u/ebkalderon]

Excellent and well-edited overview! The attention to detail and the cleverness of each technique is astounding to me.

[u/KrocCamen]

Comparison: Sonic 1 on the Sega Master System is 256 KB. 40 KB is a really, really tiny amount of space for a platform game, so I'm super impressed with this.

[u/LEmp_Evrey]

Now this is software craftsmanship.

[u/rob132]

This is what I thought I would be doing with my degree in Computer Science.

Instead i'm writing automation scrips for the telecom industry :(

[u/PinBot1138]

The video editing deserves its own accolades. It's incredibly time consuming to make great video, and I can't imagine how many hours that they spent on producing such a polished video, specifically, breaking apart the sprites for explanation.

[u/foreheadteeth]

Mayhem in Monsterland is slightly larger but is an insane display of technical prowess on the even more primitive C64.

[u/NiseP_Catcher]

I saw it, It was interesting. As a wannabe gamedev I learned a lot. A huge thanks to them. q

[u/neotorama]

Still better than some js website has> 5MB for landing page

[u/meme-by-design]

I wonder...if modern triple A games employed the same level of creative optimization, how small would they be? I know its likely not practical but what are the theoretical limits?