Caveman 2 Cosmos (ideas/discussions thread)

[Dancing Hoskuld]

Most information on a unit is stored as a promotion. There's a variety of bits of info and a lot of it, particularly what can be in packets, such as buildings are to cities, promotions can handle. There are ways to categorize various promos as well so that they aren't normal skill promos. We'd have to work together to design out according to needs.

As for inventory stuff, That's a lot of dll work but once done it could easily be reported to python for screen designs.

Usually with this sort of thing you have to identify exactly what you want on the screen then start considering the graphic display in some kind of crude mockup then once you're sure you have something of a layout, then you can proceed into the coding challenges on each segment.

Neat idea to do that as an action button. Totally makes sense. Obviously there needs to also be a way to close or exit the screen as well.

But a tribe is more like a city. It has varying population for a start.

Think of all the Python screens eg Advisors but with the ability to do stuff like you could in Civ III. I miss the Civ III military advisor. You could just show all the units you could upgrade, order them by strength or experience and choose which to upgrade on that screen without having to go through all the cities and stacks.

 

[Thunderbrd]

But a tribe is more like a city. It has varying population for a start.

The population tracking should be a new saved int on CvUnit. I suppose we could avoid having to use SM with this and could make SM simply adjust the statistics of the tribe to the right level based on the population.

Note that I think we really should be tracking down to the man on population on a tribe, not just the normal population counter that a city normally has.

@billw2015: important question for this whole project: Is it possible to ONLY declare and therefor reserve memory for a tag on a unit IF the unit is a particular type (say, defined by one of it's UnitCombats)? Or if you MIGHT have a tag in use on a unit, ALL units must initialize a storage data object for that tag?

Example is right here: Can I declare, say, m_iCurrentPopulation ONLY on Units with a Settler or Nomadic Unitcombat? And leave all other units undeclared on that object so that they don't bother to allocate memory towards that?

 

[colonelflag]

View attachment 536271 View attachment 536272

Great thanks Toffer90

 

[Dancing Hoskuld]

The population tracking should be a new saved int on CvUnit. I suppose we could avoid having to use SM with this and could make SM simply adjust the statistics of the tribe to the right level based on the population.

Note that I think we really should be tracking down to the man on population on a tribe, not just the normal population counter that a city normally has.

@billw2015: important question for this whole project: Is it possible to ONLY declare and therefor reserve memory for a tag on a unit IF the unit is a particular type (say, defined by one of it's UnitCombats)? Or if you MIGHT have a tag in use on a unit, ALL units must initialize a storage data object for that tag?

Example is right here: Can I declare, say, m_iCurrentPopulation ONLY on Units with a Settler or Nomadic Unitcombat? And leave all other units undeclared on that object so that they don't bother to allocate memory towards that?

Tribe should per person. Although I would class Mother and Infant (a job description) as one. That means we need to know what each person is doing and what "promotions" they have.

My current idea is that each Adult (=person until your tribe is rich enough to support Elders and Children) can gather and carry only so much and need a set amount to survive the turn. That amount in most cases this will be well below what the plot produces as it takes hundreds of people in a city to harvest the full resources of a plot.

Initially a tribe (a unit) is a small band of 15-25 persons each person will spend most of their time gathering and eating, ie just surviving. All these people are Adults and have 4 or 5 "jobs" mostly gathering. Mothers with Infants are necessary for your tribe to grow or stay the same size. Two of their jobs are taken up with infant care but they provide some Lore (= and Education) in exchange for not gathering or carrying as much as a normal Adult. All Adults are equal to a base warrior as far as combat is concerned.

This means that we need to store what jobs are being done in some way. It is fine to store "some one is an alpha male" as a promotion but how do you store that there are 3 Mothers wit Infants?

 

[billw2015]

@billw2015: important question for this whole project: Is it possible to ONLY declare and therefor reserve memory for a tag on a unit IF the unit is a particular type (say, defined by one of it's UnitCombats)? Or if you MIGHT have a tag in use on a unit, ALL units must initialize a storage data object for that tag?

Example is right here: Can I declare, say, m_iCurrentPopulation ONLY on Units with a Settler or Nomadic Unitcombat? And leave all other units undeclared on that object so that they don't bother to allocate memory towards that?

You could have a generic property system in C++ where you can use something like an std::map. I would not recommend it. Alternatively you just use separate classes to represent parts of the unit that correspond to particular systems. This is called the entity-component system, and is used in most games. It means you can have your unit just be an array of these components, and only add the components that are required. In this case the "population" component I guess. Actually it is the first time it occurred to me that this is probably the way to significantly reduce memory usage and increase performance in units (a lot of refactoring work though!)

 

[Nightinggale]

Actually it is the first time it occurred to me that this is probably the way to significantly reduce memory usage and increase performance in units

I get the memory usage, but how will it increase performance? The only performance change I can see is this:
Currently:
pUnit->getVar(), will take pUnit (a pointer, hence an int) + constant set at compile time, then fetch content of that pointer.
New:
pUnit->getVar(), take pUnit, get pointer + constant, fetch module pointer, add constant to that pointer and fetch that address from memory.

You have increased the number of memory lookups to read the variable you want rather than decreased it. This will slow down the performance, not improve it. Generally speaking the goal is to remove as many such lookups as possible because with the ever increasing CPU speed, the delays from reading from memory becomes more and more dominant.

If you want to add conditional memory like that, then I would recommend a union. You can make a class/struct for one UnitCombat, another for another UnitCombat etc. If you make sure you can only have one active at the same time (if any), then put all of them into a union. Not pointers, but declarations like all the other variables in CvUnit (except for the pointers obviously).

This way the memory for the uc classes will be placed in CvUnit, hence not another lookup. However all the classes in the union will be in the same memory, meaning if you have say 20 bytes for one uc, 16 for another, it will allocate 20 bytes for all instances of CvUnit (the biggest class), not 20+16 for all.

I get the feeling the unions are severely overlooked in the civ4 community. I used one the other day because I needed a pointer, but by placing multiple pointers in a union, I can decide at runtime which type I want while it's still only takes up the memory for a single pointer. Seems to work perfectly. Vanilla use unions too (in FVariable), but less clever because the different variables are of different size, hence the compiler will always reserve memory for the biggest and as such will waste memory. Unions work best if all the variables/classes in them are of around the same size.

 

[billw2015]

Entity component systems increase performance when you use arrays for your components and perform functions on everything in those arrays. Because your array is containing only the component data, and laid out consecutively in memory, you can get more of it in cache at once, with no dereferencing required. Iterating over the component array is therefore faster than iterating over a set of entities each requiring a dereference, and filling your cache with stuff you don't need.
However I haven't thought much about, let alone actually investigated, how well this model can actually be applied to the Civ units, it was just a passing thought I tacked on to the end of that post as I was having it.
ECS is normally useful in cases where you want to always be applying functions to all the entities that have a certain component, e.g. a transformation component + a physics component to apply movement each frame.

If you want to add conditional memory like that, then I would recommend a union. You can make a class/struct for one UnitCombat, another for another UnitCombat etc. If you make sure you can only have one active at the same time (if any), then put all of them into a union. Not pointers, but declarations like all the other variables in CvUnit (except for the pointers obviously).

Unions are of somewhat limited use I think compared to components, they only work in the case where things are mutually exclusive, and are only optimal (memory wise) in that case where the types are of the same size (edit: and required! If the union is entirely optional then it is also a waste of space!). I think the vast majority of a unit definition is a large set of unrelated but optional behaviours that would be better represented using a set of components.
However certainly in the niche when you have a few different, mutually exclusive, either small or required structures then a union would be a good bet, assuming we can't use component arrays in an optimal fashion (and my intuition is saying we almost certainly won't be able to, as the units are very often being accessed randomly, and the existing logic probably isn't coherent with respect to which components would be operated on).

 

[Thunderbrd]

Tribe should per person. Although I would class Mother and Infant (a job description) as one. That means we need to know what each person is doing and what "promotions" they have.

My current idea is that each Adult (=person until your tribe is rich enough to support Elders and Children) can gather and carry only so much and need a set amount to survive the turn. That amount in most cases this will be well below what the plot produces as it takes hundreds of people in a city to harvest the full resources of a plot.

Initially a tribe (a unit) is a small band of 15-25 persons each person will spend most of their time gathering and eating, ie just surviving. All these people are Adults and have 4 or 5 "jobs" mostly gathering. Mothers with Infants are necessary for your tribe to grow or stay the same size. Two of their jobs are taken up with infant care but they provide some Lore (= and Education) in exchange for not gathering or carrying as much as a normal Adult. All Adults are equal to a base warrior as far as combat is concerned.

This means that we need to store what jobs are being done in some way. It is fine to store "some one is an alpha male" as a promotion but how do you store that there are 3 Mothers wit Infants?

My original thinking on this was to categorize population by the group size categories in SM. This could be used with or without SM being in place - with it we just have some of the built in capabilities to potentially manage tribe splits.

I really don't think we should be tracking the roles, ages, genders in the tribe much and let specialized roles be a matter of unit generation mostly.

However, I'm in agreement that we would need to have gradual expansion of need and ability to collect yields on the plot. Tracking that by group size categories makes sense - again, in non-sm games these categories would still apply to helping with tracking consumption and collection of yields. We will have to get into consumption and collection amounts in decimals. One plot food = 100 Unit Food. Then we can break things down from there. Ex: An individual size unit would consume 1 food, a Battalion size tribe 300 food (3 plot food).

Collections would expand with 'promotions/buildings' and techs and size. Consumption by size. Commerces and resulting research, would accumulate, as per normal, except that collection ability would expand in similar manners to the way food collection would and as collected, it would immediately go into national totals and not be something they would track in an inventory sense. Production would, however, which would validate the ability to make purchases of various things, 'promotions/buildings', units (which would also cost population and you wouldn't be able to spend more than 1/2 your population in a tribe on units at a time). Past a point, production would go to waste as we are basically assuming that all along you've been building to whatever you choose to 'purchase' with a mission action. I suppose we could go to a lot of trouble to create a new build queue system for tribes, but that seems like a huge undertaking.

When collections start taking the full amount the tile can offer, the tile starts getting 'tired' and the next round it would produce less, thus the tribe should move on. More on that later though.

Anyhow, more to discuss as we go.

 

[Nightinggale]

Entity component systems increase performance when you use arrays for your components and perform functions on everything in those arrays. Because your array is containing only the component data, and laid out consecutively in memory, you can get more of it in cache at once, with no dereferencing required.

So you are saying you want to add a vector of components to CvPlayer and then loop the components. It seems doable and yes it will most likely be faster if you only need the component data. However if you have CvUnit and need data from the component, it will be slower. Also you have the extra overhead of linking the component to the CvUnit, including the risk of bugs (linking to wrong vector index etc). Also if the component points to CvUnit and that pointer is used during the loop, you will have gained nothing.

It's not a bad idea, but you will likely need a significantly sized component for this to work well.

Unions on the other hand will not have the overhead of linking two different locations in memory, hence you won't have the risk of going out of sync. You will need to find mutually exclusive data for them to work though.

If we look at the question, which started this, which is to store population in a settler. Following the vanilla approach, we can add the variables and leave the data 0 for non-settlers. This will waste memory for non-settlers. Even worse, this wasted memory is usually saved, meaning it's bloating savegames in addition to runtime memory.

Now if we make a struct and move some existing data into that struct, then we will end up with something, which compiled is the same as it is right now if we have one instance of that struct as member data. Say we add city bombardment data. Now if we place that struct in a union, it will still not change anything. If we make another struct and add population, if the population struct isn't bigger than the bombardment struct, then the population data is saved in CvUnit without using more memory. If you can find something, which is exclusive to both settlers and bombardment (worker data comes to mind), then add a struct for that too and suddenly it will use less data than it is using currently even if it is storing more data. Yes it will waste memory if the structs aren't of the same size, but it will waste less memory than the current design.

You will need logic to the get/set functions of the union data though. This can be done with checking unitcombat in some switch case setup, assert check that only settlers ask for population, template int parameter to function calls or something else. There are multiple ways to do this.

I wonder if you can do something clever with the structs where the get/set calls the structs and the "wrong" structs returns the default value (often 0). This would however move the problem to calling the correct struct. Maybe there should be just one struct, which then takes a template int parameter, hence one struct for each unitcombat. If done cleverly, that could move a lot of the switches between the types to compile time.

This quickly gets complex and it's no wonder vanilla didn't go this way. It's too easy to just waste memory.

It's also worth considering which kind of variables you store. Do you really need 32 bit to store population? If it's always max 15 of each group, 4 bits will be enough and bitfields can be used. That's another way to reduce memory usage. In fact putting all the bools together and use :1 can save a bunch of memory because then you can have 32 bools in what the compiler will normally assign to a single bool.

There is one more way to save memory, which is to use EnumMap and EnumMap2D (array of EnumMaps), the two classes I'm currently working on. They get a type (usually the length of an xml file, but can be MAX_PLAYERS etc) at compile time based on template parameters, reads the length at runtime (doesn't have to know the number of units at compile time etc) and then it has set, get and add functions. Kind of similar to the functions you already use, except it has strict typing in arguments and importantly here: automated memory management.

What it does is that it assumes everything to be the default value while containing a NULL pointer. It doesn't allocate the array until a non-default value is written to the array. It releases the memory when calling reset() or the deconstructor (yeah, no memory leaks). There is one more way to release memory, which is to call hasContent(), which will release the memory if everything is of the default value. Since saving the array calls hasContent(), autosave becomes some sort of garbage collector.
Also it can reduce the size of the saved variables too. If you want to make an array of PlayerTypes, the compiler will go "MAX_PLAYERS <= 128" and since it fits in a char, it will make the array to be a char array internally. An array of PlayerTypes will compile into an int array, which use 4 times the amount of memory.
I will however point out that I better finish developing EnumMap before porting it to other mods. It's still new and under development, but it's near completion, kind of like beta state.

If you are going to aim at reducing memory usage, I better keep an eye out for what you are doing. You might come up with something interesting.

Oh and do make sure you know precisely what you are storing in memory. I learned this week that Colonization stores yield modifiers for each player in each area. That's 11.5 kB of data for each area, which is always allocated and saved. The reason why this is bad is because the set function is never called, meaning it's 11.5 kB of only 0 values and whenever it's called is is used as right hand value in +=, meaning it doesn't do anything. Changing it to an EnumMap2D reduced it to 4 bytes for each area without killing the feature (we might use it in the future). Sometimes memory usage isn't in the most obvious locations.

 

[billw2015]

So you are saying you want to add a vector of components to CvPlayer and then loop the components.

No I was just describing how entity component system in general allows for better performance, I didn't think about how or even if to implement in Civ code, as I didn't look at the CvUnit structure with it in mind yet.

Oh and do make sure you know precisely what you are storing in memory.

Yeah its clear that memory usage is extremely inefficient, with massive boolean arrays allocated (not even vector<bool>, just bool* so it is a byte per value) just so one or two of the values can be set to true.

If you didn't see already I also added MemTrack to our mod: https://forums.civfanatics.com/threads/memory-usage.649538/

My thread on what stuff I am planning to look into for performance and memory optimization: https://forums.civfanatics.com/threads/dll-optimizations-im-considering.648500/

 

[Dancing Hoskuld]

My original thinking on this was to categorize population by the group size categories in SM. This could be used with or without SM being in place - with it we just have some of the built in capabilities to potentially manage tribe splits.

I really don't think we should be tracking the roles, ages, genders in the tribe much and let specialized roles be a matter of unit generation mostly.

However, I'm in agreement that we would need to have gradual expansion of need and ability to collect yields on the plot. Tracking that by group size categories makes sense - again, in non-sm games these categories would still apply to helping with tracking consumption and collection of yields. We will have to get into consumption and collection amounts in decimals. One plot food = 100 Unit Food. Then we can break things down from there. Ex: An individual size unit would consume 1 food, a Battalion size tribe 300 food (3 plot food).

Collections would expand with 'promotions/buildings' and techs and size. Consumption by size. Commerces and resulting research, would accumulate, as per normal, except that collection ability would expand in similar manners to the way food collection would and as collected, it would immediately go into national totals and not be something they would track in an inventory sense. Production would, however, which would validate the ability to make purchases of various things, 'promotions/buildings', units (which would also cost population and you wouldn't be able to spend more than 1/2 your population in a tribe on units at a time). Past a point, production would go to waste as we are basically assuming that all along you've been building to whatever you choose to 'purchase' with a mission action. I suppose we could go to a lot of trouble to create a new build queue system for tribes, but that seems like a huge undertaking.

When collections start taking the full amount the tile can offer, the tile starts getting 'tired' and the next round it would produce less, thus the tribe should move on. More on that later though.

Anyhow, more to discuss as we go.

Having a tribe as a bunch units each being a single individual is a problem. For the most part they all have to be on the same plot and moving together to new plots.

Going with "1 Plot = 100 forage" I was going with all individuals are Adults at start.

An Adult able to gather 5 forage per turn and needs 4 forage per turn to survive. An Adult with the "Mother with Infant" promotion can only gather 3 forage per turn but still needs 4 to survive. You need 1 Mother with child per 5 (may be 3, still working that out) people to maintain population plus one extra if you want to grow your population. All Adults can carry over 2 excess food for the next turn. This is way more than they can possibly get normally but it would allow for some interesting Events.

When you get the Gathering tech then each Adult gets the Gathering promotion which means that they collect one extra forage per turn.

When you get the Basketry tech you need to assign one person to be a Basket Maker. They get -2 forage but everyone in the tribe gets the Basket promotion that allows them to gather and carry over twice what they did before.

Actually this does not work with the tech tree the way it is.

Also I was thinking of having research being done in two ways, by doing stuff and directed learning as we now have. All Adults would give +1 Lore towards Scavenging. Mothers with Infants would give an additional +1 Lore to all child care and health techs. Elders and Child give +1 Lore (chosen like ). Elders give +1 Lore to cultural techs while Child give +1 Lore to Language and science techs.

Side notes to the above

• Infants are age 0-3 years and Adults are ages 3+ until Scavenging when Infants are ages 0-5 and Adults are 5+. When your tribe is wealthy enough to support them a Child is 5-12 years and an Adult is 12+.
  
  
• Goody Huts don't exist at start they are placed by excess tribes. When you make a new tribe you may not be able to control it and it becomes a very friendly independent "nation". As you get better with your organization and communication you may be able to get them to rejoin your nation but they may also just wander off and become a goody hut.

 

[tmv]

Then there's hunting, which we already have in the mod, but how would it need to be adjusted?

 

[Thunderbrd]

Actually this does not work with the tech tree the way it is

Why not? A lot of this is quite similar to what I had in mind as well. I'll evaluate it further later but I think we're looking at it similarly in terms of the numbers and reasons for increases in the ability to gather.

The tribe would be the unit core but the units that you make from the tribe are capable of moving beyond where the tribe is at. I was planning on detailing some consumption details potentially for even non-tribe units at some point, at least optionally anyhow. If that option wasn't on then some kind of upkeep from units tagged to a mother tribal unit would still apply.

Infants are age 0-3 years and Adults are ages 3+ until Scavenging when Infants are ages 0-5 and Adults are 5+. When your tribe is wealthy enough to support them a Child is 5-12 years and an Adult is 12+.

Do we really want to get into identifying the individual folks in the tribe to that degree?

 

[Dancing Hoskuld]

Why not? A lot of this is quite similar to what I had in mind as well. I'll evaluate it further later but I think we're looking at it similarly in terms of the numbers and reasons for increases in the ability to gather.

The tribe would be the unit core but the units that you make from the tribe are capable of moving beyond where the tribe is at. I was planning on detailing some consumption details potentially for even non-tribe units at some point, at least optionally anyhow. If that option wasn't on then some kind of upkeep from units tagged to a mother tribal unit would still apply.

Do we really want to get into identifying the individual folks in the tribe to that degree?

I was assuming that any units not in the tribe would still need food from the tribe, unless they were out hunting for example.

As to if we need to identify them to that degree then yes I think we do. It gives the player more control and options.

(You may have notices I did not mention or money in my description. Neither exist at the start of the game. )

Take basketry, when you get the tech that allows baskets then someone in the tribe needs to become a basket maker at some time. In this model that takes one full turn of a normal Adult's turn (or 4 gathering "slots" anyway). Then they have the promotion Basket Maker and everyone else has Baskets and get the benefits next turn. Note we could say that you need a Basket Maker per x population if we want to go that way. Which would mean that any extra population would not have the Basket promotion so would be less able to gather.

 

[Thunderbrd]

I was assuming that any units not in the tribe would still need food from the tribe, unless they were out hunting for example.

As to if we need to identify them to that degree then yes I think we do. It gives the player more control and options.

(You may have notices I did not mention or money in my description. Neither exist at the start of the game. )

Take basketry, when you get the tech that allows baskets then someone in the tribe needs to become a basket maker at some time. In this model that takes one full turn of a normal Adult's turn (or 4 gathering "slots" anyway). Then they have the promotion Basket Maker and everyone else has Baskets and get the benefits next turn. Note we could say that you need a Basket Maker per x population if we want to go that way. Which would mean that any extra population would not have the Basket promotion so would be less able to gather.

It sounds like you're not working on a system that would be easily integrated as an option.

 

[Esfera]

Let's break this down:
According to the fluff statistics of C2C, 1 Pop is 50 people, 2 pops is 100 people and, if I remember correctly, 3 pops is 250 people. And so on, it is not a logarithmic function, you get the point.
Ignoring wasted food and , 1 Pop requieres 4 to be sustained

1 equals to 100 forage, 1 forage equals to 1 adult.
Thus, 1 equals to 100 adults.
A Battalion size tribe of 300 adults consumes 3

So, yeah.

 

[Thunderbrd]

According to the fluff statistics of C2C, 1 Pop is 50 people, 2 pops is 100 people and, if I remember correctly, 3 pops is 250 people. And so on, it is not a logarithmic function, you get the point.

All that has not been recently updated and reconsidered and was going to become more subservient to whatever system is designed.

 

[Osk21]

This is the best Civilization Mod ever for any version of Sid Meier's Masterpiece. Thanks to All for your continued brilliant and hard work that have provided so many hours of enjoyment for me personally.

 

[Thunderbrd]

I was assuming that any units not in the tribe would still need food from the tribe, unless they were out hunting for example.

As to if we need to identify them to that degree then yes I think we do. It gives the player more control and options.

(You may have notices I did not mention or money in my description. Neither exist at the start of the game. )

Take basketry, when you get the tech that allows baskets then someone in the tribe needs to become a basket maker at some time. In this model that takes one full turn of a normal Adult's turn (or 4 gathering "slots" anyway). Then they have the promotion Basket Maker and everyone else has Baskets and get the benefits next turn. Note we could say that you need a Basket Maker per x population if we want to go that way. Which would mean that any extra population would not have the Basket promotion so would be less able to gather.

I didn't have a lot of time earlier to discuss this so made a more generic statement I hoped might convey some of my thoughts in a more condensed manner. Now that I have a bit of time:

1) I think it would be micromanagement hell to be defining every role in the tribe. I'd prefer to not have to think about the accounting of how many are children, how many are women etc... and would think it would be more pleasant gameplay to allow a lot of that to be beneath the resolution of detail that needs to be considered. Yeah, it would give more options, but it would also give a lot more demand to track each and every person and at the point that the tribe becomes a city, that resolution of interaction would be lost and would be a bit jarring. Besides that, it begs for huge adaptations to AI to go that route, basically an entire game's worth of new features to work with... *shudder*. I'd much rather see us do something that works a bit more simply at first and if we want to start digging deeper into further depth, fine, but we've gotta do this in steps away from the game we basically have. If we make too many new dynamics with this then it will quickly become an unviable project so we really have to be thinking in much more minimalist terms as modders here to adjust the game but not trying to write an entirely new one. Determining how many people are basket makers would be getting far too into the weeds of complexity imo.

2) I would really like to be able to simply make the buildings we have convert over to either promotions that can be purchased with accumulated production or improvements that can be placed by gatherer units (and potentially even the tribe could be made capable of building some plot improvements as well (with production expense rather than by spending a lot of time there.)) In this way, a player of the core game without this option would be able to easily relate to the roles and purposes of these buildings and improvements.

What would be an improvement? Berry Bushes. Adds an extra food production to the plot. Consider it a 'seed gathering camp' but I was thinking it might be more that berries becomes a resource and it's not actually placing an improvement to place berry bushes but rather placing a very lowgrade 'bonus' on the plot. When a city is placed and the plot with Berry Bushes becomes part of the city's territory by ownership, the berries vanish on the plot and become the berry bushes building in that city. Yes, more than one can be placed, indicating the people have been planting these berries along their migration routes so that the next time they return to that plot to collect from it, it's a more food productive plot. This sort of thing would be the early equivalent of agriculture basically.

A canoe builder's hut might be an improvement. When on that plot, the canoe units may be purchased, and the plot acts like a fort that allows for naval units to coexist with land units there. This is how the tribe would be able to build some boats that could take them to other landmasses.

What would be a promotion (building type)? Community discussions for example. Basket Weavers was a good example (we called it recently a basketweaver's hut).

I was thinking we'd go through all buildings and determine which becomes a promotion and which becomes an improvement or some other plot item that can be placed. When a city is planted by the Tribe at the point it qualifies to do so and the mission is undertaken at the desired plot to place the city, these promos would have a tag that indicates what building they automatically add to the city. Until then, they operate by giving the unit whatever tagged benefits the unit needs to get the benefit of. (part of why this becomes a major undertaking of new tags specifically for units and only for Nomadic ones - to which I'm really trying to follow the interesting tech discussions but it went off the rails of what I understand VERY fast. I need to get back to looking at all that and trying to figure out exactly where it loses me and try to start learning what it's all suggesting.)

Yes, it's good that a unit can track it's properties so there is a lot that can be done to replicate how that works on a city in comparison to how it works on a unit.

3) I do believe that not all buildings would have to have the same effect as they do in the core game, but perhaps some very much would. In the basket weaving case, just having the promotion should indicate that a percentage of the people know and take part in the weaving of baskets enough to have the promotion, which is giving the tribe more capacity to hold production and food and more capacity to gather yields. Additionally, the promotion should become available or automatically given to gatherer units, enabling them to grab more and deliver more to the tribe, and to hunters so they can carry more of the food they collect before having to return to the tribe to deliver that food they've collected - these units would consume from their own upkeep before adding to the upkeep expenses the tribe consumes that round - in fact, this whole food supply concept could then easily become a major supply line mod for ALL units throughout the whole game, which is a big part of why I wanted to work on developing that for merchants first before diving too far into Nomadic dynamics.

4) Although a few factors on some units would change or require updates, such as making sure city defense and attack mods apply to any plot where a tribe is, fundamentally, the units we have would not. We'd have the same warrior types and the same costs to produce them (maybe updated to cost part of the population in the tribe and updated so that their food upkeep needs are paid for by the tribe that they are a part of IF there is not a local source - they should be capable of feeding themselves off the land as well, to limits obviously, and if we don't let them collect, we can always send gatherers and hunters with armies to help support them, which should be a rather fun side of maintaining war parties I think.) Again, like with buildings, this becomes the way that we easily integrate this mod into an option that can co-exist harmoniously with the core.

5) If we want to work with specialized roles, perhaps we could do something along those lines with a system sorta like specialists, maybe where each specialist represents 10 people or something and for every 50 people in the tribe you get 1 to assign, something like that. However, this would again require a LOT of very complex AI work. I'd like to see us at least try to put something together that doesn't require that much management first and then perhaps we could add another sub-option that adds that dynamic. It might be necessary anyhow to help us with the GP system in relation to tribal dynamics.

 

[Osk21]

this is where I am at now....