New Civics Screen

cool, sounds like a truly sci-fi advance :scan::goodjob: I thought things with MEDIEVAL_TRADE_TECH aren't actually a Tech at all; ie it's not produced by the Inventor system or Idea points but is effectively just a different type of Founding Father points that shows up in another location.:confused:
 
cool, sounds like a truly sci-fi advance :scan::goodjob: I thought things with MEDIEVAL_TRADE_TECH aren't actually a Tech at all; ie it's not produced by the Inventor system or Idea points but is effectively just a different type of Founding Father points that shows up in another location.:confused:

Call them what you will, but they are however generated from the same system as Inventions. They are like a "Category" of Techs, but I had to add specific code for them in order for the new Invention Category Trait Bonus to work. They are a combination of Founding Father code and Invention Code :D and in so are unique and no new "Trade Tech" Categories can be added with ease. However, as many Categories as you want can be added to Inventions as per the mentioned setup rules.

I have added code to my current work that adds a new xml type: Civ4GlobalCivicEffectInfos. I have never added new XML files so I am experimenting with it. I have it planned that this is where you will add new Invention Categories as well as a place for Censures, Trade Techs, Anarchy Effects, etc. And so the Invention Categories and such can be removed from the CivicInfos.xml and it will only house the actually Effects, not Categories.
 
I ran into a problem in CvPlayer.cpp. There is a variable called m_paeCivics. It is an array of CivicTypes, but it has length of GC.getNumCivicOptionInfos() :confused:
It is also used when a similar array isn't passed in arguments at one point, meaning this isn't a strait forward conversion to JIT array like most others. I will postpone converting this one.

The same goes for m_ppiImprovementYieldChange and m_ppiBuildingYieldChange as those two are improvement/building arrays of yield arrays. You can't make a JIT array of a JIT array meaning some clever thinking is needed here.

While this touches civics, it is vanilla code.

EDIT: I think m_paeCivics is the civic settings meaning it tells which civic the player has for each category. This mean the conversion should take place on both index and content of each element in the array... hmm not standard JIT array behaviour either :think:
 
EDIT: I think m_paeCivics is the civic settings meaning it tells which civic the player has for each category. This mean the conversion should take place on both index and content of each element in the array... hmm not standard JIT array behaviour either :think:

Right, that's exactly what it does.
 
Civic Branch Push:

I tweaked the XML and added to the dll:

  • -Warehouses Expansions no longer sell OverFlow, this is now setup for Trading Posts/Markets/and Guild Halls at 50%, 65%, and 75% respectively.
  • -I have removed Yield Demands from buildings and set them up in Units instead. This is how R&R did it so I am testing things out with this setup. I keep feeling that fulfilling unit Demands should do more than just give gold as selling goods on Overflow gives gold as well.
  • -I added the help text code from R&R so that the Demanded Yields only appear on one or two lines at the most
  • -Civs now start with a Nobleman
  • -Serfs are Allowed by Wheelbarrow tech, which also allows Serfdom. Serfs do not Immigrate but can be purchased through the Immigration and Trade Screens. They gain a +1 bonus to field labor, -1 to City labor, and will eat one less food under Serfdom Civic.
  • -The City Billboard Population number will be Red if the City has reached it's max population. This number is always black for the player so this was a cool visual change that doesn't effect anything else, but greatly helps the player determine where he needs to improve his infrastructure.
  • -Added Player Unitclass Count help text when looking at Summoning Units. This will help you remember which Unitclass you still need in your Realm. This number will also appear in the Pedia if you are in an Active game.
  • -Fixed some Failed Asserts, bugs, and just plain wrong code :)
 
could the fulfilling of demands generate gold, fealty, culture in one or more various mixes?

The more fulfilled a group is generally the more loyal they will be. A society that can provide it's citizens with all kinds of wonderous goods, would also be more 'famous' too, thus controlling and influencing a wider sphere.
 
Yeah it would be cool to let relative level of Demand-fulfillment give you a unique benefit such as affecting the city Prosperity counter, to provide a special indicator that shows how well you're doing at keeping citizens' Demands fulfilled (or conversely how horrible you're doing at keeping them impoverished and unfulfilled :lol:). There are already so many combined things that all add to and result from Fealty score that we should be hesitant about combining even further effects all into this one value, or it will all become kind of a big indistinguishable Gemisch. :crazyeye::assimilate:

I've dredged up some of Kailrics & my discussions re Economy/Demands/Prosperity below. (I had also made a long post somewhere laying out some potential algorithms to let supply and demand have a gradual influence on local prices, but now I can't seem to find them anywhere among these tangled threads:crazyeye:)

Originally Posted by Kailric
Someone may have mentioned an idea similar to this but I have been thinking on it lately and it sounds intriguing...

The idea is of a Living Economy, one based on actual supply and demand. Each trade screen would have a limited supply of trade goods it can sell, as well a demand for goods. The demand will lower the more a good is introduced to the market. Each turn a certain amount of these goods are consumed by the trade screen. Prices in a trade screen would thus be determined by actual supply and demand.

In the player settlements we could use the new plotgroups system to determine the Demand of goods, thus all goods would have a certain amount of demand in each plot group. This demand coupled with the available supply will effect prices. All player dealings with the Trade Screens and Local deals will effect as well.
Yeah I support the idea that prices gradually adapt to relative demand/supply rather than semi-random jerky global adjustments like in vanilla. I had worked out a possible balanced system for price adjustments in a prior post but can no longer find it lol. Is it feasible for price adjustment to happen at the level of cities or plotgroups? This could also be interesting for non-city tradescreens; but like nightingale said earlier it could be interesting for them to be somewhat different than the more strongly adapting supply/demand of cities/plotgroups. Ie a "safety valve" for somewhere to trade with when your cities arent generating enough demand; while your long-term goal is to gradually build up your domestic economy to the point where it can produce/consume a lot locally & self sufficiently.

..
..


Since there are two main city-wide "scale"-type variables Prosperity and Fealty, important things to consider are:
- each one needs to measure a separate and distinct concept, to make it clear what it stands for relative to the other. (ie if too many things all start getting combined into only one variable like Fealty it kind of loses its uniqueness.)
- each one have separate sources and benefits that are appropriate to its theme, without overlapping/redundant sources and effects between different variables
- the different sources and benefits of each variable should be fairly evenly divided across the two, without once having overwhelming importance

My thoughts are that:
Prosperity could measure the degree to which the local economy is prospering and citizens are growing in wealth and contented with their economic needs satisfied. It should get strongly influenced by how much of the city's existing domestic demand gets satisfied. As it's benefit, maybe it could boost gold from domestic sales. Since Prosperity is YIELD_CULTURE, if it uses the city Culture Level mechanism of Civ4, it could be a good fit with your idea that reaching higher levels of culture unlocks a new tier of Max Population and Buildings and boost domestic market sales cap, etc. But be careful that this doesn't get frustrating/confusing for players.

Fealty would measure the degree of subjects' obedience/allegiance/duty and the control exerted by the ruler, and the effectiveness of local governance and administration. It should be most strongly influenced by governing by Nobles (plus maybe some additional boost from local Cross production by priests); it gives the bonus to production to all local citizens from the enhanced obedience and administration, plus the FF points from noble's patronage, and gets used to enact the Victory condition. In contrast to today medieval societies were very far from a democracy concerned about citizens opinions; it was not the primary goal of feudal overlords to make peasants and other subjects wealthy or feel in a good mood, just to ensure that they obeyed and were kept in line to serve their betters and obediently fork over a big cut of wealth and labor like they're supposed to. As one case in point http://en.wikipedia.org/wiki/Peasants'_Revolt was actually caused by *increased* relative prosperity and liberty of the peasantry arising from growing wages for rural labor following gradual recovery from the Black Death. Brutally suppressing it certainly boosted the Fealty of the remaining peasants! As with Machiavelli's motto "tis far better to be feared than loved"..

