Re: [Rails-devel] Trigger implementation / bug-fix release?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Stefan,

You haven't yet answered my questions. Are you going to register the
triggers with every single newly created move of a type? If not, how does a
Move/MoveSet know what to trigger, and how can it find the objects to
trigger without such explicit registration?

Another question: how do you prevent infinite loops? Moves that trigger
actions that create more moves that...

I still don't like this level mixing at all.

Moves already can trigger Observables to update their observers, but that is
for one simple, limited, low-level use only. I would like to keep the actual
game logic at the Manager/Round (i.e. upper) level.

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Monday 05 July 2010 00:25
To: Development list for Rails: an 18xx game
Subject: [Rails-devel] Trigger implementation / bug-fix release?

[changed Subject]

Erik:
thanks for your suggestion: At the point of my first proposal I had no clear

preference whether to observe the Model/State objects directly or to link 
with the Move objects which define their changes. In the latter case I use
the 
existing link of all Moves to the MoveSet and have the MoveSet updating the 
triggerable objects. Here the triggerable objects are observers to the 
MoveSet. To keep things decoupled the MoveSet can forward the notification
of 
the triggerable objects to the TriggerManager.

I started to look into several use cases besides checking for destination
run 
routes and it seems that in all cases the Move mechanism offers advantages.

The important difference can be seen in your suggestion below: In a sense
you 
recreate the TileMove information again: The TileMove activates the MapHex 
update and this update is then observed by the MapManager, which then 
triggers the route check. Why not have the TileMove directly (via MoveSet 
which every Move calls anyhow) trigger the route check?

Other advantages here is that the TileMove is more specific than the MapHex 
updates (which include changes of tokens as well) and it requires that the 
MapManager registers itself as observer of all MapHexes. The second
advantage 
of the Move objects are the fact that they contain additional 
information/attributes about the change and can be used for further 
filtering.

With my current idea (in mind) the MoveSet object would forward each Move to

the TriggerManager. A trigger can either be fully hardcoded or be 
partially/fully configured in XML: Either only the Move class (and
additional 
variables to be checked) are defined or even the method to be called can be 
configured. In the latter case the concrete trigger sequence is coded in
XML.

All of this is still only preliminary as I am currently focused on providing
a 
prototype implementation of the sequence model.

I do not know, what the current state of your changes are, but from my point

of view a bug-fix release soon would be nice, before the start of more 
drastic changes.

Stefan

On Sunday 27 June 2010 17:08:58 Erik Vos wrote:
> Thinking about it, I realised that such a trigger mechanism already exists
> and is widely used in Rails: the Observer pattern.
> All States and several other object types are also ModelObjects, which
> extends Observable, so any other object implementing Observer can register
> at any State to be informed about any value changes.
> This is mainly used to update the UI, but IIRC there are already some
> server-internal Observer/Observable pairs.
>
> I think this existing mechanism fulfills your need, and it works at the
> proper level (using States/ModelObjects in stead of Moves).
>
> In the example case of destination checks: each MapHex is an Observable
> that updates its Observers (which currently only are the corresponding
> GUIHex objects) each time a new tile is laid. If MapManager would register
> itself with any MapHex it is creating (this isn't done yet), it will get
> called on every tile lay, passing the new tile and its rotation (perhaps
> the hex id should be added).
> So, whenever called, the MapManager can inititate any destination checks
or
> anything else that is needed.
>
> Erik.
>
> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Sunday 27 June 2010 00:33
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3
> --undoduringCGRformationhangs game
>
> * My own first idea was to use a specific trigger interface and require
> triggers to be explicitly defined. But I realized that the moves are
> excellent triggers and the Moveset a very good place to pass the messages.
> Moveset could still delegate the task to a TriggerManager, if a better
> separation is required.
>
> And I want low-level triggers, to avoid that every (high-level)
> implementation
> has to remember to call the trigger.
>
> [EV] I still don't like at all to use the Move/MoveSets. I'd much prefer
to
> keep these clean.
> How are you going to tell an object Move that it is a trigger and what it
> must call if it is? Or should all object moves always call all
> triggerables, or the TriggerManager (and how can it find that one)? I
> completely don't understand how you see this working, and what's the
> benefit of using the Moves.
>
> Take the example: A candidate in the long run ist the function that checks
> if
> a company is floated. Every (high-level) method that moves shares out of
> IPO
>
> has to check if the company has floated. If the trigger is used, this is
> done
> automatically. This would also cover special cases in games, which are not
> yet implemented.
>
> [EV] What is exactly registering to what in this example? And what is
> triggering what? And how can both the registerer and the triggerer find
> their callees?
>
> Erik.
>
>
>
---------------------------------------------------------------------------
>- --
> 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
>
>
>
---------------------------------------------------------------------------
>--- 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

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