Discrete event traffic simulation, laggy heads, and ghosts
a-b-street.github.io
Discrete event traffic simulation, laggy heads, and ghosts
1–5 of 5 posts
Re: Discrete event traffic simulation, laggy heads, and ghosts
#2Have you ever wondered how a traffic simulator like A/B Street works? Simulating thousands of trips through a city faster than real-time can't be done in 0.1 second increments. This article explains how to model vehicles and pedestrians using discrete event simulation instead.
This is the first deep-dive article into how A/B Street works. More coming soon!
Re: Discrete event traffic simulation, laggy heads, and ghosts
#3Thanks Dustin for the awesome writeup! Event-based also seems easier to animate in a 3D engine (pseudocode is simply "move that entity x units in y seconds") compared to constantly updating positions based on the simulation which is more akin to relatively complicated multiplayer gaming challenges to keep multiple entities in sync.
Re: Discrete event traffic simulation, laggy heads, and ghosts
#4Thanks Dustin for the awesome writeup! Event-based also seems easier to animate in a 3D engine (pseudocode is simply "move that entity x units in y seconds") compared to constantly updating positions based on the simulation which is more akin to relatively complicated multiplayer gaming challenges to keep multiple entities in sync.
Thanks for reading! I think rendering vehicles following each other would still require asking the simulation for positions, unless you replicate the logic in the "Exact positions" section. How would multiplayer synchronization factor in? That's an issue when multiple different clients in a network are all sending input to move something. Here we just have a single thread on one machine running the simulation. The simulation state could be broadcast over a network and rendered elsewhere, and there's still not any synchronization problems, because there's one source of truth.
Re: Discrete event traffic simulation, laggy heads, and ghosts
#5Thanks Dustin for the awesome writeup! Event-based also seems easier to animate in a 3D engine (pseudocode is simply "move that entity x units in y seconds") compared to constantly updating positions based on the simulation which is more akin to relatively complicated multiplayer gaming challenges to keep multiple entities in sync.
Thanks for reading! I think rendering vehicles following each other would still require asking the simulation for positions, unless you replicate the logic in the "Exact positions" section. How would multiplayer synchronization factor in? That's an issue when multiple different clients in a network are all sending input to move something. Here we just have a single thread on one machine running the simulation. The si…
Ah you're right, the vehicle queuing behavior is more complicated than the peds and I hadn't read that in enough detail.
Yes, agreed the state could be broadcast and that would not be nearly as complicated as multiplayer sync'ing.