Threads for RT.

[F Smith]

Hi:

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.

The interface is the only difficult part . . .

[F_Smith]

Tens of threads per civ, just for the AI?

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'm pretty sure we can still do it, tho. I was just looking at a demo last week in which 25,000 seperate threads controlled 25,000 seperate on-screen graphics, each moving independently in real-time with no choppiness. I'll go find that link later, and post it.

[Mark_Everson]

I think its a question of scalability when considering whether the threads cause jerkiness for Real Time.

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).

I, personally would prefer to make it "back-burner" for now, because if we pursue every "we could even..." issue we'll never get anything out.

[Mark_Everson]

Tens of threads period. (that's my estimate) Definately Not per civ.

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?

-Mark