RE: [Rails-devel] Operating Round

[Brett <wak...@ea...>]

On Thu, 2005-05-05 at 19:25 +0200, Erik Vos wrote:
> > > (Another reason why this makes sense is that privates count against
> > > the certificate limit in most games).
> > 
> > Really?  
> > 
> > Hmmm... in that case, we probably do need a 
> > privateCertificate, and a parent Certificate class for both 
> > PublicCert and PrivateCert.
> 
> Well.... my approach so far has been that a PrivateCompany and its
> certificate coincide, because there is never more than one.
> This is not so for (any type of) PublicCompany (including minor companies,
> even though some also have one certificate).
> My approach is not without its drawbacks (which I was trying to smooth
> out in my new interface proposal), but separating a private and its
> certificate looks a bit over the top to me. But it certainly is an option.


I think with your mention of 18US doing things radically differently,
it's probably prudent to go with the solution that is over the top for
the smaller games because it'll be the necessary thing for the larger
scale games.


> > > I will also create a new class StartPacketItem, that will contain 
> > > either one or two Certificates, the second being the additional 
> > > certificate that comes with some primary ones. The Start Packet will
> > > be configured separately from the Private companies 
> > (because of 1835 etc.).
> > 
> > Why wouldn't you just use the certificate from the Public 
> > Company portfolio?
> > 
> > Here's how I see this working:
> > 
> > GameManager fills each publicCompany portfolio with their stocks.
> > GameManager then examines the rules for each private, and if 
> > the private comes with a publicCompany certificate, like the 
> > B&O or PRR, just call the existing set*() methods to add the 
> > publicCompany certificate to the privateCompany portfolio.
> >
> > When the privateCompany is bought, we add the contents of its 
> > portfolio to the player portfolio.
> 
> Hmmm, currently privates don't have a Portfolio because they
> never own anything, and because they are not CashHolders
> (which is supposed to be the case for Portfolio holders).
> Adding it would IMO extend Portfolio beyond its intended limits.
> 

I can see two ways of doing this:

Portfolio holders and Cash holders are separate with some
interdependency, but not mandatory interdependency.

Or, the Cash Holder in the case of Privates is the Bank or the Private's
current owner (a Player). So, if the private is paid money, it is passed
upwards to the parent's wallet.

I like the idea of allowing Privates to have Portfolios because it looks
like it'll be more flexible for future development.

> I could add an attribute "CertificateI comesWith" to PrivateCompany,
> that would enable the combo in a different way.
> 
> But I still would need an additional interface to define start packets with.
> Maybe my proposed superinterface Certificate could be used for that as well.
> 
> And I do need to define start packets separate from other config items,
> perhaps in a separate Startpacket.xml or in Game.xml.
> Here I must keep referring to 1835, where the "start packet"
> (the name was introduced with that game) consists of
> - 6 private companies (4 of which come with a major company share),
> - 6 minor companies (1-share companies, which run trains, 
> and later merge into a major company),
> - 1 presidency of a major company (Bayrische Eisenbahn).
> This packet is not auctioned, but all of it must be sold before a real
> stock round can begin (there are various variants on how the selling
> is done, because many believe the original rules to be broken).
> 

I agree that no matter what we do, StartPackets need definition and
probably their own XML file.


> Currently, privates and certificates have nothing in common,
> so I need that superinterface.
> 

If we implement a has-a relationship between Privates and Certs, I think
this problem is solved without rearranging our existing hierarchy.

> And then I need the ability to define more than one start packet,
> so I suppose I need a StartPacket class, which may have multiple instances.
> 
> For instance: in 1837 we have three start packets, which must all
> be sold consecutively before major shares come available.
> 
> And then the new 18US - a game that seems to devalidate many
> assumptions that we have all considered sacred so far -
> where a second start packet becomes available later in the game.
> 
> I hope you see why I think that the concept of a "start packet"
> and its contents should be intertwined with other concepts
> as little as possible - anything goes here.
> 

I agree.  This seems to further support my idea of having a SpecialRound
interface that we derive auctions and startpackets from.


> > If a privateCompany can exchange itself for a share of 
> > publicCompany stock, such as in 1830 with the private company 
> > that may be exchanged for a share of NYC, we don't need any 
> > initial stock allocation, we just process that as two steps: 
> > close the private, buy an available share for free.
> 
> Sure, that is no problem, but quite a different matter.
> 

This was mentioned just for contrast to the current problem.



---Brett. 

RADIO SHACK LEVEL II BASIC READY >_