Skip to main content

Dispatch from the VR Lab (February 2017)

By Eliot Szwajkowski

Hoverjunkers

If you consume any sort of media, you’ve surely been told that VR is the future at some point in the last year. Whether it’s watching the children outside the bodega share their Gear VR headset with an interested older man, or having a friend that’s far too enthusiastic about gaming tell you. The word is out. VR is here and — whether the technology is ready or not — it’s here to stay.

I have recently been working on Fullstack Academy's newly-minted Remote Immersive program, and helping to build our online campus. Each student is given a Google Pixel and Daydream VR headset for use during the senior phase of the program, and is encouraged to hack on the equipment and create VR projects.

Being a bleeding edge Javascript hipster, I of course wanted to find any possible way to incorporate VR into my stack. Unfortunately, VR doesn’t have the easiest ecosystem to work your way around in… yet.

Unity, the big player in game development, has some great support for the current mix of VR systems, but it has a fairly high learning curve. At Fullstack Academy, we teach a stack based on JavaScript, and we wanted to use this familiar ecosystem in our VR Lab. So we decided to start working with A-Frame, a web framework created by Mozilla for building virtual reality experiences.

After spending time with A-Frame, it looked really interesting. So I decided to re-work my VR boilerplate code around it and — just to get ridiculously ambitious — to "React-ify" it with a lot of the foundation necessary for multiplayer use already baked in. You can check out the code on GitHub.

The combination of readily available boiler plates and equipment has created an explosion in interest in the developer community for VR-related projects. For example, the starting point for my boilerplate looks like this:

VR Boilerplate


Interestingly, the remote students’ initial work in VR caused a surge of interest with the on-campus students as well — who were now hearing about VR projects being done by the remote students. For example, students in New York City were able to use the equipment in our VR Lab and develop apps for those platforms. The students and fellows are also able to push the limits of current VR equipment, for example by getting a LAN multiplayer game going on Hover Junkers, using Vive headsets:

Men using VR headsets

We’ve learned a lot from the first cohort of students who have been working actively on VR projects.

A-Frame is young. Like, really young.

A team of students currently building a VR chatroom for web browsers (which itself deserves a whole article) has hit so many edge case bugs in A-Frame it feels like a game of Jenga sometimes.

A-Frame developer ngokevin (whose code we run into so much we now just call him Kevin, and blame him for all things that go wrong) has personally responded to questions and feedback from Fullstack groups working with A-Frame. It’s great to see support from devs for such a young library. They also maintain a very active slack channel with public access for general troubleshooting.

Several teams used A-Frame for their Capstone projects. For example, Team Transcend built a VR classroom, where the lobby is a 3D replica (or maybe attempt) of our on-campus lecture hall:

3D replica of on-campus hall

There are issues with controller and browser support

Browser support has been an expected annoyance when developing WebVR projects — but it tends to be a surmountable issue.

Teams have also experienced a number of issues related to a wide array of incompatible controllers, with many headsets like the Vive and Oculus having different controllers.

Continuous learning

The great thing about Fullstack’s developing VR work is how useful all the current projects will be in helping future students get started developing VR apps, with a smaller learning curve.

Every new project solves a different but equally difficult problem, and builds on our foundational understanding. Every current VR project being built here is solving back end state synchronicity (due to all projects being multiplayer), and on top of that we are solving issues like flight locomotion, moving between different scenes, multiple device support, and dynamic loading instead of pure pre-load. These current pain points will provide enormous insight for future students developing in VR.

Our favorite use on campus for the VR lab (and arguably VR technology in general) is signing on for Remote Immersive’s weekly game night on our Minecraft campus and making the railways that will connect the past, current, and future students’ virtual houses together so that they always have a space to interact — and can get there quickly.

Our own version of an alumni get together you might say. We find Minecraft in VR to be one of the most full-featured games with VR support — but who knows, maybe the next one will come out of our VR lab?

3D replica of building

Find the program that fits your life.

Learn about our coding, cybersecurity, and data analytics bootcamps offered on full-time and part-time schedules.