Spring RTS Engine

I'm sure this is posted somewhere....but whenever I try to have 2 of my java AI bots in the same game, only 1 actually does anything.

Is this a limitation on how spring implements java stuff (classloader) or something I am doing wrong?

Testing with me as spectator and two NullOOJavaAI's, it seems to work fine. I recommend oyu test the same, and if NullOOJavaAI works for you, it most likely is a problem in your AI.
NullOOJavaAI spamms some output to the chat console about every 10 seconds, but as it spamms too muhc, you will only ever see output of one of the AIs at a time, so you may have to look atinfolog.txt to see if both AIs were spamming (and therefore successfully receiving events).

works ok for me...

Hmm...that's nearly exactly what I did.

I'll have to experiment more. If you guys say 2 java bots can function in the same game, I'll believe you.

:)

Two of my AI seems to work fine, on a quick test :)

btw, it appeared that my issue was related to static (instance) variables in my bot..........(shared amongst all instances of that AI. Dumb of me.

casperjeff wrote:btw, it appeared that my issue was related to static (instance) variables in my bot..........(shared amongst all instances of that AI. Dumb of me.

So all AI's run in the same JVM, interesting :)

I see options for evil ways of messing with other AI's :D

or, sharing a pathfinder or so, now that could be interesting, especially for allies :)

Can somebody point me in the right direction to determine how multiple java AI bots are handled by the game code.

I am assuming that each bot is managed as a separate thread in the same VM....but I am confused about the event model (how events are passed to each bot) and how a single bot eating up CPU/resources effects the rest of the game (and other bots). Heck, even some info about how each bot's class is loaded/executed/initialized would be informative.

Can somebody point me towards something in the main sprint rts source?

spring starts one JVM for AIs, and one only. as of now, spring (the engine) does not use Java for anything else.
so all AIs (wont always write Java AIs, as i be speaking about Java stuf only in this post) run in this one JVM. all AIs receive events through the same thread from the engine, the main thread.. the one attached to the native part (JNI logic). Only this thread will ever be sending events ot AIs, and when AIs query something from the engine through the callback interface, they must do so in this thread, otherwise, bad things will happen!! (death from behind)
Ais can use multiple threads internally of course, if they need to do. In practice though, you should try to keep this to a minimum, and optional, if possible. Why? read on:
Ill explain this with the most extreme scenario, but i am sure you can imagine that also just single events/arguments of this, could be good reasons already.

The AI Dev sits on this 4 Core 4GHz machine with 8GB Ram, Hi-Tech Graphic card, and runs spring at lowest settings. When testing his AI, he runs two instances of it against each other, or pays himself against one instance.

The AI uses 3 threads for path finding and one for a special GUI.

The user has a Single Core 3GHz machine (5 years old), 1GB Ram, and a graphic card which was medium good 5 years ago. when playing against RAI, he can play spring with low - medium graphic settings just fine.
As he is an experienced player, and likes to play spring allied with friends, against AIs, he usually plays spring with 2 friends of him, allied against 10 allied AIs. He will set up all the AIs on his own machine, and all 10 of them are instances of this new AI.
This means, in addition to the engines threads, there will be an additional 10*(3+1) = 40 threads. This puts his machines to its knees pretty early in game. Additionally, the AI dev did not do the threading perfectly (locking related bugs), but on his machine and testing setup, he never ran into problems with that. On the users machine, these problems do show up, and after a few minutes of a laggy game, it freezes up totally, or crashes.

in short: in case you want your AI to be used by players, instead of just using it as a research playground, keep in mind:
your AI will always be just a small part of a big thing. a single AI should not ever be using a lot of CPU directly, and therefore, if you really need threading, you are already doing something wrong, most likely.
if you just want to make sure the system that runs the AI will be used at its best, make threading optional, or at least scalable, so your AI can run with 0 or 1 extra thread, or use more, if the setup of the game and the hardware allows it.

hoijui wrote: ...
in short: in case you want your AI to be used by players, instead of just using it as a research playground, keep in mind:
your AI will always be just a small part of a big thing. a single AI should not ever be using a lot of CPU directly, and therefore, if you really need threading, you are already doing something wrong, most likely.
if you just want to make sure the system that runs the AI will be used at its best, make threading optional, or at least scalable, so your AI can run with 0 or 1 extra thread, or use more, if the setup of the game and the hardware allows it.

Though I understand your reasoning here, I do not agree with it. AI should have as much freedom as the developer wants/needs. Also in the case of deployment for the general public. I do think, of course, one should always program their algorithms as optimal as possible. But creating AI on GPU or using multiple threads should not be discouraged in any way, it is the future!

more threading is not automatically good, just cause we are having more cores/more threading friendly hardware. new technology != good using it very much.
if springs AIs would use 40 threads alone, that would be bad, as long as we can not assume the minimal system spec for spring is a CPU with 16 Cores or the like.