The Medieval Economy

Kailric · Sep 15, 2013

I am converting this first post to detail all the changes about the Economy in M:C

-sell 25 units per worker, Wily sells 50.
-connected trade posts increase it by 25
-Each connected foreign city without a trade post should increase by 5
-Each connected domestic city should increase by 5.
-Each connected domestic city with a 'market' building should increase by 10/15/25.

Current Screen Shots

Original Post:

Spoiler :

Nightinggale said:
I looked though the source code for that one and it appears surprisingly simple to implement. However I started thinking if it's good enough.

First of all I want to link it to the marked on/off sales. I would also argue that at least a simple marked should be available from the start as income is really tricky in the beginning.

I also came up with the idea that citizens can use yields. Not just the units, but the city counts the number of units working in buildings and the number working in plots. It will then create an extra demand based on those. This shouldn't be linear with the number of units. Instead it should encourage building huge cities, which intentionally clashes with max population restrictions.

Some amount of randomness. The modcomp adds all demands for yield X, then it divides it with 100 and the actual demand is there. I would like it to subtract 0-50% randomly in order to make the domestic marked more unpredictable.

Store leftover points. If a demand is 20, then it would demand one of those yields every 5th turn (or every 5-10 turns with random demand). If you don't sell on the turn where the demand is, then tough luck. It's gone.

Some amount of randomness in units. Say a UnitType is set to demand 50 of 4 different yields, but have a max demand of 100. Whenever a new unit is created of that type, 100 points is distributed randomly between those 4. It should take the amount for each into account as it should be more likely to demand more of a yield, if it's set to 100 than the 3 set to 50. This mean two units of the same type might demand noteworthy differently from each other. You can then have good and bad units based on what you produce on your land.... now which one do you want to make a scout and which one do you want to stay in the city?

I think this would be the most ideal solution as it would provide the ability to have a fair amount of domestic trade while at the same time it's unpredictable enough and it will not be the same in two games even if you do the very same thing twice.

orlanth said:
Yeah, I agree the consumption should be able to be turned on/off by the Market mechanism, and it works well to have it act like a regular use of yields as you said earlier rather than a totally separate system like in the original modcomp. The <AutoSellsYield> used by buildings like Market could be repurposed to mean that the building enables local consumption of that yield (which can be set on/off after having that building). The basic town buildings in M:C could allow trading in some basic goods, while fancier ones like Wine need a Tavern, etc. I'm not sure what the MODER_CODE_TRADING_POST currently does in addition to that though.

