Talk:GSoC BattleAI

More Details about AI for Battle Mode

Some basic information is contained in ticket 456, which contains some logs from IRC.

The current racing AI (Artificial Intelligence) is based on a simple way point system: the designer of a track adds a special mesh which indicates the left and right side of the track where the AI is supposed to drive on ( see the documentation on driveline are created). This mesh is converted by the track exporter into a graph of quads (in 2D actually, the current AI does not use height information at all). The quad graph structure is described here. The AI will basically aim at the center point of those quads.

For arenas (i.e. tracks used in 3-strike battle mode) no drivelines are defined at this stage.

To design a battle mode AI two major problems need to be solved:

  1. Letting the AI know where it can drive.
  2. Using this information to teach the AI what to do.

Letting the AI know where to drive

Auria has provided a simple arena (stadium) with a quad graph, and exported it as a (lap-based) track. This means that the data files described on our wiki will contain all the quads, but the graph is directed, and the karts will only drive in a circle. But this means that you can use the files, extend the XML data files (and of course also STK) to read in a more flexible data structure and use it, without knowing any blender (though blender knowledge would still be useful for this project, since you might have to modify the quads). The zip file with the exported track and blender model file is in our Add-ons section. Just unzip this file into the data/tracks directory, and STK will detect this track as a race track (not arena) next time you start it.

Here a short discussion on the pro- and cons of two design choices. Of course, other implementations are possible, there is no need to pick any of the two discussed here:

Define a Quad Graph for the AI

The designer of each arena needs to define a similar quad graph which is then read by the AI. It's not certain that quads are the best choice, perhaps triangles or others might work better. For here the word quad and quad graph will be used. Advantages:

  • The quad graph can be used to help the AI driving. For example it can be adjusted by making the quads smaller, or make them following less the actual track to drive on sharp turns.
  • Existing AI code for following a list of quads can be reused.


  • More work for track designers.
  • Large quads might need to be split manually. For example, imagine a track in a stadium, where the stadium floor is just one big rectangle. This might not be detailed enough to allow the AI to 'follow the quads' - since there is only one, making this whole design useless. Either more work then is needed to drive within a quad, or the quads need to be split into smaller pieces.

Use Texture Information for the AI

The AI could use the information about the track mesh and which texture is applied to determine where it can drive. Advantages:

  • Nearly no work for track designer (only work is to define for each texture if it's drivable or not)


  • The same texture might be used for parts that are drivable and not-drivable. For example, a tunnel might have the same texture on the floor and on the wall and ceiling. The AI must still know that it can drive on the floor, but not on the walls/ceiling. Textures could be duplicated (rock_drivable and rock_not_drivable), but this has performance impact (since then two textures need to be transferred to the graphics card instead of one).
  • Building coherent paths automatically is more difficult than by hand. An AI implemented this way should not wander from quad to quad randomly, it should still need to drive using straights and curves, as well as avoid areas where it can get stuck or fall off. Determining this algorithmically is much more difficult than when done by a human

Teaching the AI what to do

Once the AI knows where it can drive, this information must be used to define the strategy, e.g.

  • when to try to pick up an item
  • when to avoid items, e.g. if it has an item that is good or selected more than one item of a kind
  • which kart to aim for
  • how to hit it (e.g. approach from behind, front, ...)
  • how to get to the kart it has determined to hit


Some details of this task are captures in ticket 456, based on some discussions on IRC. To do this tasks a good programming knowledge (preferable in C++) is necessary. And while changes to the export scripts can be done by the STK team(once the specification on what needs to be exported is done), it would be useful to have (or be able to acquire) basic blender knowledge (to create necessary information and test the exporter), and perhaps python (in order to do quick changes to the exporter script). On top of that, some experience with path finding and other AI algorithms will be useful.