I received news this week that my pre-ordered Oculus Rift will be delayed to late May at the earliest and the Twitter/Reddit hoards assured me that I was not alone. This was actually a good thing for me, because I realized I was subconsciously using the looming shipment as an excuse to "just take it easy until the Rift comes, and then really crush it!" Nice logic, Adam.
Since I now have a ton of time, I've been struggling to build the Pause Menu for my game. The task has proven challenging, and I'm waging a serious war with distractions. The problem? Almost every video game menu designed for games up until this point will not work in VR, so I can't copy! The common strategy is to overlay the game with a 2D screen with buttons. The best menus maintain context by letting you still see the game in the background so that when you resume, you don't have to reorient yourself. I suspect that most early VR games will choose to just put a 2D UI on a flat surface in a 3D game, but that doesn't feel right to me and it can break down if it intersects with the world.
As far as I know, most VR demos out there haven't bothered to solve the problem of pause menus, but I see a few options:
- Pull the user out of the current game and into a separate 3D "menu scene"
- Keep the user in the current game, and freeze time for objects within the game while allowing interaction with menu items
- Teleport the user to a "safety platform" where they can see the rest of the scene from a spot where the menu won't be at risk of colliding with the rest of the world
The problem with the first option is that the user loses context. For a slow paced game, this seems to work. Fantastic Contraption and The Climb use this option, but I really want to preserve the context, so that when the user resumes the game, s/he knows exactly where the enemies are.
The problem with the second option is that things in the world can be in front of or intersect menu items. The context is preserved, you still know exactly what will happen when you resume, but the UI might be tough to use if the restart button is inside of an enemy or wall.
The problem with the third option is actually the same as the first. It yanks the user out of context. I honestly this would be my solution, but when I prototyped it, it felt rather disorienting.
Ultimately I've decided to go with option two and mitigate the world-menu collision by keeping the menu within the player's space and everything outside of that space, including enemies, which attack at a short distance. I might use some sort of "rubber-banding" where the menu UI elastically follows the direction you're looking without actually locking to it, but I haven't decided yet.
I'm curious to know if other developers have solved this problem in elegant ways, so if you know of something, please share! Thanks for reading.