I guess it would be good to add some element of randomness to demand, but it could eventually get a bit fiddly for players to cope with tracking idiosyncratic demand values that remain fixed and different for many dozens of individual units. (Also, in the timeframe of Civ4Col mods the units don't represent a specific individual person with unique preferences that stay fixed forever, rather a group or class of local people many of whom continuously die and are born etc during the course of a game). But like you suggested, in addition to the base demand from units/buildings there could be some random fluctuations in local demand across time, like there are in any market. That plus the existing randomness in what emigrants you get and what yields are obtainable in local terrains should make things play interestingly different in each game.
(edit: it might eventually be interesting to add some random Events using the xml Event system that could add extra demand temporarily to a city due to a temporary shortage or disaster. i.e. "Shortage of Barley in Paris! Demand +5 for 10 turns.")

What do you guys think re this earlier proposal to let local prices vary somewhat based on supply/demand balance? It would probably take quite some doing to have local prices, but letting prices respond gradually to supply/demand imbalances could make the interplay of supply/demand and trade opportunities a lot more interesting.
I've been thinking about a mechanism for allowing supply and demand to realistically shape local prices, while allowing plenty of flexibility to balance these features however is desired using just XML. Here are the ideas I've come up with, let me know what you think!

Where iBuyPrice is the current buying price in that city, and the already existing variables below come from CIV4YieldInfos.xml:
iBuyPriceLow : minimum buying price of that yield
iBuyPriceHigh : maximum buying price of that yield
iPriceChangeThreshold : price sensitivity of that yield (how many units you'd need to sell to drive the price down to iBuyPriceLow, or how many units you'd need to buy to drive the price up to iBuyPriceHigh)
iSellPriceDifference : difference between buying and selling prices (may work best to convert this to a percentage rather than a fixed integer?)

Whenever a yield is bought from a city during trade, call the following function, thus raising the local price by a degree proportional to the amount bought, never exceeding iBuyPriceHigh.
iBuyPrice = min(iBuyPriceHigh, (iBuyPrice+(iBuyPriceHigh - iBuyPrice)*(iUnitsBought/iPriceChangeThreshold)))
At the end of the turn, add up the Demand from local units/buildings (based on Androrc's mod), and call the above function using this demand as iUnitsBought; thus generating upward support for prices based on local demand.

Whenever a yield is sold to a city during trade (or sold via its Market/Tradingpost building at the end of the turn), call the following function, thus lowering the local price by a degree proportional to the amount sold, never less than iBuyPriceLow.
iBuyPrice = max(iBuyPriceLow, (iBuyPrice-(iBuyPrice - iBuyPriceLow)*(iUnitsSold/iPriceChangeThreshold)))

iSellPrice can be updated after each transaction as follows:
if using iSellPriceDifference as a percentage margin: iSellPrice = iBuyPrice*(1+iSellPriceDifference)
if using iSellPriceDifference as an absolute margin: iSellPrice = iBuyPrice+iSellPriceDifference

The basic effects should be that local prices drift down slightly if you're earning lots of gold from selling a certain yield to a city via trade or Trading Post/Market; and drift up slightly as the city generates demand for that yield (especially if that demand goes unfulfilled by selling). The price sensitivity and min/max price for each good can be set as desired. Special markets like Spice Route could get their own set of modifiers to adjust min/max price of certain goods for their unique situation, and cities with high Prosperity can get a bonus to the Demand they generate, building higher prices and profits there. Overall it would be a cool way to generate realistic and subtle shifts in local markets in response to supply/demand, so you can benefit by satisfying your citizens' demand through good strategy, without having to micromanage to an artificially precise limit like "demands exactly 3 Cigars per turn".
The main issue I'd see with this (or any other system for price change) is that in vanilla, the smallest possible price change of 1 gold ends up being extremely large in percentage terms for many goods with low price per unit (less than 5 or so, where the smallest possible movement is 20%). And if a given transaction isn't big enough to move the price by at least 1 unit, its effects won't be stored unless we make some special remainder variable to store it. The easiest fix for both of these would probably be to "inflate" overall price levels by a set amount so small/gradual price adjustments become possible. The vanilla system seems pretty crude with a large random component, so almost anything would be an improvement..

Nightinggale said:
Maybe it would be best to start simple. First step would be to add demands for buildings, get it working and then commit. After that add demands from units, commit and then we will figure out what to do from there. A great plan for a goal is useless unless you know how to get there. Just adding demands for buildings without any randomness or anything to it appears to be strait forward. Units shouldn't be too hard either.

I will postpone the whole pricing scheme until later as well. No use for price on something you can't sell anyway.

orlanth said:
Ok, sounds good BTW once Buildings can generate demand, I think it should already become possible to implement moddable XML Events boosting local demand temporarily without need for DLL changes. (XML Events could create an invisible "Building" with that demand effect, which could be destroyed after x turns.)

Kailric · Sep 15, 2013

Here is an idea I had on this. After a city builds a market and starts to be able to sell goods at market we could introduce a new Resource Bar above the current one where the player could place goods for sale at the local market. The local market wouldn't bring as much gold as selling goods along trade routes but it would satisfy a cities desired goods and increase fealty and happiness. This would keep the market system separate from the production system so you would not have to worry about modding it.

Each time a player unlocks a good he can sell it gets added to the list of Marketable goods.

Nightinggale · Sep 15, 2013

I'm not sure making a brand new system for domestic sales in cities is the way to go. Sounds like too much work compared to what we gain from it. Our greatest shortcoming is programming time meaning we should plan what to do with the little we do have. Each time we spend an hour on one feature, it's an hour not spend on another one. We should be better at figuring out "what is good enough?" rather than "what is the ideal solution?".

I plan to go on with the plan to just get units and buildings have a demand and for now not really care what to use it for. Well I plan to hook it into the yield consumption as mentioned earlier. It would be best if the AI could figure out how to use it. In fact we need far less special rules for AI.

Kailric · Sep 15, 2013

Well, once we get a new working model to play with then we can test things to see how we like it, so by all means, continue with your plan

Nightinggale · Sep 18, 2013

While looking for a good place to hook in demands I read though CvCity::calculateNetYields() and.... :eek:

For starters when it calculates yields consumed using an odd approach. It's a loop, which goes through all units to figure out which yields their profession consumes. That is ok, but it does it inside a loop, which goes through all units. Yeah, nested loops. It would appear that the outer loop is unneeded. This appears to be a vanilla issue and I suspect it's a relic of some pre-release code, possibly debug code. From what I gather if we set 3 farmers to work in a city and nobody else, then it will check 9 units as each farmer is checked 3 times. As this is n*n checks, it becomes 25 for 5 farmers etc. However it can break the outer loop in certain conditions meaning a 20 pop city might only check 20 times, not 400. I'm not entirely sure about the specifics about this and it should need further investigation.

There is some code for heavy armor. Why would heavy armor needs special code? Why isn't it using the general code like say weapons do?

A general lack of comments makes it hard to figure out what goes on as multiple tasks appears to be blended into each other. It might be a good idea to do more than one thing in the loop for performance reasons, but we should make it human readable too.

I think this function needs some cleaning, but for now it works and I don't feel like touching it.

How to continue coding
I came up with the idea to copy the custom house code from RaR. It comes with on/off for each yield and threshold. Implement this and cap sales at domestic demand and we have the user setup we were looking for. The AI might not like this, but with a little modification to how it handles raw materials I think we can get around that issue. It would then only be able to sell raw materials domestically meaning everything it sells should be raw materials. Minor setup issue.

I also wondered about the issue that money is too hard to earn in the beginning. I came up with the idea that the type of market place shouldn't tell which yields to be sold. Instead all yields are tradeable at any place, but there is a cap on how many you can trade each turn and the marketplace increase this cap. The higher the level the higher the cap. With no marketplace at all the cap should be fairly low, like 2 or something. Not much, but it means a great deal compared to not being able to sell at all. 2/turn for each city accumulates to something, enough to at least keep some workers at work.

New export price idea
I had another idea regarding trading. When you buy/sell in "Europe" the game remembers how much you traded and use it to generate new prices. This mean if you export the same over and over the price of that will drop and not raise again even if you stop exporting it for a while (vanilla issue). If we duplicate the counter and have one for total traded amount for statistics and stuff and another for price calculation we can modify the latter as we want. If we do "* X / 100" each turn where X is written in XML, then we can set it to say 95 or something and the traded amount will decrease 5% each turn, meaning Europe will forget you traded a huge quantity after a certain cooldown period and once again be able to raise the price. Likewise if you go into war and buy 1000 weapons and none after that it shouldn't affect prices too much after 100+ turns.

Kailric · Sep 18, 2013

Calculatenetyields is heavily modified for sure. The multi goods produced modified it and I modified that even further. The heavy armor is there because it is a check to see what armor is being produced at your armories. Remember you can change what armor you want your smiths to make so I added code to check for this. It should be rewrote and made modded friendly perhaps so that any building could be modded in the XML to produce different types of yields bases on user selection. Or maybe there is a better solution to this? The AI atm always chooses the best armor to build.

The other changes you percent all sound great to me.

Nightinggale · Sep 18, 2013

Kailric said:
Calculatenetyields is heavily modified for sure. The multi goods produced modified it and I modified that even further. The heavy armor is there because it is a check to see what armor is being produced at your armories. Remember you can change what armor you want your smiths to make so I added code to check for this. It should be rewrote and made modded friendly perhaps so that any building could be modded in the XML to produce different types of yields bases on user selection. Or maybe there is a better solution to this? The AI atm always chooses the best armor to build.

I think it should be redesigned to have one yield produced for each profession. The armorsmith should then be an expert in multiple professions and the building should house multiple professions. This design change is likely the most modder friendly we can come up with as it gives options for non-armor professions as well.

orlanth · Sep 18, 2013

Yeah, having multiple professions per building should make that possible easily without needing a special system. That way, you could also make some of the advanced armor professions discoverable via techs if you want (which could come after gaining access to the yields themselves). Early on you'd have to import Plate Armor from abroad to equip Knights, but after advancing could eventually become able to produce it domestically.

The other changes sound good to me as well. Re the price levels for Europe screens, one thing to keep in mind is that Europe prices trending constantly downward forces you to seek out sources of new unexploited Yields (and gradually build domestic consumption for independence in the case of M:C) But it would be nice to have at least some recovery. One option might be to eventually let Europe screens use the same demand system as cities, raising/lowering prices if their demand is persistently under/over-fulfilled. The vanilla price system seems quite arbitrary and discontinous with big semi-random lurches from time to time, so I'll be glad to be rid of it!

Nightinggale · Sep 22, 2013

I finally finished selling on the domestic market using code from domestic market and custom house from RaR and Androrc's domestic market modcomp mixed together with my own modifications. This turned out to be a lot harder than I expected. It looks fairly simple, but it ended up being fairly complex.

Still missing:
demands from units
restrictions on total sales from a city. Right now it sells 200 if the building demands is high enough.

I also wonder if it would be a good idea to add the production bonus to demands. This could be yet another reason for producing bells.

I'm also not really happy with the way local prices are calculated. They seem less random than I wanted and they appear to be fairly static. This part of the code might be completely redesigned at some point.

I plan on adding a yield group of imported goods. The minimum sale price of those should be 25% higher than the buy price in "Europe", with a minimum of +1.

I'm wondering if it could be doable to make a list of domestically sellable yields, sort of like a cache for "player can sell these". Right now it lists a whole lot of yields, which will never be sold domestically. It even lists uninvented ones.

Another thing. I didn't care much for the text strings at this point. They are copy pasted from RaR and as such some of them makes little sense in this context. They should be rewritten once the whole feature is complete.

Nightinggale · Sep 23, 2013

I added yield demands to units. That was more or less copy paste. The only thing, which prevented this from being a 5 minute job is that I made a cache rather than recalculating the demand each time it's needed. Most of the time I used on this was spent analyzing the code to figure out where to hook in to update the cache. It turned out that to work efficiently the cache needs to be able to add/remove a single unit at a time as well as make complete rebuilds. I think I got it to update correctly, but we will not know for sure until units have demands and we play real games with this. Just to be safe I added an assert check for the cache at the end of doTurn(). This check might be disabled in the future as it is a bit slow, but for now it catches cache bugs if they are present.

It turns out that the design to split the cache into two caches for buildings and units was a good choice. Now it can clear and rebuild the building cache without touching the unit cache and vice versa. Adding the two caches when using them is not a major slowdown, specially not when considering how much easier it is to manage the cache this way

While this feature still needs some polishing I say it's playable. It can read yield demands from XML, display them in the city screen and sell on next turn event. It also looks into the custom house settings to honor threshold and "won't sell" settings. By default all thresholds are 0 and it will sell anything. The AI will not change this setting and as such it will sell domestically if possible. It will however not move yields between cities to fill demands as none of the AI code looks at the demands (yet?). We should likely consider if it is wise to make demands for tools, food etc as this might cause unwanted AI sideeffects.

orlanth · Sep 23, 2013

Awesome

Having real Demand getting generated will make production and trading lots more interesting, especially when your higher-grade citizens start wanting to consume a variety of imported yields from the unique Trade Screens as well as the Europe screen. :king:

I agree it's best to avoid having building/unit demands for those yields that are frequently used in construction or for other reasons; I did this in 2071 (using Androrc's DM modcomp) to let some buildings consume Biopolymers then immediately regretted it. Adding something like the Sentiment/Fealty production bonus to demands sounds good too; however it might be even more suitable to instead add a % bonus to demands for cities with high Prosperity.

Nightinggale · Sep 24, 2013

I added iMarketCap to buildings and NO_MARKED_SALES_CAP to GlobalDefinesALT.xml.
A city will now no longer sell more yields than NO_MARKED_SALES_CAP + (iMarketCap for each building present).
I set NO_MARKED_SALES_CAP to 2 for now. Set it to 20000 or something if you don't like having a cap at all.

I also noticed that the price setting code (which is bad, I know) can set the price of a yield to 0. I added a check to make sure it will only sell if it actually gains a profit from it. Before this fix it would remove the yield, but since the profit was 0, the later trading code assumed no sale and didn't post a message about the sale. The result was that the yields disappeared without the player getting money or message about it. Now that there is a cap on how much you can sell it would be even worse as the code could sell worthless yields instead of high priced ones. It still can, but at least it will not give anything away for free anymore.

Yields are sold in the order they are indexed (bottom row left to right). It's perfectly happy using all of the cap to sell for 2 gold/yield and having used up the cap when it reaches 15 gold/yield goods. There is no easy way to avoid this in the code, though the custom house settings can be used to prevent selling low cost yields. A fix for this means a complete redesign as the selling code is only aware of one yield at the time and have to assume no other yields will be sold.

Using prosperity instead of fealty sounds like a better idea. I made a single line in the code where stuff like this should be added. However I haven't figured out how much it should influence demands or how it should be calculated. I guess we will find out eventually.

I noticed RaR has +50% demand for each level of market. We could have that as well if we like. Well it would be "this building adds X%". Docks might increase demand as well as marketplaces as it simulates natural local trade that docks brings with it.

Also I wonder about how to add population to the calculation. I wrote earlier that I want to gain a "big city bonus" to give added motivation to increase city population limit. I haven't figured out that should work though.

Nightinggale · Oct 9, 2013

This topic appeared in the Colonization 2071 thread and I decided to move it here instead. As you might have noticed, Colonization 2071 adopted M:C's DLL code and anything affecting one affects the other.

Nightinggale said:
I'm still wondering how to set up AI traderoutes. Export to Europe appears to be ok. The issue is the yields consumed locally.
Right now for each non-sold yieldtype it loops all cities to find the best target for imports. The best one is the one where a single unit can produce the most yields with the selected yield as input. It doesn't consider how many units can have that profession and it doesn't look like rebel production bonus is applied either. If more than one city is the best in this case, then it picks the one with the highest population. If more than one has the highest population of those, then it picks the one the civ gained first (time from founding or conquering). All cities then export that yield to that single city.

I'm thinking of setting export and feeder on all yields (except special ones like YIELD_FOOD). It will then turn import on and off automatically according to how much is stored and threshold. The threshold should then be:

Yield needed by building being constructed

Yield consumed by units in city * X (possibly potential consuming)

Yields sold domestically * X

Now the question is what X should be in each line and how well it would work. It would likely be a good idea to keep some "best city" code to prefer blacksmith's shop over blacksmith's house.

From what I can tell this would scale to many cities much better than the vanilla code. For instance right now if the best city is on planet A, then all cities on planet B will end up stockpiling that yield. With this modification both planets will have domestic transports and domestic consumption.

Also it allows more yields to be transported with fewer special rules. Lumber can easily be moved to cities without forest even without special rules. I don't think it's even transported right now. This would make non-forest cities much better for the AI.

Certain yields should be stored even without a need. Food should be maintained at 50% of growth threshold to allow cities, which survives on imported food, tools should always be at least 50 to allow pioneers etc.

Ideas are welcome on how this should work. Right now I'm investigating what the AI should do. Figuring out how to code it and get proper performance is postponed until I have a clear goal of what it should do.

At some point I will also have to look at how the AI picks professions in a city. Cities should start producing more of yields needed by other cities to make a better overall production/consume for all cities combined.

orlanth said:
The details of how the AI tries to plan transport and production have always been pretty unclear to me; though it was obvious the vanilla AI behavior was far from optimal and had been attempted to be improved in RaR. Particularly when there are a large number of individual Yields, and there can be local demand in multiple cities for small amounts of several yield types, the sheer number of individual transports and trips that needs to be made can get excessive even if individual trips can be automated. Since even small amounts of a yield type take up a full cargo bay, the vanilla unit-based transports are not set up to cope with moving small amounts of many yield types locally. So because of this it's worth considering some ability to have local demands not always require physical transport of everything using units, eg my National Domestic Market thread here or Kailric's posts about enabling some sharing of yields locally using plotgroups here

As far as "normal" transport using units, there's still definitely a role for it using the export and feeder system for larger scale intercontinental/interplanetary journeys. I'm thinking you could probably use your existing Yield Groups feature to let the AI use a relatively small number of standard behaviors. YieldGroup_AI_Raw_Material (including Stone, Lumber, and maybe Tools and Weapons/Munitions could use the same system) could first transport yields needed by buildings/units under construction, and then try to keep a "buffer" of x=50 stored in each city if there is overall excess of that yield. For Food/Nutrients (including Luxury Food in M:C) I'd think it would only transport if there was another city running at a deficit which couldn't produce locally; otherwise just leave the yield to stack up locally for population growth.

I have been thinking about using plotgroups and at first I didn't like it as the needed data wouldn't be available when needed and it could end up taking a while recalculating it every time. However I came up with a new idea.

Each player should have a list of plotgroups. Each item in that list should be a list of its own of pointers to the cities in the plotgroup in question (or maybe it's enough if each city has an int to tell which plotgroup it's in). In CvPlayer::doTurn() it should no longer loop cities, it should loop plotgroups. At the start of each plotgroup it calculates a an array of the combined demands for all cities in the plotgroup. This way each city can access demands in other cities in the same plotgroup without spending ages locating the other cities. Some restructuring would be needed as stuff like prices would be moved to plotgroups instead of individual cities. If we use floats when calculating the combined demands for a plotgroup, then we will be able to sell a yield even in the case where 5 cities each demand 0.2. I have already been considering moving to floats due to rounding and multiple units.

Plotgroups can also be used for AI traderoutes. The best city can be set for each plotgroup mean a plotgroup on an island will not stop producing say tools because a city on another island is better at producing tools. This way it will view each island (plotgroup) as a selfcontained "civ" when moving yields around to supply its industry.

Moving food wasn't really my plan. My plan was to set threshold to 50% of growth threshold and export for all cities. If a city produce negative food, it sets feeder service on to make other cities fill it up until it reaches 100. When no cities import, then the others will export, but has nowhere to export, which is the same as not exporting. This clears the way for AI mining colonies with minor food around it and it needs to import say 6 food/turn to feed the population.

Luxury food is currently moved from cities not producing it to cities producing it. It could be beneficial to select one city in each plotgroup to stockpile it instead of spreading it out like that. Raw materials to luxury food is distributed randomly to cities able to produce luxury food. It could benefit from using the best city code to find the best production facility instead of just using a random one. Even worse it might send sheep to one city and cattle to another. The best city code should be able to prevent that from happening.

What is left is to figure out how to deal with traderoutes to supply construction of buildings and stuff like that.

orlanth · Oct 9, 2013

That sounds good and should save processing time and AI confusion as well as tons of hassle for human players. No one wants to play a game that becomes focused on coordinating dozens of local routes for LTL freight forwarding. (oh wait, apparently some people do.) Well to each his own :king:

For buildings and constructed units that require yields for completion; when construction is underway maybe it could use feeder service to import/stockpile that yield to a threshold of the amount required. For Professions that require a yield, the need or demand for that yield won't become apparent until the AI tries to adopt that Profession and fails. To solve this it could also be reasonable to let the AI draw upon yields from its local Plotgroup to equip a profession. (Maybe it could even do this with Units/Buildings at higher difficulty levels; I'm pretty sure that could increase effectiveness of AI gameplay tremendously). Alternately it could be set to always stockpile those yields in all cities up to the required amount, but that likely seems a bit excessive and suboptimal.

