Locality Concerns
[Documents/03.4-Locality.txt]
Simon Marchant, 30 Sep 93
[plus comments by Ken McGlothlen (KM) and Ernie Prabhakar (EP))

| | To do that, I
| | would (possibly, depending on how we work it) message the server
| | asking whether the "geography" would allow it.
| | 
| Not necessarily.  If the clients are informed of the geography at startup, they
| can calculate line-of-sight and such themselves.  This reduces the work that
| the server has to do.

Unless the geography of the situation is changing.  For instance - there
used to be a wall there.  Now, there's just a big hole.

KM> No, that one's easy.
KM> Server tells the clients to destroy the wall in hex 2332.

Or - if the geography is dynamic.  A solar system for instance, in which everything is moving,
except perhaps the sun - and the movement is significant over the timescale
involved in the game.  [Note: I believe galatic bloodshed [an empire "clone"]
has precisely this behaviour.]

KM> A much better example of when you don't want the clients handling
KM> geographical considerations.  Besides, the clients will have
KM> enough to do just updating the map.  :l


Should the server have to tell all the clients that the geography has changed?
In the former case, maybe.  In the latter, probably not - it'd happen too often,
and encompass too much information.

Again, it's the problem with how smart the server is, and how smart the client
is.  As has been suggested, I think we need a sliding scale to accomodate the
various sorts of games we're talking about.

| | In SQPR,
| | though, there are individual leaders on the board who go in a precise
| | sequence - somewhat independent of which side those leaders are on.  Would
| | those leaders be separate players?
| 
| Pardon?  By "players," do you mean "clients"?  Or what?

I wouldn't think that you'd want to treat each leader as a separate player
(client) - even if you allow a client to make multiple connections to the
server [not necessarily at the same time, but consecutively, for instance].
[There are problems I can think of - ownership of units; trumping would be
difficult to handle without a certain duplication of effort on both the part
of the server and the client; the OC can give orders to all the other leaders
on their side, and so on].

| The question of whether the clients or the server has the 'master'
| copy of the location of pieces is a fairly crucial one, I believe.
| Does anyone have thoughts on that.

In a dynamic system, where the 'terrain' changes irrespective of the
player's actions [e.g. the solar system], the piece's location can change
without the player's intervention [gravity...].  In this situation, since
every piece is moving like this every tick, to have the clients hold the
master copies would require the server to pass vast amounts of
information around.  So the master copy *must* be on the server.  So,
that's an extreme situation for location.  The question is, is there a
different situation in which the information absolutely has to be on the
client?  If not, then in the interests of generality, I submit that the
information must be held on the server.

KM> I think what you're asking is whether there's a situation where
KM> the information absolutely has to be *exclusively* on the
KM> client.  *I* sure can't think of one.

Notice that even in less weird situations, whenever a piece is forced
to move [retreat, displaced, teleported, routed, etc] by someone who
is not the owning player it is clearly less effort to have the server
maintain the master location information.  In fact, in most situations,
whenever a piece is moved by the client, this still has to be passed to
the rest of the clients - so why not let the server do it [except that
it takes up more of the server's time...]?

Simon.

EP> 
EP> This is an excellent point, and quite possibly correct.  However,
EP> I want to raise some consquences of this view for people to
EP> consider:
EP> 
EP> 1) Each piece would have to have a connection to its location
EP> on the server, so it could move itself.
EP> 
EP> 2) If piece B is forcibly moving piece A, it would either have
EP> to:
EP>	a) tell piece A to move itself
EP> (thus no gain over A controlling its own location!)
EP> or	b) have its own connection to the location of A
EP> 
EP> (b) then implies
EP> 
EP> 3) Attacking pieces would need a connection both to the defending
EP> piece AND its location, which in general would be on two
EP> different hosts.
EP> 
EP> 4) The server now has to "know" about each and every piece on
EP> the board, as opposed to only "knowing" about the clients.
EP> 
EP> The key point is that anything involving a pieces location,
EP> "retreat, displaced, teleported, routed" will, in general, have
EP> an impact on the piece itself.  Since the piece will ultimately
EP> need to find out its location anyway, are we actually saving
EP> any time?
EP> 
EP> Planents in a solar system can go either way.  If they are
EP> terrain, it would make sense for the server to move them.  But
EP> if they are pieces, it is likely the time step that would move
EP> them would also change its state in other ways, so the piece
EP> would need an "update" call anyway.
EP> 
EP> I started out thinking that location belonged on the server,
EP> but the more I think about the more it seems there is no real
EP> advantage.   And encapsulation would imply that a piece should 
EP> take care of its own location.  But other thoughts are welcome!