I began using Unity a bit more than 18 months ago and decided to do a little write-up of what I consider Unity’s strengths and weaknesses.
My background is that of a professional software developer who has bought into the Test-First and Continuous Integration ideology, so I imagine some of the things I perceive as weaknesses may not even bother others
Yes, there’s something wrong with your terrain; the entire point of the terrain system is to batch large numbers of objects into (relatively) few draw calls.
What in Mathf uses degrees? It’s all radians as far as I know.
Time.deltaTime doesn’t really need to be anything other than a float, since it’s just the time since the previous frame. (But yes, it would be nice if Time.time was a double.)
Regarding all your other points (especially terrains) I really do agree. I feel that terrain rendering is pretty bad at this point in time and could be substantially improved in both workflow and performance. But I don’t feel the need to hassle Unity over it and will eventually probably end up using it regardless as the alternatives are even greater timesinks. And timesinks are something I have to avoid where possible.
But yes, I believe there is a lot of room for improvement in terrains when compared to competing engines.
Must be something wrong with my tests as well, since it tends to explode whenever you want something remotely detailed.
I’ve been looking into 1) for several weeks now, but I’ll do some more tests (disable wind, have all detail meshes in uniform scale, not use the “nature” shaders and so on). I hope I can figure it out.
In 2), it’s about things like Quaternion.RotateTowards(), Quaternion.Angle(), Quaternion.AngleAxis(), Quaternion.Euler() - there were originally methods using radians, but they’ve been deprecated in favor of degree-using replacements.
For 3) I’m happy with Time.deltaTime being float, but I’m worried that it may be calculated based on Time.time (eg. query performance counter, scale down to float, subtract previous Time.time value → Time.deltaTime would have the same loss of precision). If that’s not the case, then all is fine since all I’m ever using Time.time for is timed triggers were I don’t care about +/- 10 milliseconds.
I hope my blog post doesn’t come across like I’m ranting or trying to hassle anyone either. I just tried to write up a small opinion piece about what I liked so far and what I didn’t
If feel that had I picked UDK or CryEngine instead, I’d likely have a longer list of itches. And that with the OpenSource engines out there I wouldn’t even have a working prototype of my game yet
It’s good value. If you’re small, or you don’t have a large income stream. It’s always going to be better value in this respect.
You do develop faster in it*
It has wide support and C# is just a very lovely thing.
Well supported, excellent cross platform reach.
Things I really wouldn’t choose Unity for at the time of writing:
Large Open world games.
Ingame streaming from disc of any kind.
Speed - it’s terrains are a bit too slow. It can be optimised in a lot of places.
Collaboration - I would find it very hard to hire a reliable programmer and artist vs Unreal Engine.
You develop faster in it by far, providing you don’t need anything that Unity doesn’t support out of the box. If you’re sure you’re happy with what Unity does, it is absolutely unmatched in development speed.
But Unity is evolving and that is why I still remain a steadfast supporter. I have come to know some of the staff at Unity, and I like them a lot. They’re a good hard-working crowd of people and they’re not unapproachable.
I found that Unity’s ‘Input’ class already deals with this: if a German user presses the Y key (Y and Z have traded places on German keyboards), Unity will still report KeyCode.Y being pressed (i.e. KeyCodes aren’t scancodes). So a simple ‘pressedKeyCode.ToString()’ provides a reasonable name (even for cyrillic and far east keyboards: Russian keyboard / Japanese keyboard)
The alternative would be to create a translation table from Unity’s KeyCodes to Windows’ VK_ codes, call MapVirtualKeyEx() with MAPVK_TO_VSC_EX and then GetKeyNameText(). On OSX, mess with UCKeyboardLayout and on Linux mess with keycode_to_keysym() and XKeysymToString().
