rails-devel — List for discussion of Rails development

[Rails-devel] Update

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

It's been a while since we've seen much traffic on the list.

I've been slowly poking and prodding the Hex code into submission.  Right now, I've got a working test class for it in CVS.  Essentially it's just a stripped down version of the Colossus code. I've stripped out all of the Colosssus-specific bits.  So, now it's ready for us to extend it to fit our own needs.

The todo list I've got so far for the HexMap looks something like this:

# Define map XML specification
# Generate map XML files
# Need to create classes for loading the map files.
# Decide whether to draw hexes using Drawing2D or use loaded graphics overlayed on top of the hex panel.
# Decide on tile XML specification
# Generate tile XML files
# Create code for placing tiles

[Rails-devel] New UI

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

It has been quiet for some time on this list, but that was
not because nothing was happening. In fact I was working
on a long haul: a Swing UI that would include the same functionality
that I had included in the test servlet before.

It's now all committed, as I consider it ripe for publication.

The class to run is test.GameTest (Brett's original test class),
which I have changed to open the new StatusWindow2 in stead
of the original StatusWindow. 

I believe this UI is pretty intuitive. The main thing less so might be
that if a number of light-orange buttons is displayed, one of these
must be pressed to select something. Such a selection will activate 
a conformation button at the bottom of the relevant window.

Of course the functionality is still very limited.
It includes the 1830-style start round and the usual Stock and
Operating rounds (currently only one OR per SR).
Other limitations are:
- no tiles, tokens, trains and phases yet. In an OR only the
financial aspects can be handled.
- no private special properties, except the "comes with" shares.
But privates can be manually closed.
- no special rules as in 1835/1856; the Pr and the CGR are normal companies.
Etc. etc.

The main goal of this early UI still is to find out how
the UI/Model interface should look like. There are still lots
of loose ends and suboptimal solutions; those can be dealt
with later.

One annoying bug is that, if a player sells the last private to a 
company, that private will remain showing up under the player's
possesions (without adverse effects on the game). I don't know why.

Another is, that the Start Round window shows ups initially with 
the buttons partly hidden. These become fully visible when a private is
selected. 

The ui package now has some redundant classes, which will be 
removed later. Some of these reflect previous work by Brett.

I hope you like this UI. Enjoy.

Erik.

RE: [Rails-devel] 1835 & lots of stuff.

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

Hi Brett,

I have just finished and committed that.
The missing bit was the auction of just one
item that has several bids on it when the previous
item gets bought.

My original idea was to create a separate BidRound
for that, but it turned out to be easier to do the
auction from within StartRound_1830 itself.

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf Of Brett
> Sent: 24 May 2005 23:59
> To: rails-devel
> Subject: Re: [Rails-devel] 1835 & lots of stuff.
> 
> On Tue, 2005-05-24 at 23:46 +0200, Erik Vos wrote:
> > To get a different view on how things work
> > I have implemented part of 1835, including
> > 3 different variants for the Start Round.
> > 
> > This includes Minor companies that have no stock price
> > but that run trains, revenue splitting, start round
> > player sequence reversals, fixed par prices,
> > variant selection.
> > 
> > GameManager is now configured via ComponentManager and has
> > a separate section in Game.xml. This will become the main 
> > location for game-specific rule definitions.
> > 
> > Erik.
> 
> 
> 
> Excellent!   How complete is the 1830 start round?
> 
> 
> ---Brett. 
> 
> "It's curtains for you, Mighty Mouse! This gun is so futuristic that
> even *I* don't know how it works!" -- from Ralph Bakshi's Mighty Mouse
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit 
> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 

Re: [Rails-devel] 1835 & lots of stuff.

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

On Tue, 2005-05-24 at 23:46 +0200, Erik Vos wrote:
> To get a different view on how things work
> I have implemented part of 1835, including
> 3 different variants for the Start Round.
> 
> This includes Minor companies that have no stock price
> but that run trains, revenue splitting, start round
> player sequence reversals, fixed par prices,
> variant selection.
> 
> GameManager is now configured via ComponentManager and has
> a separate section in Game.xml. This will become the main 
> location for game-specific rule definitions.
> 
> Erik.



Excellent!   How complete is the 1830 start round?


---Brett. 

"It's curtains for you, Mighty Mouse! This gun is so futuristic that
even *I* don't know how it works!" -- from Ralph Bakshi's Mighty Mouse

[Rails-devel] 1835 & lots of stuff.

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

To get a different view on how things work
I have implemented part of 1835, including
3 different variants for the Start Round.

This includes Minor companies that have no stock price
but that run trains, revenue splitting, start round
player sequence reversals, fixed par prices,
variant selection.

GameManager is now configured via ComponentManager and has
a separate section in Game.xml. This will become the main 
location for game-specific rule definitions.

Erik.

[Rails-devel] Stock Round improvements

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

I have checked in additional stock round related work:
- bug fixes
- more validity checks
- presidency changes, incl. dumping
- methods for handling double non-presidency certificates
(not yet fully implemented).

StockRound now has some additional buy/sell method signatures
to handle different certificate types.

In addition, privates can now be closed directly from the UI
in an Operating Round. In the future this will of course be
done automatically, dependent on other actions.

With these changes, most actions of an 1830 game can now be
correctly simulated, at least financially, from a UI 
(like GameTestServlet does). 

I will continue fixing more start- and stock round details,
including those required by 1835, before I will start adding
trains. That will probably happen after my vacation, which is
from 22 June - 12 July.

Erik.

[Rails-devel] New test output & float perc.

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

I have renewed the output examples from GameTestServlet
on http://home.hccnet.nl/erik.vos/18xx.html.

No major differences, but all game actions are now done via
methods of the Round subclasses.

I have also implemented the float percentages, including
the "special" 20% for Frisco in 1870.
The 1856 float percentage is currently fixed on 30%.

Erik.

[Rails-devel] StartRound etc.

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

I have committed a whole bunch of changes, mainly
in connection with the implementation of StartRound_1830,
a class that implements the main part of an 1830-like private
buying-and-bidding round. The single-private auction, where two or more
players are bidding or passing for one private, is not yet
implemented (currently, the highest initial bidder gets the private).
Auctioning may become a separate Round subclass,
but I'm not sure yet.

Also implemented are the Start packets - a separate section
in CompanyManager.xml. For 1830-like games that may look like
overkill, but we will need that for 1835-like games.
(The base prices are now defined twice, only one of these will be retained).
The "free" PRR and B&O shares (for 1830) come with the privates,
and the B&O start price must be set on buying the related private.

The general procedure to be followed by the UI is like;

forever {
   Round currentRound = GameManager.getCurrentRound();
   if (currentRound instanceof StartRound) {
       int step = ((StartRound)currentRound).nextStep();
       if (step == StartRound.BID_OR_BUY) {
           // set up UI for a bid/buy action
       } else if step == StartRound.SET_PRICE) {
           // set up UI for setting a start price (i.e. B&O)
       }
   } else if (currentRound instanceof StockRound) {
       // Set up UI for the next stock round action
   } else if (currentRound instanceof OperatingRound) {
       int step = ((OperatingRound)currentRound).nextStep();
       if (step == OperatingRound.LAY_TRACK) {
           // set up UI for track laying. 
           // Currently only the cash spent can be processed.
       } else .....
   }
   
    // process player action, by calling currentRound methods,
    // depending on the currentRound instance and the value of step.
}

Please note, that processing player actions may change the result
of GameManager.getCurrentRound(), so it is important to call 
getCurrentRound() between a processing player action and setting up
the UI for the next action.
Round switching is done by the various Round classes in cooperation 
with GameManager.

BTW GameManager is currently a curious mix of static and non-static methods.
I'm not yet sure which way it will go. Maybe we will need different 
GameManager classes.

There is still much to clean up and refine, but I think it was time
to get some clarity on how the View/Model (i.e. UI/Round) interfaces
could look like. 

test.GameTestServlet works, and may provide code examples.
I will shortly publish some new HTML output examples.

There is a lot more to tell, but for now this should do (and it's very
late).

Erik.

Re: [Rails-devel] Drawing the Map

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

On Mon, 2005-05-09 at 16:40 -0700, John David Galt wrote:

> >> 2. An XML file, using the DTD, assigns the default terrain for the
> >> map and then specifies which hexes deviate from this default:
> >>
> >> <battlemap terrain="Brush" tower="False">
> >>     <battlehex x="0" y="2" terrain="Brambles" elevation="0">
> >>     </battlehex>
> >>     <battlehex x="1" y="3" terrain="Brambles" elevation="0">
> >>     </battlehex>
> >> </battlemap>
> 
> Not quite.  "Brush" is the name of that Battleland as a whole.  The
> default terrain type for individual hexes is not specified, it is
> always Plain.  (And tower=True|False must be specified because Tower
> lands have their own rules about which side the attacker enters from,
> and about how the defender sets up.)
> 


