
An Unreal Decision - cledet
http://martiancraft.com/blog/2014/08/an-unreal-decision/
======
reitzensteinm
I'm a PC game developer that's been using Unity for 2.5 years, and it was
pretty clear after getting involved in the ecosystem that Unity Technologies
was just resting on its laurels, and making decisions primarily on marketing
to sell even more copies. Just a few pain points:

1) Mono hasn't been updated for _five years_ due to licensing issues on iOS.
GC pauses with a complex game can be hundreds of milliseconds, being stop the
world non generational.

2) A similar story of PhysX, though I can't pin down the exact date, 2010 at
the latest

3) They added a new particle system with flashy features, but _no scripting
access_. I don't even...

4) Unity 4 added next to nothing useful (DX11 naturally on Windows only,
Mechanim which was broken etc), though it was necessary to purchase to keep
getting bug fixes

5) No 64 bit editor is very painful (I have 32gb of ram laying around doing
nothing)

6) The project is riddled with bugs, being added and removed each release,
though probably _much less_ than hacky in house solutions which are the norm
in the game industry

7) Nasty serialization formats make programatically changing the hundreds of
meta files in a project next to impossible

However, I'm getting the impression that the new Unreal licensing scheme has
been a real kick in the ass for UT, and they're taking the competition
seriously. Nearly every major problem I've had with Unity seems to be being
worked on now, for Unity 5, after a long period of atrophy.

I fully expected Unity to die a slow death, and that it was just a question of
when to switch to something else (there is not much high quality competition),
but now I'm not so sure. If they pull off their roadmap, it'll finally be an
engine I will be happy to use and recommend. Right now my feeling is: it does
the job, mostly.

Note that the experience making small puzzle games for iOS etc may be very
different, I've done that kind of thing but not with Unity.

~~~
binarycrusader
Or maybe these are all difficult things to solve and you're just now seeing
large projects to address them finally reach completion?

Sorry, but your "resting on its laurels" is clearly not true. If you had
bothered to track the improvements made to Unity's rendering engine (or the
addition of Unity 2D support) over the last two years (well before the Unreal
engine subscription launch), you'd see they actually have been doing quite a
bit.

I do agree that the situation around Mono is pretty unfortunate, and that is
clearly a business decision they've made. But they're also trying to find a
way to mitigate that as should be clear from announcements made over the last
year.

~~~
ivanca
Not true, instead of focusing in people that are a bit serious about game
development they have done plenty of bad chooses, 64 bit processors on home
PCs exist since more than a decade ago, and their engine was created in 2006
for 32 bit platforms, when it was clear 64 bits processors were here to stay.
Also the GUI system is one of the worst GUI systems I have ever seen, yeah
yeah they say they are going to fix it in Unity 5 but we need to develop games
now, not tomorrow. Also calling JavaScript to their "implementation" of what
comes down as just a mask for C# was a huge marketing mistake.

~~~
jonasechterhoff
Disclaimer: I work for Unity. -As for 64 bit support, the biggest problem for
that with Unity is all the dependencies to third party technologies we
integrate. We've managed to get all those resolved for the Runtime part
(Mac/Windows/Linux standalone players) a while ago (we've been adding 64 bit
versions of those during the 3.x and 4.x release cycles), which meant getting
Mono, PhysX, FMOD, Substance, etc all working on 64 bit. For the editor,
however, there are a lot more third party libraries involved (such as a web
browser engine for the asset store), not all of which had 64 bit versions to
start with. So there were a lot of dependencies to resolve, which is why this
took time. Good news is, we have all this working in 5.0, which will be out
later this year.

-For the new GUI, we are not going to fix this only in Unity 5, but already in Unity 4.6, which should be out really soon.

-About the "JavaScript" misnomer, I agree that that was a bad decision in retrospect, though it is not trivial to change at this point.

~~~
tobz
What is the deal with software being hard to release as 64-bit?

I'll fully admit that I don't work in C/C++ on the desktop, at all. This just
seems like a button toggle problem (I know it was that way for C#/.NET apps,
again, grossly simplify and apples to oranges) though, and it's surprising
that you aren't just able to ping someone at these companies and ask for a
64-bit build.

