The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
For those of you who don't know me, my name is Tyler Glaiel, and I've been using Unity for the better part of this year. My previous project, Closure, was programmed in C++ in a custom engine I build myself, and before that I worked mostly in Flash. I decided to learn Unity this year and make some games in it, after hearing so much about it, and I figure I'd share my thoughts on it for anyone interested. I'm using C#, with Visual Studio 2010 as my code editor. I'm a fairly expierenced programmer, and this post probably won't be applicable to you if you're just starting out.
I tried learning unity a couple years ago, after getting a free copy of it as part of Closure's IGF nomination, and just couldn't get into it. Tutorials for it were all from the perspective of someone who has minmal coding knowledge, and it felt like starting from scratch trying to learn how all the drag and drop stuff worked, looking at absolutely terrible sample code, and just dealing with the unity interface, and I gave up after about 3 days.
In December of last year, I started getting a lot of ideas for potential 3D games I wanted to try, and with no experience in 3D game programming I decided to once again try out Unity, avoiding what made me quit so quickly when I tried earlier. No tutorials, no build-in scripts, just reading the documentation and asking small questions on twitter and skype, and after couple weeks of learning this was the result of my early experiments (WASD to move, Shift to run, space to jump, E to enter cars). It's nothing special, I got distracted writing shader code like I normally do in my projects, but I wrote it all (except the camera effects) without tutorials or sample code, and actually made SOMETHING in unity, and it felt good.
Fast forward to Februrary of this year, I decided to try prototyping a multiplayer game concept I had, and opened unity up once again to try and figure it out. Within a few days I had this, and a few days later it had working multiplayer. I got distracted by how fun the bombs were and just decided to make the entire game about bombs, and decided to make the entire game about that. The latest public build of that is here, and I occasionally test more recent builds with my twitter followers while working on making the game into a more finished (and commercially viable) product.
And here is where my criticisms of Unity begin. I want to make a FINISHED product, not just a prototype. Getting a playable, fun muliplayer prototype of this game up and running in less than a month was amazing and awesome, and I don't think there's another tool out there that can do it that well. For 2D there's Flash but that's just cause I used it for 10 years and are super comfortable with it. And I think there's a lot of value in this aspect of unity. But I've come to realize, while Unity makes 90% of the game take 10% of the time, it also makes 10% of the game take 90% of the time. This is somewhat true for most games anyway, but it feels really pronounced in Unity, especially if you have a strong attention to details.
There's a lot of "little things" that bother me in Unity, along with a few big ones. And when I complain about the little things, people's response is "oh that's just nitpicky", but they do add up! A minor annoyance here and a minor annoyance there and a couple hundred more of them and it starts to feel more than just minor. I've done my best to look up answers / workarounds to most of these problems and couldn't find many, so if there exists any feel free to tell me.
I LOVE being able to tweak public variables while the game is running. It's cool, it makes tweaking minor things really easy. But you can't save the tweaked values when you stop running the game, so you're forced to write down the values that feel right yourself.
I hate that unity doesn't auto-save. Well, it seems to partially auto-save. It saves the fact that I made a prefab named BLAH, but it doesn't save what that prefab is, or changes to the scene. So if it ever crashes, you sometimes end up with "broken" prefabs, and have to remake them from scratch again, and link them back into the scripts that needed them. This wouldn't be much of a problem since the program is stable enough except for...
I hate that it doesn't run the game in its own process. You write an infinite loop in code accidentally? Gotta force-quit UnityEditor.exe. And of course it didn't save. I've complained about this before on twitter and got a bunch of "dont write infinite loops lol" and "well blah blah can't work if its in its own process", and I don't really care, visual studio handles breaking code loops just fine when working in C++.
I hate that a lot of Unity's built in stuff is just black boxed entirely, which would be fine if it was all 100% perfect for release code, but there's so many little things and inconsistencies that aren't sufficient enough for me. Network.Instantiate is buffered but Network.Destroy isn't? There's no arbitrary vertex attribute parameter on dynamic meshes (went overboard with shaders again sorry)? 3D textures are supported but not 3D texture coordinates (had to use 2 sets of 2D coordinates and staple them together in the shader)? No easy way to access the shadow texture in a single-pass shader (I wanted a custom formula for how the lighting / shadow worked, no way to do it cause unity does multiple passes for their lighting, so I had to use a second camera to generate my own shadow texture)? No way to exactly stitch sounds together (PlayDelayed works, but they use float seconds instead of int samples, so it breaks if you're changing pitch around)? Particle Effects give you a huge variety of things to control in the editor, but almost none of them are exposed to the code? Built in "Plane" primitive is like 100 triangles instead of 2, and uses a Mesh Collider and there's no Plane Collider? Adjusting color of a specific material in the editor adjusts it for all objects that use that material, rather than just the specific object you want to be tinted (works fine if you do it through code though)?
No built in user-interface system? Yeah I know about the Asset Store and NGUI and they are awesome features, I am just annoyed that the built in user interface stuff is SO bad right now, you just CAN'T use it for a release project. After spending 1500$ on Unity Pro just to be told "go spend 100 more to get a usable user interface system" just feels kinda wrong. I know they're working on it, I've been told that a lot, and I'll be glad when it's finally in but since it's not here when I need it that doesn't really console me very well (and NGUI is still not as slick to use as an innately supported solution could be)
Asset Store is actually really cool and I've bought a few things from there.
I like how scriptable the editor is, though I have't written any editor scripts yet. I've seen people make some amazing use of this though on larger projects.
I like how it supports the browser for exporting, it's one of the main reasons I liked using Flash so much. Really easy to get feedback when people don't have to download something.
I like Physics.Raycast and Physics.OverlapSphere, and the Quaternion / Vector classes. I don't like that there doesn't seem to be a way to easily check "are these 2 colliders colliding?" in code.
Components are cool. I've used Components before but not in an engine with a visual editor like unity, and I hated it. But it works so well with unity's editor and prefab system backing it up. Would be nice to be able to reference prefabs by string and not have to stick public variables everywhere...
Sorry if this sounds like just a lot of bitching, almost all of these are issues you will never run into if you're just trying to make something work, but they add up over time. At least it does seem like Unity is addressing issues like this all the time with recent updates, and maybe all my problems with it will be gone within a few years, and that'd be great! I certainly don't regret choosing unity for Bombernauts, and the game probably wouldn't have happened without it (I've never done 3D OR Multiplayer before, and prototyped it in a week! It was an amazing learning tool!), but I don't know if I'll keep using it for future projects (and I almost certainly won't use it for 2D). As it is Bombernauts already uses mostly custom-written features, I think just the online and particle effects are still vanilla-unity. It was a gradual process replacing the built in stuff though, still appreciate the fact that they were there.
Oh I should probably mention C# too. I'm one of the few people out there who really really really likes C++ it seems, so there's a lot of things that annoy me in C# that just boil down to "it's not c++". I hate that there's no "friend" functions and classes (welp, just gonna make everything public then! wouldn't want "friends" making my code "bad"). And there's times where C# feels kinda slow (I'm the type of person who loved being able to just brute force things in c++ and optimize them later). But I like using Reflection, and I like get/set stuff, and I like how some weird syntaxes are improved in C# (int myarray instead of int myarray). And I don't like how I can't do transform.position += Vector3.up or similar, because transform.position won't let me do += on it for some reason. C# is probably one of the best language's I've used when it comes to getting stuff done, even though I still prefer c++ for large projects.
So yeah in conclusion "hey should I use unity?". I don't really know it's up to you. It's probably really really good if you're just getting started making games, since you probably won't (and really shouldn't) care so much about the small details when you're first starting out, and most of my problems with it are the small details. It's taking over the world though, and it feels like it will be really really really good in a few years, so there really shouldn't be any downsides in learning it.