Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
September 21, 2014
arrowPress Releases
September 21, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Some Ramblings about Unity
by Tyler Glaiel on 08/15/13 06:43:00 pm   Expert Blogs   Featured Blogs

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.


Related Jobs

Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[09.20.14]

Senior AI Engineer
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[09.20.14]

Lead Tools Engineer - Infinity Ward
Insomniac Games
Insomniac Games — Burbank , California, United States
[09.19.14]

Senior Engine Programmer
Fun Bits Interactive
Fun Bits Interactive — SEATTLE, Washington, United States
[09.19.14]

Senior Engine Programmer






Comments


Karl Schmidt
profile image
Thanks for sharing your experiences - I suspected that with a black-box engine you would end up hitting brick walls whenever you needed to change things a little bit here and there. Good to know ahead of time that it's great for making quick progress, but not the greatest for fine-tuning final overall behaviour.

Thomas Bowker
profile image
Thanks for the read, always good to see how more experienced people approach Unity.

I've been using Unity for the past two years and enjoy it quite a bit, though I have experience using other engines (or even trying to write my own), Unity is the only platform I actually have released games with. I like it mostly because it seems to be the best option for multi-platform. And the webplayer is super useful, as you said, to quickly put together something for people to mess around with without the hassle of downloading a file.

I agree with pretty much everything you mentioned, though Unity has (finally) put in a quad primitive in it's latest release so some of the issues you mentioned are already being fixed. And I understand why Unity doesn't do some of things you brought up, such as not being able to reference components by string because that would be slower that the alternatives (although in most cases an unnoticeable difference). Also not being able to easily determine if two colliders are touching, I think this is mainly because that's just how the physics engine works, by collision callbacks. I think there is a way to force a collider to re-calculate is collision anywhere but I haven't looked into it. Even after using Unity for two years there's still small things I pick up on here and there, best practices, etc.

Everyone should know how to criticise the engine or system they're using. I've encountered some pretty weird Unity-evangelists who can't seem to be able to do this. Being able to criticise the engine or system you're using is a clear tell you know what you're talking about and a useful habit to get into. It's important that these things are talked about in order to progress, cheers!

Jim McGinley
profile image
Ramblings about Unity indeed.

What's missing is a comparison. What's the alternative?
i.e. GUIs in C++, are there free libraries that put NGui to shame?
i.e. Collision detection in C++, what libraries do it better?
I'm actually very interested to know.

I would suggest that Year Walk, The Room, and Kentucky Route Zero prove that Unity is great for completing games that worry about small details.
https://unity3d.com/awards/2013

Tyler Glaiel
profile image
flash has an amazing UI system, its why so many games use scaleform for their UI. I know there's a unity build of scaleform but right now it doesn't work for broswer builds (AFAIK)


I never said the small details are impossible to polish in unity, there's just a huge amount of speedbumps

Jim McGinley
profile image
A huge amount of speedbumps compared to what...
Flash? Unreal? A homegrown engine in C++?
I'm unsure what you're recommending as an alternative.

Amir Barak
profile image
Yes, but if you look at most (if not all) engine sites you'll find numerous award-winning games written with that engine so it's not really a reason to use Unity over anything else that's on the market.

Collision detection in C++, em, I don't know, maybe you heard of PhysX, Havok, Box2d, Bullet...

Also, the bulk of Unity itself is written in C++, not C#.

I think in the end no general solution is ever going to be perfect, it depends on your needs, skills and tool-familiarity.

Jed Hubic
profile image
There doesn't have to be an alternative. I took this as an opinion piece. I don't think this is an argument you can win or lose.

Mike Weldon
profile image
This was a great read. It is not often that you get read about the downsides of Unity. Frankly if these are the only strikes against it, that's pretty good to me. I have experienced some of the same issues, particularly the poor UI system. I had to write my own wrapper and I don't really like how I had to do it. I greatly prefer C# to C++, though I really miss being able to enforce const correctness. Also I think you should take some time to explore the power of editor scripts.

