In the realm of virtual reality development, even the best games and applications can suffer from a lack of proper testing. When it comes to playtesting, applications should receive a thorough and rigorous process of testing and retesting to make sure that nothing egregious gets through. Ideally, all software would be bug-free because of the raw amount of trialing before it reached a consumer audience, but anyone in any kind of tech field knows how difficult that claim is to back up.
Things happen, delays happen, but there are practical things you can do to make sure testing catches the major things getting in the way of a stable product. All of this relies on lines of communication between developers and testers, so before doing anything make sure that is in place.
For most developers, crunch time is an inevitability. But, if testers are performing under the same tight deadlines it can get hard to discern which problems are legitimate and which are user error. In addition to this, the human brain thrives when given breaks in between sessions. A mental reset is best before jumping into anything big, even outside of the office. One of the best things to practice doing solve a problem is, without a doubt, to sleep on it. A delay of 8 hours can stop one that may last days.
This has practical ramifications for virtual reality software development especially, because even the best and most skilled engineers can’t sit for 8 hours in a VR device. You need to give reset time, although this may not necessarily be without productivity. Menial tasks that need to be done are perfect for this time, although it may not be popular.
This may go without saying, but different people use tools in unique and sometimes terribly inefficient ways. This is an advantage for you, since if your software ends up with thousands to millions of people using it, there’s bound to be an issue found that a group in the double digits can’t find. Playtesting should be about getting as many valid experiences as possible into as short a time as possible.
A lot of the time, testing periods for any software aren’t just for bug squashing, but also for running through the fundamental design of the program. If something just isn’t working right, as intended, or as is often the case, at all, it is a pain to fix but possible before launch. The architecture for VR games allows for many more possibilities for player experiences, and though this is a good thing it’s best to start early for such a young technology. Strategies like the ones on this page: https://www.augray.com/blog/test-strategies-for-ar-and-vr-products/ should follow a step-by-step approach starting from the bottom (does the thing work at all?).
Hardware limitations are a pain, especially for VR. Even with a great VR headset, a computer may struggle with a specific app because of a separate issue. This is frustrating, but can be squashed early by testing with all different types of hardware. Prices for different things like this can add up fast, especially for graphics cards, but it’s ultimately an issue of paying to plug up potential holes in your product. Thinking about it like this, it’s a no-brainer. Don’t let yourself be cheap, if a painfully common system can’t run your program it’s going to crash before ever getting off the ground.
Checking minimum requirements for VR headsets is important, although you should be aware that users will run this type of hardware on machines that are like calculators compared to modern systems. Click here for a list of the minimum requirements for VR machines. Never underestimate the ability of people to get stuff to work on terrible machines, and equally prepare for those people to be mad if their abacus can’t run your program. Sometimes this is inevitable, but depending on the complexity of the program, it is sometimes avoidable.
While tester safety is important, it’s also just generally good to have a general idea of how much space is required for your program. This is especially important for videogames that need movement. The body is wired to move muscles, not click buttons, so if there is a safety issue it can be as easy as placing a warning to stop a potential injury on the part of the player.
Your goal as the creator should be to let the person run the program however they want. If your program is hard to use, or buggy, it’s on you but you may have never noticed since your perspective is that of the creator. It’s said commonly that artists, chefs, and engineers point out the flaws in their work way too much. But I think this misses the point, because while they do look at problems, they are looking at the wrong problems. Not everyone is as knowledgable as a developer, so trust their perspective even more than your own.
Running through your work is a fun time if everything goes well. It’s normally pretty obvious if it is going well. If something runs into a wall, take a deep breath and carry on. If there’s one thing that’s the worst thing for anyone trying to make something work, it’s definitely tempers flaring because of a frustrating issue. Take a step back, take a break, decompress, and take a stab at it again when the inspiration comes back
All Rights Reserved © 2024
