The long shadow of Super Mario Bros.

[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 30^th 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. 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 background tiles, their logic still applies to Mario Maker's toolset. Mario appropriately behaves like a sprite, moving freely across the grid, but question blocks must lock into place at preordained intervals.

In Super Mario Maker, the ease of object placement, the variety of available objects, and the quick snapping between Play and Edit modes encourage frequent iteration and refinement, both hallmarks of the level design process. Unsurprisingly, Super Mario Bros.' engine supported the same approach. Shifting a block eight pixels to the left or swapping a Goomba for a double Goomba did not require the programmers to re-architect the entire level; editing a few bytes was sufficient. Nakago's engine was impressively efficient and flexible for its time, and these features allowed Miyamoto and Tezuka to focus on refining design rather than code.

Of course, Super Mario Maker includes significant departures from Super Mario Bros.' original constraints. The most obvious additions are anachronistic retrofittings of characters, locations, and devices from future series iterations, from Bowser's brood to spinning blades to ghost houses.

But more nuanced revisions appear. Super Mario Bros. originally limited Mario's movement to a single vector. Once the screen scrolled right, the contents of the world beyond the left border were literally wiped from memory (at least from the engine's perspective). Limited RAM made tracking the status of breakable objects unfeasible, and the NES's unique handling of PPU memory made simultaneous horizontal and vertical scrolling challenging. (Think back to many of your favorite early-era NES games like Mega Man, Contra, or Metroid. You could travel both vertically or horizontally, but not at the same time.) Super Mario Maker erases the leftmost barrier, doubles the screen height, and expands the aspect ratio to bring the original into design parity with its successors.

Further graphical flourishes were never seen on the NES. Hardware sprite scaling and rotation weren't possible. Massive stacks of enemies would've quickly capped the 64-sprite maximum, triggered extensive flicker along crowded rows, and taxed the 2A03 into (the NES's trademark) massive slowdown. Object shadows weren't worth the sprite expenditure. And subtle palette improvements -- note the background hills feature green hues not found in the nearby pipes -- were impossible on the NES platform.

The irony is that Nintendo's extensive attention to polish and the expanded palette of objects have created limitations that the elder Super Mario Bros. never faced. While Super Mario Maker sets a hard limit on the width of its courses, hopping the flagpole in Super Mario Bros. demonstrates that its level lengths were limited only by the designers' whims and the maximum capacity of the cartridge. In fact, the flexibility of Nakago's engine coupled with the mutability of assembly language meant that when certain data safeguards were circumvented, Super Mario Bros. could auto-generate unintended effects -- not just 32 worlds, but more than 200.

Older NES players likely remember the fabled Minus World, a "secret" level discovered accidentally by players who used a quirk of the game's collision detection to slide through a wall at the end of World 1-2 and "trick" the Warp Zone into transporting Mario to World -1. Nintendo Power confirmed the trick in its third issue and tantalized readers with "an endless water world from which no one has ever escaped." In reality, the looping Minus World proved more punishment than reward, but it prompted players to wonder whether Team Mario had tucked away other hidden levels.

In Japan, the fervor over Super Mario's grew to the point that Miyamoto had to officially deny the Minus World's authorship and reassure players that it was an unintended glitch. As we now know, Mario is whisked away to the Mushroom Kingdom's negative regions due to a misread byte. In assembly language, the 2A03's native tongue, all information -- whether instructions, graphics, or variables -- is ultimately represented in bytes. How the NES interprets those bytes depends on their context. Sometimes the hexadecimal value A9 instructs the CPU to load a value into a special memory register; other times it simply represents the value 169.

Again, Super Mario Bros.' set decoration logic unfurls its scenery incessantly until instructed to do otherwise, while the sequence of bytes that describe its area and enemy objects are placed in order atop that backdrop. These byte sequences are stored in specific locations in PRG-ROM. So as long as the engine starts and ends at its prescribed memory locations, the courses unfold as intended. But if some code mishap occurs and the engine begins its work at an arbitrary point in memory, it can't distinguish between "valid" and "invalid" bytes. The engine's flexibility permits it to translate any bytes, whether soundtrack data or Mario's jump routine, into level objects.

This behavior formed the basis of a bizarre trick that had Famicom players swapping between their Super Mario Bros. and Tennis cartridges mid-game in order to drop Mario into dozens of weird and often unplayable worlds of floating grey Bowsers and impassable walls never intended by the game's designers. What began as a minor Minus World mystery spawned a machine-generated mythology, one so enduring that sites like Marionaire exhaustively document every possible combination of worlds hidden within Mario's cartridge ROM.

A handful of Marionaire's documented "minus worlds."

Such esoterica may be beyond the ken of many developers, but this kind of bitwise archeology reminds us that newer, next-generation consoles do not necessarily mean bigger or better games. "Obsolete" technology can still be wrung for new secrets and new surprises. Much of what's new and compelling about Super Mario Maker is what's old but unknown. And Nintendo is particularly masterful at connecting its design heritage with its design future. Plumbing Super Mario Bros.' engine reminds us that massive constraints can breed exceptional, even mythic, creativity. Whether Super Mario Maker will spawn its own legends is now in the hands of its players.