Severity
Severe
Frequency
All of the time (100% reproducible)
Area of Game Affected
Performance
Description
Off the back of the report for Track Rides crippling late game, I thought I’d also take the time to run a report on Performance of the game in “late game”; where the park rating is over 5000 and guests are reaching 10,000+ without marketing. I’ve noticed a few things that I’d like to at least formalise in case they have been missed - I’d be very surprised if they haven’t of course, but off the back of the update a while back where it was discovered that the indexing of buildings were dragging performance down, here this is. The drop in performance from the symptoms below sort of creates a bit of a bad taste when building larger parks. Since the addition of the Adventure and Studios DLC, it seems that you can no longer build “large” parks but now have to settle for “medium” ones instead.
I will supply a newer version of the park in the “Tracked Rides Cripple Late Game” bug report as these behaviours are experienced more prolifically in this park:
1. At the point of 8,500 the park performance starts to decline quite rapidly and noticeably. The FPS drop from 8500 to 10000 is approx. 64%, with the game eventually slowing down simulation to accommodate a reasonable frame rate.
2. It would appear that if you use a large number of scenery objects will slow the game down. Whether this is due to animation, indexing etc, I’m not sure. This is also true if, like me, you use building grids to create fences.
3. The simulation of guests seem to calculate the needs to individuals in a group, but they only ever act as a group – ie they never split up. So, is this another redundant calculation where it would be much better to calculate the needs of a GROUP rather than the individuals in that group? Would this free up much power?
4. Guests in queues seem to drag performance down. The longer the queue is the worse it is. Factor in a slow load / unload strategy caused by certain ride types and you can lose as much as 50% frame rate. In this park, if I set every ride in the park to test, close then reopen (effectively clearing ALL queues) then the framerate can jump as much as 45%. Based on a hunch and watching how path finding / collision detection works (and not experience of the game code), it would appear that guests in queues have a needs reduction over time; quite rightly so. But they seem to be trying to calculate a path to something that can solve that need – which they can’t do, so they recalculate. However, when not in a queue, the path is clear and so no re-calculation is needed. This, of course, may not be the reason for it, so the only thing I can say for CERTAIN is the symptom: That guests in queues reduce performance.
5. This one is more economy based than performance – but the financial system in the game will allow you to charge 1/40th of the rides prestige. This can be quite a sum of money. But this only serves to then have guests wandering your park complaining that they have no money and walking by empty cash machines or refusing to go home. This creates some flaws in the games economy.
6. Placing paths in late-game creates a lag when placing; the more you place the worse it gets. This could be linked to the queue issue and based on the Dev Diaries from the early days, I suspect this may have something to do with guest collision and pathfinding. If you place a path with 10,000 guests the engine essentially has to “open” the path to route finding for all of these guests.
7. Menu UI loading for Scenery, Buildings, Rides etc takes a long time to load in larger parks. If you load the UI, you can sit staring at an empty grid for upwards of 5 – 10 seconds before any of the items load. This seems to be getting worse as you add DLC’s that need to be loaded too. The more objects you add to the game, the longer it takes to load sooner in the game (ie it would “slow” at 8000 guests, but now it’s around 6000). I seem to remember Parkitect (a VERY different game and engine; I know) had a similar issue where they ended up pre-loading the items at game load rather than “live”. Is something like this something that could help here?
8. Training a lot of staff in batch will make the game crawl. If you set a batch of 30 or more staff to train at once, the game will come to a crawl. Not actually sure why for this one?
EDIT!! 9. It seems that the rides and coasters have to update their heat-maps and thus their ride stats live whenever a train leaves the station (at the very least when Train 1 leaves). Surely this is redundant unless the ride is testing?!
Some possible solutions based on my observations but no knowledge of the game code:
1. Adjust the needs calculations to be fore groups and not individuals as the groups never break away from each other it seems that this is redundant.
2. Complete a full review of everything in game and take stock of what processes, simulations etc you have now. This is certainly NOT a dig at the original optimisation of the game as I believe that it was actually really good. And I must also note that 1.6.1 seemed to have a slight performance jump too. This is more about looking at the system NOW and seeing if there are any new major optimisations to be made, especially now that players are building ever increasingly large, intricate and detailed parks.
3. Check over the queue system to see if continued needs route calculations are dragging performance down. Needs should obviously decline while in a queue, but something drags performance?
And just before I go, the rough specs I am running:
i7 7700K overclocked to boost to 5.2Ghz, water cooled
32 Gb RAM clocked to 3400
Asus GTX 1070 Turbo
SSD
Asus Z170 Gaming motherboard
I’ll post an updated park to this thread tonight when I get home but I really hope this report helps in some way.
Steps to Reproduce
As above
***EDIT***
Park to use:
http://tedoshay.com/performancepark.zip
Severe
Frequency
All of the time (100% reproducible)
Area of Game Affected
Performance
Description
Off the back of the report for Track Rides crippling late game, I thought I’d also take the time to run a report on Performance of the game in “late game”; where the park rating is over 5000 and guests are reaching 10,000+ without marketing. I’ve noticed a few things that I’d like to at least formalise in case they have been missed - I’d be very surprised if they haven’t of course, but off the back of the update a while back where it was discovered that the indexing of buildings were dragging performance down, here this is. The drop in performance from the symptoms below sort of creates a bit of a bad taste when building larger parks. Since the addition of the Adventure and Studios DLC, it seems that you can no longer build “large” parks but now have to settle for “medium” ones instead.
I will supply a newer version of the park in the “Tracked Rides Cripple Late Game” bug report as these behaviours are experienced more prolifically in this park:
1. At the point of 8,500 the park performance starts to decline quite rapidly and noticeably. The FPS drop from 8500 to 10000 is approx. 64%, with the game eventually slowing down simulation to accommodate a reasonable frame rate.
2. It would appear that if you use a large number of scenery objects will slow the game down. Whether this is due to animation, indexing etc, I’m not sure. This is also true if, like me, you use building grids to create fences.
3. The simulation of guests seem to calculate the needs to individuals in a group, but they only ever act as a group – ie they never split up. So, is this another redundant calculation where it would be much better to calculate the needs of a GROUP rather than the individuals in that group? Would this free up much power?
4. Guests in queues seem to drag performance down. The longer the queue is the worse it is. Factor in a slow load / unload strategy caused by certain ride types and you can lose as much as 50% frame rate. In this park, if I set every ride in the park to test, close then reopen (effectively clearing ALL queues) then the framerate can jump as much as 45%. Based on a hunch and watching how path finding / collision detection works (and not experience of the game code), it would appear that guests in queues have a needs reduction over time; quite rightly so. But they seem to be trying to calculate a path to something that can solve that need – which they can’t do, so they recalculate. However, when not in a queue, the path is clear and so no re-calculation is needed. This, of course, may not be the reason for it, so the only thing I can say for CERTAIN is the symptom: That guests in queues reduce performance.
5. This one is more economy based than performance – but the financial system in the game will allow you to charge 1/40th of the rides prestige. This can be quite a sum of money. But this only serves to then have guests wandering your park complaining that they have no money and walking by empty cash machines or refusing to go home. This creates some flaws in the games economy.
6. Placing paths in late-game creates a lag when placing; the more you place the worse it gets. This could be linked to the queue issue and based on the Dev Diaries from the early days, I suspect this may have something to do with guest collision and pathfinding. If you place a path with 10,000 guests the engine essentially has to “open” the path to route finding for all of these guests.
7. Menu UI loading for Scenery, Buildings, Rides etc takes a long time to load in larger parks. If you load the UI, you can sit staring at an empty grid for upwards of 5 – 10 seconds before any of the items load. This seems to be getting worse as you add DLC’s that need to be loaded too. The more objects you add to the game, the longer it takes to load sooner in the game (ie it would “slow” at 8000 guests, but now it’s around 6000). I seem to remember Parkitect (a VERY different game and engine; I know) had a similar issue where they ended up pre-loading the items at game load rather than “live”. Is something like this something that could help here?
8. Training a lot of staff in batch will make the game crawl. If you set a batch of 30 or more staff to train at once, the game will come to a crawl. Not actually sure why for this one?
EDIT!! 9. It seems that the rides and coasters have to update their heat-maps and thus their ride stats live whenever a train leaves the station (at the very least when Train 1 leaves). Surely this is redundant unless the ride is testing?!
Some possible solutions based on my observations but no knowledge of the game code:
1. Adjust the needs calculations to be fore groups and not individuals as the groups never break away from each other it seems that this is redundant.
2. Complete a full review of everything in game and take stock of what processes, simulations etc you have now. This is certainly NOT a dig at the original optimisation of the game as I believe that it was actually really good. And I must also note that 1.6.1 seemed to have a slight performance jump too. This is more about looking at the system NOW and seeing if there are any new major optimisations to be made, especially now that players are building ever increasingly large, intricate and detailed parks.
3. Check over the queue system to see if continued needs route calculations are dragging performance down. Needs should obviously decline while in a queue, but something drags performance?
And just before I go, the rough specs I am running:
i7 7700K overclocked to boost to 5.2Ghz, water cooled
32 Gb RAM clocked to 3400
Asus GTX 1070 Turbo
SSD
Asus Z170 Gaming motherboard
I’ll post an updated park to this thread tonight when I get home but I really hope this report helps in some way.
Steps to Reproduce
As above
***EDIT***
Park to use:
http://tedoshay.com/performancepark.zip
Last edited:
