enchant.js, Source Engine Levels in WebGL, Ender
enchant.js
enchant.js (GitHub: wise9 / enchant.js, License: MIT or GPL) from Ubiquitous Entertainment Inc. is a new game engine that uses HTML5. It supports events, sprites, sounds, scenes, maps, and a whole host of other game-management classes. It also supports controls for touchscreen devices.
The game engine itself is designed around events, so from what I can tell it’s mostly asynchronous. There’s a plugin system for extending the engine itself, and some sample images are included which includes some font sprites.
Source Engine Levels in WebGL
In Source Engine Levels in WebGL by Brandon Jones, Valve’s Source Engine BSP format is discussed in the context of WebGL. Brandon demonstrated his code at onGameStart using a level from Team Fortress 2, but he hasn’t uploaded it due to licensing concerns.
The post contains a lot of details about Valve’s level file format, and how rendering complex commercial 3D game data relates to WebGL:
I was told once that one of the big reasons that WebGL doesn’t have instanced rendering is because it’s hard to make use of it in real world scenarios, so very few games do. I’d like to present my counter example, and ask nicely for the people making decisions to reconsider!
Ender
Ender (GitHub: ender-js / Ender, License: MIT, npm: ender) by Dustin Diaz and Jacob Thornton is a package manager for front-end JavaScript. It has a command-line interface that allows scripts to be packaged and minimised, which can then be loaded like CommonJS modules in a browser.
This builds ender.js and ender.min.js files that contain the specified modules:
ender build jquery underscore backbone
Then in my client-side scripts I can require libraries when they’re needed:
var _ = require('underscore')
, _.each([1, 2, 3], alert)
// Access methods augmented directly to the $
$.ready(function() {
$([1, 2, null, 3])
.filter(function(item) { return item; })
.each(alert)
})
The ender.js file adds this line to each module:
$.ender(module.exports);
From what I understand of Ender’s source, it actually wraps the entire client-side source in its own closure:
!function () {
var module = { exports: {} }, exports = module.exports;
// Original source follows
(function() {
})();
provide('module name here, underscore or jquery or whatever', module.exports);
$.ender(module.exports);
}();
It seems like an interesting solution to managing client-side dependencies as our projects become more complicated. I’ve actually found myself including client-side modules in my package.json, and then exposing their files to the client.
The authors claim that Ender encourages people to use smaller modules rather than monolithic libraries, and I think this is a good idea. Particularly now that strong, tightly focused libraries are becoming more commonplace.
