Book Image

Unreal Engine 4 Virtual Reality Projects

By : Kevin Mack, Robert Ruud
Book Image

Unreal Engine 4 Virtual Reality Projects

By: Kevin Mack, Robert Ruud

Overview of this book

Unreal Engine 4 (UE4) is a powerful tool for developing VR games and applications. With its visual scripting language, Blueprint, and built-in support for all major VR headsets, it's a perfect tool for designers, artists, and engineers to realize their visions in VR. This book will guide you step-by-step through a series of projects that teach essential concepts and techniques for VR development in UE4. You will begin by learning how to think about (and design for) VR and then proceed to set up a development environment. A series of practical projects follows, taking you through essential VR concepts. Through these exercises, you'll learn how to set up UE4 projects that run effectively in VR, how to build player locomotion schemes, and how to use hand controllers to interact with the world. You'll then move on to create user interfaces in 3D space, use the editor's VR mode to build environments directly in VR, and profile/optimize worlds you've built. Finally, you'll explore more advanced topics, such as displaying stereo media in VR, networking in Unreal, and using plugins to extend the engine. Throughout, this book focuses on creating a deeper understanding of why the relevant tools and techniques work as they do, so you can use the techniques and concepts learned here as a springboard for further learning and exploration in VR.
Table of Contents (20 chapters)
Title Page
About Packt
Contributors
Preface
12
Where to Go from Here
Index

Plan how you're going to maintain and debug your code when you write it


Technical debt is an insidious thing. This term describes the downstream cost of fixing a mess that was left in the code, usually as a result of rushed development. And it's a project-killer.

Let's say, for instance, that you needed to get something ready for a demo, and you ran out of time so you put in a hack solution. Then, you left it there and built a bunch of additional systems on top of it. Now, you're trying to get your game online, and the thing you did shows up incorrectly on the client, and you realize to your horror that you have to rewrite every one of those systems you built on top of that hack that went in for the demo, and, even worse, you realize it's going to take weeks of work to do this.

Or, let's say you were in a hurry building your blueprint, and it works but looks like a clump of hair in a drain. You move on to the next problem. Six months later, you're about to demo the game for your publisher and a weird bug keeps happening in your system. You haven't looked at it since you wrote it, and now you're forced to spend all day and all night untangling the mess you made so you can figure out where the bug is happening.

 

 

In both of these cases, you would have saved yourself a lot of time and heartache if you'd taken the time to clean up the work you did while it was fresh in your mind. If you absolutely have to hack, mark the hack as a hack, and if you know what the proper solution should really be, write it into a comment right next to the hack. And then fix it before you build anything else on top of it. If you've gotten a blueprint or a bit of code running, go straight into your make it right phase while everything you learned during your make it work phase is still fresh in your mind.

Remember this truth: The vast majority of the life cycle of a piece of code is spent maintaining and debugging it. Drill this into your head. It's much harder to debug code than it is to write it the first time, so give yourself every advantage you can. You are not saving yourself any time if you rush when you first write your solution. You're saving time on the small part of its life and creating a big headache that will haunt you during the long part of its life. Plan for your code to be debugged when you write it. You'll be happy you did.