Design Questions about Delta time, lag with incremental/click based game.

flyinian

Member
1. Is Delta timing good for a incremental/click based game?

2. If I have variables doing calculations per step, and the game lags, will it cause issues for me? Ex: if I had two variables relying to be in sync, and become out of sink due to lag. Or is that lag just voided steps and the variables will pick up where they left off with no differences?

3. Is lag kind of like a pause? When the game lags, it stops code until it catches up?

4. Is there anything I should be aware of while making an incremental/click based game?

That's all for now, thanks.
 

andev

Member
1. Is Delta timing good for a incremental/click based game?
What is an incremental/click based game? You mean like cookie clicker? If so then yes, use delta time. Unless you're just starting out, in which case it might be overcomplicating things. You'd use delta time because the core mechanic of the game (earning money) is directly linked to the time elapsed, so keeping the game in sync with actual time is very important.

This:
Or is that lag just voided steps and the variables will pick up where they left off with no differences?
is answered by the answer to this question which is:
3. Is lag kind of like a pause? When the game lags, it stops code until it catches up?
Yes. It will never skip a step (unless you have hardware failiure, and then you have much bigger problems). It will either keep ploughing through the code or stop entirely. And that's the reason you want to write code using delta time.

Once the code realises that more time has passed than it has time to render for, it calculates how many steps need to be skipped in order to catch up. Then it increments all the variables by their usual amount multiplied by the amount of steps it skipped, RATHER than going through those steps incrementally and inevitably ending up further behind.

4. Is there anything I should be aware of while making an incremental/click based game?
Still assuming you mean a cookie clicker game here. Most cookie clicker games are somewhat procedural and just use maths to work out the prices of things. When you buy an upgrade, it would increase its price by say 20%, rather than have a list of predefined prices.

And this 'lazy' method extends to the individual upgrades themselves. All you need is a list of upgrade names, and then all you need to do is give an initial price. From then on, every type of upgrade will cost say 150% more than the last.

So TLDR:
The more you earn, the more expensive the items you want become. It feels like you're making progress but all you're doing is shifting the goal posts. At the beginning of the game you make $1 per click and your upgrade costs $20. At the end of the game you make $1,000,000 per click and the upgrades cost $20,000,000. It's just very simple scaling maths, and if you implement it like this it will save you a lot of time.
 

NightFrost

Member
Well, I doubt an idle clicker would really become so heavy that it starts skipping frames... Unless you're doing something crazy visually or juggling a huge amount of numbers. Take note though, since the numbers will grow very large, normal variables are insufficient for tracking the sums unless you go "cheaty" as some, so to speak, and only track maybe the ten most significant digits of the numbers and add a suffix, handwaving any smaller increments as irrelevant. If you want to track them down to least significant values all the time, you have to develop a system to store large values, like splitting the number into an array (which is the route I went) and to do calculations in that format.

Also, since upgrade costs are usually set to follow a standard formulas, you can precalculate all the prices. You just set a limit to upgradeability, so you have a finite amount of prices to precalculate.
 

flyinian

Member
What is an incremental/click based game? You mean like cookie clicker? If so then yes, use delta time. Unless you're just starting out, in which case it might be overcomplicating things. You'd use delta time because the core mechanic of the game (earning money) is directly linked to the time elapsed, so keeping the game in sync with actual time is very important.

This:


is answered by the answer to this question which is:

Yes. It will never skip a step (unless you have hardware failiure, and then you have much bigger problems). It will either keep ploughing through the code or stop entirely. And that's the reason you want to write code using delta time.

Once the code realises that more time has passed than it has time to render for, it calculates how many steps need to be skipped in order to catch up. Then it increments all the variables by their usual amount multiplied by the amount of steps it skipped, RATHER than going through those steps incrementally and inevitably ending up further behind.


Still assuming you mean a cookie clicker game here. Most cookie clicker games are somewhat procedural and just use maths to work out the prices of things. When you buy an upgrade, it would increase its price by say 20%, rather than have a list of predefined prices.

And this 'lazy' method extends to the individual upgrades themselves. All you need is a list of upgrade names, and then all you need to do is give an initial price. From then on, every type of upgrade will cost say 150% more than the last.

So TLDR:
The more you earn, the more expensive the items you want become. It feels like you're making progress but all you're doing is shifting the goal posts. At the beginning of the game you make $1 per click and your upgrade costs $20. At the end of the game you make $1,000,000 per click and the upgrades cost $20,000,000. It's just very simple scaling maths, and if you implement it like this it will save you a lot of time.
I have nothing to reply with besides a "Thank you".
 
Last edited:

flyinian

Member
Well, I doubt an idle clicker would really become so heavy that it starts skipping frames... Unless you're doing something crazy visually or juggling a huge amount of numbers. Take note though, since the numbers will grow very large, normal variables are insufficient for tracking the sums unless you go "cheaty" as some, so to speak, and only track maybe the ten most significant digits of the numbers and add a suffix, handwaving any smaller increments as irrelevant. If you want to track them down to least significant values all the time, you have to develop a system to store large values, like splitting the number into an array (which is the route I went) and to do calculations in that format.

Also, since upgrade costs are usually set to follow a standard formulas, you can precalculate all the prices. You just set a limit to upgradeability, so you have a finite amount of prices to precalculate.
How big of a number are we talking about?
 

NightFrost

Member
How big of a number are we talking about?
Largest displayed number had space for abound fourty zeroes. This was decided by how long a number I could fit into the UI.

I'll explain briefly how I built the system. Others may have built their idle clickers differently. Let's call the units you receive by clicking as money, as that's its main use, and the things you buy with money to generate more money as buildings. Whenever I refer to some unit of money, it was not an integer value in a variable, but an array built to store a large number. for example 99 999 999 might have been stored to an array with each slot housing three digits, as [99][999][999].

Every building had their upgrade costs precalculated to avoid cost calculations during game execution. Every building also had a money-per-step generation values, per-unit and a total. Whenever a building was upgraded (that is, you bought one more of them) the per-unit money generation value would be added into the total generated value. Every game step, the total from every building you owned one or more would be added to your current money total.

I had four workhorse scripts for handling money. First would add two money arrays together and return an array with their sum. Second would multiply two money arrays together and return an array with their total. Third would subtract from first given array the second and return an array with the result, and worked on the expectation that returning negative values was not necessary - that is, it assumed the target value would always be larger than the one to subtract. Fourth would compare two money arrays and tell if the first was larger than or equal to the second - in other words, it chielfy gated purchases, making sure your current money was enough to purchase an upgrade. There was also another function that would take a money array and turn it into a displayable string. These were resolved once and stored for most prices, as they changed so infrequently it was unnecessary to call for a conversion every time an amount of money had to be displayed.

The system had the largely cosmetic advantage of being able to track and display really larger numbers down to their least significant digit, and it was able to acknowledge even the tiniest addition of money into the total (unlike some clickers which simply ignore small numbers when sums grow large enough). Another reason to make it that way was to see if I could code such a thing. This whole thing ran with ease even on old systems, so whatever system you end up building for money shouldn't tax modern CPUs too much.
 
Top