I'm working on a cookie clicker replica.
What happens is that I am using a yield return new WaitForSeconds (0.1f) to add the cookies per second to the cookie counter, and I want them to add up in a fast way, and not second per second.
The problem is that when I run it on my computer, it works perfectly, but when I run it on my android, it slowly adds the cookies to the counter.
According to my little knowledge, I would say it has to do with the FPS. I tried to use the (Time.deltaTime * 0.1f), inside the WaitForSeconds, but it still works slowly in android. Also tried using the Invoke() method, but it works slowly too.
(I have the StartCoroutine inside the Update method.)
(When I put 1 second instead of 0.1f, it works fine, but it doesn't look good in terms of appearance.)
IEnumerator Rps()
{
Stats.CookiesTotal = Stats.CookiesTotal + Stats.cookiesPerSecond;
yield return new WaitForSeconds(Time.deltaTime * 0.1f);
yield return null;
}
private void Update()
{
StartCoroutine(Rps());
openSlot(price1text, price1, slot1);
openSlot(price2text, price2, slot2);
openSlot(price3text, price3, slot3);
}
You are calling the coroutine from Update() which is framerate dependent.
So on a 60 fps machine, it will run Rps() 60 times, while on a 30 fps machine, it will run Rps() 30 times. Thus a faster fps machine will generate cookies faster.
Also note that the WaitForSeconds is occurring after you have increased the cookie amount which means it is delaying nothing at all, so in effect, this code is the same as:
private void Update()
{
Stats.CookiesTotal = Stats.CookiesTotal + Stats.cookiesPerSecond;
//...
}
As others have suggested, using coroutines this way in Update() is not ideal. It is possible to achieve a coroutined constant cookie increase every 0.1s by starting a coroutine in Start() and having an infinite loop inside the coroutine which increases cookie count and waits for X time. You will need to be very mindful of managing that infinite loop coroutine.
(This code is not tested but should give you the general idea)
private IEnumerator countCookiesCoroutine;
IEnumerator Rps()
{
while (true){
Stats.CookiesTotal = Stats.CookiesTotal + Stats.cookiesPerSecond;
yield return new WaitForSeconds(0.1f);
}
}
private void Start()
{
countCookiesCoroutine = Rps();
StartCoroutine(countCookiesCoroutine);
}
A more straightforward approach, especially if you are working with large numbers of cookies and precision is not important, might be to increment the cookie count in FixedUpdate() based on the physics time step, such as:
private void FixedUpdate(){
Stats.CookiesTotal = Stats.CookiesTotal + (Stats.cookiesPerSecond * Time.fixedDeltaTime);
}
This will make the cookie rate increase as smoothly as physics updates and framerate independent. The reason I have used FixedTime() rather than Update() is because Update() is framerate dependant and even with Time.deltaTime faster machines will still collect cookies faster due to the higher compound cookie interest being calculated more frequently than on slower fps machines.
You may also need to wrap the display of the cookie numbers in a Mathf.Floor() if displaying decimals is undesirable.
Related
So I've been making a 2D shooter game in unity and I run my game on a global timer using the code
timer += Time.deltaTime
this usually just gives me a timer that works like a stop watch however suddenly the value of my timer variable just fluctuates at around 0.0003-0.0001 when running the script when it should be going 1 2 3 4 5 etc for every second. It has done it before and without me changing anything to my knowledge it just fixed itself after 30ish mins but now it's happened again. Does anyone know why this is?
float time = 0f;
float timer = 5f;
void Update()
{
time += Time.deltaTime;
if(time >= timer)
{
// Do something
}
}
The code is adding 1f to time every second. Using Time.deltaTime makes it so that it will be the same at any framerate (for example if the framerate is 30fps, it won't add a second 30 times in one second ) and if time (the amount of seconds) surpasses timer, we run what is in between the if statement.
When I run the game, Unity's inspector updates every few seconds, but totalTimeElapsed only increments in a series of 0.1 seconds. I tried a similar thing with totalTimeElapsed += Time.deltaTime but with the same result.
How do I get the total time since game start?
float totalTimeELapsed = 0;
int dayCount = 0;
private void Update()
{
totalTimeElapsed = Time.time;
dayCount += 1;
AFunctionTakingLotsOfTime();
}
Because AFunctionTakingLotsOfTime() takes a long time, you need Time.realtimeSinceStartup
Time.realtimeSinceStartup deals in real time, rather than computed frame-rate-time amounts that are probably getting messed up due to the fact that your function takes a long time.
Alternatively you could use DateTime.
Note that both will not be affected by things like time scale and you may want to change your function to be less intensive, such as computing only a small chunk any given call (or by using a coroutine) or by splitting the method off onto a Job thread.
float totalTime = 0f;
// Update is called once per frame
void Update () {
totalTime += Time.deltaTime;
}
I believe what you are looking for would be something like this. Assuming this class is present on runtime of your game, you should have an accurate variable which can tell you the elapsed time since the game started.
You might also want to know that the update call occurs once per frame, ie. if you are running at 60 FPS update will be called 60 times in that second. You can try FixedUpdate which updates in real-time intervals instead.
I am creating a rythm VR game for google cardboard, inspired by Beat Saber on PSVR and Oculus Rift.
The concept is that blocks with different directions come at you, following the rythm of the music, just like in Beat Saber.
For every music I have created a ScriptableObject called music, with every parameter it should contain like the difficulty of the song, the name, etc. but also an array of Vector3 called notes : the first float of the Vector corresponds to the time the note should be beaten in the rythm of the music starting from 0: ScriptableObject
Then in a script called SlashSpawnManagement, where every thing is based on WaitForSeconds(), I spawn the blocks to smash. It's realy hard for me to explain wih words the order I do it in, so here is an image : Explanation
In theory, what this script does, it waits for some time, spawns a block, waits for some time, spawn a block, etc. The logic seems okay, but here's the weird part. As you play the song the distance between each block gradually becomes bigger and bigger, meaning the blocks become more and more out of sync with the music. It starts very well, but at the end of the music there is at least a 5s gap.
I figured it has something to do with the frame rate drop, so I tried to set the frameRate to something low with :
QualitySettings.vSyncCount = 0; // VSync must be disabled
Application.targetFrameRate = 30;
But it doesn't solve the problem. I tried with WaitForSecondsRealtime instead of WaitForSeconds, but nothing changes. I have read somewhere that WaitForSeconds depends on the frame rate... Where I calculated the time, I tried sustractng h divided by a number to even out the gradual gap. This works for some blocks but not every block: Notes[j][0] - h / 500
So here's my question, how do I make the WaitForSeconds, or any other method consistent with the seconds provided ?
Thank you In advance,
PS : For more clarifications, please ask and please forgive my typos and my english :)
If you want something to happen in regular time intervals, it is important to make sure that errors don't accumulate.
Don't:
private IEnumerable DoInIntervals()
{
while (this)
{
yield return new WaitForSeconds(1f); // this will NOT wait exactly 1 second but a few ms more. This error accumulates over time
DoSomething();
}
}
Do:
private IEnumerable DoInIntervals()
{
const float interval = 1f;
float nextEventTime = Time.time + interval;
while (this)
{
if (Time.time >= nextEventTime)
{
nextEventTime += interval; // this ensures that nextEventTime is exactly (interval) seconds after the previous nextEventTime. Errors are not accumulated.
DoSomething();
}
yield return null;
}
}
This will make sure your events happen in regular intervals.
Note: Even though this will be regular, it does not guarantee that it will stay in sync with other systems like audio. That can only be achieved by having a shared time between systems, like spender mentioned in his comment on your question.
Trying to use WaitForSeconds the timing of audio and hope for the best is hoping a big hope.
Have a list of Vector3s prepared in advance. If you want to prepare the list using the rythm - it will work. Use AudioSource's time to check every Update whether the timing is right and spawn a block at that moment.
void Update () {
SpawnIfTimingIsRight();
}
void SpawnIfTimingIsRight() {
float nextTiming = timingsArray[nextIndex].x;
// Time For Block To Get To Position
float blockTime = this.blockDistanceToTravel / this.blockSpeed;
float timeToSpawnBlock = nextTiming - blockTime;
if (this.audioSource.time >= nextTiming && (this.audioSource.time - Time.deltaTime) < nextTiming) {
// Spawn block
}
}
I have a Coroutine, and I have tried using WaitForSecondsRealtime and WaitForSeconds. When I run the Coroutine, the delay is the same for a few iterations, but then there is a gap where the delay is a little longer, then it goes back, then there is a delay again.
Here is an image of what is happening, as you can see there are a few gaps between circles, and I would like the gaps to be a bit more constant.
Here is the Coroutine that I am using for this:
public float shootDelay = 0.03f;
IEnumerator Shoot(Vector3 direction) {
direction.z = 0f;
foreach (GameObject ball in balls) {
float speed = ball.GetComponent<Ball>().speed;
ball.GetComponent<Ball>().rb.velocity = direction.normalized * speed;
yield return new WaitForSecondsRealtime(shootDelay);
}
}
It is hard to tell from your tiny bit of code exactly what your question is. A good Minimal, Complete, and Verifiable code example would help a lot (perhaps minus the standard Unity3d boilerplate…there's an art to providing just the right amount of code for a Unity3d question).
But is seems like you are trying to implement a delay between "balls" being "shot" from something. As such, you want for each ball to be initialized at precise intervals. They are not, which results in irregular intervals.
Unfortunately, I don't think you can count on the WaitForSecondsRealtime() (or WaitForSeconds(), for that matter…which is probably a better choice here, as it would automatically adjust if you change the game simulation speed). These functions have significant sources of imprecision that you will need to take into account, particularly that the time that's waited is counted only after the current frame is entirely complete and your coroutine is only resumed at the first frame after the specified time has elapsed.
One way to take into account this imprecision is by using the Time.time value to track how much simulation time has actually passed since you started firing the bullets. Initialize a variable in the coroutine just before the loop, to the current value. Then when you are setting the velocity of the bullet object, also set its position based on the velocity and the difference between the current time value and that bullet's intended time value. Then wait for a period of time not the exact interval you want, but an interval that represents the difference between the current time and the next bullet time.
Without a good MCVE it's not practical for me to try to test this (i.e., I haven't), but something like this should work:
IEnumerator Shoot(Vector3 direction) {
direction.z = 0f;
float nextBulletTime = Time.time;
foreach (GameObject ball in balls) {
Ball ballComponent = ball.GetComponent<Ball>();
float speed = ballComponent.speed;
Rigidbody rb = ballComponent.rb;
rb.velocity = direction.normalized * speed;
rb.position += rb.velocity * (Time.time - nextBulletTime);
nextBulletTime += shootDelay;
yield return new WaitForSeconds(nextBulletTime - Time.time);
}
}
TL,DR: is it safe to use Time.deltaTime as the wait time for the yield in a coroutine?
Often to avoid unnecessary logic inside Update() for short lived functionality I'll run a coroutine instead. For example in my game I have a slow coroutine that periodically checks the distance between NPCs and the player, if that distance is under some threshold I'll then run a more frequent coroutine with more expensive line of sight testing using raycasting etc. This seems much more efficient than checking everything constantly in Update().
My question is this: is it safe to use Time.deltaTime as the wait time for the yield, thereby simulating Update() for the duration of the coroutine? i.e. yield return new WaitForSeconds(Time.deltaTime);
Since deltaTime is not constant what happens if the next frame takes longer than the last - is the coroutine delayed until the next frame, or is something horrible happening like the whole frame being delayed until the coroutine finishes? I'm tempted to allow a buffer for safety e.g. yield return new WaitForSeconds(Time.deltaTime * 1.2f); but ideally I'd like it to execute precisely every frame.
is it safe to use Time.deltaTime as the wait time for the yield in a
coroutine?
No. That's not how to use the WaitForSeconds function. WaitForSeconds takes in seconds as a parameter not the tiny values provided by Time.deltaTime in every frame.
Below is an example of how to use the WaitForSeconds function.
IEnumerator waitFunction1()
{
Debug.Log("Hello Before Waiting");
yield return new WaitForSeconds(3); //Will wait for 3 seconds then run the code below
Debug.Log("Hello After waiting for 3 seconds");
}
As for waiting with Time.deltaTime, you usually use it in a while loop in addition to another float variable you will increment or decrement until you reach the wanted value.The advantage of using Time.deltaTime is that you can see how much waiting time is left while waiting. You can use that for a countdown or up timer. You also put yield return null; in the while loop so that Unity will allow other scripts to run too and your App won't freeze. Below is an example of how to use Time.deltaTime to wait for 3 seconds. You can easily turn it into a countdown timer.
IEnumerator waitFunction2()
{
const float waitTime = 3f;
float counter = 0f;
Debug.Log("Hello Before Waiting");
while (counter < waitTime)
{
Debug.Log("Current WaitTime: " + counter);
counter += Time.deltaTime;
yield return null; //Don't freeze Unity
}
Debug.Log("Hello After waiting for 3 seconds");
}
If you want to check every frame there are WaitForEndOfFrame
There is no point to WaitForSeconds if you don't need specific time to wait for
You can also yield return www to wait for it finish
Update, there are CustomYieldInstruction and some of it inheritance for used in coroutine, like WaitUntil
I know that this is a bit old, but I just came across it today while looking for something that's related.
Anyways, Programmer's answer is a good start. Using Time.detlaTime is not a good way to release control of a coroutine. For one, using a null value will get you to the next frame in simulation. Second, what happens if the frame you just finished was a bit slow (or the next frame is a bit fast). Please keep in mind that the simulation (or game) runs in frames, much like the frames in a film. Because of this, using WaitForSeconds can have some interesting effects. For instance, if the time you requested happens between frames, what do you think will happen? The coroutine will regain control after the requested time. So, if you were hoping to just shoot off a WaitForSeconds(Time.deltaTime) on each loop in the coroutine, chances are, you are skipping the occasional frame (sometimes more).
I had a coworker that did a bunch of WaitForSeconds, inside a long running coroutine and the total time that passed was anywhere between 5 to 10 seconds longer than what was expected. Those off by part of a frame errors in the requested time will add up, and unlike nature, where errors tend to average out, these errors will always add up. That's because the amount of time that passes will always be greater-than or equal-to the amount of time that's requested.
Programmer's answer showed you how to use Time.deltaTime to get the passage of simulation time. I should warn you that once you start using things other than null to release control of the coroutine, that Time.deltaTime might stop working for you.
If you use a null follow by some code followed by a WaitForEndFrame, you will still be within the same frame when the coroutine resumes control. Because you are still in the same frame as you were before calling WaitForEndFrame, the simulation time that has passed will be zero, but Time.deltaTime will not be zero. So, yeah, measuring time can get tricky once you start mixing different return types. You should also be careful of switching between frames and fixed-frames. Using a WaitForFixedUpdate will put you into the times of the fixed-frames. Calling Time.fixedDeltaTime after a WaitForFixedUdpate will give you the time between that fixed-frame and the previous fixed-frame, which has nothing to do with Time.deltaTime or any of timings for the frames.