HTML5 Game Engine | Hacker News Reader

HTML5 Game Engine

kesiev.com

167 pointssandaru146 comments

I'm so psyched by the idea of games in HTML/JS. I've made a few games in Canvas myself using Processing.js: http://games.zetabee.com/ but frankly I'm amazed at the Akihabara games. I realized Processing.js was cool but I don't think it lends to raw speed as well as these games. I think I'll be making a lot more games in JS in the near future. Thanks for this link sandaru1.

Edit: Having looked into the source code... wow! For the "capman" game, he's creating the game map using ascii art and his "help.js" library has a function just for that: asciiArtToMap. This takes me back to the early 90s when making games meant you had to bitblt sprites and worry about every byte in the RAM. His library is great if you want to make sprite-based 2D scroller-type games but I don't know if it is easier to roll your own mini-library or use his for other types of games (e.g. puzzles). However, the source code itself is very extensive and I can certainly see the gamebox.font library being very useful for JS games.

Doing anything in JS and Canvas seems exactly like programming in the early 90s. I think Commander Keen on a 386 may have had more performance headroom than this! This is what is supposed to save us from proprietary tools like iPhone and Flash? I really don't get it.

Programming in the early 90s felt like the Wild-West - anyone could strike gold, anyone could make pickaxes, and anyone could build a town around a set of rail-tracks. Almost all of the large game companies today started as small programming teams in the 90s. I don't know what could be more exciting for startup.

The fact that feature-rich tools, IDEs and libraries don't exist for JS/Canvas games is EXACTLY why I love it. There is so much opportunity here for those who love to build and innovate. If you don't believe that JS/Canvas has a future, I can't change your mind. But if you think that there is a future for browser-based games running JS, then this a very exciting field to jump into.

Before prototype, mootools, and jQuery etc., JavaScript frankly sucked. It was alerts, statusbar texts, and title bar changes. I see Canvas being in that category right now. There is a lot that needs to be done before you will see a thousand "Top 10 tricks to speed up your Canvas game" posts but that's exactly where the most exciting part lies.

"Before prototype, mootools, and jQuery etc., JavaScript frankly sucked."

Proto, mootools and jQuery are written in JavaScript. So your statement compiles to "JavaScript sucked until people figured out what it could do."

(Which is essentially your larger point, but still.)

> "JavaScript sucked until people figured out what it could do."

Actually yes. Do you remember any amazing JS apps from 2002? IE6 has been around since 2001 and even on slow machines, it can still run most of the JS apps (provided you make the fruitless effort to support it). Where were the JS apps in 2002? Only things people used JS for were form validation and annoyances.

I know these frameworks are written in JS. What I meant to say was that very few people had actually used JS to its full potential and capabilities till just 5 years ago when protoype/scriptaculous/RoR and apps like Google Maps started to show up. I wrote an Ajax-enabled app for IE6 in 2003 and it was so much more work than $.ajax({url:foo,callback:bar});

There was the nice "asteroids" microsoft DHTML demo. But Microsoft was afraid of DHTML...

> Do you remember any amazing JS apps from 2002?

Yes, I remember Outlook Web Access providing a desktop-caliber mail client in the browser using ajax and javascript.

for rather low values of desktop-caliber

mootools made javascript a better language? Javascript is a wonderful language regardless of the availability of good tools and libraries.

He didn't say the language sucked, he said 'javascript' sucked, which includes the language and what people do with it.

I think all the hubbub is because the browser has dominated computing in the past decade. Being able to play a game on both your web browser and your smartphone with only minor changes (input, screen scaling, and perhaps locked fps) is a big deal because everyone knows how to use a browser and the barrier to accessing your game is as trivial as currently possible. Having to actually install a game, even if it's just downloading and running an installer, is apparently a lot more annoying to users than you'd think.

Unless some kind of native backend is written to make HTML5 apps just as responsive as plugin-based ones, I don't really see how this is going to be successful for games. The performance hit is just too gargantuan.

I think the performance won't be a big problem in the foreseeable future. There's some great competition going on between Safari, Chrome, Firefox and Opera. With every new version their Javascript engines get faster and with the coming WebGL we'll have hardware accelerated drawing in <canvas>.

