 |
|  |
 |
|
MrBaggins
|
|
Sure. In the midst of working, I've been jotting down a few notes. Trade and gold rebalancing has been a part of that.
Heres the concept I've been thinking of so far.
In the trade db a couple fields are added (and the name of one field changed for consistancy)
GoldValue
ShieldValue
FoodValue
This forms the basis for the value of a good. A city with a good in its radius, which isn't trading it, adds these values to its gross food, shields and (gross) gold.
Thats basically a GoodMod effect, but would be implemented in the game.
If the good is sent internally in the civ, to another city, then these values get multiplied by a trade coefficient.
The trade coefficient is...
code:
sqrt({distance in tiles *100}/{travel distance (in 100's)}) * sqrt({distance in tiles *100}/{max empire size})
with a minimum value of 1.
then is multiplied by {internaltradecoef}
internaltradecoef would be a new coefficient in govern.txt, just for the purpose of calculating (internal)
trade values per government.
I.E. Say a city is sending a good to a city 40 tiles away,
fully railroaded (and railroads had a move value of .2),
the maxempiredistance for its government was 2000,
and the internaltradecoef was 1.25
That would calculate as sqrt(800/4000) * sqrt
(4000/2000), which calculates to a multiplier of 3.16,
which would then be mulplied by the internaltradecoef
of 1.25, for a final coef of 3.95.
Thus the value of the the good would be multiplied by
3.95 for the purposes of this internal trade... of course,
caravans would still need to be built, etc.)
The receiving city gains 3/4's of each of the trade's net values (food, shields and gold), rounded down. The remainder is kept by the sending city.
Thus you can implement food and shield caravans... included in the trade system.
---
If the trade is international, that is, between different civs, the system is almost the same, with a few slight differences...
The first is that a different government trade coefficient is used... foreigntradecoef
The second is that the sending city (I.E. you) gets 3/4's of the trade's net values, and the destination city (I.E. them) gets 1/4. Thus trade is mutually beneficial, but still overwhelmingly biased to the good owner.
Lastly, and most importantly, 'gold' is treated as commerce rather than just gold, for both parties.
---
Regarding gold rebalancing
Gold will never be important without a use. Currently its not very useful; its main use is construction through rushing, which can be achieved as about as well in other ways, and in diplomacy which is pretty marginal at best. City improvement maintainance is negligable.
Other ways gold could be used (should in my view)
- Introduce unit updating (ala Updater2, but integrated)
- Proportional City Improvement costs (so upkeeps should include optionally upkeep_gold_per_pop)
- Introduce TI upkeep costs
Last edited by MrBaggins on 22-01-2004 at 20:11
|
|
|  |
 |
|
MrBaggins
|
|
Sounds good... although maybe a goodbonuscoef would achieve about the same thing?
In retrospect, I think that having as much flexibility in being able to alter values is the best policy.
In terms of implementing separate terrain bonuses and trade bonuses, how would that work in practice?
|
|
|  |
 |
|
MrBaggins
|
|
Incidentally... I don't really see much point making this new trade system optional: its an extension to the existing trade system, and can largely simulate the existing system. Perhaps the only optional thing might be whether gold should be treated as commerce for just international trade, all trade, or no trade.
|
|
|  |
 |
|
MrBaggins
|
|
What I was referring to, was the actual calculations involved:
I mean that I've dealt with the 3 situations... untraded goods, internally traded goods and externally traded goods, with the relative value that each situation gives the host and destination city.
If you include a separate set of values for untraded goods, is it still in effect when you also trade that good? and how does that effect the values of the trading?
|
|
|  |
 |
|
MrBaggins
|
|
Yep... a little bit complicated... here's a solution:
Four structures in the goods.txt
BaseGoodBonus
{
GoldBonus
FoodBonus
ShieldBonus
HappyBonus
}
TradedGoodBonus
{
TradedGoldBonus
TradedFoodBonus
TradedShieldBonus
TradedHappyBonus
}
SentGoodCoef #each sent and received pair should equal 1
{
SentGoldCoef
SentFoodCoef
SentShieldCoef
SentHappyCoef
}
ReceivedGoodCoef #each sent and received pair should equal 1
{
RecdGoldCoef
RecdFoodCoef
RecdShieldCoef
RecdHappyCoef
}
So... the good if untraded has one value and another if traded (modified by the coef I mentioned in my first post,) and the proportions of the sent and received values can be altered... so food can be 'sold' for gold, or all the 'values' equally shared, should we wish.
This allows us to implement luxuries too...
|
|
|  |
 |
|
MrBaggins
|
|
A slight extention to the system too... renegotiation.
Another tab is displayed, showing preexisting foreign trade routes. You are allowed to "buy-out" a route by paying double what its worth to both parties. It still requires a number of caravans to form, too. The trade is revalued, given the new situation.
Your reputation with the previous "buyer" is hurt... slightly. Your reputation with the sender is possibly hurt or enhanced.
|
|
|  |
 |
|
tyrantpimp
|
|
But oil is used in lots of things its not just a fuel source.
|
|
|  |
 |
|
tyrantpimp
|
|
Slave trading sounds too complicated what about if Public works points could be traded in diplomacy? That might be usefull.
My thought is that if there is slave trading from civ to civ you would have to have some nice fat penalties and such to make it balanced.
Also one thing that earks me the most about the trade system is that the routes never take the best route to a city. They allways stay in shallow water if they can even if theres a shorter distance over deep water. This becomes problematic because they AI doesnt really ahve to work too hard to pirate routes. Since all routes end up jumbled together in the shallow water. This is my experience anyway anybody else notice this?
Last edited by tyrantpimp on 24-01-2004 at 21:55
|
|
|  |
 |
|
tyrantpimp
|
|
Trade takes the long way around no matter what, i have the whole map explored and the routes stay the same. This is after breaking them and making new ones. Routes favor the shallow water for some reason.
|
|
|  |
 |
|
Fromafar
|
|
At first I thought tyrantpimp was playing the wrong version of the game. For all I knew, CTP2 always had straight-to-the-goal trade routes. I remember CTP1 having
routes that followed roads, and me wondering why this silly AI that was creating trade routes right through my cities when at war with me.
After some testing, I realised he was correct after all. When crossing water, strange bends may appear in the routes for CTP2. Time to find out how it really works, and delve into the pathfinding. 
The A* pathfinding is based on 2 values for each tile.
The first value is the real cost it took you to get to a tile from the city that is going to send a trade good (start). This is 0 at the start, and goes up until you reach the city you want to send the good to (goal).
The second value is an estimate of what it will cost to get to the goal from a tile. This starts at some value in the start, and goes down or up, depending on whether you move towards or away from the goal.
Now, you basically begin at the start, and expand it by determining the real and estimated costs for each of its neighbour tiles. After this, you select the unexpanded tile with the lowest sum of real and estimated costs, expand it, and repeat the process until you reach the goal.
First observation: unlike for the army movement paths, the real costs for the trade routes do not depend on the terrain, nor on its improvements. The only thing that matters is the direction. For N, S, E, and W "movements", the real costs are 5. For NW, NE, SE, and SW "movements", the real costs are 4.75. So, the trade routes prefer a straight NW + NW (cost 9.5) over a bended N + W (cost 10) path.
Second observation: the estimated costs do depend on the terrain movement costs, which are recomputed every barbarian turn. For the actual values, see the Movement values in terrain.txt and the MoveCost values in tileimp.txt. Typical values are 100 (plains, grassland, all water tiles),
50 (rivers, cities), and 33 (roads).
Third observation: for the trade route computation, the value of a tile does not only depend on the movement cost of the tile itself, but also on its surroundings. Have a look at .
The bottom part of this picture shows a block of 8 tiles with XY coordinates, starting at the top left of the map. You may ignore the top part of the picture. It is showing the same block with RC coordinates. I was just too lazy to remove it.
The map is divided into a repeating pattern of blocks of this shape, and all tiles of a block share the same value, being the smallest of the movement costs of the 8 tiles. So, if you have only water tiles in a block, the value is 100. It will also be 100 when e.g. 7 of the 8 tiles are mountains (movement 400) and only 1 of the tiles is water. Note also that after completing a road on any of the mountains, all tiles of the block would get value 33.
Fourth observation: it gets even worse. After having assigned each block a value, the actual estimated cost is not value of the block, but the smallest value of a group of (up to) 9 blocks, consisting of the block itself and its directly neighbouring blocks. So, completing a road at tile (7,7) may set the value of tile (0,0) to 33, even when all tiles in the block of 0,0 are unroaded mountains or water.
This explains why water tiles far from the coast stay at value 100 for a long time (until you start building underwater tunnels), while tiles near to the coast will get lower values earlier in the game (when you construct cities and roads).
Fifth observation: unexplored tiles will never be used in a trade route path, but will be taken into account in the value computations. So, the AI is not the only one to cheat. 
Last observation: the estimated cost for a tile is simply the product of the remaining tile distance to the goal and the value of the tile. Tiles with value 100 will just not get selected for expansion, unless there really is no other option to get to the goal. With a real value of 5, a city or river somewhere on the coast would already enable a detour of at least 10 tiles.
It really is a pity that the original code comments have been removed. It would be interesting to see whether it has been designed in this way deliberately. And the real cost code of CTP1 has been lost as well.
|
|
|  |
 |
|
MrBaggins
|
|
Yup, first thought is that. Water tile effective move cost (for trade calculations) should be changed by certain naval techs, rather than being fixed.
|
|
|  |
 |
|
MrBaggins
|
|
Uh? Could you explain that again, Martin?
|
|
|  |
 |
|
MrBaggins
|
|
I still don't see how why it would follow the shallow water tiles, if they cost the same as un-roaded, un-rivered plains/grassland. I.E. 100
Surely the land route is better either way... although it might take a slightly different route on the river, if the maglev isn't there.
|
|
|  |
 |
|  |
All times are GMT. The time now is 05:33. Apolyton Time is 00:33. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|