There are several tags for Culture which may have been deactivated in Civ4Col:
<CityCulture>NONE</CityCulture>
<iNumCultureCities>0</iNumCultureCities>
<iTotalCultureRatio>0</iTotalCultureRatio>
Now that YIELD_CULTURE (Prosperity) is back in M:C, maybe these could be reactivated which would allow you to mod victory conditions such as having 10 megacities reaching the Legendary level of Prosperity, or have your empire represent a certain percent of the global total Culture/Prosperity using <iTotalCultureRatio>. If Prosperity is gradually earned by successfully fulfilling your citizen's demands over a long period (and the mechanism you'd suggested earlier of high Prosperity attracting raiders as a balancing mechanism, who could then ravage local Prosperity if not defeated); then reaching high levels would be quite a challenging/fulfilling game goal for those more interesting in careful economic management than revolution.
 
Maybe the answer would be to not gain gold on overflow. Rather than thinking "what should this feature be like", we need to ask "how should the economy work?".

The problem with this is goods would always be wasted when overflowing unless the "market cap" for demands was raised to cover all goods overflowing. And you would have to micromanage turning on and off "Never Sell" as goods reached and fell below the overflow cap.

Those are some good points orlanth. Currently, the two aspects that are combined are Immigration and Culture. Culture is modified by Religion and Education as I figured these two add to a societies Culture. And Immigration is a measure of the things I figured would attract people to your Realm; Fealty, being that the more loyal your people are they more they will be saying encouraging things. Then Religion as people are always attracted to region, and then Education, as people look for Education opportunities. Fealty is still its own separate yields.

The Immigration system could be expanded in that Units could have a "Favored Yield" and the more a City produces that yield the more a chance they will join the Immigration que.

Over the next couple weeks I'll be play testings and balancing. The best way is to actually play a game through with different settings and test out how the game flows. I am wanting to get the game balanced in its current Theme, so then we can branch out and start adding things like new Victory conditions and Empire Upkeep.

Ray pointed out in a post that the Demands system of R&R was not a critical part of the game, you could manage it or not. In my current M:C game it is not critical at all as you can always Sell those goods on the market manually. That is why I say it "feels" like it should do more so that the player has to actually focus more attention to it, or not just depending on what we want from it. What is more critical, but not a game changer either, is selling overflow goods, as this keeps you from completely wasting your goods, and players don't have to manage it. So, I really don't want to lose the overflow selling effect of buildings.
 
I don't like the marked because you can potentially sell hundreds of unwanted yields of a single type even though that massive amount has no buyers at all. It could be say grapes on a map with way too many grapes on it. If we export the grapes, the price will drop and you will have to make an effort to move them far away. Just placing a single marked in a single city and then sell virtually unlimited amounts is horribly off balance.

Reading what orlanth wrote gives me an idea. Right now the doTurn code sums up all demands and available yields. This is then used to sell the yields, but we could do more than that if we like.

Say we calculate a score for how well the demand is met. This score is then applied to every city in the plotgroup and can be used for certain stuff, like prosperity production bonus. This score is then reset and calculated every turn.

If we store yield produced this turn as floats (currently int), we can produce 10.9 prosperity. The code will still read this as 10 when reading it, but if we add 8% from markets, then it will be 11.772, which is read as 11. 10 + 8% is 10.8, which is read as 10. In other words using floats will make it more likely to be affected by small bonuses. (this is something worth considering for multiple places in the code).
A negative bonus should start by adding a small amount to prevent -1% from changing a production of 2 to 1. Minor balance issue.

If we do this, we should figure out a well made formula for bonus calculation because not having a demand will result in 100% supplied and not supplying the only demanded yield will result in 0% supplied. The calculation should be somewhat neutral at first and then increase as the number of demands/citizens increase.

The only real problem with this system (apart from figuring out how to calculate bonus) is that sales takes place after CvCity::doTurn(). This mean whatever we do has to be a function being called later. Not a major issue, but it is something to keep in mind to avoid silly bugs.
 
I don't like the marked because you can potentially sell hundreds of unwanted yields of a single type even though that massive amount has no buyers at all. It could be say grapes on a map with way too many grapes on it. If we export the grapes, the price will drop and you will have to make an effort to move them far away. Just placing a single marked in a single city and then sell virtually unlimited amounts is horribly off balance.

