So, what can the prototype do? Right now the engine provides

• a game loop
• resource loading
• an entity/component framework
• a 3D renderer (CubicVR)
• a 2D physics engine (Box2D)
• a bunch of unit tests and examples

Modularity is a strong design goal and we use require.js to keep the source code in small files that define reusable modules.

demo

Earlier this year we started collaborating with Andor Salga to build a demo game on our prototype engine. The demo shows off some of what the engine can do right now, but it’s also been very helpful in testing out some of our APIs. It’s also helping us collect some early performance feedback from the platform and identify issues.

what’s next

You probably noticed that there are some important features still missing from the engine, like sound support. In the coming weeks I’ll be working on a cross-platform sound extension for the engine. Input also needs work. Right now there’s keyboard support but it’s difficult to use. I plan to add support for input maps and stateful event handling to make it easier for game logic to react to state changes. Finally, I’m working on some refactoring in the engine core to clarify some key abstractions and to break code apart so that it’s more reusable and easier to unit test.

There are a few infrastructure changes coming as well. Dan Mosedale prepared a pre-commit hook that runs our unit tests. We’re also updating a bunch of programs in our toolchain to newer versions. And if we have time this quarter, we’ll be refactoring our unit test suite to use require.js so that we can test our source modules in isolation.

For more information about Gladius, check out our git repository and our project page.

The second change I made was to add task groups to help capture different stages in each phase. For example, there are default groups for Physics, Animation and Logic, as well as others. A new task can specify a list of groups as dependencies during creation, and the scheduler will make sure that the new task runs only after each of its dependencies has finished. Creating a new task looks like this:

var t = new engine.scheduler.Task({
    schedule: {
        phase: 'Update',
        depends: ['Physics'],
        interval: 100
    },
    group: 'Animation',
    callback: function() {
        ...
    }
});

This creates an Animation task that is scheduled after all Physics tasks, and runs every 100 ms in the Update phase. Because this task is in the Animation group, any other tasks that depend on Animation will be scheduled to run after this task. This is much cooler than a hard-coded game update loop because it’s not necessary to modify engine code to add new services to your game, only the schedule you pass in when you create your task.

(Thanks @secretrobotron for the pretty image!)