~~~
exDM69
> This just seems like a button toggle problem

Sometimes it is, sometimes it isn't. The problem is knowing when it is or
isn't. That needs building with all warnings enabled and vetting through them
manually, a run with a static analysis tool searching for possible 64 bit
bugs, or at worst, running extensive test suites to try to detect errors at
runtime.

Some (older) software might also have some internal structures that are
designed on the assumption that pointer size equals 32 bits.

This issue is made worse by the loose conventions in implicit integer type
casts in C and C++. Warnings do help here, but there's going to be a huge
amount of spurious warnings too.

So, at best, all you need to do is change compiler flags. At worst, you'll
need a lot of manual labor in making sure that your applications build cleanly
for 64 bit machines.

~~~
pjmlp
To the point that Microsoft even introduced 32to64 porting tools in the
Windows SDK, because not everyone made proper use of platform agnostic types
and helper macros to start with.

------
keerthiko
My teammate and I started moonlighting on the first game for our studio about
8 months ago, right before Epic announced the current $19.95/seat pricing
model. We decided to go with Unity purely because I already owned a Pro
license, that we could use to make final beta builds and be responsible for
the advanced visual effects that needed Pro. Additionally I already had lots
of experience with Unity, and nearly none with UE.

We are only a two-person team, making a fairly limited-scope 3D puzzle racer
game. Thus we didn't hit the major issues with collaboration bugs (we did a
few times) or platform switching (we're focusing only on PC). We were able to
build our MVP in less than 2 weeks of hacking, and it felt amazing. The asset
store was also an amazing resource to circumvent the artist issues.

However, it's been nearly a year since then, and polishing the game to the
standards we'd like has been presenting larger and larger challenges --
performance, obscure shader behaviour, limited editor extensibility (it's
good, but not quite good enough), and reading this post, it looks like at this
stage of development Unreal would have served us much much better.

If we can get our studio rolling and increase our team size to actually
incorporate dedicated artists, we'll have to seriously consider switching to
UE4 for our next game.

Jeff's write-up sheds insight that few people can have, given not everyone has
spent the time to get well-enough acquainted with both engines in the team
setting to know their professional tradeoffs as well, and I appreciate it a
lot.

~~~
christoph
You highlight one of Unity's real strengths here that is often forgotten - the
asset store. Want to drop in a nice city scene? Thats 10 bucks. Want realistic
car physics? That's 10 bucks. A few nice NPC's with rigged faces? Thats 20
bucks. A pack of nice shaders? 10 bucks.

I don't think Unity is targeting AAA developers at all. Its targeting small
studios that want to get ideas built quickly. It's got great, simple Oculus
integration as well. If you're planning on building something AAA (or close),
you probably have modellers, artists and level designers and don't need the
asset store. You probably need, or are already using Unreal.

~~~
ivanca
Absolutely false, using imported materials and creating your own is extremely
easy to do in Unreal, and there are tons online of stores where you can buy 3D
models, Unreal integrates pretty well with all kinds of 3D models (including
riggs) specially those from Autodesk Maya. And over top of that there is an
Asset Store for Unreal, is called the Marketplace and the EPIC team is filling
it itself with tons of free high quality materials and models.

~~~
exDM69
Yes but the point in OP and GP is that the amount of content available in the
Unity store is greater than other stores. Sure Unreal has the same goodness
but there just isn't as much stuff readily available in the Store you can just
pick up and use.

So it's a content issue, not a technical issue with the engine itself.

~~~
TMichael
@christoph:

As the article's author pointed out, you don't need many of those addons in
UE4 because the functionality is ALREADY built into the engine.

Want realistic car physics? Already built in! Want great shaders? Already
built in! Want rigged faces or a cityscape background? As regular assets, buy
them anywhere on the internet (including the Unity asset store), and then put
them into UE4!

And this is why one of Unity's strengths is also one of its weaknesses. The
reliance on so many third party libraries for basic functionality means that
A) integration with the engine isn't always perfect, B) updates and fixes are
dependent on the third party author, and C) the UT community is nickeled and
dimed for many things which should be included already.

------
Coincoin
As someone who tried to develop a Unity game on a big team, it was hell. The
collaboration is horrible, there are conflicts all the time for no reason.
Simply getting the source, running the game and updating would produce
conflicts. We also had to buy the cache licenses to make it somewhat workable.

But the worst was the support. It was worthless. Anytime we would open a
ticket, they would simply google and return us links to forum threads that
didn't address our issue. When we asked about missing important features or
bug fixes, they told us to buy something on the asset store.

~~~
oafitupa
Wow, that's horrible. So what do you recommend?

~~~
Coincoin
For a big team, either use Unreal or the in house engine.

I heard good things about Havok's game engine too, and their support is the
best I've ever seen.

------
Tepix
I recently started getting to know Unity3d and it was extremely easy and quick
to learn. One annoying discovery was that their variant of JavaScript is not
real JavaScript, it's "UnityScript". It took me quite some time to convert a
simple script that I had written for node.js to UnityScript.

I need the pro version of Unity3d to generate iOS, Android or VR games for the
Oculus Rift. For someone who is just doing a bit of indie development, that's
too expensive.

So I checked out UE4 also. You can subscribe for a month for $19 and then
continue using the version that was the current version during your one month
of subscription. If you need updates later on, subscribe for another month.

UE4 is harder to learn but looks a lot better than Unity OOTB.

Anyway, I hope Unity will be competitive again regarding pricing with the
imminent announcement of their 5.0 release.

~~~
jimmaswell
Why would you choose to develop for a game in JavaScript anyway? The language
devs use for Unity tends to be C#. The design of the language fits the
framework much more. I've been using C# with Unity and using JavaScript on
webpages for years and JavaScript has always been much more cumbersome and
error-prone to write nontrivial logic in. So many errors all the time that
would've been found at compile-time in C#. Maybe Unity's JS is different; I
haven't used it.

~~~
JabavuAdams
Unity's JS is different. It's all Mono under the hood. It's not at all like
working with browser Javascript.

------
klodolph
I've been bitten before by some of the problems regarding Unity and
collaboration with source control. Everyone wants to test out their changes on
the same scene, but it just blows up when you go to merge... even if you use a
dumb merge strategy like _ours_ or _theirs_ (as a Git user) it seems to break
things. Unity seems really cool, but I'm never going to use it again for any
project with more than one programmer.

~~~
keerthiko
We build BitGym (www.bitgym.com) using Unity, and it has a lot of moving parts
and 2-3 developers working on scene, code and assets, and we've made it work
with git. It really comes down to developing and maintaining some best
practices:

\- Always use prefabs wherever possible. But avoid nesting prefabs

\- Always save your prefabs, then save the scene before pushing. Thus the
.prefab files are also updated through git: these are more robust and have
higher priority than the scene.

\- Make sure source control uses meta files (unless you're using Unity's Asset
Server) so that scene references are stored again in separate files updated
through git.

\- Make sure individual developers have a lock on individual prefabs. Unlike
scripts, Unity will bomb changes from one side of the merge on binary files,
but this is expected when using git on binary files. Of course you can treat
the scripts as any other code project, and they merge fine.

It's still not ideal, and we occasionally wind up with merge issues or a day
of having to carefully iron out scene conflicts when doing larger branch
merges, but they haven't been so dreadful as to make us decide never to use it
again because of the collaboration issues.

~~~
Stratoscope
That's very helpful, thanks! One question...

> Make sure individual developers have a lock on individual prefabs.

Can you elaborate on that? Git doesn't have file/directory locking unless you
use something like gitolite, so what kind of locking do you mean?

I found UnityLock in the asset store, which is supposed to let you lock assets
against editing, but it doesn't seem to work in 4.5:

[https://www.assetstore.unity3d.com/en/#!/content/4851](https://www.assetstore.unity3d.com/en/#!/content/4851)

The code seems straightforward enough, so I may see about getting it working
if the author doesn't do it.

------
mahyarm
Their entire attitude of accessible, changeable source, accepting patches and
responsiveness is really refreshing. If you do windows or apple dev, the
frustrations of having none of that available is a big productivity drain. The
high amount of responsiveness part is even nicer, since that seems rarer in
platforms such as unity or android.

------
Fr0styMatt
These are my gripes with Unity, in question format :) Would love to hear from
anyone that has concrete answers for these:

