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.