AR is an impressive technology but until the launch of ARKit 2.0 last year, single-user experiences were the norm. Unfortunately, these early apps neither retained customers, nor monetized. (We know this from first-hand experience!) Since then, multiplayer apps, where people can share a virtual experience in real time, have gained steam. Players can affect the same environment and see different things depending on where they are positioned. Just as in gaming generally, social playing is simply much more fun.

Recently HiPoint Studios partnered with Caesars Entertainment in its first foray into multiplayer AR gaming. We created a series of mini-games for a new bar experience in The LINQ Hotel in Las Vegas. Using the bar coasters as targets, five different AR flick-style sports games (baseball, football, basketball, hockey, and beer pong) can be played, with high scores posted on an online leaderboard.

One of the games, beer pong, is a multiplayer game. And here, let me go straight to the punch line. Both the design and engineering of multiplayer AR games are super challenging but using target-based AR considerably reduces the risks.

Beer pong has a well-understood gameplay mechanic, so designing a two-player version around a bar coaster was not difficult.  However, designing multiplayer AR that is NOT target based can be hard because the players have complete control of their camera and, depending on the gameplay style, may need to know what the other player is seeing and how it is different from their perspective. Imagine a multiplayer AR combat game where your opponent is hidden on the roof, not visible from your orientation? How does a designer encourage player movement, perspective shifting and mental rotation, when necessary? The UX challenges can be monumental.

Regarding technical hurdles for multiplayer AR, relocalization is one of the toughest nuts to crack. Until world maps could be saved across multiple sessions, and transferable between devices, users could not revisit a location and find that the app remembered it. It also meant that AR experiences were generally always solo ones. Then Apple introduced relocalization in iOS 11.3, which let users restore a state after an interruption, allowing them to relocalize a world map to a later session, or share to another user or device. There are some highly complicated visual computing systems to support this process, e.g., SLAM map coordinates, but relying on a common physical tracking marker image or QR code, as we did in the Caesars game, neatly solves the problem.

For the marker to work, both players point their phones at the coaster on the table in front of them; the app treats the marker as the origin coordinates, making the real world and the virtual world consistent across both phones. This works quite well and removes some low-level problems of figuring out where the players are relative to each other. Instead, the device makes assumptions based on where they are relative to the coaster.

Meanwhile, target-based multiplayer AR has an obvious disadvantage. While it works quite well in a specific location like a restaurant or office, only certain kinds of games or experiences lend themselves to playing around a coaster or beacon. It’s definitely a good short-term fix for multiplayer AR, and a great way for our company to “get its feet wet,” but obviously only the beginning.

What’s next for the team at HitPoint, now that the Caesar’s LINQ game has launched? Given our extensive experience with the now defunct Tango phone, our engineers are particularly excited about the Cloud Marker tech from Google that uses recognized landscapes for relocalization (similar to the ADF scans that we used with Tango for some cool AR retail demos.) Can’t wait to see what the HitPoint team comes up with next!