C2C - Units

I unobsoleted Guerrillas, and now Felis Superiors are unstoppable. I've autorazed about 15 cities, captured 3 or 4, and made room to found another 6 or so of my own. One of the cities autorazed had cultural defence of 450ish%, and str 100+ defenders, but with enough (about 40) FSs, it's no obstacle. They can't capture the city, which is why you need the Guerrillas. Oh and all this in peacetime. 35 FSs took down a chopper horde with strength 721. And at least half of them survive. Not that that matters because most cities can build brand-new ones with Bottleneck IV in one turn.

They really should not require the Prehistoric unique wonder. It won't help with a runaway tech leader, but the first thing that needs to happen is, they need to be trainable by everyone.
Interesting points. One thing that is currently lacking in the unit chains is advanced strike teams around that era and beyond, upgrades that would normally make them a slight enhancement rather than a GREAT one. They will be more easily balanced once that core is completed. I can see them currently being overwhelming.

Build by everyone? Perhaps... It's certainly something a prehistoric building may be too much to expect will still even matter by then. Will consider this further.

Another factor is that units themselves aren't all that well balanced by this time in the game in general and many balance points of various counter-unitcombat modifiers and so on have not been so far well plotted out, which is a part of what's getting established in this unit planning. It's my hope that they won't seem so overwhelming at that point, though the stealth factor may be pretty impressive at that stage and it's possible the AI isn't staffing good enough visibility units to see them coming and thus easily gets overwhelmed by the little ninja cat people.

I have previously done a chain of upgrades map on Felines but I'll be considering them again further soon here so I'll look for ways to tame them a bit as well.

Thanks for the observations on that and drawing my attention to it as a problem spot for deeper consideration.
 
General update:
I've been pushed back down to a basic phone sales mule for a while since the boss's business enterprises are being heavily impacted by the outbreak here. So while that sucks and its boring and it's really feeling like the most horrible backpedalling for me, it does give me a little more time and mental bandwidth to work on things here. As I said before I'm making faster headway anyhow.

So for the CORE units so far, I've added and completed planning on pages for tags regarding:

Religions, Corporations, Research, Trade, Healing, PropertyManipulators, Spying, and Investigations.

