Thread history

Yep, the engine is not thread safe.

Creating ClassLoaders should be faster than creating separate JVMs, but don't know by how much.

Another approach would be staying with separate JVMs, but not restarting them before each battle. Exchanging messages between JVMs and using the API inside a loop instead, much like how the RoboRumble client works.

Creating ClassLoaders once and reusing them on many battles is also another approach. I remember trying this approach in a custom multi-threaded RoboRumble client a long time ago. Didn't remember exactly what went wrong. Maybe the need of a custom JAR loading mechanism.