Feedback and Suggestions

I am excited about this.
Me too. However sadly at the current speed it will not be done in quite a while I keep getting higher priority stuff to do and I haven't written a single line yet :(

I've also learned that improving ones public infrastructure with roads and bridges has the added effect of increasing production in the private sector. So, by adding plot groups we can finally set it up so that cities can be connected by trade routes. I am thinking one benefit to being connected to a trade route is +Hammer so that a city receives two free production.
I'm not sure that is the best implementation, but I am in favor of bonuses for getting big. We can add bonus based on total population in a yieldgroup and stuff like that.

One interesting option is to limit production bonus based on people in the plotgroup. This could be done logarithmic just like culture expansion meaning you quickly gain some, but then you really need to glow to gain more. The formula needs to be modified though as gaining a new level at 10, 100, 1000 people is a bit.... you pretty much won if you gain 10k people in one plotgroup, production bonus or not. We could also set a production bonus cap based on this.

We just need to brainstorm on what we want it to do and ideas are welcome. We will worry about how to implement the ideas later which mean we ignore CPU usage and stuff like that for now. Just show up with whatever you can come up with.
 
Me too. However sadly at the current speed it will not be done in quite a while I keep getting higher priority stuff to do and I haven't written a single line yet :(


I'm not sure that is the best implementation, but I am in favor of bonuses for getting big. We can add bonus based on total population in a yieldgroup and stuff like that.

One interesting option is to limit production bonus based on people in the plotgroup. This could be done logarithmic just like culture expansion meaning you quickly gain some, but then you really need to glow to gain more. The formula needs to be modified though as gaining a new level at 10, 100, 1000 people is a bit.... you pretty much won if you gain 10k people in one plotgroup, production bonus or not. We could also set a production bonus cap based on this.

We just need to brainstorm on what we want it to do and ideas are welcome. We will worry about how to implement the ideas later which mean we ignore CPU usage and stuff like that for now. Just show up with whatever you can come up with.

Ok, sounds good. I'll be thinking on it. I'll have more time to dedicate to programming soon as this semester is over in Dec, so hang in there :)
 
One interesting option is to limit production bonus based on people in the plotgroup. This could be done logarithmic just like culture expansion meaning you quickly gain some, but then you really need to glow to gain more. The formula needs to be modified though as gaining a new level at 10, 100, 1000 people is a bit.... you pretty much won if you gain 10k people in one plotgroup, production bonus or not. We could also set a production bonus cap based on this.We just need to brainstorm on what we want it to do and ideas are welcome. We will worry about how to implement the ideas later which mean we ignore CPU usage and stuff like that for now. Just show up with whatever you can come up with.
In Civ4BtS cities get a named Culture Level based on logarithmic thresholds: below 10 Culture a city is called Poor, from 10-100 Developing, then Influential, then finally Legendary. If you get x Legendary cities you win a Culture Victory. I always thought it would be cool to get a slight bonus in your cities based on what culture level you managed to achieve.

Since Prosperity / YIELD_CULTURE will be generated by fulfilling demands of a larger population through local trade, that could become a good way to model how successful you are at developing a prosperous network of large populous cities that are planned well with most of their demands being fulfilled. Then you could get a slight local bonus for each level of Prosperity; becoming greater at higher levels which are logarithmically harder to achieve. Implementation-wise, this bonus could be made easily moddable by triggering creating of an invisible Building <bGraphicalOnly>0 that applies the desired effects to that city. :king: (effect-based "buildings" like these have been successfully used by many civ4 mods to represent local effects of spells or city races, etc). This would also have a side benefit of automatically allowing modders to create buildings or units that have certain local Prosperity levels as a prereq. Prosperity levels themselves could also generate demand, or yields like Crosses, Hammers, or Fealty, using the existing buildings xml.

