Buggy Blasters – Multiplayer HoloLens Considerations

This guest post was written by Bernard Francois, Kasper Geeroms, Matthew Cormack, and Jannes Plyson, respectively founder, project manager, and programmers of PreviewLabs, a company specialized in rapid prototyping with game technology. PreviewLabs was founded in 2010 and has been using Photon since 2013.

Buggy Blasters is the first multiplayer HoloLens game concept to appear on the Microsoft Store.  It’s single player mode allows driving a virtual RC buggy around in your living room, and the multiplayer mode turns it into a two-player real-time strategy concept with a hybrid of capture-the-flag and defend-the-base mechanics. The multiplayer mode works for two players in different locations, or as a shared holographic experience within the same location.

PreviewLabs developed the concept on request by it’s parent company Cronos Groep, who gave them carte blanche to come up with an interesting case for the HoloLens – and this is what we learned…

Getting to a Shared Play Space: Possible Approaches

Through the use of a feature called spatial mapping, the HoloLens generates a 3D mesh of your environment, which can be used for instance for z- buffering (allowing virtual objects to appear behind real world objects) and collision handling. This can greatly enhance the feeling of presence in augmented reality – the feeling of seamless integration of virtual content with the real environment.

Objects such as the buggy and traffic cones are able to interact naturally with the environment by using the environment mesh as a collider.

However, in a real-time competitive multiplayer game, you want to make sure to have a level playing field. Let’s take a look why it could lead to unfair situations if you would simply allow each HoloLens to use it’s own mesh in a game like Buggy Blasters:

1. When the exact shape of the mesh has an impact on the gameplay (e.g. slight bumps in the floor surface mesh leading to variations in driving speed), players can feel disadvantaged.
2. When real-world objects occlude the game, it could mean a serious disadvantage in the multiplayer game. You may simply miss that your opponent just stole your flag!

Note that this can be important even when you’re playing with two HoloLenses in the same physical location, since due to variations in the scanning process, no two meshes of the same room will be exactly the same.

Now here are two approaches that can be used:

• Comparing the meshes generated by the two HoloLenses, and taking the differences into account in order to get to a single, shared mesh.When the two players are in the same room, the average between the two meshes could be taken, while also speeding up the scanning process by adding the results of the two HoloLenses together – allowing your HoloLens to gain understanding of a part of the space it didn’t even see yet.When the two players are not in the same room, the furniture from one player’s room could be copied to the other’s, and vice versa. For instance if you have a coffee table in the middle of your room, while I have a recliner, you’d get my recliner virtually added to your room, while I’d get your coffee table, so we both end up with the same environment. The furniture from the other player that gets ‘imported’ into your room could be visualized with a simple abstract shading effect.
• Throwing everything away, and using a simple plane at the floor height, obtaining a perfectly level playing field. And heck, since we’re a prototyping company, we just went with this – after all, we like to get to something playable quickly.

To play Buggy Blasters, two players with the HoloLens can define a rectangular play space, in order to get to a common ‘play space’ based on the overlapping part of the two rectangles.

Since the game needs to take place in a shared space that is fair for both players, this play space needs to have the same size for both. It would definitely not be fair if your opponent with a larger living room would be able to hide behind – how you would perceive it – your wall. We used a very simple approach for this:

• Each player defines a rectangle of free floor space. In the case of Buggy Blasters, this is done by tapping the floor to place traffic cones. The first corner of the resulting rectangle is seen as the origin of the play space.
• We then combine both play spaces and choose the overlapping rectangle of the two spaces as the multiplayer play space.
• Network communication about positions and rotations is all done relative to the origin of the combined play space.

Once this is implemented, playing in the same room with two HoloLenses becomes easy: all you have to do is to set up exactly the same play space on each HoloLens by having both players put their cones at exactly the same position. This definitely does the trick for a prototype!

Developing Efficiently for HoloLens with Unity

To get a Unity project running on a HoloLens, a Visual Studio solution is built. From there, you can build and deploy to the HoloLens. For the Buggy Blasters project, the whole process takes around 5 minutes. Testing the multiplayer gameplay meant that each time we had to deploy to two HoloLenses.

This is how we worked more efficiently, avoiding a long build-and-run loop:

• Simulate moving around and Air tapping in the Unity Editor using an Xbox controller, speeding up the development.
• Since you can’t wear two HoloLenses at the same time, it would be hard to have a single programmer test multiplayer features. Therefore, we allowed testing with a single HoloLens, while the other player client was tested in the Unity editor. This was made possible by setting up a Unity scene containing a saved scan of a room (since scanning a room is not possible without the actual HoloLens device) as well as a pre-set up play space.

For more info and download, see the Buggy Blasters page.