[Nathan Altice is the author of I Am Error, an extensive technical and cultural study of the Nintendo's classic NES platform, which contains a detailed analysis of the development of the original Super Mario Bros. Here, he considers the development of the original game, which celebrates the 30th anniversary of its original release on September 13, 2015, and today's Super Mario Maker.]
Super Mario Maker's release has brought new attention, especially among non-developers, to the structure and design of several of video game history's most important and enduring platformers. Since the game's unveiling during Nintendo's 2014 E3 Digital Direct, critics and players alike have expressed delight at the potential for amateur designers to take a crack at crafting their own Super Mario levels.
Previously the purview of ROM hackers and homebrew editing tools, sculpting the Mushroom Kingdom's athletic playgrounds is now within reach of any Wii U owner. And Nintendo's willingness to playfully acknowledge their own legacy -- allowing makers to seamlessly hop between four distinct Mario aesthetics or import mechanics from newer games into the old -- promises to yield many weird, anachronistic, and surprising levels.
But equally as important as placing an accessible tool into the hands of amateur designers is how Super Mario Maker offers a fascinating glimpse into the formal logic driving its games. Mario Maker's 2014 debut made this clear with the first clap of its virtual slate board, halting Mario's progress to overlay a graph paper grid and a menu of familiar structural elements atop the play screen.
With a clever visual cue, Nintendo exposed the tile-based framework lurking beneath its platformers' exteriors. Old-timers and pixel art aficionados likely understood that early platforms like the NES relied on interlocking tiles to build characters and worlds, but newcomers raised in the post-bit era may not realize just how rigid those parameters were.
During Nintendo's E3 event this year, Super Mario Bros. co-designers Shigeru Miyamoto and Takashi Tezuka explained that Mario Maker's inspiration came from Nintendo's own in-house editing tool. According to Miyamoto, "the tool got so good that, the more we worked with it, the more we realized we could also turn it into something everyone could enjoy."
Tezuka, holding aloft gridded sheets of paper with the familiar colored contours of several Mario courses, reminded viewers that he and Miyamoto originally conceived levels by hand, which they then passed along to their programming team for translation into code. This tantalizingly brief look at Super Mario Bros.' design heritage traced a direct through line from the NES to the Wii U.
In I Am Error, a platform study of the Nintendo Famicom/NES, I spend the bulk of one chapter describing the engine that drives the original Super Mario Bros. The game, its characters, and even its level design are some of the most widely discussed and analyzed in video game history, but few beyond a handful of dedicated ROM hackers and NES homebrew developers have delved into its source to understand how its machinery ticks.
There are numerous barriers preventing this kind of study, from the legal challenge of disassembling Nintendo's proprietary source code to the technological challenge of deciphering the terse syntax of the NES CPU's 6502 assembly language. But a contemporary developer might also wonder: Why bother? What relevance does a 30-year-old engine designed under considerable computational constraints have in 2015?
Today, the luxuries of Blu-ray, terabyte drives, and cloud storage have shifted developers' mindsets, as code and assets expand to fill ever more copious disk space. But 30 years ago, Miyamoto and Tezuka's small team managed to pack 32 levels, over a dozen enemies, taut platforming physics, a bevy of sound effects, and a memorable four-instrument soundtrack into the 40KB -- yes, kilobytes -- of ROM we know as Super Mario Bros.
In modern development environments, 40 kilobytes doesn't go far -- a 115-pixel square .psd, the minified Bootstrap JS file, two-tenths of a second of uncompressed audio -- but 40K was generous (and expensive) in 1985. When Nintendo's engineers devised the Famicom hardware in the early 1980s, they used Donkey Kong as the spec software, and 40K more than doubled the necessary ROM to contain the arcade source.
The dual ROM chips found inside the Super Mario Bros. cartridge (image: bootgod's NES Cart Database)
Famicom cartridges split that 40K of memory into two distinct chips: 8KB of character memory (CHR-ROM) and 32KB of program memory (PRG-ROM). The latter contained the game's code and piped directly to the NES's CPU, a slightly modified version of the MOS 6502 -- called the 2A03 -- found in numerous 8-bit platforms like the Commodore 64 and the Apple II. The smaller CHR-ROM stored the 8x8-pixel patterns that comprised the game's graphics and fed directly to the NES's Picture Processing Unit (PPU).
That 8K in turn was split into equal sections to house sprites and background tiles. Though they looked the same, their functions diverged: sprites could move freely across the screen, but were limited in maximum quantity (only 64 onscreen at once) and density (only eight per scanline); background tiles, in contrast, could be patterned and repeated freely across the screen, but had to adhere to a rigid, 32x30-tile grid.
Super Mario Bros.' sprite (left) and background (right) tiles, as seen in an emulator.
When the Nintendo Famicom arrived in Japan in summer 1983, 40K of cartridge memory was adequate to approximate the arcade titles that then dominated the video game industry. Nintendo's first few years of development focused on delivering convincing ports of arcade hits like Donkey Kong and Popeye. Few games required more than a handful of characters or movement beyond a single screen, and Nintendo's early experiments with scrolling, like Gyromite and Wrecking Crew, rarely panned beyond the two screens the Famicom's PPU could store in memory.
But as arcade technology developed and personal computers became more capable and prevalent, the demands of home play changed. The fierce difficulty of quarter-driven play made little sense on a console. Players had the time and desire to explore larger worlds, and Super Mario Bros. was Nintendo's first attempt to accommodate players' shifting priorities.
To appreciate how remarkable it is that Super Mario Bros. managed to pack 32 levels into 40K, consider the resources necessary to construct an NES image onscreen. Displaying a single screen of background tiles requires 960 bytes of ROM. Assuming we allowed space for no other code or assets, 40K would provide enough memory for 41 screens. Doing a quick survey of Super Mario Bros. maps, we soon discover that we reach our memory quota by World 2. So how does Mario ever reach World 8?
Lead programmer Toshihiko Nakago and his team devised a clever "object-based" engine that broke Mario's courses into several distinct layers. The "set decoration" layer spun out a repeating pattern of background tiles that described each course's scenery motif. In World 1-1, for instance, there is a noticeable cadence of hill, cloud, bushes, hill, cloud, bush, clouds, clouds, bushes that stretches across ninety-six tile columns. Nakago programmed the set decoration algorithm to be "automatic," meaning that the engine generated this pattern, no matter how long the level, until a specific end-of-level object triggered its conclusion. Those fortunate enough to jump the flagpole (or own a Game Genie) could see the set decoration routine at work, since the same stretch of unimpeded scenery repeated until the timer ran out.
The set decoration pattern found in World 1-1.
Two subsequent layers -- area objects and enemy objects -- formed the substance of Mario's level design. The former comprised the blocks, pipes, and other collidable elements placed for Mario's traversal, while the latter comprised the Goombas, Koopas, and other enemies that posed threats to Mario's progress. These objects could be placed "atop" the set decoration according to a simple, one-dimensional list of bytes formatted to include data about the object's specific type, size, and position. Flipping a few bits could move a spring into place, raise the height of a pipe, or swap a green Koopa for a red. The extreme economy of Nakago's engine meant that the entirety of World 1-1's area and enemy object lists, for instance, totaled 131 bytes -- a fraction of the data necessary to store tile data for a single screen.
"Thirty years later, what's compelling about Super Mario Maker is how it translates the NES's architectural constraints into its design space."
Thirty years later, what's compelling about Super Mario Maker is how it translates the NES's architectural constraints into its design space. Players aren't asked to fuss with set decoration, laboriously populating the overground courses with clouds or hills. Instead, dragging terrain across the screen triggers shrubs and trees to animate into place automatically. Mario Maker's core mechanic is object placement. Players select enemies, tiles, power-ups, and items and drop them onto the gridded playfield. And though the Wii U no longer divides its graphical elements into sprites and
No tags.
