Agent Data

Each active agent maintains its position, direction and speed: the agent position is updated depending on speed and direction, and taking into account possible collisions against non-walkable areas. The direction taken by an agent depends on its behavior, i.e. wheter it is a civilian, zombie or policeman, plus its current status. The complete set of rules is the following.

Coordination Rule

When agents are near each other, they tend to move in the same direction. In the current implementation, this rule is enforced only on civilians, and depends also on their current amount of 'stress' (currently represented by the steer friction parameter. When a civilian is panicking or got stuck somewhere, they will be more likely to behave as similars around them.

Avoidance Rule

Collision Rule

This rule gets applied whenever an agent's movement would bring them in an unwalkable area (i.e. against a wall). The collision rule, as it it now, makes agents behave in a pretty stupid way: Whenever they hit a wall, their stress parameter increases and they will try to move in the first free direction they find, rotating clockwise. Since tre agent stress parameter increased, they will likely follow nearby agents, increasing the possibility of finding a meaningful path away from the obstacle. When lots of agents are present, their collective bahavior will be acceptably correct, despite this rule being an oversimplification of human behavior.

Predator Rule

This rule is the core of the predator (ok, zombie ^_^) behavior: when a civilian in in a predator's awareness range, they will run at them. When a predator is close enough to a civilian (the kill range), the civilian will become infected, while the predator hunger will go down for some time: the predator won't attack other civilians for a while. An infected civilian will look dead for a while, then turn into a zombie.

Fighter Rule

This rule is used to represent agents that try to actively fight zombies (for instance, armed policemend). The rule is overall pretty simple to the predator rule explained above: fighters will try to attack zombies in their awareness range, and if a zombie gets into the kill range of a fighter, it will die. After killing a zombie, fighters cannot immediately kill another one: this is used to simulate 'fighting time': different values for this parameter can be used to implement different scenarios (i.e. killing a zombie barehanded would require more time than using a machinegun)

Memory alignment

One of the most challenging things encountered while implementing this application was understanding how memory alignment works with CUDA. In my code, I pass an array of a custom struct data (my agent data) back and forth from the kernels. While compiling code for device execution, CUDA performs 8 byte alignment on the data. This can be seen in the previous debugger screenshot: a dummy variable has been added to the agent structure. The problem is that alignment is not performed on the host version of the structure, but the structure is still seen at the same type in host and device code: and memcopy operations are legal but they do not take the alignment into accout. Result: memcopies from and to the device will turn most of your data to garbage.

Inconsistent execution

Another quite serious problem arises when executing less-than-perfect code on a CUDA device: if a kernel does not end execution correctly, and resources are not consistently cleaned up, the CUDA device is apparently left in an unstable state: the same application may fail or run unpredicably, apparently depending on the current status of the device. Other than specifying crash-safe cleanup code into your application, I found no other solution. There apparently is no way to reset the CUDA runtime active on a device, in order to force it to perform some sort of clean up.