Let's talk time!

[Helmic]

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.

Neither of those things you said make sense.

Of course it addresses the unrealistic amount of time it takes to walk 1 meter, that's the whole point of jogging, to move faster. The game isn't going to have "realistic" movement rates because that would result in way too fast animations. However, we CAN "cheat" the system by having people who need to move a long distance move faster without penalizing people who design their prisons to minimize walk times.

If a prisoner is 20 units from his destination, he'll walk at a rate of, say, 10 units per second. He gets there in two seconds. If another prisoner is 100 units from his destination, he'll jog at maybe 40 units per second until he's 20 units from his destination, at which point he'll slow back down to 10 units per second, taking four seconds. Had he not ran, he would have taken a grand total of ten seconds. Prisoners closer to their destination will always get there before prisoners further away, but far away prisoners then don't take so long that they don't have any time left over to fulfill needs once they get there.

As for performance impact, what are you talking about? Distance is already calculated as a normal part of pathfinding, doing a quick comparison to see if the prisoner should run would be trivial. You just determine whether they run or walk with a simple comparison test, if it's greater than 20 units (or whatever arbitrary distance we want to use) they run at the set running speed, else they walk. When they're within X units of their destination, walk. It's cheap to the point of being utterly negligible even with thousands of AI pathing everywhere. And the AI already knows how to sprint, they just don't sprint enough when they should be in a hurry.

[LordBowler]

*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.

Or, and this might just be crazy talk, but what if they just stop tracking 4 different kinds of time and connect *all* ticks to clock time? One minute of clock time is long enough for a guy to walk at least 50 meters. Scale to that. That way when I speed up clock time, people actually move faster. Thirty minutes of clock time without addressing a need makes the need tick up.

Re: simulation speeds: As it stands, the difference between > and >>> in my games seems to be marginal. An hour at speed 1 takes 60 seconds or 3600:1. An hour at speed 3 takes 45 seconds or 2700:1. [small map] So making speed 1 go 7200:1 and speed 3 go 1800:1 and speed 2 go the standard 3600:1 would give us the simulations speed range we're clamoring for, and by tying all behaviors to some scaled factor of clock time we also tie simulation time to simulation speed, a la Kerbal Space Program's physics acceleration. Max speed should be at *least* twice as fast as the lowest speed, imo. But a 1:2:4 ratio is an even wider spread.

Broaden up the simulation speed spread a bit, tie all behavior to clock time and voila. Everyone's happy, right? Or am I nuts?

/IANA programmer
//I just play one on TV

[Helmic]

*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.

Or, and this might just be crazy talk, but what if they just stop tracking 4 different kinds of time and connect *all* ticks to clock time? One minute of clock time is long enough for a guy to walk at least 50 meters. Scale to that. That way when I speed up clock time, people actually move faster. Thirty minutes of clock time without addressing a need makes the need tick up.

Re: simulation speeds: As it stands, the difference between > and >>> in my games seems to be marginal. An hour at speed 1 takes 60 seconds or 3600:1. An hour at speed 3 takes 45 seconds or 2700:1. [small map] So making speed 1 go 7200:1 and speed 3 go 1800:1 and speed 2 go the standard 3600:1 would give us the simulations speed range we're clamoring for, and by tying all behaviors to some scaled factor of clock time we also tie simulation time to simulation speed, a la Kerbal Space Program's physics acceleration. Max speed should be at *least* twice as fast as the lowest speed, imo. But a 1:2:4 ratio is an even wider spread.

Broaden up the simulation speed spread a bit, tie all behavior to clock time and voila. Everyone's happy, right? Or am I nuts?

/IANA programmer
//I just play one on TV

Exactly, having all these different kinds of game time is insane. Everything needs to march to the same clock, even if we call days "years" when talking about prison sentences. The issue is movement speed, so the solution is to make people move faster (when they need to), realism be damned. This should be map size agnostic, if someone needs to move a long distance then they need to move faster.

