• View
• Edit
• History
• Print

How does it work :

• one web server serving several webVR clients
• one nodeJS server answering and managing all connected clients

Technical choice

webVR has been chosen over proven frameworks like Unity or Unreal because

• it is open for all to use and improve
• it was well known by at least one of the programmers
• none of the proven frameworks were known by any of the programmers nor team members
• it is multi-platform, known to work on at least Cardboard for Android, Cardboard for iPhone, Oculus DK2 with Windows desktop

Client

On smartphones the client only needs a webGL compatible browser, (Chrome mobile, Safari mobile, Firefox, Opera, ... ). On the computer you need a webVR compatible browser (Chromium experimental, Firefox nightly build with webVR add-on) to use a VR headset tracking your head movements. i.e. Oculus Rift The browser then

1. loads a piece of HTML that loads
   1. several Javascript files including
      1. ThreeJS to handle 3D graphics with primitives
      2. webVR boilerplate to handle VR headsets
      3. the mechanics of the game
      4. the networking part of the game based on web sockets
   2. 3D assets (bobsleigh, players, environment)
   3. 2D assets (textures)
   4. sound assets

Note that because the page becomes quite heavy some little tricks regarding networking have been done in order to let the page load then safely connect to the server.

All this is being done in the browser and can be inspected and thus debugged (relatively) easily with the in browser debugger.

The frame rate has not been measured during the event because it "felt OK" on most devices. It was clearly not 60fps but the goal was to make a proof of concept during less than a weekend, not a polished product.

Server

The server is a NodeJS web socket server that handles all the connections. NodeJS was picked for its ability to handle large amount of concurrent connections thanks to its asynchronous event loop. This allowed for all clients to simply burst all coordinates non stop rather than throttling or capping. The server waits for incoming connections that are properly formatted (JSON messages) and discard all others.

The timeline is as follows:

1. the clients loads the page, requests the server to add him
   1. the server receive the request from the client, counts how many clients are already connected then assign the roles accordingly
      1. 1st client connected becomes the head of the bobsleigh
      2. 2nd client connected becomes the back player of the bobsleigh
         1. the server detects that at least 2 players are connected and sends a ready signal to all clients
      3. all other clients connected become passive backs of the bobsleigh
2. clients await being assigned a role
   1. once received clients await the "ready to go" signal
      1. once received the ride starts,
      2. the browser updates the 3D objects position locally based on the speed parameter
      3. the server changes the speed parameter of each player according to the amount the 2 player are synchronized
   2. clients sent their HMD orientation to the server
      1. the server constantly broadcasts back to all client the orientation of all clients

The latency hasn't been measured during the event because it "felt right" (at least under a second on average) despite being used on a publicly facing web server. A local server inside the hackathon premisses could have been used but in order to let testers use their own devices rather than ours we used a normal server located in the north of Paris. For debugging purpose also servers running locally on the computer where used. This to be able to work with multiple persons on the same network code but not on the same server.

Note that after the hackathon some development tricks have been added

• rides can be restarted infinitely in order to allows for very easy continuous user testing
• forever.js is used to run the client managing server. This to automatically restart the server despite potential crashes
• nodemon to track server changes and reload clients accordingly
• nodemon to track client changes and reload clients accordingly then forces them to reconnect???? M: I don't know?????
• server control in order to force the client to start the race for debugging purposes
• The server address is related to the development branch to avoid version conflicts

Pitfalls

• gradual integration of assets is much safer than leaving it to the last minute, it ended up working but until less than an hour before the deadline we had a black background and coloured boxes with beautiful assets stored on the side.
• not having a cleanly separated testing and development server with different protocol number lead to massive headache
• not having a clearly established step by step process during the demo lead to a lot of frustration
• multi-platform remains a goal more than an actual simple reality. A lot of hardware has to be fine tuned and tested again and again to insure it does work properly on all platforms especially in a cutting edge environment
• team members have to honest about their abilities and have to communicate frequently about what has been done and was is lagging behind so that new priorities can be established
• proper versionning, being of the networking protocol, or the source the code, or even of the tests matter even more in a fast paced development environment than in a long term but slower development environment. There is no time to waste wondering if this version caused that other incompatible version to crash
• A game consist of a lot more than just the code. The 3d design of the game assets, creation and composition of the game environment, adding sound effects, setting the mood with background music, developing a smooth and fun way to control the game, thinking of good game mechanics. They are all mandatory to end up with a good game. To develop all this with a group at the same time and to communicate all the ideas. Is a very complicated job.

Especially with VR it is not really known what will work and what not. So trying to get everybody in the loop as fast as possible might be a good approach. This so that everybody can start to understand the place of their idea in the game and can start improving on their design. This was very hard with the webVR technology, since a lot of code has to written to get the basic game working. (Actually it took the whole weekend which what was somewhat to be expected.) In the future, when the technology is more evolved and programmers can be more experienced with it. More time can be spent on the other game aspects.

Author Fabien Benetou @utopiah & Michiel Van Dyck