East Coast DevCon 2014: Programming in UE4 - A Quick Orientation for Coders

Editor's Notes

1. *** Prepared and presented by Gerke Max Preussner for East Coast MiniDevCon 2014, November 12-13th Hi, my name is Max. I work as a Sr. Engine Programmer at Epic Games and would like to give you a quick introduction to programming in Unreal Engine 4. Who in the audience is a programmer? Who thinks that programming is awesome? Yes, programming is awesome…
2. … because it empowers you to create really cool things from the comfort of your armchair, and to make other people’s life better, or at least more entertaining.
3. Programming also really sucks… because all programmers are crazy! Who read Peter Welch’s blog post “Programming Sucks”? It is the most accurate description of what it is like to be a programmer and work in a programming team. Welch argues that all programming teams are composed by and of crazy people. He also describes how most programmers start writing perfect little snowflakes, and on Friday they are told that six hundred more snowflakes are needed by next Tuesday. And then a lot of sketchy code gets dumped into a pile of snow that quickly melts together, and some of it turns yellow because a cat peed on it. All large teams end up working this way, and Epic is no exception. We, too, are crazy – perhaps in a good way, or at least with good intentions. We are successful, because we have more snowflakes than others, and the remaining pile is split into manageable parts, and the yellow snow is hidden, because someone leaned a Picasso against it. Who thinks that C++ is awesome? C++ also sucks… but so does every other programming language! They all suck, just in different ways. Most of the time it is because we are trying to use them in ways they were not designed for, and there is no language that solves all software engineering problems well.
4. But do not despair! I will quickly show you a few things to get up and running with Unreal and make your life easier.
5. By the way, we have really great documentation on our website for getting you started, so I won’t go into too much detail. After installing UE4 you can go to GitHub and download the latest source code. Don’t forget to download and install the required dependencies (ZIP files) as well (instructions are on the GitHub page). We currently support development on Windows and MacOS, and there is also preliminary support for Linux. If you work in Visual Studio we highly recommend installing our UnrealVS plug-in.
6. Now, let’s start with some of the most common blockers for programmers just starting with Unreal Engine. The first thing that throws off a lot of people is that compilation is not actually performed by Visual Studio or Xcode, but by our Unreal Build Tool. Visual Studio and XCode solutions are only generated for your convenience. We do this so that we can support different IDEs. In combination with Unreal Header Tool, it also performs a lot of code pre-processing. I will talk about this in more detail in another presentation later today.
7. UBT uses special C# files (*.Build.cs and *.Target.cs) that you create inside your module directories to figure out what it needs to do. Here you can see the build and target rules files for QAGame, a special game that our QA team uses for internal testing.
8. Another little known feature of UBT is the ability to generate dependency graph data that can be visualized. Here is a screenshot of a JavaScript based visualizer that shows a section of our code base.
9. The full source code for all three tools is included with the Engine. You can find it in the Engine’s “Programs” directory on GitHub. Besides UBT and UHT there is also UAT (Unreal Automation Tool), which is used for packaging, launching and deploying your projects.
10. By now you are probably aware of our generous use of acronyms. I already mentioned UBT, UHT and UAT, and there are many others. Don’t worry, you will quickly learn and get used to all of them.
11. We also use code names for some of our tools, and you may stumble upon them in our documentation. The names are often chosen by the developers themselves. For example, Cascade is our particle system editor. It will soon be replaced with a completely rewritten version that is code named Niagara. Swarm is a C# program that allows for distributing expensive work to other computers on your network. It is currently only used by Lightmass and will soon be rewritten C++.
12. If you have experience writing your own little game from scratch, you may be tempted to locate our Engine’s main entry point in an attempt to learn something about how it all works. This is the wrong way to get started. You cannot possibly learn anything useful from this, because most of the code you will use on a daily basis is on a much higher conceptual layer… with about two million lines of other stuff in between. Read and watch our programming tutorials instead!
13. You will notice that we use prefixes for all our types, and there is no logical explanation for it. The story goes that Tim Sweeney, when he started working on Unreal Engine in his Garage, added FVector for 3D vectors with floating point components and a U-prefix for Unreal game classes. When other programmers joined they assumed that these were naming conventions… and that’s how snowflakes turn into yellow snow. We also use upper-case for all names in C++. It may really upset your OCD, but please don’t try to fight this convention as it will help keeping everything consistent. It may take a while, but you will get used to it.
14. C++ is great for a lot of things, but it is also lacking useful features that are present in more modern programming languages, such as Java or C#. Runtime reflection, garbage collection and automatic serialization are the most important ones. We would still like to use those features, so we implemented them on top of C++ with the help of macros that will be parsed by Unreal Header Tool. These special decorators will cause UHT to automatically generate all the glue code that is required to make this work.
15. Here is an example for how a C++ structure for 3D vectors may be marked up in this way. From this, Unreal Header Tool will generate all the glue code, and you will most likely never have to see it.
16. All our fundamental types are declared in the Core module. We have platform specific type definitions for numeric types and strings. We don’t actually use the standard numeric types that are part of the C++ standard. This allows us to hide platform specific behavior of fundamental types.
17. The Core module also contains many generic container types. We also have an implementation for various kinds of event delegates…
18. There is also a library of smart pointer implementations. The most common ones are shared pointers, which also come with thread-safe variants. Shared pointers simplify the lifetime management of objects, and we use them often.
19. String types can be a bit confusing at first, because we distinguish between regular and localized string objects. They each come with special macros for string literals. We also have so called FNames, which store string values in a global hash table. These are very heavily used in the UObject sub-system to identify classes, functions and properties.
20. Oh, and FNames are case-insensitive. If you ever wondered why you can’t correct spelling errors in the Editor right now, that is the reason why. And if you think that’s crazy… well… that’s because it is!
21. We also use macros for less complicated things, such as logging and assertions. These are some macros you will likely encounter when working on your project.
22. We have an internal coding guidelines document that is not yet posted on the Wiki. Since so many programmers from inside and outside Epic are involved, you will find some inconsistencies in style. And, of course, choosing good names for modules, classes, functions and variables is by far the most difficult task for programmers, but also one of the most important ones.
23. We also try follow proper software design principles more often now. You may already be familiar with some of them, such as KISS and YAGNI. One of the most important, but less known object-oriented principle is SOLID. [more details here, if time available] We also use common patterns from Gang-Of-Four and Enterprise Integration Patterns. Other methodologies we’re experimenting with are Domain-Driven Design, Test-Driven Development and Aspect Oriented Programming for cross-cutting concerns. Those are all huge topics in themselves. I will have to talk about them another time.
24. Make sure to check out our extensive materials on the internet, all of which are available for free – even if you don’t have a subscription yet. Any questions?