Correct.  This is where I suggest we deviate from their definition and
choose attributes that more closely fit our needs, such as a "default"
terrain type. For most maps, it'll likely be plains, but for some maps
it might be mountains, or, for 2038, it'll be something else entirely.


> > Please keep in mind that:
> > a. Some games have hexes with the flat sides north and south,
> > other games have the flat sides east and west.
> > b. Some games have the letters left-to-right, others top-to-down.
> 
> There are also some games that use oddball schemes.  For instance,
> 1853 uses a capital letter for the row, and small letter(s) for the
> column, and the columns after z continue with aa, ab, ac...
> 

As with my response to Erik, this is exactly why I suggest we use a
game-agnostic notation for the code and allow for an associated
parameter to aid in cross-referencing.

I think it will be much too painful to try supporting everyone's layout
scheme in the map layout definitions themselves.



> > Not sure if we should distinguish Hex and Tile at all,
> > given the fact that we have preprinted hexes etc.
> 
> In my own project, I included a designation of a preprinted tile as
> one of the properties of every hex.  (This means that the preprinted
> contents of every hex in the game have to be included in that game's
> list of tile types, including BLANK; though if there aren't any tiles
> that match the hex, its count in the inventory gets set to zero.)
> 
> The code to place a tile then has to check whether the hex already
> has a tile (so you don't try to return a preprinted hex to the tile
> supply); but it's a very simple addition to the code, and it allows
> the Tile class to be made responsible for all track-connection logic.
> 
> Similarly, when a phase change causes a red hex (or a similar gray
> hex in 18GA, etc.) to increase in value, you simply define another
> "tile type" with the higher value and have the phase change event
> cause the new tile to be automatically played.  (There is already at
> least one game, 1837, where a phase change causes an automatic tile
> lay.)
> 


An interesting idea.



---Brett. 

When the speaker and he to whom he is speaks do not understand, that is
metaphysics. -- Voltaire

RE: [Rails-devel] Drawing the Map

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

On Tue, 2005-05-10 at 00:47 +0200, Erik Vos wrote:
> > 1. They defined an XML DTD that defines the shape of the 
> > board in simple alpha-numeric coordinates:
> > 
> >     label (
> >          A1|A2|A3|
> >         B1|B2|B3|B4|
> >        C1|C2|C3|C4|C5|
> >       D1|D2|D3|D4|D5|D6|
> >        E1|E2|E3|E4|E5|
> >         F1|F2|F3|F4    )  #REQUIRED
> > 
> > The DTD also defines the types of terrains available to be 
> > potentially assigned to each hex.
> 
> Please keep in mind that:
> a. Some games have hexes with the flat sides north and south,
> other games have the flat sides east and west.

As far as I know, this is simply an issue of rotation. The hex itself is
unchanged otherwise. We're not dealing with a six-sided polygon with
irregular side lengths (such as the Colossus mainboard).

