From: Erik V. <eri...@hc...> - 2005-12-13 21:14:20
|
> 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. |