Project: Multeor

After several weeks of developing, we’ve recently launched a multiplayer webgame called Multeor. In it you play a meteor that’s crashing into earth and you score points by leaving the biggest trail of destruction. In this article, I’ll gloss over some of the techniques used and how they fit together.

Smartphone as a controller


Inspired by Super Sync Sports we set out to build a webgame that can be controlled using smartphones. Our goal was to have multiple players compete against each other simultaneously and still have the game respond well to each of these players touch movements.

To accomplish this we’ve adopted WebSockets as the communication mechanism between browser, server and mobile devices. However, providing a high-response rate proved to be somewhat problematic. Most wifi networks we’ve tested on couldn’t handle the amount of data we were sending through, even when all components were on a local network. Consider someone in the United States playing our game, each data-packet coming out the controller needs to be sent to the Multeor server in Europe and back to be able to move their Multeor character on screen. Multiply that by the number of players and you’ve got a lot of data crossing the Atlantic.

We’ve spent a lot of time trying to lower the number of packets per second whilst still providing a one-to-one feel to the character on screen. So far, the best algorithm we’ve managed to write is based on polling the touch-moves a user makes on the controller, calculating a vector (angle, length, depth), sending that to the game which then interpolates between the current Multeor position and the new vector. This way, we’ve been able to tune the number of packets per second down as much as possible whilst still maintaining the feel that you are in control of your Multeor.


The backend

The backend is written in Node.js using as an abstraction layer for the WebSockets communications. The role of the backend is that of a mediator between the game itself and the connected smartphones. It’s job is to keep track of games, players and their state. It does this with asynchronous events that are sent back and forth between the connected devices. Node.js is extreemly fast, asynchronous by nature, written with javascript and thus in every way perfect for our purposes.

To be able to bypass firewalls that block outgoing traffic on anything but port 80 and 443, we’ve switched from using the default port 843 for WebSocket connections to port 443, which is preserved for SSL traffic. This minor adjustment works like a charm to be able to play Multeor on most protected networks, like corporate ones.

UK provider TalkTalk gave us some unexpected connection problems. Apparently they sent out a ping-back to every url you visit, maybe to verify if it’s a legitimate server? In any case, this weird behaviour made our game crash after about 10 seconds of play. After some research we found out that these ping-backs invalidated an open connection, crashing the game. A custom patch on was needed to ignore these (see this bug-report for more information).

The game

The game itself is written in vanilla javascript using HTML5 Canvas as the rendering surface for our graphics. From the start of the project, we decided not to use a prefab game engine and built the entire thing from scratch. Which means rendering the graphics, detecting collisions, keeping track of entities and coding a particle system for the explosions. Not depending on a specific game engine was great fun, it gave us a lot of creative freedom and we definitely learned a lot because of it.

Canvas performance gave us the biggest headaches. It’s quite hard to get it running smooth as soon as you are trying to create something serious. We’ve read a lot online and tried cleaning/re-writing our code where possible, based on intensive profiling. These blog posts really helped in optimizing our code: Improving HTML5 Canvas Performance and HTML5 Canvas Optimization: A Practical Example and probably some other interesting ones that I can’t seem to remember (damn you brain).

Level editor

Our custom level-editor

Multeor currently only has one level, called Forest, and even though we might never built a second level, it made sense to separate game-data from game-logic from the get-go. A custom level-editor was created to be able to construct a level file in a drag-and-drop fashion. The artwork, sprites and animations had to be placed meticulously and adjusted often to produce the game world we wanted. After adding audio and spending hours fine-tuning and testing, Multeor turned into a full-fledged game.

You’re welcome to tinker with our level-editor as much as you like. It’s quite a crude tool, but it proved to be very effective for our needs. Note: you won’t be able to save anything you make. But you can send us your JSON file (press export and copy/paste into a mail when you’re done) and we’ll definitely look at it.

About us

Multeor is developed by Arjen de Vries and Filidor Wiese and designed by Arthur van ‘t Hoog. High-five to Arjen Post who helped on creating the level-editor when we were under severe time pressure during the Indie Gameleon 2013 game-jam organized by Mendel Bouwman (thanks for taking such good care of us during these hours of panic-coding).

can u send the code of this please?

Thanks for your interest Sri, but we’ve not yet decided to opensource Multeor.

Wow this game is incredible. Keep up the good work!

– your friends in Canada

Can you write the codes please

Add a remark