Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2001:
[Freeciv-Dev] Re: freeciv feedback
Home

[Freeciv-Dev] Re: freeciv feedback

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Christian Knoke <ChrisK@xxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: freeciv feedback
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 26 Nov 2001 10:59:29 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Sun, Nov 25, 2001 at 02:01:38PM +0100, Christian Knoke wrote:
> On Sun, Nov 25, 2001 at 09:24:10AM +0100, Raimar Falke wrote:
> > On Sun, Nov 25, 2001 at 04:22:14AM -0300, Martin Olveyra wrote:
> 
> [programming client-side ai]
> 
> > > May be it would be nice to write a complete guide to client-server
> > > communication to help the interested programmers to do that.
> > 
> > As pointed out in the past: it is a very nice idea (for the first
> > moment) to code a complete new client (and so need to reimplement the
> > client-server protocol) but this fails. Consider the case where you
> > made changes to a city and want to calculate the city to see the
> > effects: either you let the server do this (very slow) or you do it in
> > the client. However if you do it in the client you have to do it in
> > the same way as the server. So you can either copy the current code
> > (and for a city calculation for example you need a lot of code) and
> > you then have to track the code and update the copy (for example the
> > recently introduces game.fulltradesize and game.notradesize are such a
> > change). So the most reasonable approach (at least to me) is using the
> > existing freeciv code and infrastructure. This may mean a new
> > client/gui-guiless directory or the integration into some existing
> > client (like agents should be).
> 
> I'm not sure with this. First it affects how agents are implemented.
> I think, no matter how much calculation you do in the client, you
> should never never rely on that the server comes to the same result.
> You should rather accept / deal with that the agent calculations
> simply are not perfect.

Yes the client calculations can be wrong but this is only because the
client has old data. Consider the case where a city produces 4 shields
and the unit which got build has 35/40. And the city wants the finish
it the next turn. It now has to have a accurate way to calculate the
shield output for various tile allocations. If you know that your
calculations may differ by one shield from the server in 30% of the
time that you can just not do this kind of optimization.

> Second, if we go to agents / automated clients / client side ai's
> - and I think we should - we need independece between client
> and server, and, yes, it would be nice to have a guide on that
> interface.

If you use the existing code base you can and should use the code in
common/*. This code holds always the current information. For sending
packets you have to use the common/packets.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "USENET is *not* the non-clickable part of WWW!"


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