East Coast DevCon 2014: Engine Overview - A Programmer’s Glimpse at UE4

Editor's Notes

• #2: Prepared and presented by Gerke Max Preussner for East Coast MiniDevCon 2014, November 12-13th Email [email protected] in case of comments, questions or suggestions or visit our AnswerHub at http://answers.unrealengine.com
• #3: Unreal Engine has been developed over a period of over 20 years and contains code and content from hundreds of developers. The result is an unprecedented feature set for game development, but also a lot of things to learn. Despite the large number of components and concepts, you should find it relatively easy to get started. We have put a lot of effort into hierarchically organizing everything, so that the Engine as a whole is really just a big collection of simple parts.
• #4: The very first things you will encounter after downloading Unreal Engine 4 are the various directories on your hard drive. Most of the files are located within the Engine directory, which contains everything needed to make and run games. Over time, you will add your own directories, one for each project you are creating.
• #5: After looking at a few sample projects and perhaps creating your own first project, you may wonder how the Engine knows what to load and what to do. The answer to this are configuration files – we call them INIs. Many systems, such as the Engine, the Editor and games have their own so called INI file stack.
• #6: There is not just one INI file, but multiple ones that are stacked hierarchically.
• #7: In previous versions of Unreal Engine, users had to modify INI files quite frequently. This was tedious and error prone. In Unreal Engine 4 we are making a big push to expose all the important settings directly in the Editor. We hope that, in the future, users will no longer have to edit INI files directly.
• #8: For some very advanced settings you may still have to edit the INI files directly. It cannot hurt to familiarize yourself with the syntax. Here you can see a portion of the BaseGame.ini file. The different types of sections and key-value pairs are easily recognized.
• #9: Take a look at the GameSession class in this example. Note that the C++ declaration of the class (right picture) is marked up with special attribute macros. These macros cause our build tool to generate magic glue code that will add INI file support to the corresponding properties. These properties can now be assigned in the INI file and will be automatically initialized when an instance of this object is created.
• #10: In previous versions of Unreal Engine all code was split into a small number of DLLs. Each DLL had a large number of responsibilities, which lead to a lot of very tightly coupled code that was difficult to maintain and extend. For Unreal Engine 4 we have rewritten large parts of the code base from scratch and reorganized it into hundreds of modules, each of which has one particular purpose. Modules are still compiled into DLLs, but they can also still be compiled into one large monolithic binary. The important point is that the code base is now much more organized and easier to use.
• #11: We split our modules into various categories. Modules that are used by the Engine can be found in the Runtime directory. Modules that are used to build the Editor can be found in the Editor directory. We also have some standalone programs, which share their modules with the Editor. Those modules are located in the Developer directory. One important convention to remember is that Runtime modules must not have any dependencies to Developer or Editor modules.
• #13: Like I said, there are now hundreds of modules in the code base, but you only need to know a few of them. When you first begin programming with Unreal Engine, you will frequently use features from Core, CoreUObject, Engine and Slate. Nearly all other modules in the code base are built on top of one or more of these.
• #14: Once you are more familiar with programming games and tools for Unreal Engine, you may also be interested in other more advanced modules. Most of the remaining modules in the code base implement features for Unreal Editor. You can use them as a learning resource for implementing your own plug-ins and applications.
• #15: There are also several modules that will make it easier for you to add cool new features to the Editor or your game. We recently added the GameLiveStreaming module, which allows your users to stream their game play to Twitch. There is also a module for 3D Head Mounted Display support – the Oculus plug-in uses it to add Oculus support to the Engine. There are also various utility modules, such as Json and XML helpers.
• #16: All these modules are used in the Engine, the Editor and our tools. However, you will actually spend most of your time in your own projects. Projects are really easy to create in Unreal Engine 4. We provide a number of both Blueprint and C++ project samples for various types of games. More templates will be added over time, and you can even add your own.
• #17: Here you can see the project template browser and the sample project browser.
• #18: When your project is ready for testing, you can cook, package and deploy it. Cooking is the process of optimizing your game’s content for the desired target platforms. Packaging will arrange all content files and binaries in a way that is best for the target device, usually a .pak file. Deployment is the process of getting your packaged files onto the device. Cooking and packaging each time is very time consuming. We recommend that you use the Quick Launch feature instead, which utilizes Cook-On-The-Fly.
• #19: UE4 recently started to use C++11 language features that are well supported on all platforms that the Engine runs on. Most notably, we are gradually replacing our OVERRIDE, FINAL and NULL macros. For the time being, you will still see both the old macros and the new keywords being used in parallel. We are also in the process of replacing static local functions with lambdas, and namespaced enums with enum classes. We can’t use all of the modern language features yet, because the XboxOne SDK still requires Visual Studio 2012.
• #20: Of course, this short presentation is not even remotely enough to introduce you to all the components of the Engine. We have prepared a number of other talks for today that will provide more detail on various topics.
• #21: Make sure to check out our extensive documentation on the internet!