IIRC one other important "safety valve" to allow blocked building/unit construction to proceed is to pay gold to complete it. I had thought this was possible through gameinfo/CIV4HurryInfo.xml but it looks like that relates to rushing Hammers and immigrants.

Nightinggale · Oct 9, 2013

orlanth said:
For buildings and constructed units that require yields for completion; when construction is underway maybe it could use feeder service to import/stockpile that yield to a threshold of the amount required.

That's the plan. However now I came up with another idea. Each player can set if human players should have this feature as well. If enabled a city will automatically import whatever yield is needed for the current building if the city lacks it. This will reduce micromanagement regarding spreading tools and stone to cities needing them just once. I wonder if that can go bad somehow.

orlanth said:
IIRC one other important "safety valve" to allow blocked building/unit construction to proceed is to pay gold to complete it. I had thought this was possible through gameinfo/CIV4HurryInfo.xml but it looks like that relates to rushing Hammers and immigrants.

Oh I forgot about that (even though I use it once in a while). I need to look into how it works and it certainly is possible that the AI could use this.

orlanth said:
For Professions that require a yield, the need or demand for that yield won't become apparent until the AI tries to adopt that Profession and fails.

The current transport code works based on how much a profession will produce when using the yield in question as input. It will not actually have to have anybody working in that profession and as such that approach avoids the problem you just mentioned. On the other hand it doesn't look at how many are actually working in that profession and it doesn't look at how many slots are available for that profession, at least not yet.

