Fritz Heckel

I tracked down the issue that was causing agents to stop, and it comes down to synchronization. Essentially, an agent could come back around to its next iteration and attempt to resolve actions before all of its behaviors had run, since they are running in separate threads. I’ve tested this by doing the dumb thing: I fixed the number of threads at run-time (the code is set up to allow the creation of more threads on demand), and dropped a barrier wait into the worker threads, so that the threads essentially run in lock-step: all agent controllers run, then all behaviors run. There’s only one barrier, so it really just requires the agent controllers to run before the behaviors.

The barrier wait is not a good solution. I’ve come up with a few different possible fixes, but I think the most logical is to just assign behaviors in the same thread as the agent controller runs. There are potential balancing issues with this, but those exist at the moment anyway.