maybe you invented a new game-genre:
It just feels a little like Banana-Software: gets ripe at the customer…
Nevertheless, Rome hasn’t been built in one day and without further due let’s be more constructive:
I get the distinct feeling that most of the stutters appear during a “waypoint-update” of the agents.
One solution to improve this possibility could be that agents update city after city, not all at once.
And also the algorithm used for wayfinding can be a reason for these fps-drops.
For the vehicles a simple “if track is blocked, search for nearest empty track at destination. If not found, repeat till all tracks at destination are checked. If all full, sleep until one vehicle exits a blocked track” can be very helpful. Also queueing at stations would be nice, like first come, first served.
Agents should just use vehicles as means of transport… agents go in and go out. Wayfinding should just be necessary between stations for transit and between start (home, work, recreation, consume) and station and between station and goal (home, work, recreation, consume). As a result only vehicles plus “walking” pedestrians/cargo need to update their paths; as soon as agents enter a station, no more update in wayfinding is needed for them, only the 20min-timer should continue. Maybe “chunking” the path could also be a solution (binary-sort-like, just a crazy idea…).
But imho a even better idea is that only _one_ pathsearch at the start of a trip of one agent should be done; the result should an array like: start at U, goto station X, use lane Y, exit at station Z, walk to station W, use lane T, exit at station S, walk to house R, done.You could also give crossings node-ids, which can be used like stations. Then it is …, walk to crossing Y, walk to crossing Z, walk to station W, … ; As a result you only have to check once a second if they have reached their target in the array. And sifting through an array should be faster than waypoint-calculation.
Granted, if a better path is developed by the gamer during one trip the agent does not use it immediately . But then again, you can sell it as: agent plans ahead and checks for better alternatives only at the start of one trip or if a path disappeared. And if the player destroys one path: is it the agents fault? So no money for the player… Or would you like to pay your public transport if they get you stranded somewhere or detour you around a block? Solution for destroyed lanes could be: if one path is no longer available: calculate new path to destination; if none exists, go home.
Long “bla” short, if not done already:
Separate wayfinding for agents and vehicles
Agents use vehicles as means of transport; while on vehicle, no waypoint-update necessary.
Vehicles use independent wayfinding with possibility to use multiple (fastest) paths if one is blocked.
Calculate path only at start of a journey; use saved waypoints for travel. (imho the best improvement in calculation-time)
Update paths not all at once.
Even if you don’t/can’t implement it because of limitations or restaints we all are unaware off, maybe a little inspiration has come out of it 🙂
Sincerely and best wishes,
PS: one crazy idea just came to mind: do you use the visualization of the paths for all agents to walk along, without painting it on screen, but they are there, invisible (Z-buffered) like the cargo-“passengers”??? Because the most severe framedrops happen when turning the camera in follow-mode of a vehicle and turning the camera horizontally towards cities in the distant. Please, don’t use Z-Buffers for paths: even if they are not painted, they are still calculated…