Worst Mario Game Ever In the 15 years between the time the U.S. Government introduced Cabbage Patch Kids to desensitize the public to the appearance of mutated children born in the aftermath of a nuclear war and the time the U.S. Government released the final arcade version of Super Battletoads as part of a series of ESP experiments trying to seek out precognition in children, there was a golden age of video games. I was born into that era. The first few years were governed by blocky graphics and beeps-and-boops for soundtracks. But, much like the mutated rabies virus that the U.S. Government will "accidentally" release ushering in the zombie apocalypse, video games were evolving at an exponential rate. My first exposure to video games occurred at Showbiz Pizza Place featuring the animatronic band, The Rock-afire Explosion, the robotic ancestors to the cybernetic androids that the U.S. Government will be forced to unleash in a futile attempt to control the zombie apocalypse.

As a little kid, I never questioned why a robotic band would have to take breaks between songs. But, it's clear now that it was just to present the kids with opportunities to pump quarters into the arcade machines that filled the place.

In fact, the arcade machines were rigged to only accept tokens. As soon as you fed a bill into the token machine, your money was already gone.

To save on tokens, the arcades were coming home... in a very technically-inferior fashion.

Unlikely the consoles that followed it, the Atari 2600 enhanced your imagination skills. No my friend, those are not blocky graphics at all. There is an entire universe in there.

I was also fortunate enough to own an IBM PCjr. Released in 1984, the PCjr was marketed as a gaming PC featuring 2 joystick ports and 2 cartridge slots. It featured a 16-color extension of CGA and sufficient RAM for off-screen buffering, enabling full-screen flicker-free animation. It also supported 3-voice sound.

Mr. Wizard actually demoed the ColorPaint cartridge seen running above on one of the episodes of his Nickelodeon show, mirrored optical mouse pad and all. Actually, come to think about it, I wonder if IBM paid Nickelodeon to do that.

The genre of graphical adventure games that would dominate PC gaming for the successive decade began on the PCjr.

When it came to computers, it was still very much a hobbyist-era. Magazines and books featured BASIC programs that you could type-in. They encouraged you to tinker, to be creative.

As a little kid, the idea of creating my own video games was sufficient motivation to learn how to program. I had all the tools that I needed.

"Cartridge BASIC"... Really? They couldn't think of a better name for it?

In fact, I had access to another flavor of BASIC. Scroll back up for a moment and study the image of the Atari 2600. Notice it says, "VIDEO COMPUTER SYSTEM", above the cartridge slot. Atari was forced to release a version of BASIC for the 2600 because customers complained that they advertised the system as a computer and computers are programmable devices.

Look at that box art. So that's what it's like to be a video game programmer! This "Special Edition" cartridge will thrust you into Stanley Kubrick's 2001 and beyond! But, like most Atari 2600 game boxes, the amazing artwork would not compensate for the crappiness within. Due to hardware limitations, the IDE restricted you to 9 lines of code and the language itself had only the slightest resemblance to BASIC.

The cartridge came with special keypad controllers. Compare the arrows around the button at the bottom of the left keypad in the image below with the logo on the shirt of the man on the box art. That's about the extent that the box art has anything to do with the box contents.

Okay. Programming for the Atari 2600 was out, but at least the box art was inspiring.

Anyway, 2 years after the PCjr was released, the Nintendo Entertainment System (NES) hit store shelves. It was bundled with Super Mario Brothers, the game that would serve as the template for all side-scrolling platformers, defining the gaming landscape of at least 2 generations of consoles. Before the NES, arcade game designers thought of video games as digital extensions of carnival games or pinball machines. Duck Hunt, which was crammed into the same cartridge as Super Mario Brothers, was designed with that mentality.

Compare it to the Seeburg Ray-O-Lite machine released in 1936.

While a handful of side-scrolling platformers did exist prior to the introduction of the NES, the prevailing design mentality of the time was that game play occurred on a single static screen usually with a black background to improve contrast.

The restriction was not necessarily because of technological limitations, but rather due to video game designers failing to fully recognize the significance of the very concept of the side-scrolling platformer.

IBM did not have the foresight to introduce video hardware necessary to support side-scrolling.* Consequentially, for the next few years, even though PCs had far superior processors and memory, PC gaming evolved along the lines of slower paced graphically-rich adventures while the consoles owned video games.

Nevertheless, as a little kid with my magazine-acquired BASIC programming skills, I still wanted to develop video games for my PCjr. My games wouldn't require the fancy graphics of the NES, which I couldn't draw and the PCjr couldn't support anyway. I would borrow ideas from the Atari 2600, which demonstrated that game play could be achieved with less.

The PCjr supported 2 text modes. As you can imagine, the 40×25 mode displayed a very large monospaced font. In that mode, I combined ASCII characters 1 and 19 together to form this little armless guy:

More inspired by Mega Man than Super Mario Brothers, my text mode video game even used asterisks for spikes, the deadly obstacles seen in the NES screen shot below.

I didn't develop more than a few screens of that game. I wanted to do something more ambitious, something with actual graphics. I drew a screen consisting of a red stickman, some brown blocks and some green pipes representing Mario and his world. Below is a recreation resembling what I remember. The original BASIC source is long gone.