As for fast forward speeds, I find that in dorflikes I pretty much am always using the max speed when I'm not paused. Dwarf Fortress handles this well, you have two speeds, paused and unpaused. Everyone moves at the same rate and it doesn't take ages for spring to become summer to become fall. I think most of the effort should be going into finding a satisfying MAX speed, all else be damned. Who seriously uses anything other than paused, standard, and max? Or standard for anything other than watching the occasional cool moment?

[LordBowler]

As for fast forward speeds, I find that in dorflikes I pretty much am always using the max speed when I'm not paused. Dwarf Fortress handles this well, you have two speeds, paused and unpaused. Everyone moves at the same rate and it doesn't take ages for spring to become summer to become fall. I think most of the effort should be going into finding a satisfying MAX speed, all else be damned. Who seriously uses anything other than paused, standard, and max? Or standard for anything other than watching the occasional cool moment?

Pay closer attention to DF. That game has at least half a dozen tick rate streams going at once. And all of those rates are tied to cpu ticks. And it's not multithreading. I've had big enough forts that it took my farmers a season worth of ticks to plant crops. Subsequently I could only plant crops that had a 2+ season rotation. Alternatively, a year is supposed to take about an hour or real time. In some larger forts, that goes up to about 4 or 5 hours per game year.

Personally, in PA, I use standard speed to get a sense of general flow through my regime, or to catch bugs/trouble. I've visually caught prisoners stealing scissors or digging around their toilet before, and when trying to troubleshoot multiple kitchens, watching and tracking your cooks is key.

[Inge Jones]

Or, and this might just be crazy talk, but what if they just stop tracking 4 different kinds of time and connect *all* ticks to clock time?

Yes!!

[Inge Jones]

Neither of those things you said make sense.

You said "Or running late". What computationally cheap calculation can determine this?

[Helmic]

Pay closer attention to DF. That game has at least half a dozen tick rate streams going at once. And all of those rates are tied to cpu ticks. And it's not multithreading. I've had big enough forts that it took my farmers a season worth of ticks to plant crops. Subsequently I could only plant crops that had a 2+ season rotation. Alternatively, a year is supposed to take about an hour or real time. In some larger forts, that goes up to about 4 or 5 hours per game year.

Personally, in PA, I use standard speed to get a sense of general flow through my regime, or to catch bugs/trouble. I've visually caught prisoners stealing scissors or digging around their toilet before, and when trying to troubleshoot multiple kitchens, watching and tracking your cooks is key.

What are you talking about? I think you misread my post. I already know about Dwarf Fortress's time scalings, because I brought that up specifically to compliment how it doesn't take very long IRL for years to pass, its there specifically so that you can watch your fortress and your dwarves age over time. When I said there's only two speeds, I meant that there is no "fast forward" button in Dwarf Fortress. You are either paused, so that you can read something or check descriptions or plan out your fortress, or at max speed, where time starts moving. I prefer this approach because dorflikes should assume the players is ALWAYS going to pick the fastest speed available to them for the vast majority of their playhours that aren't spent paused. I brought up the 1 hour = 1 year thing in DF because I think PA should aim for something similar while assuming the player is going to play at max speed whenever they're not paused.

I say that because a lot of people in this thread and elsewhere keep mentioning that there should be yet another speed in the game for those who want to skip to the next day so that they can get new prisoners, an "ultra-max" speed setting if you will. The reality is that this new ultra max setting would just become the default speed setting for most players. I mean, who the hell uses the ">>" setting over the ">>>" setting? You mention yourself that you use the standard speed setting merely to get a sense of how fast the game "should" be running at, to help debug behaviors. You're not using it during normal gameplay, most people don't because real life time is a valuable thing.

Since the speeds are so similar, I think it'd be better to just focus on making max speed feel good. In reality the "standard" speed setting should just be there to make you feel like you're going as fast as you possibly can when you pick fast forward, even if the devs are designing the game knowing that fast forward is the de facto default and "standard" is more like slow-mo. I don't think I've ever clicked the "medium" fast forward setting, it's there almost purely for psychological purposes to make max feel super fast by contrast. It's the 9 button on a microwave, or any power setting other than full or half.

Neither of those things you said make sense.

You said "Or running late". What computationally cheap calculation can determine this?

You check the time? At, say, 15 minutes before the current regime ends, prisoners still in transit (have a job to move to area) are set to run/scarf down food/et cetera. The game is already capable of assigning tasks based on time, there's no reason it couldn't modify someone's movement speed. There's nothing to suggest this would cause a slowdown, at all.

[Inge Jones]

Running late depends what you have to do when you get there. You have to subtract the time needed for the activity, and the time required to get to the activity at current speed, from the time left for it. You're late for a class as soon as it starts, but you're only late for lunch when there is no longer enough time to eat it. I suppose your simple calculation may be better than nothing, but in that case why not have them all jogging to the next place all the time? Which is then a bit more like what some other people suggested about speeding up movement, which wasnt popular with everyone

[Helmic]

Running late depends what you have to do when you get there. You have to subtract the time needed for the activity, and the time required to get to the activity at current speed, from the time left for it. You're late for a class as soon as it starts, but you're only late for lunch when there is no longer enough time to eat it. I suppose your simple calculation may be better than nothing, but in that case why not have them all jogging to the next place all the time? Which is then a bit more like what some other people suggested about speeding up movement, which wasnt popular with everyone

It's not necessary to do any of that. The issue is that prisoners arrive late to their destinations, causing them to miss out on whatever activity they were wanting to do. If they're running late, it's as simple as giving them a speed boost (which can be explained away as them knowing they're running late and hurrying up). Generally making everyone rush to reach their destination thirty minutes before time's up should be enough for everyone to complete one task, such as eating a meal. I suppose 15 minutes might be too short for anything more than a quick shower, using 30 minutes as a flat timer makes it a lot more consistent and thus easier for the player to understand if they wish to incorporate that behavior into their prison designs. If 30 minute regime timeslots become a thing, anyone assigning a mere half hour for lunch in a large prison shouldn't be surprised that not everyone can make it in time to finish their meals.

As for not having them jog at all places at all times, it's the same reason that the game doesn't already have prisoners zipping across the entire map like they're on roller skates. It's a matter of good visual design. If everyone is constantly rushing all the time it stretches the suspension of disbelief too much, it looks ugly and it doesn't reward clever prison design because then transit times become a complete nonfactor. Restricting running to when its actually needed lets the prison move at a visually pleasing rate with the occasional superpowered burst from some very visibly late prisoners. And, of course, everyone should look like they're moving "as they should" even on max speed. A good dorflike should remember that 95% of a players' time not spent paused is going to be spent fast forwarding as fast as possible, you can't let the player spend 95% of their time disliking how the game looks.

This reminds me of how Spacebase DF-9 had a longstanding issue with its fast forwarding. It'd cause all sorts of little bugs, like oxygen leaks (which would cause the entire prison to asphyxiate and be sucked into the nearest pub). And so the game felt a lot less enjoyable because you had to run the game "too slow." It didn't help that the standard speed had everyone moving at an utterly glacial pace. Had they never included fast forwarding but simply sped up the movement speed and animations, the game would feel just right because there's no max speed button sitting there in the UI telling the player that they're wasting their time. Don't buy Spacebase DF-9, by the way. That's how you not make a dorflike. Or any game that relies on constant updates, for that matter.

[Gangrene]

I'm playing at "0.5" warp. Keep that in mind.

So, based on some experimentation I did on my stream last night the prisoners are moving at about 250-275 meters per hour when compared to real life of about 5kph. So about 5% of real life speed or 20 times slower.

What I realized it that if the sprites are moving about a normal speed we'd have to take the clock time down 20 times and we'd be playing at close to real time... not good. I'm thinking that we don't have to have them going at a "real life" pace though... so if we start by cutting the "Clock Time" in half that might be a good start for testing and we can go from there... 500 meters per hour would be better but I'm not sure if it would need to be slower until I played it. We should also stabilize the time warp and begin testing. This may be something that is better suited for beta testing though.

[nielsmh]

Wasn't TimeWarpFactor added as a feature for medium/large prisons specifically only as an attempt to deal with the walking speed challenges? That it took prisoners/staff too long to walk through the larger prisons.
But then it turns out the way it was implemented, it affects other things in the game too: Needs accumulation, job completion time, research completion time, punishment (lockdown/solitary) time, possibly more.

