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

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

See below.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Sunday 20 June 2010 14:41
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1835 playtest report - Rails 1.3

Erik:
to continue the discussion, see my comments / questions:

> The rule enforcing for tile laying in Rails has not changed (yet).
> Enforcement is on my list, but it requires a more drastic change of the
> current UI implementation. It will also consider the various approaches
> (permissive, restrictive, semi-restrictive), with the default set
> accordingly
> for each game.
>
> [EV] A permissive check would be easy to add. All that's needed is adding
a
> call to a method that returns if a given track on a given hexside is part
> of a route (to be inserted in GUITile around line 115). The other
> approaches would require some more coding but need the same method call.

What currently stops me somehow from implementing it there is the more
general 
question, if those validity checks should be part of the UI-code or better 
handled by the backend?
Most likely for the current implementation it does not matter, but in the 
longer run (at least for my understanding) the backend should provide the 
information about valid tile lays for the UI. This information should be 
passed to the UI via the action objects?
I have not searched the archive of the development for the issue of 
client/server separation exactly, so I do not know, what your planning
there, 
but I would have guessed, that you prefer to have as much in the backend as 
possible.

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