Why are 60 UPS = 1s?

[Doublespin]

I know the game is updating 60 times per second but I wonder is there reason to use 60 ticks?
If the tick rate is too low then there probably are stuttering issues but what is "too low"? Too high and the game performance would get worse. So isn't this a parameter which could be used to improve the performance of the game? If lowering it to 50 UPS = 1s* without any issues then the performance should increase by around 1/6= 16,7%? (assuming every tick has the same workload).

*I think about it like this:
At 60 UPS a assembler drains 3 kW meaning that each tick 1/60*3 kW is offset against the energy production.
At 50 UPS a assembler drains 3 kW meaning that each tick 1/50*3 kW is offset against the energy production -> It would not change energy consumption but only the stepsize in the calculation.

[FrodoOf9Fingers]

60 is just a good standard. Monitor are typically 60hz, so and 60 frames per second works real well, and so 60 updates per second.

The update cycle doesn't just do logic, it also prepares things for drawing. That's why you'll see fps drop but ups stay high sometimes, but fps will never go above ups.

[eradicator]

*I think about it like this:
At 60 UPS a assembler drains 3 kW meaning that each tick 1/60*3 kW is offset against the energy production.
At 50 UPS a assembler drains 3 kW meaning that each tick 1/50*3 kW is offset against the energy production -> It would not change energy consumption but only the stepsize in the calculation.

Power is not calculated as a per second value. It is defined as a per tick value (as is proably everything else relevant to this), so trying to change UPS would mean manually adjusting amost every number in the game (power, crafting time, inserter rotation rate, belt speed, etcpp), if you want to keep the same percieved speed.

[Doublespin]

To clarify: I don't want so suggest to lower the UPS. I'm just curious.

I didn't know that fps and UPS are linked. But in general this doesn't has to be the case. For example Minecraft runs with 20 ticks/s but fps are much higher. Concerning the updaterate of a monitor. I never noticed a difference for games which run on 50 fps or with 70 fps on a 60hz monitor. Even though my experience is not representative I dont think it would be an big issue if the game would run with 50 fps.

*I think about it like this:
At 60 UPS a assembler drains 3 kW meaning that each tick 1/60*3 kW is offset against the energy production.
At 50 UPS a assembler drains 3 kW meaning that each tick 1/50*3 kW is offset against the energy production -> It would not change energy consumption but only the stepsize in the calculation.

Power is not calculated as a per second value. It is defined as a per tick value (as is proably everything else relevant to this), so trying to change UPS would mean manually adjusting amost every number in the game (power, crafting time, inserter rotation rate, belt speed, etcpp), if you want to keep the same percieved speed.

I thought so. Thats what I mean with changing the stepsize. The values for the energy consumption are already in seconds, so in theory (it probably is much more complicated) it should be possible to "just" change this stepsize. And even if the data is already per tick, then its just a fixed factor bigger or smaller.

[Jap2.0]

To clarify: I don't want so suggest to lower the UPS. I'm just curious.

I didn't know that fps and UPS are linked. But in general this doesn't has to be the case. For example Minecraft runs with 20 ticks/s but fps are much higher. Concerning the updaterate of a monitor. I never noticed a difference for games which run on 50 fps or with 70 fps on a 60hz monitor. Even though my experience is not representative I dont think it would be an big issue if the game would run with 50 fps.

Minecraft is the exception, not the rule. It's also horribly optimized.

In many games, FPS and UPS are decoupled - meaning that you can have unlimited FPS, while the tickrate is at a constant amount. This includes games like Minecraft. Why does this matter? It means that the tick rate has less of an influence on FPS.
But this does not occur in Factorio* because everything happens 60 times per second - in animations, 1 frame is 1/60 of a second, belts move 60 times per second, combinators update 60 times per second, etc. Due to this, having an uncoupled framerate would be very difficult, and impossible in many areas.

There are several reasons this can't easily change. Animations would all need to be recreated. Combinator creations which make use of counters to measure time would be broken. Vehicles, biters, and projectiles would be slower. Belts, bots, inserters, assemblers, etc. would need to be sped up, or there would be discrepancies between animations and results, and setups would produce materials more slowly than before. Overall, trying to change this would be difficult and result in numerous bugs. In short, it's not feasible.

