Re: [Rails-devel] 1835 playtest report - Rails 1.3

[Stefan F. (web.de) <ste...@we...>]

Erik:
only a few short replies. I think the choice is up to the one implementing it. 
My preference is B > A >>> C

Option C) is in my opinion the worst. Forwarding the network information to 
the client only requires the network graph object. But this object has 
references to all vertices and edges (with further references). One would 
have to recode the whole network graph (which would still be larger than the 
list of all possible tile lays) and then define new methods working on that. 

The encoding of A could also be two of identifiers (hexes and tiles) and a 
bitset (orientation). 

My current approach in the map correction does not fully delegate everything 
to the backend, it is more a hybrid type. It only delegates the validity 
checks and provision of the available options to the server. The update of 
the UI is still done by the client controller itself and not via state 
changes/model updates in the server. The model state only changes after the 
action is fully defined/executed. (This also implies that the undo affects 
the full action and does not undwind partial steps).
From my point of view this still allows clearer separation of responsibilities 
without creating additional states.

Stefan

On Saturday 26 June 2010 13:55:32 Erik Vos wrote:
> Stefan,
>
> A third option could be:
>
> C) In addition to the "simple" LayTile of my proposal (only listing
> reachable hexes), send the current routes in some form or shape from server
> to client, and let the UI use these routes to sort out all laying
> restrictions. I don't know if sending route information is practical,
> though.
>
> About your options:
>
> A) In practice, I suppose it would be a (uuencoded serialized) List of
> Lists of something. Not sure what space that would take.
> Basically you're right that size would't be excessive. Just two additional
> remarks:
> - in my experience, it always pays off to keep traffic small,
> - don't forget that there will be a lot more stuff to transport from server
> to client. To name the probably biggest thing: all Observer updates.
>
> B) Partial actions I have been weeding out consistently since the early
> days, but I understand we now have them back already...
> (Yes, I remember we have had some discussions about that in the past).
> One drawback would be that more state needs be maintained (I suppose that's
> what you refer to as complexity).
> Another reason I'm somewhat concerned about this approach is that it might
> pose restrictions on further developments.
> One use case I have in mind is a future PBEM version. Will the users have
> stand-alone clients, exchanging messages over a slow channel, or will they
> all have full-blown Rails versions, sending mails to each other and/or to
> some central moderator? Most likely it'll be the latter, and then my
> concern is moot, but I'm not sure. Perhaps is just a matter of intuition.
>
> Facing a choice, my current order of preference would be A, C, B.
>
> Erik.
>
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Friday 25 June 2010 23:05
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1835 playtest report - Rails 1.3
>
> Erik:
> I have some doubts that splitting the support of the tile lay between the
> UI
>
> and the server is optimal. Especially if both have to do route
> calculations.
>
> To allow lightweight clients in the long run (think a browser), that part
> should be server only.
>
> I think there are two alternative options to consider:
>
> A) Are you really convinced that the message size for a complete list of
> possible tile lays and orientations is excessive? Assume that you have 20
> hexes with 6 tiles each to replace. That is 120 combinations and each hex
> and
> tile can be identified by 2 bytes. A bitset for the 6 orientations would be
> another 1 byte. Thus overall a 600 bytes message. Even ten times larger
> should work.
>
> B) The client could ask the sequentially about the available options: First
> the server supplies a list of hexes, the UI selects the hex, the server
> response with available tiles, after tile selection, possible orientations
> are transmitted.
> I used this approach of partially completed actions for the map correction
> action, however for a different reason.
>
> Between the two approaches I am personally indifferent, B) is somehow more
> complex to implement, but has the advantage that all logic stays in the
> backend.
>
> >From a network point of view solution A) is preferred, if the restricting
>
> factor is latency, B) to solve bandwidth issues.
>
> Stefan
>
> On Friday 25 June 2010 15:16:25 Erik Vos wrote:
> > [EV] Yes, in principle you are right on the client/server task division.
> > But in this case, it would mean that the server would need to send to the
> > client a full list of all tiles in all valid orientation that can be laid
> > in any layable hex. Although that would be the right thing to do in
>
> theory,
>
> > it would overload the client/server communication a bit, to my taste.
> >
> > LayTile is already prepared to carry a list of layable hexes. My
>
> preference
>
> > would be to use only such a list, and leave sorting out the valid tiles
>
> and
>
> > orientations to the UI. Most of that is based on the current map and the
> > static tile upgrade specifications (any static info is always available
> > to the UI). Then the only missing info in the client is about any allowed
>
> lays
>
> > in unreachable hexes (already passed in special LayTile actions) and any
> > reachable but disallowed hexes (partly covered in special code, partly
> > yet uncovered, I think). Starting to use that list of layable hexes might
> > fix the latter hole.
> >
> > However, this might imply that route evaluation should finally be done
>
> both
>
> > (and separately) in the server and the client. IMO the server should be
> > able to do a full validation of everything it gets from the clients (even
> > if we only partially implement such validation). But I'm not sure how you
> > think about that....
> >
> > Erik.
>
> ---------------------------------------------------------------------------
>- --
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel