Super Mario fully implemented in HTML5


I think it’s been Boinged at the moment…

I’m going to rant a little plus ask for clarification, as my rant may not be entirely on point. Shouldn’t we be calling this Super Mario fully Implemented in JavaScript? It’s my understanding that HTML provides little more toward this new form of game development than the canvas element, which offers up a flat pixel drawing surface to plop images and draw bitmaps and vectors onto (unless the Javascript is manipulating DOM elements, but that would be insane, and also, would have been able to be implemented in previous versions of HTML…). That’s a great advance for HTML, but I think this gives too much credit to HTML5, as if it suddenly has interactivity baked in. The lion’s share of the work of creating a game here is done with JavaScript. In fact, 99% of the files in the github are JavaScript files, and I would venture to say that not a whole lot of them are generating what anyone would recognize as “html” they’re managing image assets and placing them all on the canvas element. Once placed, the assets on the canvas can’t be address or changed, so the assets are being continuously juggled in that JavaScript code, waiting to paint the next state onto the canvas. Maybe this is nit-picky, but all of the JavaScript written here is near identical to the functional code you would write in any other environment, and indeed could have written for years in JavaScript, the canvas just gives you a place to paint it all in-browser. I’m not sure what power I speaking truth to with this little screed, but let me put it this way. If I had two people working on a project, an “HTML5 person” and a “JavaScript person” I know who would get top billing. (not that this would be a sensible division of labor)


But is it DRM’d?

1 Like

Open source and free and entirely unencumbered by bothersome copyrights and trademarks. Oh wait.

…I do have to hand it to Nintendo for not coming down hard on Super Mario Crossover and Mari0 and the various other creative concepts that have cropped up over the years, but then they’re probably well aware of the Streisand Effect.

Well, yes, you are right.

However, the Javascript could have been written for years and without the mechanism (i.e., canvas) that HTML5 provides, there was no way to actually have the Javascript DO anything from the end-user’s point of view.

So, HTML5 has become a shorthand way of saying, “HTML5/Javascript” as both parts are absolutely essential to making this work.

1 Like

I suspect that ‘HTML 5’ made its primary contribution(aside from the canvas element, which is about the world’s least efficient framebuffer) in spurring an arms race among javascript engines such that it is now possible to duplicate the power of bare-metal programming on a 1.79 MHz 6502 (with some hardware sprite acceleration) and 2KiB of RAM on a contemporary computer of merely modest specs…

In theory, (while it would be vile) you could ‘implement’ an NES in any browser modern enough to support a 256x240 cell HTML table and twiddle cell background colors (or 1 pixel images of different colors stretched to fill the cell, if you feel horrid); it would just be…not fast… on a level that mortals cannot truly comprehend until the javascript benchmark wars began in earnest.

(speaking of 6502s and javascript; nothing says “plenitudo potestatis, I haz it” like executing code, in-browser, on a virtual model of a once-current CPU (model built from actual die shots no less. No mere instruction set emulation here…))


Using ‘canvas’ just shows that you are a traitor to HTML tables and abusing cell fills! Heretic, we know your perfidity.

1 Like

1 Like

This is impressive, but there’s a lot off about it. The speed Mario moves, how he jumps, the responsiveness—these things are all very, very important—and they’re not quite right. It’s open source, so I bet someone ail come along and fix these sooner or later.

If you want to see a Super Mario clone that seems like they got these things exactly right, check out Mari0. Mari0 isn’t a straight port. It’s a Mario-Portal crossover, but the little things were clearly painstakingly reproduced. It’s cross-platform and the source is available as well.

It would be interesting if both the level editor and the generator could optionally enforce NES limits. Those limits heavily influenced the design of the games themselves and the levels.

For example the generator just made a level with 5 goobas 2 helmut guys, and 2 turtles blocked by 2 piranha plants. It’s unlikely an NES game could do that and (a) not slow down a bunch and (b) it would flicker like made given it’s 8 sprite limit per scan line. A sprite on NES being 8x8 pixels means most enemies are 2x2 sprites so if you want no flicker you can never have more than 3 enemies in a horizontal area of the level on screen at the same time since once Mario enters that area he’s 2x2 to 2x4 sprites.