Andrew Syfret
profile image
It's tough to know sometimes if there is a way to do something you want to do and you just don't know it, or if it's just not possible. I hate having to re-implement highly optimized collision detection functions in script but it seems sometimes necessary for pixel perfect implementations.

Amir Barak
profile image
I work with Unity quite a lot and I think it has more than a few downsides (for my personal projects I don't use it to be honest). Although it is a pretty good renderer and you'd be hard pressed to find a cross-platform deployment solution that's quite as alluring as its promises (of course write-once deploy-everywhere is a bit of a lie but it mostly works).

Yannos Soumis
profile image
Well, it is getting better all the time but I agree with you; right now the biggest strength of Unity is the amazingly fast prototyping.

If you aim for release quality (where you cannot overlook minor issues anymore) you hit a LOT of dead ends and you will have to custom code many things from scratch. If more parts gave source access it would be so much better.

edwin zeng
profile image
If you are doing procedural generation stuff, for sure, you wont be using Unity at all. You don't see Starbound, Minecraft, and all others in this genre use this engine at all. A black box engine cannot allow "hacking", which is essential to this genre.

Also, be aware that not all award winning games use Unity. Awards themselves can be subjective as not all award winning games make money. But based on my current observations, the games that make a lot of money don't use Unity at all. They all have their own custom-built engines, with custom features, and custom-optimizations. Which makes them stand out from the crowd, as they sail in the blue ocean, as opposed to those whom use black box engines and sail only in the red.

Rune Skovbo Johansen
profile image
You are kidding, right? Starbound doesn't happen to be made in Unity but Starforge is. Minecraft isn't but several Minecraft-clones are. Google a bit and you'll find plenty more examples. Or browse the Unity Asset Store a bit to see various voxel solutions (cube-based or smooth) or tile-kits, some with procedural functionality.

edwin zeng
profile image
My point is, if you want to make money in the procedural generation genre, you cannot use a black box solution. You must have the best flexibility for hacking.

We can certainly put Starforge as an exception, but that is not going to change the reality for this genre.

Rune Skovbo Johansen
profile image
Unity is surprisingly hackable; there is very little black box about it.

A Unity game I forgot to mention that pushes procedural generation to new heights is "Sir, You Are being Hunted" with its procedural British countrysides.

I think it's fair to say that these days, a large proportion of the games that pushes procedural generation forward are made in Unity. The statement "If you are doing procedural generation stuff, for sure, you wont be using Unity at all." is just plain false, because lots of people are doing it with great success.

edwin zeng
profile image
If you think its good to use it for procedural generation, then go ahead. But I wont be using it because Starbound, Cube World, etc don't use it. Its your own choice. But I did mention that sailing in the red ocean is a no go for me. If you think that you can sail in the blue ocean by using Unity and procedural generation, then thats good for you. But I prefer to follow the likes of Starbound, Cube World, etc, and build my own custom features. And sail in the blue ocean.

And why should I pay for Unity that cannot have all the technical features that Starbound has? If I have to pay for a system, I expect it to have everything from day one. And all I have to do is content, not research and development.

If I have to do my own research and development, then I would roll my own system and custom features. So as long as there is one piece of required research that is not already in Unity, it can be easily said that it cannot be used for procedural generation. And if its a patent, it gets worse, Unity can never have it.

On the flip side, I know that there is Voxel Farm. But not everyone can use nor afford it (if its expensive). Anyone with their own system can choose to integrate Voxel Farm directly. That is, if they think they should use it for a 3D procedural generation game. Or they can choose to follow the path of Starforge and use Unity with Voxel Farm, but can they be sure that their game will eventually sell well?

I happen to see it this way - If you cannot do better than eg Starbound, Cube World, Stonehearth, Castle Story, etc you must question yourself if Unity or any other engine has been getting in the way in the first place. Infrastructure is only one part of the solution. Never put the infrastructure first. Know what you want to achieve first is better than simply sink into one premade engine.

David Rico
profile image
As someone doing a very large game with lots of procedural generation in Unity, I don't really see how another engine could help you much more than Unity.

Unity is a general purpose engine. It has pieces and full systems you can tap into to do most things you want. I wrote my own culling system for my procedural worlds as Unity's Umbra only works for static pre-made environments. I have custom pathfinding solutions. I have my own procedural gen algorithm to generate everything.

But these are all things you can't expect an engine to do. This is all unique to your game. What engine out there gives you all the tools you need, while still keeping your game unique?

You can use UDK and reskin their example project and tweak the numbers if you want an engine you don't need to modify to fit your needs.

If you're going to be paving new ground, you're going to have to get your hands dirty with this sort of stuff. Whether you do it all yourself or use an engine as a starting point, all that changes is the amount of things you need to make from scratch. At least with Unity, I didn't have to write my own renderer, physics, and sound systems.

I have a ton of peeves and things I hate about Unity from working on a 1.5 year huge project with it, it's plain to me that Unity was made with smaller games in mind. But is it unusable for large projects? Hasn't stopped me yet.

Llaura Mcgee
profile image
There's an odd dichotomy in that being the most effective with Unity seems to take a different approach to code structure than typical game dev, but because of how open it all is you also need to have a lot of discipline probably learned from a more typical coding environment.

Luis Guimaraes
profile image
EDIT!!! read { as <

"Would be nice to be able to reference components by string and not have to stick public variables everywhere..."

You can find components with string, just it's slower and ghost-error prone, and leads/comes from bad architecture overall*:

(SomeComponent)GetComponent("SomeComponent")
(GetComponent("SomeComponent") as SomeComponent)

Faster and safer:

(SomeComponent)GetComponent(SomeComponent)
(GetComponent(SomeComponent) as SomeComponent)

So much Better:

GetComponent{SomeComponent}()
GetComponent{SomeComponent}()

And there's the so underrated Hierarchy, one of the best things in Unity:

GetComponentsInChildren{SomeComponent}()
parent.GetComponent{SomeComponent}()
root.GetComponent{SomeComponent}()

And other usefull stuff:

CameraManager.gameplayCamera
playerInput.OnPullTriggerDelegate += TryToShot

* all learned the hard way... :(

Anything else you can always hook your own .dll with it, write your own C# solution, or get from the Asset Store. But sure an open InputManager should be built-in.

Jason DuPertuis
profile image
The saving prefab thing, combined with no real version control, has been the biggest annoyance we've had with unity at my work. I do all the UI stuff (yeah, NGUI is pretty excellent) so I make prefabs up the wazoo, but if I got a proverbial penny every time a prefab would break for other people (missing links, empty prefabs, etc) after getting it from perforce...

Steven Liss
profile image
It's been a few months since I've Unityed much but I'm pretty sure that stems from not saving the "project". When you Ctrl+s it only saves the current scene. Before you update, you have to explicitly save the project by hitting File->Save Project. My guess is Unity is holding some new links you made in memory. Then you update, get someone elses links in the file and then Unity doesn't look and just stomps them when you acutally do save. Just my best guess.

Jason DuPertuis
profile image
Oh we know all too well about "save project". But even then sometimes it screws up coming out of perforce. Sometimes it's a simple problem like all meta files not be checked in, but sometimes it's just because. The only recovery is for someone to fix it back and check it back in.

Ryan Campbell
profile image
Those could easily be Preforce issues. I had issues in UE3 with with Preforce as well.

Joe E
profile image
Yeah I've had similar issues with Unity + Perforce integration.

Nooh Ha
profile image
Surprised nobody has mentioned Marmalade as an alternative. Not as user friendly in its current version but arguably more functional and definitely wider/better platform support...

Maurício Gomes
profile image
Marmalade suck, REALLY hard.

I bought it, and caused so much problems that we had to ask our money back.

Before it had the name Marmalade, it was reasonable, now it is just the result of executive infighting and money grabbing.

Pavel Bibergal
profile image
Marmalade is too buggy.

Steven Liss
profile image
20$ well spent. http://u3d.as/content/almost-logical-software/play-mode-persist/1
tS

But you could probably make this on your own in a few days.

Ferdinand Joseph Fernandez
profile image
Agree with most of the stuff here.

A few quick points, and this is for everyone using Unity, not just the author:

1. Use File > Save Project to actually save changes to prefabs, or when you make new prefabs, etc. This is because Unity likes to delay saving changes to prefabs until you close the editor.

2. In C#, you can probably do the equivalent of friend using interfaces (the same thing Java has, and I do believe is equivalent to Objective-C's protocols).

3. I wouldn't make public variables at all. I use the [SerializeField] attribute to force private variables to be exposed to Unity's inspector.

4. transform.position is like that because position is a Vector3, which is a struct. In .NET/Mono, structs are pass by value, so when you call transform.position, you're actually receiving a copy of the position values, not a "pointer" to it. Generally, you can't access structs by reference. At least, not in this scenario.

3. Materials are shared among its users to save on performance as I understand. An easy way to override for per-object would indeed be nice. Perhaps something similar to cascading style sheets (I had the same idea regarding prefabs). In code, materials are indeed overridden per object, unless you use renderer.sharedMaterial

4. Unity's new "Shuriken" particle system indeed has so much that are not exposed in script. It's quite dissapointing. I stick with the old legacy particle system. Its less user-friendly but indeed has more flexibility in code. For example, you can resize a particle emitter during runtime with the old system, whereas you can't (as of yet) with Shuriken.

The same goes for the new "Mecanim" animation system; its scripting interface is lacking compared to the old legacy animation system. As I understand it, once the scripting interface of the new systems are on par with the old systems, the old ones will be retired.

5. I wouldn't use the current built-in GUI system for anything other than prototyping.

6. The way I understand it, the built-in networking system is good only for a LAN setting (i.e. perhaps less than 10 players). I've heard from other users that use the built-in networking system that it just breaks down when a lot more players are connected. You can consider the alternatives (i.e. 3rd-party libraries) like Photon, uLink, or SmartFox. From what I heard, among the things Unity Technologies is improving in its engine, the built-in networking system isn't on the list.

Juan Mora
profile image
Good information, thanks for sharing.

It's a shame the [SerializeField] attribute is so little known among unity developers. I didn't know about it until very recently, tbh. Being forced to have so many public variables was my biggest complaint about unity scripting, but this attribute solves the problem completely.

About materials, objects sharing the same material (which implies they have the same values on all shader parameters) are eligible to be rendered together, which is a very important rendering cpu optimization (objects are "batched" together and drawn in a single "draw call"). That's why unity doesn't like to create a duplicate of the material when you edit a value on it on an object. Instead, you have to create a duplicate manually if you really want it (and be aware of the performance implications). Nonetheless, an override option would be cool, indeed.

Also important, when accessing materials from script, the first time you access renderer.material on a given renderer, unity creates a duplicate of said material and sets it on the renderer (at that moment, you can even see how the material is renamed as a duplicate in the inspector). This, of course, would break the "batching" optimization, so you should always use instead renderer.sharedMaterial, unless you actually want a material duplicate. For instance, you need a duplicate if you want to modify a material value on one specific object in your scene.

Samuel Batista
profile image
I would recommend those turned off by Unity's prefab and asset management system to look at the Wave Engine. It's a new engine written in C# that also uses a component system, but it's more friendly for 2D game development (has a sprite batch renderer like XNA), and it's completely free, at least for now...

http://www.waveengine.net/

Kujel s
profile image
Thanks for sharing, I'll at least check it out.

Vicente Cartas Espinel
profile image
Wave Engine team member here :)

Thanks for the kind words about the engine. And about the pricing we don't have any plans to charge for Wave. Regards!

Adrian Hall
profile image
I've been working on a Unity project which uses NOTHING BUT the GUI functions for rendering (long story). I know that they are bad, but it's been so long since I started using them that I actually don't remember why anymore. I'd be curious to hear what exactly people hate about them these days.

Really good read!

[User Banned]
profile image
This user violated Gamasutra’s Comment Guidelines and has been banned.

Jeremy Alessi
profile image
Unity is like a great game, easy to play but difficult to master.

The criticisms here are easily dealt with by developing best practices. I've been using Unity for 6 years. There's never been anything I wanted to do with it that I couldn't. Each year that I use it I discover some new untapped potential.

Finally, the Unity team is always making the tool better. To have them on your "team" is a gift. At times maybe they lag behind the desire for a certain feature but usually it's not long enough to make a tangible difference. If you follow the Unity tech curve, you're still way ahead of most.

Kujel s
profile image
I once considered unity but never really got around to checking it out. Anyway I have a lot of respect for Unity and the team behind it but I'm perfectly happy using the engine I wrote for my games, I know what it can and can't do and it's perfct for 2D games (the type I prefer to make).

I do hope Unity continues on the way it has because I keep hearing it's a really solid engine and and I've played a few very good games made with it.

Ted Brown
profile image
TO SAVE RUN-TIME CHANGES to a component, you can right-click on the component and copy its values. After stopping the game, right-click on the component and paste the values.

(sorry for the all caps, if it gets your attention and saves your bacon it's worth it, right? :D )

I agreed this was a huge annoyance in the past, but they addressed it.

Ashkan Saeedi Mazdeh
profile image
Unity is a great engine and i've used it from 2.5 version but as you said and well said is not empty of problems. Well no software system is like that. In fact when it comes to workflow for multiplayer games it's really lacking a lot.
The build system is really limited in coding (it's getting better but not great) for example you can not pass defines to the compiler in code but you can do in editor.

fonts are exposed to script in 4.x version!!!
I think i'll write a similar post from another point of view.

But there are many great things about it as well.

Brett M
profile image
At least some of the limitations force habitual engine makers to make a game instead of tinkering with their custom engine for years (whilst pretending they're making a game).

Luiz Alvarez
profile image
You can do transform.position += Vector3.up, what you can't do is transform.position.y += 1.

This happens because "position" is a property (not a field) that gets/sets a struct, a Vector3 in the case, that is passed by value. The first one would translate to:
transform.set_position(transform.get_position() + Vector3.up)
while the second would be:
transform.get_position().y = transform.get_position().y + 1
which doesnt make much sense.

Tyler Glaiel
profile image
knowing the technical limitations for why something doesn't work doesn't make it less frustrating

Luiz Alvarez
profile image
For sure. I used to run into this until I got used to these Vetor3.up, Vector3.back, etc

Samuel Rivello
profile image
Great discussion. You've done the hard work, using and critiquing the Unity3D tool. A fantastic follow-up would be to list all of your criticisms as feedback so you contribute to the solution to the problems, so that your readers can vote on the items about which you are most passionate, and so the tool is improved for all users.

http://feedback.unity3d.com/unity/all-categories/1/hot/active

Ian Morrison
profile image
My own experience with Unity is that you really have to think a bit differently to take advantage of the architecture and the specific ways Unity wants you to use GameObjects and components. Once you've become familiar with their brand of moon logic, the documentation and design is really easy to follow.

Of course, it's still missing some major features. One of the biggest from my perspective is the lack of a built-in graphical shader editor like UDK (though there are third party solutions I haven't tried that do this, apparently quite well). I hardly mind writing shaders by hand (especially with helpers like the Unity surface shader system around) but it leads to the odd situation where I have UDK on my machine to prototype and experiment with my shaders, and then re-implement them in Unity.

The other major thing I miss from UDK is something akin to Matinee. Unity has an animation system, but it's not something you'd really want to use for cinematics OR for character animation, sadly.

For me, the bottom line is that Unity is incredibly solid with a forgiving workflow (and the best prototyping tool I've ever used) but it's missing a lot of high end features, whereas UDK has a lot of high end features and tools but is substantially less flexible and has a workflow that is, on occasion, pretty painful.

Eric Boosman
profile image
A couple other super useful and time-saving plugins from the asset store:

Killer Waves: https://www.assetstore.unity3d.com/#/content/6640 - a massively flexible spawning system for enemies, enemy waves, pooled prefab objects, coins, bullets, etc., including built in variable tracking and tweaking right from the inspector. This will absolutely save you time.

Master Audio: https://www.assetstore.unity3d.com/#/content/5607 - The most fully featured audio system available for Unity, with the most refined & streamlined UI and workflow. Seamless sample crossfading, weighted sound pooling, and it's the only plugin that features complete native audio filter support for things like reverb, etc.

I'm biased, being that these are made by my studio, but our user reviews tell the story, and you can rely on fanatical user support and constant upgrades. There are trial versions available for both, as well, if you want to check out core functionality and workflow.

It's safe to say we're fans of Unity.

Carter Gabriel
profile image
Thank you for this article.

To note, the new GUI system is pretty awesome (at least so far, I am impressed. I never used NGUI or anything else, and the old GUI was horrendous. This new one seems pretty great.)

However, all those tiny bugs are still prevailent.

Unity can't even render 2D correctly. Rendering is the most important aspect of any game engine. To have rendering flaws is just insanity. All new features are filled with tiny bugs, that although are not game-breaking, are UNACCEPTABLE for a polished release.

I'm talking about sub-pixel rendering issues which boggle the mind (sometimes to get correct pixel rendering, you have to offset gameobjects randomly. GameObject#1 & #2 will need to be offset by 0.5, while #3 & #4 can't be offset. It seems entirely random. Then there are problems with the 2D animation system, where once an animation loops a set amount of time, it will decide to transition randomly before correcting itself- more bugs. I was even involved in bringing attention to rendering flaws, getting Unity dev acknowledgement that they will be fixed (which they were). Yet to even have the flaw in the first place? So unacceptable. Yet similar flaws still remain, even if they are barely noticeable to most users. These tiny things add up, especially to my frustration. How many times can I facepalm in one week?

Asset Store assets seem to have less bugs, but are not prone to bugs. Some of them are god-awful, but some of them are good. Still, they do not fulfill development goals like a custom made game tool would.
Not to mention that sometimes it takes a long time to learn the asset and the asset developer's perspective. All that time could have went into building your own (better) tool in your own engine. Once again a trade-off which is great for prototypes but very inefficient for real games.

I have never been stuck for very long while programming (creating my own code). I however constantly will find myself pulling my hair out, endlessly frustrating, having wasted 3-9 hours trying to fix someone else's bug. It is even worse when you spend so much time thinking you didn't learn to use the tool (Unity, Asset Store plugin) right, but eventually find out it's a bug and you just helped them fix it! -_-
I've done this trying to fix bugs in asset store content and unity itself. It is not fun dealing with other's code (asset store stuff), but especially when you can't see it (unity).

It is just more enjoyable, fulfilling, and just plain more FUN to program than to...well...not program. Even the most complex scripts I created in Unity, is not real programming. It's all very simple scripts. This is a plus to some, but IMO a real snore-fest and very unfulfilling. You don't feel like you accomplished anything, because you had such a large crutch and had to find crazy workarounds to solve problems in the laziest way possible.

At least when there are tiny flaws in your own engine, you can do something to fix them.


none
 
Comment: