VR is a whole new ball game when it comes to Ux, software development and testing. This article goes over our experience in testing the VR game we are developing for one of our customers.Read More
As with the rest of the software world we were excited about the possibilities of VR and getting our hands dirty with some VR code. So it was with a big smile on our face that we took in our first official VR project. And not just any boring "also ran" VR app but a full blown first person shooting game!
Nothing compares to writing a game. Add to that the total immersive environment of a HTC VIVE (our first target platform) you have something that literally stops us from living in the reality of this world :)
I'll be writing here about our experiences in this first serious dabble in the world of VR. Here are somethings that we wish we knew from the beginning...
Virtual reality is a whole new ball game
Duh! That should be obvious. But if you think about a software company that has been around for 14 years, you'll realize that we are a group of people that has seen really wide range of technical innovations. So we just assumed (the wort possible word in our profession - as we learned once again) that most of our experience would translate to this new platform. We soon realized that although coding skills (e.g. Unity or C# skills) translate pretty well but as soon as you hit anything Ux be it GUI, interactions or usability you have to learn everything from scratch. The total immersion of VR and the closeness of that experience of that with everyday human experience leads to a complete rethinking of how the software should interact with the user. Mr. Cooper, a new About face is sorely needed.
Interfaces are your friend
I mean the Interface constructs the programming languages. VR hardware is still at infancy. Just like every other hardware race, several companies are fighting it out with their own set of hardware, SDKs and way of doing things (mostly bugs :) ). So the code you write needs to have a way to be abstracted easily so that you add new hardware support without rewriting the core game logic. And that's where all those OOP skills will come in handy. A simple rule we use is to keep asking "what if I switched to Rift here?" and that helps give perspective. So go for all the IPlayer, IScorePack, Ix you can think of!
Get early feedback
OK this is really ancient advice in software, but we felt that in VR software this is even more true than other spaces. Again, because of the closeness to everyday human experience and the immersion in a VR application (particularly a game with realistic graphics) it's very easy for users to assume they know exactly how (and where) things should be. Gone are the old escape routes that techies used to take like "Windows has their Cancel buttons there" or "right click is always context menu". As soon as we got our first broken version out we found that even team members were complaining about how a certain thing was being picked up or how a door was being opened. And it's obvious, these are things we have learned over years of real experience, there is a universally accepted convention out there for basic things like "picking up an object" and you cannot mess with it! So schedule demos at every point of the project, run usability sessions, even better run Joel's hallway tests at every opportunity you get.
OK on that note let me leave with some of our "hallway tests" put together in a little video by our design guru.
I'll be sharing more of our VR development experience here, so watch this space!