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

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

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.