Traffic system in a game?

Blitz3D Forums/Blitz3D Programming/Traffic system in a game?

Pongo(Posted 2009) [#1]
Does anyone have any ideas on how to implement a basic traffic system in a game? I'm not necessarily looking for code, although I'd sure like to see some. I'm interested in either 2d or 3d approaches, since I figure the concepts should be the same for both.

Here is an image that I have made up to help discussion.


What I am looking to do is populate the roads with some cars. The yellow dots are waypoints, so a single car should be able to move around in this manner, picking a random waypoint at an intersection.

Additional cars can be added into the system, but then the issues of collision avoidance start to happen. For example, how can I get cars to line up behind a stopped car without simply plowing into it? Distance based collision would work somewhat (don't allow a car to move if it is too close to another car) but this falls apart when cars are traveling in different directions and get close to each other.

Anyways, I'm just looking for ideas here. It doesn't have to be actually correct, but I want it to look correct if that makes any sense.


nawi(Posted 2009) [#2]
You need to check if the car is both close enough and in front of the car (just calculate the angle between the two cars centers, and compare with the angle of the car). You could then either implement red lights (make a zone where the first car will stop in front of the red light, if the red light is on.) Or you could implement a right of way system.


stayne(Posted 2009) [#3]
Try using a pivot on the passenger side front and rear. That way traffic in opposing lanes won't attempt to avoid each other since the pivots are on opposite sides of the cars. For same lane traffic you could match the speed of the car behind with the car in front according to pivot distance (with a bit of slack of course to simulate acceleration/deceleration).

Just a basic idea. I am sure it could be done much more elegantly with some nifty math.


Stevie G(Posted 2009) [#4]
The simplest method of checkng cars in front and behind is using tformpoint. e.g.

tformpoint 0,0,0,ThisCarEntity, ThatCarEntity


Pseudode ..

if tformedz() > 0 then This car is tformedz() units in front of That car
if tformedz() < 0 then This car is tformedz() units behind That car
if abs( tformedx() ) > ( This Car Width * .5 + ThatCarWidth * .5 )  then That car will not collide with This car if stays on current heading.


Using a combinations of these tformed results you can determine whether breaking is required, the car in front has stopped at traffic lights etc...

Give me a shout if you need a hand.

Stevie


Pongo(Posted 2009) [#5]
Thanks for the comments. I will have to try setting up some code to see how this might work. These methods seem to make sense, but I wonder if there isn't an easier way. I'm concerned about the overhead of tracking a larger number of cars through a larger map.

Baby steps first though,... I'll try to get things working with a single straight road, followed by a single intersection,... then onto something like the pic I posted above.

Do those waypoints look correct? Do I need more? can I get away with any less?


stayne(Posted 2009) [#6]
Good luck with it Pongo, I'm sure it's going to be quite the task. I've seen AI cars slamming into each other and getting hung up for several minutes in big games like GTA and Test Drive Unlimited. I can only imagine how tough it would be to code the logic where an AI vehicle needs to recover from being spun around...while facing a wall head on :). As far as waypoints go if you are using aligntovector you could probably get away with less as long as you force the AI cars to slow down before curves.


Pongo(Posted 2009) [#7]
Yea, I know.

Right now I'm just in the early phase of things, and I need to find out if I can make things work. The basic gameplay is get from point A to point B within a certain amount of time. The cars need to be there only to create interference. That's why they don't need to necessarily do everything correct,... they are simply moving obstacles. (Although I would like the ability to knock them aside, rather than them being solid fixtures.)

Gameplay is also going to be top-down, so 2d works as well as 3d for this.