orlanth said:
To solve this it could also be reasonable to let the AI draw upon yields from its local Plotgroup to equip a profession. (Maybe it could even do this with Units/Buildings at higher difficulty levels; I'm pretty sure that could increase effectiveness of AI gameplay tremendously).

Sounds like a bad idea to me. I don't like the concept of the AI cheating like this (it's an awesome cheat. You can't interrupt their transports). Likewise it spoils a lot if the human players can do something like that.

orlanth said:
Alternately it could be set to always stockpile those yields in all cities up to the required amount, but that likely seems a bit excessive and suboptimal.

That was actually the plan. I just improved on the plan. Right now the game picks the best suited city, which scales really poorly. Imagine producing 50 ore and the best city only takes 18 as input. That scenario demands spreading the ore to several cities to fully exploit the ore.

The solution is to look at all cities and locate the best building for processing the yield in question. Then all cities with that building will import the yield. However cities with enough in the warehouse are skipped. This way blacksmith building lv 2 will take everything (assuming there is only one). Once the input buffer there is filled, there will no longer be a building lv 2 in the consideration and all level 1 buildings will start importing. Once the level 2 building has used enough ore to start importing, all level 1 will stop importing and the cycle repeats. If no building exist to take it (all input full or none has even been built), then it will consider the ore to be a final product and sell the surplus to Europe.

I think that will likely be the best approach. It scales well (or at least a lot better than vanilla) to big empires by allowing production in multiple cities while at the same time try to reduce the number of units used to get the production going as the best buildings have a higher priority when getting raw materials.

orlanth · Oct 9, 2013

Originally Posted by orlanth View Post
For Professions that require a yield, the need or demand for that yield won't become apparent until the AI tries to adopt that Profession and fails. To solve this it could also be reasonable to let the AI draw upon yields from its local Plotgroup to equip a profession.

The current transport code works based on how much a profession will produce when using the yield in question as input. It will not actually have to have anybody working in that profession and as such that approach avoids the problem you just mentioned. On the other hand it doesn't look at how many are actually working in that profession and it doesn't look at how many slots are available for that profession, at least not yet.

Ok, but I wasn't referring to yields consumed by production professions, but the yields that are required in order to equip a profession (ie <YieldEquipedNums>). Most of the vanilla and M:C map professions are like this, and some require more than one yield simultaneously (probably rare to have lying around in AI cities, which must make some complicated M:C military profs hard for it to equip). Unlike Buildings/Units construction requirements where import feeder can be set as soon as construction is underway; the AI won't be able to plan to transport yields in advance of needing to use them as equipment. Some possible ways to address equipment blockage would be A) be able to use surplus yield from the local Plotgroup when equipping professions, B) be able to spend Gold to "hurry" profession equipment that's missing locally, or C) set the AI to always stockpile the equippable minimum (50 units) of all equipment types in all cities as a contingency in case it needs to equip professions locally.

