Gedemon's Civilization, development thread

@Teiwaz93

You mean unstack the population from cities to tiles ?.

well yes ... each worked tile would could have a certain amount of population and the city itself would do so both giving different modifiers or other bonuses based on their size

vanilla civ always sort of gave the impression all citizens were living in the city center and then go out into city vicinity to work which isnt accurate ... there was citiyfolk and there was rural populace and if we could implement something to represent that i think it would be great and might even open up a lot of different other opportunities
 
well yes ... each worked tile would could have a certain amount of population and the city itself would do so both giving different modifiers or other bonuses based on their size

vanilla civ always sort of gave the impression all citizens were living in the city center and then go out into city vicinity to work which isnt accurate ... there was citiyfolk and there was rural populace and if we could implement something to represent that i think it would be great and might even open up a lot of different other opportunities
I agree for the most part. Above all it never made much sense to me that your Builders/Workers would build improvements on tiles, before you have population (workers) to assign to the tiles Then the improvements deliver a standard/fixed yield irregardless of how much or little it has been used previously. Actually, the Civ 4 improvement of "Cottages" was interesting for this reason. You could develop it into a Hamlet/Village/Town, simply by working the same tile for many turns. Of course a mine doesn't necessarily collapse just because operations have ceased for some time, but on the other hand you need to invest time and effort to start digging those tunnels and find minerals.

Another idea for tile improvements
It would be really interesting for example to replace the Vanilla system of improvements with a more dynamic system. All tiles could be improved the longer/more intense you work them. If you assign "citizens" to a tile, that tile will improve over time. If the tile has a resource like Iron then your mining operations would expand over time, and yields would increase due to workers becoming more skilled and mining techniques would improve (spreading to adjacent tiles) or to other mines in the same city. One way to speed up the development process could be to assign more citizens to the same tile, or you could work a project in the city, for example: "Expand mining industry". Additional ways to speed up development could be:
  • working more tiles of the same type/resource
  • simply having neighboring cities and/or Civilizations with more advanced tile-developments
  • researching beneficial technology
The biggest problem I see with this system, is how you would control what the tiles are actually producing. Would you still use the Builder unit to build an initial improvement (lay the ground work)? Or would you be able to choose some other way? Otherwise tile development could be determined automatically by city needs or by the resources on the tile in question. Example: if the city needs food then all tiles will develop their farming. Maybe you could even have several improvements on the same tile, but the share of labour for each improvement is determined by City needs.

Also, if you could implement population being distributed to tiles, then each tile could have their own demands for food, needing to met in order to increase extraction of resources/development of other yields.
 
Last edited:
@Knasp

Thanks, a lot of good suggestions, I like them.
Glad to have something to offer.

Barbarian units could also somehow be linked to mercenaries (roaming and looting the map when not under contract), if we can make less agressive barbarian units (ie non-suicidal)
Yeah, that's really neat. Barbarians never crossed my mind. Actually, if you want to you wouldn't need to disband the mercenary unit once the contract runs out. Just turn the unit into a barbarian ^_^

Quick summary, please correct me if I've forgotten something:

Standing Army : unit construction in city, from "personnel" reserve and equipment stock - medium upkeep cost, no auto-disbanding (I need to think about the opportunity to create an "officer" reserve, something I'm pondering since R.E.D. WWII)
Conscription: construction of a one-turn "building-project" spawning unit(s), mostly from "lower class" population, unit type dependant of population classes and available equipment, % from each classes could change with policies, low upkeep, (low) turn limit before disbanding
Mercenaries: buying a "building-project" spawning unit(s), unit type dependant of nearby civilizations context (or/and the mercenary group history), no resources required, high upkeep cost, (medium) turn limit before disbanding

Now, do you think that you could try to include that information somehow in the units table ? Eventually with an estimation/guess of the number of "personnel" required in an "unit" ?

For reference, we'll use division-sized units in latest eras, (ie 5,000 to 10,000 personnel in an "Infantry Divison" units), but lower values for the first units (50-100 for example in a "Hunting Party" ?)

We'll need some kind of progression on which the general balance of the mod will be based (production, growth, ...)

And propositions for unit's "organization" names (could/should change based on the civilization ethnicity ?) are welcome :)
Is there an easy way to make a table in a forum post? Otherwise, I'll probably just do a google sheet.
The hardest part isn't really to gather information about a specific Civilization, specific soldiers and equipment. The problem comes when trying to generalise the information into unit categories, and determine how/when units should be upgraded/replaced.

Anyway, I'm gonna look into info on unit sizes/organization etc.
 
Last edited:
Just a couple things. One question is, what is the purpose of prisoners? I read early on that they may end up being slaves or in later periods may be able to be traded back to you but do they serve any purpose right now? Also with combat, am I to assume with what you are doing with weaponry and armour that combat is to be tougher? I had a warrior against a barbarian spearman and basically it healed up enough every turn that it was a constant back and forth with my warrior in forest healing and attacking and the spearman healing and attacking me and neither of us got anywhere until I got a slinger into the mix and then I made progress and took it down. Attacking a civilization also feels much tougher than it was, which isn't bad. But pacing wise, it almost seems like the pace of how time goes by needs to be slowed a bit. I wasn't able to really get any headway onto getting my second city until late in the BC timeframe due to attacks by civs and barbarians, not to mention getting negative growth and having to do something about that.

Overall though it's a nice change from the standard game so far and am looking forward to seeing what is coming next.
 
With one of heinous_hat's posts that had made me curious about the potential of urban/rural population, and now Teiwaz93's post, I've put some more thoughts using your suggestions about unstacking population from cities, so here is a possible design (including cultural diffusion rework):

  • Cultural diffusion as it is currently implemented (ethnicity strength on a tile, assuming there is an undefined number of rural population on each non-city tile, with diffusion rules based on terrain/road/rivers and culture "build" in cities) is completely removed
  • Instead of a "culture map" with strength value for each "culture group" (aka "ethnicity" in most case, including "dead" civs, but also separatists) on a tile, we have 4 values (upper, middle, lower, slave classes) for each culture group
  • Instead of "culture diffusion", we have "migration/colonization/settling" happening each turn from one tile to all adjacent (non water) tiles
  • This automated settling will follow the basic diffusion rules (faster along roads/rivers, slower over/through mountain, hills, jungle, forest, ...), with new factor like tile's Appeal
  • Define a "global" culture value for a civilization, then use it to calculate "conversion rate" from culture groups with lowest values to those with higher values (also using policies, tile's ownership as factor) on each tile (with special rules in cities/districts based on buildings)
  • "Separatists" would be a culture group to which a part of all other culture groups that are far from their capitals (distance modified by eras/policies) will be "converted"
  • Same as current cities, tiles will have "size" value, using the same formula, currently it's population = math.pow(size, 2.8) * 1000
  • The current tile's base output values (yields, resources collected) will define the "size 1" output value. The real output is based on the % of required population already on the tile to reach size 1
  • "Size x" tiles would provide (size 1 output * x) + a % of size 1 output based on the percentage of required population already on the tile to reach size x+1 from size x
  • A population threshold (and under size 1 I think) will be required for a tile to be owned outside a city range
  • Ownership is defined by the culture group with the higher total % of population (pondered by population classes)
  • No threshold required for ownership in range of cities, but the 2 outer rings will be unlocked either by era, tech or building (or the population threshold if it happens first)
  • A city "size" would include the urban population and all the rural population of the tiles owned by that city (which may include tiles farther than the third ring)
  • The reason being that city size determine the available "citizen" to place on slots, and it's actually hardcoded in the game
  • The placement of citizen on the map's slots (using the current UI) will raise a tile's appeal related to population movement, which in turn will raise its output faster. It will also be a way to control a bit your border's expansion direction
  • Output of a tile with an assigned citizen slot will be higher, but (opposite to the current mod's code) the resources collect/extraction cost will also be higher (you're "demanding")

What I still need to define:
  • population growth formule on tiles without ownership ? (using owning city stocks/formule for the other)
  • housing values (population limit) based on terrain/feature/improvment for each classes ?
  • employment values on tiles (improvements) or buildings being a factor for tile's appeal ? how to correlate that value with tiles/cities size ?


And what did I forgot ?

The biggest problem with the above design (outside coding time), is the risk of introducing major lag in late game, the cultural diffusion mod was causing some in end game for civ5 until I've converted the code to C++ after the DLL source was released.

The Lua scripts in civ6 seem to run faster than 5 as I said, but we're introducing 4 more variables for each tiles on the map (cf the serialization problem I've mentioned for units data) and someonewhoknowhismathmayknowexactlyhowmuch more calculations per turn.
 
Last edited:
Is there an easy way to make a table in a forum post? Otherwise, I'll probably just do a google sheet.
The hardest part isn't really to gather information about a specific Civilization, specific soldiers and equipment. The problem comes when trying to generalise the information into unit categories, and determine how/when units should be upgraded/replaced.

Anyway, I'm gonna look into info on unit sizes/organization etc.
Go for the google sheet :D


Just a couple things. One question is, what is the purpose of prisoners? I read early on that they may end up being slaves or in later periods may be able to be traded back to you but do they serve any purpose right now? Also with combat, am I to assume with what you are doing with weaponry and armour that combat is to be tougher? I had a warrior against a barbarian spearman and basically it healed up enough every turn that it was a constant back and forth with my warrior in forest healing and attacking and the spearman healing and attacking me and neither of us got anywhere until I got a slinger into the mix and then I made progress and took it down. Attacking a civilization also feels much tougher than it was, which isn't bad. But pacing wise, it almost seems like the pace of how time goes by needs to be slowed a bit. I wasn't able to really get any headway onto getting my second city until late in the BC timeframe due to attacks by civs and barbarians, not to mention getting negative growth and having to do something about that.

Overall though it's a nice change from the standard game so far and am looking forward to seeing what is coming next.

Yes, the pace will be changed to reflect the mod's mechanisms.

The prisoners/slavery mechanism is needing a base to work on, and as we're redefining the population classes ATM, it's waiting for that to be done first.
 
Really like the ideas for rural areas! Also wanna quote a post I made in this thread earlier today in the wide vs tall discussion, where I went into some detail (well... some... I think it's a serious contender for longest post ever on this site) on what I feel like would be a good way to balance city size versus number of cities, being able to unlock special rewards for growing big cities, but requiring smaller cities to send food towards such big cities. I figure it might be a valuable contribution to the population etc aspect of this mod, though the post is, of course, written with the base game in mind. It's in the spoiler, and be careful, it's a long read.

Spoiler :
Basically, the idea is as follows: Larger cities can do things that smaller cities cannot, and not simply in being bigger and being able to build more, but in opening up new options, instead of being able to select more of the same options. I want to add the idea of the pyramid (mentioned earlier in this thread) to that, as the core of an empire is indeed often sustained by the rural areas, and I also want to call back to a discussion before the release of Civ 6, where it was said that the "wide vs tall" might be replaced by "urban vs rural".

Before going into detail, one of the biggest advantages for a system like this, in my opinion, is that it does not penalize a player for making a choice, be it "building a new city" (wide) or "growing a city" (tall). Instead, it grants bonuses depending on what you choose - the only penalty is not unlocking something because you're choosing for something else, which feels very different from a player perspective.

Now, going wide already unlocks things: Most importantly, it unlocks the ability to grow more cities, and to build more units and buildings at the same time. In Civilization VI in particular, it grants the advantage of being able to build more districts of the desired kind; after you've built a campus with the at-that-point-available buildings, there's no way to further increase the science in the city (excluding the minor science per pop), except building a settler and building another campus in that new city. Going tall, however, unlocks relatively little: only said minor amount of science and culture, as well as some tile yields, though this tends to be insignificant apart from the production yield, which you can of course convert into all kinds of other things. To add to that, population growth in Civilization VI is relatively slow; I, at least, barely ever get the eureka's related to "largest city"; only Early Empire I do normally get, and I typically have 2 cities already at that point.

So, there needs to be a bonus for having bigger cities, to balance against having more of them. As @universecreep mentioned (or in fact started the thread with), a good idea to do this is to add bonuses to big cities, is to make them population-restricted; this basically solves all problems that a system might have at once: It cannot be accessed by just spamming cities (which would defeat the whole purpose), it can be explained flavour-wise (smaller cities cannot support such things) and it makes sense from a gameplay perspective, as it is a 'reward' you unlock by growing your city to a certain size, even if this reward still requires you to pour in production; just make it worth that production.

Now, there are two main systems possible for these bonuses, a passive, and an active system. A passive system is very simple: When you reach size X, you gain bonus Y. An active system not only requires you to reach size X, but to actually get bonus Y, you need to do something. In Civilization terms, that will most likely mean two different things. The first is to add buildings, that most likely require a district (or even two) on top of the city size requirement. The second is to add wonder-like buildings that require an own tile, but are not unique, in that more than one may be built of them. They may be limited to one per civilization, but do not neccessarily need to be. This depends both on how strong their bonuses are, and how the balance works out in practise.

As for passive systems, these may be automatic ("once a city reaches size 15, you gain +5 science, +5 culture, +5 faith, +5 production, +10 gold, +1 amenity", or a "every citizen beyond size X" version of this to reduce spiking) or may be depending on districts you have (I would like to see this part for certain, as it increases the importance of districts) and may additionally require a player choice, where you can maybe select a bonus to only one of your districts (and therefore yields). For example, a city reaches size 20 while having a Campus, Industrial Zone, Commercial Hub, Encampment and Harbor. Now, the turn this city reaches size 20, you get a choice:

(just some not neccissarily balanced ideas for what you could do)

1. +5 science, +20% science in this city.
2. +15 production.
3. +8 gold, +2 trade routes.
4. +50% production towards units.
5. +10 gold, +5 food.

Note that a deliberate part of this (at least from me) is that you cannot specialize a city towards a district you build after reaching the threshold. This makes sense from a flavour perspective in particular, as, say, a Theater Square built after would not be a historical part of the city; the cultural importance was attracted to the city after it became big, while historically, it might've been a scientific hub instead.

Now, there are two more things I have not yet addressed. These are fun ideas to incentivize (sp?) bigger cities, but they do not stop you from simply going wide first, and then afterwards going tall, and simply getting this in all your 20 cities. However, this can be solved through the other thing: The empire is not yet pyramid-formed, as cities do not really interact with one another. To change this, trade routes are split: There are now domestic traders as well as international traders. International traders are limited by harbors, commercial hubs, etc, whereas domestic traders are limited by things like the amount of cities owned. Of course, this is the basis, and there could very well be more factors, also because domestic and international trade routes no longer need to be balanced against one another, allowing more freedom to tweak.

Next, those domestic traders do not anymore generate a heap of food and production. Rather, they transport food and/or production from one city to another and generate a minor revenue (taxes over the transported goods). This allows you to build rural cities with a lot of farmland, and then send traders from those cities to your central cities, giving you the food required to turn those cities into megacities (also solving the problem mentioned in my third paragraph that cities grow too slowly) and at the same time freeing up more land in those central cities for districts, wonders and whatever else, as you no longer need to have farms locally anymore. This allows for two different playstyles: A "tall" playstyle, where you use rural cities to pump up your core cities, which turn into urban megacities with special buildings, tons of adjacency bonuses, etc. On the other hand, a "wide" playstyle, with self-sustaining cities that have a few districts at most, but all directly contributing to your empire (instead of being food silos) and being able to do stuff. It should be noted that, for both styles, more cities is better. However, a tall playstyle will still mean less need for micromanagement compared to a wide style, which (at least in my understanding) is the most important reason for people prefering tall. On top of this, it would be possible to add a way to import food from other countries, actually removing the requirement of the rural cities, which can, basically, be owned by a neighbouring civilization.

This last thing would actually bring back tall playstyle as it was before - just a few, big megacities. However, it would do so without strangling wide (as happened in Civ V), and on top of that it would require good relations with your neighbors, just like real life "tall" countries like the Netherlands (we actually got a surprising amount of farmland by the way) or Japan (who probably got a surprising amount of farmland as well, I guess).
 
I've added a few equipment classes for testing purpose, especially constructing units before having the infrastructure/tech to produce their equipment by stealing it (or from trade routes)

Updated on GitHub
Code:
- Add Spears, Bows and some Armor equipment classes
- Add Artillator and Armorer Buildings
- Remove pre-required techs for Archer, Spearman, Swordsman, Chariot
- Lower personnel requirement for all early units
- Change Standard number of game's turn to Marathon (but all production are still at standard speed)
- Remove units upgrades path (until the custom replacing mechanism is implemented)
- Add some mod-related rewards to Goody Huts and Barbarian Camps

Let me know what you think of it.
 
Nice! But are captured weapons supposed to disappear from a unit?

Playtest example:
On turn 16 my Warrior/Clubsguy captured 63 wooden spears from a Barbarian Spearmen (they went to Rear instead of Front?). I finished building a Spearman unit some turns later in my city and there was no transfer of spears happening during production or when the unit was finished.
But on turn 22 (6 turns after capture) the 63 spears disappear from the unit. They seem to be transferred to the city. Because the city stock says +63 spears.
Edit: In fact I seem to be able to build Spearmen units without having spears in stock. They are fully equipped with spears regardless.
Edit: Horses can't be captured, but I guess that's to be added eventually?
Edit: Melee units can't capture ranged weapons (Wooden bows)?

Also, maybe you could hinder the barbarians from spawning horsemen and horse archers so early in the game? Standard speed, 31 turns in, 3550 BC. Or maybe I should play at a slower speed?

/Otherwise I'm still working on compiling tables of population size, army size, unit size etc. Gonna post as soon as I've got something comprehensible to show.
 
Last edited:
Thanks, yes, seems that I have introduced a few bugs with the last serie of updates, I had some too in my playtest, I'll have a look at the logs.

The horses are not captured yet, I forgot about them, but capturing them was planned (and still is)
 
I just had a thought about automatically reclassifying units or automatic "upgrading".

Just throwing it out there:
What if the class (base stats/combat role) could be altered due to cicumstances?

For example: if a Warrior/Light Skrimisher unit captures spear and shields enough to outfit >50% it is automatically upgraded into a Spearman unit?

Basically you could have a system where a unit's class/base strength is re-evaluated due to the current equipment and experience?

Or maybe unit type should be independent of equipment level (armor and weapon metals used etc) and have more to do with training/organisation/tactics/combat role. I.e. you could have classes like:

  • Skirmisher
  • Skirmisher Cavalry
  • Infantry
  • Shock cavalry
  • <!-- Elite infantry (For breakthrough/Holding the line)?-->
  • Artillery
Ships could have similar types or simply use embarked units (requiring sailors/oarsmen personnel in the Rear for rowing the ships)

The class would be determined by the number of horses (or later vehicles), and composition of weaponry. A unit where a majority of the soldiers has ranged weapons will be classified as Skirmisher. If they have >66% horses they are upgraded to Cavalry.

An Elite unit can be obtained by gaining XP or special training. Or maybe skip the Elite class alltogether and just leave XP and promotions.

A unit with spears and ranged weapons will prefer skirmishing. A unit with spears and shields will prefer Infantry role. A unit with spears shields and bows will prefer shirmishing.
A unit with spears, shields and armor will prefer Infantry.
A unit with horses will prefer Cavalry if enough horses are in stock and they have time for training (maybe retraining for X turns).

However lack of training would influence a unit's requirements for changing its combat role/unit type. I.e. if soldiers are trained using a spear and shield, they won't start using bows without good reasons. Maybe a promotion awarded upon recruitment and also social policies, depending on unit type, could alter requirements. A cavalry skirmisher will have an easier time switching to foot-skirmisher (when they lose horses), while a foot-skirmisher will be more inclined to keep staying on foot (due to lack of training). A unit trained to use bows, won't start fighting in melee just because they capture swords and armor. (Rather their melee defense will increase)

A modern example could be a Mechanised infantry division being downgraded to a Motorized infantry div. when the share of armored vehicles are 50< %. Regardless of the types of personnel weapons or how many anti-tank cannons they carry.

The benefits to the system above is that you could have the same unit classes through the entire game. The only changing parameters would be equipment and horses/vehicles.
 
Last edited:
That's a concept that makes a lot of sense at the scale of the game, and what I want to do with equipment will allow parts of it when coded.

We have a kind of "same unit classes through the entire game" in the current design: units attributes will change depending of the different equipment types they got in the classes they are allowed to use. For a late game example, imagine the equipment "torpedoes" being part of the ammo classes available for an attack aircraft unit.

The Skirmisher / Skirmisher Cavalry / Infantry / Shock Cavalry / Artillery are the upgrade lines, the change of "equipment class" in a line will only occur in late game with the infantry/skirmishers having access to firearms and later the horses being replaced by motorized vehicules.

The actual implementation is based on the existing civ6 units, not what we'll have in the final mod. For example, I've designed the "blunt weapons class" as a placeholder to test the code using the "warrior" unit of civ6, but we could have some "Pre-firearm Infantry weapon classs" and "Firearms Infantry weapon classes" that would be enough to cover the whole game's length for the Infantry line (wich could have 3 sub-classes that we don't have actually, ie professional army, mercenaries, mobilized population)

The "upgrade" representing the organizational change of an unit (more personnel, faster resupply, etc...), without changing its equipment class.

Technically, it would be possible to allow switching to one class to another depending on the circumstances, but I'd prefer to keep the choice of the current units specific role under direct control (by producting/hiring/conscripting in cities)

It's true that an unit that has not enough equipment of a class to heal does not heal until it gets that equipment, in turn that could lead to waste of other resources (especially if that unit is killed), your solution would prevent that (and also has the advantage of dynamism, and would not require any AI coding)

Now, what I'd like to do is to allow adjacent units to directly exchange personnel/materiel/equipment (for example, an unit A with captured equipment required by unitB could transfer that equipment allowing B to "heal")

An alternative to your idea would be that in some cases (enough personnel available, some equipment available but unusable for that unit, and none of the required equipment available) "split" the unit.

Say an infantry unit with captured bows but no access to blunt weapons (or the other weapon classes it could use) and more personnel that it can possibly send in front line with the equipment left (that surplus in personnel could come from cities if it's only the weapons supply/production line that is cut, or from healed wounded or bonus personnel from goody huts or liberated prisonners...) could automatically create a skirmisher unit out of those resources in excess, the health of the new units being relative to those values.

The two mechanisms above would prevent some waste of resources, without changing the role of any pre-existing units but still allowing your army to automatically adapt (a bit) to circumstance.
 
Last edited:
Technically, it would be possible to allow switching to one class to another depending on the circumstances, but I'd prefer to keep the choice of the current units specific role under direct control (by producting/hiring/conscripting in cities)
[...]
The two mechanisms above would prevent some waste of resources, without changing the role of any pre-existing units but still allowing your army to automatically adapt (a bit) to circumstance.
Sharing equipment and splitting units both seem like viable solutions/complements. But if splitting up means that the resulting units are weaker (since they fight alone?) then it could screw up your strategy. Regarding unit type flexibility, I just thought it would make sense for the units to adapt to it's current situation. For example: if they're being harassed by chariots or horse archers, trying to charge them with melee weapons instead of using backup slings/bows would probably be a waste of time and lives.

Maybe captured weapons could offer a unit tactical bonuses/adaptibility (at least for defending themselves), even though the unit's type/class is retained?

And finally, a difficult question regarding scale and design of warfare:

The issues we're discussing are dependent on which geographical and time scale the mod is supposed to simulate. Civ-games have always been rather flexible about scale. You've mentioned earlier that ideally a tile would represent about 10000 km2 or 100 km distance (center to center). But if the military units are to operate on a similar scale, then your army and/or all your units would generally occupy the same tile (like Civ 4's stacks of doom).
But if the scale is to be maintained along with 2 UPT, that would mean you'd have your army divided into 2 parts, the ranged and the melee part (artillery and cavalry w). Another way is to continue the path of Civ 5-6, and have warfare operate on a parallel and larger scale (simulating a smaller battlefield/land area).

I've been pondering about these questions for some time, and I believe that they are highly relevant for the design of Units and Armies, and especially how we want combat to be represented.
 
Last edited:
I'd like to have something like 4 to 6 (combat) UPT in late game (2-3 "division"-sized, 3-4 "regiment"-sized, we could even have n-UPT when n is based on the "size" of the units), a kind of middle ground, to avoid both stack of doom (or having each unit representing an army groups) and archer firing across the Mediterranean sea... DLL access will be required, so we'll test on 2UPT until then, but the design should be for 6UPT (again, late game, say 2-3UPT at start)

We have to manage the fixed scale of the map (even if having the map scale changing by era is an idea that is lingering in the back of my head since some time now) and the evolution of military organisations and conflict during 10,000 years... we need to keep some flexibility :)

About splitting, the units won't be weaker in that scenario, the new unit will always been made from the "reserve"/"rear" of the initial unit, which will keep it's actual "frontline" (and that's the "health" value of the unit, if the first unit is at 25HP, it will still be at 25HP after the split), what we'll be doing is taking the part of the unit that can't reinforce the "frontline" because of lack of equipment and make another unit that can fight alongside the first one, instead of waiting to be captured/killed when the last elements of the frontline collapse (spawning a small barbarian unit from the reserve of a defeated unit would also be possible BTW)
 
Last edited:
GitHub updated
Code:
Set PrereqTech to Military Science for Encampment
Set PrereqTech to Industrialization for Industrial Zone
Set PrereqTech to Mass Production for Shipyard (not available for construction ATM)
Set PrereqTech to Castles for Fort improvement
Fix bug with city production crashing before removing used resources for some units (allowing construction without supply)
Add Horses capture from units

I'll try to make a little something for the barbarian units (before a complete rework)
 
Update on GitHub:
Code:
Add buildings: Treadmill, Windmill, Fruits Market
Balance some buildings cost
Tweak Tech tree
Use the same kind of priority request of units for resources that are required by an item in the build queue of a city
Add a small Barbarian replacement function for early ages, you can still get a few barbarian swordsman in ancient age (30% to b precise), but, hey, you do get swords when looting camp...
A few bug fixes
 
Update on GitHub
Code:
economic tweaks, to correct a few bugs in transfer:
- raise max variation per turn percent (25, was 15)
- raise values to calculate max/min cost from base cost (x10, x0.1, was x4, x0.25)
- make transport cost a percentage of the current cost, not just a fixed value based on distance

I'm going to use Knasp's method for the upgrades in an unit's line, I'll try to code a prototype with the current units.

Basically, the equipment class of the unit will include every equipment it can use from start to finish, the units are already requiring equipment based on their "desirability" (that was coded as part of my old design, which was based by type -ie "Swords" or "Blunt weapons", I didn't thought to use it on a bigger scale, ie "Wodden Club" to "Assault Rifle"...), and once it has a majority of equipment defining an unit "type", it will upgrade (or downgrade) to that type (assuming it has enough personnel/materiel to do so)

It's more elegant to my previous design which would have been to request the equipment needed for an upgrade, store it in reserve, then upgrade once enough equipment is stored.

It should also be (relatively) easier to code, and, as you've pointed, has the advantage of allowing the unit to benefit of the new equipment bonus (relative to % equipped) before the upgrade.

We'll just need to have a smooth enough transition in number of personnel/materiel required by an unit type to allow a lower type to upgrade to the new type without loosing too much "health", basically the "reserve" + frontline personnel of a previous unit should always be bigger (or at least not much lower) than the frontline personnel of it's upgrade type.
 
Update on GitHub
Code:
economic tweaks, to correct a few bugs in transfer:
- raise max variation per turn percent (25, was 15)
- raise values to calculate max/min cost from base cost (x10, x0.1, was x4, x0.25)
- make transport cost a percentage of the current cost, not just a fixed value based on distance

I'm going to use Knasp's method for the upgrades in an unit's line, I'll try to code a prototype with the current units.

Basically, the equipment class of the unit will include every equipment it can use from start to finish, the units are already requiring equipment based on their "desirability" (that was coded as part of my old design, which was based by type -ie "Swords" or "Blunt weapons", I didn't thought to use it on a bigger scale, ie "Wodden Club" to "Assault Rifle"...), and once it has a majority of equipment defining an unit "type", it will upgrade (or downgrade) to that type (assuming it has enough personnel/materiel to do so)

It's more elegant to my previous design which would have been to request the equipment needed for an upgrade, store it in reserve, then upgrade once enough equipment is stored.

It should also be (relatively) easier to code, and, as you've pointed, has the advantage of allowing the unit to benefit of the new equipment bonus (relative to % equipped) before the upgrade.

We'll just need to have a smooth enough transition in number of personnel/materiel required by an unit type to allow a lower type to upgrade to the new type without loosing too much "health", basically the "reserve" + frontline personnel of a previous unit should always be bigger (or at least not much lower) than the frontline personnel of it's upgrade type.
Cool, really looking forward to try it out!
Btw, I've been looking at population sizes and the share of urban/rural population through history, because I'm intending to weigh on the discussion about moving population out from the cities. But now I feel that I really ought to get back to looking at army/unit sizes again, and looking into the military tree ;)
 
Update on GitHub
Code:
economic tweaks, to correct a few bugs in transfer:
- raise max variation per turn percent (25, was 15)
- raise values to calculate max/min cost from base cost (x10, x0.1, was x4, x0.25)
- make transport cost a percentage of the current cost, not just a fixed value based on distance

I'm going to use Knasp's method for the upgrades in an unit's line, I'll try to code a prototype with the current units.

Basically, the equipment class of the unit will include every equipment it can use from start to finish, the units are already requiring equipment based on their "desirability" (that was coded as part of my old design, which was based by type -ie "Swords" or "Blunt weapons", I didn't thought to use it on a bigger scale, ie "Wodden Club" to "Assault Rifle"...), and once it has a majority of equipment defining an unit "type", it will upgrade (or downgrade) to that type (assuming it has enough personnel/materiel to do so)

It's more elegant to my previous design which would have been to request the equipment needed for an upgrade, store it in reserve, then upgrade once enough equipment is stored.

It should also be (relatively) easier to code, and, as you've pointed, has the advantage of allowing the unit to benefit of the new equipment bonus (relative to % equipped) before the upgrade.

We'll just need to have a smooth enough transition in number of personnel/materiel required by an unit type to allow a lower type to upgrade to the new type without loosing too much "health", basically the "reserve" + frontline personnel of a previous unit should always be bigger (or at least not much lower) than the frontline personnel of it's upgrade type.
This looks really cool. I wonder if you could use the same mechanic to add say man portable anti-armor weapons to infantry units or add pikes to musketmen to create a pike & shot unit.
 
This looks really cool. I wonder if you could use the same mechanic to add say man portable anti-armor weapons to infantry units or add pikes to musketmen to create a pike & shot unit.
Good idea, in this mixed-equipment system you could add hybrid units, that are specifically equipped with both weapons (musket/arquebus + pike) upon recruitment. The prerequisite would be technology and production of both kinds of weapons, along with maybe a project?
 
Back
Top Bottom