rails-devel

RE: [Rails-devel] More Token Code

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

I think we ought to define this company-by-company to account for the varying number of tokens each company gets.  Also, this would be a good place to note reserving a token for destination runs (1870).

How about this:

<Company name="PRR" ...>
<Tokens costMethod="fixed" cost="0,40,100,100,D"/>
</Company>

What do you think is better, using a D or a -1 to denote the last token is reserved for destination runs?

I would rather use a term like "fixed" rather than "1830" for parameters like costMethod because it'll make things a lot more difficult in the future if we have to keep referencing the game name for a particular style of game mechanic.

Though, now that you mention other scenarios, I think we'll need to think about this...

1835 we clearly won't be able to fully implement until we're able to do route calculation and improve our knowledge about the map.

The fixed rate tokens (18EU) should be some of the easiest to cope with.

Variable token price at floating time (1841) also doesn't strike me as particularly difficult, though definitely a special-case.  Perhaps extending our above model to allow for something like this:

<Tokens costMethod="variable" cost="0,40,%,%,D"/>

For now I'm rather thankful that 1830, 1856, and 1870 are so similar. ;-)


If you want to add token laying to ORWindow, go ahead and do that as soon as you are able. It doesn't have to correctly calculate the cost just yet, but if you can get the buttons in the UI working to add a token to the station, I can then start working on adding the coordinate offsets for when tiles contain multiple tokens.

Also, we're going to need to display the number of remaining tokens somewhere. Perhaps in StatusWindow?

---Brett.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Dec 13, 2005 11:59 AM
To: rai...@li...
Subject: RE: [Rails-devel] More Token Code

> I've committed more token drawing code. 
> 
> Now, drawing a single token in a normal and an OO tile is 
> reasonably correct.
> 
> 
> Next, I'll need to get ORWindow to handle the manual token 
> placement.   Any thoughts on how we're going to handle 
> processing the costs of laying each token?  Do we need to add 
> token costs to the XML data we load?

Yes, that must somehow be done. There are a lot of different ways 
in which token costs are calculated in the various games, 
and I don't know if we can create a generic structure for that.
For instance, in 1835 the cost is 20DM per hex distance from
the home base, "as the crow flies", with the proviso that the
crow has no passport (i.e. may not cross the German border
- there is one potential token lay on the board where this proviso
makes a difference).
In other games, tokens are bought at a fixed (18EU) or variable
(1841) price at floating time, after which token laying is free.
I think we will need game-specific classes in some cases,
but we could take the 1830 method as the default.

I don't think we need a TokenManager. 
Perhaps add a line to CompanyManager.xml like
<Tokens costMethod="1830" cost="0,40,100"/>
This might change, though, once we start looking at other games.

I suppose the token laying code in ORWindow and MapWindow 
would be similar to the tile laying code.
If you want I can pick it up, or extend it to OperatingRound 
from where you leave it.

Erik.

RE: [Rails-devel] More Token Code

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

The cost isn't really much of an algorithm, so I think it makes sense to just explicitly define the fixed costs.

This allows us to even partially encode some of the real cost algorithms out in the XML if we want to approach it from that direction when we look at implementing other games in the future.

Though, at this point the driving idea is to leave things flexible enough to make implementing more games a reasonable task for the future. While I don't want to solve all the problems today, I don't want to paint ourselves into a corner if we can easily avoid it.

---Brett.

-----Original Message-----
From: "John A. Tamplin" <ja...@ja...>
Sent: Dec 13, 2005 1:41 PM
To: rai...@li...
Subject: RE: [Rails-devel] More Token Code

On Tue, 13 Dec 2005, Erik Vos wrote:

> Only the number of tokens varies by company, not the cost or
> the cost algorithm. I would define the costing only once.

No, in some games the cost for various tokens change.  For example, in
1850 the edge tokens are $50 rather than $100, and cannot be the sole
station on a route.  In 1846 the fourth token for the B&O and PRR (and
maybe CO, I don't remember off-hand) costs $100 if used normally or used
as a teleport token to its reserved slot, but a different amount (varies 
for the company) if it is placed there when they have connectivity.  
Several games have destination tokens that may be placed at the normal 
cost or placed for free if associated with a destination run (which may 
take place outside the normal OR sequence as a special run or may be one 
of the normal runs).
  
> You may choose the number of tokens you buy, with a maximum.

And a minimum -- minors must have at least one and majors must have at 
least two.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

RE: [Rails-devel] More Token Code

[John A. T. <ja...@ja...>]

On Tue, 13 Dec 2005, Brett Lentz wrote:

> What do you think is better, using a D or a -1 to denote the last token
> is reserved for destination runs?

I think you are going to wind up needing something more complicated, as
there are many different types of special tokens for companies.  For
example, you have east/west edge tokens in 1850, in 1846 you have tokens
which have one price when placed normally or a different place when placed 
to special reserved locations while you have connectivity to them (the 
regular price if you use them as teleport tokens), etc.
 
> I would rather use a term like "fixed" rather than "1830" for parameters
> like costMethod because it'll make things a lot more difficult in the
> future if we have to keep referencing the game name for a particular
> style of game mechanic.

I agree with the idea, although I think more thought is required in the 
implementation.
 
> 1835 we clearly won't be able to fully implement until we're able to do
> route calculation and improve our knowledge about the map.
> 
> The fixed rate tokens (18EU) should be some of the easiest to cope with.
> 
> Variable token price at floating time (1841) also doesn't strike me as
> particularly difficult, though definitely a special-case.  Perhaps
> extending our above model to allow for something like this:

No, in 1841 the cost per token is dependent on how near track is to your 
starting locations.  Then you purchase all of them up front (1-4 for 
minors, 2-5 for majors) at that cost each -- later placement is free.
 
> <Tokens costMethod="variable" cost="0,40,%,%,D"/>

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

RE: [Rails-devel] More Token Code

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

> > Variable token price at floating time (1841) also doesn't 
> strike me as
> > particularly difficult, though definitely a special-case.  Perhaps
> > extending our above model to allow for something like this:
> 
> No, in 1841 the cost per token is dependent on how near track 
> is to your 
> starting locations.  Then you purchase all of them up front (1-4 for 
> minors, 

1-2 actually. Extra tokens may be bought when minors upgrade or merge.

>  2-5 for majors) at that cost each -- later placement is free.

Erik.  

RE: [Rails-devel] More Token Code

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

> I think we ought to define this company-by-company to account 
> for the varying number of tokens each company gets.  Also, 
> this would be a good place to note reserving a token for 
> destination runs (1870).
> 
> How about this:
> 
> <Company name="PRR" ...>
> <Tokens costMethod="fixed" cost="0,40,100,100,D"/>
> </Company>

Only the number of tokens varies by company, not the cost or
the cost algorithm. I would define the costing only once.
 
> What do you think is better, using a D or a -1 to denote the 
> last token is reserved for destination runs?

To me that is a different kind of token, which I would define
in a separate tag.
 
> I would rather use a term like "fixed" rather than "1830" for 
> parameters like costMethod because it'll make things a lot 
> more difficult in the future if we have to keep referencing 
> the game name for a particular style of game mechanic.
> 
> Though, now that you mention other scenarios, I think we'll 
> need to think about this...
> 
> 1835 we clearly won't be able to fully implement until we're 
> able to do route calculation and improve our knowledge about the map.

I know the map, but the game has its own complexities indeed.
 
> The fixed rate tokens (18EU) should be some of the easiest to 
> cope with.
> 
> Variable token price at floating time (1841) also doesn't 
> strike me as particularly difficult, though definitely a 
> special-case.  

The cost determination is difficult, at least for companies
that start later in the game. 
For these companies you can choose your own start city, 
but the tokens get more expensive when you start closer to
existing track: 200, 100, 50 or 25 lira per token depending
on whether you start on, or 1, 2 or 3 hexes away from any tile.
You may choose the number of tokens you buy, with a maximum.

> Perhaps extending our above model to allow for 
> something like this:
 
> <Tokens costMethod="variable" cost="0,40,%,%,D"/>
> 
> For now I'm rather thankful that 1830, 1856, and 1870 are so 
> similar. ;-)

> If you want to add token laying to ORWindow, go ahead and do 
> that as soon as you are able. It doesn't have to correctly 
> calculate the cost just yet, but if you can get the buttons 
> in the UI working to add a token to the station, I can then 
> start working on adding the coordinate offsets for when tiles 
> contain multiple tokens.
> 
> Also, we're going to need to display the number of remaining 
> tokens somewhere. Perhaps in StatusWindow?

Yes, and also in ORWindow. I will add some space.

For later we must make these windows more flexible.
Lots of games do not have par prices, so that column
should then be removed. In other games companies may own shares
(in 1841 -again- even of other companies!)

OK, I had planned to start with this task one of these days,
so why not so it first thing, now that I have the screen update
issue off my mind (although it is not finished yet, but there is
no hurry with that).

Erik.

RE: [Rails-devel] More Token Code

[John A. T. <ja...@ja...>]

On Tue, 13 Dec 2005, Erik Vos wrote:

> Only the number of tokens varies by company, not the cost or
> the cost algorithm. I would define the costing only once.

No, in some games the cost for various tokens change.  For example, in
1850 the edge tokens are $50 rather than $100, and cannot be the sole
station on a route.  In 1846 the fourth token for the B&O and PRR (and
maybe CO, I don't remember off-hand) costs $100 if used normally or used
as a teleport token to its reserved slot, but a different amount (varies 
for the company) if it is placed there when they have connectivity.  
Several games have destination tokens that may be placed at the normal 
cost or placed for free if associated with a destination run (which may 
take place outside the normal OR sequence as a special run or may be one 
of the normal runs).
  
> You may choose the number of tokens you buy, with a maximum.

And a minimum -- minors must have at least one and majors must have at 
least two.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723