Coming up still:
Builds
XP (maybe isn't still needed and what is might be absorbed into another category - not sure yet)
Theaters of Operation
Cargo (which will include planning some deep coding changes to this stuff to allow multiple kinds of cargo to be carried and accounted separately or in a pool by the transporting units - and some debugging)
UnitCombat Class assignments and more firm categorization rule definition planning
AI type assignments and some deeper planning for some major unit AI overhauling.
Prereq Bonuses
Prereq Civics
Prereq Buildings
Misc tags

Then I get to get into some fun stuff with some Combat Mod planning
Combat Mod core basic tags
Advanced S&D tags
Size Matters tags that apply to unit type infos
Hide and Seek tags (and a bunch of stuff that applies to the core game without it)
Heart of Battle tags (and some deepening planning of a morale system)
Battleworn tags (exhaustion and frenzy)
Strength in Numbers tags (probably going to be renaming the option)
Power Shots (limited number of initial more powerful attacks)
Stunning Strikes
Outbreaks&Affliction tags - won't enable the activation of the option yet but will take care of the core unit planning side of it
Critical Hits - will require O&A and again won't enable the activation of the option but will take care of the core unit planning required
Elemental Damage - Some replanning will be necessary for this section but I'd like to map it out and determine what units will do what - the naval plan includes some of this.


There are more categories of tags that won't be necessary to get into from a planning perspective, particularly not for these core units, things like tags that only apply to animals and art tags and so on that will need to be resolved on a case by case basis during application.


Once this is complete for all core units, it will be time to start duplicating the entire document and mapping it all out for the units that are optional, non-combat, and for units in modules. I may also get the naval and air units in on things before I move in to actual application but once I do application and start putting the plans into action, I'll be working from the beginning of the game forward and should be able to go fairly quickly with it.

There's actually a light at the end of the tunnel for the basics to be completed here and that's a huge step forward because things get faster still after all that.
 
There are mainstream sources suggesting the macuahuitl (the so-called obsidian sword) could also be made using flint. There are much more speculative sources* that suggest that ancient Europeans might have used a similar weapon.

* I say "speculative sources", but knowing the veracity of 'pathworking'/out-of-body travel from personal experience as I do, I regard the speculation as 'confirmed'.
 
There are mainstream sources suggesting the macuahuitl (the so-called obsidian sword) could also be made using flint. There are much more speculative sources* that suggest that ancient Europeans might have used a similar weapon.

* I say "speculative sources", but knowing the veracity of 'pathworking'/out-of-body travel from personal experience as I do, I regard the speculation as 'confirmed'.
This would be the kind of thing we could show with the equipment mod eventually.
 
Progress Update (5/16/2020):
Since I'm mostly back on the phones at work I get to make a little progress (more now that the SA playthrough has come to a finish) on the unit design work. So although I'm hitting some of the tougher stuff, I've made some big strides.

I had said earlier:

Coming up still:
Builds Done - There was some interesting cleanup in this that I found as well as the reveal that we are a little elementary in our current setup with terraforming which Raxo ironically already began to address - suffice it to say as an upcoming project I think we can still accomplish quite a bit of improvement in this regard so even this planning document was just a way to mop up application of what we currently have and didn't attempt to consider adding more... yet.

XP Done - Toffer recently changed the meanings of the attack and defense XP tags and in going through this planning document I was able to establish some initial ways to approach assignment guidelines for these tags. I think they will work quite nicely once implemented in full.

This evaluation also brought to mind a question... would promotions that increase the amount of XP you earn for attack or defense be an interesting thing to introduce into play? I'm thinking it would be very interesting indeed.

Somehow, the Great Commander stuff and XP for attachment and so on got blended into this evaluation so that became a part of this page and I'm now chomping at the bit to get that Great Aviator (Great Military Person) into the game pronto! A few investigations showed it will be super easy to isolate the range of a commander to units of a particular domain only so between the 3 this should be really cool to have.

This one did illuminate that by the time I really call this whole project complete and can start actually applying it to code and xml, I will probably need to include ALL (naval, air, cultural, hero, non-combat capable) units to the plans before going forward or numerous things will be highly out of whack with the land domain core combat units I'm evaluating now.

However, I do think those will go much smoother with this core being mapped out first. Adding a huge degree of insight that the FULL unit review will be necessary was the next page review project:

Theaters of Operation
Well this became a much bigger project than I'd thought it might going in. I was thinking, these are all land units by definition so this should be quick. Ugh. The mapcategory assignments got really REALLY interesting but it was cool because I was watching that SA playthrough walking through a lot of that future material. Thank you Raxo for helping to clarify what each maptype meant. We may have more coming at some point but for now, it's a good structure and the units I planned now have determined what they can and cannot experience.

I know that I need to ensure that units that are being transported don't have to necessarily qualify to be on that maptype they are being transported through. And buildings need a tag that will make the city count as if it can be considered another maptype environment once the building is in place so that, for example, earth units can be moved to moon cities. May also look to make promos capable of adding a mapcategory type to a unit, so that cyborgs in spacesuits can go out wandering on the moon surface all they want. And so on.

The concept of a land unit VS naval unit gets really liquid later on in the tree... another reason it's going to be critical to doing the reworked naval review as part of this thing.

Cargo
My previous note added: (which will include planning some deep coding changes to this stuff to allow multiple kinds of cargo to be carried and accounted separately or in a pool by the transporting units - and some debugging)
I managed to rethink this whole system. Not reprogram it yet - I've decided this is my new methodology: Plan (thoroughly), Program, Implement. I'd just jump in on what I've planned out here to the programming side but I really came to realize ALL units will be needing editing now with this new design in place so... I'm going to press on and finish the xml planning on all these units first.

However, here's the overall gist of what the new system will be. It should be a lot cleaner than the metastasized version of the original highly shortcut simplified original CivIV setup I was too intimidated to rework from the ground up the first time through.

Units will ALL require being defined with the <Special> tag and at this time it looks like it can be completely dedicated to being a tag for determining a 'transportation type' as other possible ways to apply the special tag have fallen by the wayside in C2C. I have numerous new definitions for these which came together as the planning revealed their needs. After navies are added in, this list might add one or two but I think having done most of the naval planning previously already, we're probably looking mostly there with what defines I've found so far.

Then units that can transport other units will have a SpecialCargoTypes tag that will have nested <SpecialCargoType> tag and beneath that an optional nested iTypeCargo tag. It's optional because only if an iTypeCargo of a non-default (-1) amount is assigned to the SpecialCargoType, will that Cargo Type be isolated out of counting against and towards general cargo hold when a unit of that type is carried. Otherwise, if it is defined, then the amount of units that can be carried of that type is defined entirely separately for this carrier and any units of those types (a unit can only have one special definition) will count only towards the pool of units that can be carried of that specific type.

Word salad there I know.

Here's an example of some random kind of setup, possibly for a coastal warship or something:

Code:
<SpecialCargoTypes>
    <SpecialCargoType>
        <SpecialType>SPECIALUNIT_PEOPLE</SpecialType>
        <iTypeCargo>2</iTypeCargo>
    </SpecialCargoType>
    <SpecialCargoType>
        <SpecialType>SPECIALUNIT_TROOP</SpecialType>
    </SpecialCargoType>
    <SpecialCargoType>
        <SpecialType>SPECIALUNIT_BEAST</SpecialType>
    </SpecialCargoType>
    <SpecialCargoType>
        <SpecialType>SPECIALUNIT_ROBOTIC</SpecialType>
    </SpecialCargoType>
    <SpecialCargoType>
        <SpecialType>SPECIALUNIT_MISSILE</SpecialType>
        <iTypeCargo>2</iTypeCargo>
    </SpecialCargoType>
    <SpecialCargoType>
        <SpecialType>SPECIALUNIT_VTOL</SpecialType>
        <iTypeCargo>1</iTypeCargo>
    </SpecialCargoType>
</SpecialCargoTypes>
<iCargo>3</iCargo>

The ship's general cargo hold is 3 units (iCargo in its own generic tag). Since Troops, Beasts, and Robotic units are not given an iTypeCargo, any of these types will count towards those 3 when carried and any of those types can be carried as long as there is room in the general cargo hold still. None of them can be counted as any of the special types or take up room in the hold specifically dedicated by the iTypeCargo tags to those special types. Thus, I can't store a Robotic unit in the VTOL only slot or in either of the People only slots. Conversely, I cannot have more VTOL (helicopters) units landing on this unit than the one it has room for, even if the iCargo general hold has room for more.

Thus, this unit can carry 0-2 people, 0-3 Troops, Beasts, or Robotic units in any combination of the 3, and up to one Helicopter.

I will be able to program promotions to add to general hold, add to the types that can be added to general hold, and add additional space for a special type only.

There are enough Special type defines planned to be able to eliminate the old DomainCargo tag entirely, as well as be able to play into SM naturally with this so that I need to add a tag to the SpecialUnitTypes xml to help guide that but generally, I can save us a lot of memory by getting rid of SMSpecialCargo, SMNotSpecialCargo, iSMCargo and iSMCargoVolume entirely.

So while this may seem more complex to some, it should save us quite a bit of memory and aggravation and will completely debug all problems I've been having with the captive transportation system. Although I haven't planned it out, it also allows us to make it possible for hunters or scouts or whatever to load subdued animals and maintain an expandable cargo hold for them, and I've planned out a return to having trained bird units be a special thing one can develop for their hunters - and possibly even scouts. I also have considered some even more interesting things for the lategame in terms of spirits, bringing back the dead, trapping spirits, using them for energy, that sort of thing. Some of that is still being considered and coming together but there's a skeleton of a plan in regards to some of it in terms of transportation. Further, releasing nasty carried nano units may become a thing for advanced spies. And this whole rework is setting us up for the trap system to come into play finally as well.

And yes, for the core land units, the planning on all this is complete and once the basics were determined, it was pretty easy to work out the details on a given unit so as I'm adding more units to the eval, this should go pretty quick. I feel a great weight lifted even just having sorted out how this will work.




Still pending:
UnitCombat Class assignments and more firm categorization rule definition planning - This begins this week but should go quickly since MOST of it is already pretty well defined out - it will mostly be a maintenance review more than anything. There are some rule plans, sure, but it's all pretty simple really and most of that has already been conceptualized in notes.

AI type assignments and some deeper planning for some major unit AI overhauling. - Been thinking a lot on this. A lot indeed. Oyvey.

Prereq Bonuses
Prereq Civics
Prereq Buildings (With all of these prereqs, I may not be seeking to do a very deep conceptual restructure and might keep it to mostly just a review into this for now and may leave a lot more of it until later potential deepening as we go back over buildings with some new tags and such, but we've been discussing some building prereq tag redesign and I may just plan and implement a version of that now for units.)

Misc tags - most of these basically mean very little after being sucked up into the other design pages.

Then I get to get into some fun stuff with some Combat Mod planning
Combat Mod core basic tags
Advanced S&D tags
Size Matters tags that apply to unit type infos
Hide and Seek tags (and a bunch of stuff that applies to the core game without it)
Heart of Battle tags (and some deepening planning of a morale system)
Battleworn tags (exhaustion and frenzy)
Strength in Numbers tags (probably going to be renaming the option)
Power Shots (limited number of initial more powerful attacks)
Stunning Strikes
Outbreaks&Affliction tags - won't enable the activation of the option yet but will take care of the core unit planning side of it
Critical Hits - will require O&A and again won't enable the activation of the option but will take care of the core unit planning required
Elemental Damage - Some replanning will be necessary for this section but I'd like to map it out and determine what units will do what - the naval plan includes some of this. I don't think I can underestimate the importance of accomplishing this for the lategame units as this kind of diversity becomes a very critical element to things there.

Note: I've been doing a lot of ruminating on the morale system and have some concepts forming that should make it fairly workable - would be implemented through the Heart of Battle combat mod as noted but I think I've figured out mostly what I'm going to do there. When going through all this stuff with a fine toothed comb in the code, I'm hoping we can get any bugs and deficiencies in the combat odds and displays sorted out nicely as well. Also would like to advance the combat log display quite a bit and take away some of the overburdening general combat notes from the normal game alerts, so that if you want to see things blow by blow and well defined how combat played out, you will be able to, while not being nagged by a bunch of withdrawal messages and such at game turnovers.
 
So no plans for VTOL planes like the Harrier?
This sets things up for the potential for that certainly. But we've had that potential for a while. I'm probably not going to try to get too crazy with new air units that I don't 100% need. There's certainly going to be a lot of room for fleshing out further units after all this is done but it will be providing far more clearly delineated guidelines for stat developments since it will always have something nearby to compare to. Most of this review is about establishing standards for all future development.

But yeah, I've wanted something like the Harrier for a while so maybe we'll quickly be able to fit it in when doing the Air unit review side.
 
Last edited:
Any thoughts on tuning down the strength of guerillas? When they appear in the game (tech guerilla warfare) they are by far the strongest unit in the game with a strength of 60 and commando ability lity. Even tanks (coming a bit later in the game) are not as strong, while the much later modern infantry has a strength of 50.
This looks somewhat absurd to me, though I use it in my advantage.
 
Any thoughts on tuning down the strength of guerillas? When they appear in the game (tech guerilla warfare) they are by far the strongest unit in the game with a strength of 60 and commando ability lity. Even tanks (coming a bit later in the game) are not as strong, while the much later modern infantry has a strength of 50.
This looks somewhat absurd to me, though I use it in my advantage.
In the replan they are reduced significantly. Imbalances like these are the largest reason the replanning is being done. I could tell you they're new str will be 35 but that won't bear much relevance until you see the new strengths of units it may likely conflict with as well. It will still be a little strong, just not overwhelming.
 
Update:

The 3 day weekend was a good thing for some productivity - finally got through my first pass at the unitcombat assignments. When I was about 10% into this page I realized it was going to take a serious forever to get through it. But I have completed the FIRST review there and that's a major accomplishment actually.

However, along the way I realized I need to go through a more specific edit review regarding a few things again. I want to double-check all of the weapon methods as I changed a few internal assignment rules on that in preparation for the equipment mod pending and it's hard not to think deeper about these things as you're assigning the unitcombats to new units and so on because the whole time you're thinking, how will I make all this work and as answers form, you realize you need to shift approach on a thing or two to make it easier in the end. So there's that.

There's also a tech prerequisite factor to certain weapons and shield types and I want to now look at how I've set these up and establish firmly where certain prerequisite techs are defined on weapon and shield unitcombats then make sure that I don't have some earlier than those rational points of tech prerequisite.

These second two sweeps shouldn't take nearly as long as the first sweep through and I gotta tell you - Now that I'm looking at all that's been established I'm getting REALLY excited to see a lot of this stuff go into the game! I don't want to spill too many beans here - if you're interested enough you can track back here and check out the planning document link and give it a look through.

I'm really very excited to get through the land unit review entirely as a whole. I'm not sure I can say I see the light at the end of the tunnel here and as soon as I complete it there are other huge steps to take for naval, air, cultural, and hero units to get them into the review as well. But I CAN say that being soon to move on to some of the AI assignment planning is truly cool. And that's approaching quickly.
 
Update:

So I know things seem to be going slow. REALLY slow. It seems even moreso that way to me I think since I'm used to contributing so much more on a regular basis.

HOWEVER, progress is absolutely being made. I've finished the unitcombat planning on the core land units. Whew! In the process, as noted above, I've determined exactly what techs open up what weapon and defense systems and that's going to be very critical in equipment mod design. Very cool stuff there and it feels so good to have a clean room where it comes to that stuff. That's a lot like what this feels like - cleaning my room as a kid. Ugh... sucks but once it's done it's so much nicer. It will be really nice to see in play but so much needs to be done still before that can start to happen because a lot of this plan is a puzzle that has to be constructed almost all at once. I know... I could work on this as a branch and I probably will when it comes time to start working directly in the code and xml but its amazing how much I go back and correct later as a result of the planning process and it will be easier to get it all applied once the plan is complete. That will even give yet another edit process during the application phase.

Anyhow, I began on the AI and AI related tags.

The first thing I've done is record those tags for these units as they are now.

What a freaking mess!

From tons of really bad AI type assignments to almost completely arbitrary and sometimes absolutely counter-intent assigned asset and power ratings, I'm not surprised our AI performance in play is a train wreck.

There are a number of... old vs new clashes in the way the AI is currently functioning. Many units have roles that simply aren't being fulfilled because they are being stuffed into trying to fulfill them through AI types that have almost been completely ignored as far as finding ways to even put them in play... ugh.

So... I've planned out the rough sketch of an overhaul on unit AIs and I believe it can be done through a combat mod AI option for a while as its being perfected in application. I'm remaining somewhat optimistic that the many new AI type definitions that represent a replan of how the AI will organize its forces and use them will be actually not all that hard to implement. When all is said and done, the units the AI utilizes should be much better at presenting strong, well designed stacks, countering numerous known weaknesses in their existing strategies, and even be fully prepared to use surround and destroy to the fullest. If all goes according to plan, I may very well be able to push some of the best players down a notch or two on the difficulty level they play at. AND the AI should be able to fully utilize most of the Combat Mod stuff. It should also make it quite a bit easier to adapt to multimaps when that gets into play.

I also have created an iPower calculator that I keep updating. I'm not going to be too demanding of accuracy there so long as it just spits out something logical and relevant and bears some logical consistency across the board. That's the main thing it needs. iPower ratings add up on units to give the power comparisons for the player level determinations as a leader (or player) looks at the power comparison ratio on the scoreboard. Numerous player level war decisions are made in light of this information and our units are currently completely whacked as to how they are rated - some even go backwards in power rating after an upgrade... oy vey.

Uph... this is some serious foundational work for getting us the launch platform that's going to take C2C into the vision we've always had for it. This segment might take a bit in the planning. Before anyone mentions it, when I get into the coding side of all this, I also know of numerous actual bugs to resolve in AI functions that have been with us for a while and I'll be looking to fix those things too.
 
So a few weeks ago I finalized the core land unit AI evaluation page. Went with a simpler way to assign out iPower and iAsset on units that's only goal really is to just gradually increase them and show a relative improvement of power and civilian value.

The AI structure concept is now pretty well thought out and the overhaul will manage a shton of super complex problems we have in the mod with stack composition, stack intent, unit count balance, unit role specialization, AI unit upgrade pathing through complex upgrade branches while maintaining specialized roles, new effects and abilities, surround and destroy, land units carrying other land units, massive reductions in turn times due to new paradigms in how unit stacks would select best attackers and defenders that dramatically reduce the number of necessary iterations in large stack combat, much faster means to figure out what exact unit types are needed for specific purposes without taking loads of end of turn time number crunching to determine current 'best' options... and so much more.

Obviously when I go to PROGRAM this stuff it's not going to be a total walk in the park but the plan contains within it an inherent blueprint that is obvious to me now that it's been walked through. I'm excited to get to that point where I CAN start working on the coding for that side of things now.

But I'm not quite there yet and many other units will need to be evaluated to get the absolute complete picture formed on that. Nevertheless, I can't understate the amount of effort and planning time this took (even if I HAVE allowed myself some distractions so I can live some outside the modding during this time.)

At the moment I'm working on the Bonus Prerequisites page, and have just finished basically recording on that page what we have now so it can be evaluated and used as guidelines.

This leads me to a few questions to discuss before just barreling through the rest of this part of the planning.

BONUS PREREQUISITES DISCUSSION

Item 1) When I did the Law and Crime and Health Care unit evaluations and mapped out bonus prerequisites and put what I planned out into play, one thing we had to contend with afterward was that my assumptions regarding a lot of bonuses and their availability was often challenged by either the AI not being as good at ensuring access to certain bonuses would be achieved, or finding out that some bonuses were actually a lot harder to simply get than I would've thought, leading some units to be very difficult to obtain, perhaps a lot more so than they should've been.

I don't really want to go down a huge rabbit hole with this, and get into how and why some bonuses are so hard to get, like Soap and Drugs and Tools, but I'm wondering if there's some way we can get a bonus list that includes some guidelines about how hard or easy they are to obtain at various points. Just looking at when they become valid seems to be what I did to cause some major problems for the AI, and sometimes for the player. So how should I know how accessible some bonuses are without a full building/map/tech evaluation on them all? hmm...

Note: I'm not working on any culturally unique units at the moment - obviously that's a bonus restrictive sort of thing with our current design... but not an issue of any concern.


Item 2) The tags regarding bonuses are in 4 forms.
1: <BonusType> When this sits on its own it indicates a singular required bonus that all units of this sort need. It's an initial platform MUST have and goes back to Vanilla setup.
Code:
<BonusType>BONUS_AUTOMOBILES</BonusType>
2: <PrereqBonuses> This is an OR list of bonuses, any of which must be owned in addition to the base <BonusType> prerequisite for the unit to qualify.
Code:
            <PrereqBonuses>
                <BonusType>BONUS_BIOFUEL</BonusType>
                <BonusType>BONUS_PETROLEUM_PRODUCTS</BonusType>
            </PrereqBonuses>
