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?
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.
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.
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
Yeah, it is 
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.
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.
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.
