Let's talk time!

[RichieGrape]

Finally got to do this test and report the results.

This DOES NOT work! It's game breaking to change the warp factor. From what I can tell in my testing is that the accumulation of needs is not effected by the warp... That's not what is needed. Accumulation of needs should be directly related to the time warp factor.

Chris Delay... If you want me to make a recording of this let me know. I can make a YouTube video...

The game had a .5 warp factor originally. I played for a while on .1 warp factor... That was TOO SLOW. A night is unbearable at that pace even with (>>>) clicked. So, I switched it to 2.5, which seemed fine... but when my prisoners woke up they ALL peed and crapped their cells before they even reached the toilet, in their cell. All of their needs were MAXED out except sleep...

That's another mechanic that should be fixed... If the bowels and bladder are getting toward max and the sleep is low or none... They would wake up and go to the bathroom, but that is beside this point.

Overnight my prisoners were starving. Even though my prison was 40+ days without incident. I had my first incident since day 2 as the starving prisoners started kicking off after waking. Changing the time factor should never of made that happen.

The warp factor shouldn't effect how much need is stored over time. Let's say you gain 5 bladder (+)'s in eight hours... If the clock is going fast or slow 8 CLOCK hours should equal 5 +'s regardless... independent of if that 8 hours took 15 minutes of game time or an hour. It does not work that way.

Do not change the warp factor currently until it is redesigned.

