Menu
▾
▴
Re: [Rails-devel] Trigger implementation / bug-fix release?
|
From: Stefan F. <ste...@we...> - 2010-07-05 22:25:47
|
Erik, sorry for not providing satisfying answers to your q's. I will try a little better, but not too much, as I am currently more concerned about my sequence proposal. And even more words might not replace a working example. More comments see below, Stefan On Monday 05 July 2010 21:13:55 Erik Vos wrote: > 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? > It works the way around (at least half way): All Moves are already register themselves with the current MoveSet. The MoveSet (or the MoveStack) then forwards those to the TriggerManager (for separation from the Move classes - by your request). The triggers register themselves on creation (preferably from XML via the standard Rails mechanisms) to the TriggerManager only. Thus there is only a one time/one place register necessary. > Another question: how do you prevent infinite loops? Moves that trigger > actions that create more moves that... The mechanism (as any other with a similar intention) cannot prevent infinite loops: Only the logic of the triggers themselves can do this. But your suggested observer mechanisms can easily create infinite loops as well: Think about a maphex change which causes the observer to change the maphex again. Only if the observer itself decides to stop the loop at some time, the infinite loop is broken. > > 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. I disagree here: In my perception moves (at least a substantial subset of them) are part of the game logic. Putting everything into Manager/Rounds puts a too strong burden on those (see the other mail). And the trigger mechanism explicitly addresses those cases, where low-level changes activate other (high)-level actions. Every tile lay (regardless who did it) can activate the destination run, any additional share might float a company. > > 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 > > > --------------------------------------------------------------------------- >--- 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 |