Nightinggale · Oct 10, 2013

I was thinking of solution C. However I don't want to hardcode 50 units because then you can't make a super unit using 100. Alternatively the AI stockpiles 100, but that would be overkill if it only needs to store 20. I came up with this:

Make a cache in each player with an int for each yield and set it to 0 (YieldArray<int> will do that automatically).
Loop through all professions. For all allowed professions, if yield requirements is higher than already in the array, then set the value in the array to the required number.

Once this loop is done, we will have a list of minimum requirements in the AI cities. This is even dynamic and will change as the player gain access to more inventions/founding fathers. It wouldn't be a logical solution to stockpile for uninvented professions.

The drawback is that this could place 15 horses in all cities. I would like a priority list of cities for this, but I haven't figured out how to do that yet. Maybe sort the cities according to population and assume that big cities are more likely to produce those professions.

Kailric · Dec 6, 2013

I am currently testing out the new Building/Unit Demand feature to see how it plays and how it works. I have one question though, why is the getYieldDemand in CvCity.h divided by 100 as in its code...

return (getBuildingYieldDemand(eYield) + getUnitYieldDemand(eYield)) / 100;

I removed the "100" so I don't have to set the values into the hundreds. I tested things out and all seems to be working well in my first assessment.

Edit: Ah, I see where you stated that the factors are divided by 100, but I am not sure why.