It would also be cool if letting your prosperous city get captured or raided depletes much of the Prosperity that you've spent 50 turns accumulating, and the Prosperity would start to tick down if a city has lots of demands go unfulfilled. That would realistically model the benefits to ensuring long periods of uninterrupted protected prosperity and trade for your large core cities (a la Pax Romana) while you won't worry as much about border skirmishes in your less developed border towns on the periphery.

OTOH, there will already be quite a big built-in advantage to having large connected cities in that they will start generating income by fulfilling each other's demands. Also the quantity & efficiency of goods produced already grow very rapidly when combining large numbers of colonists & high level buildings, especially when adding bonuses from Rebel Sentiment / Fealty, so income will explode over time unless prices are continually adjusted downward with supply/demand forcing the player to seek out new goods. Adding too many more free bonuses on top of that could start to get overpowered & also disadvantage Archipelago maps or anyone who wants more than 1 contiguous colony. This could be easily balanced though if the bonuses work through XML buildings or civics system.
 
In Civ4BtS cities get a named Culture Level based on logarithmic thresholds: below 10 Culture a city is called Poor, from 10-100 Developing, then Influential, then finally Legendary.

Something like that exists in Civ4Col as well. :)
 
Since Prosperity / YIELD_CULTURE will be generated by fulfilling demands of a larger population through local trade, that could become a good way to model how successful you are at developing a prosperous network of large populous cities that are planned well with most of their demands being fulfilled.
If we pool city demands for all cities in a yieldgroup and then allow all cities to sell to that pool, then how do you know which city to increase prosperity for? I mean if we have 2 silver and 8 cities each demand a silver each, then which two will increase for selling the silver? Should it be the 9th city as that one, which has the silver stored?

If we look at prosperity (bonus?) as a function of domestic sales compared to demand, then we will decrease prosperity if we add a unit with high demands where we can only supply half of the demands. This mean you could get better prosperity for clearing speciality for units with high teach level (university level units).

This is what I mean by brainstorming for what we want. None of the ideas are bad as such, but when they start to work against each other it becomes bad.
 
If we pool city demands for all cities in a yieldgroup and then allow all cities to sell to that pool, then how do you know which city to increase prosperity for? I mean if we have 2 silver and 8 cities each demand a silver each, then which two will increase for selling the silver? Should it be the 9th city as that one, which has the silver stored?
Sorry for jumping into the discussion...

I would increase the demand "value" per turn. Let it start with a multiplier of m=1 with m increasing by +1 each turn. If the demand was completely satisfied, have m reset to 1, else (partial satisfication) reduce it by 1.
To avoid one city going through the roof, install a cap of m = 10 (just as an example).

For delivery, just look at the cities with the highest demand value. If there are more than one with the same demand value, just satisfy the first in the queue.

After some turns you will get some kind of auto-adjustment.

If we look at prosperity (bonus?) as a function of domestic sales compared to demand, then we will decrease prosperity if we add a unit with high demands where we can only supply half of the demands. This mean you could get better prosperity for clearing speciality for units with high teach level (university level units).
I would call this costs of opportunity. For the decreased prosperity you would have got a unit with high education...
 
I think Commander Bello's idea seems a fair one if I understand it right (is the concept to have a rotating queue of which city's demand is first in line?)

A simpler and likely faster way could be to use the proportion of plotgroup demand fulfilled, and apply it to cities in proportion to their local demand. Eg where the PlotGroup demanded 8 silver and sold 2:
Code:
plotgroupdemand=8
plotgroupsupply=2
proportionfulfilled=plotgroupsupply/plotgroupdemand
foreach city in plotgroup
     localprosperitychange = localcitydemand * (proportionfulfilled - 0.5)

This makes prosperity stable when around half (0.5) of demands are fulfilled, and grow or diminish at higher or lesser ratios. (The 0.5 base ratio may be something that could be adjustable as a game difficulty option). It also weights the effect size by how much demand that city generated. If one city generated all of that plotgroup's 8 demand for silver, it would get the full effect from whether its plotgroup met that demand. Cities that didn't demand silver would get no effect. This could mean Prosperity would be best stored as a float, but it could also be feasible to sum the total Prosperity change for that turn then round it to the nearest int.

