Unity3D and UDK are the two foremost free game engines in the independent, student, and amateur game development world. Unity was developed sometime around 2006 by Unity Technologies, while UDK, or Unreal Development Kit, was released by Epic Games in late 2009 as their own bid in the indie-friendly world. Both engines became available for free roughly a week apart from one another, and both, by this point, are getting a fairly strong following. Therefore, much in the way that you hear modelers discussing the merits of Maya versus 3DSMax, you hear a lot of discussion about whether Unity or UDK is the better game development platform. This article will serve as a comparison/contrast of the two for the benefit of this discussion, as I’ve had a lot of experience working with both.
Trying to define a “better” game engine is always tricky, because different engines offer different things. Virtually any engine can accomplish any task, it’s just a matter of how much work you have to do to make different tasks happen in one as opposed to another. It’s less that one game engine is actually “better” than another, and more that they’re better-suited to specific kinds of production. In the case of Unity and UDK, both Unity Technologies and Epic Games are firmly set in developing an engine that caters to a wide variety of different kinds of projects and publishing needs, so it’s an especially tricky discussion that requires a peek into a lot of details. We’ll break this down in terms of Unity’s features, then UDK’s, and then a comparison.
Editor Interface and Pipeline
Everything in it is based on “GameObjects,” which are simply containers that you attach mesh renderers, materials, scripts, particles, and various other components to. Where other engines would require you to define a set of sockets, here you can design an object directly in the level editor by lining up all the parts, then grouping them in a GameObject, effectively locking them all together. You can then go on to stick GameObjects you’ve defined into a “Prefab,” which is a pre-defined object that can be instanced repeatedly. An instance of a prefab can be changed in any way without affecting the others, or you can edit the “master” prefab in your library, and changes will take effect in all of them. This is a convenient pipeline that makes creating content very smooth and intuitive, with convenient parallels to working in Flash game development — prefabs and gameobjects aren’t terribly dissimilar to Movieclips and other Symbols.
No particular language here is weaker than the others — Unity Technologies went the whole nine yards, writing equivalent functions for all three for whatever you might want to do. This flexibility is largely without precedent, as most engines say “this is our scripting language, and you’re going to use it.” The only respect where one might be “better” is performance, in that C# runs significantly faster than the other options and has the benefit of accessing all the .NET libraries for C#.
The real highlight of Unity3D, though, is its extremely lively community of developers both amateur and professional who are all willing and eager to be helpful, and its documentation. The Unity3D resource page has several avenues for getting your questions answered, including UnityAnswers (an “Ask.com” type of site specifically for Unity), documentation on all major topics, and the best Scripting reference I’ve ever seen. You can rest assured as you approach Unity that whatever it is you’re trying to figure out how to do, you can probably find it.
In terms of its publishing options, the free version of Unity can publish to PC, Mac, and to a special web browser-based player developed by Unity Technologies. Unity Web Player was one of Unity’s biggest features on release, as it’s the first engine to really challenge Flash as a medium for browser games. Additionally, users can invest in packages for even more publishing options, including ones for iOS, Android, and major consoles. Most recently, Unity Technologies rolled out a Flash Player 11 option, enabling people to get around the download for Unity Web Player and just jump right into the game. Any way about it, Unity defined flexible publishing options. All of these options, though, come with a fee — $400 per team member for the basic publishing packages, and $1500 per head if you want to upgrade to Unity Pro and get the latest features. The good news is that publishing at all is royalty free–once you’ve paid your dues (if you really have to), Unity won’t take a taste of your profits, but you have to front a lot of money to get a really pro-level development tool.
Unreal Development Kit
Editor Interface and Pipeline
The Unreal Development Kit is basically a free version of the Unreal Engine 3, featuring everything the engine has to offer short of source-level access–IE, access to the C++ code that includes native functions, the graphics, lighting, and physics engines, and other super low-level elements. Epic does significant updates to UDK every month, sharing every feature that they give to the AAA development teams that they license to. If you have a machine that can do it, yes, you can play with DirectX11 features.
The downside is that using the engine is generally more technical, as the editor is based on a 15-year-old codebase. Many un-intuitive conventions are still left over from the Unreal Engine 1. In the updates since 2009 a lot of them have been ironed out to reflect more modern sensibilities: subtractive world is gone forever, for better or for worse, the content browser in particular is vastly better for displaying assets than Unreal Tournament 3’s generic browser, and all kinds of new gadgets have been added, including a new terrain editor that works like Zbrush, putting it miles ahead of Unity’s terrain editor in many ways. But that doesn’t change that there’s an awful lot of work-arounds and technical mumbo-jumbo that needs to be done to put a game together.
Importing assets is, while not a pain in the ass, a rather picky process involving grabbing things and putting them in a compressed package, which requires careful organization in order to assure loading efficiency. For modelers it can be a little bit of a pain, as it requires adding an extra plugin to their modeling program called ActorX; UDK recently made a move to integrate the FBX standard, but it’s still not as reliable as ActorX, mainly because different modeling programs output FBX files slightly differently from one another. A friend of mine had no end of hell trying to make Blender’s FBX exporter play nice with UDK.
Additionally, unlike with Unity, which will import a complete asset direct from the raw source files, UDK requires you to basically disassemble and reassemble a model’s components. In other words, what you get when you import it is a blank model, and you have to re-assign animations, rebuild materials, and then re-assign them after already putting them together in your art program. In order to make a complete, working game asset or object, meanwhile, you need to script a class — no easy click-and-drag interface here, you fill in file paths for everything manually with good old fashioned brute force programming busywork.
It’s not that this technical mumbo-jumbo is all that hard that’s the problem. UDK is using standards that are employed across an entire industry of game and software development tools, and honestly does a lot more to save time and effort than most people realize. Rather, the problem is that it’s very intimidating and that it can be easy to get lost within the huge array of pre-canned tools the thing comes with. Where Unity3D’s free/indie license cuts out a lot of tools and functions, forcing you to buy a $1500 per head license in order to get the rest, UDK gives you everything, and I mean everything. Here’s a list of the things that UDK comes with:
- Level editor featuring CSG brushes for blocking out levels.
- Animtree editor for composing animation logic visually. Very little code necessary.
- “Kismet” visual scripting editor for level design.
- “Matinee” interface built-in to Kismet for composing cinematics.
- Node-based Sound editor, enabling networks of sounds to be integrated together.
- Node-based material editor, allowing artists to compose materials visually.
- Skeletal and Static mesh editors, including configurations for cloth, fracture meshes, native collision mesh tools, and LoD generation.
- Node-based post-processing chain editor.
- A whole bunch of assets, default gametypes, and scripts from Unreal Tournament and Epic’s GDC demos.
- Scaleform, a programming resource allowing you to integrate Adobe Flash UIs into your game.
- Cascade, a particle editor with support for a huge array of particle features.
The benefit is that if you master these tools, your projects will glide. You wouldn’t believe how much time they save if employed properly and judiciously. You don’t have to write new shaders, you don’t have to hand-script every door opening — you don’t even have to hand-program most animations, because the Animtree for a character just looks at what state it’s in or what direction it’s moving in and how fast, then blends animations accordingly. There’s always quirks and limitations, but a basic understanding of Unrealscript can alleviate them, giving you an in to developing custom nodes in any of these editors. I myself have developed a handful of custom animtree nodes and plenty of custom kismet for the games I’ve worked on — they’re just little containers that access a function call or a variable.
Speaking of which, the programming tools are … well, there aren’t any. People ask me all the time “where exactly IS Unrealscript? I can’t find the editor!” That’s because there is no Unrealscript editor integrated with the Unreal Engine interface at all. Rather, what you’re meant to do is grab ConTEXT, Notepad++, or Visual Studio, get an Unrealscript library for it, and use that to program. The upside is that if you can get your hands on Visual Studio, it’s the best programming tool around — NFringe’s autocomplete and syntax highlighting for Unrealscript is fantastic and will save you tons of time. If you can’t afford Visual Studio or aren’t at a University with a cushy student deal with Microsoft, then Visual Studio Shell will work just fine as a free alternative.
Fortunately, UDK comes with a huge library of Unrealscript files, ranging from kismet nodes to weapon assets, player pawns, and gametypes, offering lots of examples you can follow to start scripting. UNfortunately, none of these were actually made with the intention of being learning examples; the most complete stuff comes from Unreal Tournament and is so bloated with stuff that’s not necessarily relevant to what you’re trying to do that it’s really impractical to try and dissect. What’s more, there’s a very specific hierarchy to how Unrealscript is meant to be organized, with classes extending from classes extending from classes and whole trees of them already laid out.
This organization and codebase is very intimidating at first, and takes a bit of time to learn, but it ultimately benefits you an awful lot more than it holds you back once you get to understand it, in that it’s highly consistent and supplies you with a solid base for whatever you need to program. There’s already a “Weapon” class that covers all the basics of giving a character a weapon, for instance, and you can extend that into potentially dozens of scripts, each of which only features just enough code to do what you want, keeping them clean and easy to look through.
Learning how the pre-built sets of classes fit together and communicate is a little intimidating at first, but actually is rather easy as you start to learn that they sort of sit in different “families” that can be explored from the bottom up when you aren’t sure what to do or can’t figure out what function needs changing. Classes can be instanced, found, and referenced at the drop of a hat, referred to in the same way that you’d refer to any standard variable (int, float, etc.) and are extremely reliable and efficient once they’re working.
This, kids, is called object-oriented programming. It’s a standard of software development designed to make big programs like this efficient, and it’s here to help you a lot more than it is to hurt you. Unity also supports it, but not as intuitively, and for beginner game developers in Unity it’s easy to fall into bad habits with it. You can extend and inherit Unity classes in a similar way, but remember, a Unity class is a behavior–only a piece of a full, functioning asset. To do the same things with GameObjects as you can with Classes, you have to go well out of your way and do some things that aren’t necessarily terribly efficient, mitigating a lot of the benefits of object-oriented programming.
If there’s a real problem, it’s that understanding how all of these things fit together takes time, and Epic’s documentation and community, although it’s improved significantly in the last year, is still not very friendly to use, let alone able to compete with Unity’s. The editor documentation and resources are fantastic, but the coding resources in particular are awful, half because the script library changes all the time and half because there just aren’t a lot of good places to look. It’s getting better all the time, but for a beginner, figuring out what basic “parts” come together to make up a fully working game is the problem a lot more than understanding what an Integer or a Float is, and very few people are willing to give a good explanation. This, though, is a problem holding back game development education universally, not just UDK.
UDK out of the box is able to support PC and iOS publishing. Epic has support for virtually every other platform, but you need to go through them to get that support. There’s a license of $99 that you need to pay in order to publish a game commercially… but you pay that once, for your entire production team — not per head, and not getting this license doesn’t preclude you from receiving any of the editor’s tools; you get exactly what AAA game devs get no matter what level of user you are. When you publish your game, however, once you make $50,000 off of it, Epic is entitled to a 30% royalty, making the licensing model a bit of a double-edged sword. Obviously that isn’t the case if you become a full Unreal Engine licensee, but that license fee is in the millions of dollars anyway.
So, let’s get to the point, finally — which one is better? Again, it depends on the type of game you’re trying to make.
Where Unreal Wins
If what you want is to create a real-time action or puzzle game of any kind, then UDK is far and away a much better choice. With the libraries and tools that it already has, you can accomplish in a week what it’d take you a month to set up in Unity and generate content faster and more reliably–yes, I said faster. The pipeline might take time to understand, but it’s also non-destructive, and many of the “extra steps” I talked about, if you care about performance and fidelity at all, you would have to do in Unity anyway. You’d have to program new shaders to get things looking the way you want, which means you’d have to reassemble your art assets anyway, and you’d have to do real object-oriented programming instead of fake object-oriented programming. Worse yet, you’d have to go out of your way to accomplish these very basic things that UDK makes easy or has already covered for you.
I want to make this absolutely clear: Unity doesn’t have Matinee. It doesn’t have Kismet. It doesn’t have an Animtree editor. It doesn’t have Scaleform, unless you’re willing to pay a $200 license for that and a $1500 license for Unity Pro (yes, compatibility with third-party plugins is one of the things they hold back). It doesn’t even support animated particles out of the box unless you script that by hand yourself.
This extends all the way down into the source, into the graphics engine. Unity can accomplish visually most of the things that UDK can, but because it’s aimed at the indie market, which isn’t expected to create as ambitious a set of projects, it cuts a lot of corners that can end up crippling a project. There isn’t native level-of-detail support, you have to code that for yourself. There isn’t native culling support, it renders everything. If you put together the exact same environment in both engines, UDK will come out way ahead in terms of framerate and performance because it doesn’t cut these corners.
Basically, everything that UDK goes out of its way to help you do, you need to script for yourself, or else you need to develop your own tools for it. It has a fistful of pre-built classes that can be helpful for kick-starting your projects, like the Character Controller, but where Unity has this bare minimum, really superficial effort’s worth of scripts available (I never use the default stuff, the details are always way off), Unreal has the foundations already laid for entire games — you just need to be savvy enough to know what you don’t have to code for yourself to take advantage of them.
Where Unity Wins
If you’re trying to create virtually any other type of game other than a real-time, action-based game, then Unity comes out miles ahead. For as much as I talk about Unreal setting a better professional standard and being more efficient, there are many times when its vast library of resources and tools get in the way.
If you’re creating a turn-based RPG, for instance, it can be much more of a pain in the butt than it’s worth to try and make the UDK Pawn into a battle character, being that all you need is something that looks like it’s working, not something that actually has collision and weapons and whatnot. You’re basically going to program all the functionality from scratch anyway, so what’s the point? If you’re making a strategy game, then what good is it to have Kismet and Matinee at your disposal? Your cinematics just aren’t that big of a deal. If you’re making a casual game aimed at iOS or Android, what’s the point of all the extra guts? You have to cut down the graphics anyhow.
Better yet, what’s the point of having to jump through an extra set of hoops just to add Android to your list of platforms? Unity’s attitude is “if you can pay, you can play,” giving you a direct line to the tools and features you want without a fuss where Epic requires you to negotiate with them. The initial investment is more expensive than running with UDK, at hundreds and even thousands of dollars per head, but the long-term is much better, with no royalties to worry about.
Even better still, Unity web player! If you don’t want to shell out thousands of dollars, you can jump straight into doing browser games that’re on par with Playstation 2 to early Xbox 360 production values, which can be both incredibly fun and incredibly lucrative. For the same support … oh wait, Unreal doesn’t have equivalent support. Epic is working on Flash Player 11 support, but it’s uncertain at the time of writing when this is actually going to see the light of day with UDK, or even if it will since Unreal Engine 4 is on its way.
Meanwhile, just because Unity doesn’t have a lot of the tools UDK has by default doesn’t mean it can’t have them. That lively community I was talking about has developed a whole world of editor extensions that you can purchase through Unity’s in-editor Asset Store. Among my favorites are an XML/JSON serialization library I found for $15, and uScript, a visual scripting interface for Unity that works exactly like Unreal Kismet. There’s tons of tools and libraries like this specialized to many different niches and types of productions, including branching dialogue tools and even toolsets that enable you to make 2D, tile-based games. Unlike Scaleform, many of these are compatible, to at least a certain extent, with the free version of Unity.
Oh, this stuff costs. Many of them range $50-100 or even $200, so again, big initial investment. If you were to add it up, UDK’s built-in tools total about $4000 worth of Unity extensions (including a Pro license). Still, there’s a certain benefit to being able to pick and choose specialized tools, and there’s more of a benefit still to how open the platform is. In Unreal, there’s no possibility of added editor extensions; what Epic ships it with, you’re stuck with, unless you’re a full Unreal Engine licensee. With Unity, you can use Unityscript itself to build these extensions — the entire Unity editor is even built in Unity’s GUI system, so all your conventions from gameplay programming carry over directly to extension programming.
Conclusion and Additional Reading
So, there you have it — my breakdown of Unity vs. UDK. Hopefully folks will find this informative and useful information. I would love to add a few more perspectives to this analysis, like how they measure up to CryEngine, but alas, my experiences with it are very limited compared with these two engines, which have been my tools of choice for five years. I could talk about XNA and the merits of programming your own engine, or GameMaker, perhaps, but it seems like those are discussions best kept to another day — for right now, the 3D game development tools will do fine.
If you’d like additional resources on these engines, here’s a list of extra reading:
Unreal Development Kit
- My Tutorials — A set of tutorials walking through the creation of basic game assets. Some may be in need of an update.
- Mougli’s Portfolio — Another tutorial site with additional resources.
- UDN Documentation — Epic’s official documentation.