I don't know the intricate level of detail which you use to manage the "people traffic", but, from an observational and programming perspective, I would like to suggest the following, for serious consideration.
I seems, to me, that you are doing a collision-check, for every person, at every iteration. This is a bit excessive, as its only even needed when there is nearness, and motion. There does not seem to be any generic rules for walking, or if there is, they are not being obeyed, or can't be, due to the collision detection issues.
First, some standards, for a rule of thumb...
1: People veer right (or left), when moving forward, but you have to pick ONE.
2: "Groups of people", who are a family, tend to line-up behind ONE person, who leads, "through a crowd". EG, when encountering a high traffic area, they will change from a side-by-side or 2x2 block, into a single-file line of 1x4.
3: When encountering a "crowd", which looks impassable, or highly resistant to traversal, people will instantly look for another path "through", or "around", or change their destination to a new one, which is unobstructed. EG, Before getting to an over-crowded impassable location, they will opt to take a longer path, which is shorter, by "traffic-time", or just jump onto a ride that is close-by, in hopes of traffic clearing, or canceling their plans for anything past the crowded location.
4: People with no specific "target objective", will often yield to oncoming persons. They normally walk slower, signifying that they have no real destination, while someone with a set destination, tends to walk faster, with "somewhere to go". Casual walkers will also tend to hang-out at the edges of a path, or in empty spaces, as opposed to joining a crowd and causing more impedance. They will also be the FIRST to avoid traffic and find a less crowded path to get to NOWHERE.
5: Touching on #4 and #1. Like with cars, high speed traffic tends to be on the inner-lane, while outer lanes are normally reserved for exits and parking. People walk the same way. Slow, casual walkers tend to hug the curbs. While fast, further destination-bound walkers, tend to gravitate to the center of paths. Veering right, or left, avoiding any oncoming foot traffic.
6: Yes, crowds are unavoidable and a naturally occurring event. But not the extent which the game portrays. People slow-down, before hitting a congested area, and few try to brute-force (through crazy collision detection), to the other side. Some will naturally yield, while others WILL just try to brute-force, within reason. (Not trying vibrate, like pachinko balls, through a crowd.)
7: When someone is "on your butt", you tend to walk a bit faster, considering looking for a "free space", to move out of the way, if you have no destination currently set. You will just take a random right or left at any fork, and attempt to aid in the ease of congestion. Especially when exiting a ride.
Now, with those generic considerations for "human behavior", which I do not see exhibited in the game, at all... I also want to suggest the following ideas. The ones above are something that can be done, easily, in code, to the lowest extents. Simply using a logical 4-lane split on a path, simple "shortest path calculations", and giving "placement desires", as well as using "walking speeds".
When it comes to rides... I noticed the most annoying occurrences, related to people entering and exiting rides. You make people wait, to get into a ride, until every last person has completely exited a rides exit. Most rides, in a real park, will allow people to "enter", WHILE people are "exiting". In the least, as soon as the ride has cleared, new people will begin entering, to be seated. Often managed by having a clear, and often isolated, entrance and exit side to a ride. (Get in on the left, get off on the right. Or, there is a person who acts as a "wall", isolating the exiting crowd from the entering crowd.) That simple action can also assist with overcrowding. Since, people are "exiting", BEFORE people have begun to "enter", and they are exiting right into crowds that are waiting to get into the queue-line. If the people are both entering and exiting, at the same time... (no collision needed for those entering, on those exiting too) Then there is already some decongestion being done, at the queue-line entrance, before anyone reaches the exit. There is a "space" for them to walk into.
When it comes to "walking around"... Yes, get the destination, get the path-selection, but don't act so bluntly on it. People tend to follow others, going the same direction. If you know that person B is behind person A, and they are both traveling the same four sections of path, before parting ways... You ONLY need to calculate person A, and person B is just walking in person A's prior footsteps. No collision detection needed, since they are FOLLOWING person A, and they are doing everything that person A is doing... If A stops, so does B. If A and B are tailing one-another, without a space between them, no other person should be "calculating a path between them". This extends to "groups" too. A group, obviously trying to stay together, is virtually only one collision-check needed, once they form a "line" to slice through a crowd.
You can also get better "flow", simply by, like in reality, lowering your collision restrictions. When there is no crowding, people would naturally avoid one another. It is normal to use a wide collision detection and limit for them, so they veer properly and leave more passing-space for others. When crowded, you can lower your collision-detection area, as people would normally pass, shoulder-to-shoulder. (Having a matching animation for that would also be ideal. A path, loosely setup as 4-lanes, would become 6 or 8 lanes, for "twisted passing".) However, if the above things are programmed, this should not be a common occurrence.
People who have "been here before", know their way around. They know the "crowded spots", and would prefer to "take a path of least resistance". Also, they tend to have multiple potential destinations, as alternatives, for avoiding traffic. They know where the less popular food locations are. They are not often "sight-seeing", unless there is something new to see. (So they are not often rubber-necking, or lingering where it is already reaching "crowded status".)
I don't have any citations, but the biggest thing that will help traffic, is literally, traffic coding. The only thing, code-wise, I can suggest to implement, because it doesn't seem like it is being used, at all... Is "weighted shortest paths". It is a simple algorithm, which gives weighted factors to path-segments. Such as a path being crowded, thus, also being slower. A path being narrow, thus, potentially a congestion spot. Which adds a form of virtual length, as "time", to various paths. Ignoring the raw "shortest path", as it is not the shortest, "in time", to get to the destination. (It would require each person to "drop" a value into each path-segment data-field, after they traversed it. Kind-of like googles traffic-monitor that records your speed as you go down certain roads, to monitor for traffic-jams. This code is often used in games that have realistic traffic simulations, like city-skylines.) Open areas, you could just use a simple "bit-map" style database, for speed. Creating a heat-map of traffic, or using that heat-map, internally, to do your AI pathing.
All my suggestions are simply due to the fact that I am tired of seeing traffic-jams, for no apparent reason, all over. People seem to have an AI lower than a blind slug in this game.
Also... Give us another "path type"... Called, "Path Area". So we don't have to use "hacks", to make wide, non-standard pathing areas. Paths are great, for paths. Areas for walking, which are not real "paths", need to exist too. Paths should easily connect to them, but they should be editable, like an object or a roller-coaster, to shape them. (Adding more points and curves and adding negative "cut-out" sections where people should not be walking.) That would also give more "free space", for people to huddle into groups, while keeping "virtual lanes", at the edges, for "traffic". Just adding that any object placed into a "path area", would optionally be an "obstruction". Perhaps the option selected in the object itself, but defaulting to being an obstruction when added to a "path area". Like, adding a rock or a planter or a light, or a bench, versus adding a sidewalk-star or a curb-spacer.
I seems, to me, that you are doing a collision-check, for every person, at every iteration. This is a bit excessive, as its only even needed when there is nearness, and motion. There does not seem to be any generic rules for walking, or if there is, they are not being obeyed, or can't be, due to the collision detection issues.
First, some standards, for a rule of thumb...
1: People veer right (or left), when moving forward, but you have to pick ONE.
2: "Groups of people", who are a family, tend to line-up behind ONE person, who leads, "through a crowd". EG, when encountering a high traffic area, they will change from a side-by-side or 2x2 block, into a single-file line of 1x4.
3: When encountering a "crowd", which looks impassable, or highly resistant to traversal, people will instantly look for another path "through", or "around", or change their destination to a new one, which is unobstructed. EG, Before getting to an over-crowded impassable location, they will opt to take a longer path, which is shorter, by "traffic-time", or just jump onto a ride that is close-by, in hopes of traffic clearing, or canceling their plans for anything past the crowded location.
4: People with no specific "target objective", will often yield to oncoming persons. They normally walk slower, signifying that they have no real destination, while someone with a set destination, tends to walk faster, with "somewhere to go". Casual walkers will also tend to hang-out at the edges of a path, or in empty spaces, as opposed to joining a crowd and causing more impedance. They will also be the FIRST to avoid traffic and find a less crowded path to get to NOWHERE.
5: Touching on #4 and #1. Like with cars, high speed traffic tends to be on the inner-lane, while outer lanes are normally reserved for exits and parking. People walk the same way. Slow, casual walkers tend to hug the curbs. While fast, further destination-bound walkers, tend to gravitate to the center of paths. Veering right, or left, avoiding any oncoming foot traffic.
6: Yes, crowds are unavoidable and a naturally occurring event. But not the extent which the game portrays. People slow-down, before hitting a congested area, and few try to brute-force (through crazy collision detection), to the other side. Some will naturally yield, while others WILL just try to brute-force, within reason. (Not trying vibrate, like pachinko balls, through a crowd.)
7: When someone is "on your butt", you tend to walk a bit faster, considering looking for a "free space", to move out of the way, if you have no destination currently set. You will just take a random right or left at any fork, and attempt to aid in the ease of congestion. Especially when exiting a ride.
Now, with those generic considerations for "human behavior", which I do not see exhibited in the game, at all... I also want to suggest the following ideas. The ones above are something that can be done, easily, in code, to the lowest extents. Simply using a logical 4-lane split on a path, simple "shortest path calculations", and giving "placement desires", as well as using "walking speeds".
When it comes to rides... I noticed the most annoying occurrences, related to people entering and exiting rides. You make people wait, to get into a ride, until every last person has completely exited a rides exit. Most rides, in a real park, will allow people to "enter", WHILE people are "exiting". In the least, as soon as the ride has cleared, new people will begin entering, to be seated. Often managed by having a clear, and often isolated, entrance and exit side to a ride. (Get in on the left, get off on the right. Or, there is a person who acts as a "wall", isolating the exiting crowd from the entering crowd.) That simple action can also assist with overcrowding. Since, people are "exiting", BEFORE people have begun to "enter", and they are exiting right into crowds that are waiting to get into the queue-line. If the people are both entering and exiting, at the same time... (no collision needed for those entering, on those exiting too) Then there is already some decongestion being done, at the queue-line entrance, before anyone reaches the exit. There is a "space" for them to walk into.
When it comes to "walking around"... Yes, get the destination, get the path-selection, but don't act so bluntly on it. People tend to follow others, going the same direction. If you know that person B is behind person A, and they are both traveling the same four sections of path, before parting ways... You ONLY need to calculate person A, and person B is just walking in person A's prior footsteps. No collision detection needed, since they are FOLLOWING person A, and they are doing everything that person A is doing... If A stops, so does B. If A and B are tailing one-another, without a space between them, no other person should be "calculating a path between them". This extends to "groups" too. A group, obviously trying to stay together, is virtually only one collision-check needed, once they form a "line" to slice through a crowd.
You can also get better "flow", simply by, like in reality, lowering your collision restrictions. When there is no crowding, people would naturally avoid one another. It is normal to use a wide collision detection and limit for them, so they veer properly and leave more passing-space for others. When crowded, you can lower your collision-detection area, as people would normally pass, shoulder-to-shoulder. (Having a matching animation for that would also be ideal. A path, loosely setup as 4-lanes, would become 6 or 8 lanes, for "twisted passing".) However, if the above things are programmed, this should not be a common occurrence.
People who have "been here before", know their way around. They know the "crowded spots", and would prefer to "take a path of least resistance". Also, they tend to have multiple potential destinations, as alternatives, for avoiding traffic. They know where the less popular food locations are. They are not often "sight-seeing", unless there is something new to see. (So they are not often rubber-necking, or lingering where it is already reaching "crowded status".)
I don't have any citations, but the biggest thing that will help traffic, is literally, traffic coding. The only thing, code-wise, I can suggest to implement, because it doesn't seem like it is being used, at all... Is "weighted shortest paths". It is a simple algorithm, which gives weighted factors to path-segments. Such as a path being crowded, thus, also being slower. A path being narrow, thus, potentially a congestion spot. Which adds a form of virtual length, as "time", to various paths. Ignoring the raw "shortest path", as it is not the shortest, "in time", to get to the destination. (It would require each person to "drop" a value into each path-segment data-field, after they traversed it. Kind-of like googles traffic-monitor that records your speed as you go down certain roads, to monitor for traffic-jams. This code is often used in games that have realistic traffic simulations, like city-skylines.) Open areas, you could just use a simple "bit-map" style database, for speed. Creating a heat-map of traffic, or using that heat-map, internally, to do your AI pathing.
All my suggestions are simply due to the fact that I am tired of seeing traffic-jams, for no apparent reason, all over. People seem to have an AI lower than a blind slug in this game.
Also... Give us another "path type"... Called, "Path Area". So we don't have to use "hacks", to make wide, non-standard pathing areas. Paths are great, for paths. Areas for walking, which are not real "paths", need to exist too. Paths should easily connect to them, but they should be editable, like an object or a roller-coaster, to shape them. (Adding more points and curves and adding negative "cut-out" sections where people should not be walking.) That would also give more "free space", for people to huddle into groups, while keeping "virtual lanes", at the edges, for "traffic". Just adding that any object placed into a "path area", would optionally be an "obstruction". Perhaps the option selected in the object itself, but defaulting to being an obstruction when added to a "path area". Like, adding a rock or a planter or a light, or a bench, versus adding a sidewalk-star or a curb-spacer.
Last edited: