We got started working on Dark Deception as a couple guys working on their weekends, and one of the first things we had to decide was: What engine should we use?
Background
After a bit of looking around, we had 4 main contenders: Valve's Source Engine, CryEngine, the Unreal Development Kit, and Unity.
We dabbled in Source Engine for a bit, but the lack of artist tooling made us drop it.
Then we spent a good while in the UDK (Unreal Development Kit), but ran into problems and decided it wasn't a good fit.
We considered CryEngine, but avoided it due to rumors about licensing delays and problems preventing nearly completed games from being finished. (When funding a game out of pocket, the idea of finishing it then not being able to release is really scary).
We decided to try out Unity for a couple of days, and we liked it enough we decided to drop the UDK and focus entirely on Unity.
Costs
Unity and the UDK are both very upfront about their pricing.
UDK:
Basically, you can start out a commercial license for $99.
The first $50K you make from your first game (after platform fees and taxes) goes straight to your company. After that, you pay a 25% royalty (again, this is calculated after platform fees).
I'm pretty sure that money earned from kickstarter actually counts as game income for these purposes. Epic recommends you get in touch with them for a full license after making about $200K to $250K, which means the full license probably costs around $50K.
Unity:
You can start out for free. To really get anywhere with the game in a team project, you're better off with the pro version and the team license. That's $2000 up front per person, though there's actually a
leasing program that lets you pay a lot less ($95 per month for a year). By the time a year has passed, we'll either have a decent budget to buy the actual software, or we'll be closed, so we both went with subscriptions.
Unity has no royalties.
So as a comparison, lets look at what you take home depending on how much you make. I'm looking at the money after platform taxes & fees (I don't know exact numbers, but I wouldn't be at all surprised if 30% of the money from every purchase on Steam goes to Valve). This is assuming 2 people and that Epic doesn't charge you another $50k when you want to get the full license. This is also ignoring any costs for buying Visual Studio and NFringe to edit Unrealscript.
| Game Makes | UDK cost (estimate) | Unity Cost (per developer) |
| $0 | $99 | $1,200 |
| $50,000 | $99 | $1,200 |
| $100,000 | $12,599 | $1,200 |
| $150,000 | $25,099 | $1,200 |
| $200,000 | $37,599 | $1,200 |
| $250,000 | $50,000 | $1,200 |
| $300,000 | $50,000 | $1,200 |
| $1,000,000 | $50,000 | $1,200 |
Unity also has some extra costs in the form of the asset store - basically, you can buy libraries and assets from other people. A lot of stuff that Unreal does automatically needs to be either made from scratch or bought from the asset store, which drives up the price somewhat. A little annoying, since sometimes people will post a script to the asset store and link it in help requests, instead of just posting the code to show people how to solve their problem. OTOH, lots of really cool libraries available for relatively small amounts of money.
Coding
UDK uses Unrealscript, which is a customized language that has a lot of odd constructs. I've been working in C++ family languages for a long time, so a lot of coding systems Unrealscript requires feels very odd to me.
With the help of NFringe, you can program Unrealscript in Visual Studio, which is awesome (though very much not free). However, every time you modify your scripts you have to restart the editor... very annoying, but I've heard rumors online that they're fixing that in Unreal Engine 4.
Unity uses C# with a bunch of custom classes and functions. They've gone through a lot of effort to make things dead simple to use, but that does have some drawbacks. They package MonoDevelop with Unity and with a bit of effort you can do inline debugging (you have to launch the unity editor from the IDE, then load your map and start the game).
In general, I found Unrealscript to be more verbose than Unity's C# systems, which can be both a good and a bad thing. I'll show an example of basic Bot that follows the player around.
In Unity, I drop in a 3rd person player, tear out the camera and control components, and add a Nav Mesh Agent component and a new script. I also need to select my floor & obstacles and bake the Navigation in the editor.
My script is simple:
public class Follow : MonoBehaviour {
private NavMeshAgent nav;
public Transform playerLocation;
void Start () {
nav = GetComponent<NavMeshAgent>();
}
// Update is called once per frame
void Update () {
nav.destination = playerLocation.position;
}
}
In the editor, drag the player game object into the playerLocation variable, and there you go. Took me a while to figure out how to do all of that, but very little overall code. On the other hand, this bot will always play the same animation, will often look a bit clumsy, and you don't actually know anything about what the NavMeshAgent is doing under the hood.
In the UDK, making a basic bot is far more annoying. You need to make 2 classes (a pawn and a controller), figure out all the required defaultProperties (set the mesh, set the controller, set the groundspeed, etc), figure out UnrealScript's state system and important controller functions. The code below replaces one line of the code in the Unity script:
Begin:
Player = GetALocalPlayerController().Pawn;
NavigationHandle.SetFinalDestination(Player.Location);
if (NavigationHandle.ActorReachable(Player)) {
MoveToward(Player,Player);
} else if (FindNavMeshPath(Player)) {
NavigationHandle.SetFinalDestination(Player.Location);
if(NavigationHandle.GetNextMoveLocation(TempDest, Pawn.GetCollisionRadius())) {
MoveTo(TempDest, Player);
}
}
Goto('Begin');
Lots more to type, and far more opportunities to screw it up. But since I've already got that entirely typed out, I can pretty easily stick in alterations to change behavior at specific times. For example, if I want to do a lunging jump as soon as there are no obstacles in the way, I just replace the first part of the if statement.
UDK also automatically handles animations really well, so when a bot is turning or sidestepping it plays appropriate animations. The bot has built in footstep sounds too. My understanding is that its not too hard to set that up on the artist side, but we never got to that point.
Overall, UDK depends pretty heavily on large amounts of scripts if you want to do anything custom. In Unity you're just adding custom scripts to GameObjects, and those scripts are often really short and simple when you get them working. I'd say the UDK is much harder to get started on and do simple things in, while in Unity it's harder to get a really polished final product.
I've been getting stuff done a lot faster in Unity than in the UDK, but I'm still worried that I'll have a harder time with the really deep and complex stuff.
Art
Vince seems to like Unity a lot more than the UDK. He was making good progress with the UDK, but light mapping issues were giving him fits.
From almost everything I've seen, most Unity games just don't look as good as most Unreal games. An engine written the way Unity has been will have a very hard time matching Unreal in terms of performance, which means fewer polygons and rendering tricks. UDK also comes with a lot of awesome rendering, lighting, and special effects systems, while in Unity you'll have to find those in the asset store (and most asset store systems don't post any information about how expensive they are to render).
At this point our Unity build looks better than our UDK build, but most of that is because we're not running into lighting problems.
Level Creation
Both editors are really good at letting you put together large and complex levels. I like Unity more because of their component and prefab systems. The component systems means you can easily add almost anything to an existing game object. Want something to emit light? drop in a component. Want it to move around? be an obstacle? emit particles? Just add the right components.
Being able to quickly and easily create new components that can be configured in the editor means that when Vince wanted to make a flickering light, he could just copy and paste a script someone had posted online, then configure the speed of the flicker in the editor.
The prefab system means you can easily create dozens of copies of an object. You can modify some of those objects to be customized, and you can easily change the prefab to modify all instance of the object across all your levels.
In the UDK, you can create custom types of objects via script (which then requires an editor restart), but you can't do much to modify the functionality of an object that already exists. However, the UDK has kismet, which allows you to set up complex systems and behaviors without touching the code. The biggest complaint I've heard about kismet is that it can't really be put into a version control system, but it's also missing some basic functionality (like vector math).
Conclusion
For a small indie studio that doesn't want to spend years on a single game, Unity makes a lot more sense from almost all perspectives. It wont give you AAA quality visuals or top of the line rendering capacity, but it will let you focus on your gameplay and actually get your project out the door.
For a larger team that wants to make a game that looks amazing and/or has tons of enemies on screen, the UDK is probably a better choice. The upper end of what can be done with the engine is higher, and most of the systems assume that you'll take the time to polish everything.