I understand your issues with it. The "buyers" are simulated, much like the Trade Screen markets, as there isn't really any market at all. But, the problem with any system that sells yields locally is that it is over ridden by the ability to sell Huge amounts to the Trade Screen markets or to nearby foreign towns. So, any local markets, at the moment, is a minor game mechanic. This is what is happening in my current game: Say, I produce 300 units of Wine, which I can sell on the Silk Road for maximum profits, so there is no need really to just let my Wine slowly sell each turn when I can sell the whole load in a few turns with a trip along the Silk Road. Also, I buy 300 units of Silk on the silk road, which I can sale for 3x as much on the Spice Route, so why should I leave my Silk in a town for the local demand when I get my money faster buy selling manually?

So, We can either design it so that fulfilling demands gives other bonuses where you don't actually receive gold perhaps, or make it a more critical part of Trading, or leave it a minor factor.

We can easily make it so that we can set up Auto Trade Screen routes where a Unit will continue picking up goods from your Ports and Shipping them off to the Trade Screens. Right now you have to start them over again each time they return.

Reading what orlanth wrote gives me an idea. Right now the doTurn code sums up all demands and available yields. This is then used to sell the yields, but we could do more than that if we like.

Say we calculate a score for how well the demand is met. This score is then applied to every city in the plotgroup and can be used for certain stuff, like prosperity production bonus. This score is then reset and calculated every turn.

Yes, this idea has potential and will keep this in mind as I play test.
If we store yield produced this turn as floats (currently int), we can produce 10.9 prosperity. The code will still read this as 10 when reading it, but if we add 8% from markets, then it will be 11.772, which is read as 11. 10 + 8% is 10.8, which is read as 10. In other words using floats will make it more likely to be affected by small bonuses. (this is something worth considering for multiple places in the code).
A negative bonus should start by adding a small amount to prevent -1% from changing a production of 2 to 1. Minor balance issue.

Actually, it is a Float right? When you hover over a building for help text it tells you how much is produced and when it calculates it, considering the percent factors, it shows, for example "Total Religion = 3.18", but it only produces 3 goods that turns.
 
Actually, it is a Float right? When you hover over a building for help text it tells you how much is produced and when it calculates it, considering the percent factors, it shows, for example "Total Religion = 3.18", but it only produces 3 goods that turns.
CvCity doesn't use float or double for storing anything. It does however use int to store a bunch of yield stuff. I haven't looked at the help text for any GUI stuff for that matter (right now), but from what I can tell, the core calculations are all done in int.

Presumably Firaxis decided to use int as much as possible because int used to be a whole lot faster than floating point. Modern CPUs handle floating point so much better that using float everywhere where vanilla divides with 100 would likely speed up the game. (partly because division is still relatively slow).
 
phew, I finally found the stuff about supply/demand gradually adjusting local prices. sometimes it can get impossible to find stuff in all these threads!:p

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 XML tags below come from CIV4YieldInfos.xml, allowing you to flexibly mod the characteristics and price elasticity of each good:
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)))

Whenever a yield is sold to a city during trade, call the following function, thus lowering the local price by a degree proportional to the amount sold, never falling below the floor of iBuyPriceLow.
iBuyPrice = max(iBuyPriceLow, (iBuyPrice-(iBuyPrice - iBuyPriceLow)*(iUnitsSold/iPriceChangeThreshold)))

At the end of the turn, calculate the fraction of local Demand that got fulfilled, and use this to adjust local prices slightly up or down similar to the above functions.

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). If you're generating tons of money by fulfilling all the Demand for a good locally with your supply, local prices will drift downward, gradually stimulating you to seek out other export markets where that good is in shorter supply. :king::gold: The price sensitivity and min/max price for each good can be easily balanced as desired using just XML. 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 (and by successfully trading from areas with oversupply to areas with undersupply), without having to micromanage to an artificially precise limit like "demands exactly 3 Cigars per turn". If you like, Trade Screens prices could work by generating a certain amount of Demands like other cities do to enable price adjustment (I agree it is somewhat too easy currently to simply dump everything on a single Trade Screen without thinking about things.)

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 yields 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. Maybe this could be easily solved too if prices could be a float instead of an int.
 
CvCity doesn't use float or double for storing anything. It does however use int to store a bunch of yield stuff. I haven't looked at the help text for any GUI stuff for that matter (right now), but from what I can tell, the core calculations are all done in int.