Why was Factorio built in 60 UPS in the first place? It's a standard many games use (with exceptions). Many monitors are (or used to be) 60 Hz, and most higher refresh rate monitors (for example, mine, which is 75 Hz, or gaming monitors, which are frequently 120 or 144Hz) support displaying things at 60Hz without jitter. Due to this, if they were not given content to display at a multiple or divisor of 60 (such as 50), some frames would be displayed longer than others, leading to jitter. Although you may not notice it, it usually makes things look worse overall. Having a framerate higher than 60 would be wasted on many monitors, and lead to higher GPU loads.

*Yet - I have heard that it may happen, but only with player movement, i.e. the frame may move more than 60 times per second, but it will only update 60 times per second

[bobucles]

3d games in general desync their FPS from the internal UPS because, well, because they're 3d. It is easy to issue a 3d motion command to a video card and let it pump out as many frames as it can manage. Factorio doesn't really need that because it's a 2d sprite based game. If the game state doesn't update then there's no reason to draw a new screen. Under MOST conditions anyway.

There is one really ugly thing where if you set the game.speed TOO low it will cripple your FPS with it. Without any FPS you can't even use the menu. That's very annoying.

[eradicator]

Power is not calculated as a per second value. [...]

The values for the energy consumption are already in seconds,[...]

Do you even read the things you quote? Only the GUI displays energy per second when required. The simulation knows nothing about this. A "step size" does not exist internally.

Btw 60fps is an industry standard. Going below that would anger a great many very vocal people that are (or pretend to be) very sensitive to framerate changes. In 3D shooters there's even a very vocal group that refuses to play below 120Hz. As someone else already mentioned 3D can interpolate any arbitrary state between two points in time because they're vector based. Many shooters (and minecraft as you noticed) infact only simulate what's happening at 20Hz and interpolate the visuals inbetween. 2D engines can not interpolate an object that moves only by e.g. 0.33 pixels without horribly blurring the result. Read up on the difference between vector (= i want a green line from a to b don't bother me with the inbetween) and bitmap graphics (=draw me a red pixel at exactly these coordinates) if you're really interested.

[TruePikachu]

A "step size" does not exist internally.

Yes one does, with a step being 1/60 of a second. There is no way for the simulation to operate as a continuous entity while maintaining both interactivity and determinism.

Many things in the prototype definitions explicitly specify amounts per tick; for example:

