categories

Last week’s sketches introduced the idea of a lookup table, where each situation in the game corresponds to a cell in the table. Each of these situations has a corresponding behavioral response.

To help illustrate these lookup tables in practice, here’s a simple example of the behavior of a lazy soldier (long story :), represented as a lookup table.

The lookup table makes it easy to understand this simple situation, but if you simply add one boolean variable to represent the situation more accurately, the table doubles in size. In effect, you have twice as much work to do to edit the behaviors.

Now, the problem is that the average actor needs many variables to model the situation, and even more for the internal state. Having to take into account two dozen of these variables is not uncommon. This makes the table grow very quickly in size.

The number of necessary behaviors grows exponentially larger very quickly along with the variables. This is known as the curse of dimensionality, as each variable can be considered as a separate dimension to the problem.

White tables have their advantages for understanding simple problems, it becomes almost impossible to edit the behaviors exhaustively using a large table. Thus, an alternative solution is required…

Next week’s Sketches explain how game developers cope with this curse by dealing with all these problem variables selectively.