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

New server

We have moved the test environment to a dedicated server, meaning the site will be accessible even when my computer is turned off. Furthermore, it even has a fancy-pants domain name, so you don’t have to hassle with writing in my IP-address and port number. Here it is:

xaero.gscept.com

And to play Floose, simply go to

xaero.gscept.com/floose

Remember that the recommended browser is Chrome, and that it will not work at all in Internet Explorer.

Otherwise this week has been dedicated to fixing bugs and making a new level for Meat Factory. Also, we have added the possibility to send delayed messages to entities, which might come in handy in different kinds of games.

Pre Milestone 3

We are working on the presentation for Milestone 3 which is due on Monday (14/3). We have also written a post mortem report. All that’s left now is some polishing and documentation of the code.

Platformer kit

We have worked on a small demo game to showcase the capabilities of our engine in the form of a platform game called Meat Factory. It features a state based animation system with support for transition animations to play between states. To enable this we made an animation manager class that handles the updating of all animations. When playing an animation with the manager a lot of options are present, for example, you can set the frame rate of animations, decide if it should loop or not and also supply a callback function to be called when the animation has finished playing. So in the game, when going from one animation state to another we first check if there exists a transition animation between these. If a transition exists we play that one first and from its callback function we play the animation we originally requested.

We have also made a very useful trigger property that can be put on entities that should do things when touched by some other entity. This property became so general and useful that we’ve decided to add it to the core of the engine. It has attributes for what type of response it should send to an entity that touches it and if it should be removed on contact or not. In Meat Factory we currently use this property for pickups, spawn points, areas that kill you and also the level goal. When touching the level goal a new level is loaded and the player is spawned in that level. To keep the player between levels, we copy it the same way as in the editor and then simply paste it to the new level once it has loaded. To be able to change which level is the starting level as easy as possible we have made an entire level just for the player that we load first to get the player with the attributes we want and not have it attached to a game level.

This demo game will most likely be released along with the engine as a platformer kit to give developers some ideas on how to use the engine.

Apache2 and php5

At first we implemented a web server using node.JS exclusively. Recently however, we have put the responsibility of serving the page and all contents on an Apache2 server instead, leaving node.JS with only the real-time network handling. The reasons for this were multiple. To start with, Apache2 comes with many neat web server features (e. g. php and media streaming) all set and ready to go, neatly presented in an easy-to-get-going package. To re-implement them all in node.JS just for the sake of it would be time-consuming and unnecessary in our case. Also, apache is the most widely used web server solution in the world, so we figured it would be advantageous to gain some basic knowledge about it. We find it easy to see why it is so popular: it took like five seconds to have a page up and running.

We feel that this hybrid model has the potential to really harness the individual strengths of two different systems, and it also encapsulates the functionalities in a really easy-to-work-with way.

Audio and polygons!

We have been working on an audio manager for our engine, a process which has not been entirely painless. Not only do various browsers support different types of audio formats, they handle the audio tag differently, especially when trying to retrieve the file from a server. The way we have implemented it now however seems to work pretty well. When loading an audio file, the audio manager is supplied the file name without the suffix and then it proceeds to query the server about a file that is suitable for the users current browser until it finds one. This means that for the audio to work in all browsers the server has to supply the same audio file in the formats ogg, wav and mp3.

Not everything has been pain though, a cool new feature in the physics editor that was quite fun to implement is shown in the picture above, namely the ability to draw polygons! When drawing polygons, vertices are added one at a time by clicking somewhere on the drawing area. Because the polygon has to be convex in the physics engine, every time a new vertex is added we go through the shape to make sure everything still looks OK. If any point would make the shape concave as a result of adding a new vertex, that point is removed from the shape. This makes closely fitting a physics shape to the entity much easier.

Floose: Flying Moose on the Loose!

We are proud to present Venison Engine’s first game (click here to play!) (only tested in Chrome on Windows 7 and Ubuntu):

Floose!

You now know the truth. The crazy scientist bent on world domination who planned on spreading terror across the earth through brain wash and genetic manipulation of cute and harmless animals – who seemed so nice – was really evil all along. So now you and your fellow flying moose must compete in order to eventually be able to stop this madness in an ending cut-scene or a sequel maybe.

Instructions: Avoid the walls, the floor and the ceiling. Click the canvas to make your floose fly up, release to make it fall.
Tip: Small movements are easier to control than large ones.

Floose utilizes real-time multiplayer capabilities implemented with socket.io powered by node.JS on the server side. Any other players connecting to the server will show up in your browser window, and will be updated in real time. Try this by opening multiple tabs in your browser and navigate to the page.

