Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2002:
[Freeciv-Dev] Re: rfc: autoattack
Home

[Freeciv-Dev] Re: rfc: autoattack

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Mike Kaufman <kaufman@xxxxxxxxxxxxxxxxxxxxxx>
Cc: "Per I. Mathisen" <per@xxxxxxxxxxx>, Freeciv Development List <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: rfc: autoattack
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Sat, 23 Nov 2002 18:42:44 -0500

Having no client bias like Mike, I still think he may have a reasonable
playability argument on the power of serverside automated units. If they
always provide a first strike capability that cannot be countered by the
unit moving up to attack, this is a problem.

Either a unit with enough moves can move and attack with some sort of
initiative weight to decide who goes first, or a "surprise" factor that
means the catapult does *not* always strike first, or even if it attacks
becomes the defender, might be needed to balance things out.

Of course there are always ploys like exhausting the catapult with a 
suicide unit before moving in with the real attacker. This would mean
autoattack units were always susceptible to a sucker ploy which is 
probably equally bad, but somehow not quite as serious seeming a flaw :-).

If you go to a client-only solution, then one needs both simultaneous
or multiphase turns, and a builtin delay factor after moving before one
can launch an attack. The delay factor must be at least one second which
is about as fast as human reactions can spot and counter to get into
the intervening slice, or you need to force everyone to use automated
clients. Multiphase turns where players get serialized opportunities
to respond may solve the delay issue but having popup dialogues in your
face all the time as events requiring serialized resolution occur and
get resolved will probably be a pain.

Some sort of balanced server/client automated feature for hotseat or
strategic play modes (vs action gaming) that had a well defined pattern
of actions and counteractions would not be a bad thing though.

Cheers,
RossW
=====

At 12:30 PM 02/11/18 -0600, Mike Kaufman wrote:
>
>On Mon, Nov 18, 2002 at 05:49:36PM +0000, Per I. Mathisen wrote:
>> On Mon, 18 Nov 2002, Gregory Berkolaiko wrote:
>> > But yes, even this autoattack is deadly. Too deadly...  It obsoletes
>> > defenders, really.
>> 
>> That is what I was asking myself, too. But I suppose this is what good
>> players do anyway, only they do it by an amazing feat of micromanagement
>> instead of server code ;) Right, pille?
>> 
>> Also, defenders are not obsoleted. To the contrary, now even the most
>> experienced micromanagement wizard has to use defenders - to bodyguard his
>> attack units.
>
>I do not like this at all. Here we are attempting to put more crap in the
>server, attack code, no less. This is the _wrong_ direction to be going in
>people. If people are able to micromanage from the client-side, then more
>power to them. The "slow-connection" argument is ok, but in no way
>outweighs the harm we would be doing in making this available. I have no
>problem at all with putting automated attack code in the client. That's
>what it's for. But don't screw with the server. (the server's going to be
>taking a performance hit anyway real soon now, let's not bog it down even
>more.)
>
>In my opinion, the server needs only to make a few intelligent decisions:
>where to place or remove a citizen by default when city size changes...and
>perhaps which improvement to sell if you run out of cash, but there's damn
>few other decisions it should be making, and doing attack routines is not
>one of them.
>
>> 
>> > Especially if Raahul's sea bombardment is added.
>> 
>> I don't like it much anyway... it gives too much power to CCA&H (Catapult,
>> Cannon, Artillery and Howitzer), and combined with autoattack it becomes
>> unbalancing as you can defend against both ground and sea with one
>> relatively cheap unit. (Bomber and stealth bomber can do this now, but
>> they are much more expensive.)
>
>good point.
>
>-mike
>
>
>



[Prev in Thread] Current Thread [Next in Thread]