So long as we're tracking the vertices and/or sides of the hex (e.g.
entrances and exits), I don't really see that this is a problem.


> b. Some games have the letters left-to-right, others top-to-down.
> c. a) and b) do not seem to correlate very well.
> So I think we will need two independent parameters controlling this.
> See the recent discussions on hex numbering in the 18xx group!
> We should adhere to the numbering of the game as published, or,
> where the map has no numbers, with common PBEM practice.
>  


I think this is a separate issue from how we internally represent the
hexes in the code.

In the XML we can parameterize the tile names to help coordinate the
translation, but I think we ought to have a universal coordinate naming
scheme for laying out the map that is specific to our implementation.

As with the Colossus battle map example, this layout is simply to define
the dimensions of the map horizontally and vertically, not their
contents, and not what tiles are used. 


> > 2. An XML file, using the DTD, assigns the default terrain 
> > for the map and then specifies which hexes deviate from this default:
> > 
> > <battlemap terrain="Brush" tower="False">
> >     <battlehex x="0" y="2" terrain="Brambles" elevation="0">
> >     </battlehex>
> >     <battlehex x="1" y="3" terrain="Brambles" elevation="0">
> >     </battlehex>
> > </battlemap>
> 
> Something like that, yes.


Here is where we'd define whether a particular hex is a mountain, a
river, ocean, or a specific town.


> > 3. The Hex object, along with child objects, serves to track 
> > each indivdual hex's properties, including entrances and exits.
> > 
> > I think that for the purposes of developing a route 
> > validator/calculator, we'll need to be able to track this 
> > information for each tile layed.
> > 
> > For defining tiles, I think we'll need a Tile class that 
> > extends from Hex, and stores information related to the 
> > layout of the track.
> 
> Not sure if we should distinguish Hex and Tile at all,
> given the fact that we have preprinted hexes etc.
> 

I make the distinction because the starting map has contents, such as
mountains, that aren't a numbered tile. Tiles are, to me, the hexes that
are layed on top of the starting board during the course of play.




---Brett. 

"Protozoa are small, and bacteria are small, but viruses are smaller
than the both put together."

Re: [Rails-devel] Drawing the Map

[John D. G. <jd...@di...>]

Erik Vos wrote:
>> 1. They defined an XML DTD that defines the shape of the 
>> board in simple alpha-numeric coordinates:
>>
>>    label (
>>         A1|A2|A3|
>>        B1|B2|B3|B4|
>>       C1|C2|C3|C4|C5|
>>      D1|D2|D3|D4|D5|D6|
>>       E1|E2|E3|E4|E5|
>>        F1|F2|F3|F4    )  #REQUIRED

This is the definition of a Battleland, not the main board.  Colossus
_does_ support some variant versions of the main board, but I haven't
looked at that part of the code.

>> 2. An XML file, using the DTD, assigns the default terrain for the
>> map and then specifies which hexes deviate from this default:
>>
>> <battlemap terrain="Brush" tower="False">
>>     <battlehex x="0" y="2" terrain="Brambles" elevation="0">
>>     </battlehex>
>>     <battlehex x="1" y="3" terrain="Brambles" elevation="0">
>>     </battlehex>
>> </battlemap>

Not quite.  "Brush" is the name of that Battleland as a whole.  The
default terrain type for individual hexes is not specified, it is
always Plain.  (And tower=True|False must be specified because Tower
lands have their own rules about which side the attacker enters from,
and about how the defender sets up.)

> Please keep in mind that:
> a. Some games have hexes with the flat sides north and south,
> other games have the flat sides east and west.
> b. Some games have the letters left-to-right, others top-to-down.

There are also some games that use oddball schemes.  For instance,
1853 uses a capital letter for the row, and small letter(s) for the
column, and the columns after z continue with aa, ab, ac...

> c. a) and b) do not seem to correlate very well.
> So I think we will need two independent parameters controlling this.

I suggest a parameter spelling out how coordinate labels are
assigned in each direction, similar to the TYPE parameter of the
<OL> element in HTML.

