Building/Unit prereq obsoletion/replacement review

Which means that new cities become impossible after awhile.
Replacement buildings do not require the building they replace to be present when they are built. So how are you saying this would happen?
Case of Forge and Foundry. A forge is relevant even if something better exists. A forge might not be allowed to co-exist with its upgrade. The possibility of building another forge can potentially exist even when something superior is available. The only relationship we know is absolute is that, at the point the building "isn't doing anything measurable" (in-context) , that is, when it's obsolete, is the same point when a player should not be allowed to build another one.
Problem with the overlap approach is that it creates small periods of time where your cities are really way too powerful - in the case you suggest - where the forges also exist, there's TON's of production until the forges are obsoleted. The replacement solves that perfectly. By being just a small step up but removes the benefits of the replaced building, it keeps things on a controlled curve of improvement.

One other thing I thought I'd highlight is the larger need in C2C development to represent the structural Design decisions as separate from the Mechanical, interpreted product of game files. When we figure out how to accomplish a Design goal - e.g., use an out-of-fashion structure to quicken production of an upgrade; specify all techs have costs dictated by their column; make buildings have costs dictated by their tech column - we put those mechanics in the game files - e.g., set a Building_BuildingModifier to something nonzero; set 929 <Cost> fields in an XML file - but we lose the coherency of the Design decision.
One place that is less spreadsheet-ible of this problem, is with technologies. We might know that technologies should be in certain relations to each other, like being Definitely After another one, but the current form of the tree makes the Requires relationship redundant. This is where optimizing the game files loses Design information.
It's an unfinished job in that the value of a building, unit or tech is not taken into account in the cost. But in the meantime, it is a method that challenges the player to read into the value vs the cost to see where the best opportunities to exploit are found. That may not be a bad thing for a game.
 
Replacement buildings do not require the building they replace to be present when they are built. So how are you saying this would happen?
Instead of building a small office for the local police officer in your new hamlet you have to build a full set of offices in a building that belongs in a city! (This is based on the up keep costs as well as the build costs.) The same for health care and so on. There needs to be an appropriate "time sensitive" building for new cities. Or the old has to be available to be used. A new city needs to be able to afford to pay for the buildings it needs.

Perhaps what is needed is an obsolete by city size not tech. Except that is not quite right either. I assume crime etc grow with population so eventually the "old" building is not providing enough "cover".
 
