Coroutines are not magic

Wow, have we been reading the same thread? Most people seem to agree with the OP and then go on to elaborate in which instances using one or the other makes more sense for them. It's actually quite interesting reading, you're the one who seems to be stirring up trouble.

 

:/

That's a creative way of viewing arguing over minutia.

 

I didn't view it as arguing, rather a discussion. If the OP just wants to state his opinion without an evolving discussion (sometimes those wander off and don't comply 100% with the thread title) he should write a blog post or something, forums are for discussion.

But yeah, my post is actually way of topic, so sorry about that.

 

While that's a fantastic opinion, it is an opinion. You view arguing as civil discussion and civil discussion as causing trouble and you obviously feel that 99% of the things posted on forums should be on blog posts. Okay, great. Have a nice night.

 

Actually in that quote from me I was directly addressing issues raised by this guy:

Recognise him? He was then echo'd by this guy:

So I concur with Tanel and ask you to please stop associating me with your 'better' or 'best' argument.

 

Can we please go back to discussing the trade-offs of coroutine use? As that actually provided a good, useful discussion, unlike what is now occurring.

 

There's no trade-off that I can see. Coroutines are a convenient way to automate something. I think your code flow can benefit from it if you like sugar, but if you're a procedural guy you're going to prefer method calls with iterators (that sounds better to me, but I'm biased).

I don't think it's necessary to create analogies, here, to understand this stuff. Sometimes there's a fancy tool and a simple tool... neither is better. And you don't have to pick one or the other. In fact, you should make use of everything in concert.

There, now you can go back to "discussing".

 

If anything, the biggest trade-off with using Coroutines over Update is the fact that it's a bit more difficult to manage the order that each Coroutine executes code as opposed to Script Execution order for Update (and FixedUpdate? And LateUpdate?)

You cant execute a bunch of Coroutines from different Monobehaviours and expect Script Execution order to have an effect on which one's MoveNext is called first. You can manage the order of Update calls between scripts.

However, it is much easier to queue actions done by using Coroutines and yielding to other Coroutines executing. It's very difficult to try to do this dynamically between different Monobehaviors through Updates unless you're using events or monitoring the status of something occurring, which can cause a lot of bloat-code very easily.

I guess these are hardly trade-offs as much as they are just preferences for achieving similar logic.

 

^ this ^ is answered by v this v

I like coding my own delays into everything.

Wait until it's finished WWW has an isDone property to check. It's even got a progress property to check haha. For other things, you can check the resource itself. Is it null? then only continue execution of code that doesn't depend on that. Or if this is for loading your initial resources, just keep track of your resources. I've been doing that since AS in flash! Have an int to track your resources, increment it each time a resource finishes, and have your main Update loop just run something like

Code (CSharp):

1. void Update()
2. {
3.     if(resource_count < total_resources)
4.     {
5.         return;
6.     }
7.  
8.     runProgramNormally();
9. }

I've got a utility class I use across my projects to handle stuff like this.

--edit

I see discussion about update execution & multiple monobehaviors with update functions. That is indeed quite the pickle. So....

1) make an object called "game" or "main" in your scene
2) put a monobehavior on it that has an update loop
3) rename all other update loops to something class specific, ie "playerUpdate()"
4) call them in your preferred, predictable order from the main Update loop

I've even got it to the point where instead of having objects with monobehaviors, I've got scripts created by the main script that then proceed to create their bodies. One main to rule them all!

 

My two cents...
While I agree that many people do not use coroutines properly, the reality is that if the minor additional cost of using a few coroutines as though they were built-in Update functions is enough to kill your app's usability, then you've got far more serious issues with your code structure in general.

 

...so much debate over nothing.

 

You're just jealous

 

Yes I am jealous, if I had this kind of time I could rule the world

 

Ruling the world is pointless. It can't make you defy physics, even if your people are as gullible as *North Koreans.

*Some people don't leave even when given the chance because they believe the dictator is actually a god who can harm them after they leave (source: documentary and or interview with someone who fled)

--edit

That was easy to find. Sadness.

 

Enumerating/iterating within a method call is not comparable to what a coroutine actually does/is. You cannot reasonably achieve the actions of a coroutine in this manner without essentially writing the underlying coroutine logic itself which begs the question of how you could be more efficient about such a task without access to low level efficiency that the internals of Unity are provided.

Edit: Yes you can write code that executes every n seconds in an Update loop but that is the sort of project one should file in the circular file after finishing.

A coroutine can assure computation occurs on the main thread every n seconds. Internally, one can conjecture, that Unity steps forward on the enumerable the actual function returns, calling it, viewing it's yield and re-registering it internally so that it is invoked in the future approximately when it should be (An interesting question I think is how they preserve the stack of what is executing; that doesn't seem obvious to me). This is, in contradiction, to completely blocking the main thread for the full duration of the iteration/enumeration of something in a single go.

