Re: [Rails-devel] 1880 Implementation: Opinions wanted

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

My initial views:

 

a)       

Currently, there are two ways to assign rights to Players and to Companies: with SpecialProperties and with Rights.

SpecialProperties always (at least so far) come with acquired private companies.  In a game like 1835, the special property immediately transfers to the player owning the private, and I believe this is the way you should try to implement the 1880 private properties as well.  Implementing new special properties is not trivial, and I think that in many cases you will have to create new (either generic or 1880-specific) SpecialProperty subclasses.  Of course I’ll be willing to help you out.

 

I understand you would like to display such player-owned private rights in the UI.  This is not yet done anywhere.  A Rails principle is that players ought to know the game rules, and in this case, what special rights they have when owning certain privates (which *are* displayed). They can also look up private rights in the Info menu.  See 1830 for examples.

 

Right has been created for 1830 Coalfields and is  intended to take care of properties that are not linked to privates but can be acquired by everyone.  I have considered handling the Coalfields right as a SpecialProperty as well, but handling was too different to make that achievable without major changes.  I would think that the 1880 building rights should be implemented as Rights, but (as always) the proof of the pudding will be in the eating. 

 

As with all new generic items intended to cover new game-specific features that *may* have general impact, I consider the Rights implementation as provisional as long as it has not been proven to be able to cover multiple cases, and Rights definitely falls into this class.

 

a)       

I believe this is the same situation as we have with 1856 if the CGR has no train: it “borrows” the train that currently is on top of the IPO stack.  Effectively, it runs that train without ever getting it.  I think the same solution should apply to 1880.  So we don’t need a new portfolio: it already exists, and is called “IPO”.

 

As for displaying a borrowed train: if that doesn’t already happen in 1856, it’s probably a good idea to add it there too, so it would be a generic feature.  I would start checking out if updating TrainsModel could cover such a case, e.g. by adding a method ‘useBorrowedTrain (Portfolio ipo)’.  Passing a reference to IPO would cause displaying the first available IPO train in square brackets (for instance).  Passing null would switch that off and return to the normal display.

 

Erik.

 

 

 

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Sunday, January 29, 2012 12:22 AM
To: Rails Development
Subject: [Rails-devel] 1880 Implementation: Opinions wanted

 

Hi,

 

i would like to get some opinions for two todos next on my list.

 

a) Major Companies in 1880 have their tile laying rights bound to a "building" right. This will be determined not at creation of that company but at Start based on the director share type and the player chosing from a number of indefinetely available rights.

 

In Connect with that "semi-static" Right, the company in question will receive a numer of rights if the director of that company holds a private (Taiwan, Ferry, Bridge). Its not linked to the company but through the player to all companies he owns.

 

If i want to display those right i think i'll have to make use of the not yet fully implemented RightsModel Class. Any objections, different approach suggestions here ?

 

b) the train lending feature: For the Investors/Minor Companies the currently in the bank available train is used to determine the Revenue.

I would like to have that displayed in the companies portfolio and of course used in the revenue calculation.

 

I propose to generate a 4th heap/portfolio which will hold the not yet leased/lent trains and then use a leaseTrain method that will move those trains into the Minors portfolio upon start/event and move the already listed trains to the scrap heap.

 

Any ideas there ? Cause the low level approch of using the Portfolio mechanismn directly is not what should be done or? (Besides we dont have a removeTrain method thats visible outside of Portfolio for a reason anyway.)

 

Regards,

Martin