I plan on testing out the Economy aspects of the game and make adjustments and improvements. I added a new feature to the Manor building in that in increases the output of the center plot by 2. This value can be modded in the XML under the new Building attribute "iCenterPlotBonus".

In Medieval terms the Center Plot would be considered the "demesne" or private domain of the Lordship. All other plots around would be considered tenants and the workers are paying rent to the Manor Lord in the form up goods harvested/gathered. The tenants or serfs are required to work on the Manor Lord's private property several hours per week and so we can consider that's how those goods are acquired.

When we start to add in the new Civics screen we may can modify how the relationship between the Manor Lord and his tenants work as there were several ways this operated in medieval times.

orlanth · Dec 8, 2013

I will look forward to having a Civics screen available! :king:

Do you think it'll be possible to bring back the Tech Categories of the original modcomp? It would be cool to have categories such as Religious, Military, and Economic techs for which certain FFs could give a discount to research costs in that field.

Kailric · Dec 8, 2013

orlanth said:
I will look forward to having a Civics screen available! Do you think it'll be possible to bring back the Tech Categories of the original modcomp? It would be cool to have categories such as Religious, Military, and Economic techs for which certain FFs could give a discount to research costs in that field.

I had to download and install the Inventor mod again to check out how Categories work as its been a while since I have played that mod. I see no reason why they can not be added back and I am not sure how much they function already but the discount to research sounds like a cool idea.

