Is it possible or realistic to improve the path finding logic? And my thoughts on it.

[Naelyi]

I've loved RCT1/2 for a long time, and recently I discovered OpenRCT2. I'm really impressed with the improvements. However, with the larger maps and increased guest/ride limits in OpenRCT2, guest pathfinding on large maps has become quite challenging.

I understand that real-time AI pathfinding for more than 7,000 guests is unrealistic, even on a decent PC. However, I have some thoughts on how we can improve pathfinding in a different way, though I’m unsure of the workload since this would fundamentally change the game’s logic.

Here is my proposal:

Instead of performing real-time pathfinding for all guests, we could perform non-real-time pathfinding for each pathway/tile. For each pathway, we can calculate several possible paths and travel times to all rides (including the use of transport rides as part of the path) and then cache a few shortest paths in a dataset (e.g., TileToRidePaths).

Whenever a pathway is modified or a ride is opened/demolished, an additional thread could asynchronously update the path data in the background. Since instant refresh isn't necessary ( guest can still use the old path until new path is ready), asynchronous updates within a few seconds should be acceptable to avoid lag for players. We might also consider not updating this data when a ride breaks down, as in reality, guests typically discover a ride is broken only upon arrival.

In large maps, the total number of pathways should be smaller than the total number of guests. Even if the number of pathways is higher than the number of guests, this approach will still allow us to perform the pathfinding in a non-real-time manner.

Then, when a guest decides to go to a specific ride (and for more realism, only for guests carrying a map can benefits from this new pathfinding system), the game can read from the TileToRidePaths to find the best path pre-calculated with the guest's current pathway/tile  location (including the use of transport rides and whether they can afford the fare to consideration).

This approach would allow guests to purposefully use transport rides and reduce the CPU cost for pathfinding by avoiding real-time pathfinding for all guests. This should also greatly improve the performance on fast/hyper speed mode, as we rarely add/remove pathway/rides during speed mode. 

Edited June 28 by Naelyi

[TheKillerChicken]

5 hours ago, Naelyi said:

I've loved RCT1/2 for a long time, and recently I discovered OpenRCT2. I'm really impressed with the improvements. However, with the larger maps and increased guest/ride limits in OpenRCT2, guest pathfinding on large maps has become quite challenging.

I understand that real-time AI pathfinding for more than 7,000 guests is unrealistic, even on a decent PC. However, I have some thoughts on how we can improve pathfinding in a different way, though I’m unsure of the workload since this would fundamentally change the game’s logic.

Here is my proposal:

Instead of performing real-time pathfinding for all guests, we could perform non-real-time pathfinding for each pathway/tile. For each pathway, we can calculate several possible paths and travel times to all rides (including the use of transport rides as part of the path) and then cache a few shortest paths in a dataset (e.g., TileToRidePaths).

Whenever a pathway is modified or a ride is opened/demolished, an additional thread could asynchronously update the path data in the background. Since instant refresh isn't necessary ( guest can still use the old path until new path is ready), asynchronous updates within a few seconds should be acceptable to avoid lag for players. We might also consider not updating this data when a ride breaks down, as in reality, guests typically discover a ride is broken only upon arrival.

In large maps, the total number of pathways should be smaller than the total number of guests. Even if the number of pathways is higher than the number of guests, this approach will still allow us to perform the pathfinding in a non-real-time manner.

Then, when a guest decides to go to a specific ride (and for more realism, only for guests carrying a map can benefits from this new pathfinding system), the game can read from the TileToRidePaths to find the best path pre-calculated with the guest's current pathway/tile  location (including the use of transport rides and whether they can afford the fare to consideration).

This approach would allow guests to purposefully use transport rides and reduce the CPU cost for pathfinding by avoiding real-time pathfinding for all guests. This should also greatly improve the performance on fast/hyper speed mode, as we rarely add/remove pathway/rides during speed mode. 

I really like that idea. I had to upgrade to a ryzen 9 5.70Ghz processor in order to handle 35,000 guests in my park. I hope that some form of SMT will be possible at some point in time as this game is mainly a single-threaded execution program.