Your right of course, but yields produced results are not stored they are calculated each turn. I haven't looked so I am not sure what kind of calculations they use for the actual total produced, but I know the help text uses a float. Anyway, we can change it up to calculate using a float.

At the moment my goal is to get the game balanced and fun as is and I am not going to worry so much about demands and such. I would love for someone else to actually play test as well so we can swap some in game ideas around.

I would like to see a more realistic economy set up, but if there is going to be any considerable time spent on it then it would need to be done in such a way that truly impacts the game so the player has to consider his economic choices. I personally wouldn't want to spend a whole lot of time on a system that want get utilized much, not at this point. I am wanting to work on game changing stuff, or graphics ;)

orlanth and others have offered some good suggestions and when I am done with my current goals I'll look into other options.
 
Your right of course, but yields produced results are not stored they are calculated each turn. I haven't looked so I am not sure what kind of calculations they use for the actual total produced
It calculates the production each turn and stores the result in an int array. When it adds production modifiers and ad to warehouse etc. it does it with int calculations.

It is a good point with help text. We should rewrite the code to make it use the same functions (calculations) for help as it use for internal calculations. That way they will not go out of sync and weird results will be easier to spot.
 
Ah, ok, I didn't realize or forgot it saves the total, didn't think it would even do that.

I'm in a tight spot in my current game, Saladin has started his conquest and I am a good ways off still yet. Makes me wonder if I'm just slow or the AI too fast. Anyway, I am defiantly seeing areas in need of changing or improvement. It is taking me a long time to build up my three cities, mainly because production just takes so long, especially when settlements begin with so few buildings. Makes me wonder if production costs should be lowered, but maybe I'm just not a very good city manager:cry::lol:
 
I noticed a potential problem with civics. We coded everything in CvPlayer while vanilla assumes the code to be in CvTeam. Most of the time it is the very same thing, but if multiple civs are on the same team (could happen, specially in multiplayer), then we have to decide if we want to use player or team.

If we stick to player, then each player has his own set of inventions, civics and all that. If we use team, then research is a joined effort. Founding Fathers are dealt with on a team basis.

What I noticed right now is that revealed bonuses are handled by CvPlayer, but CvTeam stores which bonuses are revealed. What should we do about that?
1: revealed to one player in a team means it is revealed to all players in the team
2: try to move the code into CvPlayer
3: something else... (whatever that might be)

We may also consider if we should set reveal bonuses in civics. Right now we set if we can use bonuses, but being able to reveal with one tech and then exploit with a later one might be a wanted feature.
 
I noticed a potential problem with civics. We coded everything in CvPlayer while vanilla assumes the code to be in CvTeam. Most of the time it is the very same thing, but if multiple civs are on the same team (could happen, specially in multiplayer), then we have to decide if we want to use player or team.

If we stick to player, then each player has his own set of inventions, civics and all that. If we use team, then research is a joined effort. Founding Fathers are dealt with on a team basis.

What I noticed right now is that revealed bonuses are handled by CvPlayer, but CvTeam stores which bonuses are revealed. What should we do about that?
1: revealed to one player in a team means it is revealed to all players in the team
2: try to move the code into CvPlayer
3: something else... (whatever that might be)

Yeah, we can add code so that Inventions are revealed to all players on the team, if they are applicable. Civics should be separate of course as they can be chosen per player.

Barbarians (Natives) are another issue. We need to decide just how to deal with them once and for all:) Do they remain as minor Civs, with few advancement options (as per Vanilla) or are they able to reach certain or all tech levels.

We may also consider if we should set reveal bonuses in civics. Right now we set if we can use bonuses, but being able to reveal with one tech and then exploit with a later one might be a wanted feature.

Yeah, I've started leaving things like this on a request basis. If its a cool idea but I don't want it for myself at the moment and no one is requesting it then I just add it to the "cool idea list".

Edit: also, when we start adding and removing access to yields or professions we have issues of what to do with current yields and professions we can no long have. With professions we would have to cycle all units and do a "Do to recent Civics change, your Unit has lost its job". I think I have code for Professions already but it may need improved.
 
Does "team" count any alliance you agree to in-game? If so it could be best to keep all effects per-player or any team will easily rack up tons of combined tech and FF bonuses.

Originally Posted by Nightinggale View Post
We may also consider if we should set reveal bonuses in civics. Right now we set if we can use bonuses, but being able to reveal with one tech and then exploit with a later one might be a wanted feature.
Yeah, it would be cool to let early techs reveal/discover certain Bonuses like they do in Civ4. (especially for world history could allow later discovery of advanced bonuses like happens with Oil/Uranium in Civ4, adding a strategic resource twist you won't know right from the beginning). Another good civicinfos tag would be to add a given amount to yields produced by a Bonus, Feature or Terrain.

Barbarians (Natives) are another issue. We need to decide just how to deal with them once and for all Do they remain as minor Civs, with few advancement options (as per Vanilla) or are they able to reach certain or all tech levels.
I think they should start out with fewer (or different) starting techs and a penalty to research, but still be able to eventually progress. Civs like Magyars, Slavs, and Burgundy weren't permanently different from others like Franks or Ostrogoths, maybe they started out a bit more disorganized/backward but did progress into regular feudal civs and civilized nation-states just like all the others. (In World History or 2071 there also wouldn't really be any civs that remain permanently unable to make any progress). Maybe there could be some tech Feudal Society that they could gradually reach, after which their initial <isNative> feature of "invisible borders" gets turned off. It would be especially cool if by trading with your neighbors you're also helping make them gradually advance, so it's a double-edged sword where you need to think twice about giving up lots of advanced tools/weapons/tech to someone who could eventually become your competitior. :king:

Edit: also, when we start adding and removing access to yields or professions we have issues of what to do with current yields and professions we can no long have. With professions we would have to cycle all units and do a "Do to recent Civics change, your Unit has lost its job". I think I have code for Professions already but it may need improved.
That's a good point.. I guess when a Profession gets obsoleted, units with that could change to default profession for that unitclass. I like that unitclass immigration can get unlocked separately (ie you might be able to get a rare special unitclass by special Event, even before you unlock immigration of that unit.)
 
Does "team" count any alliance you agree to in-game? If so it could be best to keep all effects per-player or any team will easily rack up tons of combined tech and FF bonuses.
In standard games, there is one player on each team. In custom games and multiplayer (multiplayer is always custom), you select team number of each player. Default is a unique team for each player.

When you manually set two or more civs to one team, they will join forces in multiple ways. For instance they always share map and field of view. They can threat teammates' plots as their own. You declare war or ally with teams, not players. You share founding fathers and share founding father points. You can set up traderoutes to unload in cities owned by your team, not just your own cities. Native attitude towards you is reduced by number of teammembers in excess of the first one. There are presumably more stuff as well.

I haven't used it in singleplayer, but it works well in multiplayer (in RaR. I still haven't looked at M:C multiplayer). Set two humans to the same team and increase difficulty level. It will then be humans against the AIs, which rather well.

Teams can't be changed once the game starts. It has nothing to do with allies.

Yeah, it would be cool to let early techs reveal/discover certain Bonuses like they do in Civ4. (especially for world history could allow later discovery of advanced bonuses like happens with Oil/Uranium in Civ4, adding a strategic resource twist you won't know right from the beginning). Another good civicinfos tag would be to add a given amount to yields produced by a Bonus, Feature or Terrain.
Don't we already have something like that? If not, then we should certainly add it.

@slow native research
Maybe we should make a "reduced research" trait, which we can give to the leaders we want to act "native". We can even make events or triggered events to remove such a trait if we like. We way also introduce techs, which can't be researched by certain civ types meaning natives will not evolve in certain directions without interacting with other civs. In fact we could make it impossible for a single civ to research everything themselves and trading/demanding/stealing techs from each other could be a major game factor. If we do that, then it should be a game option as it certainly is a matter of taste if that is a desired gameplay.

That's a good point.. I guess when a Profession gets obsoleted, units with that could change to default profession for that unitclass. I like that unitclass immigration can get unlocked separately (ie you might be able to get a rare special unitclass by special Event, even before you unlock immigration of that unit.)
Good except you risk reverting your soldiers to no profession and lose all your weapons.
 
Top Bottom