# Driver AI in racing game

I'm curious how I could control cars in a racing game.

Should my AI agent control its car with commands like "throttle on 0.35, steereing wheel on 0.5 right, brake on 0.0"? Or should I rather pre-compute a curve the car sticks to, and visuals like front wheels turning are just to make everything looks consistent? Or is there any other way?

• The "stick to ideal curve" strategy only works as long as there is no interference. The moment AI agents start to interact with other cars (dodging them or getting rammed) they will need to improvise. Commented May 18, 2017 at 12:52
• Yep, something like nodes along the track with boids type steering. Commented May 18, 2017 at 13:04
• Here is an article on AI in Colin McRae's Rally 2. Commented May 18, 2017 at 16:18
• @gre_gor, this is very helpful article, thank you! Commented May 19, 2017 at 10:15

We can say that at some level the game is following a pre-computed path. Since the tracks of the racing game are (usually) a pre-computed path anyway.

Even if we are talking about generating the tracks by random, the game must have computed the current portion of the tracks for the moment where the car gets there.

Well, that was easy. Anything else about it?

Both, following a pre-computed path and controlling the car systematically have uses in the game industry. The answer is to use both, sort of.

First off, I want to mention that "computing a curve" can mean two things:

• Creating functions that will output the position on the curve, having as parameter how far on it you want to query.

• Creating a path, understood as list of points (or instructions and other control information) to follow.

The former can be useful for prediction or in some physic simulations. Yet, when we talk about controlling an object, the latter is the recommended approach.

Note: For older games (1980's) the other cars where more like moving obstacles. They were there for you to avoid them and surpass them. We are not talking about those.

• Following pre-computed a path: This is useful for cinematics or repeatable scenes. For example in GTA San Andreas the chase missions the chase target and all the cars follow a predefined path (this ensures that the chase target can avoid the traffic※). Yet, as soon as you perturb them they fall back to AI control, in this case the AI will have to path find to get to where it should be following its regular path.

※: In fact, it was prerecorded. Record and playback was one of the new features of the GTA SA game engine.

• Controlled by AI:

The AI at its simplest form is a state machine. It checks on what state it is and executes some action depending on that. I will be referring to these combinations of state and action as behaviors. The actions do not have to match the player's gamepad. Neither do the behaviors.

For a simple game, you probably only need two notable behaviors: 1) if it is on the tracks then follow the track avoiding other cars and any obstacles and 2) if it is not on the tracks, get back on the tracks.

At this stage, it is not far from following a path (the tracks). Yet, since the tracks are not really a line, we are not talking about following a path, but staying close to it (while avoiding other cars and any obstacles). Meaning that the AI has to solve “steering, braking and accelerating”.

For a modern game, the car will also be subject to physics simulation (to resolve collision and keep realism). Because of that, each iteration of the game loop the car will updated based on its speed and acceleration, and also “steering, braking and accelerating” (tweaks to speed) will be applied to follow the current behavior.

I also want to mention that modern games may have behaviors that are more complex, for example, the AI may choose to hit another car or to block their way. In fact, the AI may even choose which to apply based on some form of machine learning, but I digress.

Finally, consider that it may also be useful to have a simpler control for AI cars outside of player view. Either for performance or for Rubber Banding (which in this case keeps AI cars close to the player to keep the race interesting, it can be regarded as the AI cheating when you can't really leave behind any opponent).

About animation, it usually not a good idea to simulate physics for the wheels independently. If you do it, it would may add realism to the game, but will cost performance. Usually the game will animate the wheels based on the behavior instead of expressing the behavior in terms of movement of the wheels and simulating the consequences.

Of course, you may need to put additional consideration in whatever or not the wheels are in contect with the ground. And perhaps animating suspension.

• This is just wonderful answer, thank you very much. Commented May 18, 2017 at 13:39

I strongly recommend separating the car physics/state model from the car controller, and making the AI agent and the player controller be two kinds of interchangeable controller, with high level commands like the ones you suggested in your question.

This has a number of nice effects:

• You can implement and debug the physics/state model once for both player and AI
• Any new features of the physics/state model immediately apply to both the player and AI
• Player and AI cars behave consistently on the track, which increases perceived and actual fairness (if you want to handicap the racers, of course, you can do it by changing parameters on the cars)
• Various kinds of multiplayer support become much easier to develop.

This is a particular case of MVC separation, by the way.

• I like this answer, but that final statement is just absurd. Remove it and you have a point from me. Separation of Concerns? - Certainly. But MVC does not apply across the context of your full answer. Commented May 18, 2017 at 18:33
• Apart from the fact that the View aspect isn't discussed in the question or answer, why do you think it's absurd to frame this as MVC? Commented May 18, 2017 at 20:40