RE: [Rails-devel] The Player Class

[Brett <wak...@ea...>]

On Wed, 2005-04-27 at 23:59 +0200, Erik Vos wrote:
> > > 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".
> 

I cleaned up the code I already had in GameLoader today. I've renamed it
to GameUILoader to make its purpose more clear.

I also have changed quite a bit of Game and Bank to static methods. I
agree with you that Bank may or may not need to be a singleton at some
point. Though, I can't really imagine the mechanics for an instance
where we'd have more than one bank, especially because breaking the bank
is such an integral part of the end game.

These conversions to static methods broke a whole bunch of things, but I
think I've cleaned them all up, so the current code in CVS ought to
build and run without errors.


> 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.
> 


Is there ever a StartPacket that isn't an Auction of some sort?

How about we do this:

Let's define an interface called Round.
Then we define three more interfaces called StockRound, OperatingRound,
and SpecialRound that all extend from Round.
Lastly, let's have Auction be an interface extended from SpecialRound.

>From there, we'll create our actual Auction types, like 1830Auction,
etc. I think that if we implement the auctions one type at a time
starting with the most basic, we can do some analysis about similarities
to other auctions that will allow us to create a hierarchy that moves
from most basic to most complex, inheriting similarities from one
Auction to the next and overriding previous implementations where
differences crop up.

If there are any non-Auction starting rounds, they too can just extend
from SpecialRound, just like any other special-case sub-rounds, such as
forming the CGR in 1856.

In my opinion, this takes advantage of one of the best parts of being
object-oriented in the first place: Code Reuse. This is a big enough
project that if we can find areas where we only need to code certain
behavior once and allow everything that needs said behavior to inherit
it, we really ought to.


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


Agreed.


> 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.
> }
> 


Exactly as I see it, and exactly as we've been implementing it so far.


> 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!)

Totally fine by me. Hell, if this project ends up having a couple
different ways of providing users the ability to play 18xx games, I
won't complain.

It looks like I'm going to have a pretty fair amount of time to commit
to this project each day now that some things in my personal life have
stabilised again.

I expect I'll be ordering those Swing books soon as well. Though, there
is enough documentation on-line that seems to be handling my current
needs.



---Brett. 

A little experience often upsets a lot of theory.