This is another short excerpt of text that was originally written as
part of my final internship report in June. It is here aimed towards Unity, as
this was the silver bullet of the year, but a lot of this can generally be
applied to pretty much any closed silver bullet engine.
I have now worked with Unity for three projects. A small game at the global
game jam this year, an online multiplayer board game prototype, and a first
person shooter.
If you want to make generic re-hashed physics games, where the player is a
character walking around a world, and you don't want to do anything
technologically innovative, then Unity is for you, and then you should use it.
For me, it is a pure waste of my time.
Initially, I had given it a chance, because it seemed interesting, and there
was quite a lot of attention paid to it recently. While using it for the first
time, though, I got the impression that the overly designed architecture, which
Unity forces you to use, leads to some very sloppy coding practices (public
variables, singletons, and such), and others who I talked to found this as
well.
Another issue that quickly turned up with Unity was the fact that it's not
possible to debug. When Unity crashes with a fatal error, and it really does
that in quite a few situations, you can lose a very valuable amount of time on
figuring out just where it's going wrong. Sure, with Unity it's possible to try
after every single line of code if it works, because the compilation takes
literally no time. After a while you start spending more than half of your time
on just launching the game just to see if that last line of code doesn't crash
Unity.
I expect from an engine that it only provides me with highly optimized
implementations of fundamentally important techniques that take a long time to
write. And that I can choose to bypass or modify as I wish. Unity does not give
me this. Instead, it gives me a truckload of half working garbage made from a
bunch of libraries they licensed from elsewhere which they crudely stitched
together to form one static unified blob. In comparison, the most friendly
engine that I have used is XNA, simply because it does all the boring stuff for
you, but gives you complete freedom in the area of graphical programming. Unity
is making me think of ditching C# altogether, just so I can avoid it.
But one of the major issues, really, is vendor lock-in. Mostly any script
written for Unity, can not be relevantly used in any game that does not run
under Unity, thanks to the Unity specific interfaces that are necessary for
scripts to interact with each other in Unity. On the other hand, code written
in C++ for one project, with one engine, can easily be retransformed for use in
another project without major changes, even when using a different engine,
because a proper engine does not force me to use poor design patterns. And a
game written in C/C++ using OpenGL and OpenAL runs potentially on everything,
because I can make it to, while a game written in Unity will only run on the
platforms that Unity decides to support. Unity will not run on Linux, because
they said so.
It also does not allow me to experiment with new technologies or techniques.
It is not practical to, for example, make use of OpenCL from within Unity, as
we do not truly have direct access, which makes it impractical to share data
between Unity rendering and OpenCL without needlessly copying data back and
forth between the mainboard ram and the gpu ram.
Then there are countless bugs and design flaws, especially in the networking
and sound interfaces of the Unity engine, that they have known about for a long
time already, as can be proven by various posts on the Unity forums, which are
easier to fix by writing an own engine, than by working around them.
In the end though, if I constantly have to hear, only from people who
actually don't even make games with Unity themselves, how good Unity is, that
"everything" will be fixed in "the next version", and that I should just use
it, then something is clearly wrong. It's more viral marketing hype than useful
technology.
It's potentially a nice level editor, though.
But the thing is, a lot of people do prefer to work with a commercial
all-in-one solution, such as Flash, Unity, or whatever the next silver bullet
is. They just want to get their ideas out there, without having to bother with
technical details, and they'll just hop on to the next bandwagon whenever it
passes by. The upside of this is that they will keep following the current
technological advances. The downside is that they'll be lagging behind the
current technologies for as far as their engine of choice goes.
I'm not in favor of writing your own engine from scratch either. The thing
that you need to be capable of doing, is to rush forward, ahead of the commonly
known techniques, and extend what already exists. There is no use in rewriting
again and again what we already have, it is more valuable to build upon that.
To make a car analogy here; don't reinvent the wheel, make something that's not
a wheel that can do it's function of transportation much better than a wheel,
and mount it on an existing car.
So, in my opinion as a programmer, the best choice is to start out from a
game engine which gives you full access to the source code, whether that be a
commercially licensed or open source licensed engine does not matter. What
matters is that you should have the ability to fix what is wrong, without
wasting more time than necessary. And extend that with your own unique ideas
and experiments.
The
