Hi Angus:
Just came off a Unity project for my last job
(http://neveralonegame.com/). My advice is exactly the opposite; if you
value your time as an artist, don't even bother with Unity. It's nowhere
near the level it needs to be to even think about competing with
UE4/CE3, let alone other game engines.
I normally don't like to write negative things, but because I feel so
strongly against how Unity is designed (and how they responded to our
support requests for stuff that was clearly broken), here's my breakdown
of why I disliked working with it.
*Shaders*: Even U5's new PBR shaders are a nightmare to work with. No
node-based shader editor (other than Shaderforge, thank god for that)
makes it very difficult for non-technically inclined artists to work up
cool shaders. And I was working with U4, which was terrible in itself in
terms of OOTB offerings for lighting. And as for the "one-click
multi-platform deployment" stuff, yea...the last 3 months of Never Alone
were our main engineer and a few of us frantically trying to figure out
why our shaders were all compiling pink on PS4/fine on PC/geometry not
rendering on XB1/other mad bugs, and Unity pretty much refusing to help
fix their own bugs. At least with UE4 we'd have been able to fix the
problems, whether ours or the engine's.
*Mechanim*: The entire animation system is a nightmare to me. The
retargeting system really pissed me off as an animator, and as a rigger,
I wouldn't ever want to work with it again. Essentially whatever rig you
provide Unity will always be re-targeted to a internal rig that is
pre-defined and unchangeable...and it provides 2 spine bones for
deformation, along with also requiring you to setup RoMs for every
single joint...for every single character that you make. The only
benefit to this? Animation re-targeting. Which no other sensible
re-targeting system (afaik) does in this manner. The alternative? None,
other than using the legacy animation system which is unsupported and
does not have IK solvers. I should also point out that it was in
response to Unity's nonsense with Mechanim that I ended up writing a
custom viewer for Maya just so our animators (and I) could look at our
own animations and critique them objectively without worrying about if
Unity was actually doing some weird stuff with the Avatar system that
was causing them to look different in-engine.
*Shuriken *(particle system): Let me put it this way, having worked with
UE4 and Unity (and a few other particle systems besides), there's no
contest. Shuriken is in serious need of an overhaul; it's way too basic
and buggy (esp. with animated textures and mesh particles), and 99% of
the time effects I want I end up using a combination of
scripting/shaderforge to get what I want, rather than struggling with
the limitations of Shuriken.
*Pipeline*: Unity's YML files (way it stores metadata) is an absolute
nightmare. Apart from the annoying way it generates metadata files (and
regenerates GUIDs for every asset comes in) the way it works (by
randomly writing metadata everywhere within the same YML file) pretty
much ensures that if you have more than 2 people working on the same
level at the same time, you're going to end up with merge conflicts all
the time unless you have very, VERY well-trained artists/designers in
terms of SVN lock/whatever VCS you choose to work with. We ended up with
a gDoc that had people manually update what section of which level they
were working on based on nothing more than an honour system, because
people didn't know how to use SVN lock, and you can imagine how that
went :)
As for animators, because blend state trees also use the same YML file
storage format (and the same dumb ways of using GUID/UUIDs to refer to
animation clips instead of filenames) also ensures that only ONE person
can work on ONE file at a time, and must ensure that their file is
checked in along with the metadata file that accompanies it, or Unity
will start regenerating it on everyone's machines automatically, and
then when they check those files in, enjoy resolving the resulting mess
of conflicts!
I'm not here to plug UE4 really (I personally am a huge fan of CE3 cause
I'm a graphics whore :P), but I will say that if you think it's easier
to 'learn' Unity compared to UE4...perhaps the UI? But I would suggest
that running into technical roadblocks that actively inhibit producing
quality content is far more damaging than getting over a higher learning
curve.
Hope that helps, (and it doesn't sound like I'm bashing Unity too much)! :P
Yours sincerely,
Siew Yi Liang
On 1/19/2015 7:58 PM, Eric Turman wrote:
@Nicolas Esposito
"....In the end you could end up spending A LOT of money just to have
some basica stuff which you could code ( if you have the knowledge... )
For me Unity is a good engine for a team project, not for a personal
one."
I think that you might benefit from considering thinking from a
different point of view:
Purchasing the right asset from the asset store can save a lot more
money in the long run when you stop to consider how much time it would
take you to create that from scratch (even if you are a competent
coder.) When Considering assets from the asset store, the real
questions are:
* Could I script/learn-to-script this in less time than I would have
to pay myself at $n/hour
* Does the asset give enough capability and flexibility out of the
box, and, if possible, what could it take to extend its capabilities
* Is this something that I would rather invest in my time to become
proficient at
Unity allows an individual or very small team to accomplish a wide
variety of projects on a wide variety of platforms that could
otherwise be out of their reach.
There are even node based setups in the asset store for programming.
As for examples in Unity, there are many as well.
Cheers,
-=Eric
--
-=T=-
