I'm currently working on an HTML5 framework geared toward game development focused on the Canvas element. The framework is modular and customizable, and has the following features/goals:
* Modular scripting
* Minimal setup
* Support for a wide variety of genres
The way the framework handles things is that it uses the Modernizr library to load scripts for various features/functions -- some of which are "core" and not optional (such as the "display" script, which facilitates access to the game canvases), and some of which are optional (for example, a module that handles tile-map rendering). The "core" of the framework is mainly used for setup, while the other modules are more specific to a game.
Of course, it is up to developer as far as handling their in-game objects (such as sprites). This way, a developer is able to develop simple, frame-based sprites; or mesh-based sprites with computational animation; or anything in-between. As long as this kind of object has a "render" function, the rest is up to the developer's imagination.
In other words, it does not attempt to hold one's hand -- it merely is intended to take away a bit of the tedium and hassle of certain aspects of writing a fully featured game.
I have already started on a couple of projects with the engine in its current state (a graphical Roguelike entitled "WulaBugr"; as well as a Poker game). The only differences between the code for these two games is certain object definitions -- for example, WulaBugr uses tile maps and sprites with frame-based animations; while the Poker game uses (mostly) static card images that are animated via motion (i.e. rotation and scaling).
These two games use the same game-state manager (though with differing state definitions), the same input system (with different input events defined for different purposes), the display module (which handles setup of a "screen" canvas as well as a "buffer" canvas), and even the same animation manager (animation sequences are actually objects that contain an arbitrary "render" function, which is passed an argument indicating the "position in time" of the animation sequence).
Hopefully you get the idea (my track record on explaining things is spotty, at best). In any case, I'm having a wee bit of trouble coming up with a title for this gizmo (it was originally intended to be an "in-house" tool, but I don't see any harm in releasing the source in case anyone is interested).
I need help thinking of something meaningful -- something that reflects the philosophy behind the framework (which is, in a sense, akin to the old "teach a man to fish" parable), but I think it would behoove me to get some input from others before searing a brand onto it.
If you have any suggestions (or more questions about the framework), type at me.