Who needs Flash? Build Flash-like game with scripty2
mir.aculo.us
mir.aculo.us
Show me something that fits in at Kongregate or ArmorGames, not something that was probably done in Flash a dozen years ago.
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.
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.
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.
Just wondering, is this how you respond in real life when others give you constructive feedback?
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.
http://games.zetabee.com/chains
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.
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.
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.
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.
Looks like Legend of Sadness has got a start on at least some of that.
http://mikecantelon.com/demo/demo_blood_funnel.html
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.
All in 70 lines of Javascript.
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.
Also, re: LOC, fwiw, you can do position/dimension .morph()'s w/ zero lines of code in Flash.
jQuery, scriptaculous, prototype, mootools -- all great javascript libraries, but not very good at game development.
thank you, but no.