[freeciv-ai] Re: (PR#5633) Order of AI activities.

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

There are a number of competing confused objectives in the past discussion
thread, but to possibly clear the air of technical fixes required for the
server AI to have equivalent access to a client AI, and thus relegate the
subsequent balance questions due to turnaround latency to a scheduler issue
consider this ...


Currently the server AI is a monolithic processing module. Once activated
it does *all* actions within a given category for *all* AIs. The first
problem is to break the (usually) high-level loop over all AI players.
Except where people have been generating shared AI data summaries in
global memory, this is mostly just a matter of handling the top-level
loop in a manage function a little differently. The longer term task is
reordering the list of activities to deal with ramdom events and data
changes during processing. But this is what the client AIs are busy
experimenting with now, and apart from the robustness aspects of dealing
with possibly stale local data, is largely a strategy optimization.

The second issue is that the low-level actions directly access the server
code instream. This is because one uses function calls to access the
Freeciv API instead of packet protocol actions. This is a biggie because
one of the issues here is reuse of global memory for local AI data
specifically over low-level function calls that in a client require network
packet cycles. Note the missing piece of code is a dummy netpacket driver
that each server AI should use - could probably be a current local client
connection, or an in-memory to input queue packet transfer - not a bit deal
... and a change to all server AI low-level function calls to use the packet
API layer rather than bypassing it and going directly to the source. Of
course, some new Packet APIs will need to be added for server AI specific
actions like omniscent summaries.

Packet Protocol actions are like events that trigger server code responses
and going through the common network packet receive acts like a round robin
scheduler. One could change this slightly by moving to two-staqe processing
where packets are input and queued, then subsequently processed by a more
sophisticated scheduling algorithm, such as a time-delayed priority queue
that handled a maximum of one client packet per tick, effectively slowing
all clients to a defined network latency, including server AI. Note, the
Start-of-turn packet or some such is a perfectly valid way to enter the
top-level server AI manage code, i.e. as opposed to a hardcoded for loop.


Now, you can go back to the discussion about how you want to setup a
uniform scheduling of actions for all clients including serverside clients
and the implications of different choices on the ordering of actions etc.
(client AI strategies).

Or you can discuss the steps to reach a uniform client model, with the
(accepted) tradeoffs for partial solutions along the way (migration
issues and intermediate working models).

Or you can go back to how to organize a monolithic AI in ways that do
something other than a uniform client model, such as a turn-based system
where all actions are effectively processed in a monolithic sequence for
each client, or a phased turn based model where subsets of actions are
processed in monolithic blocks (latency/event independent models).

Suggestion, once you have worked out things for a network client model,
or a more monolithic turn-based one, then worry about how to mix the two
in a fair way, as is done in the current code jumble. Working backwards
may help unscramble/reveal the problems and bottlenecks in some cases.


Hope this helps provide a somewhat concrete continuous full-spectrum view
of possible solutions and segregate the topic channels (i.e. my model is
better than your model), from the technical and game balance issues within
a model or sub-spectrum range ...


Cheers,
RossW
=====


Jason Short wrote:
> ue80@xxxxxxxxxxxxxxxxxxxxx wrote:
> 
>>On Thu, Sep 11, 2003 at 09:40:27AM -0700, Gregory Berkolaiko wrote:
>>
>>
>>>On Mon, 1 Sep 2003, ue80@xxxxxxxxxxxxxxxxxxxxx wrote:
>>>
>>>>I think it's possible to split up some of the AI-activities.
>>>>
>>>>A human has to rethink about his moved units when he sees new enemy
>>>>units in front of his city. (Double turns)
>>>>
>>>>And i think the same is true for the AI. When i land with a transport
>>>>full of horses and the AI can't do anything after i've done that the AI
>>>>will never have a chance to beat me. (Ok the same is true for humans
>>>>with AI-double turns ...)
>>>
>>>I am working under assumption that when you play against the AI, you want 
>>>a strictly turn-based game.  I certainly do.  And humans don't have a 
>>>chance to react to AIs moves, so why should AI have the privelege?
>>
>>
>>That's hard to decide if i want a blocked moves or not.  
>>
>> - There shouldn't be differences between a game human/human and
>>   human/AI
> 
> 
> There are fundamental differences between playing against humans and 
> computers.  The lag is much slower for a computer.
> 
> Playing turn-by-turn makes for a superior game; the only drawback is 
> that you have to wait while the other player moves.
> 
> 
>> - As human i want to have to react when an ememy unit is in front of my
>>   city. 
>>
>>A turn is really long, and with end-of-turn and begin-of-turn moving an
>>AI can kill very much in very short time, a human can't handle more then
>>2-3 units in short time, but AI ... especially teamed AIs ...
> 
> 
> The current situation is completely fair: the AI moves in one phase, and 
> the humans in another.  (The only exception is the double-moves bug.)
> 
> 
>>We have concurrent moving, i think AI should be able to do it so.
> 
> 
> I agree that the AI should be able to be able to do non-movement actions 
> during human turns.  But I don't think there's any reason the AI should 
> be able to move units.
> 
> 
>>How should an AI work which isn't on the server? 
> 
> 
> A client-side AI would work just like a human player.  Which is another 
> argument for supporting synchronous turns (in addition to the 
> asynchronous ones we have now).
> 
> jason