From: Stefan F. <ste...@we...> - 2012-06-30 05:29:41
|
Another but hopefully the final update to the new Item hierarchy in Rails 2.0. The current iterations is simpler and closer to what we have in Rails 1.x, but still powerful. An implementation is already there, but some major testing is still required. So what is the core idea? One issue (especially with having more games added) is that is not easy to access all objects of a Rails game from anywhere in the code. However this is needed especially for the specialized classes that cover the (more or less obscure) rules that pop up in various 18xx games: For those it cannot be predicted which parts of the game might interact. To achieve this, every object (read: every Rails java object, which includes all game objects) is part of a tree hierarchy: To ensure this every (non-utility) class in Rails is derived from the Interface "Item". It requires the definition of a parent (Item) and an id (String). To locate an item there can be special nodes defined by the Interface "Context", which extends Item. Every Item gets stored inside a lookup table of the closest Context up the tree. An abstract class implementation of a Context is the "Manager". The top node is a special class "Root" which itself an extension of Manager. It serves as the "Super"-Context of all Items. (It might change its name into "GameManager" later, but this is already used). A concrete example: The 1830 Company "B&M" is an Item with the CompanyManager as parent, which acts as the closest Context here. So one could locate B&M by asking companyManager.locate("B&M"). Another possibility is to ask the root.locate("companies/B&M"), if companies itself has the root as parent. Relation to the State mechanisms: The Root itself contains a StateManager which is responsible for handling the changes of the States (those variables which can change during the game progress). An important feature of the object tree is that the parent/id definitions are not states themselves (thus cannot change), however the lookup tables inside the Context are States themselves and can thus change without breaking the undo mechanism. Stefan |
From: Erik V. <eri...@xs...> - 2012-06-30 08:43:20
|
Hi Stefan, This looks great. How to find unrelated objects has been a major problem all the time, and your approach finally fixes that in a consistent way. I'm really looking forward to Rails 2.0! Erik. > -----Original Message----- > From: Stefan Frey [mailto:ste...@we...] > Sent: Saturday, June 30, 2012 7:30 AM > To: Development list for Rails: an 18xx game > Subject: [Rails-devel] Rails 2.0: The item hierarchy > > Another but hopefully the final update to the new Item hierarchy in Rails 2.0. > > The current iterations is simpler and closer to what we have in Rails 1.x, but > still powerful. > > An implementation is already there, but some major testing is still required. > > So what is the core idea? > One issue (especially with having more games added) is that is not easy to > access all objects of a Rails game from anywhere in the code. However this is > needed especially for the specialized classes that cover the (more or less > obscure) rules that pop up in various 18xx games: For those it cannot be > predicted which parts of the game might interact. > > To achieve this, every object (read: every Rails java object, which includes all > game objects) is part of a tree hierarchy: To ensure this every (non-utility) > class in Rails is derived from the Interface "Item". > It requires the definition of a parent (Item) and an id (String). > > To locate an item there can be special nodes defined by the Interface > "Context", which extends Item. Every Item gets stored inside a lookup table > of the closest Context up the tree. > An abstract class implementation of a Context is the "Manager". > > The top node is a special class "Root" which itself an extension of Manager. It > serves as the "Super"-Context of all Items. > (It might change its name into "GameManager" later, but this is already > used). > > A concrete example: > The 1830 Company "B&M" is an Item with the CompanyManager as parent, > which acts as the closest Context here. So one could locate B&M by asking > companyManager.locate("B&M"). > Another possibility is to ask the root.locate("companies/B&M"), if companies > itself has the root as parent. > > Relation to the State mechanisms: > The Root itself contains a StateManager which is responsible for handling the > changes of the States (those variables which can change during the game > progress). > > An important feature of the object tree is that the parent/id definitions are > not states themselves (thus cannot change), however the lookup tables > inside the Context are States themselves and can thus change without > breaking the undo mechanism. > > Stefan > > ---------------------------------------------------------------------------- -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and threat > landscape has changed and how IT managers can respond. Discussions will > include endpoint security, mobile security and the latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Stefan F. <ste...@we...> - 2012-07-02 17:11:05
|
Hi Erik, glad to see that you like some of the refactoring goals... I hope I will be able to make you jump boats at some point in time in the foreseeable future. Stefan On 06/30/2012 10:43 AM, Erik Vos wrote: > Hi Stefan, > > This looks great. How to find unrelated objects has been a major problem > all the time, and your approach finally fixes that in a consistent way. > > I'm really looking forward to Rails 2.0! > > Erik. > > >> -----Original Message----- >> From: Stefan Frey [mailto:ste...@we...] >> Sent: Saturday, June 30, 2012 7:30 AM >> To: Development list for Rails: an 18xx game >> Subject: [Rails-devel] Rails 2.0: The item hierarchy >> >> Another but hopefully the final update to the new Item hierarchy in Rails > 2.0. >> >> The current iterations is simpler and closer to what we have in Rails 1.x, > but >> still powerful. >> >> An implementation is already there, but some major testing is still > required. >> >> So what is the core idea? >> One issue (especially with having more games added) is that is not easy to >> access all objects of a Rails game from anywhere in the code. However this > is >> needed especially for the specialized classes that cover the (more or less >> obscure) rules that pop up in various 18xx games: For those it cannot be >> predicted which parts of the game might interact. >> >> To achieve this, every object (read: every Rails java object, which > includes all >> game objects) is part of a tree hierarchy: To ensure this every > (non-utility) >> class in Rails is derived from the Interface "Item". >> It requires the definition of a parent (Item) and an id (String). >> >> To locate an item there can be special nodes defined by the Interface >> "Context", which extends Item. Every Item gets stored inside a lookup > table >> of the closest Context up the tree. >> An abstract class implementation of a Context is the "Manager". >> >> The top node is a special class "Root" which itself an extension of > Manager. It >> serves as the "Super"-Context of all Items. >> (It might change its name into "GameManager" later, but this is already >> used). >> >> A concrete example: >> The 1830 Company "B&M" is an Item with the CompanyManager as parent, >> which acts as the closest Context here. So one could locate B&M by asking >> companyManager.locate("B&M"). >> Another possibility is to ask the root.locate("companies/B&M"), if > companies >> itself has the root as parent. >> >> Relation to the State mechanisms: >> The Root itself contains a StateManager which is responsible for handling > the >> changes of the States (those variables which can change during the game >> progress). >> >> An important feature of the object tree is that the parent/id definitions > are >> not states themselves (thus cannot change), however the lookup tables >> inside the Context are States themselves and can thus change without >> breaking the undo mechanism. >> >> Stefan >> >> > ---------------------------------------------------------------------------- > -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and threat >> landscape has changed and how IT managers can respond. Discussions will >> include endpoint security, mobile security and the latest in malware > threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |