WaitForSeconds for controlling time based Event Calls - opinions and suggestions for learner?

OK here goes, I am tinkering and trying to learn about time based event calls to move a player, if you think of the Snake game where movement is dictated at a set repeatable timestep. Once a pickup is picked up, this timestep decreases slightly. initially the timestep is at 1 second, but this will go as low as 0.1 seconds.

what I currently have:
I have an event setup called MoveNow() that when fired instructs all subscribed objects that its time to move.

This MoveNow() event is fired within a CoRoutine with a yield return new WaitForSeconds(timeStep) to control time increments**,** so i can vary the timestep float when say an item is picked up and thereby control MoveNow() call times.

Stripped down this is what I am using:

IEnumerator MovementCalls()
{
    while(true)
    {
        yield return new WaitForSeconds(timeStep);
        MoveNow();
    }
}

from what I’ve been reading over the last couple of days is that using this style where it could effectively be called 10 times a second, is garbage collection and how inefficient it is, so rather than me going down a path that will give me bad habits I thought I would ask for opinions or direction on what alternatives to read up on.

I have toyed with using InvokeRepeating() and once the time needs to change, cancel the invoke and recall it, seems to work ok.

I have also tried another method, whereby i cache and predeclare all the WaitForSeconds objects for 0.1 to 1.0 in 0.1 increments (so 10 of em) for use in the coroutine.

each of the methods appears to work, but, I’m just kind of stumped on which to go with to not go down the road of starting with bad habits.

Just looking for a bit of advice and direction please.

Instead of coroutines, you could implement your game using FixedUpdate and change the fixed time step to setup your game speed.

yeah, i dont use FixedUpdate for anything as theres no physics calculations required, theres other things going on within update calls, but I could independently use that. Ill have a go tomorrow, say set the physics timestep to 0.1 and try binding the movement to multiples of that. Ill have a go themorro, cheers for the suggestion.

I have been doing some digging in relation to the physics timestep, theres pros and cons, but at the end of the day its only running at most 10 times a second on a really small game.

so might be overcomplicating things. more for me to think about :slight_smile:

could just create a timer with the update method

public class Test : MonoBehaviour {
    [SerializeField] private float _timeBeteenEvents = 1f;
    private float _timer;

    private void Update() {
        _timer += Time.deltaTime;
        if (_timer >= _timeBeteenEvents) {
            _timer = 0f;
            // do my time based stuff here
        }
    }
}
2 Likes

FixedUpdate is not exclusively for physics computation. If you game does not use physics, it means you have even more freedom to use it.

Do you mean there is a maximum of 10 FixedUpdate calls per frame? That is wrong. You can have much more calls than that by tweaking the fixed time step.
What is exactly the requirement of your game that is not satisfied by the cons?

This code assumes that the event rate is less than the the frame rate. In the case the event rate is higher, let’s say _timeBeteenEvents = 0.001 (1000/s), a lot of events will be skipped.

Yea, think ill just use that for simplicity. Cheers passerbycmc.
Curiosity was getting me down the rabbit hole so to speak :slight_smile:

Sorry Eric, was a bit late when i was messing about last night, yep im going to have a play around with the physics steps today. I meant to say that my little snake game will only need to call an event at every 0.1 seconds. im just using it as a learning case and trying different things.

No problem ;). It’s a good practice to run small experiments by yourself to validate or invalidate how something actually works.