\- How does UDK build apps for iOS natively on Windows without requiring a
Mac? Are they doing some kind of insider thing that Unity can't replicate?

\- I see Unity as massively extensible and that's one thing I like about it.
Comparisons are often made between vanilla Unity and UDK; what about Unity +
PlayMaker + UFrame + Level Builder, etc. I don't see this ease of editor
extensibility with UE4 (I'm sure it's there; but the Unity Asset Store just
lets me cherry-pick one, click buy and then just have it to use immediately
after download - I like that).

\- My biggest gripe with the editor is the font size. Will the new UI that's
coming in 4.6 and/or 5.0 allow me to increase the font size used by the Unity
editor to actually make it comfortably usable rather than fatiguing?

FWIW I've preordered Unity 5 and I use UE4 at the moment as well. Nothing big
completed in either engine (just some side work here and there) but no fanboy-
ism for any particular one (though a bit of a fondness for Unity as I
encountered it back in the old Mac days when Unity were called Over The Edge
Entertainment; GooBall was pretty cool by the way).

~~~
ido
I don't know how UDK does iOS but I'd like to mention that was also a big draw
to adobe air for me - you can develop/compile/deploy to ios from windows
(don't know how it does it either but apparently it's possible).

------
JabavuAdams
I may eventually do the same for a project I'm working on, although for me the
draw would be UE's battle-tested network prediction code.

For visual programming in Unity, there's PlayMaker -- an add-on available from
the asset store. It allows creation and graphical editing (and graphical
runtime debugging) of FSMs (though not hierarchical FSMs). It's quite a good
implementation of a FSM / event / action framework. It's basically superior to
some tech I spent half of 2013 developing for an in-house proprietary engine.

I agree on the collaboration problems. Even with purely text-based
serialization, collaboration is one of Unity's weak points.

------
joeld42
I'm writing my own engine. That's a terrible idea, I'd be much better off with
either unity or unreal. But since game dev is more of a hobby for me, and
writing the engine is the fun part, I'm ok with that.

However, for smallish projects (smaller than Republic Sniper, I mean)
sometimes it's the right choice. I see a lot of indies struggling with lugging
around and maintaining a huge engine (unity, especially, but even cocos2d),
and running up against the limitations like difficulty integrating with native
sdk features, and their game's requirements are modest enough that they could
probably code it from scratch in not too much time.

~~~
erikb
Also hacking together a development environment through different open source
projects and own code is not a bad idea. It's harder in the beginning but also
gives you more control and more skill in the long run.

------
mrfusion
Side question. Where do single indie developers get the artwork for games?

~~~
nacs
By hiring a graphics person or by creating it yourself.

There are some free assets out there but they're mostly low-quality and the
few production-quality ones are used in numerous low-quality games.

~~~
mrfusion
Why aren't more production quality ones free or available for sale? It seems
like it might encourage more foss games?

~~~
dublinben
Programmers tend not to be artistic, and artists tend to not support ideals
like free software/free culture.

~~~
LeftSideDrive
I make 3d models for games. In fact, I make 3d models for the game in the OP
at MartianCraft. There's a vibrant community of game and 3d artists supporting
eachother, giving out free assets, free help, free advice, tutorials ETC. I
take issue with your broad assertion that artists don't support free culture.

When it comes to assets, it's tough to put together a library of free, or even
purchased ones, because the style, poly count, texture resolution, texture
mood, art direction ETC just won't be consistent across assets. We even
purchased a couple of low-priority models and found that it took more time to
fix them and bring them up to MartianCraft standards than it would have taken
for us to design, re-topologize and texture assets ourselves.

Furthermore, almost everything needs to be designed and and built for specific
layouts and proportions. If that pillar is a little too tall or not tall
enough, you can't just scale it up as it will stretch the textures and look
terrible. Things you can see and judge with your eyes are more difficult to
piece together from disparate/inconsistent parts than invisible code.

~~~
mrfusion
Thanks for the detailed writeup of your experiences. What would you say would
be different for a hobbyiest just learning 3D game development? Would free
assets be more viable if you don't need a professional, polished look? Could
you still get a playable game?