A good designer like Miyamoto would generally not have allowed the slowdown or the flicker and so would have designed around it. If the editor could warn you when you’re breaking those rules it would be really interesting feedback for new game designers

1 Like

Yeah, it is :frowning:

You have a good point with HTML5 being different from JavaScript. It is, and not enough people understand it. Javascript is a friendly soulmate to HTML5. The majority of the game is just parts of the game engine, but there are a few features make HTML5 a more accurate descriptor than pure JS:

  • CSS3 transitions - especially within the editor (also not technically HTML5)
  • <audio> element - which is actually HTML5
  • <canvas> element (most importantly) - what made it all possible. The first builds of the game just used <div>s for everything, which was crappy for performance and elegance. Now that it uses HTML5’s canvas, it runs way faster. Most elements are generated with the createElement() function.

tl;dr: There’s HTML5 there

Audio and Canvas tags were added by Apple to Safari before HTML5 was a thing, and they work just fine in HTML4 documents. You can actually take the JavaScript code for Mario here and render the game in a Flash-based implementation of the canvas API or take it to mobile with Open GL ES via Ejecta or the like… and not use any HTML at all. So the game is created with JavaScript, and it happens to be using a couple of HTML elements that are now in the official HTML5 spec for rendering graphics and audio.

The only reason anybody bothers to mention HTML5 ever is for marketing/buzzword effect. And BECAUSE of the fact that it is a buzzword (made so by Google) now “HTML5” is also the shortest way to explain to somebody you made something with JavaScript instead of Flash.

So HTML5 is actually a new specification of HTML tags (and really doesn’t do much compared to what JavaScript and CSS3 do). But people don’t use “HTML5” to mean that. They use “HTML5” to mean CSS3 and/or JavaScript and/or some HTML5 tags, too. And sometimes an “HTML5” project doesn’t even use any HTML5 tags at all.

If you want to be angry about the term being used in a technically incorrect way, please blame Google. It is the fault of their marketing department.

To be fair though, people write games mostly in C and then call them “OpenGL” games. That’s a kind of similar situation.

P.S. I didn’t know it was ok to steal Nintendo sprites.

1 Like

Man, I bet this is a hoot. Too bad I can’t find a browser that will run it. Chrome doesn’t do anything, Firefox and Safari give me the error saying to use it in chrome and now I just want to get get my NES and dust that off…

It’s worth noting that what’s being called HTML5 is almost antithetical to what W3C originally intended HTML5 to be. It was supposed to be a push back toward separating semantic markup and rendering.

I also am unable to get it to run (Chrome, Firefox, or IE).

Ok… I’m going full-on off topic now! HTML5 was the kitchen sink spec vs XHTML2 which was very much about advanced, semantically meaningful markup. HTML5 was about flattening all markup languages and conventions into one spec. For example, using SVG in HTML5 is way easier than what was proposed for XHTML2… that’s good. The HTML5 spec also supports all the bad, sloppy forms of markup that aren’t valid XML… that’s less good. So anyway, HTML5 won out over XHTML2 (follow the money), and while some of its document/text tags provide semantic meaning that used to have to come via class attribute (e.g. article/section/paragraph tags), HTML5 did NOT bring us any closer to a machine readable web with real semantics. We’re still left with micro format bandaids that aren’t widely adopted for things like phone numbers, contact info, product meta data, etc etc. XHTML2 would have been more sophisticated and better for content consumers… but I’ll concede potentially less accessible for content authors.

1 Like

Thanks for the reply, and I realize now I didn’t give proper kudos on the project. It’s a great idea well executed. I’ve done a couple of small animated and interactive projects with JS/CSS on the canvas, so I can only imagine the commitment and creativity this took. Again, I hope my comment didn’t come across as diminishing the project itself, but rather, following a lot of what @zachstronaut said, I think that the buzzwordliness of HTML5 actually conceals and confuses the domains where the balance of the effort learning and talent take place.

That was exactly my take as well. The speed, jumping, etc are a bit off and when you want to clone a game that is so universally loved, getting those things right is ultimately more important than having it be pixel for pixel visually correct.
We didn’t love SMB for the graphics. We loved it for the way it played.