Today we’re releasing the first in a series of video playlists that presents research undertaken by the team at Crytek relating to movement in VR. We’ve shipped two award-winning VR titles – The Climb and Robinson: The Journey – on Oculus Rift, and many of the methodologies we explored made their way into the games. Some locomotion methods and actions will make it into future projects, and by sharing our research, maybe your own.However, throughout the research we will also be presenting methods that didn’t work. Over the coming weeks we’ll be sharing over 40 videos, each of which looks at different movements and actions in a VR space and we’ll talk about what works, what doesn’t, and how certain experiments could be applied.
Interview with Julius Carter, Game Designer at Crytek - Research & Development Team, CRYENGINE:
Researching ways to move around in VR isn’t new. When you’re in this creative sphere, you have plenty of people who are very smart and intelligent looking at movement and how to eliminate sickness, not just in game development. This has laid some useful ground rules for developers. We know that acceleration in a VR environment can make us uncomfortable. We know that when objects are in very close proximity when you are moving can induce discomfort, and so on.
We’ve seen plenty of examples of how developers have gone about testing movement. Often, however, they take place in a playground - white-box environments. This makes sense for quick and rapid testing, which is crucial, especially on commercial projects. However, it’s not necessarily true that you are going to have the same reactions in a playground as you would do in something more resembles a polished video game level. And of course, when you see advice on best practice, whether shown alongside testing environments or not, you don’t necessarily know how they tried certain movements, what techniques they used, in what context, what sort of environments, and so on. We wanted to develop a suite of comprehensive methodologies in an environment that would resemble the kind of spaces we want to set games in.
The Test Environment
The process started with our test environment. First, we decided to make it more like a video game level, populated in a way that was far beyond a playground. Our aim was to discover ways of moving through a video game level, so it made more sense for us to have a level that was more authentic, presenting a similar environment to the sort of areas that level designers will create, and offer something that is a bit more consistent to the brain. It’s not realistic, but we wanted to create an environment where the user would get a sense of being present.
Then we filled it with features that we know can induce discomfort in VR. We had to make it large, so we could test acceleration to high speeds at large distances. We created very close tight spaces so we could test methods with elements in very close proximity. There’s a carousel, an elevator that moves and accelerates up and down at random, a room that replicates the motion of being on a boat at sea, platforms to jump off, and many other features designed specifically to provoke uncomfortable feelings. Our environment was designed with input from members of our game design team, and if you are looking to create your own test environment, we suggest adopting the same approach to create a level that can meet your requirements.
There were some challenges to overcome during the course of testing. Many people quickly get used to being in VR, so feelings of sickness can naturally diminish. That meant that we had to try out our prototypes on many different people, testing out “new brains” to ensure our finding were legitimate. Then, of course, we also had to try different people’s reactions to each prototype. What works for one may not work for another. And we had schedule down time for people who experienced discomfort, which, with over 40 different ways to test locomotion in a devilish environment, was inevitable.
Over the series of videos we’ll look at expected movements, control schemes that we haven’t seen anywhere else, and all kinds of different actions. We’ll look at what works, what applications they might have, and what doesn’t. We hope this research will help any developer looking for solutions, or indeed, just looking to rule out options for their game. We think there are elements that can inform and inspire your own prototypes – it’s certainly achieved this for us – and we’d love to see people try new solutions we haven’t yet thought of. It’s also an ambition to release the test environment itself, so people can play around in it themselves. Watch this space.
Feel free to address your questions, comments and concerns so Julius and the team can come back to you in this topic!
- CRYENGINE Official
- - Forum Rules
- - Official Announcements
- CRYENGINE Development
- - Educational & Beginner's Corner
- - - Getting Started with CRYENGINE
- - - Build Feedback
- - - Tutorials & Learning
- - - Plugins, Source Code & GitHub
- - CRYENGINE General
- - - General Discussion
- - - Showcase Gallery
- - - Virtual Reality / Augmented Reality
- - C#/C++ Programming
- - - Entities
- - - Networking
- - - Shaders & Rendering in General
- - - Programming General
- - Asset Preparation
- - - Plugins & Tools
- - - Models & Art
- - - UI
- - - Audio Middleware
- - Game Design - Sandbox Editor
- - - Audio
- - - Animation
- - - Materials
- - - Physics
- - - Debugging
- - - Visual Scripting
- - - UI (HUD/Menu)
- Online Services
- - Website
- - Launcher
- - Marketplace
- Community Corner
- - Events & MeetUps
- - Recruitment & Collaboration
- - - Job Offers [PAID work only]
- - - Talent Showcase - looking for work
- - - Collaborations [Free Work & Hobby Teams]
- - Off-Topic Discussions
Who is online
Users browsing this forum: No registered users and 1 guest