It feels like Unity is constantly putting up roadblocks

Hi everyone, I've had this account for a number of years (back when they gave out non-pro licenses for free for version 3.5 or something) but I'm still a novice in Unity.

This is mostly because I didn't really use Unity at all until recently and had a pretty nice starting experience.
But as soon as I got semi-serious Unity started to show one big glaring flaw: it doesn't really offer much of anything to help you make a game.
Sure it makes it easy to haphazardly throw around some objects in a scene and mess around with them but that's about it.

Let's be upfront, i'm primarily a C++ programmer (with some experience in other languages, including C#), so it's probably my mindset.

My biggest problem is that I came into Unity expecting a sort of Delphi or Visual Studio for game creation only to discover Unity is pretty much what Macromedia Director was back in its day.

Also a few things really grated me (there are more, but I don't want to start a flame war):

• That Coroutines exist as actual coroutines - I've seen first-hand just how badly they can be abused. You know, really bad, like the works:
  Code (CSharp):

  1. while(condition){
  2.     //do stuff that really, should be in its own thread or in an update function
  3.     yield();
  4. }
• Maybe I haven't figured it out but there seems to be no way to programatically create / configure Animation Controllers object instance ? In fact a lot of objects and properties can only be accessed/modified through the GUI.
• The fact that methods like float GetFloat(String) & void SetFloat(String, float) actually exist to get and set properties defined in the editor. This is C#, you can extend classes here; there should be no need for stuff like this, right?
  
  Anyway, for all its shortcomings Unity also seems like a genuinely useful tool (I mean THERE ARE literally a ton of games made in it) and I wouldn't exactly like to give up on it after only 3 weeks of tinkering around.
  
  So given my background as a coder who prefers having some access to the application flow, could I find some resources to help me (maybe even change perspective) and start getting somewhat productive in Unity?
  
  Right now it seems the flow is basically: mess around for 5 minutes in the editor, write 10-20 lines of code, mess another 10 minutes in the editor, etc.

 

I'm sorry, I'm not sure what the problem is. That you can abuse coroutines? Then... just don't do that?

And also I'm not really sure what you want to do with the animator controller, but I assume you looked through the API? http://docs.unity3d.com/ScriptRefer...ontroller.CreateAnimatorControllerAtPath.html

 

I don't understand why some developers spend 5-10 minutes in the editor and then just 10-20 lines of code in Visual Studio. I usually spend 10-20 minutes in VS kicking out 10-50 lines of code and then just using the editor to launch the game for playtesting. Do people really put a lot of things in their scene after initial setup?

EDIT:
I never really use the editor for editing, but more as a great visual debugger.

 

On Coroutines: don't use them. I (almost) never do. They are a crutch that make it very easy to do certain kinds of things, but like you, I feel they're often abused (or at least, used in cases where other approaches seem simpler/clearer to my mind).

Your other beefs appear to be all related to the Animation Controller. I have quite a few beefs with that myself, but you might be amazed how many of my games have no need for it. There is a vast world of video games out there that don't have 3D animated humanoid characters running around and jumping over things.

In the 2D world, you can do with or without Animation Controller; and even if you choose to use it, you can use it in what I think of as "lite" mode or you can go all-in. Check out my article on 2D Animation Methods in Unity; as a coder, I think you'll find it quite enlightening.

 

I didn't mean to be rude but tell that to those who abuse coroutine primitives.
Again I've seen my fair share of language feature abuse in both commercial and open-source applications. You either educate your language "userbase" (the coders) not to be smart-asses OR you simply don't allow the feature.

Looks like http://docs.unity3d.com/ScriptReference/Animations.AnimatorController.html is sort of what I was looking for, but I had hoped that you could create an AnimatorController as an object in-place not as an asset.

From what I've seen of the docs, that's how they teach it. I haven't really had the time to try out alternate ways of doing it.
I'm sure you could, possibly, create a dummy scene, dummy object & script and go wild from there but there's not much documentation on doing it this way.

Heck, I've seen unity games that import ms3d, x, md2, mmd? and other "esoteric" (as in not fbx) files but don't yet have enough experience in Unity to write my own importer and don't feel like doling out $$$ for plugins just yet (given Unity is still unproven to me as of now).

Wow that article was pretty eye-opening for me. At a glance I also agree with your conclusion that the second approach is probably the best for moderately complex 2D games. That third approach tho . Pardon my french but holy ****! I don't even want to think how that graph would look for a moderately complex 3d character (as in walk, run, crouch, jump, grab edge, melee).

Then again it proves that a solution to the problem is still up in the air. Perhaps it's time to re-think and maybe innovate. But I'm really getting ahead of myself here.

Also from your article:

Doesn't Unity have a facility to allow manual posing of bones? At worst someone could create some helper functions to play & blend animations by hand.

 

What's wrong with Unity's decision to give us actual coroutines? I could easily understand if this were a game creation suite intended entirely for beginning developers but it's intended for professionals just as much as everyone else. If anything I would be less inclined to use Unity if it treated me as someone who didn't know any better.

 

Of course, "bones" are just transforms (which, combined with a SkinnedMeshRenderer, allow for bone-based mesh deformation). You can position them manually however you wish. See the ootii Bone Controller for an example of an asset that does some very interesting & useful things with bones, quite separate from (though compatible with) Unity's animation components.

But at that point you are not playing a modern Unity (i.e. Mecanim) animation. The point of that part of the article was just that: if you want to play such an animation (for example, because you have bought mocap animations from Mixamo), an Animation Controller is the only way to do it. I don't think the data format of these animations is open. But of course I could be mistaken.

 

*Mind blown*

What the heck do you use then when you need to do stuff over time? Especially when you need to do something when it finishes? Somehow Lerp everything, and do constant checks on status flags?

 

I don't use them either. I use timers, states, the classic stuff. It's not slower and the upkeep code wise is the same as coroutines because you'll need to have a healthy amount of attention on making sure these things don't get tangled in larger games.

A complex big game can just have coroutine nightmares, and frankly I don't think it's worth pumping allocations and getting the garbage collector to throw a strop for the few cases I need coroutines.

I do miss being able to chain things when other things finish, but I can live without it using a silly old switch.

 

Yeah in some cases coroutines can be really nice but when you use them in large quantities at the same time then you'll start seeing the profiler complain about them.

I'm not an expert on them but IMO it depends on the situation. I still use them because where I have them is easy to read and maintain but if I needed to scale them up I might start to reconsider and opt for timers and switches... Although, that's a pretty different structure to design so its probably something worth testing up front to avoid a possible redesign later.

 

To do stuff over time, I use the Update method. There is no more or less Lerping in this case than when doing it in a coroutine. Nor is there any particular difficulty doing something else when whatever-it-is finishes.

I don't want to hijack this thread, but if you want to start a new thread, maybe we could take a few specific cases and compare different approaches (coroutines vs. Update).

 

I tried to make thread about this some time ago, but ended up being trolled at.

 

re coroutines: I mostly use them for WWW stuff, because they are like asynchronous HTTP calls.

Back to the OP: Maybe you should checkout my book Unity in Action? I'm a professional game programmer who uses Unity at work, and I wrote the book to teach Unity to people who already know how to program.

 

I don't think he needs to buy a book lol.

 

*shrug* He said he's an experienced programmer having trouble getting to grips with Unity; that's the target audience for my book.

I mean, he did ask:

 

Coroutines, at least the "classical" ones, (and please correct me if I'm wrong) were basically invented as a crutch to allow multitasking back in the 16-bit era of computing (Win 3.1, Win 95).

They're not completely useless nowadays and can still be used for things like message pumps, event schedulers (esp. in thread-unsafe environments) or pipes (an example for C is libevent, or heck unix sockets), but the important thing here is that coroutines are not threads, and they are definitely not asynchronous.

Code (CSharp):

1.  
2. Threads:
3. main.............................done(http)---->return 0
4.           http....................^
5. vs
6. Coroutines:
7. main...http...main...http...main...done(http)...return 0
8.  

From what I read in the docs Coroutines act like this in Unity as well.

Also in C/C++ coroutines can mess up your stack if you're not careful, but I doubt this is an issue in C#.

Maybe I shouldn't have complained about coroutines, as it seems to have started a little conflict.

As for working with Unity, yeah it's definitely not a "classic" engine where you'd get free control over (mostly) everything.

It looks like the brute force, "bang your head against it till it cracks" won't work here.
I'll just have to try and get used to it by doing some more simple prototyping with primitives and if it works out well enough, look into importing animated models and custom assets.

 

I had to use coroutines to fix specific bugs in my code. First had to do with a Google Play login timing issue, and the second was a RenderTexture issue. Essentially, I needed to wait for the frame to render before issuing the RenderTexture's application, and WaitForEndOfFrame() was the perfect yield instruction to work with a coroutine to get this working properly.

So my experience: Use coroutines if you absolutely need them, but you should strive to find a better solution.

 

I still don't understand what your problem is.

After a topic subject of "It feels like Unity is constantly putting up roadblocks", I would expect something other than

1. Other people can write bad code, oh no!
2. I can't do something that I actually sorta can, I just haven't read through the Api enough.
3. Something completely arbitrary and nitpick-y.

 

@AcidArrow, it's clear the OP was feeling frustrated and wanted to vent a bit. Let's not jump down his throat for that. It may even be useful for the Unity designers to see how newcomers react to the product, regardless of whether or not those reactions turn out to reveal deep flaws.

 

Yeah, you're probably right. Maybe it's not Unity putting up roadblocks. Hell, maybe I really am a bit dumber than average.
It just feels kinda frustrating to kinda-sorta have the experience necessary behind you (I have some experience in pretty much all areas needed to make a game, well except making music, and I'm currently working as a coder) but never managing to adjust to a tool or process that streamlines all the damn boilerplate.

Based on what I read and saw from other developers' experience, I was REALLY hoping Unity would be "the one".

As a side-note the last time i managed to actually complete (as in menu to credits) a game project was somewhere in 2011.

 

I'm not jumping at his throat, I'm trying to make him provide clearer answers about what his problems with Unity are, so that we can suggest workarounds. There are a ton of legitimate reasons to be frustrated with Unity and it's clear he's frustrated, I just don't know... why?

 

Well, I have some good news, at least for myself: It clicked, I finally managed to import an older model
and get some code running.
I kept thinking and realized that you can use blender as a "middleware" of sorts to get convert ms3d models to fbx. It's primitive... but it works! After that it simply clicked and in no time I animated the model. The camera code wasn't written on the spot. Looks like venting here actually got me fired up!



I'm gonna take a 5 minute break now and see where I can go from there.
EDIT: On second thought It's 1:45AM here so.... yeah

 

To be honest, it seems to me that you're actually making a problem of things that aren't a problem

Have the things you've listed caused you problems? It seems that your concerned that some things may cause you problems at some point.

I'd suggest just jump in and see if these things really have any impact of your ability to use Unity to create you next awesome game!

Everyone has 2c, that's mine

 

Lots of programmers coming from outside of Unity go through the same struggles. To get the most out of Unity you do have to give up some control of the things you got to do on your own previously.

 

I'm already beginning to discover this in my first month of Unity usage. I rewrote several classes a few times in different ways as a programming exercise, and found that everywhere I thought I needed a Coroutine I was basically just wrong and I didn't.

I would be interested in what their most common justified use cases are in Unity.

Most people who are advanced programmers seem frustrated with Unity building too many bridges for them, I feel great in it's middle ground since I can handle OOP & general logic structures but I couldn't realistically do stack/heap memory management / GC myself; though I'm conscious of the issue and try to do stuff like use references where it makes sense to.

 

Randomly wandering off topic.

The coroutines is an interesting one. I personally use them a lot. Some of my classes are just made of coroutines. I even wote about them in my blog.

So here are some of my use cases.

As timers. This is probably the most obvious use case for a coroutine. Let unity deal with scheduling future events.

To invoke a task on FixedUpdate or LateUpdate. There is just this one thing that needs to be done on the FixedUpdate cycle. Coroutines help out here.

As a FSM. By definition a single instance of a coroutine is a FSM. So for simple, linear FSMs, using a coroutine often beats out a more complicated structure.

Avoiding Update. Often a value needs to be polled every frame for only a short portion of an objects life. Using a coroutine can be superior to Update in these circumstances.

A less frequent Update. Sometimes you need things to update at something other then the frequency of Update or FixedUpdate.

Waiting for threads. Sure you can do call backs, but then you have to jump through hoops to get back into the main thread. Sometimes simply yielding until an asynchronous call is done is the best way.

As a threading substitute. Sure, sometimes threads are appropriate for long running tasks. But what if you are using the Unity API? A coroutine can be great for splitting tasks like terrain generation, ray casting, particle collisions ect over multiple frames.

Almost every single one of these tasks can be done without a coroutine. But that doesn't make coroutines bad, often they are quicker to write and have less boilerplate code.

There are plenty of traps to run into with coroutines. But that is the same with any powerful language feature.

 

I see, singleton-style my AI and let it process every 10-30ms using a Coroutine. I'm going to do this tonight I think.

I thought I wasn't going to be able to handle 100-200 simple fairly low poly skinned mesh renderers but it's looking very doable as long as you don't make some mistakes like running their AI in update/fixedupdate and not using projector-based blob shadows.

 

Unity is written in C++, C# is just the language exposed as the scriptable interface

 

I believe he's referring to coroutines outside of Unity since Windows prior to 95 and Mac OS prior to X were based around cooperative multitasking (which is basically OS-level coroutines) rather than the preemtive multitasking that we see now.

Weirdly enough there is one operating system in active development that still uses it.

https://en.wikipedia.org/wiki/RISC_OS

 

Probally if your spending more time coding, and less time in the editor, it's a good indication that your game will be very dynamic and interesting to play. You put things in the the game through the editor, and then spend time to write code to move and rotate them, let the player interact with the environment is a good thing.
I would say 70% percent of my work is actually coding, and only maybe 30% of editor usage.

 

Ahh, yea that makes sense.

The problem with Unity (and I'm an expert...like Lecture, run code camps, been published, define the next version of .net expert) is that it's NOT OOP, it's very functional by nature. True OOP have a lot of trouble with it because it breaks encapsulation and separation of concern rules and forces you into a functional flow model and style of programming a lot.

Now if you're a disciplined developer and setup your projects correctly, lay groundwork and frameworks and abstract what Unity's doing into wrappers for your own OO styles, then it gets a lot easier, but that level of C# architecture isn't that common.

 

I have a lot of trouble with semantics because my formal education is lacking and sparse. it's there though, like I know my AI isn't OOP and could be, but it doesn't really need to be either. No point losing your S*** to modularize everything when you're working alone I guess.

This, so much. This is true regardless of the engine though. My code keeps getting shorter but each iteration does more than the last.

 

OO and modular aren't the same, but as long as you're happy with the work your doing, and your iterating into more maintainable code, rather than less...you're on the right track.