OpenRCT2
OpenRCT2 copied to clipboard
OpenRCT2
Improvement: Characters should pathfind through transport rides.
Version: <=0.3.1
- [x] Reproducible in RCT2 (vanilla)?
- [ ] Specific to multiplayer?
Steps to reproduce:
- Create a section of the park that is only accessible by transport ride.
- Create rides in this section of the park. Guests will be unable to find the distant section of the park, and complain that they can't find the rides there. If a ride is broken down in the distant section, mechanics from the main section will be unable to reach the ride, but will still make an attempt. Without manual intervention, this prevents the ride from being fixed, as the single mechanic attempting to reach it locks out other mechanics that are able to do so (this is especially troublesome in multiplayer, where manually-set staff paths don't always sync between clients).
Screenshots / Video:
This may cause a catch 22 with pay-per-ride, unless the transport ride price is set to free: Guest x33 pays to go on the transport ride Guest x33 pays to go on the isolated ride Guest x33 is stuck because because their cash doesn't cover the transport ride fee -Now we're back at the current situation...
That's like a no-entry banner in front of the park exit, and more an issue to solve by the player. Fortunately RCT2 features ATMs.
Theoretically that can happen in the current version. Guests can reach the isolated ride, but only if they happen to randomly take the transport. If there's any way to spend money over there they could get stuck. Thinking of real-life parks, such transportation is usually free.
It'd be difficult to find and track a single guest that's stuck like that, unlike with staff where you might only have a handful to keep track of.
Edit: Adding pathfinding through transport rides could help fix this issue. If a guest is incapable of reaching a ride due to an expensive transport ride, the game could pop up a new thought like "I don't have enough money to get to (target ride)!" It could say something similar if the guest is prevented from leaving the park in this way (although it's partially covered by "I want to go home")
I would just solve the issue by only having free rides count as part of pathfinding. I mean, it would be like if Disneyland expected you to pay for a ride to a specific part of the park. You'd treat that like a ride rather than a path to somewhere else.
I was sure that this was a duplicate issue but I can't find the original one. It has always been the intention to improve the pathfinding to account for transport rides rather than the current setup where there is only an increased preference to use transport rides.
Without manual intervention, this prevents the ride from being fixed, as the single mechanic attempting to reach it locks out other mechanics that are able to do so
Are you suggesting that staff (or at least just mechanics) should be able to ride transport rides?
Also, before this progresses too far, I'd like to ask that non-transport type rides with transport-like track layouts be considered in this as well. Should this still work if, for example, you replaced the transport ride between the two isolated places with a two-station log flume transporting between the two places? Or should it be strictly only for transport rides?
@ocalhoun6 Yup, but non transport rides should probably have a higher pathfinding cost than transport rides, making guests prefer transport over rides (I want to get to my destination WITHOUT riding the entirety of Mr. Bone's wild ride, thanks) and prefer short times over high ones.
Sounds really cool to me. This always disappointed me as a child - I liked making separate islands and only having transport rides between them, especially in RCT3 with the tonnes of cool transport rides.
It does deviate from the main game a bit though, so it might be better off as a plug-in, or at least as an option.
@SijmenSchoon It's a QoL feature. I'd say it'd make perfect sense in the official, as we're not stuck in the 1990s anymore.
It looks like someone thought about doing this a long time ago, but never followed through: 113c41b97699f40236f06dd8dc7175d799baff92
I looked through the code very briefly and I feel the scope of the work is quite extensive. Apart from the source code directly, are there more technical materials written about path planning?
This would be a huge quality of life improvement if it were to be implemented and give transportation rides a true meaning and purpose. Is this on any roadmap at this time since I know it's been a while since opened?
It's a pretty daunting task, requiring a lot of from-the-ground-up coding. It would require a lot of rethinking how the pathfinding algorithm works, since as I understand it, peeps/staff usually don't have the entire route planned out in advance when they're navigating somewhere -- they only look a few turns ahead. And then you have to factor in things like how fast the rides move vs. how fast they walk (for different walking speeds and different ride times between different stations), how long the Q lines are, how long it's likely to before the next train arrives at the station, etc.
And if you're going to have staff (mechanics) riding rides to get where they're going, you'd probably need to make a bunch of new sprites/drawing code because there currently aren't any sprites available for a mechanic riding any ride. (It would be pretty ugly if the mechanic suddenly turned into a regular guest when he sat down on your miniature railroad train.) From what I understand at the moment, the sprites for drawing peeps on a ride are actually part of the ride vehicle's sprites, so every type of vehicle a mechanic could possibly ride would need new sprites to show him riding it.
This could be achieved rather simply with a dijkstra algorithm, and then have the transport ride have the other exits and entrances connected.
Ignore my amazing art skills, but it gets the point across I hope
Ideally, the user would be able to choose between modern and classic pathfinding. Therefore, we would really like to make the pathfinding routines more modular before we rigorously change the approach. This should happen before a new pathfinding algorithm is introduced.
As for the algorithm, while Dijkstra's is a fundamental approach, it may be a bit naive. We have had an experimental PR for A* in the past (#6440). I think such a weighted method may lead to better results.
Ideally, the user would be able to choose between modern and classic pathfinding. Therefore, we would really like to make the pathfinding routines more modular before we rigorously change the approach. This should happen before a new pathfinding algorithm is introduced.
As for the algorithm, while Dijkstra's is a fundamental approach, it may be a bit naive. We have had an experimental PR for A* in the past (#6440). I think such a weighted method may lead to better results.
I'll start working on making the current pathfinding more modular so I can start on a new pathfinding system.
Please check with @duncanspumpkin as well; I believe he had some plans for this.
I think pathfinding being modular is a good thing, but I don't know if I agree that the user themselves should be choosing. I imagine it should either depend on the scenario, or perhaps be set on a peep by peep basis (with cheats so that the user can change it if they want). Otherwise the high scores generated aren't going to be strictly comparable anymore.
The main rationale behind making it modular is so that it can be switched. As for it being per peep, why? Surely that would remove the whole purpose of the improved pathfinding, hiding it in some obscure cheat menu and you having to go through and enable it for each of your few thousand peeps?
I don't actually think per peep would be a good idea, I just figured if people thought it wasn't something that should be scenario specific then that was an alternative example. The main point I wanted to make is that giving the user direct control over something like this without making a cheat is basically giving them a difficulty setting switch without any indication of what "difficulty" they're using reflected in any end result.
One advantage of having per peep would be that you could make peeps with maps smarter. It wouldn't make sense if a peep without a map could just pathfind the most optimal path to a ride from anywhere.
You could also adjust it based on their needs, e.g. a tired peep could prefer transport rides over walking, even though walking would be shorter.
There are a few things to consider when it comes to transportation rides:
- What happens when the queue is full.
- Should guests consider the time between waiting for the transportation ride to arrive vs walking.
- Should guests consider the time the ride will take vs walking.
- The cost of the ride.
- Guests should not have god like knowledge, they must own a map.
- Should they prefer rides when it rains?
- How does a guest determine when to take a ride instead of walking: random, happiness, energy, etc.
The path finding is from a technical standpoint easy, keeping the game balanced not so much.
Also, what should be kept in mind, is that Sawyer most likely considered this exact feature when designing the game, but decided not to for some reason - very likely either performance (less relevant nowadays) or game balance (still very much relevant)
The decision was probably a bit of both, performance and balance. It would be really odd if peeps would start using transportation rides only from when they are available, but performance was probably the biggest concern back then, having 32 MiB memory was pretty good when the game was developed, so caching off all possible paths was probably a bad idea back then, recomputing them all the time even worse.
I'd say not all guests should have the same patience too, so some would value the transport ride less than others depending on queuing times and etc
There are a few things to consider when it comes to transportation rides:
- What happens when the queue is full.
- Should guests consider the time between waiting for the transportation ride to arrive vs walking.
- Should guests consider the time the ride will take vs walking.
- The cost of the ride.
- Guests should not have god like knowledge, they must own a map.
- Should they prefer rides when it rains?
- How does a guest determine when to take a ride instead of walking: random, happiness, energy, etc.
The path finding is from a technical standpoint easy, keeping the game balanced not so much.
Stuff like the cost of the ride can use pre-existing calculations, and everything else would just be messing around with numbers. All of the criteria is easy to meet, sorta of the main reason of using a weighted graph.
You would increase the weight of taking the transport ride based on all of those factors.
- If the queue is full add 1000 to the weight
- If the ride costs too much add 1000 weight
- If they don't own the map, ignore the ride from pathfinding
- You could decrease the weight of the ride when its raining, make the guest more likely to use it.
- If the guest has lots of energy, increase the weight of the ride, if the guest is low on energy decrease the weight.
The hard part is the implementation of the pathfinding itself, as opposed to the deciding factors of taking the ride
A big problem is that it would be nice to be able to have a transport ride to move between different areas of the park, but if they need to be using a map to ride the transport ride, then they should arguably not be able to know about rides they haven't already been nearby, otherwise you'll still get peeps complaining that they can't find a ride when they don't have a map, because of the transport ride that's necessary to path through, which could create a negative change on the park.
Ideally you could store what rides the peep "knows" in some temporary memory and until they get a map they wouldn't be able to specifically target any other rides to find, but that would require a lot of extra overhead, so I still think it would be better to have some sort of compromise, like that peeps consider free transport rides for pathing even without a map.
One question that comes to mind here is if peeps need different ride logic.
Specifically, should peeps be allowed to choose to stay on the ride so that they can use another exit station?
@henke37 Oh no -- that would make things even more complicated!
Just have the peep exit the transport ride normally at each station, and then pathfind from there. If the optimal path from there means getting on the transport ride again, they'll have to go through the queue of the next station to keep going.
@ZehMatt Another balance issue might be that this suddenly makes transport rides much more popular ... making the transport rides constantly overwhelmed with more peeps than they can handle, especially in big parks. Some transport rides have pretty low throughput, but there could be lots of peeps trying to pathfind through them. (While a path has infinite throughput. Peeps will complain about overcrowding if the path is too full, but none of them will be blocked or delayed trying to get through.)
That's a big reason I think the pathfinding should maybe depend on scenario, because older scenarios were obviously designed without this sort of thing in mind and it could drastically alter game balance, but if you designed a scenario with, say, two big areas of the park that are disconnected and very far apart with only a small amount of rented land between them (or if possible just a single transport ride that exists on area the player can't own, because that's an interesting concept, that they can't demolish the ride), then it would make sense why peeps need to use the transport ride.
For the sake of memory and processing limits I agree that it makes more sense to just have peeps get off and on, but I think this all adds to the overall challenge of making sure your transport rides are efficient (ie, many short trains instead of fewer long ones).