rails-devel

RE: [Rails-devel] Operating Round

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

>I could change the isCompanyWhateverable methods (or any other method) 
>to suit your approach if you would want to highlight the clickable areas 
>(which I would recommend).

Eh. Not really necessary. If you look at my current UI code, you'll see that all clickable areas are simply a matter of calling the .setBackgroundColor() method on the clicked area.

I suppose I could set a border on the clickable areas so that there's less guesswork involved in spotting what's clickable and what's not.  At this point I think it might be a little less than obvious to everyone but me, but who knows.  I figured I'd let that kind of minor tweaking slide until all the major pieces are functioning.

 
>I don't see a real need to use exceptions right now,
>unless you would find checking the return values cumbersome.

From a code cleanliness perspective, they're about equivalent. An If/Then is about equally as ugly as a Try/Catch.

The only real advantage to using exceptions is that we can save all the condition checking for the UI rather than having each layer doing its own sanity checking. On the other hand, having each layer doing sanity checking might be preferable.

Each approach seems to have equal value.  So, I guess it's a matter of whether you want to just throw exceptions or whether you want to actually code the checks into the layers you're working on. I'll let you make that call.

>BTW I'm testing an initial version of GameManager, which, however,
>does not handle the private auction yet. That will come next.

Excellent. 


---Brett.

RE: [Rails-devel] Operating Round

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

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

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

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.

RE: [Rails-devel] Operating Round

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

> > (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 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 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).

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

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.

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

Erik.

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

RE: [Rails-devel] Operating Round

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

I have checked in the results of the class/interface renaming
that I announced a while ago:
Certificate(I) -> PublicCertificate(I),
and a new top-interface Certificate.

As this affects many classes, please update before you start new work.

Certificate is currently extended by PublicCertificateI
and PrivateCompanyI. Whether or not further changes are needed
will turn out when I have made more progress in implementing
the auction/startpackets. I cannot judge all that now.

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

Yes. But I will call it StartRoundI and the 1830-style auction class
something like StartRound_1830.

We might also need a top interface for the kind of exchange and merge
rounds that occur later in some games (1835, 1841, 18EU, 1826),
which might be named SpecialRound.

But I doubt if we need an interface to combine these two types of 
"special rounds", as I think these have very little in common.
Should I be proved wrong here, it should be easy to insert such an
interface.

Erik.

RE: [Rails-devel] Operating Round

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

> >BTW I'm testing an initial version of GameManager, which, however,
> >does not handle the private auction yet. That will come next.
> 
> Excellent. 

In fact I'm already looking at the auction. The point is, that several
games (for example 1835) have "start packets" that contain both private
and public (minor and even major company) shares. To put these all
in a nice collection I need an interface that covers them all. That means:
a superinterface above PrivateCompanyI and CertificateI.

I would propose the following:

- rename Certificate(I) to PublicCertificate(I) 
[BTW I am willing to reconsider Stock or Share for shortness sake],
- create a new interface Certificate that is implemented by both
PublicCertificateI and PrivateCompanyI. 
(Another reason why this makes sense is that privates count against
the certificate limit in most 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.).

For 1830 I will use this feature for the C&A/PRR and B&O/B&O combos.
That saves me from coding two "private special properties", 
which become instances of a generic mechanism.

OK?

Erik.

[Rails-devel] GameManager and Bank.format

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

> > >BTW I'm testing an initial version of GameManager

Checked in now, and used by StockRound, OperatingRound and GameTestServlet.

Also of interest is the static method Bank.format(amount),
which can be used to format a game's money amounts according 
to whatever the local currency is. 
This is configured in a format (now hardcoded in Bank)
where the amount is represented by the @ character.
So for 1830 the format is "$@". 
This will of course become a configuration item.

CashHolder classes now have an additional method
String getFormattedCash().

Erik.