3: <TrainCondition> There are numerous interesting ways this is expressed. <And><Has>, <Or><Has>, <And><Or><Has> - anyhow the point is it COULD be used alone to craft all prereqs, cannot be avoided to craft numerous forms of prerequisiting we have established if we want to keep those constructed definitions (which often are super appropriate), sometimes ARE the only way that prereqs are expressed, and yet I've heard numerous times that somehow the AI is not as 'aware' of what the needs are here.
Code:
<TrainCondition>
                <Or>
                    <Has>
                        <GOMType>GOM_BONUS</GOMType>
                        <ID>BONUS_WHALE_OIL</ID>
                    </Has>
                    <Has>
                        <GOMType>GOM_BONUS</GOMType>
                        <ID>BONUS_KEROSENE</ID>
                    </Has>
                    <Has>
                        <GOMType>GOM_BONUS</GOMType>
                        <ID>BONUS_ALCOHOL</ID>
                    </Has>
                    <Has>
                        <GOMType>GOM_BONUS</GOMType>
                        <ID>BONUS_TAR</ID>
                    </Has>
                    <Has>
                        <GOMType>GOM_BONUS</GOMType>
                        <ID>BONUS_OLIVE_OIL</ID>
                    </Has>
                    <Has>
                        <GOMType>GOM_BONUS</GOMType>
                        <ID>BONUS_FISH_OIL</ID>
                    </Has>
                    <Has>
                        <GOMType>GOM_BONUS</GOMType>
                        <ID>BONUS_GHEE_OIL</ID>
                    </Has>
                </Or>
            </TrainCondition>
So... questions:
* I'm curious if that means we can/should improve the AI so that it is, or exactly what that means the AI does 'see' about the original tags and how those 'influence' the AI (to get access to those resources if it can tech qualify for a unit but doesn't have those resources?), or what this stuff really means to the AI.
* Should we be killing off the original <BonusType> and <PrereqBonuses> usage entirely given that it's now unnecessary to use them? Could we save much info if we did? Clearly the above programming was used to replace the original <PrereqBonuses> on the Arsonist - the statement means what the original one did - are we moving in the direction already of getting rid of that original <PrereqBonuses>? On a number of units, there is NO use of the other 2 tags at all and that appears to function well enough.

4: <BonusProductionModifiers>
Code:
            <BonusProductionModifiers>
                <BonusProductionModifier>
                    <BonusType>BONUS_DONKEY</BonusType>
                    <iProductonModifier>5</iProductonModifier>
                </BonusProductionModifier>
                <BonusProductionModifier>
                    <BonusType>BONUS_CAMEL</BonusType>
                    <iProductonModifier>5</iProductonModifier>
                </BonusProductionModifier>
                <BonusProductionModifier>
                    <BonusType>BONUS_COW</BonusType>
                    <iProductonModifier>5</iProductonModifier>
                </BonusProductionModifier>
                <BonusProductionModifier>
                    <BonusType>BONUS_HORSE</BonusType>
                    <iProductonModifier>5</iProductonModifier>
                </BonusProductionModifier>
            </BonusProductionModifiers>

