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

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

See below.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Sunday, July 24, 2011 9:38 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Removal of static class variables (git: 8b9df8)
> 
> Brett & Erik,
> I like the discussion, however sometimes for me it is on a too general
level.
> 
> I think to decide on how to proceed with the coding it depends on what
> information will have to be exchanged between clients and server and what
> the server will actually do. And I have to admit that I currently have
only
> vague ideas what the your actual proposals are. But to change my coding
> behavior you should provide a more concrete plan. I will try to give my
idea
> shortly below.
> 
> >From my point of view the most realistic way is similar to what VASSAL
> >does,
> which how I understand it, is mainly exchanging messages and each client
has
> a complete model of the game.
> There are two candidates what to put into those messages: Either the
actions
> (like in the save files) or moves (like for the undo/redo stack). Both
allow to
> replay the whole game, moves also allow to move backward. Thus on each
> client a complete Rails game runs (with additional code that restricts
only
> entering move for one player) and sends messages to all other clients. If
this
> is actually done peer by peer, or one client serving as a message relay or
a
> centralized sever in-between does not matter much.
> 
> All other separations imo require much more efforts in both restructuring
old
> code and writing new code.

Exactly. In a way, the AutoSave/Load  feature already brings us pretty close
to your action-exchange model, except that it's now exchanging complete
action stacks (saved files) instead of single actions.

My own approach to accomplish a real client/server split would be to work
bottom-up. First I would refactor all GUI<->engine interchanges to objects
that are passed between the GameManager and the GameUIManager.  We already
do this with the action objects, and implementing the action object exchange
was in fact my first step in this approach.  However, that work is dormant
now (other wishes and needs have prevailed).  If it ever would be completed,
the main thing that remains to be done is to serialize these objects and
build a comms interface in between these managers to transfer the serialized
objects (and yes, we have initialization issues too).

Brett prefers and has started to work on a top-down approach. 
I don't know where he currently is on that path, and I hope Brett doesn't
mind that I'm a bit sceptical about his approach, because I believe that he
will have to deal with the same low-level issues that I have been working
on, and that those can better be addressed first.
But equally well, it could turn out to be a nice fit when we meet each other
somewhere in the middle...

> But most likely the chosen method will depend on the views of the person
> who volunteers to undertake that task.

That's real life, indeed.
 
Erik.

> Stefan