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

[brett l. <bre...@gm...>]

On Sun, Jul 24, 2011 at 5:10 AM, Erik Vos <eri...@xs...> wrote:
> 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
>

I don't think the approaches necessarily conflict. With Erik's
approach, we'll get one method of network play (probably earlier than
with my approach) and all of that same work is necessary for what I
want to do.  None of it is lost work.

For me, I'd like to *also* have the ability of the server-side to hold
the state of the game to allow for asynchronous play. This would allow
a wider range of play possibilities.

Historically, I think Erik and I have always preferred to work on
differing sections of the code. ;-)

---Brett.