Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.
X

More Physics

Today we integrated box2Dweb (http://code.google.com/p/box2dweb/) into our game engine. It is based on version 2.1a of box2DFlash and is more up to date with the original box2D engine compared to box2Djs. We also added the option of using our own physics. Unfortunately we only have support for circle shaped objects so it’s not quite as exciting.

Say hello to Box2DJS!

Yesterday we realized that implementing a physics engine of our own had been a bad idea. It would have required a huge effort, and it would still not have been comparable to the big names out there. So, we thought to ourselves, why not smoothly integrate a free solution into our game engine, taking something good and making it better? Well, we couldn’t really think of any particular reason, so we spent today on integrating Box2DJS (http://box2d-js.sourceforge.net/) into our engine, and so far it has been going very well, as the screenshot implies.

Drawing in debug mode

We have implemented a hierarchical grid data structure to store all our physics entities, and to have a fast way to check for potential collisions. We have also added the option of rendering debug information, such as frame rate and bounding volumes.

Simple animations and an outline for the physics system

The engine can now handle animated entities by simply cycling through a set of predefined images. On the picture,┬áthe hatch of the boat opens repeatedly, and the green moose actually toggles between green and brown once every second! Also, we have implemented a physics manager and a physics property – the moose at the bottom is really falling downwards!

Layers and LevelLoader

A test has been successfully carried out in which a level is automatically loaded from an XML-file. Each of the moose has three properties: one for graphics, one for input and one for camera control. The focused moose is always centered in the middle of the canvas since the camera is following it. The moose to be controlled and followed by the camera is toggled with a certain key. The moose are explicitly put in different layers in order to be rendered in the correct order.

Property test 1

Things have been running smoothly and we have just recently performed a first test of game entities with properties. Below is a screenshot from a test where the moose in the middle had an inputproperty as well as a cameraproperty. The moose was steered via the arrow keys, and the camera followed it automatically.

To be able to use the concept of properties we had to implement the skeletons of quite a few of the main parts of the whole engine. Following is a list with the script files partly implemented so far.

First design

So we are officially underway. Last week we started thinking about the engine design, and we summarized our thoughts in a UML which you can view below.

We have also tested the performance of the canvas element by drawing 10 000 moving moose. We got a little bit stressed out at first, because the version of Firefox we were using (3.6) occasionally experienced sudden extreme drops in framerate. Luckily, the fault didn’t lie with us – when we tested with Chrome we got very stable framerates so that is the browser we will be using primarily while testing, for now.

Project Plan

We are finished with the first version of our project plan which is available here. After the presentation of the plan on Monday, we will begin working on the general system design of the engine. Exciting!

Hello world!

So, we are officially up and running! The Venison Engine will be using HTML5 and JavaScript. It will not utilize WebGL since it still has very limited support and because the engine at this stage will have no need of 3D functionality. The first version of the complete project plan will be presented on Monday.