This causes issues because needs accumulation and job completion times were initially balanced around no time warp (i.e. factor 1), but when you change the time warp they become unbalanced.
So yes, TimeWarpFactor as currently implemented changes game balance. That is probably not the intention, especially considering the problem it was intended to solve.

Another issue at the ground of this is the perceived movement speed: The speed characters walk at should "look good". I believe that the current walking speeds were chosen with that in mind, not any grounding in any sort of reality. Wanting to keep the perceived movement speed the same, i.e. the number of pixels traveled on screen per second, at some given zoom level, at slowest game speed, explains why the game clock slows down rather than everyone speeds up.

Unfortunately there isn't really any good solution that doesn't involve scrapping TimeWarpFactor again. Even if it were made to affect only movement speed and not the other systems, it would still affect game balance. The same building layout should play the same regardless of the starting map size, that's what all common sense dictates.

Therefore: TimeWarpFactor needs to go away, and walking speed through larger prisons needs to be dealt with in a different manner.

Luckily PA is still in alpha stage, which should make it clear that balancing it is still not a major concern. Getting all the basic game systems in place is.
When all the systems are in place, and interconnected all the way, then balancing can commence.
Another very successful Early Access game just transitioned from Alpha to Beta stage: Kerbal Space Program. They are following this model, and have specifically announced that only now are they putting effort into really balancing the game, shuffling elements and numbers around until they provide a good and fair challenge. That is sound game development practice, and I trust Introversion will be doing something similar.
Yes PA is not balanced yet, and lots of things still need to be tried out (such as TimeWarpFactor) to see if they can work. The pieces can be put together for a balanced experience later.

[LordBowler]

Pay closer attention to DF. That game has at least half a dozen tick rate streams going at once. And all of those rates are tied to cpu ticks. And it's not multithreading. I've had big enough forts that it took my farmers a season worth of ticks to plant crops. Subsequently I could only plant crops that had a 2+ season rotation. Alternatively, a year is supposed to take about an hour or real time. In some larger forts, that goes up to about 4 or 5 hours per game year.

Personally, in PA, I use standard speed to get a sense of general flow through my regime, or to catch bugs/trouble. I've visually caught prisoners stealing scissors or digging around their toilet before, and when trying to troubleshoot multiple kitchens, watching and tracking your cooks is key.

What are you talking about? I think you misread my post.

It appears I did. I stand by my point that DF's time solution is no more optimal than this one, but that's not what you were referring to. Mea Culpa.

[SonofSuperJoe]

Wow, some pretty smart folks commenting in this thread.

I'm not sure I have much to add other than this:

While I'm not familiar with Dwarf Fortress, I am familiar with D&D, having been a DM for a number of years. In D&D there's often the a look at time-scale in a bit of a reverse from what's going on here. That's a turn-based game and time is divided into a number of "Turns" when action breaks out, with (theoretically) infinite time allowed for the players to make decisions on their turn. There the average movement speed per turn (for humans) is 30ft when not running, or 10 meters, using the PA frame of distance reference. When calculated based on average real-life movement speed, a turn ends up being about six second, which is the average amount of time an adult human can cover the distance of 30 feet/10 meters at a walking pace (try it yourself at home! Just count six seconds and walk in a straight line, see how far you can get!)

All of this is to say that, yeah, a minute per meter - at ANY timescale - is exceptionally slow for human beings. Since this isn't a halfling prison, it seems the rate at which prisoners walk relative to the timescale needs to be GREATLY increased. Having anything close to a timescale where prisoners are moving at 1 meter a minute is insanely slow if we're comparing to either reality, or even a turn-based game as classic as D&D.

That said, the issue with the controllable timescale that users have in order to get to the next day and especially regarding how much time = a year regarding prisoner's and their potential release from jail seems something that definitely needs to be under the user's purview.

