Re: [Rails-devel] Some (multi-)undo related bugs

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

* The toolTip on hexes was not updated correctly after undo/redos (still 
showing the tile information from the previous state), as the update was 
controlled only by the tile/token lay UI classes and not the game backend.
I shortly considered a ToolTipModel approach, but I realized that is much 
easier to update the toolTip at the time it is requested by the user.
I would still like to move the code to create the toolTip string from the UI

GUIHex class to the game MapHex class to reduce the amount of processing and

calls to the game classes from the UI class. 
Or is there a reason to avoid that, Erik?

[EV] Let me restate the long-term architectural goal (which surely is no
news to you): that one day Rails should support client-server operation,
where one client per player communicates real-time with a central server
over the Internet. Although we are not very close to reaching this goal, I
always use it as a background for any architectural decisions. I want to
work towards it, not away from it.

In this concept, the client (UI) can obtain any info it needs for display in
three different ways:

(1) All static info can be obtained from the objects after these have been
initialised as is done currently. This occurs independently in both client
and server.
(IIRC Brett once made a case to push all static info from server to client
as well as the dynamic info mentioned below. I would that cosnsider that a
more extreme vision than mine, and certainly possible, but it'll probably be
a further development).

Any dynamic (state) info is not directly accessible to the client. As far as
the client needs it for display, it can get such info in two ways:

(2) By having dynamic info be pushed from the server to the client (by
sending that info to connected clients, or queueing it for disconnected
clients). This should happen with all information that must be displayed by
all clients alike: tiles, tokens, money, shares, messages etc. Basically
this amounts to all dynamic info that the GUI needs. This server push has
already been implemented for a large part of that info, but certainly not
yet for all of it.

(3) By having dynamic info be pulled by the client from the server.
Currently this is done in many cases by direct server method calls, as Rails
originally did for all such info. I think we should continue to get away
from that. Network latency and the need to keep all clients on the same
footing are just two reasons why I find this unattractive. We might
encounter exceptional cases that where this approach would be a good
solution, but I don't think there will be many such cases.

--

What does this mean for the tooltips?

Once the UI knows which tiles and tokens are laid in what locations and
positions, almost all tooltip info is static and can be composed from
locally available data as in approach (1). I think the only missing bit is
the current phase (for the offboard revenue values).

Getting to know about tiles and tokens is a bit tricky. Tile info is already
pushed via approach (2) (see GUIHex.update()). This is not the case for
tokens yet, for which the server is pulled (3) when a tile is (re-)drawn
(see, for instance, GUIHex.paintStationTokens()). The latter process
obviously needs to be replaced by a server-push driven one (2). 

The current phase is currently also pulled (3), but, as all clients need it,
it will also have to be server-pushed (2). We probably need a phase model. 

My conclusion is, that in the end it will be possible to compose the
tooltips in the UI only (1), and that there is no real need to involve the
server. But to get the tooltips right now, I concur with your proposal that
tooltips can best be created when requested by the user. For now it will be
acceptable to call the server, if possible via a common interface that is
also used by the drawing code. As said, later on all info will be locally
available after being pushed by the server.

Other approaches are feasible. In (2) the tooltips would be composed in the
server, and pushed by MapHex on any change. The catch is, that we should be
careful not to oversee cases when the text must change: all such cases
should trigger all relevant MapHex models to update their views. That's
added complexity I'd rather avoid.

In this particular case, even method (3) might be an option, because
tooltips only need to be displayed on request. However, I fear that the
slower tooltip appearance (because of latency) could be a bit annoying. I
don't think we should go this way.

My opinion therefore is, that we should leave tooltip composition in the UI
(but fix it as discussed).

-- 

A separate issue is, that the tooltips currently aren't multi-lingual. IMO
that should change.

--

Talking about internet play and multi-linguality: I envisage that clients
playing the same game could use different languages. This would mean, that
all multi-linguality must ultimately be achieved in the client/UI anyway,
not in the server/game-engine. Each message will then be pushed as a keyword
with its parameter values rather than as full text.

--

Sorry that this response to only one of Stefan's questions was even longer
than his whole message. But in any case now you all know what I might (or
might not) find myself working on after I have retired next year, if not
implementing new 18xx games, or doing other interesting things....

Erik.