I haven't had any 'jerkiness' yet with threads, altho I have not yet pushed them to the limit, processing-wise. I've only used them for 'server' applets.

I've seen several Java video games, however, that clearly have overcome that problem. The smooth graphics of some of them surpasses current games. There's several versions of 'Link' that are neat, an amazing set of racing games (their sprites move *perfectly* smoothly, at high speeds).

There's a simple example of such *with code* at the javaboutique.com -- the "asteroids applet". They use one thread to run a 'timeline' "loopThread", basically, and set it to priority 'MIN'. They also create thead just to load sounds "loadThread".

Then, in every 'cycle' of the thread, you put your 'turn' code. It's no different than 'turn' based, from a coding standpoint. You just make the turns run automatically, one after another.

Frankly, there's really not much In Asteroids that has to be done by each thread. What we're talking about is probably at least a factor of 1000x more stuff in our graphics, and 1000x more in the game itself. The AI alone should have Tens of threads running, thinking about strategy, tactics, etc. for several different civs at a time. With modern desktop power I'm sure we can do it for TB (turn based), but we'll just have to see for RT.

Your point in the other RT thread is quite right IMO. At this point all we need to do is keep RT in mind in the models and interface design, and put hooks in the code for it. Then, if/when we implement RT playtesting can tell us whether its going to work "on the cheap" (with relatively few design / gui changes).

Really?

Forgive me, I'm completely ignorant in that department, but does it really take multiple seperate threads to do the AI? That seems incredible. Is there any other architecture that would suit? Is there any way to bundle operations into fewer threads? I probably don't even understand enough about AI to even follow ya'll's discussion, but perhaps a little brainstorming by ya'll who understand this stuff could cut that down? I thought AI was a matter of situational awareness and pre-defined (perhaps changable, allowing 'learning', via 'reflection') strategies/responses. This sounds like lists of properties that could be stored in memory, as multidimensional arrays or linked lists or some such. This would allow just a few threads to control many civs, and allow for massive depth and cunning in the AI. Am I as ignorant as I think I am?

We probably need to discuss architecture, anyway. There are still some big things we haven't nailed down, like exactly what on-screen details do we want to use sprites for -- units, cities, terrain, etc? Do we want to stay with 'squares', or move to a coordinate system, or go with a 'risk'-type abstract map with 'regions'? We could use hexes . . . Do we want to 'draw' the map to the screen, or import tiles?

I *think* the AI I'm drooling over can all be made to work with like 50% of the clocks, but we'll see. One Really cool thing about a Hot server would be to evolve AIs within it. Get ones that do well against a variety of playing styles, etc. That would be major fun.

For the AI the main thing we need is a good set of rules. Especially if the player has a slow machine and wants to run it flat out. But if you want it to be somewhat unpredictable (but not just by doing random stupid things) you need something like the GA. I think we need to do both, and
if the GA part takes too much time we will trim it or toss it. The GA is what might use a bunch of the threads. Trust me for now, but verify later ;-)

But we'll just have to look into the tradeoffs when we get further along.

Looks like squares is the way to go to me. You're right we need to talk about city/unit/etc image handling. Could you organize that?