Or more National Wonderrs (or giving free "basic" building... or New city in later era with free basic building.
An example : "
"Ministry of Health" National Wonder, free Doctor's Office in all cities
 
I'm not sure that volumetric resources is an inevitable part of C2C. My gut feeling says it'll be a lot of added micromanagement with little addition to strategic depth, and hard to balance (also for the AI). Even if somebody starts on such a system, there's a non-zero chance it will eventually fail due to being rejected for making the game less fun.
Without volumetric resources you need to have another reason to build the respective factories, even though they "give" pollution and flammability. Unless you are OK with people producing all kind of resources in huts and/or workshops. The bigger amount of goods produced is the main RL reason to build factories (and to accept the increased dependence on e.g. electricity). So you need another reason (not at all related to RL) why people should industrialize. If it's too far away from what would happen in real life you have a fourth wall issue.

Of course I realize that volumetric resources are still far away, but I really think that should be the "ultimate" solution to this problem.
 
@tmv what is your idea on volumetric resources?

Is it something more concrete, where factories produce the same good as huts but in larger quantities (10 vs 1 for example), or something more abstract, where factories produce a "different" type of resource from huts, but whose bonuses are the same but 10x stronger that what huts provide (if following the example above)?
 
As factories produce more then they should produce more hammers and commerce. Volumetric resources directly compete with the base system of hammers, food and commerce. Which is an abstraction to lessen micromanagement.
 
Problem with the overlap approach is that it creates small periods of time where your cities are really way too powerful - in the case you suggest - where the forges also exist, there's TON's of production until the forges are obsoleted. The replacement solves that perfectly. By being just a small step up but removes the benefits of the replaced building, it keeps things on a controlled curve of improvement.
No no, I'm saying that you have the structure be an upgrade of the older structure, but the older structure doesn't obsolete until a while later. If you build the upgrade, the old Forge goes away so the bonus doesn't accumulate. Obsolescence is caused by discovering a specified tech, which makes the building nonfunctional. Upgrading also makes the building nonfunctional. The obsolescence doesn't have to be at the same time as, and should even be later than, the unlock of the upgrade building.

It's an unfinished job in that the value of a building, unit or tech is not taken into account in the cost. But in the meantime, it is a method that challenges the player to read into the value vs the cost to see where the best opportunities to exploit are found. That may not be a bad thing for a game.
I think I was completely misunderstood here. I don't know what you're talking about. I'm saying that the current process for stating tech costs is by writing 929 <Cost> fields in an XML file. But at the level of you guys as designers, your decision was to come up with 100 or so (however many columns) prices that increase with a nice pattern.

In general, you have design decisions that reflect certain elegantly stated goals, but the game files that implement these decisions are not self-documenting. If, in the future, a new directive is taken on the design decisions, it is likely that the directive is elegantly stated in reference to the previous design decisions, which have been erased in the game files. Thus, you want documentation, and ideally, a metaprogram that automates the generation of game files from a structured document expressing the design.
 
I think I was completely misunderstood here. I don't know what you're talking about. I'm saying that the current process for stating tech costs is by writing 929 <Cost> fields in an XML file. But at the level of you guys as designers, your decision was to come up with 100 or so (however many columns) prices that increase with a nice pattern.

In general, you have design decisions that reflect certain elegantly stated goals, but the game files that implement these decisions are not self-documenting. If, in the future, a new directive is taken on the design decisions, it is likely that the directive is elegantly stated in reference to the previous design decisions, which have been erased in the game files. Thus, you want documentation, and ideally, a metaprogram that automates the generation of game files from a structured document expressing the design.
This metaprogram is the sort of thing I wrote my entire work life, or at least for the last 2/3rds of it.

What HorseshoeHermit is saying is that we can replace some of the hand coding we now do by recording the design decisions in XML as rules and have a program that applies those rules in a way that makes things easier to do in the future.

For example:

The design decision to tie building costs to tech column with defined multipliers for defined building variants - National and World Wonders and buildings that are extensions to existing buildings (eg food buildings associated with temples). This information is meta information about a particular tag (iCost). A program could be built similar to the C2C XML Validation program that goes through all the Building Infos files and fixes the iCost (where it is not -1) to the value it should be based on the tech grid.

In this case the meta information is
  • the cost related to tech column - this is either a formula or a list of X-grid value and iCost
  • National Wonder multiplier eg 4
  • Global Wonder multiplier eg 8
  • extension multiplier eg 1/4
Arte these varied per Era?​

As we get more and more information into the meta XML there is less work to do in maintenance eg when we move the tech tree around. There are still a few missing techs and some may be in the wrong column.

Do we have a similar solution for?
  • cost of units
  • work cost of improvements eg requires Bronze/Iron Working/Canal Building to do in Terrain X, costs 200x, and provides X% :hammers:
  • improvement pillage value based on Tech it becomes available
  • iAsset/iPower on buildings and units
It also means that we can run the meta-program once just before a release to align everything.

edit The biggest advantage is that the design decisions are not lost but are recorded in the project as part of the XML.
 
@tmv what is your idea on volumetric resources?

Is it something more concrete, where factories produce the same good as huts but in larger quantities (10 vs 1 for example), or something more abstract, where factories produce a "different" type of resource from huts, but whose bonuses are the same but 10x stronger that what huts provide (if following the example above)?
Mostly the former (although there are some modern+ resources that would be very hard to make even in small quantities in a building like a hut). For once, we can take a look at [civ5] where we have volumetric resources (although the execution was a bit silly - then again, this is [civ4]). A unit or perhaps even a building would not only use a resource, but consume it on production (would it even be possible to have a promotion, like Cold Combat, require a resource like furs?). A hut could produce perhaps 5 units (not 1, this is a strategy game and not an RPG), a workshop 15 and a factory 50 (a futuristic super-factory perhaps 200). Now if you want to field a large army your choice is to either build many cities with huts in each of them or to build a factory or two in order to have enough resources.

And a factory could also improve what you could call the "supply-output relationship" (I don't know if there is a proper word for that) where you have this big output with a comparatively minor supply requirement (perhaps a hut produces 5 units of output for a single supply unit, a workshop 15 for 2 and a factory 50 for 3 in order to make these buildings really worth it).

At this point you wouldn't have to worry anymore about using ancient production buildings as a viable strategy. You also wouldn't have to worry anymore about overly large SoD until the late game (and too many units on the map), only at this point there will not be many nations left and next to no animals.

Edit: Your second option wouldn't be possible, I think. A super-resource ten times more powerful would almost require a system where you can build a ten-times-as-powerful unit, and that wouldn't really be possible without SM, I think. And the CM options are not (by a long shot) popular enough to make them mandatory, but without SM this option would be very hard to implement. The first option OTOH makes no demand on the presence or absence of SM in a game.
 
Instead of building a small office for the local police officer in your new hamlet you have to build a full set of offices in a building that belongs in a city! (This is based on the up keep costs as well as the build costs.) The same for health care and so on. There needs to be an appropriate "time sensitive" building for new cities. Or the old has to be available to be used. A new city needs to be able to afford to pay for the buildings it needs.

Perhaps what is needed is an obsolete by city size not tech. Except that is not quite right either. I assume crime etc grow with population so eventually the "old" building is not providing enough "cover".
Since there are not size upgrades to buildings or the ability to build multiple stations, the building of one assumes that it scales to the size of the community it has been built in and continues to as the city grows or shrinks. The production cost obviously doesn't change, which is a flaw in the Civ IV approach to many buildings, not just this example. You could, and probably should, have larger versions available as the city reaches certain size prereqs. No need to obsolete the lesser buildings but if the buildings aren't upgraded then they end up being insufficient. That would be the best approach. Which I would've used if it were already a convention of C2C design - it would need to become one in a much wider application than just crime or health buildings if it gets introduced to any of them anywhere. BIG project. I felt that for now, just having a building to represent the basic need was detailed enough for current game needs. There are a lot of ways to improve things still but, imo, the most important thing to address is to flesh out the basic core functions of supply and demand before working on that much detail resolution.

No no, I'm saying that you have the structure be an upgrade of the older structure, but the older structure doesn't obsolete until a while later. If you build the upgrade, the old Forge goes away so the bonus doesn't accumulate. Obsolescence is caused by discovering a specified tech, which makes the building nonfunctional. Upgrading also makes the building nonfunctional. The obsolescence doesn't have to be at the same time as, and should even be later than, the unlock of the upgrade building.
OK, I agree with that and must have misunderstood your original point.

In general, you have design decisions that reflect certain elegantly stated goals, but the game files that implement these decisions are not self-documenting. If, in the future, a new directive is taken on the design decisions, it is likely that the directive is elegantly stated in reference to the previous design decisions, which have been erased in the game files. Thus, you want documentation, and ideally, a metaprogram that automates the generation of game files from a structured document expressing the design.
This is why I posted the charts in the Modder's Documentation thread. I would hope any modders to come would take some time to understand and apply the same method. Sadly, I know that's probably not going to be the case.

What HorseshoeHermit is saying is that we can replace some of the hand coding we now do by recording the design decisions in XML as rules and have a program that applies those rules in a way that makes things easier to do in the future.
With a few tags, or even one, to indicate if a building/tech/unit should take on an abnormal cost mechanism, we could put cost derivation entirely in the dll and have it be determined during the mod load process. No problem. Before doing this sort of thing, we would need to heavily test the applicability of the existing calculatory method, a test which is currently underway. Not sure it's necessary to take this step but could probably save a hell of a lot of time for future cost adjustment methods as well and enforce adherence for all time to come. We've learned already of some exception cases. There could be more. I kinda doubt this will become enough of a need to invest the time into it however.

and that wouldn't really be possible without SM, I think. And the CM options are not (by a long shot) popular enough to make them mandatory, but without SM this option would be very hard to implement.
One of the many reasons I developed Size Matters was the recognition of how important this would be to a reasonable volumetric resources system. I don't think we have enough RAM to pull it off though.
 
Since there are not size upgrades to buildings or the ability to build multiple stations, the building of one assumes that it scales to the size of the community it has been built in and continues to as the city grows or shrinks. The production cost obviously doesn't change, which is a flaw in the Civ IV approach to many buildings, not just this example. You could, and probably should, have larger versions available as the city reaches certain size prereqs. No need to obsolete the lesser buildings but if the buildings aren't upgraded then they end up being insufficient. That would be the best approach. Which I would've used if it were already a convention of C2C design - it would need to become one in a much wider application than just crime or health buildings if it gets introduced to any of them anywhere. BIG project. I felt that for now, just having a building to represent the basic need was detailed enough for current game needs. There are a lot of ways to improve things still but, imo, the most important thing to address is to flesh out the basic core functions of supply and demand before working on that much detail resolution.

Ah what I wanted way back when. Also what I did with the admin buildings:mischief:
OK, I agree with that and must have misunderstood your original point.


This is why I posted the charts in the Modder's Documentation thread. I would hope any modders to come would take some time to understand and apply the same method. Sadly, I know that's probably not going to be the case.


With a few tags, or even one, to indicate if a building/tech/unit should take on an abnormal cost mechanism, we could put cost derivation entirely in the dll and have it be determined during the mod load process. No problem. Before doing this sort of thing, we would need to heavily test the applicability of the existing calculatory method, a test which is currently underway. Not sure it's necessary to take this step but could probably save a hell of a lot of time for future cost adjustment methods as well and enforce adherence for all time to come. We've learned already of some exception cases. There could be more. I kinda doubt this will become enough of a need to invest the time into it however.


One of the many reasons I developed Size Matters was the recognition of how important this would be to a reasonable volumetric resources system. I don't think we have enough RAM to pull it off though.

The problem with having it in a document here on the forums or in the dll is that it can't be modified or tweaked easily or quickly. Having it in some new XML and applied by the dll would be the best outcome.

As you know I have philosophical and other issues with Size Matters. If it worked in a more actual military way I would be much happier. Eg 5 spearmen merge to form a phalanx or one upgrades to a phalanx with 1/5 of the health and it can't then split. My main gripe I suppose is the viability of singleton units after the invention of squads and the make up of these squads. Even if we had tactical battles a unit less than a squad (platoon(?) in US lingo) are not meaningful with the exception of specialists. At different times units of troops are of a set size, a square of pikemen for example. Armies are a different matter and these are both the stacks and all the stacks in range of a Great Commander. (Does that range change with changes in communications technology?)
 
Even if we had tactical battles a unit less than a squad (platoon(?) in US lingo) are not meaningful with the exception of specialists.
Strengthwise, this stays true with Size Matters with the exception of how smaller groups can delay other units by soaking their attacks. Besides, it all depends on what it is. One tank can take on quite a few footsoldiers for example.
Eg 5 spearmen merge to form a phalanx or one upgrades to a phalanx with 1/5 of the health and it can't then split.
Far too susceptible to becoming a nightmarish host of individually defined solutions that do not adhere to a generic norm that works for all in a simple enough manner for a game, imo. The groupings are fairly applicable still to historically accurate groupings of various military forces as it is though.
At different times units of troops are of a set size, a square of pikemen for example.
We can represent that with special promos available to those size and unit types if we wanted to get that specific.
Does that range change with changes in communications technology?
Not currently but it would be a good mod to set up - I always wanted to eventually better represent modern communications tech by enabling generals to not even have to leave home, just establish permanent control over selected units with no range consideration remaining. Among a host of other adjustments to some ranged factors due to modern communications.
 
Which I would've used if it were already a convention of C2C design
What about the housing system (even if it's autobuilt)?
My main gripe I suppose is the viability of singleton units after the invention of squads and the make up of these squads.
Perhaps the Bottleneck promotions are a bit too powerful - they should not be able to make up for the loss of base strength so much. Even the Battle of Thermopylae was won by the Persians in the end. Bottlenecks should give you the ability to hurt the big unit, but (unless the situation is unusual, like a big tech difference) you should not win the fight. A modern tank platoon could eradicate Caesar's armies on its own, but that shouldn't be - mostly - down to Bottleneck.

It might be better if Bottleneck "only" gave you First Strikes against the bigger unit.
 
What about the housing system (even if it's autobuilt)?
What about it? Are there population prereqs on those or just tech and bonus access?

Perhaps the Bottleneck promotions are a bit too powerful - they should not be able to make up for the loss of base strength so much. Even the Battle of Thermopylae was won by the Persians in the end. Bottlenecks should give you the ability to hurt the big unit, but (unless the situation is unusual, like a big tech difference) you should not win the fight. A modern tank platoon could eradicate Caesar's armies on its own, but that shouldn't be - mostly - down to Bottleneck.

It might be better if Bottleneck "only" gave you First Strikes against the bigger unit.
Perhaps it should be a little curtailed but I wouldn't change the basic functional concept of it over to something other than what is directly countered by the Swarm, Sting and Bully promos and I'd adjust them to the same modifiers. It's only standing out because it's the most commonly leverageable (though I would wager if one were to counter this with heavily merged Swarm promoted units they'd find it's not all that problematic in the end.)
 
What about it? Are there population prereqs on those or just tech and bonus access?
For some there are. I think Longhouses require pop. 6 (and probably some other houses as well), the skyscraper housing requires skyscrapers (which means pop. 13 IIRC), and the arcology housing requires arcologies (which means pop. 25, I think). And as https://forums.civfanatics.com/threads/c2c-housing.420663/ shows that was already the original intention with housings.

Perhaps it should be a little curtailed but I wouldn't change the basic functional concept of it over to something other than what is directly countered by the Swarm, Sting and Bully promos and I'd adjust them to the same modifiers. It's only standing out because it's the most commonly leverageable (though I would wager if one were to counter this with heavily merged Swarm promoted units they'd find it's not all that problematic in the end.)
The problem I see is that this should be different. No matter the promotions, squads shouldn't be able to defeat armies unless there is a huge tech difference. It's also a problem that Bottleneck doesn't even require a suitable terrain, it works even in open terrain. Large units should (in general) have big advantages - and not just because they are much harder to build. As I said even the Battle of Thermopylae was a Persian victory in the end - this battle did not even contribute to the ultimate Greek victory, other than perhaps inspiring people.

There are examples of small units performing much better than you would expect, but outright victory is very rare when the group size differs too much. Bottleneck in real life is a good idea to hurt large units though, that's why I suggested this promo should give a few First Strikes (and perhaps an increased chance of getting away - I don't remember right now what that was called). That way you could use small units very well, you might even be able to wear a large unit down with lots of small units (and you still have that big advantage in defense that one unit cannot attack more than one defender at once), but considering Bottleneck a mirror to Swarm is a mistake IMO (some heroes can get comic book-like qualities with such a strong promotion).

Edit: The "heavily merged swarm" unit requires training an immense number of units and putting all of your eggs in one basket, not to mention the tech requirement for heavy merging.
 
The problem I see is that this should be different. No matter the promotions, squads shouldn't be able to defeat armies unless there is a huge tech difference.
Special forces squads do it in the real world all the time. Skill in battle is an equivalent factor to the size of the force, particularly in any role-playing environment which I was preparing to involve more elements of.

That said, I find that even with these promos, Heroes are far more imbalancing on games without Size Matters as there is NO way to counter them without just severely out-teching them since they can't be upgraded to keep up after a while.

some heroes can get comic book-like qualities with such a strong promotion).
And that's basically the point. Victory of design!
 
Special forces squads do it in the real world all the time.
Erm, special forces squads that destroy entire armies (with comparable tech)? Do you have a real life example for that?

Skill in battle is an equivalent factor to the size of the force
If we go technical, at least in modern combat you need four times the skills to make up for the other size being twice as big: https://en.wikipedia.org/wiki/Lanchester's_laws

Victory of design!
Loss of immersion.
 
Erm, special forces squads that destroy entire armies (with comparable tech)? Do you have a real life example for that?


If we go technical, at least in modern combat you need four times the skills to make up for the other size being twice as big: https://en.wikipedia.org/wiki/Lanchester's_laws


Loss of immersion.
Meh. Everything you're pointing at goes back to the fact that heroes are already repugnantly imbalanced with or without SM.
 
Special forces are just that special! They are not the norm and making everything like them, or to fit them, just makes no sense.
 
Special forces are just that special! They are not the norm and making everything like them, or to fit them, just makes no sense.
Given that they are about all that's been employed lately, they are not abnormal by any means.

Besides, not all is 'like them'. If you take a squad of swords up against a battalion of them, you're pretty likely to get stomped. The power difference is extreme already. If we want to reduce the promotions that get x% combat mod per step difference between them and the other unit, then that's fine - I intended to make them a bit strong at first to make sure they got used and that commenting players would become familiar with them as a result. They could be nerfed a bit and still be balanced and would probably make it more 'immersion friendly'. Very few, truly VERY few, lesser group sizes have any kind of chance against a similar type of force, at least without the promotions to help take advantage of the differences and curtail the negative of being lesser in some measure.

At the moment I think it's +10%/category of difference. +5%/category of difference would probably achieve the results sought without making the promos useless.
 
Back
Top Bottom