Return to Answer

None of these are correct. Don't base your opinion on answers based on the upvotes. There's far too much wasted computation when you run an update function and check a condition and then just ignore it if it's not matching said condition.

What you actually want to do is have a controlling behavior that enables/disables this component.

Otherwise every frame you're wasting cpu-cycles. If the behavior should be active, tun on the component and once the limit is reached, turn off the component. The manager should manage should manager when the component is enabled.

It's such a waste of resources to run a function every update and check a condition that determines if a function is run. Especially when they've got relatively non-trivial conditions that must be calculated to produce a bool. Even then, it's still pointless. You want a component that runs that function on Update and then disable it when it's done. There's some edge-cases here where you're using a modulus value to determine whether or not you want to run something every two frames, but that could probably be met with some criticism and more efficient approaches.

Also never use while true is a complete no. You're completely giving up your ability to control the flow of the application. Especially if there's no break in there. It makes much more sense to simply assign a boolean value that the while(b) uses so that you still have control over it, even compared to having while(true) with a break inside that is hit when a boolean is met.

Basically, you're wasting cpu-cycles, especially when calculating the condition, every frame, just to check if you want to use it. Use a manager to enable it when it should run. Also avoid coroutines in mass. They do have their usages, but using it to replace something like update, is just asking for wasted cpu-cycles.

Hope this helps. I've had to learn this things the hard way, unfortunately. I think if you give it some thought, it will become apparently. So essentially, create another component that has an update function (though you should consolidate your update calls to a single engine object and call them from there), and then once the time is over, disable that component. Two minutes later, turn it on, from the manager. Perhaps event-based responses. Rinse and repeat. If you've got one thing doing this, you'll probably not notice it unless you benchmark it, but this is definitely not a good way to build at scale.

None of these are correct. Don't base your opinion on answers based on the upvotes. There's far too much wasted computation when you run an update function and check a condition and then just ignore it if it's not matching said condition.

What you actually want to do is have a controlling behavior that enables/disables this component.

Otherwise every frame you're wasting CPU-cycles. If the behavior should be active, turn on the component and once the limit is reached, turn off the component. The manager should manage should manager when the component is enabled.

It's such a waste of resources to run a function every update and check a condition that determines if a function is run. Especially when they've got relatively non-trivial conditions that must be calculated to produce a boolean. Even then, it's still pointless. You want a component that runs that function on Update and then disable it when it's done. There's some edge-cases here where you're using a modulus value to determine whether or not you want to run something every two frames, but that could probably be met with some criticism and more efficient approaches.

Also never use while true is a complete no. You're completely giving up your ability to control the flow of the application. Especially if there's no break in there. It makes much more sense to simply assign a boolean value that the while(b) uses so that you still have control over it, even compared to having while(true) with a break inside that is hit when a boolean is met.

Basically, you're wasting CPU-cycles, especially when calculating the condition, every frame, just to check if you want to use it. Use a manager to enable it when it should run. Also avoid coroutines in mass. They do have their usages, but using it to replace something like update, is just asking for wasted CPU-cycles.

Hope this helps. I've had to learn this things the hard way, unfortunately. I think if you give it some thought, it will become apparently. So essentially, create another component that has an update function (though you should consolidate your update calls to a single engine object and call them from there), and then once the time is over, disable that component. Two minutes later, turn it on, from the manager. Perhaps event-based responses. Rinse and repeat. If you've got one thing doing this, you'll probably not notice it unless you benchmark it, but this is definitely not a good way to build at scale.

None of these are correct. Don't base your opinion on answers based on the upvotes. There's far too much wasted computation when you run an update function and check a condition and then just ignore it if it's not matching said condition.

What you actually want to do is have a controlling behavior that enables/disables this component.

Otherwise every frame you're wasting cpu-cycles. If the behavior should be active, tun on the component and once the limit is reached, turn off the component. The manager should manage should manager when the component is enabled.

It's such a waste of resources to run a function every update and check a condition that determines if a function is run. Especially when they've got relatively non-trivial conditions that must be calculated to produce a bool. Even then, it's still pointless. You want a component that runs that function on Update and then disable it when it's done. There's some edge-cases here where you're using a modulus value to determine whether or not you want to run something every two frames, but that could probably be met with some criticism and more efficient approaches.

Also never use while true is a complete no. You're completely giving up your ability to control the flow of the application. Especially if there's no break in there. It makes much more sense to simply assign a boolean value that the while(b) uses so that you still have control over it, even compared to having while(true) with a break inside that is hit when a boolean is met.

Basically, you're wasting cpu-cycles, especially when calculating the condition, every frame, just to check if you want to use it. Use a manager to enable it when it should run. Also avoid coroutines in mass. They do have their usages, but using it to replace something like update, is just asking for wasted cpu-cycles.

Hope this helps. I've had to learn this things the hard way, unfortunately. I think if you give it some thought, it will become apparently. So essentially, create another component that has an update function (though you should consolidate your update calls to a single engine object and call them from there), and then once the time is over, disable that component. Two minutes later, turn it on. Rinse and repeat. If you've got one thing doing this, you'll probably not notice it unless you benchmark it, but this is definitely not a good way to build at scale.

