Complete.Org: Mailing Lists: Archives: freeciv-dev: July 1999:
Re: [Freeciv-Dev] Idea for 2.0

Re: [Freeciv-Dev] Idea for 2.0

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Greg Wooledge <wooledge@xxxxxxxxxxx>
Cc: Freeciv Dev <freeciv-dev@xxxxxxxxxxxx>
Subject: Re: [Freeciv-Dev] Idea for 2.0
From: Jules Bean <jmlb2@xxxxxxxxxxxxxxxx>
Date: Thu, 15 Jul 1999 09:31:23 +0100

Greg Wooledge wrote:
> I don't know whether anyone's currently working on fog of war, but I'll
> offer my thoughts.
> The only good way to get all of the above working correctly is to enforce
> it at the server.  If the client is told all of the units in a stack, it
> could be hacked by the player to give information the player should not
> have.  (Under Civ2 rules, you can determine that an enemy boat is carrying
> one or more passengers (or shares the square with another boat) by the plus
> sign, but you can't know what those passengers are until you attack and win.
> But if the server tells the client what all the units on the boat are, the
> player has information (s)he shouldn't have.)
> Fog of war would work similarly.  Tile update information cannot be sent
> to the player unless the player should get that info -- if the enforcement
> is at the client, the client could be hacked to do what it currently does
> (display all tile updates).  Or people could just run old clients....
> The same goes for invisible units.  If you don't want the player to know
> where enemy subs are, don't send the information!
> So, every way I look at it, the server needs to be modified.  It has to
> be more selective about what information it sends to the player.

Absolutely.  The server should definitely only send what the player is
supposed to know.

Cosmetically, I'd like to see the client displaying a visible 'fog' over
'known but not currently seen' tiles, so we know what we know, IYSWIM.

> But for fog of war specifically, there's another factor.  The player
> should be able to see a tile (s)he has already explored, even if it's
> not updated.  Thus, the client has to keep a copy of the last "version"
> of a tile sent by the server.  That's all fine, and trivial... until you
> get to the saved game.  When a game is loaded, and a client reconnects,
> it should get a copy of the map just like the one it had when the game
> was saved.  Thus, the server must also know what the client sees -- which
> means the server must keep a record of every client's "view" of the map.

I disagree.  I think that at save game time, the server should ask the
client 'is there any data you want to save?'.  And the client should
send back its map.  I think it's rather complicated to have the server
remember what each client thinks it can see - and additionally it seems
less elegant.  In fact, the server could treat the data the client sends
back as opaque, and just save it - so clients could be extended to keep
more information (statistics, say) and the server would just stick it
into the savegame.


|  Jelibean aka  | jules@xxxxxxxxxxxxxxx         |  6 Evelyn Rd        |
|  Jules aka     |                               |  Richmond, Surrey   |
|  Julian Bean   | jmlb2@xxxxxxxxxxxxxxxx        |  TW9 2TF *UK*       |
|  War doesn't demonstrate who's right... just who's left.             |
|  When privacy is outlawed... only the outlaws have privacy.          |

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