It seems like something that should be an option on map generation as an option similar to something you'd see in Civilization or something - Short Game - A year is 12 Days, Normal Game - a year is 24 Days, Long Game - a year is 72 Days, Hardcore "Realism" mode - A year is 365 Days. Options on game generation this would be especially user friendly, as it would allow for the player to determine how much time they really want to devote to playing the game based off of the potential game speed. I know for myself from playing games like Civ, that having this option is much preferred. I like longer civ games to allow for more specific strategies on battles and such, but others prefer quickly blasting through them. Making this an option for the player is the best way to serve the largest number of player preferences.

Especially considering my earlier post regarding the importance of potential seasons and weather effects ( found here- viewtopic.php?f=43&t=51722 ) as a "tell" for the player in order to see the years pass by and the rates at which prisoners' sentences are finished out, I'm thinking this issue of timescale and AI movement within it is something that needs to be resolved before something that shows the passage of time can even be addressed.

[Roy974]

Regarding the issue of time advancing too quickly whilst prisoners are moving around. I actually agree that it's weird that prisoners often can't even get to their destination within an hour, so I could easily make time advance at 1/2 speed to solve that. In fact we do exactly that with large maps - there is a value called TimeWarpFactor that is set to 0.5 for the biggest maps. You can probably try some experiments yourselves by setting that value. Set it to 0.1 and time will advance 10 times slower than currently, but everyone will still move around at the same speed.

HOWEVER, there is another chorus of players who think the day progresses too slowly. They want to be able to advance time to tommorow at 8am for example, to get more prisoners. If I made this change, they'd be pissed off because now you'd have to wait twice as long or ten times as long for a day to pass. A day will feel much longer if we make this change.

I'm still undecided, is what I'm saying.

Awesome I will have to look into this. Anyway I guess one way of adding it is in gameplay under options. You could have a drop down which allows the player to select what speed they want, simple to add but a lot of work under the hood as far as balancing changes made with "IF" entries like if timewarp 1 = and then the code entries to the selected balancing code for that timewarp factor. For example some coding I did on a game that allowed for some realism to be added.

Code: Select all

   if(!Realistic_Weather) // = If Realistic Weather is NOT enabled
{
   Weathers[n].Wind.Speed.Min = 4.0;
   }
   else // = If Realistic Weather IS enabled
   {
   Weathers[n].Wind.Speed.Min = 0.0;
}


this worked like a charm and this simple yet effective coding was used a lot for each and every realistic factor entries I had made for that game. Under options the player was able to simply check a box for each feature (leaving the box unchecked meant the game would not run that feature) perhaps a similar way could be done here for PA?

P.S.
Just noticed in the save file that the line of code is not created on small maps where you the player has purchased additional land thus expanding your prison size beyond that of even the large map size. So my conclusion is to only play on the large map giving your prisoners the added time they will need to see to their needs and get to their destinations with time to spare. Obviously this is taking into account that the prison you have built is one that could be built on the small map and not spread out across the whole map.

Update:
Adding the line of code to the save file works fine, I have adjusted the warp factor to 3.8 because on a slower speed the needs are not balanced enough and prisoners fight to much because of their needs. Will see how 3.8 works out. But I already feel this speed is much better although I would like to have the option to have a slower speed with needs balanced for that speed. I do have a question though, is there a way to modify the base timewarpfactor code outside of the save files which in turn would use the new values in all map sizes you have modified the values for without the need to change that value in the save file?

[Jazzpirate]

Wait a second - sorry if I'm asking a noob question, but do I understand the discussion in this thread right, that movement speed and clock speed are not exactly in relation to each other? I mean - let's say it takes a prisoner some time t (on the ingame clock) to do x. If I now speed up, does it actually take him longer (on the ingame clock)? If so, that's insane! I'm almost always on the highest speed since normal speed is just way to slow - I give building commands etc. on pause and then switch to the highest speed until it's finished. That would basically mean I should leave everything on the slowest speed and get bored while they finish some humongous building -.-

But I absolutely second the fact that everyone moves waaay to slow. It shouldn't take a prisoner half an hour on clocktime to walk 200m or something, and it's really bugging me. And it messes with the needs of my prisoners in an uncalculable, unintuitive and annoying way...