The UNREAL® Way

Document Summary: A discussion of design decisions for various aspects of the Unreal Engine. Also known as the zen of UNREAL.

Document Changelog: Created and maintained by Richard Nalezynski^?.

Overview

The Unreal Engine was designed to get a game project up and running as fast as possible, as easily as possible. To do this, we encourage doing things the Unreal® way ^TM, which is how the engine prefers to have things done.

Please remember that the engine is an established system, and for the most part there are practical reasons why something has to be a done a certain way in a certain instance, and the solutions that we provide are usually the best and most practical within the context of the Unreal Engine. As has been stated in the past, a system designed in isolation could easily be more advanced, easier to work with, or more efficient than Unreal's, but it would also probably cause countless headaches when making it work with the rest of the codebase and making it run at a decent frame rate.

We therefore encourage you to use the solutions we provide in an effort to minimize your manipulation of the core engine, as it will save you innumerable hours of time and effort working with and merging future builds. Follow our model for making our game projects, which are all built off of the same engine that you are working with! Isolate your game project - both in terms of content and code. Subclass core components and mirror example functionality in your own modules as much as possible so that your modifications will not affect the core engine. This will not only help with merges, but with support, as well.

As with all projects using licensed technology, you have to weigh the time and effort to merge updated code with the theoretical improvement your changes (or wholesale subsystem replacement) will make. If you have any questions about a design goal for an engine modification or would just like to understand the technical challenges and tradeoffs for a certain approach, please feel free to ask us in the appropriate manner.

For a list of common questions, see the Frequently Asked Questions page; and for a list of "gotchas" see the Common Tech Problems page.

Best Practices

Coding Standard

For Epic's coding standard used for developing the Unreal Engine and games using the technology, see the Coding Standard page.

High-Level Concepts

Native C++ Code Orientation

For a simple code orientation to the Unreal Engine for programmers that are new to the Unreal way of programming, see the Code Orientation page.

Packages and Versioning

For an overview of packages and asset representation in the Unreal Engine, please see the Unreal packages page.

General Implementation

Unreal Units

For an outline the gotchas that have been discussed regarding the complicated task of changing Unreal Units, see the Changing Units page.

Zoning

Most of the functionality of zones has been moved into volumes; as such, Epic no longer uses Zoning in levels. see the Visibility Culling page for more information.

Widescreen

We design our games for one FOV (16:9) so it's going to look differently on the other (4:3). Having fixed horizontal FOV seems like a good choice for games that don't have a lot of vertical, so 4:3 is still playable and you don't get tunnel vision. It means that at 4:3 you will see more compared to widescreen, but we haven't seen that as an issue if the game is designed for 16:9.

If you design your game for 16:9 locked vertical FOV, you don't get a wider FOV for 16:9 but a narrower for 4:3. Properly balanced this means you get tunnel vision on 4:3. If you don't want that, having a wider than normal FOV with 16:9 means that you not only render more pixels, but also most likely more triangles/ geometry for mostly horizontal levels, causing perf to take an extra hit. From our design standpoint, locked vertical FOV is not a good approach if your main focus is 16:9.

We've shipped with locked vertical FOV for past PC games as most folks had 4:3 screens and it also made first person weapons easier, but focusing on 16:9 means fixed horizontal is preferable, which is what we are using nowadays.

UnrealScript

In general, UnrealScript was designed as part of the Unreal Engine - so it, itself, has taken part in driving the technical design decisions of the engine.

See the UnrealScript Reference page for more information.