Please note that this implementation of Floose is merely a simple tech demo to show what possibilities might exist in the final release of the Venison Engine.  As such it is not intended to be a full-fledged, robust and enjoyable game. As a result, we haven’t had all that much time to put on the design and polishing of the game . For example, the other players moose do not look particularly good. Also, there is no way to win or lose, and the level is very boring since the obstacles are constantly reappearing in exactly the same pattern. Furthermore, we have not spent any time on designing any cheat-prohibiting mechanisms – take a look at the code (by showing the source of the page) and you will see that the full responsibility of every player lies with the client; the server more or less only acts as a forwarder of messages between the clients.

Physics Editor

Shown in the picture above is a sub-editor to the main one, and it is used for editing the physics shapes of entities. To edit shapes for multiple entities their textures have to be the same and only the shapes that they have in common will be shown.

The main drawing area shows a scaled version of the texture of the selected entities and their physics shapes. To add new shapes to the entity, first select a draw mode in the upper right (currently box and circle) and then draw the shape on the canvas. If you instead choose the ‘select’ option from the radio buttons, you can click on entities to select them.  The currently selected shape is drawn in red color and shape specific information is shown on the right side of the screen. In this area it is possible to fine tune the values of the shape, set its collision categories and also remove the shape from all selected entities. There is also a button for clearing all the shapes that the selected entities have in common and, of course, a button to exit the editor.

More Editor Features

The screenshot shows the new camera controls (bottom left of the main area) and the game area reference controls (bottom right of the main area). They are both transparent, and their visibilities are toggled via the buttons in the main menu on left. The game area reference controls are used to show what area of the world will be initially visible in a canvas of a certain size, representing it as a black rectangle in the main view.

In the top right of the screen is the minimap which shows a bigger part of the (theoretically infinite) world. On the minimap, the black rectangle represents the area of the world that is shown on the main drawing area (note that the camera is rotated in the screenshot, resulting in a rotated rectangle on the minimap). The minimap camera automatically moves to always fully contain the area that the main camera is showing.

The screenshot also shows the ability to drag and select multiple entities at once: the green rectangle is the selection area.

Viewport Culling

Recently we discovered that it would actually save some time if we could figure out which entities that were outside of the visible area and not draw them. So we made a hierarchical grid data structure (hgrid) and some very coarse ‘collision detection’ to do so. The hgrid uses hashing to store the entities, allowing for an infinite number of grid cells, theoretically, maintaining the needlessness of specifying world boundaries when using the engine, since the box2dweb physics engine also allows for infinite world sizes. The hashing combined with a double linked list structure within the hgrid allows for a time complexity of O(1) for insertion and deletion, making it straightforward to keep the hgrid up to date – an entity that is moved is simply removed from the grid and then inserted again.

However, the first implementation of the hgrid contained a fatal bug: when removing an object from the double linked list, it’s pointers to the previous and next objects weren’t nullified, resulting in circular chains within the list, in turn resulting in infinite loops when checking the viewport against the grid. It was a very hard bug to track down, since the program seemed to work fine until one entity sharing a grid cell with at least one other entity was moved out of that cell and then back into it. The program would then freeze due to the infinite loop as mentioned above, causing confusion among the testers.

Unfortunately, the results of culling are rarely something to show, mainly because the fundamental purpose is to figure out what NOT to show. Nevertheless, appended below is a screenshot showing the successful culling of approximately 2000 entities outside the visible area of the canvas. Enjoy.



Venison Editor

For the past week we have been hard at work creating an editor for our game engine. As can be seen on the picture, the main view has a few different areas defined. In the top left corner of the screen is an image view where users can place images that they want to use while working in the editor. By dragging a picture from this area and dropping it onto the big area in the middle, a game entity is created and inserted into the level.

The middle area is a canvas element that displays the current state of the level and you can move focused entities around by dragging them (or use the arrow keys). To make an entity focused, you simply click on it. This will also display information about its properties in the lower left corner that users are free to edit as they see fit. It’s also possible to add new properties to entities in this area by selecting a property in the drop-down menu and then clicking the “add” button. Focus is not limited to a single entity, by holding the Ctrl key multiple entities can be selected at the same time. The properties displayed in the lower left will then be the ones that all entities have in common. In the top right corner of the screen is a small mini-map. While working in the editor, only the graphics are updated as we don’t want objects to start bouncing around or whatnot while trying to position them correctly. =P

When all is said and done and you would like to test your newly created level, click the “save level” button (or use the Ctrl+s command) to generate an XML file representing the level that you can then load up and play.