This brings up Item 3)

Some have attempted to propose that most bonuses shouldn't even be prerequisites but just production modifiers. That we should assume all civs have some access to all resources, but use these to indicate how stronger sources of access to the resources really required to make the unit should instead be used as modifiers to how fast the unit is trained.

I balk at this a lot. I like the idea of having to really strain sometimes to get resources so as to be able to train certain units, particularly the powerful ones that can influence the game deeply. To me, Civ has always thrived on this approach. Still, the idea that there's ALWAYS SOME Iron, seems to be also true to an extent. So I guess I'm asking for discussion and opinions. I might not agree with all of the statements this question invites but I want to get an idea of what people think - so I'm asking the opinions from ALL players on this. Because I need to get a clear idea of how much this should or shouldn't be employed and make how much we do a more standardized matter.

One thing I really DON'T like is that the use of this can really skew the cost of the unit. Therefore, if this exists, should it not offset the base cost of the unit to make it more expensive if you DON'T have access? Another thing - such as the example given, if you have access to all of the above, you're not qualifying for one 5% modifier, you're tallying up to a total of a 20% production modifier. What kind of sanity rules in limitations should we expect there to be when using this sort of tag instead of a hard prerequisite. At what point should we be using a hard prereq instead of this sort of tag, or vice versa?

How can/should we standardize our approach to this alternative bonus prereq paradigm?


Item 4)
Just how realistic should we really be with prerequisites? Should we strive to make it HARD and really require you to THINK about how to strive for access to bonuses to ensure access to units, even super hardcore critical ones? Should we be adjusting to make critical units easier to reach? What's the opinion on how much reality we should be striving to express here? Some units that would obviously need this or that have no resource requirements at all while others have very strict resource requirements and can thus be very challenging and in some games even impossible to get - or only possible through establishing trade or whatever. I'm curious about y'all's thoughts on this matter so I can maybe try to strike a chord that works for most preferences better.
 
So a few weeks ago I finalized the core land unit AI evaluation page. ...
Item 1 - Bonus availability: It's probably safe to just ignore this in favor of what makes sense; stone axmen require stone type of thing, just go with gut. Bonus availability will change wildly when buildings get overhauled (stone should probably be split into stone for buildings and stone like rocks for units, for instance...), so if some units end up being harder or easier to build now, oh well, that'll just change anyway when buildings/resources do. No sense worrying about availablility now, just go for appropriate theming of units requiring building or bonus prereqs from that which we already have ingame.

Item 2 - Bonus tags: Having multiple methods of inputting the same information smells of bad design, particularly when they seem to be handled differently. <TrainCondition> seems to be the more powerful option than the vanilla, though does it allow for nested conditionals? E.g. have (Stone or Obsidian) AND (Wood or Prime Timber), or something like (A and B) OR (C)? Vanilla doesn't seem to, and it would allow for some more interesting prereq conditions.

Item 3 - Prereq vs Modifier: I can see this going either way. I'm not quite sure I like the boolean nature of having it or not, especially as a civ that only has 1 can't export any to allies. This also may be alleviated in building overhaul; if you need "Obsidian Tools" instead of obsidian, where the tools are provided by buildings that have some cost associated with them, then a civ that has access to the obsidian resource can make and export obsidian tools for value, etc. This seems imo my favored solution, but will require building overhaul to make functional.

I agree with the option of flipping the concept of production modifiers; instead of 20% faster with X, 50% with Y, you instead have maluses for missing the resource. Ex: +100% cost for no iron, +50% for no horses, etc. This makes balancing a little easier, as you don't have to inflate the production costs of units to account for how many prereqs they have. Course it'd take a bit of work in the cpp but shouldn't be hard; would also require the AI to have a concept of value of unit per total hammer cost, which I'm not certain it does though?

Item 4 - Realistic prereqs: I'm definitely in favor of more complex prereqs; civs should need to trade to have access to buildings, units, etc, unless they're already snowball winning and have control of basically everything. Critical units requiring critical resources is very much in line with reality, and when a player doesn't have access to say, oil, it suddenly should become a very high priority to acquire it, which gives the player an active goal.
 
Last edited:
Doublepost, copying a response with permission from Giuseppelll on discord so it doesn't get lost:

"The unit stuff is super exciting. I might have to find some time to play again when it all gets implemented!

As far as figuring out how rare a resource is, I would think the main bottleneck would be the frequency of its base components and not where it is located on the tech tree. So a calculation like (base frequency)a(land requirements)b(building cost)c(misc other factors) where a,b,c are arbitrary factors modeled to make the results nice, might be a better model to figure out resource rarity. I’m not sure how this information is stored in the python, but this would optimally be modeled bottom up, first getting base resource values, before getting resource values of resources that require those base resources. Then you would use some equation a(resourceRarity)b(techPosition) to figure how it should affect the units.

I also like needing to have certain resources to build certain units. While it might be a little gamey, I think it adds another lay of strategy, and once you do get those units makes them feel really earned and special.

For how complicated the required resources should be, I think what matters more is how the info is presented than how many hoops the player had to jump through. Having a long tree of requirements to get a special resource can be fun if what is needed is obvious, but frustrating if you don’t know how to get there. Interested in seeing how this shapes up going forth!

To make the resource calculation a little more clear, it should be modeled as a recursive tree, optimally memorized bottom up where cost(resource) = {sum(a_cost(resource-1)), b_cost(resource -1), etc} where constants are placed based on resource type (physical resource, manufactured resource, terrain type, etc.)

So one run through the python would be made to add connections between ‘resources’ making sure not to build any loops (if necessary create dummy duplicate resources) with another loop through to memorize the structure and get costs."
 
AI and some players sometimes trump up resource management. Sometimes map may be unforgiving.
I think it should be made clearer for players and AI to see what they are missing, and how they can plan for it.
 
Item 2 - Bonus tags: Having multiple methods of inputting the same information smells of bad design, particularly when they seem to be handled differently. <TrainCondition> seems to be the more powerful option than the vanilla, though does it allow for nested conditionals? E.g. have (Stone or Obsidian) AND (Wood or Prime Timber), or something like (A and B) OR (C)? Vanilla doesn't seem to, and it would allow for some more interesting prereq conditions.
It actually does allow for nested conditions yes, so it's pretty cool in that way. I've just been told here and there that the 'AI doesn't have visibility on it' and I THINK we've fixed problems with pedia visibility on those issues but there used to be some struggles there even making it so the player could see it. Also might be tougher to identify what's missing when you hover over a greyed out unit that isn't getting something it needs rather than seeing there the red highlighted 'NEEDS THIS' notification, particularly since it might be a bit more complicated - BUT I also think that was resolved too. I don't know for sure so that's part of what I'm asking here.

Another neat thing you can do is make a tech vs building vs resource prereq. So you either have x tech, y building OR z bonus. Things like that appear possible though so far I only see buildings and bonuses being employed in the TrainCondition tag and I'm not sure about civic and tech use behavior but I suspect it would check for if the player has those things now. Thus what could be cool is, say, on some nukes, you either need Heavy Water, OR you have an advanced enough tech that you no longer require it. That sort of thing.

I also think you can use it to nest entirely different comparison sets, like you must have one of either A or B AND One of either C or D OR ignore all of that if you have E. From what I saw in the few forms of examples, there could be some really interesting stuff one COULD do. @AIAndy may have set up something more interesting than I realized here because I got caught up in some of the unanswered vaguaries, like, what does it mean to HAVE exactly, and how do I bracket various things I might want to say? Some of the examples seem to actually answer better to that last question than I understood before as I've seen AND condition lists and THEN ALSO Or conditions.

A look through the code from one of you better programmers might be helpful here to help me see what I'm really working with.

We could probably clear up some data usage if we could kill the 2 original tags entirely and if that's the plan then I can start expressing all bonus prereqs in these terms.

Item 3 - Prereq vs Modifier: I can see this going either way. I'm not quite sure I like the boolean nature of having it or not, especially as a civ that only has 1 can't export any to allies. This also may be alleviated in building overhaul; if you need "Obsidian Tools" instead of obsidian, where the tools are provided by buildings that have some cost associated with them, then a civ that has access to the obsidian resource can make and export obsidian tools for value, etc. This seems imo my favored solution, but will require building overhaul to make functional.

I agree with the option of flipping the concept of production modifiers; instead of 20% faster with X, 50% with Y, you instead have maluses for missing the resource. Ex: +100% cost for no iron, +50% for no horses, etc. This makes balancing a little easier, as you don't have to inflate the production costs of units to account for how many prereqs they have. Course it'd take a bit of work in the cpp but shouldn't be hard; would also require the AI to have a concept of value of unit per total hammer cost, which I'm not certain it does though?

