Transitioning from UE3 to UE4

Hi everyone! I’m posting on behalf of Matt Stafford (aka “Wraiyth”), technical director at Pub Games. Matt was kind enough to write up a post detailing Pub Games’ transition from UE3 to UE4 and all of the benefits the studio has encountered in making the switch. Enjoy!
My name is Matt Stafford aka Wraiyth](, and I’m technical director at a company called Pub Games]( Based out of Melbourne, Australia, Pub Games specializes in Unreal Engine development. We released our first game in 2012. Entitled BlastPoints, it’s an iOS and Android space shooter. Pub Games has also worked on a variety of other projects as contractors, most notably InFlux]( and Primal Carnage](

Pub Games is only a small studio, consisting of about six employees and another six regular contractors. We recently received funding to develop Arx, a fantasy action game that plays on the concept of sacrifice and choice.

When I was first asked to write this blog post, I had to give some serious thought to how I was going to approach it. Moving from the Unreal Development Kit (UDK, the free version of UE 3) to UE4 was odd, and there were some vast differences, but the new engine has a strange sense of familiarity, despite significant improvements and changes.

I did a quick run around the office, asking people what they think the biggest improvement over the previous tech is. Everyone seems to have a different opinion, which is a positive reflection on the quality of the improvements Epic has made to all aspects of the engine. But the common thread in every suggestion is that UE4 is giving more power to the non-programmer. I have compiled a short list to better highlight some of the key changes and improvements. Some of them are fairly major, and some are small but useful improvements that even current Unreal Engine 4 developers may not be aware of.

Probably the most well-published and biggest change is the addition of Blueprint]( visual scripting. There’s a lot to be said about the power and versatility of Blueprint - too much to be covered in a single post.
Blueprint replaces Kismet, prefabs, archetypes and adds more power, all in one. Artists can create simple Actors, add a variety of components and build its behavior - all without input from a programmer. These are reusable and very customizable. There’s already a wealth of resources available for Blueprint, with many more in the works. But be aware of its existence and how powerful it is.

No More Packages!
One of the nightmares in UE3 is the package system. Split your packages up the wrong way and a small change to a simple asset could mean a big commit to your game’s repository. In UE4, that’s all resolved by having assets as individual files, or UAssets. Moving these assets around inside the Content Browser for organization is quite fluid, a simple drag and drop process. Coupled with the editor integration of source control management like Perforce and Subversion, it definitely tidies things up!

Simpler Importing
Speaking of drag and drop, it’s now possible to import groups of assets simply by dragging them from a folder in Windows Explorer straight into the Content Browser. It might seem like a minor improvement, but it’s one that improves usability and efficiency.

Animation Assets
Removal of packages also has the positive side-effect of the removal of “group” object types such as Animation Sets. Each animation is now stored as its own asset file, related back to a skeleton. This makes asset sharing much simpler.

In fact, the entire animation system has had an overhaul. UE4 introduces AnimMontages, which puts control of animation sequences right into the hands of the artist. An artist can use AnimMontage for chaining together complex sequences of animations, event-based animation switching and much more.
The replacement for UE3’s AnimTrees is a Blueprint-based system called AnimBlueprint. This enhanced system provides a lot of power to artists, allowing them to build entire animation state machines and transition rules right inside the editor.

The end of INI editing?
“Which ini file is that in?” is a common question that I heard at work all the time during the UE3 days. Luckily, Epic has heard our cries of pain and brought editing of INI files straight inside the editor for common tasks.

Edit > Project Settings exposes a whole heap of useful gems of functionality. You can set your own general settings, collision channels, keybindings, physical surfaces, and much more. Explore these menus - they might save you a lot of work!

Auto-Rebuilding for BSP & Navigation
BSP brushes no longer need to be rebuilt when they have been modified. You’re free to drag brushes around and manipulate them, and see those changes in real time. This dynamic system extends to things like Navigation, which gets automatically built. If you don’t like that feature, or find it destroys your performance, you can also disable it in Project Settings > Navigation System.

No States
If UnrealScript has one strength, it is its state system. It’s a great way to build, well, anything stateful. But with the move to C++, we no longer have native support for state machines. Epic has aimed to address this by building tools that reduce the need for programmatic state machines, including Behavior Trees for AI, and Animation Blueprint States. If you’re still one for using programmatic state machines, C++ is a powerful enough language that you can just write your own!

Subscribers can have a look at the Unreal Tournament 4 source code on Github for an example of a C+±based state machine in UE4.

Asset Referencing
When writing code, you almost always need to reference a variety of art assets - 3D models, particle effects, audio and many other things. Asset Referencing has been vastly improved with the addition of Blueprint, where all of these can simply be added as components inside any given Blueprint.

The natural result of this is that you can end up with a code base with Blueprint references everywhere. Thankfully, there are two systems in place to resolve this: the Asset Registry and Object Library. The Asset Registry allows querying assets that aren’t loaded based on things such as tags and path. This enables you to look up assets during gameplay - for instance, if you have a game with player classes, you can store all your player class Blueprints in a folder, look that up at runtime, and populate a user interface with them - all without the need for hardcoded asset references!

Plugins & Extensibility
One of the biggest gripes many people have with UE3 is the lack of extensibility of both the engine and the editor. This has been significantly improved in UE4 with the addition of plugins, which can be used to add both runtime and editor functionality.

The engine ships with a great collection of examples, the most interesting of which can be found in the “Experimental” directory. For instance, Paper2D adds 2D sprite-based support to the engine. Maths Expressions adds support for using mathematical expressions in Blueprint.

These are still in heavy development but they highlight the power of the plugin system - everything from the addition of new Blueprint nodes to full editors and in-editor visualizations, and probably things we haven’t thought of yet!

What Else?
This list barely scratches the surface of UE4’s feature set, but hopefully it provides some insight into some of the changes - big and small - that you can expect to encounter when moving from UE3.

Be sure to check out the helpful UE3 to UE4 Transition Guide]( on the Unreal Engine wiki and please sound off to give us your thoughts below!

and for some migration from ue3 to ue4

Are UDK3 Level Design Books Still Applicable…

This was absolutely on my mind the other day, not because I was a UDK3 user BUT, because I had purchased two large books on UDK3 which I never got the chance to really use; Mastering Unreal Technology I & II - Introduction to Level Design and Advanced Level Design.

I was wondering, now that I have an UE4 license (thanks so much, Epic) how applicable are those books with UE4??

At this point I’m very thirsty for any kind of books and training on UE4, so if it was possible for me to (finally) get some usage out of those two large tombs of UDK books, it would be great for me!

I’m totally in love with Blueprint, so with that aside for game and level logic, would reading those two books now be helpful for me with UE4, or lead me down a more painful path over just learning and practicing from the available videos and documentation?

I guess I could just start reading volume 1 and get a feel it it’s helpful or not, but it would be nice to hear from someone who has directly worked with UDK3 and is now using UE4.

Any thoughts or suggestions are truly appreciated!


I guess its a bit of yes and no. I own both these books and they were good resources for learning UDK and there is some stuff that will help in regards to general knowledge and workflow but a lot of the specific stuff will confuse you or just be outright unhelpful. Some of the basic skills that you might get from it (ie some theory about level design, theory about materials etc) are generally useful but due to some of the large scale changes in the tools, a lot of whats in those won’t be overly applicable to UE4.

I’d recommend just aiming to learn UE4 through practical use and the other videos & tutorials available. There’s a plethora of them out there.

Thanks for taking the time to reply, Wraiyth, I ended up grabbing volume I off the shelf and started reading though it again (I’m a chronic highlighter, so it’s easily for me to see exactly how far into a book I’ve gone.)

Yeah, the few tips on games development in general were nice to read again - though right off the bat they dashed the hopes of any LONE developers when they stated that UDK games will require multiple, specialized people…

But when I started reading the making your first level and how they were using the subtractive brushes etc., and seeing how much better the UE4 editor is now compared to what I was seeing in the book, yeah, I put it down before even getting to the end of the chapter.

Shame though having spent good money on the books - I had hoped they would be somewhat helpful now with UE4 - perhaps I’ll skim though other chapters and see if I can grasp any nuggets here and there…


Just to avoid you being under any illusions, I think most games will require multiple specialized people to make - although it does depend on the style of game you’re making. I think one of the big upsides of UE4 is that there are so many tools that let you produce something with minimal programming, with a fairly fast turnaround. That means if you’re art-focused you’ve got better opportunities to create gameplay and mechanics without having to learn code.

Dear Wraiyth,

I enjoyed your article!

[FONT=Comic Sans MS]:heart:


Hi, yeah, no illusions, I’m a software engineer by profession, though not in the gaming sector - mostly C#, .Net and recently, heavy stuff.

I’ve been a Wing Commander junkie since the mid '90s and therefore my dream has always been to redo WC Privateer for myself.

Though I’ve used C++ for decades prior, my preference now is C#, which of course had me using Unity up until Epic’s absolutely amazing generosity with their UE4 licensing.

So I’m testing the waters now with UE4 and Blueprints. As I become more comfortable with UE4, I’ll dip my toe back into C++ to make things more optimized as required.

Of course now that Chris Roberts is working on Star Citizen, the pressure is off of me making my own Privateer clone (lol), but at heart, I’m software tinkerer, so I doubt I’ll give up my lofty goals anytime soon, though admittedly 3D is very hard and time consuming.

Having now discovered Paper2D though a YouTube 2D tutorial, I figured I’d spend some time doing some “simpler” 2D games to get familiar with UE4 instead of wrestling with 3D right off the bat.

So far I’m loving everything, as I learn more and more!