This competition is precisely what was missing for Flash.

I think that Javascript, the language, itself has barriers to performance. I think few programmer know, for instance, that a dictionary lookup is 100 times slower than a switch statement. (If you don't believe me test it! It's what I found under Firefox anyway.) The language absolutely begs for a real map type... Objects just don't cut it because of performance (it has to be concerned that someone might have extended the Object prototype) and because of their limitations, e.g. confusion if someone defines a key string called "hasOwnProperty".

If you actually try to use some of it's nice functional features, as well, you can forget about performance. Maybe you think engines can solve these things, but I doubt it will ever compare to any language built from the ground up to have reasonable performance.

Even so, browser games as-is are bottlenecked by render performance, not language performance; both platforms are capable of running Quake(1 or 2), but JS holds the advantage as far as running it at reasonable resolutions and framerates, while the Flash implementations are hobbled by software rendering.

Even that bottleneck is going away; see: http://en.wikipedia.org/wiki/WebGL

Not quite powerful enough to run, e.g., Doom 3 or something.. but headway is being made.

Unfortunatly, it does not play well with a german keyboard. Z, X, C keys are used as buttons, but on a german keyboard Z und Y are switched.

I can assure you, it works much worse with a Dvorak layout.

This should be easy to fix with a 'configure my controller' option. They could let you choose which keys do what for their game, and maybe show the most common configurations as options before you make your own.

If you take the Flash market as an example, any sort of configuration seems to be too much effort for most developers to undertake.

(Although I happen to be building a Flash engine that would simplify adding configuration options.)

That's just laziness or lack of foresight on the part of the developers, adding customisable keys should be trivial.

Between this and the Apple iAd demo in HTML5, which notably demo'd pressing the screen and getting an 'inline' audio response instead of throwing you into a media player, a basic feature of most simple games currently missing from Mobile Safari, I think this is just about to get interesting.

The games don't seem to register my keypresses in Chrome on my MacBook running Snow Leopard.

I thought that too until I saw the tiny text informing me that "A" actually means "Z"

That worked. I didn't ever see the tiny text, though.

Did you try the "forced" versions linked at the bottom? Maybe it's detecting your browser as a mobile one.

Amazing... a few years ago I would have swore this was Flash.

Was excited about trying a demo on my iPhone, but seems the demos are all keyboard only. A mobile demo would go a long way since that's a reasonably big use case.

This is supposed to be a mobile version:

http://www.kesiev.com/akihabara/demo/game-tlol.html?touch=ye...

I couldn't get it to work on the desktop but the controls are there for touch screen.

Ah, thanks for that. Impressively smooth.

So this is using Canvas? I wonder for 2D graphics, especially for sprites you don't just use CSS, have all the blting and event handling done for you.

Now how do we all get sound working in HTML5 games?

With the new <audio> Tag.

A few weeks ago, I "converted" an old flash animation of mine to HTML5 <canvas> and <audio>: http://www.phoboslab.org/files/venetianization/

Oh dear. I closed the tab and Firefox kept playing the music.

Will this work well enough for use in an interactive game?

This is so awesome! It certainly is a step towards the future of online games. No more flash, no more CPU at 100%!!

JS canvas code can just as easily peg your CPU at 100%.

Right, because every browser is going to perfectly implement HTML5 without any bugs!

So 320x240 is the future?

I'm all for HTML5 and all, but this honestly doesn't impress me.

This is exciting because people are beginning to build cool libraries around HTML5, not because of the details of the games themselves.

Well, it ran great on my iPhone.

Slow but still playable on my 3G. It's probably not too shabby on the 3GS.

I really hope Apple have put some work into Mobile Safari's JS engine in 4.0. HW accelerated canvas rendering would be nice too.

Yep, totally smooth on the 3GS. Blows the hell out of those crappy Java games I played on the phone I had before my iPhone...

wow great work. HTML5 games are definitely going to be big

I've seen the future.

very nice work!

Looks nice - certainly runs fast in Firefox, but couldn't get it to work in Android - however looks like a good start.

Reply on news.ycombinator.com