> Not sure if we should distinguish Hex and Tile at all,
> given the fact that we have preprinted hexes etc.

In my own project, I included a designation of a preprinted tile as
one of the properties of every hex.  (This means that the preprinted
contents of every hex in the game have to be included in that game's
list of tile types, including BLANK; though if there aren't any tiles
that match the hex, its count in the inventory gets set to zero.)

The code to place a tile then has to check whether the hex already
has a tile (so you don't try to return a preprinted hex to the tile
supply); but it's a very simple addition to the code, and it allows
the Tile class to be made responsible for all track-connection logic.

Similarly, when a phase change causes a red hex (or a similar gray
hex in 18GA, etc.) to increase in value, you simply define another
"tile type" with the higher value and have the phase change event
cause the new tile to be automatically played.  (There is already at
least one game, 1837, where a phase change causes an automatic tile
lay.)

> Perhaps hex is just a location, like a stockmarket square,
> and a (usually level-0, i.e. lightgreen) Tile should have 
> the initial properties (one dit, one city, etc.).
> This is just a thought, not a firm opinion from my side!

I think we're on about the same wavelength.

RE: [Rails-devel] Drawing the Map

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

> 1. They defined an XML DTD that defines the shape of the 
> board in simple alpha-numeric coordinates:
> 
>     label (
>          A1|A2|A3|
>         B1|B2|B3|B4|
>        C1|C2|C3|C4|C5|
>       D1|D2|D3|D4|D5|D6|
>        E1|E2|E3|E4|E5|
>         F1|F2|F3|F4    )  #REQUIRED
> 
> The DTD also defines the types of terrains available to be 
> potentially assigned to each hex.

Please keep in mind that:
a. Some games have hexes with the flat sides north and south,
other games have the flat sides east and west.
b. Some games have the letters left-to-right, others top-to-down.
c. a) and b) do not seem to correlate very well.
So I think we will need two independent parameters controlling this.
See the recent discussions on hex numbering in the 18xx group!
We should adhere to the numbering of the game as published, or,
where the map has no numbers, with common PBEM practice.
 
> 2. An XML file, using the DTD, assigns the default terrain 
> for the map and then specifies which hexes deviate from this default:
> 
> <battlemap terrain="Brush" tower="False">
>     <battlehex x="0" y="2" terrain="Brambles" elevation="0">
>     </battlehex>
>     <battlehex x="1" y="3" terrain="Brambles" elevation="0">
>     </battlehex>
> </battlemap>

Something like that, yes.

> 3. The Hex object, along with child objects, serves to track 
> each indivdual hex's properties, including entrances and exits.
> 
> I think that for the purposes of developing a route 
> validator/calculator, we'll need to be able to track this 
> information for each tile layed.
> 
> For defining tiles, I think we'll need a Tile class that 
> extends from Hex, and stores information related to the 
> layout of the track.

Not sure if we should distinguish Hex and Tile at all,
given the fact that we have preprinted hexes etc.

Perhaps hex is just a location, like a stockmarket square,
and a (usually level-0, i.e. lightgreen) Tile should have 
the initial properties (one dit, one city, etc.).
This is just a thought, not a firm opinion from my side!

Another option is of course that only preprinted track 
is represented by an initial glued-to-the-board tile.

Erik.

[Rails-devel] Drawing the Map

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

I've been doing a lot of thinking about how to approach drawing the map board. I've also been crawling around the Colossus source code to get some ideas on how they tackled the problems that are very similar to our own.

Here's how they've done it, I think a similar approach may work for us as well:

1. They defined an XML DTD that defines the shape of the board in simple alpha-numeric coordinates:

    label (
         A1|A2|A3|
        B1|B2|B3|B4|
       C1|C2|C3|C4|C5|
      D1|D2|D3|D4|D5|D6|
       E1|E2|E3|E4|E5|
        F1|F2|F3|F4    )  #REQUIRED