I have come upon an idea I would like to work on first before I do a Civics screen and that is an overhaul of the Fealty/Bell production system. I want Fealty to be an individual aspect of the game and each unit having its own Fealty attribute. As of now Fealty/Rebel Sentiment is the same as vanilla in that it adds up to be a percentage of the total population and when you add a new unit to a city it automatically lowers the Fealty. I never liked that even in vanilla.

The new system will give a Fealty attribute to each unit as mentioned. Fealty will then be raised or lowered depending on different factors.

Factors that can Raise Fealty:

A unit who is working at his chosen profession
Certain Civics and Techs
Having access to "Demanded" goods
Prosperity of town
Extra Food Fed to population(3 food instead of two)
Buildings
Symmetry of Other units (Master Vintner/Expert Vintager)
Founding Fathers

Factors that Lower Fealty:

A unit that is unemployed
A unit that is not working at his chosen profession
War (some units will not like war)
Certain Civics and Techs
Starvation
Taxes
No Access to preferred buildings(Monks with no Monastery)
Corruption

Benefits of High Fealty:

Production Bonuses
Combat Bonuses

Fealty of your Units will range from 100% to -100%. At -100% a unit may even leave your Realm for another Realm. Fealty for starting your Conquests will be an average of all your Units Fealty. Certain units could have a starting bonus to Fealty or penalty.

Corruption is also an idea I have. It was a huge part of Manorial life in that the further away from the Lord's Manor you were the more corruption that took place (much like the concept in the older Civilization games). Corruption could be added as a new Yield that is countered by Fealty production in your Town Centers. Like Fealty has a positive effect, Corruption has a negative effect and it increases over time if there are no units producing Fealty. Certain Civics/Techs/FFs will also raise or lower Corruption. Criminals in your Realm could automatically add to Corruption impressing a need to get them converted or shipped off to prison:suicide:

I feel like these two systems will add greatly to the strategic depth of the Mod while working well with the new Civics Screen and not adding too much complexity. Any thoughts?

The Medieval Economy

Jack of All Trades

Jack of All Trades

Deity

Jack of All Trades

Deity

Jack of All Trades

Deity

Storm God. Yarr!

Deity

Deity

Storm God. Yarr!

Deity

Deity

Storm God. Yarr!

Deity

Storm God. Yarr!

Deity

Jack of All Trades

Storm God. Yarr!

Jack of All Trades

Similar threads