Re: [Rails-devel] Removal of static class variables (git: 8b9df8)

[Erik V. <eri...@xs...>]

See below.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]

> >From what I understood from previous discussions is that Erik prefers
> the fat client approach, where "clients" all have a full game back-end
running
> and only pass around actions between them. The server merely acts as a
> message broker.

No.  As I explained, I take an intermediate position, let's call it the
"medium" client.  It knows about all the game objects, but nothing about the
game state, except what info it receives from the server - mainly screen
updates (to all clients) and allowed actions (to the client having the
turn).

 > -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]

 > Because the clients should take the "authoritative" values for things
given to
> it by the server, not whatever arbitrary values somebody decides to put
into
> their own local XML files. Trusting the client to do the right thing on
its own
> makes exploitation far too easy.

That's a good point, but if we go that way, it should occur only once, at
the start of the game.

> > Always local, in my concept.  Static info does not need to squeezed
through
> the client/server interface.
> > Unless you want to make the client really dumb, of course.  And slower.
> >
> 
> Over-use of static info also makes supporting multiple threads more
> problematic; it increases the likelihood of race conditions and other
difficult-
> to-debug issues. In general, most of the stuff that's currently static
doesn't
> really _need_ to be static.

Apologies, I should *again* have said: "static (as opposed to dynamic)",
i.e. never changing. 
I'm as much against "static (as opposed to instance)" as you are.

> The response can be a variety of things, depending on how "thick" or
"thin"
> the client is.
> 
> 1. It could be a simple "success/failure" response.
> 2. It could be success/failure, with an updated client Wallet value.
> 3. It could be success/failure, with the current state of every player's
> holdings, the whole stock market, or even whole game.

OK.  To be more precise, I think we must distinguish three types of
server->client info:
1. The response: what only the previously acting player client gets
(success/failure, error message).
2. The broadcast: what *all* clients get (i.e. the initial data, the GUI
updates and other state-like info).
3. The prompt (or whatever): what only the next active player gets (i.e. the
list of allowed actions).  Or will we allow all players to enter any move,
as someone suggested?

Erik.