The DTD also defines the types of terrains available to be potentially assigned to each hex.

2. An XML file, using the DTD, assigns the default terrain for the map and then specifies which hexes deviate from this default:

<battlemap terrain="Brush" tower="False">
    <battlehex x="0" y="2" terrain="Brambles" elevation="0">
    </battlehex>
    <battlehex x="1" y="3" terrain="Brambles" elevation="0">
    </battlehex>
</battlemap>


3. The Hex object, along with child objects, serves to track each indivdual hex's properties, including entrances and exits.

I think that for the purposes of developing a route validator/calculator, we'll need to be able to track this information for each tile layed.

For defining tiles, I think we'll need a Tile class that extends from Hex, and stores information related to the layout of the track.

Any comments on these initial points?


---Brett

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

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

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

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

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

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.

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

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

> > These classes allow marking allowed actions in the UI in detail.
> > For instance, to check if the current Player can buy a share
> > of a given company from the Pool you could call
> >     isCompanyBuyable (company, pool);
> 
> I've approached this slightly differently in the Swing UI.
> 
> There's only two buttons: Buy and Selling.
> 
> When you select a particular company and player, and press the Buy
> button, if the company isn't started yet, it buys the 
> president's share,
> if it is started, it buys the next available share from any pool.

OK, that is a sensible approach (and it answers my question in the other
mail).
You could then still call isCompanyStartable() and/or isCompanyBuyable()
afterwards to see what StockRound method to call (startCompany() or
buyShare()). Or use company.hasStarted() to check this, but then you have to
look
up company yourself. 

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).
 
> I'm planning on making this a bit more granular once I add 
> displays for
> each pool, but for now it keeps things simple and effective.
> 
> > This method does not yet include a check that the player has enough
> > money (this is checked, though, in buyShare), but I will
> > add such checks later.
> 
> I think conditions like these only need checking once. The tricky part
> is, where should the checking be?
> 
> Do we want to use exception throwing to pass errors deeper in 
> the class
> hierarchy up to the higher level classes for handling?

As I said, I'm doing this in StockRound.buyShare().

Currently, all XxxxRound action methods return true or false
indicating whether the action was valid or not (all checks included).
If false, an error message is stored in Log, you can retrieve it
with Log.getErrorBuffer() (the message is then cleared) and display it.

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

My current approach is to move most of the game logic to the
middle layer (i.e. the Rounds and GameManager), including all
validation, and that is only one level below the UI.

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

Erik.
 

Re: [Rails-devel] Operating Round

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

On Wed, 2005-05-04 at 18:16 +0200, Erik Vos wrote:
> 
> Other responsibilities of these middle-layer classes are:
> - all validation of player actions (though many invalid actions
> will be impossible if the UI is set up correctly - see below).

Correct.  I see this as a task for both layers.

The UI ought to block invalid input from the users, and the middle-layer
ought to attempt to disallow invalid input from the UI.