Code: Select all

  {
    type = "construction-robot",
    name = "construction-robot",
...
    speed = 0.06,
    transfer_distance = 0.5,
    max_energy = "1.5MJ",
    energy_per_tick = "0.05kJ",

A construction robot has a base speed of 0.06 tiles/tick (3.6 tiles/second), and consumes 0.05kJ of power every tick it is in flight (3kJ of power per second, or more formally 3kW of power)

Other things, such as machines, specify their power consumption in more formal units; for example:

Code: Select all

  {
    type = "assembling-machine",
    name = "assembling-machine-1",
...
    energy_usage = "90kW",

An AM1 consumes 90kW of power, or 90kJ of power per second, or 1.5kJ of power per tick.

[eradicator]

A "step size" does not exist internally.

Yes one does, with a step being 1/60 of a second. There is no way for the simulation to operate as a continuous entity while maintaining both interactivity and determinism.

There are steps, nobody said anything about continuous (doesn't exist in computers). But there is no fixed "size" (=duration) for these steps as the OP presumed. And there is no global variable you could just flip to bend everything to a new "size". This can be quite clearly shown by changing game.speed to >1 or <1 and observing that none of the menus care about this. They're hardcoded to "60" regardless of how many ticks make up a real-life second.

An AM1 consumes 90kW of power, or 90kJ of power per second, or 1.5kJ of power per tick.

Energy strings are the only thing on the lua side that have a "built in" factor of 60. Probably for ease of use. And they're only used in the data stage. Energy in control stage is a per tick float value.

[xng]

*I think about it like this:
At 60 UPS a assembler drains 3 kW meaning that each tick 1/60*3 kW is offset against the energy production.
At 50 UPS a assembler drains 3 kW meaning that each tick 1/50*3 kW is offset against the energy production -> It would not change energy consumption but only the stepsize in the calculation.

You are perfectly right about that they could've chosen any arbitrary step size for logic iterations, but it doesn't mean it would work with any. The step size will for example limit how fast a belt can be (or it could internally transform the stepsize into more steps each tick which would not benefit performance or animations in the least), and changing it would mean having to change lots of other internal logic. Updating physics like animations 60 times per second have proven to work nicely for fooling our minds into believing things are happening seemlessly, it can't be much lower or it seems choppy, or higher without demanding more juice in players computers.

It doesn't really have much to do with monitor refresh rates though as modern monitors have a wide variety of recommended refresh rates, and taking for granted that everyone is running 60 fps only works if living in the US and playing on console.

[Doublespin]

Thanks a lot for all the answers
Especially the difference between 2D and 3D games is interesting. I think I will investigate this topic further.

[Hedning1390]

You can change it to 50 ups by typing the following into console: /c game.speed=5/6. Note that this will also affect fps.

[TruePikachu]

You can change it to 50 ups by typing the following into console: /c game.speed=5/6. Note that this will also affect fps.

As far as the engine is concerned with respect to in-game time passing per tick and units (as a result), there are still 60 ticks per second. All the console command does is tell the game how fast you want the game to go compared to normal.

[AnthonyForPOTUS]

1/60 of a second is the time it takes an item, e.g. a copper plate, to move one space on a blue conveyor. Speeding up or slowing the UPS max would effect conveyor speeds. Besides, your eyes can't even see 60 frames per second, let alone 120. You are fooling yourself if you think you can. it's more like 15 frames per second for most people, with certain genetic variations letting some (<0.001% so no you aren't one of them) see up to 25 frames per second. What some people perceive at higher frame rates is motion blur. So higher frame rates will look better, but motion blur effects can be simulated in hardware. Since motion blur would have no real effect in factorio, it isn't needed, and the 60 UPS is locked. 60 FPS is also locked because there is no reason to display at a higher framerate when the image literally doesn't change any faster.

[Splitframe]

But this does not occur in Factorio* because everything happens 60 times per second - in animations, 1 frame is 1/60 of a second, belts move 60 times per second, combinators update 60 times per second, etc. Due to this, having an uncoupled framerate would be very difficult, and impossible in many areas.

*Yet - I have heard that it may happen, but only with player movement, i.e. the frame may move more than 60 times per second, but it will only update 60 times per second

Wasn't there a FFF where they touched on that? With overlapping time frames and whatnot?
From that FFF I got the impression they switched to make UPS and FPS separate from each other.
Maybe I find it again.

A quick google search later: https://www.factorio.com/blog/post/fff-70
So it's still coupled, but not as strictly as before. Maybe this helps you people with the discussion.

[Hedning1390]

You can change it to 50 ups by typing the following into console: /c game.speed=5/6. Note that this will also affect fps.

As far as the engine is concerned with respect to in-game time passing per tick and units (as a result), there are still 60 ticks per second. All the console command does is tell the game how fast you want the game to go compared to normal.

What do you mean? Lets take combinators as an example (since they can be made into a clock). Combinators work by doing their function every tick. What effect are you saying game speed will have on combinators? As far as I'm concerned they still do their function every tick, just that the ticks happens with a different time interval.

[aober93]

OP is correct, this would positivly affect the game performance.

But in fact the game does already do something like this, it updates some entities only once every few ticks, which essentially is the same as your proposal.

But it would have a negative impact if the UPS came down as a whole ,because for example the movement of belts or inserters would become choppy. 50fps not so much but here you have 60 and you cannot tune it that easily.

[eradicator]

Btw, if this makes it easier to imagine, the suggestion to "reduce UPS to 50 to gain 13% performance" , if transfered to 3D shooter would be something like "why not reduce the resolution to 800x600 to gain 50% fps", or "why not reduce the polygon count of all models by 50% to gain more fps". Of course reducing the detail of the game makes it run faster (simulation detail in factorios case). The question is simply how low or high detail the developer wants to deliver, and then the game is made around that assumption.

[TruePikachu]

I might mention at this point that the speeds of yellow/red/blue belts are currently 1/32, 1/16, and 3/32 of a tile per tick, or 1+7/8, 3+3/4, and 5+5/8 of a tile per second. If the engine were to be modified to run at 50FPS retroactively, it would require the belt speeds to be non-1/32-increments, which I'm not 100% sure is good for the engine (I think I heard that positions are quantized, but I don't recall to what increment). Belts would run 16.67% slower without adjustment of the speeds, and a blue belt would only deliver 33.333 items/second instead of the current 40.

[bobucles]

Making a 50UPS or 40UPS mod is hard, but making a 30UPS mod is easy. Just double the speed of everything!