[Freeciv-Dev] Re: Twitch-guard

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

There are a couple ways to solve this that aren't that intrusive. 

First, collect all server move updates in a delay queue that is 
emptied every "n" tenths of a second. This both synchronizes client
response times as well as building in a normal expected delay to
game play.

Then, all multi-step moves are handled in this server event queue
by executing only one element, and requeuing the move to the back of
the queue. One could also just send a status update back to clients 
to request the next step and have the move split there. This allows 
other actions to take place at well defined points in the move. 

Units "on guard" can register "triggers" with the server to attack
any enemy unit moving into their zone-of-control. When a unit moves
the square it moves to can be checked for such registered actions and
the response is immediate. This is really just setting a flag on units
and having the move code run an adjacent loop checking for flagged
enemies so should be really trivial to implement.

Note most keyboards have repeat-key delays of various fractions of a 
second, so such impacts on usability are not unreasonable.

Cheers,
RossW
=====

At 10:57 AM 01/09/21 +0200, Raimar Falke wrote:
>On Fri, Sep 21, 2001 at 12:46:06AM -0700, Asher Densmore-Lynn wrote:
>> It's mighty hard for a script, player, or AI to suddenly just DEAL with
>> someone with a high movement rate, who appears out of nowhere.
>> 
>> Would it be unreasonable to propose a "movetimeout" such that a unit within
>> or entering an area controlled by a hostile player [this calculation
>> handwaved until further discussion] may only expend one MP until
>> movetimeout seconds pass?
>> 
>> In this fashion, the player is suddenly made aware of an -enemy-, and given
>> the possibility to intercept if feasible or move to threaten, elsewise. Set
>> to half the turn, and for the first half of that turn, you're free to
>> attend to management details without nasty surprises cropping up. Set to
>> zero, and it doesn't apply.
>> 
>> A unit that the enemy player couldn't reach is just as safe as otherwise; a
>> unit that is NOT is vulnerable to ambush or jihad.
>> 
>> I'm not sure if this would be useful or not, but it seems like it'd be
>> helpful to client-based agents.
>
>So you propose a minimal time between steps?! From the point of view
>of the player/agent who sees a unit moving it is ok. However from the
>point of view of the player/agent which does the move it
>isn't. Imaging that you can't move your settler down the road with 3
>key presses which but have to wait for some seconds between each. The
>same applied for agents. Agents may perform them in parallel but you
>have other problems with synchronization.
>
>       Raimar
>-- 
> email: rf13@xxxxxxxxxxxxxxxxx
> "Make it idiot-proof and someone will make a better idiot."