RE: [Rails-devel] Suggested object model for core generic framework

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

>>
>>- Tokens are sometimes not bound to a location but
>>to one of two (or even three) cities on one tile.
>>I think we need "City" as a separate object type
>>(also for revenue calculation).
>>Also remember that the values of two cities on one tile
>>are not always equal, see 1841 Venice.
>>Cities can merge, be upgraded, or even disappear (1856).
>
>A good point, and one I want to think about further. I'm not sure that 
>having a City class adds any value beyond associating Token directly with 
>Tile, as it is the Tile that dictates the number, size and revenue of the 
>cities, towns, etc. Neither does a City class solve the problem of
>avoiding 
>all relationship migrations during an upgrade (disappearing cities sound 
>like a downgrade!), though maybe that is unavoidable... I will think 
>further.
>


Do you think we'll need a City class for helping calculate routes?



>This is both good news AND bad news. Good news, because there is a lot of 
>literature on graph theory and traversal algorithms. Bad news, because
>most 
>graph traversal algorithms are non-polynomial and fall into the class of 
>mathematical problems known as NP hard. This means, that the runtime of
>the 
>algorithm is exponentially sensitive to the number of stations that the 
>train can visit.


I suspect this is probably how it was done in the 1830 PC game. A good=
 indicator is that, even though this is a DOS-based game, it still takes=
 quite a bit of time calculating the AI's turns on newer processors.


>Single train solutions are probably not too bad to calculate as the graphs=
 
>involved won't be too large. I'm more concerned about multiple train 
>solutions, because a strategy of optimizing each train in turn may not
>lead 
>to the optimal combined solution. What I mean is, that in a hypothetical 
>situation, the best total revenue for a two train company may be 90 - made=
 
>up of one train running for 50 and another train running for 40. However,
>it 
>may be the case that the optimal single train solution has a revenue of
>60, 
>but that only leaves a maximum revenue of 20 for the second train giving a=
 
>sub-optimum total revenue of 80. In other words, the maximum combined 
>revenue requires the highest revenue earning train to take a route that is=
 
>less than its individual maximum potential.


It's probably best to leave this problem for later and for now, simply=
 assure that we build in the components needed to work on it when we get to=
 it.