Item 4 - Realistic prereqs: I'm definitely in favor of more complex prereqs; civs should need to trade to have access to buildings, units, etc, unless they're already snowball winning and have control of basically everything. Critical units requiring critical resources is very much in line with reality, and when a player doesn't have access to say, oil, it suddenly should become a very high priority to acquire it, which gives the player an active goal.
Perhaps we need to consider WHAT resources are more a representation of a 'large amount of access but everyone has it' vs WHAT resources represent 'if you don't have it, you really DON'T have it'.

Somewhat like the definition on D&D 3e skill checks that states whether you can attempt a skill if you haven't learned it or not.

I totally see what you mean about buildings. You said that well and yeah, there's a good chance that bonus and building unit prereqs should AGAIN be reviewed during and after a better building review has been done particularly with supply stuff in mind during the building review.

As far as figuring out how rare a resource is, I would think the main bottleneck would be the frequency of its base components and not where it is located on the tech tree. So a calculation like (base frequency)a(land requirements)b(building cost)c(misc other factors) where a,b,c are arbitrary factors modeled to make the results nice, might be a better model to figure out resource rarity. I’m not sure how this information is stored in the python, but this would optimally be modeled bottom up, first getting base resource values, before getting resource values of resources that require those base resources. Then you would use some equation a(resourceRarity)b(techPosition) to figure how it should affect the units.
@GiuseppeIII Totally get what you're saying but this isn't a calculation the game makes at the moment and I'm doing planning on a document outside direct processes necessarily in the game itself for what to establish on the unit's xml definition - what all that means is by the time the unit info is loaded into the mod, this stuff has been determined already. So python has nothing to do with it. However generating some kind of note field for that 'ease of access' on a list of bonuses might be a good way to help guide such decisions. I have a list of bonuses around here somewhere that I was using for the naval - might be a little out of date but probably easily updated. I'll have to dive in and find that and we can discuss coming up with some general concept of how hard various resources are to get. That might be needed before I really move forward on this planning.

For how complicated the required resources should be, I think what matters more is how the info is presented than how many hoops the player had to jump through. Having a long tree of requirements to get a special resource can be fun if what is needed is obvious, but frustrating if you don’t know how to get there. Interested in seeing how this shapes up going forth!
AI and some players sometimes trump up resource management. Sometimes map may be unforgiving.
I think it should be made clearer for players and AI to see what they are missing, and how they can plan for it.
Yeah alright good points but anyone have any suggestions as to what could make that easier?

For now, WE need to start getting an idea of the hoops one needs to jump through - probably as stated on a spreadsheet for the bonuses.

Then we can take a look at how the AI might be able to preempt this better.

But what about for the players? Should we be trying to provide some kind of in play screen that shows what resources by tech you could have but don't - and then some way to say whether you'll need to get it from the map (what improvements would access it, what units can build such improvements) or if it comes from a specific building and what you might be missing in other prereqs to build that building somewhere or if you CAN build it somewhere now but you've just overlooked that?

Ideas maybe?

To make the resource calculation a little more clear, it should be modeled as a recursive tree, optimally memorized bottom up where cost(resource) = {sum(a_cost(resource-1)), b_cost(resource -1), etc} where constants are placed based on resource type (physical resource, manufactured resource, terrain type, etc.)

So one run through the python would be made to add connections between ‘resources’ making sure not to build any loops (if necessary create dummy duplicate resources) with another loop through to memorize the structure and get costs."
@GiuseppeIII Are you suggesting a way to state to the AI the 'difficulty' of getting a resource, or some way to guide the AI in HOW to get to a resource? Does it matter the difficulty really? I suppose it certainly could if you're looking at trying to help the AI understand the value of a resource in trade if it doesn't have one - though I have to wonder if even that is necessary or if it's simply enough to say to the AI, if you don't have something, try to get it. Then again if it's only a simple building away, it shouldn't be making great sacrifices I guess. I'm not really wanting to currently get into the diplo trade side of resource valuation, though perhaps the AI should have a system by which it is told that it needs something for a unit that it doesn't currently have and that may prompt it to become more proactive about trying to get it through an evaluation of how to best go about doing that, including keeping trade in mind as one of its options. An AI might even be compelled to try to go out of the way to make friends with a player because that player has something the AI really needs and somehow admits it can't get without a fight it can't win or doesn't want to engage in.

But now we're talking 15 yrs off project level stuff. Maybe just notify the AI that a unit can't be trained because it doesn't have x,y,z or f and make it therefore want that more in building evals, or just tell it even simpler if it doesn't have a resource that due to tech level it COULD have, value getting it. I haven't researched into that sort of thing too deeply but I THINK a lot of that is in place, though that may also be what some have meant by saying the TrainCondition tags are invisible to the AI as the reasons it may not be able to construct or train and that could be something that still needs to be improved. Which may be cause to hold off on putting every unit over to ONLY using TrainCondition...
 
With the resource caluclation I was referring to what was being discussed here:

"I don't really want to go down a huge rabbit hole with this, and get into how and why some bonuses are so hard to get, like Soap and Drugs and Tools, but I'm wondering if there's some way we can get a bonus list that includes some guidelines about how hard or easy they are to obtain at various points. Just looking at when they become valid seems to be what I did to cause some major problems for the AI, and sometimes for the player. So how should I know how accessible some bonuses are without a full building/map/tech evaluation on them all? hmm..."