> - keeping track of who has the turn (I have not used the Turn class,
> I think we don't need it).

I agree. We probably don't need it if GameManager is handling this
function. Though, if used, it does provide another point of
extensibility. Not that we really need that, but it's an option.

> These classes allow marking allowed actions in the UI in detail.
> For instance, to check if the current Player can buy a share
> of a given company from the Pool you could call
>     isCompanyBuyable (company, pool);

I've approached this slightly differently in the Swing UI.

There's only two buttons: Buy and Selling.

When you select a particular company and player, and press the Buy
button, if the company isn't started yet, it buys the president's share,
if it is started, it buys the next available share from any pool.

I'm planning on making this a bit more granular once I add displays for
each pool, but for now it keeps things simple and effective.

> This method does not yet include a check that the player has enough
> money (this is checked, though, in buyShare), but I will
> add such checks later.

I think conditions like these only need checking once. The tricky part
is, where should the checking be?

Do we want to use exception throwing to pass errors deeper in the class
hierarchy up to the higher level classes for handling?

> 
> My suggestion would be to mark the background of clickable fields
> with a light colour (e.g. pale yellow), and those that are have been
> selected (or pre-selected: the player or company that has the turn)
> with a darker colour (e.g. green).
> 

I don't think the selection color really matters so long as the UI only
has a single item selected at any given time. 

Right now my Swing UI allows a single selection in each of the three
status boxes, which isn't good, but is easily correctable.

> I have not touched the XML in a while: there is a lot hardcoded now.
> This is high on my list to do, but I'll first try to complete the
> round/turn management, as this deeply affects the UI code that Brett is 
> currently working so hard on.

Sounds good to me.

I've pulled the hex code from Colossus and put it into ui/hexmap . The
main reason I like their hex code is because, just like us, they need to
handle what's on each side of each hex. Thankfully, for us it's just
entrances and exits rather than different types of terrain. But it's a
great starting point because much of the math and drawing is already
coded.

I'm working on getting more familiar with it so that I can work on
drawing the map while you're finishing up the turn/round logic.

Do we happen to have anyone on the list familiar with programming hex-
maps already?


---Brett. 

If it doesn't smell yet, it's pretty fresh. -- Dave Johnson, on dead
seagulls

[Rails-devel] RE: Bug: Starting a company at $100

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

After much single-stepping through the programming, I found the bug and fixed it.

Short form:

The money was being transferred in two separate places from two separate methods. 

I changed this to just do a single call into the Player.buyShare() method.

[Rails-devel] Operating Round

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

I have implemented OperatingRound to include most
of the actions that a player can do in that round.
Track and token cost and train buying is still a matter
of just moving cash from a company to the bank, though.
Also the revenue must be entered manually, but payout
and withholding work, as does buying private companies.

This class and StockRound intend to become the prime
interface for the UI to get the status and allowed actions,
and to execute the player's actions. Direct access to lower classes
will in most cases only be needed to get the display details
(cash, owned certificates, etc.).

Other responsibilities of these middle-layer classes are:
- all validation of player actions (though many invalid actions
will be impossible if the UI is set up correctly - see below).
- logging messages and errors (both retrievable for UI display 
from the Log class).
- keeping track of who has the turn (I have not used the Turn class,
I think we don't need it).

I have (of course) changed GameTestServlet to use these classes,
have a look there if you want examples of usage. Maybe I'll
publish some updated screenshots shortly.

Switching rounds is not implemented yet, this should currently
be done externally, simply by creating a new StockRound or 
OperatingRound object. Handling that will become the duty of
GameManager.

These classes allow marking allowed actions in the UI in detail.
For instance, to check if the current Player can buy a share
of a given company from the Pool you could call
    isCompanyBuyable (company, pool);
This method does not yet include a check that the player has enough
money (this is checked, though, in buyShare), but I will
add such checks later.

My suggestion would be to mark the background of clickable fields
with a light colour (e.g. pale yellow), and those that are have been
selected (or pre-selected: the player or company that has the turn)
with a darker colour (e.g. green).

I have not touched the XML in a while: there is a lot hardcoded now.
This is high on my list to do, but I'll first try to complete the
round/turn management, as this deeply affects the UI code that Brett is 
currently working so hard on.

Erik.

RE: [Rails-devel] Bug: Starting a company at $100

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

Brett,

I don't have this problem, but I have not synchronised the last few days.
I will do so when I am done with OperatingRound, and then try to debug
your problem (if it's not gone away by then).

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf Of 
> wak...@ea...
> Sent: 03 May 2005 22:06
> To: rai...@li...
> Subject: [Rails-devel] Bug: Starting a company at $100
> 
> It looks like we're doing a little extra subtraction when a 
> company starts its par value at 100$
> 
> The money transfer is correct for 90$ and 67$ (and by logical 
> induction, every value except 100$). However, for the 100$ 
> start price we're taking 300$ away from the player and giving 
> it to the company's treasury.
> 
> Can someone track down this bug?  I can't seem to locate it.
> 
> 
> ---Brett.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 
> great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>