I am still in pre-dev phase - creating Assets, editing storyline, doing OOP analysis. I plan to make game in UE 4 and would like for game to have VR support. Would it be good idea to start right away with Oculus Rift(like "mobile first" approach) or add it when I have working game prototype? Thanks
\$\begingroup\$
\$\endgroup\$
Add a comment
|
4 Answers
\$\begingroup\$
\$\endgroup\$
3
There is no correct or incorrect answer to this question. There are so many factors to consider, that the only one who can actually answer that question is yourself.
Keep the following in mind:
The more integrated the headset is into gameplay, the sooner you probably need to add support: Not every game can benefit from a headset, and some are even unplayable with headsets. If the headset is a necessary item to fully experience your game idea, you probably want to add support at the prototype stage.
The more complex the assets in your game are, the earlier you want to add support. Rendering stuff for a headset requires you to draw everything twice (or even three times, if you also want a centered POV to display on the non-headset monitor). It would be a huge waste of time if you develop your assets extremely detailed and with very heavy shaders, only to see that when you render them twice, you're getting very poor performance, and then you have to remake everything with less detail.
Remember that the headset is not only a display, but a controller that lets you choose the orientation and position of the camera. You should keep this in mind since the very conception of the game, and make sure your game makes sense with such a controller.
Headset programming has very high demands on framerate and response time. You may not want to consider this until optimization, but if you're creating the low level aspects of your renderer so you're rendering things a few frames behind they're actually displayed, adding headset support as an afterthought will pose many challenges.
(Added from Phillip's comment) Many headset users seem to report that the game taking control of the camera is very uncomfortable. If you're making a game for which you're planning to support headsets, you may want to consider designing it so the game can be played without having the game take control of the camera.
(Added from Lars Viklund's comment) Many graphical techniques that look good on a flat display won't look quite as good on a headset. Things like effects, where you can sometimes get away with a billboard in a flat monitor won't necessarily look as good on a headset. Other elements, such as the game GUI may need a complete rethinking when using headsets.
A headset will let you move your head around in all directions. This may have an impact on your audio model. Maybe you could get away with a simple stereo audio system when working on a flat screen, but you probably need full 3D audio support if you want your game to be as immersive as possible.
All around, headset support, even though programming-wise may be as easy as ticking a checkbox in whatever game engine you use, has very deep implications on gameplay, art and the entire engineering of your game. The earliest you think about all this, and optimally test your ideas with an actual headset, the quicker you will find flaws and be able to solve whatever problems you may find.
I believe headset support is something you build your game around, falling back to monitor when no headset is available; not something you add at the very end as an afterthought. Because of this, and -especially- if this is your first headset game, I would recommend you add headset support as early as it is practically possible.
answered Jun 4, 2015 at 8:06
-
3\$\begingroup\$ An important thing to consider when designing a game for a 3d headset is to never ever take control of the camera. Most Oculus Rift users report that this is extremely uncomfortable and nausea-inducing. This restriction can affect the game design from early on. \$\endgroup\$– PhilippCommented Jun 4, 2015 at 8:25
-
3\$\begingroup\$ It may help to mention that many techniques that work well on mono displays fail miserably in stereo. Among those are UI (need in-world planes with opaque backgrounds), billboards (particle effects may require proper volumetrics). \$\endgroup\$ Commented Jun 4, 2015 at 8:39
-
\$\begingroup\$ Another thing to keep in mind is the fact that the user cannot see the physical world. So entering text will be difficult as the user see the keyboard or pickup the controller when resuming play without having to remove the headset. Simulation games work well for VR except if the player needs to press 'g' to raise the landing gear and return to a flightstick for controlling the craft. So the control scheme for VR should be clear as soon as possible and goes beyond just the ingame controls. \$\endgroup\$– FelsirCommented Aug 26, 2015 at 11:19
\$\begingroup\$
\$\endgroup\$
Start with it straight away (like mobile first). It is a fundamentally different platform, with its own very unique design constraints. If you start with a non-VR game and try and tack on VR support later, you will end up with a very poor experience that probably makes your users feel ill.
If you start with VR, then it will be possible to make a pared down non-VR experience later, far more easily than the other way around, but depending on how much you take advantage of what VR gives you, you need to face the possibility that you might not be able to support both in the same game.
\$\begingroup\$
\$\endgroup\$
I've never used OR before but it might be like mobile where you make 90% for PC then configure the rest for the specific target. This allows for fast and easy testing so you can focus on the rudimentary pieces of your game. Just keep your target platform in mind for gameplay and performance reasons.
\$\begingroup\$
\$\endgroup\$
Unless your game is exclusive for VR then you should design the game based of it. If not, then you should make sure you're game is fully operational, on the initial platform, then decide if you're going to do a port for VR