If we look at prosperity (bonus?) as a function of domestic sales compared to demand, then we will decrease prosperity if we add a unit with high demands where we can only supply half of the demands. This mean you could get better prosperity for clearing speciality for units with high teach level (university level units).

True, but as CB points out it actually may be a good thing to have some form of consequence for being unable to fulfill demands. The most highly productive/advanced citizen types could have relatively higher expectations and desire some luxury goods not easily available on the frontier. If you're able to supply them, this demand represents an opportunity for additional profit from the sale, on top of the production advantage of the advanced citizen. The tradeoff is the demands are something the citizen actually expects to be met, and conditions become at least mildly suboptimal if they're not. If you prematurely recruited lots of discontented citizens you can't supply, you would be less prosperous than having founded large settlements consuming more ordinary goods which you are able to fulfill.

An alternative could be to let another system eg "Happiness" incorporate how well citizen demands are fulfilled, and use Prosperity for something else (total production and city size, or amount of building demands fulfilled?). But I think this probably crosses the line of adding an unnecessary amount of variables and increasing the complexity-to-fun ratio. Since there's already tracking of Fealty / Rebel Sentiment, probably best to avoid introducing too many more systems at this point.
 
Sorry for jumping into the discussion...
:trouble::trouble::trouble:

Spoiler :
:joke: It's ok for everybody to speak their mind. If I really wanted to care for who comes up with the concept rather than how it should be done, then I wouldn't have asked in the first place ;)


A simpler and likely faster way could be to use the proportion of plotgroup demand fulfilled and apply it to cities in proportion to their local demand. Eg where the PlotGroup demanded 8 silver and sold 2:
Code:
plotgroupdemand=8
plotgroupsupply=2
proportionfulfilled=plotgroupsupply/plotgroupdemand
foreach city in plotgroup
     localprosperitychange = localcitydemand * (proportionfulfilled - 0.5)
And how will a markedplace fit in this calculation? Remember that we have capped sales in each city and this is based on available buildings. Naturally we can change that, but removing already coded features shouldn't be done just because "oh I forgot about that".

While I find the ideas here interesting, only the last one gives any clue to how to deal with city based prosperity vs yields shared in a plotgroup.

I have been thinking about how to deal with that specific issue and I came up with this:

Don't handle domestic trade during CvCit::doTurn. Instead let all cities finish. After that a new function is called to deal with domestic trade.

We make a new class containing YieldType, Price and city pointer and then for each plotgroup we do the following:
  • Make a list/vector of the new class
  • Loop all cities and store the demands the list.
  • sort list based on price (biggest first)
  • go through the list and sell what the city demands of the yield in question. If the city lacks the yield, look though all cities in the plotgroup to take from storage somewhere else

This way we can get yields from all cities in a plotgroup while doing sales locally in each city and gain prosperity or whatever locally. At the same time if we are capped at selling 2 in a city (no marked building) and the demand is 3, then it will sell the two yields with the highest profit rather than the two with the lowest yield IDs like it will do right now.

One interesting part of this is that it can handle different prices in each city and sell where the profit is the highest.

However there is an issue where 5 cities each demand 0.2/turn. This will not result in a sale even though even though it adds up to a full yield demand. I haven't figured out a good way to deal with that. Maybe some building allowed fetching leftover demands from other cities. Kind of like how you buy normal stuff like food locally, but if you need something out of the ordinary like a computer, then you might have to travel for an hour or so to get the right one. I imagine it was the same in past days for people who could afford to send servants to pick up the goods. Such buildings might be limited to specific yields.

Another thing I have been wondering about is if we can somehow tell the quality of road between cities in a plotgroup. Stuff like is there a road all the way, is it paved and will the access use rivers for transport. This could be used to share fractions of demands into a whole demand. We could also use travel time between the cities and allow sharing for max 3 movement points or something. This limit could be set in xml and possibly invented to be better. However I fear looking into this becomes too complex, specially if we consider performance.

Actually we could use a simple plot distance. Each city caches which cities are within range and then whey check for sharing, city A checks if city B is in the list of cities in range and if they are in the same plotgroup. This cache will only need updating when a new city is build or we raze a city meaning it can be done without really hurting performance. If cities are aware of distance to each other we can also add other neighbor city effects to the game.
 
hmmmm, that sounds rather optimal actually :king::goodjob: especially as it allows for naturally adaptive demand-based city prices, and selling goods in areas with higher prices, exactly as the many independent traders acting in a real economy would do.

However there is an issue where 5 cities each demand 0.2/turn. This will not result in a sale even though even though it adds up to a full yield demand. I haven't figured out a good way to deal with that. Maybe some building allowed fetching leftover demands from other cities. Kind of like how you buy normal stuff like food locally, but if you need something out of the ordinary like a computer, then you might have to travel for an hour or so to get the right one. I imagine it was the same in past days for people who could afford to send servants to pick up the goods. Such buildings might be limited to specific yields.

Another thing I have been wondering about is if we can somehow tell the quality of road between cities in a plotgroup. Stuff like is there a road all the way, is it paved and will the access use rivers for transport. This could be used to share fractions of demands into a whole demand. We could also use travel time between the cities and allow sharing for max 3 movement points or something. This limit could be set in xml and possibly invented to be better. However I fear looking into this becomes too complex, specially if we consider performance.

Actually we could use a simple plot distance. Each city caches which cities are within range and then whey check for sharing, city A checks if city B is in the list of cities in range and if they are in the same plotgroup. This cache will only need updating when a new city is build or we raze a city meaning it can be done without really hurting performance. If cities are aware of distance to each other we can also add other neighbor city effects to the game.
If you can accomplish even what you set out before this section I'd say you're already in the running for the Nobel Prize in Civ4Col Economics :gp: Ability to deal with pooling of fractional demands would be nice to have, but may not even be mandatory since the proposed system would already be such an improvement. Using trade buildings or local plot distance sound like good solutions though if they're feasible to implement. As realistic as it would be to incorporate things like different Route types and actual travel time, I agree it seems not worth the added time and complexity to implement.
 
:blush:


Another thing I have been wondering about is if we can somehow tell the quality of road between cities in a plotgroup. Stuff like is there a road all the way, is it paved and will the access use rivers for transport. This could be used to share fractions of demands into a whole demand. We could also use travel time between the cities and allow sharing for max 3 movement points or something. This limit could be set in xml and possibly invented to be better. However I fear looking into this becomes too complex, specially if we consider performance.

Actually we could use a simple plot distance. Each city caches which cities are within range and then whey check for sharing, city A checks if city B is in the list of cities in range and if they are in the same plotgroup. This cache will only need updating when a new city is build or we raze a city meaning it can be done without really hurting performance. If cities are aware of distance to each other we can also add other neighbor city effects to the game.
Here I would think of using "travel time" instead of "distance". An improved road decreases the turns (=time) needed to get from A to B. "Range" then could be something within the limits of x turns.

Don't forget: if a unit A has a movement rate of 2, but the distance is 7, it will take 3 turns for unit A to travel. In fact, unit A is effectively as fast as unit B with a movement rate of 3. :eek: (Of course, in relation to that distance)

Now, if the number of turns needed for travelling is reduced by the "quality" of the roads, you have will have automatically put the quality into consideration.
 
I think we all agree that travel distance would be best to use when looking at gameplay. However plot distance is cheap on the CPU time while travel distance is fairly complicated. It has to take into account if you add/remove road, enemies blocking the road etc. You will have to do the same calculation as if you have a unit and then right click to see travel path. This is a lot slower and it is a question of how long we are prepared to wait for the next turn to be ready. Personally I don't think we should accept long waits for something like this. The gain from it isn't that great, at least not with the proposed feature using the distance. We would need an awesome feature to make it worth the time.
 
Just a question: In the founding fathers screen, are "art and science" produced by theaters, etc. Research? Courthouses? The manor? I'm not clear on what this means, but I'm sure not getting any at the start of the game.
 
I'm currently working on fixing a few bugs in feeder service in RaR (just one left) and I intend to copy the fixes to M:C once I'm done. While working on it I came up with a new idea.

Construction feeder service
I came up with the idea to have two thresholds. One is the current one, which remain unchanged. The other one is the one used by fully automated transports. The auto threshold is set to the same as the normal one with one exception. If the building currently under construction demands the yield in question and it demands more than the threshold, then the auto threshold is set to the building demand.

Example:
A city sets export and feeder for tools and the threshold to 0. No tools will be imported as the city has at least 0 tools (naturally). The city starts building a building, which needs 50 tools. The automated transports will then automatically supply the city with 50 tools and once those tools are used on the building, the demand will go back to 0.

In other words automated transports will automatically supply all cities which has feeder service enabled without supply the cities with too much because you forgot to reduce the threshold once the building is done.

AI building buildings
Next logical step is to make the AI use this. After all the AI use nothing but fully automated transports. If the AI enables feeder service for all yields needed by current building under construction, then the AI will be able to supply the construction sites with minimal code and without cheating.

Which yields to transport
Currently the fully automated transports picks the transport with the highest value (investigating details) meaning it's something like amount transported multiplied with price of each. It is optimized for selling the yields in Europe, but that is not precisely what we want it to do all the time. What we want is something like this:
  1. Supply buildings under construction
  2. Supply domestic industry
  3. Sell to home country (cities with import, but no local need for yield)
This mean some modifications to the traderoute value calculation will be needed. The current calculation is the vanilla one, which is the same as in RaR and I noticed that the wagon trains prefers to move 24 tobacco to the colony with the cigar factory rather than 8 stones to the colony having 92, but needs 100 for a building. Stones have such a low value that they are rarely moved around, which stalls construction if it relies on automated moves.

Plotgroup supplies
A long term plan would be to make the AI aware of produced, possible production, stored and demand yields in its own plotgroup. This can be used for some more advanced setups like a city starting to build a building without having the required yields as the AI is aware that they can be imported from other cities in the same plotgroup. Lack of a certain yield can in turn encourage production of that yield in whatever city able to produce it in the plotgroup. This is far into the future, but it will provide an AI city management, which can figure out fairly complex supply chains spread across several cities in a plotgroup and be well functioning without having to do something the human players can't do.

I still haven't looked into the stuff I mentioned earlier in this thread. I haven't forgotten it, but I ended up with other things to do first and I ended up spending the little coding time I do have on fixing bugs in RaR (mainly transport related ones, but also a few network related ones). Bugfixes for RaR takes priority right now as I would really like those bugfixes to be in the next release.
 
That sounds awesome. I think one of the main weaknesses of the vanilla AI was often getting stuck trying to construct things for which it didn't know how to get the requirements. The auto threshold could also incorporate the same thing for Units under construction which require yields for completion (eg ships/cannons).

If at the end of the turn yield consumption/production takes place before checking yields needed for building/unit completion; then it could use the predicted amount after yield consumption/production to check against the thresholds. Then I'd think that could automatically set a threshold that incorporates both construction requirements and domestic industry consumption (and incorporate whether needed Tools/Stone is already being produced in that city). If the AI makes use of completing production for gold when it gets stuck lacking only a handful of yield units; then it might not be necessary to create separately prioritized thresholds for building/unit completion yields and industry inputs, since it would already want to transport in situations where it was a large amount such as 50 or 100 items below the threshold to produce units/buildings. If you're only short 8 stones out of 100, it could make more sense to pay the amount needed to finish rather than soaking up an entire unit transport for 8 items. Alternately, maybe you could use your Yield Group mechanism like in M:C so yields used as Raw Material are weighted more heavily than their value when determining transport needs.
 