I was talking about a python script that for each resource could get a value for accessiblilty. I didn't realize all of the unit code was done in XML, so the language of the script wouldn't really matter it would just have to pull the data from the XML. What you would want to do is pull the data from the xml and run a script where for each resource or resource like item not seen yet pull the resource into a hashmap or dict with the key being the resource and the value being an array of requirements. This could be done fairly quickly (O(n) time). Then you could think of this hashmap like a DAG and use a recursive function accessibility(resource) = {x*sum(a*accessibility(resource-1) + (b*accessibility(resource-1) + etc...) for resource > 0, x = resourceRarity (as defined in the xml) for resource == 0} Where x is arbitraily defined as a cost for number of steps needed and a, b are defined based on type of resource resource-1 is (if wanted, this is not really necessary). This could be memoized pretty simply by topologically sorting the DAG and running a memoization function in-order and the output would determine the accessibility of each type of resource. This could all be done pretty efficiently in O(n) time and then another script could be used to automatically use these values in a function to determine the new value of units and place them automatically into the xml. The only thing to look out here is that when you put the resources into the hashmap that no cycles are being created, or that if there are you have a way to deal with them so that the recursive function does do an infinite number of calls and cause all values to be equal to infinity. Obviously the script would have to be re-run if resource percentage values were changed, but if it inserted all of the new values automatically into the XML that shouldn't be too bad.
 
Female Christian priest has 3 movement speed while the male has 2. (edit: 2 and 1, respectively. I forgot I had Famen Temple)

Tamed Animals and Breeding Pairs could be merged. They should probably be able to build the Myth buildings as well; not having access to the Myth effects even though you still have the animals as a resource can cause a little weirdness sometimes.

It would be cool to be able to plant other animal resources on the map the same way that you can plant Donkeys and Cows.

Some Animals don't have Tamed/Breeding Pair versions that it seems like should (sheep, kangaroos, poultry).

Tamed/Breeding Pair units should probably be tradeable via diplomacy.

Only lightly touches on units - but, corporations and their relationship to resources that can be duplicated easily (e.g. with Herd - Cows and planting Cows on the map) should probably be re-examined.

Transport troops promotion seems to do nothing; it doesn't reflect on total cargo space, anyways.

Mounted units that have flanking/stack bonuses against siege units should maybe have them apply more generally, instead of against a couple very specific units?

It would be good to be able to preview stealth combat modifiers when moving onto a tile against a unit you can see when they apply, instead of only being able to preview normal odds.

Not sure if, given the recent rebalance of merchant costs, you still want buildings or traits that give a boost to trader production speed, e.g. the Negotiator trait or the Caravan Post.

Unsure if this is intended, but Food Merchants in general represent an easy way to convert hammers into food and really speed up your city's population growth (up to the point that food consumed = food produced).

Not sure if you should still be able to build the base Worker and animal Workers at the same time? This lets you build base Workers then spend a little money to upgrade them, skipping some of the hammer cost.

Maybe the Carrack should not be an Explorer unit, so that it's able to merge and split?

The Caravel does not get better results from tribal villages, unlike the Outrigger that it upgrades from.

Not directly Unit stuff, but the AI should probably value manufactured resources more on the diplomacy trade screen. At the moment the AI just gives most of it to you for free, or for trivial amounts of gold. I'm receiving Tin ingots for nothing right now, and it's really weird.

It would be cool to be able to see the % success chance your missionary has of spreading a religion (affected by traits, wonders, and civics).

Bandit Riders and Footpads are ridiculously strong units for their era, and remain the strongest for quite a long time.
 
Last edited:
I want to first say that I'm not really familiar enough with the code to assess how complicated it would be to implement this so feel free to discard the idea without further thought if it unnecessarily complicates the workings of the mod.

My idea regarding this is thus: Arrange the availability of different types of units primarily by the presence of a certain set of buildings. If you want a stone axeman, you need a stone tool maker. The stone tool maker requires some "rock stockpile" or "stone gatherer" building. If you want an obsidian swordsman, you need access to both a source of obsidian and the stone tool maker within that city or your trade network. An obsidian swordsman is principally a stone clubman with an obsidian tool, so we just apply a mutually exclusive "weapons" and "armor" upgrade to the unit - clubmen entering a city with the appropriate facilities and resources can thus receive the upgrade. The upgrades are arranged in tiers so the city applies the upgrade of the highest tier of weapon to any compatible unit that passes over it, or perhaps the upgrade is purchasable with money by units within the city limits or by some other means.

As the game progresses, more specific unit templates become available to reflect the evolving format of warfare, and new buildings become necessary to further equip your units. Unique, rare, or technologically optional paths may open up to equip normal units with exceptional or unusual equipment, perhaps even a third upgrade can provide a unit with one unusual "equipment" to customize it. At the start this could look like equipping a ground unit with ladders or hooks to provide a percent chance to bypass city defenses, or traps to provide bonuses against animals, or camouflage requiring pigments, etc. and later it could look like providing early medieval ships with rare sunstones so they can cross short patches of deep ocean, and eventually providing infantry with an anti-tank support company that gives a reasonable chance against tanks, or furnishing a destroyer with anti-air cannons that decrease incoming bomber damage and increase aerial attrition.

The AI might follow a series of procedural templates to approach building units in a city. When new units become available in a city, the AI generates a template that directs it regarding how to equip any optional upgrades to the unit, and uses the costs and properties of each template to assess its' valuableness for any mission it has in mind. When new tools become available, the AI either upgrades existing templates or spawns a new one if the tools do something special. As units become unavailable due to upgrades, some templates will naturally be removed or updated to fit the new unit if possible.

Some unique units could require access to certain upgrades which they absorb and improve on, and may have limited upgradeability. So a hoplite is a spearman with a bronze weapon, bronze armor and a bronze shield as its' equipment - there is no/limited opportunity to upgrade these properties. It's cultural upgrades give it an exceptional defense against infantry or some such. Other unique units may just be a standard unit with some special quality - minutemen are enlightenment-era gunmen with an unusually low cost that makes them more rapidly deployable, but are otherwise normal units.
 
Y'all ever answer a question, then realize you missed the point of the question?
'Cuz that was me just now :crazyeye:
 
Top Bottom