Over on the Springshare Lounge, I was asked for some detail about how our new augmented reality game works, so I posted the text below. I thought it might also be useful to share this here…

This [AR game] was built on a new Group Homepage, starting with a completely empty Homepage Template. Starting with an empty group homepage gives you a blank slate for custom HTML and JS/CSS. With this starting point, you have a lot of flexibility to build what you want.

Nonetheless, there are limitations [with LibGuides]: the “Upload Customization Files” section of the Look & Feel section only allows certain file types, and files under a certain size. I bumped up against these limitations more than once, and it did limit what we could do to a certain extent.

The AR functionality comes from a JavaScript library called AR.js. This library is a bit rough around the edges, and not entirely robust, but we never hit any insurmountable roadblocks when trying to deploy it, so we just kept going. AR.js is meant to be used with a framework called AFRAME, which was not my first choice, but which turned out to be pretty usable. The AFRAME code is what handles the game logic.

The virtual shapes in the library space are triggered by markers, which are posters with patterns on them that we put up around the library, rather than geotagging. The good news is that this meant that once the game was loaded, it could be played without a wifi or cell signal. The bad news was that people kept taking down our posters without asking :(

In the end there were two hard parts: First, getting the HTML menu, welcome screen and congratulations screen to align properly in the viewport of the phone was not easy. It was especially problematic since the image produced by the camera was not usually the size of the screen. If I’m diagnosing this correctly, AR.js was manipulating the image behind the scenes, which made it hard to write the correct CSS. In the end it was a classic finicky CSS problem, and it just took a lot of banging my head against the problem to get it to work.

The other big problem is that modern phones have more than one camera. They even usually have more than one outward facing camera. The problem is that the AR.js library does not always pick the correct camera, making it unusable in a small percentage of cases. Reading the relevant GitHub issues on this showed me that this is something the makers of the AR.js library haven’t even solved, so my odds of solving it are extremely low. Despite this flaw, the game works on over 90% of the phones we have tried, so we decided to proceed with using it as a new student orientation activity nonetheless. When a student’s phone didn’t work, we had them partner with another student who had a working phone.

Anyhow, I hope this brief write-up helps. Let me know if you have any more specific questions!

This entry is licensed under a Creative Commons Attribution 4.0 International license.