+7 stone/hour

[GoogleCodeExporter]

The thread on LoU forums is closed, so I'm posting here.

original city:
http://www.lou-fcp.co.uk/map.php?map=L000000000A000A00C00B00C0A000A0000000B00C0A
A00000000000000C0000AA0CA0B000C00A0000BBB0BB0D0000D000000B0000000000CC0C0B00000B
000D0C000000000A00D0C000000AAD000CCC00000AAAA00000C0C000000000000BB00000BBD00000
B000A0000000000B0000000CC00000C0B0CC0000CC0A00D0C0BB0000000000000000B0BB00000000
00000000000

Run this city on rev 78 with default settings.  There is a quarry in the NW 
that is connected to 0 stone, 1 mason, 1 cottage.  Remove it, place it by the 3 
stones, and you get +7 stone per hour.  Granted, that is really small, but it 
suggests an optimization.  As a post process, sort all used production 
buildings by res/hour, sort all empty terrain by possible res/hour if a 
production building were placed here, swap while empty is greater than placed.  
It may be possible that this process would invalidate boosters and cottages, 
but I doubt it.

Original issue reported on code.google.com by Daniel.K...@gmail.com on 22 Dec 2011 at 12:49

[GoogleCodeExporter]

just a quick comment so people know i am alive and that someone reads this 
every so often: right now, the algorithm is purely greedy. there are various 
ways it could be made non-greedy, and the idea you mention would fall into that 
general category. since the basic optimization routine already works in the 
manner you describe, the only change needed to implement this would be to 
sometimes remove the lowest performing building according to some heuristic and 
then continue. if the removal was limited to once per N steps you wouldn't need 
to worry about cycles too much except at the end: if you wanted to keep ripping 
and re-placing the last building then you would of course need to detect a 
fixed point.

Original comment by moske...@gmail.com on 9 Feb 2012 at 4:51

• Added labels: Type-Enhancement
• Removed labels: Type-Defect