I didn't know anything about physics or math for that matter. When my stickman jumped, he moved upward linearly for a specified distanced and then he reversed direction. He jumped in a saw-tooth pattern instead of a parabola. However, since he moved 1-pixel-at-a-time in any direction, collision detection between the stickman and the ground and pipes was easy. It checked the pixel color below each foot and to the left and right of the hands. If it wasn't black, then the stickman couldn't move there.

Sadly, that's about as far as I got. Reality began to set in. I had no idea how to write a game engine. I had no idea even how to do the timing code. In fact, most PC games of the era got that wrong forcing PC manufacturers to include Turbo Buttons that enabled you to slow your machine down for older games.

Luckily, my interest in programming never waned since I was a little kid typing in code from magazines. I often wondered, what could that Cartridge BASIC version of Super Mario Brothers have been had I actually had the knowledge to write a game engine back then. Was I crazy enough to fire up an IBM PCjr emulator to find out? Nope. I wanted to create something that people could play online that was in the spirit of my PCjr coding efforts. I don't know Flash and I predominately code in Java; so, Java it was.

Several websites feature images of all the worlds stitched together from screen captures from NES emulators and I began this project by encoding them by hand into text files. Of course, it's possible to rip the maps directly out of the ROM file, but this way gave me a chance to make minor changes if necessary and it also gave me that long-lost feeling of typing in magazine source code.

It occurred to me while doing this, that I don't think that I ever played through all the worlds. Super Mario Brothers doesn't offer you a continue option on the Game Over screen (Yeah. I know about the A+Start cheat on the Title Screen. I'm not sure if I knew that one as a little kid though.). In this way, there was little incentive to play through every world. Instead I would warp from 1-2 to 4-1, warp from 4-2 to 8-1, and then just play through to the end, missing most of the game. I added a continue option to my version. I also added a hard mode that replaces Goombas with Buzzy Beetles, shortens moving platforms, and removes the Warp Zones forcing you to play through all the worlds to beat the game.

I was also surprised to rediscover that Super Mario Brothers doesn't have much of an ending aside from a few sentences of text. It doesn't even credit the developers. I decided to add a more interesting ending to my version.

Java's write-once-run-anywhere motto fails when it comes to fonts. Fonts render differently on each system. A bitmap font would solve the problem, but I wanted to avoid bitmaps. So, I made a simple font based on the 16-segment displays on my microwave oven.

My games doesn't feature sound or bitmaps or much of anything else. The default keys are:

Move = Arrow Keys Run = D Jump = F Pause = P Start = Enter

The keys are configurable if you prefer a different mapping.

LAUNCH GAME

Feel free to hack up the source code.

2010.08.14

Update 2010.08.21

Bug fixes:

There are 3 pipes that you can enter in World 6-2 that take the player to a bonus area. Prior to this fix, if you entered the right-most of the 3, the game would freeze.

The player has built-in block-alignment logic. If the player stands below a narrow opening that is exactly 1 block wide, he will need to be precisely aligned with the opening to jump into it. The block-alignment logic automatically moves the player slightly left or right when it detects such a situation. Also, the world only scrolls rightward and the player is never allowed to pass through the boundary defined by the left side of the screen. Prior to this fix, the block-alignment logic and the screen boundary could conflict causing the player to get stuck. This was originally detected on World 4-2. In the NES version, the player can exploit a bug in similar block-alignment logic that enables the player to climb. Close to the start of World 4-2, the player smashes out a column of blocks exposing the ceiling. Then, the player advances, scrolling the world until a channel slightly less than 1 block-width is formed against the right edge of the screen. The player then jumps into this channel. In the NES version, the block-alignment logic forced the player into the channel and then upwards 1 block. The player could then jump a few times, smashing blocks and gain access to the ceiling. However, due to the aforementioned bug, the player would get permanently stuck hanging there as if glued to the blocks above. After fixing the bug, the player will not get stuck; however, he cannot climb either. Meaning, you can't cheat in this version.

Prior to this fix, when the player beat a castle as Luigi, the game thanked Mario instead.

If the player maintains running speed, he can safely run over gaps 1 block wide. Prior to this fix, sometimes the player would fall through such gaps while running.

This fix makes some worlds slightly easier. It adjusted Turtle Cannons to fire less frequently.

I also clarified some of the discussion above and I fixed a few typos.

* For those interested, even though PCs had superior processors and memory capacities years before the introduction of the NES, they still lacked the video hardware necessary to support side-scrolling games. Much like text mode on PCs, the NES took advantage of tile mapping indirection. Backgrounds were constructed out of 8×8 pixel-sized tiles and a 32×30 map of 1-byte tile identifiers, called a "name table", covered an entire screen. For scrolling, the displayed image was generated from a pair of name tables conceptually laid end-to-end. The read offset into the pair could be adjusted by simply modifying values of video registers and if you offset beyond the boundary of the pair, it would effectively wrap-around. The full level map was stored in memory elsewhere and it would be incrementally copied, either 1 column-of-tiles-identifiers-at-a-time for horizontal scrolling or 1 row-of-tiles-identifiers-at-a-time for vertical scrolling, into the hidden region of the name table pair as the read offset changed. Copying memory is the slowest part of the process, but due to the indirection, only 30 bytes per column needed to be copied as opposed to 1920 pixels worth of data.