RE: [Rails-devel] The Player Class

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

> > In hindsight, I think the player list belongs in Game
> > (not in Player or in GameLoader),
> > so that all possible UIs can get it from there.
> > What about that?
> > 
> > We should be careful to keep game data and UI stuff separate,
> > so that in the future our classes can also be used for
> > a 18xx game server (just to name one possibility).
> > So the player list should not be saved in the UI code.
> > 
> 
> 
> I was seeing the same thing myself. Probably most or all of GameLoader
> can be moved into Game.

Except the part that calls the UI methods.
If you want I can work on that next weekend or next week,
when I should have some time. I could also make a start 
with "turn management".

Which brings me back to the old question how to define
the View/Model interface. Last week I've already tried to
describe the Auction (renamed to StartPacket) part of that.

I consider the Model to be a state machine, which changes its own
state as a consequence of player actions, passed via the UI.

The general scenario that I have in mind for interactions 
across that boundary runs like the following
(with "current Model process" I mean the round or subround or 
other distinguishable process that the game is currently in,
which I suppose is represented by some Model class instance):

forever {
   Player: Executes some action.
   View (UI): Catches the action and interprets it.
       Call appropriate methods in the current Model process.
   Model: Logs the action, and processes it, updating the Model state.
       If the current Model process termininates (e.g., a Stock Round is
over),
       or if some subprocess needs be started (e.g., an auction)
       it notifies a central controller (let's call it GameManager) about
that,
       before returning to the UI.
   View: Calls the GameManager to find what the current Model process is
       (it might have changed, as indicated above).
       Then it calls the (old or new) current Model process and any other
Model class
       to find out: (1) what UI and data to display, (2) who's turn it is, 
       (3) what actions are allowed.
       The UI rebuilds the screen accordingly.
}

This is a rather loose description that probably needs refinement.

BTW one reason that I intend to continue developing my test servlet is
exactly to ensure, that we create a proper View/Model boundary.
If our code works both ways, we're probably OK.
And it also frees me from being totally dependent on the progress of UI
development.
(I have ordered some Swing books, though!)

Erik.