None of these are correct. Don't base your opinion on answers based on the upvotes. There's far too much wasted computation when you run an update function and check a condition and then just ignore it if it's not matching said condition.

What you actually want to do is have a controlling behavior that enables/disables this component.

Otherwise every frame you're wasting cpu-cycles. If the behavior should be active, tun on the component and once the limit is reached, turn off the component. The manager should manage should manager when the component is enabled.

It's such a waste of resources to run a function every update and check a condition that determines if a function is run. Especially when they've got relatively non-trivial conditions that must be calculated to produce a bool. Even then, it's still pointless. You want a component that runs that function on Update and then disable it when it's done. There's some edge-cases here where you're using a modulus value to determine whether or not you want to run something every two frames, but that could probably be met with some criticism and more efficient approaches.

Also never use while true is a complete no. You're completely giving up your ability to control the flow of the application. Especially if there's no break in there. It makes much more sense to simply assign a boolean value that the while(b) uses so that you still have control over it, even compared to having while(true) with a break inside that is hit when a boolean is met.

Basically, you're wasting cpu-cycles, especially when calculating the condition, every frame, just to check if you want to use it. Use a manager to enable it when it should run. Also avoid coroutines in mass. They do have their usages, but using it to replace something like update, is just asking for wasted cpu-cycles.

Hope this helps. I've had to learn this things the hard way, unfortunately. I think if you give it some thought, it will become apparently. So essentially, create another component that has an update function (though you should consolidate your update calls to a single engine object and call them from there), and then once the time is over, disable that component. Two minutes later, turn it on, from the manager. Perhaps event-based responses. Rinse and repeat. If you've got one thing doing this, you'll probably not notice it unless you benchmark it, but this is definitely not a good way to build at scale.

None of these are correct. Don't base your opinion on answers based on the upvotes. There's far too much wasted computation when you run an update function and check a condition and then just ignore it if it's not matching said condition.

What you actually want to do is have a controlling behavior that enables/disables this component.

Otherwise every frame you're wasting cpu-cycles. If the behavior should be active, tun on the component and once the limit is reached, turn off the component. The manager should manage should manager when the component is enabled.

It's such a waste of resources to run a function every update and check a condition that determines if a function is run. Especially when they've got relatively non-trivial conditions that are just checking bools. Even then, it's still pointless. You want a component that runs that function on Update and then disable it when it's done. There's some edge-cases here where you're using a modulus value to determine whether or not you want to run something every two frames, but that could probably be met with some criticism and more efficient approaches.

Also never use while true is a complete no. You're completely giving up your ability to control the flow of the application. Especially if there's no break in there. It makes much more sense to simply assign a boolean value that the while(b) uses so that you still have control over it, even compared to having while(true) with a break inside that is hit when a boolean is met.

Basically, you're wasting cpu-cycles, especially when calculating the condition, every frame, just to check if you want to use it. Use a manager to enable it when it should run. Also avoid coroutines in mass. They do have their usages, but using it to replace something like update, is just asking for wasted cpu-cycles.

Hope this helps. I've had to learn this things the hard way, unfortunately. I think if you give it some thought, it will become apparently. So essentially, create another component that has an update function (though you should consolidate your update calls to a single engine object and call them from there), and then once the time is over, disable that component. Two minutes later, turn it on. Rinse and repeat. If you've got one thing doing this, you'll probably not notice it unless you benchmark it, but this is definitely not a good way to build at scale.

None of these are correct. Don't base your opinion on answers based on the upvotes. There's far too much wasted computation when you run an update function and check a condition and then just ignore it if it's not matching said condition.

What you actually want to do is have a controlling behavior that enables/disables this component.

Otherwise every frame you're wasting cpu-cycles. If the behavior should be active, tun on the component and once the limit is reached, turn off the component. The manager should manage should manager when the component is enabled.

It's such a waste of resources to run a function every update and check a condition that determines if a function is run. Especially when they've got relatively non-trivial conditions that must be calculated to produce a bool. Even then, it's still pointless. You want a component that runs that function on Update and then disable it when it's done. There's some edge-cases here where you're using a modulus value to determine whether or not you want to run something every two frames, but that could probably be met with some criticism and more efficient approaches.

Also never use while true is a complete no. You're completely giving up your ability to control the flow of the application. Especially if there's no break in there. It makes much more sense to simply assign a boolean value that the while(b) uses so that you still have control over it, even compared to having while(true) with a break inside that is hit when a boolean is met.

Basically, you're wasting cpu-cycles, especially when calculating the condition, every frame, just to check if you want to use it. Use a manager to enable it when it should run. Also avoid coroutines in mass. They do have their usages, but using it to replace something like update, is just asking for wasted cpu-cycles.

Hope this helps. I've had to learn this things the hard way, unfortunately. I think if you give it some thought, it will become apparently. So essentially, create another component that has an update function (though you should consolidate your update calls to a single engine object and call them from there), and then once the time is over, disable that component. Two minutes later, turn it on. Rinse and repeat. If you've got one thing doing this, you'll probably not notice it unless you benchmark it, but this is definitely not a good way to build at scale.