The things you're going to ask with UE4 VR
Most of these things you're going to ask are already answered, but you have to find them and collect them together.
I've done this curation to you. If you've got an another tutorial that you think solves something VR related is sufficiently interesting, not already covered by existing articles listed, send me a mail and I'll consider adding it!
Architecture of UE4
So lets say you've never properly used UE4 before, the first thing you'd like to know how it ticks. Best description I found was fairly deep in the official programmer's manual.
Programming Guide > Gameplay Programming
Unreal used to be a first-person shooter game engine. It has some interesting traits left from this time. For example. If there are no cameras in the world, it'll drop the player into a spectator mode.
The game engine behaves like a small operating system. It's doing its things in certain way and you don't easily budge away from that. This may feel a bit crummy until you notice the structure is mostly exactly what you need in most cases.
Your game has a mode and a state. Player controller joins the game. When a player joins, he possesses a pawn in the scene. Player's controller consists of his playerstate, inputs and other elements that describe a player in the game.
UE4 has a class hierarchy which ascends in this manner:
- objects - records not inside the scene.
- actors - objects that can appear in the scene.
- pawns - player-possessible actors.
- characters - humanoid-style pawns with a movement component.
In addition to this you have levels. Multiple levels may be loaded at the same time and they may be loading while the game is playing.
Blueprints
Blueprints are plans for building items into the game. They contain a graphical programming language that's shares the name "blueprint". Overall you only have to write C++ if you're doing something cool, which is cool.
The official blueprint introduction video helps you accustomize to where everything is. The visual programming language in blueprints produce state machines that are actuated by signaling them.
Blueprint quickshot videos show different ways to use blueprints in practice for variety of shenanigans. These detail out where you can find out where to change some crucial settings such as gamemode and default spawn. In minimum read about events and blueprint interfaces.
I also found it useful to read about flow control in blueprints. So I know that condition corresponds to 'branch' and how to add loops into my blueprints.
Actually getting started with VR
Tom Looman's article about getting started with VR in Unreal Engine 4 was the most helpful for starters. Overall it was easy to find once you realise you need this after you don't figure out how the VR game in the templates work.
From Looman's site you find out about the motion controller components that you can lob into a pawn blueprint with a camera, then you're ready to place your first VR-watcher seat into the scene.
Virtual reality live training series covers creation of interactions in VR. They are all hour long tutorials so I wouldn't suggest watching them all through at once.
Decoupled control
The player itself becomes an actor in a VR game but often you want him to control something else in VR.
Features to do this has been in Unreal Engine since its foundations. Already in Deus Ex players had rockets they could remote control directly. The feature is called possession and it's documented in the possessing pawns -section.
Aside possession, there's also a feature called "enable input", This is used for implementing light switches and such. Though there's a catch: The "enable input" is not working with pawns or characters. It goes beyond my understanding why it doesn't but it doesn't. Also you can posses only one pawn at a time. If you hit that problem, the solution is to connect the "extra pawns" through variables. Another catch: The blueprint that uses the input first is consuming it unless you uncheck a box.
UE4 tutorial: Control two characters with one player presents how you can detach a camera from the player and how to control multiple pawns using variables.
Pawn or Actor?
This is something that I think gets really confusing as I progress. UE manual describes Pawns as objects that are AI or player controllable. I keep staying mystified by what does this actually mean?
The problem seems to be a misconception that the AI and player are symmetric entities. In practice you see AI-controlled everything that isn't obviously convertible into player-controllable elements. Also the player and AI control wildly varies, as some objects are both player and AI controllable at the same time.
IMHO the whole distinction seems like tacky legacy left to demonstrate how object-oriented programming fails in practice.
Avoiding common pitfalls
Write your goals and plans to paper before you start working on them. The interface in UE4 easily distracts you away to trying different things and you may forget what you were planning when hitting the first obstacles. It's also good to have a place to write down the ideas you get while working, so you can resume on exploring those ideas later.
I haven't seen anything else as underwhelming, expensive yet poor as AAA games with edutainment-grade game mechanics about pressing buttons in the right point at the cinematics.
It's great to have tools that make it easy to produce procedural content or interactions in large scale, but you should keep doing things that are challenging to come up with. Simply the time and effort spent to the art demands that the game design stays good and sharp as well.
Use of procedural content and getting easy if you can is great. It's stupid to drop back to doing the same things hard way. You shouldn't constraint yourself to only doing the things that are easy to do with the current tools.
On the opposite spectrum is a problem of spending effort unevenly to the wrong things. This is ultimately similar to other arts such as drawing. You see people spend inproportionate time to shading intimately detailed eyes when they haven't gotten proportions right or detailed anything else yet. It is possible to do this with game design as well. The solution is to work on big things first and gradually and evenly descend to details while being attentive of how the whole thing looks.
If you are an artist I would expect you to understand body proportions, geometry, perspective and human anatomy. What I'm going to tell next is going to feel like it contradicts this. It doesn't because you should study things relevant to your work regardless of what kind of feedback you get.
Skilled ridicule is surprisingly difficult to find. However there's plenty of unskilled ridicule for everybody who dares to create anything. Disregard ridicule. Don't fight it. Don't especially satisfy it.
I mock people quite lot myself over their work. I do it to feel better myself. I also do it because I really hate or like the work or person who did it. But ultimately I think there's more in it for me than there's for the artists who did the work.
Often the artists don't look at the feedback but the emotion in the ridicule. Though the useful part, the feedback of the ridicule is so miniscule that overall I think it's better for artists to disregard mockery entirely.
There are at least two ways to get good results. One thing is to pick up references and get everything detailed and proportioned as well as you can. Another is to communicate through the drawing what you remember about the things you draw. Use it to describe everything you remember. Later you check up what you got right and laugh at your work afterwards.
You can always do better than you did.