Thesis statement for the knowledgeable, short of time, and/or semi-literate:
UDK and Unity Pro both present advantages and drawbacks; will Torque 3D be the open-source savior of Rift development?
I didn't vote - this poll is missing an "
Open-Source Alternative" option (and adding it now will destroy the votes already cast). I'm
hoping Torque 3D will meet my needs; it is a fully open-source,
MIT-licensed, C++ engine with features to rival UDK. GarageGames makes their money by selling art assets and special effects tools through
their own asset store; while there isn't nearly as much content as you'd find on the Unity Asset Store, even a small yet growing base of additional content would seem preferable to UDK's huge in-built asset browser with no official store on which to buy and sell additions. The lead developer of Torque 3D hopes to have full, free, drop-in
Rift support released within the week, and should be setting up a MTBS thread in which to further extoll the virtues of the engine then;
GarageGames' own forum is a good place to direct any questions now or in the future.
OlivierJT is correct about UDK - it really is a
fantastic toolkit for building complex games. I've yet to use any of these engines, but in my research on the topic I keep encountering several entrenched opinions:
"
UDK is perfect for creating first-person shooters like Unreal Tournament, but becomes increasingly cumbersome the more you try to make a game that isn't Unreal Tournament." People have successfully bent UDK to their will and built stuff like
side-scrollers, but it's clear to me that Unity is vastly superior for creating experimental gameplay types as well as any game more suitable to a mobile device than a console or PC. First-person games will necessarily be the Rift's bread and butter, so UDK seems a natural fit;
Torque 3D's roots lay in the shooter genre, so it will likely be similarly useful for Rift development. Please also consider that
Chivalry: Medieval Warfare ultimately became a UDK game, and it features
the best melee combat system I've ever seen. UDK can clearly do anything you want it to, but this leads to the next caveat...
"
UDK isn't a toy, it's the real deal. The learning curve is potentially excruciating, and the toolchain is tailored to a full-fledged studio. Solo developers, embrace UDK at your peril." OlivierJT's opinions would seem to contradict this somewhat, and that's very encouraging, but the underlying point remains something to consider. Unity's accessibility is its primary selling point; with zero experience, I was able to create
a demo for some VR hardware in a lazy afternoon, and other people have had
similar successes. Unity is the
perfect engine for solo tinkerers, which is why I remain so annoyed that Unity demands $1500 for Rift support (and please note, that juicy-looking 4-month "Pro Trial" deal
won't actually let you release anything you create with it!) UDK is so fully-featured it seems to anticipate a studio that has a 3D modeling team, a texturing team, a level design team, a gameplay mechanics team, etc., and lone developers working with UDK run the risk of being crushed to death by all the individual hats they're forced to wear. Torque 3D is attempting to
position itself between these two - accessible to smaller developers like Unity is but more graphically powerful and with a deep toolchain like UDK - but the very idea that you might see some source code is as off-putting to some developers as it is attractive to others. To my knowledge, Torque 3D has nothing like
UDK's Kismet visual flowgraph scripting system, it's C++-esque Torquescript or straight C++, period.
"
Unrealscript (UDK's only scripting option aside from Kismet) is a plague upon the Earth. Anyone coming to it from another language will hate it, and anyone learning it as a first language will inevitably go mad." This is perhaps overstating things, but the general opinion is encountered often. Unity helpfully provides support for C#, Javascript, Javascript-like Unityscript, and Python-like Boo; this is a major boon to developers already familiar with one of these languages, but unhelpfully fragments the community and documentation among these various factions (just try to dig up an A-Z Boo tutorial, I dare you). Epic seems ready to finally acknowledge Unrealscript's reputation by
completely dropping Unrealscript from its upcoming Unreal Engine 4, resorting to further increasing Kismet's capabilities and accepting pure C++ as necessary. This only serves to muddle the entire issue at present, however, because UE4 is the super-expensive source-included big-boy version of UDK, a UDK based on UE4 may not follow these same principles, and UDK4 may not even be released until UE4 has been available for months or years (
and there's been no announcement of a release date). Scripting in Torque can be done in C++ and the C++ source code is as free as the engine itself, so it would seem to be the perfect option for anyone looking to build a first-person game that would run into the closed-source limitations of UDK; UDK's FPS-focused toolchain may make it a better fit for anyone not straying too far from the basic tropes of FPS gameplay, and Unity is very probably an even better option for anyone straddling genre lines and/or exploring new and different gameplay tropes.
"
Okay, Unity sounds great! Why would I ever use anything less accessible?" Well, for one thing, $1500 is a lot for a solo developer to shell out, hardly what I would call a "steal" when all its competitors don't charge a dime up-front; UDK's 30% cut past $50,000 in revenue is far more comfortable for microstudios but UDK's workflow may not be (and 30%
is a painful slice to cut off of any kind of project expecting "real" revenues). I can't say for certain how Torque 3D will compare, but a free engine with a cash asset store seems considerably more appealing to
all developers than a $1500 paywall or a(n eventual) 30% royalty. What may be a larger but less apparent reason to avoid Unity is a potential conflict in the deferred rendering implementation when viewing scenes through a Rift. I can't find more than some
very general speculation about this, but apparently shadows aren't where they should be when viewed stereoscopically; this is obviously a bug (and one Torque 3D has
already squashed), but it remains to be seen if Unity fixes it in a timely manner. In general, I agree with
Aabel's preliminary assessment: "At first glance it does not look like as much care went into the Unity implementation as went into the UDK implementation." Consider the contents of
Rift KS Update #25: UDK has "Optimized low latency VR rendering - sensor update on the render thread, disabling GPU buffering and adding full scene super sampling (1.5-2x)." This is a very exciting line to anyone following this stuff, because if any one thing can kill mainstream adoption of VR, it's people getting physically uncomfortable
due to latency and
mismatched vestibular cues. What Epic is saying with that line is that they've placed the headtracker sensor output in the optimal place in their program loop to minimize latency, turned off the buffering that normally allows extremely complex geometry to load and play smoothly but impacts the speed at which frames are pushed to the player, and added an anti-aliasing method that may provide a pleasing lack of polygon jaggies (hopefully!) without the massive performance hit normally associated with this operation. That's a lot of latency reduction, and it's clear to the Abrashes and Carmacks among us that every damned millisecond counts in VR; Unity has made zero such announcements regarding optimization for the Rift, saying only that it "works". The Torque team seem confident they've arrived at
a number of latency optimizations, and their further progress on the subject may rival UDK's. I do fear that many people will pour countless hours into Unity development only to realize the engine's inherent limitations make it a poor fit for any kind of VR use, but this is only speculation and Unity may yet update their engine to get back on equal footing.
Expecting a TL;DR after all that? There isn't one - the whole situation is a morass of confusion at present and the "best" engine for your project is largely subjective. From my (limited) perspective, assuming Torque 3D really
is more suited to small development teams than UDK, the most basic flowchart looks something like this:
I wouldn't go pinning months or years worth of work on one guy's ramblings, though, so get researching!