A coroutine and what you've described cannot be compared like that directly as they do not provide the same control flow. Coroutines are essentially async-like operations that are synchronous with the main thread yet only periodically block the main thread.

Edit: In response to the original post, I agree. There is no reason to use a coroutine unless you have to do lengthy computation that does not necessarily have to complete for the game to continue without blocking the main thread.

Edit: It is surprising that a use I describe above is recommended against even though technically, at a reduced level, handling states is an application of the above. Preforming an action over a given time period while in a state.

 

Go program a game, already! How much useless tech talk can I possibly be expected to be subject to?

I am finally getting my pizza.

 

Pic in the event of an edit: http://puu.sh/d5Kdt/64697aac6a.png

I find it surprising that your posts like that, of which have garnered you over 100 posts in the past couple weeks, which range from nonconstructive to trolling has not led to an infraction on the forums.

 

You actually think I would edit my post to hide what I wrote?

 

I'm not entirely sure what you're talking about... but you do realize that coroutines aren't particularly hard to implement?

 

No you're right this place would just be one big party with nothing but people like you. Anyone with any shred of personality or sense of humor must instantaneously be removed for being disruptive.

 

I'm aware but what purpose would be implementing them when they already exist? It would be egotistical to think that another implementation would have the same level of abstraction AND efficiency compared to what is already offered. Surely I'm sure it can be done and possibly made to work just as efficiently if not more, maybe, but the abstraction would be difficult to achieve imo and the gained efficiency would be paid in abstraction. Unity itself is in the better position to fill that order.

Edit: the context of that part of my post @npsf3000 is best understood after reading the post it's a response to.

 

A forum where people respond to questions, provide information to the best of their insights without posting about pizza in multiple threads isn't mutually exclusive with having a forum with personalities and humor.

 

Just how much do you stalk me bro

 

Thankfully you do not frequent the forum I try to contribute to most however, nobody has to stalk you to be subject to your posts as you post several times a page in nearly all active threads I've visited in the past few weeks.

But this is completely offtopic. As was your conversation about pizza. It has nothing to do with coroutines.

Edit: And your intentional misquote.

 

Let the mods decide, I'm 100% o.k. with whatever they decide.

 

Wheels aren't particularly hard to make, either. I still go to my auto dealer when I need a new one, though.

 

for F***s sake, just act your ages guys.

 

That's quite a jump. It's not hard to make the rubber with the proper patterns on the wheels to handle different kinds of terrain and keep friction on wet surfaces? I disagree

The unrelated part of your posts are usually their own little section after making a point. I doubt a mod or anyone free of certain social issues would be bothered by this.

...from whom did you order that pizza?

mod-san said'd a swear!

 

Sorry... ;_;

My 2 year old is rubbing off on me

 

Swearing is effective among adults if it's said in a certain tone that's with a sigh of exasperation, it conveys a bro feeling that other adults fully understand

 

I have to say it definitely communicates a lot more to me if you just say the f word, then words like "infarction"

 

I believe you are talking about a tyre. A wheel, in its simplest form, is simply a thing you can roll. Which is kind of the point - even though it's not rocket science it'd be harder to do than just getting an off-the-shelf wheel, and it won't be as good (thinking past the initial 'can I make it do what I want to do?').

If you end up doing something a lot in programming, it's typically considered wise to wrap it in a reusable function, class, etc. rather than re-write it all over the place. For some of what's being talked about here, that equivalent comes right there in the box and is called a coroutine.

 

I read the "for F***s sake" in ziegsden's voice, so it didn't bother me.

I'm trying to trust Unity, but I've got some deep trust issues, man.

 

As I've mentioned in this post I've actually have done that already! The Unity version while a pretty neat, simple implementation:

• Isn't strongly typed.
• Doesn't give you much control (e.g. pause, priorities, loop, reset).
• Doesn't have many concepts (e.g. wait for event, wait for message).
• Isn't multithreaded.
• Isn't serializable (I'm experimenting with this now).
• Is limited to Unity.
• Quite possibly isn't that optimised behind the scenes.
• etc.

Unity have the opportunity and capability to build in abstraction and efficiencies that surpass what an ordinary developer can easily do, however I see nothing to suggest that this is the case here.

 

While I agree improvements in general could be made I don't agree that implementing specifically the features that Unity's current coroutine offers, and nothing more, would be beneficial. If you needed something with more functionality then obviously you would need something different.

 

I've always found state machines to be the easiest way to represent the behavior that coroutines give you.

Behavior trees work pretty well too.

 

I don't think trees will work for me anytime soon, it's winter and they all died :c

State machines though. Those are pretty good.

 

State machines are like bicycles. Simple, works every time.

 

And once you implement them you never forget how?