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

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

Stefan,

I remember Brett also once proposed Jabber to be used in the way you
suggest. That certainly seems a viable solution to me, and much easier to
achieve than mine; whether or not internet-play development would end there,
I don't know.

In any case, in your approach it doesn't matter much in which way the UI
gets updated. And, as I already said, the tooltips can be done in any way.

Although the current Rails Model/View implementation allows pulling, I don't
see the added value of it when only used that way. Its strength is enabling
the push through the Observable/Observer pattern. For pulling, a direct (or,
perhaps in the future: remote) method call works just as well. In other
words, I only see value in a separate ToolTipModel if the tooltips are
pushed. And even then, why not have the existing MapHex model do the same
job? It's already there, waiting for you to be enhanced...

Just my ideas, all this; I don't want to keep you from doing Good Things
your way. However, discussions like these, which I very much appreciate,
might help to prevent us drifting apart too much... :-)

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Wednesday 18 August 2010 23:52
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Some (multi-)undo related bugs

Erik:
thanks for outlining your approach.

What makes things difficult to discuss, but easier to implement is the fact,

that Rails has an additional layer of explicit models for the UI, which 
transform the game elements in something more digestible for the 
Take the example of shares, for which the ShareModel combines the
information 
of the certificate portfolios.

Something similar would be a ToolTipModel that generates toolTip String from

the deeper game model elements. This was my motiviation to suggest the move
of 
the generation of the ToolTip text to the game(.model) classes. I am very
much 
agnostic, how the information is passed around between client/server
model/UI, 
any of your solutions is a valid one. In the case of ToolTip it seems to me 
that the pull approach is efficient. One could even start pulling the data
as 
soon as a user hoovers over a hex, the ToolTip display is already delayed by

definition.

My vision for online play currently is not a split in remote clients and a 
centralized server, but rather have each player a client/server combination 
locally (similar to what we have now) and merely pass around the actions 
between the server instances. Each client than still gets update from the 
local server instance, thus keeping network traffic at a minimum. 
My current idea is to use the XMPP(rotocol), better known as Jabber, which 
allows to pass around serialized objects or xml/json messages with existing 
Java libraries (e.g. Smack). This would strongly leverage on existing 
infrastructure.

Again a rather long text for such a simple fix ;-)

Stefan


On Wednesday, August 18, 2010 11:06:49 pm Erik Vos wrote:
> * 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).

----------------------------------------------------------------------------
--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel