Quick Questions , Quick Answers

What's the current (rough) plan for HERITAGES?
Replace buildings that cannot be in one city without being in all cities with a nationwide object separate from buildings applied to player objects rather than to city objects.
This to improve performance and reduce memory usage and later expand to open up new possibilities for interesting new content.
 
Replace buildings that cannot be in one city without being in all cities with a nationwide object separate from buildings applied to player objects rather than to city objects.
This to improve performance and reduce memory usage and later expand to open up new possibilities for interesting new content.
GOOD.
 
Unrelated question:
Is unit merging a coded mechanic, or can it be modded for more variations?
Starting with something as banal as "mass-merging" (merge 81 units in one click, ya know).
Though I'm rather daydreaming about "unit type merging", lol.
Basically, making it possible to create "unit parties" comprised of several unit types, but behaving (and thus consuming memory) like a mere singular unit.
You already have tons of unitcombats (or whatever you call "melee" and "English", lol), so it's not too big of a leap to allow mixing them into one unit.
That would immensely reduce the memory consumption, since you'd have a single unit that has 10 unitcombats(?) and can act as any of them, depending on the situation.
Just daydreaming, yeah.
 
Unrelated question:
Is unit merging a coded mechanic, or can it be modded for more variations?
Starting with something as banal as "mass-merging" (merge 81 units in one click, ya know).
Though I'm rather daydreaming about "unit type merging", lol.
Basically, making it possible to create "unit parties" comprised of several unit types, but behaving (and thus consuming memory) like a mere singular unit.
You already have tons of unitcombats (or whatever you call "melee" and "English", lol), so it's not too big of a leap to allow mixing them into one unit.
That would immensely reduce the memory consumption, since you'd have a single unit that has 10 unitcombats(?) and can act as any of them, depending on the situation.
Just daydreaming, yeah.
I had the idea once of defining 'chimera' units that were blends of 3 different types and you'd be able to merge 1 of each type into the one larger chimeric unit. I figure it's a 'someday yeah probably' kind of thing that definitely comes long after the current unit review project. Obviously you could split one down as well. There's a few other ways to get added unit teamwork interactions I want to implement first at some point before even that though.

Anyhow, yeah considered in the dreams of distant future projects.
 
I had the idea once of defining 'chimera' units that were blends of 3 different types and you'd be able to merge 1 of each type into the one larger chimeric unit. I figure it's a 'someday yeah probably' kind of thing that definitely comes long after the current unit review project. Obviously you could split one down as well. There's a few other ways to get added unit teamwork interactions I want to implement first at some point before even that though.

Anyhow, yeah considered in the dreams of distant future projects.
My question is, whether this needs literal newly written from scratch code, or maybe it can be done more "manually"?
Like, maybe by fiddling with Git values or something (obviously it's not a mere xml issue, as much as I'd wanted it to be so)?
As opposed to quite literally coding Python or DLL, which I won't even look at.
 
My question is, whether this needs literal newly written from scratch code, or maybe it can be done more "manually"?
Like, maybe by fiddling with Git values or something (obviously it's not a mere xml issue, as much as I'd wanted it to be so)?
As opposed to quite literally coding Python or DLL, which I won't even look at.
Oh no... that'd be WAY complex coding stuff to enable this, plus defining the valid unit blends as unit types of their own.
 
Oh no... that'd be WAY complex coding stuff to enable this, plus defining the valid unit blends as unit types of their own.
Why "types of their own"?
Can't a unit be BOTH "melee" AND "ranged" (or "English" AND "French", lol), since both are simply "subcategories" now, as opposed to "strict types" back in vanilla?
For example, Heroes have a whole range of different "additional subtypes", yet ALL of them have the Hero functionality, and I "really doubt" you created "personal" subtypes for each Hero.
So you CAN combine separate subtypes into a single unit, no?
I took a look at XML aaand:
Code:
 <Type>UNIT_EXILE</Type>
 <iMaxPlayerInstances>2</iMaxPlayerInstances>
 <Special>SPECIALUNIT_PEOPLE</Special>
 <Combat>UNITCOMBAT_CRIMINAL</Combat>
 <SubCombatTypes>
  <SubCombatType>UNITCOMBAT_MELEE</SubCombatType>
  <SubCombatType>UNITCOMBAT_THROWING</SubCombatType>
Lol, "MELEE" and "THROWING" in one unit, already.
And I'm sure there's a lot more like this.
The programming point would be then to ADD subcombat types, not FIND them.
Sure, I have no idea HOW to do so, but it wouldn't break the game at all, since units with multiple "contradictory" subcombats already exist.
Damn, I WANT THIS!
 
Why "types of their own"?
Can't a unit be BOTH "melee" AND "ranged" (or "English" AND "French", lol), since both are simply "subcategories" now, as opposed to "strict types" back in vanilla?
For example, Heroes have a whole range of different "additional subtypes", yet ALL of them have the Hero functionality, and I "really doubt" you created "personal" subtypes for each Hero.
So you CAN combine separate subtypes into a single unit, no?
I took a look at XML aaand:
Code:
 <Type>UNIT_EXILE</Type>
 <iMaxPlayerInstances>2</iMaxPlayerInstances>
 <Special>SPECIALUNIT_PEOPLE</Special>
 <Combat>UNITCOMBAT_CRIMINAL</Combat>
 <SubCombatTypes>
  <SubCombatType>UNITCOMBAT_MELEE</SubCombatType>
  <SubCombatType>UNITCOMBAT_THROWING</SubCombatType>
Lol, "MELEE" and "THROWING" in one unit, already.
And I'm sure there's a lot more like this.
The programming point would be then to ADD subcombat types, not FIND them.
Sure, I have no idea HOW to do so, but it wouldn't break the game at all, since units with multiple "contradictory" subcombats already exist.
Damn, I WANT THIS!
That's not the only factor to blend. Not even close. Also right now I'm working on establishing some rules that will make things more balanced in cases with multiple primary unitcombats. Also will look to have combat potentially shift at times and phases from one type to another, so for example, mounted/melee, may keep mounted at the beginning and end but not during the middle. It's gonna get more complex.

Anyhow, blending units is not so trivial as you're hoping.
 
That's not the only factor to blend. Not even close. Also right now I'm working on establishing some rules that will make things more balanced in cases with multiple primary unitcombats. Also will look to have combat potentially shift at times and phases from one type to another, so for example, mounted/melee, may keep mounted at the beginning and end but not during the middle. It's gonna get more complex.

Anyhow, blending units is not so trivial as you're hoping.
I can imagine. Kinda a pity, would've been really cool AND would reduce memory consumption drastically.
 
I can imagine. Kinda a pity, would've been really cool AND would reduce memory consumption drastically.
Probably would NOT reduce memory consumption since it would mean more unit definitions which all stay in memory from the moment the mod is loaded.
 
Probably would NOT reduce memory consumption since it would mean more unit definitions which all stay in memory from the moment the mod is loaded.
My point is that you'd be able to combine tons of various separated units into multi-type single units, which clearly reduces memory consumption based on the total number of active units.
Kinda like allowing much higher limits for unit merging earlier, but potentially in such a way that the result would exceed the equivalent of merely "later era" merging.
Example:
You have 9 units during Prehistory.
If it's 9 Macemen, your best memory saving is to make them into 3 Macemen x3 - this is 3 units total.
Now, my point is that if you have 3 Macemen, 3 Slingers, and 3 Dogs - you could potentially "platoon" ALL of them into a single New_Name unit that actually has the "power" of all 9 of them.
Thus, instead of 3 units, you'd have only 1, but covering for all 3 of them in warfare (somehow).
Taking this into HUNDREDS of units and DOZENS of combined types - you'd be able to reduce UNIT memory consumptions quite drastically, without losing any firepower (again, somehow).
What now is 100 separate units of 10 different types, would become merely 10 "platoon" units of 1 combined type - for example.
And don't forget that the worst part of it is unit "thinking", which is directly related to the total number of ANY existing units, not to the total number of their types.
But, yes, this requires quite a huge leap of immersive CODING, unfortunately.
 
Just because you could condense hundreds of units down to a single unit doesn't mean it would be good design. They DID implement this solution, although in the simplest possible terms, with the one unit per tile rule in civ 5 and beyond, and it completely and irremediably dumbed down warfare. Stacks of doom are annoying, micro managing stacks is annoying, but single unit confrontations are just worse. Civ 3's armies were a much cooler idea in terms of finding a balance between fun and power.

I know you will say that one unit per tile is a completely different thing, but ultimately the gameplay outcome is the same as what you're suggesting. Besides, a merged omni-unit that can perform all unitclass roles at the same time is highly unrealistic.

Yes, dogs spam needs to be fixed and mixed units could be interesting, but stacks are ultimately what make warfare in civ 4 fun.
 
New question:
Is there already an implemented mechanic for "unit with a specific promotion is the prerequisite for something", be it a building OR a unit?
There's a Wonder with a requirement mechanic for a minimum unit level, but I'm asking about actual promotions by name.
Why?
Because, and I feel like it had been discussed in the past, I'm ruminating on the idea of "promotions leading to upgrades", be it as "another way", or ultimately as "the only way".
Basically, you can only train "grunts" that are essentially Brutes, and then you must promote them in order to actually upgrade the to better units.
This, by the way, may be a "sister concept" to the "multi-type merging", but this type via "multi-promotion upgrading", probably via subcombat types to begin with.
Basically, you promote your grunt with Swordsman AND with Archer, so you can turn it into a Sword-Archer, lol.
Either by replacing with a template (but this does lead to the problem of requiring hundreds of such templates), or merely adding the appropriate subcombats without changing its graphics.
The latter, of course, would be "problematic for the human player to easily deduce visually", so we again bump into the circular problem of "graphics and ideas, ideas and graphics".
Sigh...
 
My point is that you'd be able to combine tons of various separated units into multi-type single units, which clearly reduces memory consumption based on the total number of active units.
Kinda like allowing much higher limits for unit merging earlier, but potentially in such a way that the result would exceed the equivalent of merely "later era" merging.
Example:
You have 9 units during Prehistory.
If it's 9 Macemen, your best memory saving is to make them into 3 Macemen x3 - this is 3 units total.
Now, my point is that if you have 3 Macemen, 3 Slingers, and 3 Dogs - you could potentially "platoon" ALL of them into a single New_Name unit that actually has the "power" of all 9 of them.
Thus, instead of 3 units, you'd have only 1, but covering for all 3 of them in warfare (somehow).
Taking this into HUNDREDS of units and DOZENS of combined types - you'd be able to reduce UNIT memory consumptions quite drastically, without losing any firepower (again, somehow).
What now is 100 separate units of 10 different types, would become merely 10 "platoon" units of 1 combined type - for example.
And don't forget that the worst part of it is unit "thinking", which is directly related to the total number of ANY existing units, not to the total number of their types.
But, yes, this requires quite a huge leap of immersive CODING, unfortunately.
Problem is all the chimeric unit definitions themselves might cost nearly as much as one thinks they might be able to save over the standard SM design precedents as they are now being capable of reducing massive unit count sizes. I still wouldn't want to allow more merges than the game already does because it's not ALL about trying to streamline battles but about interesting decisionmaking. I'm looking to first lean into the team effects of having supportive other units making a difference in how your unit in combat performs as we go about assuming some elements of the other units being present would help to make things more favorable for the front unit. For example, because there's a couple other melee units to the side, throwing units just behind, and archers even further behind an attacking swordsman, as well as flanking riders to help stabilize the efforts against enemy flanking riders, and catapults behind backing up those swords as well, you'd have some influences on the lead swordsman in battle similar to the influences granted by surround and destroy. The same would help defending units as well, further promoting fully prepared stacks of teamwork designed defenses. This would support larger stacks of proper teams without having to lean into chimeric unit concepts that would ultimately mean a ton of newly defined unit types and the graphics to go with it.

Then, you'd have special promotions to help some units be better at such team support roles.

This combat mod was at least for a moment there nearly in place until it was removed because I didn't have time to finish it.
 
I think I did say that this was ONLY for "reducing memory consumption" - it's neither "more realistic" or "better gameplay".

Also, what about the other question?
 
Top Bottom