The auto threshold could also incorporate the same thing for Units under construction which require yields for completion (eg ships/cannons).
I think the code is for whatever is produced using hammers meaning we get buildings and units at the same time. If not, then we will deal with that later.

If at the end of the turn yield consumption/production takes place before checking yields needed for building/unit completion; then it could use the predicted amount after yield consumption/production to check against the thresholds. Then I'd think that could automatically set a threshold that incorporates both construction requirements and domestic industry consumption (and incorporate whether needed Tools/Stone is already being produced in that city).
That would be nice, but sadly it makes the code way more complex. Yield consumption/production is surprisingly hard for the AI to handle. Part of the issue is that it changes all the time and as such isn't cached and it would take forever if the AI takes those numbers into consideration when planning. This mean if we use those numbers, then the first step would be to make a proper cache for those. I would like the end result, but the process of designing and coding such a cache is better postponed until the core concept is working correctly.

If you're only short 8 stones out of 100, it could make more sense to pay the amount needed to finish rather than soaking up an entire unit transport for 8 items.
I did that when I noticed the problem. However the description of the solution is part of the problem as well. It was when I noticed the problem. I had set it to import 100 stone and only 92 arrived and being late game I had too many colonies to check such details all the time. If I order 100 to be transported the code should give me 100, not 92.

Alternately, maybe you could use your Yield Group mechanism like in M:C so yields used as Raw Material are weighted more heavily than their value when determining transport needs.
That would increase the value all the time. It would be better to check what the current construction needs as it will increase the value for currently needed yields only. Also the value is only increased for the cities, which needs them. Using a yieldgroup to tell which to move first can result in moving stone from A to B when C is the one, which really needs them.
 
I did that when I noticed the problem. However the description of the solution is part of the problem as well. It was when I noticed the problem. I had set it to import 100 stone and only 92 arrived and being late game I had too many colonies to check such details all the time. If I order 100 to be transported the code should give me 100, not 92.
Do you think the problem was that the AI saw the demand and chose to transport Stone, but only 92 items were available? In many cases filling up transport bays with lots of small sub-100 item loads will be suboptimal; maybe some code encouraging it to wait till a full load is available before loading a transport may help. OTOH the full load may never become available and it would be stuck waiting. A fully comprehensive solution would likely require fairly sophisticated planning as you mention in the Plotgroup Supplies section; but for the time being, as long as it can complete with gold as a safety valve when smaller amounts are missing the current system will be a huge improvement on vanilla. (BTW interestingly I think what you mentioned is similar to the way goods are sourced based on the demand for them in certain "lean manufacturing" systems.)
 
I am liking the ideas of the Construction feeder service. I know the vanilla AI does a horrible job at moving resources around to complete construction. I think I may have even enabled them to cheat at it. I know I have asked this before but could you give me a quick synopsis of what exactly the feeder service does as I can't remember or find a definition.
 
Feeder service is the 3rd option in city import/export screen and it is a bool you turn on and off.

Whenever the amount of stored yields changes or the user edit import/export and feeder service is on:
-If stored yields are more than or equal to threshold, then imports are turned off.
- If stored yields are less than 75% of threshold, then import is turned on.

This mean if 3 cities wants to import 6 units each turn, then the transport code is perfectly happy with delivering all 18 to the same city each turn. Using feeder service it detects if this is the case and turns off imports to give the other cities a chance to import. This (by concept) relatively simple change makes it a lot easier to distribute more evenly between multiple cities.
 
Top Bottom