i think you originally misunderstood what the time warp factor does...the only thing it does is adjust how long it takes to make it through an hour...so be setting it lower your "hour" becomes longer...needs and such still decay at the same speed (could be modded to fix this though i'm pretty sure)...so if you set time warp faster you could actually end up with a prison that prisoners don't have enough time to complete tasks

pretty sure if you modded "needs.txt" you could adjust decay on needs to smooth out your prison

pretty sure the reason its not all tied together is because of the open modding support...the way the files are set up its really easy to make small adjustments to everything you have said above...even going as far as build speeds, walk speeds, strength of prisoners, strength of gaurds, etc

[Gangrene]

Yeah,

I thought the needs would beat to the metronome of the day clock... that would make sense. I thought I would just be giving more time to the prisoners to move from one area of the prison to another, animations.

Having the prisoners practically die overnight is game breaking. So, I would not advise editing the current game time warp factor.

[Gangrene]

I still think the game day time should be running at about half of what it is and that likewise the needs accumulations and spending time should be slowed by half.

[Arenlor]

If you set it low enough I guess you could just have them sleep for 1 hour a night, and make tons of money from having them work so long every day? It sounds like a few things need to be more firmly tied into it, needs should be emptied/filled? at the opposite rate, and production (of food, plates, etc) should be changed at the same rate.

[Maxiansheng]

I agree with you Gangrene. I have my eat time set to 2 x 3 hours every day because all prisoners don't make it to the canteen within the first hour and then they get pushed around inside the canteen and a large portion of them stops at the door for a while before they take something to eat. But of course if the clock is slowed down, the needs needs to be slowed down too. Same at work time when it takes them almost an hour to get to class...

[Hamnils5]

How about you change the Time Warp Factor to 0,5 permanently and just add a fourth time speed button, for those people who just want to get new prisoners they can just go on in super-fast mode. I find it really annoying that I need 2 hours for each food break because the prisoners take ages walking :/

Also I'm all for the half-hour time slots in the Regime !!

[Taosion]

So the upshot is the game currently plays really differently depending on the starting size of the map. The TimeWarpFactor is set when the map is created but is not altered by buying land, so otherwise identical prisons behave very differently. Confusion central for anyone trying re-use a layout designed for a different starting map size etc.

For anyone who hasn't grokked the scope of this issue, I'll attempt to break it down in detail:


Description

0. Terminology. The word 'time' is highly ambiguous in this context. I will use 'clock time' to refer to the clock dial and day counter, 'sentence time' for the prisoners served and remaining years, 'game time' for the games internal timekeeping and 'real time' for how long the simulation takes to run (excluding when it is paused).

1. When creating a new prison there are small (100x80), medium (150x120) and large (200x160) starting size options.

2. A variable called TimeWarpFactor is added to the save file if medium (TimeWarpFactor=0.75) or large (TimeWarpFactor=0.5) is selected. Small (TimeWarpFactor=1) uses the default TimeWarpFactor so does not specify it in the save file.

3. TimeWarpFactor affects the ratio of TimeIndex to SecondsPlayed. TimeIndex is the number of minutes of clock time since midnight day 1 (when you start a new game it is 8am day 1 so TimeIndex=8x60=480). SecondsPlayed is more or less how long the simulation has run unpaused in real time. e.g. the start of the save files on a small and large map at 1am day 2 (25x60=1500) running at >>> almost the whole time:

small
Version alpha-28
NumCellsX 100
NumCellsY 80
OriginX 0
OriginY 0
OriginW 100
OriginH 80
TimeIndex 1500.58
RandomSeed 22687
SecondsPlayed 215

large
Version alpha-28
NumCellsX 200
NumCellsY 160
OriginX 0
OriginY 0
OriginW 200
OriginH 160
TimeIndex 1501.08
TimeWarpFactor 0.500000
RandomSeed 20287
SecondsPlayed 412

4. TimeWarpFactor does not affect game time, game time = constant*TimeIndex/TimeWarpFactor e.g. workers can build the same amount of stuff in an hour of game time regardless of TimeWarpFactor, the difference between a large and small map is that only 30 minutes clock time will have elapsed on the large map. This means you can build twice as much on a large map before 8am day 2.

5. Some things are calculated using TimeIndex, others use raw game time. Things like financials (wages, prisoner income, bureaucracy etc) and schedules (regime, deployment, timers, new prisoners etc) use TimeIndex. Things like movement speed and needs (both the rate needs increase and are satisfied by objects) use game time.

6. Sentence time uses TimeIndex, 1 year sentence time is equivalent to about 5 days clock time in alpha 28. Takes about 12 clock hours for sentence time to advance 0.1 years whether TimeWarpFactor is 0.5, 1 or 10.

7. Prisoners only care about game time, clock time only matters to them insofar as it tells them where they have to be/what they have to do/when they get released. Doesn't matter that only 30 minutes has passed on the clock, to a prisoner it's an extra game time hour since he last exercised (or ate/slept/anything he didn't do in the last clock 30 minutes) .


Discussion

This is kind of like dropping prisoners from Earth on a planet where the day is twice as long and the legal system doesn't recognize they are not biologically adapted to only sleeping for 16 hours straight once every 48 hours. No wonder
some people get really cranky prisoners first thing in the morning. Needs going nuts after being on sleep regime for 16 straight hours. Then spending 4 hours in the cafeteria that they only get to visit once every 24 hours before standing in line for a shower for 2 hours and then working the first of two 8 hour shifts etc.

I'm not going to be using anything other than TimeWarpFactor=1 except for testing purposes in alpha 28. Good thing I always start with small maps anyway. If I had any prisons started on larger maps I'd give serious consideration to setting the TimeWarpFactor to 1 (or removing the line) in a copy of the save file. It would almost certainly break the prison design a bit as prisoners will now spend a larger part of the day in transit and have less time to complete their activity once they arrive. But, if you can figure out what changes you need to make to kitchen sizes etc you can go back to the original save and make the layout changes so the appropriate infrastructure is in place before changing TimeWarpFactor.


Analysis

Not sure how often it makes sense to tie a variable to raw game time, clock time seems to make more sense for the vast majority of cases I can think of. If the intention of TimeWarpFactor is to alter the balance of larger prisons by increasing the clock walking speed and decreasing the clock time to complete an activity then that is a problem. However, if the intention is simply to make larger prisons play smoother by running the simulation through more cycles per clock minute that is probably doable.

If the variables that currently use game time but ignore TimeWarpFactor are fixed the TimeWarpFactor would no longer affect gameplay balance, it would just be a another level of speed control beyond >, >> and >>>. There would be wacky behavior for extreme values of TimeWarpFactor (with low values causing animations to play very slowly and high values making everyone move around too fast to keep track of). High values would probably break the game by reducing the time for some actions/animations to below a single simulation cycle etc. Still makes sense though, unlike what happens now (where you can almost stop time and make a huge number of workshop items in a single day or have 20 years of a prisoners sentence go by before they even need to go to the bathroom).

With land expansion it makes no sense that TimeWarpFactor is determined by the starting map size. If it is determined by map size it should be the current map size. As performance is much more heavily affected by the number of
staff/prisoners/visitors than land size the current pop would be a better way to set it. Even better, redesign the UI for the speed controls and give the player more on the fly control of the simulation speed and make TimeWarpFactor redundant.

The current implementation of TimeWarpFactor is pretty essential for the viability of a huge number of prisons. Changing it will break them so good to keep it as is for legacy and modding purposes (every one of the shared prisons I have downloaded uses a TimeWarpFactor other than 1). Does exactly what it says on the tin, warps time in that the number of hours per hour is not 1. If it is deprecated all new prisons would have TimeWarpFactor=1 but players would still have the option to change it in the save file.


Goals

What improvements to the time system are people actually asking for and how do they relate to TimeWarpFactor? I have seen requests for the ability to:

a. specify the ratio of sentence time to clock time. Could be a good option to set on prison creation or at least be able to add a line to the save file. Totally not obvious whether 0.2 years per clock day is more reasonable than 2 months per clock day or 1 month per clock day. Would need to be tied in to new prisoner numbers, otherwise the lower the sentence time per clock day the larger the break even population. Also affects sentence extensions due to infractions, how many programs prisoners can complete etc. Nothing to do with TimeWarpFactor, I include it because it is part of the discussion in this thread.

b. make a clock day take less real time than currently possible without changing the behaviour of the simulation too severely. If its 2 am and you have a few prisoners who are all asleep, of course you want to spend less real time waiting for morning. If the user is ok with the crazy animation speed it's a great feature to push to the technical limits of the simulation and very useful for testing.

c. improve performance in larger prisons beyond what is otherwise possible by making a clock day take more real time. TimeWarpFactor partially addressed this by making the clock time elapsed for each "stutter" smaller. This cuts the clock time needed for utilities and rooms to start working properly on a large map, but does not reduce the distance each prisoner moves each time the simulation updates etc. Scaling movement speed will not make the simulation update more often, just reduce the difference between updates. To redraw the screen without updating the simulation some kind of interpolation would be needed.

d. have their reasonable looking layouts work better. TimeWarpFactor has skewed what is considered reasonable, once that source of confusion is removed all that is left is a balance issue with how long actions take in game compared to the real world and each other. The balance is of course a wip (that has been hampered by the introduction of TimeWarpFactor), but that's a topic for other threads.

None of these goals require TimeWarpFactor as currently implemented.

Conclusion

TimeWarpFactor is a fudge that alters the way large maps play compared to small maps by increasing the amount that can be done in a clock hour. This allows prisoners to walk further, kitchens to be smaller (or lunch to be shorter) etc so reduces the penalty for less compact layouts, overcrowding etc. It affects needs etc in a serious and nonsensical way by not scaling them with TimeWarpFactor. TimeWarpFactor is determined in a static and nonsensible way, leading to people trying to compare setups without being aware they don't use the same rulesets. Many currently viable prisons rely on a TimeWarpFactor of 0.75 or 0.5, fixing TimeWarpFactor so it affects game variables consistently will make many of them unviable. The easiest thing to do is deprecate TimeWarpFactor so it is always 1 for new vanilla prisons, make people aware of the issue so they can stop using TimeWarpFactor where possible and create some fresh code to deal with whatever issues TimeWarpFactor tried to address.

Even then, it will take a while for the confusion to clear up. Many of the problems people post take the form "setup x does y for you but setup x does z for me". TimeWarpFactor issues explain many of these cases. Get ready to ask/answer "What's your TimeWarpFactor?" a lot.

[Gangrene]

Thanks for the detailed breakdown Taosion! I read the whole thing.

How would you like to proceed with the discussion?

[RJenkos]

I haven't read all of the replies. But I feel like the time and speed are pretty broken. Each block is a meter correct? How long does it take you to walk a meter even at your slowest pace? Not 30 minutes to walk 100, that's for sure.
It's complex to fix due to timing Vs lag issues. But I'm sure that is already in the works.

[Inge Jones]

Definitely needs should be tied to clock time, not processor tick intervals.

[Gangrene]

I guess I'll restate my thoughts using your terminology... This should help clean things up a lot because as we can see... There is a lot going on within this "time" concept in the game, but really I’m not just talking about time we’re also talking about speed! That’s where the rubber is hitting the road, so to speak.

I think more time terms are needed in the list of terms. We know from basic Physics that Speed = Distance over Time. Let’s not get into relativity in this discussion. We have a distance in the game where we use meters, which I like.

“Movement Speed” is the amount of “Clock Time” it takes for a prisoner to move a set distance from point A to B.

I’d like to expand “Movement Speed” to “Game Speed” where that includes the movement of needs. Thinking of needs “moving” might be strange at first, but we can visualize it. Imagine the need as a bar where Point A is the left side(0 Need) of the bar and Point Z is the right side of the bar(max Need). Over time the amount of that need is visualized as a point moving from left to right as it accumulates. So, using that we can see that needs can have a speed (rate) applied to them. Different needs might have individual variables applied as ratios of the game speed meaning that the food need travels at 1.2 Game Speed and Sleep travels at .8 Game Speed. Instead of getting into the individual rates of needs we are compiling them all under the umbrella term “Game Speed”. Since the “time” component of the formula both come from the “Clock Time”(or should) manipulating that should effect both in the same way.

We also now have to consider “Animation Speed”. This would be how “Clock Time” relates to “Real Time”. This mechanic already exists in the game as the “Pause”,“>”, “>>”, “>>>” which directly effect “Animation Speed”.

Hopefully that all makes sense to you.

1. I play large maps and therefore I play the game almost exclusively at a time warp factor of “0.5”. That is my frame of reference. I'm glad we cleared that up. That helped to clear up while I was sometimes having problems in the morning... time is already warped for me from what other players on smaller maps were experiencing.

MAIN ISSUE
In my opinion "Clock Time" should be god. That is what the player sees. That is the tool the regime is planned by. Game mechanics should be tied to that time. "Sentence Time" should be a ratio of "Clock Time". That ratio should be able to be set by the player at some point in alpha or beta. "Game Time" should be directly tied to the "Clock Time". I think the time warp factor should be, effectively, removed. I say effectively because it could stay in the code but no longer be used as a variable. Having time warp as a variable means the same prison is working different ways for different saves. This is IMO, frankly, a terrible idea. I’ve taken this into account on the new terms as I never mention “Game Time”… only “Clock Time”, “Sentence Time”, and “Real Time”. Just to be clear… in the beta “Clock Time” to “Game Time” might need to be tweaked, but not in-between individual saves of the game. In the stock game that ratio should not be variable. In real life it takes longer to walk farther, so it should be in the game as well.

My MAIN ISSUE is “Movement Speed”. That needs to be doubled or tripled . We can get that detail hammered out in Alpha / Beta testing. This can be done by slowing the “Clock Speed”… but that should also slow the Game Speed by which the Needs are increasing or decreasing(moving). If the "Clock Speed" is the (t) in both equations s = d/t that would work. After doing some research it seems that people on average walk about 5kph. I think I’d be happy if they walked 4kph and suppressed prisoners walking 2kph.

I’m going to run some tests. I’m going to create a few long halls between a cell and a canteen and figure out how fast the prisoners are walking and I’m going to compare that to reality. Once we have that we’ll have a real number for “Movement Speed” and we can discuss that.

Another side issue is other people have an issue with “Animation Speed” and want to be able to increase “Animation Speed” as fast as possible. If the game can handle it I have no problem with giving more flexibility to lower the ratio of "Clock Time" to "Real Time".

[Helmic]

I guess I'll restate my thoughts using your terminology... This should help clean things up a lot because as we can see... There is a lot going on within this "time" concept in the game, but really I’m not just talking about time we’re also talking about speed! That’s where the rubber is hitting the road, so to speak.

I think more time terms are needed in the list of terms. We know from basic Physics that Speed = Distance over Time. Let’s not get into relativity in this discussion. We have a distance in the game where we use meters, which I like.

“Movement Speed” is the amount of “Clock Time” it takes for a prisoner to move a set distance from point A to B.

I’d like to expand “Movement Speed” to “Game Speed” where that includes the movement of needs. Thinking of needs “moving” might be strange at first, but we can visualize it. Imagine the need as a bar where Point A is the left side(0 Need) of the bar and Point Z is the right side of the bar(max Need). Over time the amount of that need is visualized as a point moving from left to right as it accumulates. So, using that we can see that needs can have a speed (rate) applied to them. Different needs might have individual variables applied as ratios of the game speed meaning that the food need travels at 1.2 Game Speed and Sleep travels at .8 Game Speed. Instead of getting into the individual rates of needs we are compiling them all under the umbrella term “Game Speed”. Since the “time” component of the formula both come from the “Clock Time”(or should) manipulating that should effect both in the same way.

We also now have to consider “Animation Speed”. This would be how “Clock Time” relates to “Real Time”. This mechanic already exists in the game as the “Pause”,“>”, “>>”, “>>>” which directly effect “Animation Speed”.

Hopefully that all makes sense to you.

1. I play large maps and therefore I play the game almost exclusively at a time warp factor of “0.5”. That is my frame of reference. I'm glad we cleared that up. That helped to clear up while I was sometimes having problems in the morning... time is already warped for me from what other players on smaller maps were experiencing.

MAIN ISSUE
In my opinion "Clock Time" should be god. That is what the player sees. That is the tool the regime is planned by. Game mechanics should be tied to that time. "Sentence Time" should be a ratio of "Clock Time". That ratio should be able to be set by the player at some point in alpha or beta. "Game Time" should be directly tied to the "Clock Time". I think the time warp factor should be, effectively, removed. I say effectively because it could stay in the code but no longer be used as a variable. Having time warp as a variable means the same prison is working different ways for different saves. This is IMO, frankly, a terrible idea. I’ve taken this into account on the new terms as I never mention “Game Time”… only “Clock Time”, “Sentence Time”, and “Real Time”. Just to be clear… in the beta “Clock Time” to “Game Time” might need to be tweaked, but not in-between individual saves of the game. In the stock game that ratio should not be variable. In real life it takes longer to walk farther, so it should be in the game as well.

My MAIN ISSUE is “Movement Speed”. That needs to be doubled or tripled . We can get that detail hammered out in Alpha / Beta testing. This can be done by slowing the “Clock Speed”… but that should also slow the Game Speed by which the Needs are increasing or decreasing(moving). If the "Clock Speed" is the (t) in both equations s = d/t that would work. After doing some research it seems that people on average walk about 5kph. I think I’d be happy if they walked 4kph and suppressed prisoners walking 2kph.

I’m going to run some tests. I’m going to create a few long halls between a cell and a canteen and figure out how fast the prisoners are walking and I’m going to compare that to reality. Once we have that we’ll have a real number for “Movement Speed” and we can discuss that.

Another side issue is other people have an issue with “Animation Speed” and want to be able to increase “Animation Speed” as fast as possible. If the game can handle it I have no problem with giving more flexibility to lower the ratio of "Clock Time" to "Real Time".

Nail on the head. I think a more elegant solution to the speed problem is to just have prisoners/workers jog if they're far away from their destination or running late, then slow down when they get close to it. They still get there faster if you design your prison to minimize transit times, but long distances no longer take ridiculously long. Prisoners should also rush themselves at the end of the timeslot to finish whatever it is they're doing, like scarfing down their food or finishing up their shower, or even just making a beeline for whatever it is they need instead of standing there staring blankly into nothingness.

[Inge Jones]

I think a more elegant solution to the speed problem is to just have prisoners/workers jog if they're far away from their destination or running late, then slow down when they get close to it.

There are two things wrong with this. Firstly it doesn't address the unrealistic time it takes to walk 1 meter *compared to clock time*. Secondly the type of processing needed to calculate whether a prisoner needs to jog is not only expensive to the system, but dreadfully hard to actually compute. Can you imagine writing an algorithm that takes into account where the prisoner is going, and what he's going to do, and how long that activity will need to complete, then subtract that from a cutoff time derived from *all* the factors that might limit available time in the location doing the activity? Only humans can efficiently apply this sort of multi-factorial logic, because we all have our own CPUs.

[LordBowler]

My MAIN ISSUE is “Movement Speed”. That needs to be doubled or tripled . We can get that detail hammered out in Alpha / Beta testing. This can be done by slowing the “Clock Speed”… but that should also slow the Game Speed by which the Needs are increasing or decreasing(moving). If the "Clock Speed" is the (t) in both equations s = d/t that would work. After doing some research it seems that people on average walk about 5kph. I think I’d be happy if they walked 4kph and suppressed prisoners walking 2kph.

Real Talk. All discussion about timewarpfactor aside, (thanks chris, for that bit of info. And taosion for the awesome breakdown), *everyone* walks far too slowly. Which is only made more frustrating by the fact that *sometimes* they decide to sprint 20-30 yards. Patrols are expensive just because you need 2 guys for every 25 meters of patrol, because they are walking at about 1 meter per minute. Or 0.0167 m/s. For comparison's sake, a snail crawls only *slightly* slower than my guards on patrol at 0.013 m/s [TWF =0.5]

Non patrolling guards move about 50% faster, as far as I can tell. But roughly the same speed when escorting prisoners. And then they move at about the speed I think I'd like to see when they are responding to an active brawl.

A movement speed tweak feels kind of necessary to me. Though this breakdown of how "time" works has given me a whole new insight into some of my prison's problems.

[Inge Jones]

*everyone* walks far too slowly.

Only compared with clock speed. They appear to be walking at an authentic speed otherwise. I think they should simply halve how fast the clock goes by default, while leaving top superspeed the same for those who want to get through a night time quickly. Just make sure that needs, like the program, are tied to elapsed clock time not to some other hidden tick counter.