Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2002:
[Freeciv-Dev] Re: RFC: new implementation of island numbering
Home

[Freeciv-Dev] Re: RFC: new implementation of island numbering

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Freeciv Developers ML <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: RFC: new implementation of island numbering
From: Davide Pagnin <nightmare@xxxxxxxxxx>
Date: 11 Nov 2002 14:07:43 +0100

On Sun, 2002-11-10 at 22:01, Mike Kaufman wrote:
> Here is an idea I have for solving several problems related to general
> improvement effects as well as PR#2238.

PR#2238 has been merged into PR#2223. (Only a NOTE)

> 
> here I use islands and continents interchangeably.
> 
> Currently, the server and the client have different ideas as to what is a
> continent. Since the server sees the whole map, the server can determine
> precisely which tile belongs to what continent and assigns that tile a
> number. (see mapgen.c:assign_continent_numbers())
> 
> The client doesn't have the luxury of being omniscient, it can only see
> what is known. so if a nation sends out a ship exploring and runs into a
> new landmass which isn't visibly connected to the original land, it does
> not really know whether it's a different continent altogether or the same
> continent connected somewhere in the unknown part of the map. So it
> defaults to a new continent and if later it finds out they're the same,
> merges the the continent under the same number. 
> (see climisc.c:climap_renumber_continent())
> 
> This disparity has some immediate consequences, namely for trade routes and
> some effects: for trade routes, cities on different continents get a better
> deal than ones on the same continent. So if the client calculates the
> trade, it might wind up with a different answer than the server which is
> the origin of 2238. Or for island-wide effects, this behavior leads to more
> information than a client needs to have: the presence of an effect could
> tell a client about unknown terrain.
> 
> My solution to these problems is to have the server calculate all
> continents numbers, but to do so from each client's point-of-view. So
> instead of saving these numbers in tile->continent, they will be in
> player_tile->continent. That way, for you, the server and you have the same
> idea of geography.

I'm not endorsing nor opposing to the fact that the server maintain the
'continent' idea from each client point of view.
This is an implementation matter not a game rule matter.

I do agree that having client side continent idea coming from server
will definitely end every possible problem of server <--> client having
to fight different data.

This will end up in a little bit more work for the server and for the
network, tough. I don't know if the gain is worth the change.

> 
> Davide has raised a concern that the new behavior is exploitable in the
> following way:
> 
>    oooooo
>   oo####oooo
> oooLL###LLooo
> oooCLL##LLCooo
> ooooLL##LLoooo
> oooooo###ooooo
> ooooooooooooo
> 
> o = ocean
> # = unknown
> L = land
> C = a city
> 
> if you found two cities as so and create a trade route between them, you
> will get the benefit of a trade route between separate continents, even if
> you're reasonably sure that the two cities are sitting on the same
> continent. That's true, but I contend that this is an unusual strategy, one
> that takes more work than gives benefit, since if you uncover any of the
> unknown your benefit goes away, and it's potentially dangerous to have that
> situation for trade benefit, and you _don't_really_know_ if these cities are 
> actually on the same continent. In short, I don't think that this is a good
> enough reason not to do this.

Here I disagree with Mike. I don't want any possible way for exploiting
rules.
I understand that probably my example isn't a good example of a
'winning' strategy.
But, in the case you're able to conquer an enemy city, with trade routes
to other cities (perhaps in the same continent), you can exploit this,
for a while, because you "don't know"...

> 
> The only potential problem I see in implementing this is the coordination of
> continent numbers between players. This leads to a couple of odd effects: a
> trade route between two nations may yield different amounts of trade for
> each nation: 
> 
> scenario: player A know that his city and B's city are on the same 
> continent. B doesn't know this. When the trade route is created, A
> gets less trade than B does. A solution which I think is fine is that a
> trade route will reveal the continent which the city is on. In that case,
> when the trade route is created, ther server will inform B that A's city is
> on the same continent. What should happen if neither know? Should they find

This is precisely the scenario in which PR#2223 arises.

> out or does the server act as is they are on separate continents. I prefer
> the latter.

The concept of trade route in civ I and in civ II were flawed and too
simplistic. Anyway they work.
By creating a trade route, a caravan will go from its homecity to the
target city, and create a trade route (bijective***).

The whole point of this system is that both cities get revenue from the
creation of the route, and the amount depends from the total trade of
both cities.

From a 'real world' explanation, we can see the traderoute as the
revenue (for both sides) from exchanging valuable goods.
It is clear (for me) that both sides know each other.
(I mean, each side know were and how they come to the exchange)

Thus, if player A knows that city X and city Y are in the same
continent, then this knowledge should be shared with player B, when the
trade route is established.

I can think a scenario were both 'sides' don't know this information.

scenario 1, involve city trade.
(Player A create a trade route between city A and city B, the he gave
city A to player B and city B to Player C)
This way, Player A knows that the cities are in the same continent, but
nor Player B neither Player C knows.
I think that this example let A, B & C, trade cities in a way that let
them gain unappropriate trade benefit.
(This clearly involve something like an alliance between the three
players, but no shared vision)

scenario 2, involve city trade && airports.
Player A give an inland city A with airport to Player B.
Player B uses City B on its own city to move to City A his caravans.
Then he create the trade route between city B and city A.
In this case, nor Player A neither Player B are sure that city A and
City B are/aren't in the same continent.

Perhaps it is not a great way of cheating, but I think that endorsing a
client perceived geography open the door to potential problems, instead
having a server perceived geography and a client partial understanding
of that will leave us free of such problems.

This do not conflict with server side "continent", it is only a matter
of agreement on how server and client geography can differ...

> scenario: A has discovered all of continent 1. B has two colonies on
> continent 1, but he doesn't know that they are the same continent, so he
> labels them 2 and 3. A sees both of B's colonies. B sees that one of his
> colonies (on 2) is on the same continent as A's city Rome. Now: A builds an
> improvement in Rome that delivers an island-wide effect. Question: should
> B see this effect on continents 2 only or should he see it on 3 as well?
> After all, A sees 3 in on the same island, he expects that the effect is
> affecting B's cities/units/etc on that island. I don't know about this one.
> 
> Interesting: should mere knowledge of geography or lack thereof be a
> deciding factor in whether an effect works?
> 
> Comments are welcome. Other difficult scenarios too. 
> 
> -mike
> 
> 





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