Eh, as games go I'm not impressed. If you want to impress the guys using Flash to produce games (like me) you're going to have to make something much better than that.
Show me something that fits in at Kongregate or ArmorGames, not something that was probably done in Flash a dozen years ago.
Half of the point seemed to be to build Flash-like games. That's not a Flash-like game it's a one page tutorial that's probably been written for every language in the last 30 years.
The other half was who needs Flash? Until you can show games comparable to these - http://www.kongregate.com/top-rated-games - with no omissions or compromises or exceptions, the answer is people who are serious about producing casual games need Flash.
JavaScript is improving in a lot of areas but "not Flash" is a horribly weak argument especially when backed by examples such as this. "Not Flash" implies the platform's actually a problem itself ... consumers, developers and an enormous portion of the internet don't share that mindset. If you want to win marketshare against Flash you need to be better in most or all areas, not almost equivalent in some.
He's not though. Proving that you can write a small game in javascript/html5 does not in any way prove that you can write a complex, feature filled game.
I write games for a living (see http://www.rocksolidarcade.com), and the thought of developing them in html5, with the tools and compatibility we have now makes me sick. Eventually an abstraction layer that's fast and powerful enough will come along, once all the browsers support all the features needed.
But writing an abstraction layer, writing a tiny game in it and declaring that "in 2010, games built in JavaScript can be just as shiny, interactive, and fluid as games built in Flash." is ridiculous.
How about instead of giving us 'boys' 'a hint', you drop the condescending bullshit and explain exactly what you mean.
I'm an experienced and successful game developer. Hundreds of millions of plays. Done very well financially. People sometimes recognize my game on the street when I'm wearing a company shirt. I think that entitles me to have an opinion without being treated like an idiot.
Hey, no hard feelings. I think we're all guilty of that from time to time. I'm sorry I hit back so hard (I'd erase it now you've appologized but unfortunately the edit window has lapsed).
If you were using Flash IDE and wrote the game on the timeline, it would take the same amount or fewer lines, since a good third or more of the code is graphics and anim-related stuff that would be done entirely in the tool.
As the other guys are saying, if we're talking about a bigger game, libraries and frameworks can provide substantial savings since they help you build consistent behavior across the whole app. But you can build those for Flash, too. I'm building one. It lets you iterate over the assets while the game runs and then ship a preloader by running a different compile script; it has user setting abstractions for keyboard, mouse, and sound, it has bitmapped font support, an entity model, some limited-but-growing tilemap and spritesheet abilities, pathfinding...in the next few days I'm planning to build out a menu system that I can reuse or customize for every game.
In any case, these things are considerably more game-specific, and they provide an LOC savings that matters even on "weekend projects" - everyone likes to have user settings, everyone likes having a sprite sheet pipeline, etc. But you don't get that from a web framework used as a game platform, which is what this is.
I hope to make tons more over the next month. I use Raphaeljs and JQuery. The best part about making games in JS/HTML is that you can pick and choose the good parts from each platform. It is easier to do rotations in Raphael so I use its .rotate() function. It is easier to make a navigation menu using ul, li tags in HTML/CSS so I use that and overlay it on top of the Raphael canvas. You can even use JQuery to bind events to nodes created by Raphael.
I can easily include images and backgrounds natively and monitor mouse events. The best part is that the games work in all browsers and iPad/iPhone natively. Also I don't have to worry about loading native fonts etc. because I can just use the default browser fonts for most everything. Testing is also very easy because it's just a single JS file that I work with. I want to create a simple library for others to use but I don't have much idea on how to go about it. I don't expect to create something as complex as http://www.kesiev.com/akihabara/ but I think having a good framework for creating browser-based games would help.
If you're going to put 'Who needs Flash' in the title then this is low hanging fruit. :-)
Has anyone got any examples of more complex games in HTML/JS? I'd be interested to see how far people can push performance. The only benchmarks I remember seeing currently put Canvas+JS at a significant disadvantage over Flash but I'd love to be corrected on that.
Oh wow, those are great. It's been in my mind for years (basically since I discovered Comet) to create an in-browser 2D MMORPG based on a very large programmatically-generated trackable map.
Looks like Legend of Sadness has got a start on at least some of that.
The key to Akihabara performance is small number of actual pixels being drawn/computed.
Resolution of game's <canvas> is just 320x240 (check "view image" in Firefox) which is then blown up by browser renderer to 640x480 (in a same way how you can resize image in CSS).
Thus you get 4x as many pixels and cool retro 8-bit look with a lot of work done by browser's C++ code instead of much slower JavaScript.
Till we don't have hardware acceleration for <canvas> tag, unfortunately demos and games are going to be quite limited.
I have yet to see a game written in Canvas + JS that was anything but explicitly an advocacy demo for Canvas + JS. I don't think anyone is writing games with the main focus being to create something for the game's sake that people want to play. (A good metric would be, how many games or even demos are written in Canvas + JS where the author doesn't think it's important to mention the platform it was written on in the title.)
JS/HTML5 games certainly won't replace every Flash game but given enough time, there will be a new ecosystem for these games. When Flash games came out, this is what everyone said and compared them to PC games. But now we have hundreds of thousands of Flash games coexisting with PC/Console games. I think JS games will flourish because they are so easy to make compared to Flash or PC games. Also, they work in almost all the new browsers/devices.
Even though the speed/performance may not be up to par, good games will be made. And I'll do my best to make that happen. It is so much fun making these games. Seriously. Give it a shot. Flash games are a headache to build/deploy compared to plain-JS.
Targeted to Chrome: It's pretty slow in Firefox, alas, and sound doesn't work well in Safari.
Doesn't compare to more sophisticated Flash games, and my engine cries for optimization, but I think we're going to see a lot of HTML 5 games emerging.
I love the idea of "native" browser games. Sadly, even with the neat new things coming in HTML5 & CSS3, there will be big things missing.
Highest on my list is decent sound support. Needing to provide both mp3 & ogg (since different browsers support different sound file formats), suboptimal support for mixing, and lack of decent programmatic control of panning or channel volume all stand out as significant deficiencies, especially as compared to Flash.
Still and all, it's obvious that it's worth pursuing native browser games. Even without the sound support, there are a fair number of compelling games that could be done. Users often don't want the sound on in the browser games, anyway. Still, it makes the split between browser games and stand alone games wider than it needs to be, IMHO.
When made a game for Ludum Dare last weekend, I decided to see what I could do with Javascript. It was actually much nicer to work with than the flash work I've done. You can play it at http://labs.haleret.com/ludumdare/ld17/ld17.html .
Disclaimer: I'm the author of the tutorial (and core team member of Prototype, and the author of scripty2)
You can probably port the ideas and basic functionality very easily to other frameworks. Prototype or scripty2 don't contain anything specific to games, however. It's easy to write the interactions required in plain old JavaScript...
I do like to use Prototype for stuff like this, because it helps clean up the "logic" code a lot (for example the "avoiding stuck cards bit", section 17 in the tutorial.
Note that if you like this style of coding, but prefer jQuery, you can use the Underscore.js library, you might want to look into that.
for the real story on why non-flash web games matter, you have to look at ease of porting to mobile/smartphone/social network platforms. If you could write a game that had 50% of the richness of a flash game, but worked quite nicely on (highly monetizable) facebook and could be easily ported to the (highly monetizable) iphone, is that worth more to you than the richness and playability on IE?
So you're using prototype & scriptaculous to make a game. How is that easier than flash? How do I do particle effects using scriptaculous? How do I pair it with background music & sound effects? What if I wanted box2d style physics and collision detection? What's the proper way to animate a sprite?
jQuery, scriptaculous, prototype, mootools -- all great javascript libraries, but not very good at game development.
Show me something that fits in at Kongregate or ArmorGames, not something that was probably done in Flash a dozen years ago.