~~~
LeftSideDrive
Ehhh, it's tough. What happens when you need a vertex moved or a poly count
reduced? Visual assets really impact game performance in a way that requires
bespoke work on almost everything. It doesnt help that the number of free
game-ready assets out there is basically 0

------
jokoon
I remember being at a private game programming school, there was a school
project to make a game with unity 2 or 3. An entire class was using it.

Things were synced using subversion.

I never really jumped in that. I did not continue at that school.

I really think a video game is something that should be made with your custom
tools. A good smith makes his own tools. Of course if you want to save time,
you can use an expensive, well-made tool, but it will be at the expense of
something else.

I'll always remember at that school, quickly arguing with a guy, that in C++ a
vector is just a linked list.

Game programming is often highly technical, and often much more complex than
what you're expecting it to be. That's why you should not neglect your tools
and highly concentrate on making choices that fit your work.

~~~
scott_karana
> A good smith makes his own tools

The problem is, this can be taken to infinitely far ends.

Editor annoys you? Modify it to your desires. Don't like the compiler? Write
your own. Get sick of the programming language? Invent your own. Get annoyed
with how the OS does something? Change it or invent your own. Bump up into
x86's limitations? Start on custom FPGAs.

Ten years later, you might still have 0% completion on your videogame, and
indetermine completion on your ever-fractaling toolchain. (And this isn't just
a thought exercise; I remember a HN submission earlier this year that was
nigh-identical to what I describe)

I would rephrase what you said as _" A good smith knows his tools and their
limitations, and knows when it's appropriate to make his own tools"_. Even
when talking in analogy... a smith's apprentice would not presume to make his
own tools before experiencing his master's, and even further I suspect most
smiths did _NOT_ make their own anvils, or mine their own steel... ;)

There's also a healthy serving of "Worse is better" in this line of argument.

~~~
jokoon
Yes it's true, but I would not take the smith tools argument that far.

You could say there's a spectrum of low level/high level tools you will either
work with or build yourself.

Most low level tools are now quite good enough. The more you go high level,
the more will deal with specific cases that will restrain your ability to do
thing the way you intended. Like the article said, Unity will fit for very
small teams and very simple games, but it will be hard to do anything really
complex.

I think compilers, languages and engines are better suited for more use cases
than an editor like unity is. It's a dilemma of flexibility versus speed and
ease of development.

ease of development/flexibility:

ease<|--#-------------------------|>flexibility

ease<|-----#----------------------|>flexibility

ease<|----------#-----------------|>flexibility

ease<|--------------#-------------|>flexibility

ease<|------------------#---------|>flexibility

ease<|----------------------#-----|>flexibility

ease<|-------------------------#--|>flexibility

------
georgeecollins
I have been Producing a very large game project with Unity. We have a large
team, at times 50+. Our graphics aren't as state of the art as they could be
but the performance of the Unity engine does not seem bad. The cross platform
compatibillity is very strong. The third party tools are very strong. It's
worked out well.

Unity seems like it was built with ease of of entry as a first consideration.
As people do larger and more ambitious projects with it they are hitting some
of the tradeoffs and limitations. I am sure UE4 is a good choice as well.

------
malkia
Haven't used the tools much, but I'm subscribed, and simply in awe of Unreal's
internal UI system (used for the Tools), and hope EPIC release it in some more
independent form.

------
LeicaLatte
Recently moved to UE4 too. Used to do Unity.

I moved because I was originally a C++ developer. Had code lying around I
could use easily.

~~~
vyrotek
How was the move from C++ to C#? The last time I seriously touched C++ was 10+
years ago. I've been doing almost all C# (and a bit of Java) since. The only
reason I feel like I'm sticking with Unity is because of how familiar I am
with C#.

~~~
LeicaLatte
C# felt like it is tooled well for doing many things on game stacks. Would
love to spend more time with it.

------
_random_
The problem is that Unity3d is being mis-marketed as a triple 'A' tool-set.
It's not.

------
rodgerd
> The other big obstacle was that the UDK tools which were Windows only.
> MartianCraft is a shop of (mostly) dyed-in-the-wool Mac folk who’d rather
> not spend their days using Windows.

That really doesn't seem like a great way to run a railroad.

