Thecw

Join Date 08/2012

+84

Building uniqueness and limits

While creating massive production planets i started to think about the limitations of the game system as it is now. Especially the absence of a relation between the population size and the number of a given improvement. Furthermore it annoyed me that for a given terraforming tech the number of tiles was just 1 or many, and nothing in between.

At the moment for a given improvement there are three modes of limitation:
1) improvement is unique for the player (<IsPlayerWonder>) - like the Manufacturing Capital;
2) improvement is unique for the planet (<IsColonyUnique>) - like the Colony Capital;
3) improvement can be build limitless - like the Factory.
and
4) uniqueness defined by a group of improvements is enforced through the use of preclusions (<Preclusions>).

These above facts limit the granulation of the improvement construction (count), and make the internal integrity and maintenance of the (ImprovementDefs.) xml file vulnerable. The vulnerability shows in the fact that for every improvement out of a group all others must be specified as preclusions. That this vulnerability is not theoretical has been shown by the fact that in the xml files these mistakes already exist; and have been mentioned in various posts - including acknowledgement by Stardock.

I would like to propose an alternative system to address these issues. The current (xml) infrastructure already supports targeting, so lets use that. Instead of the two unique tags and the preclusions tag the following (xml) constructs could make it far more flexible and robust.

And as an added bonus modding becomes easier (especially when multiple mods are going to be used), because a mod does not need to know about all the 'new' improvements within a improvement group that are defined in another mod.

Note: The following XML shows only the to this proposal relevant tags.

Replace <IsPlayerWonder>true</IsPlayerWonder> with:
<Limit>
<Target>
<TargetType>Player</TargetType>
</Target>
</Limit>

Replace <IsColonyLimit>true</IsColonyUnique> with:
<Limit>
  <Target>
      <TargetType>Colony</TargetType>
  </Target>
</Limit>

Replace (or augment) <Preclusions> with - example for Solar Power Plant:
<InternalName>SolarPowerPlant</InternalName>
<ImprovementType>Manufacturing</ImprovementType>
<ImprovementGroup>ManufacturingPowerPlant</ImprovementType>
<Limit>
  <Target>
      <TargetType>ImprovementGroup</TargetType>
      <ImprovementGroup>ManufacturingPowerPlant</ImprovementType>
  </Target>
</Limit>

Result: No need for preclusions on SolarPowerPlant, FusionPowerPlant, AntimatterPowerPlant, QuantumPowerPlant.

Alter <UpgradesFrom> from a single improvement to from multiple improvements:
<InternalName>FusionPowerPlant</InternalName>
<ImprovementType>Manufacturing</ImprovementType>
<ImprovementGroup>ManufacturingPowerPlant</ImprovementType>
<UpgradesFrom>SolarPowerPlant</UpgradesFrom>
<UpgradesFrom>NuclearPowerPlant</UpgradesFrom>

Result: a single (possibly unique) improvement can be in the upgrade path of multiple improvements.

Limit the number of times an improvement can be build - example raise limit Soil Enhancement to 4 and lower the Ultra Terraformer tile limit to 6:
<InternalName>SoilEnhancement</InternalName>
<Limit>
  <Target>
      <TargetType>Colony</TargetType>
  <TargetLimit>
<Count>4</Count>
</TargetLimit>
</Target>
</Limit>

<InternalName>OmegaTerraforming</InternalName>
<Limit>
<Target>
<TargetType>Colony</TargetType>
<TargetLimit>
<Count>6</Count>
</TargetLimit>
</Target>
</Limit>

Limit the number of times an improvement can be build depending on something else - example limit the number of factories by population:
<InternalName>BasicFactory</InternalName>
<ImprovementType>Manufacturing</ImprovementType>
<ImprovementGroup>ManufacturingBuilding</ImprovementType>
<Limit>
<Target>
<TargetType>ImprovementGroup</TargetType>
<ImprovementGroup>ManufacturingBuilding</ImprovementType>
<TargetLimit>
<TargetType>Population</TargetType> 
<Multiplier>2</Multiplier>
</TargetLimit>
</Target>
</Limit>

<InternalName>XenoFactory</InternalName>
<ImprovementType>Manufacturing</ImprovementType>
<ImprovementGroup>ManufacturingBuilding</ImprovementType>
<Limit>
<Target>
<TargetType>ImprovementGroup</TargetType>
<ImprovementGroup>ManufacturingBuilding</ImprovementType>
<TargetLimit>
<TargetType>Population</TargetType> 
<Multiplier>4</Multiplier>
</TargetLimit>
</Target>
</Limit>

Example: a world with 20 billion people can have 6 Basic and 2 Xeno factories (or 4 Basic and 3 Xeno or some other combination). The result is that to have a lot of high order manufacturing plants you need a lot of population.

Optional additional uniquenesses:
Unique improvement within a solar system:
<Limit>
<Target>
<TargetType>Star</TargetType>
</Target>
</Limit>

Unique improvement within a galactic range - example 20 tile range:
<Limit>
<Target>
<TargetType>GalacticRange</TargetType>
<GalacticRange>20</GalacticRange>
</Target>
</Limit>

These additionals could enable things like the implementation of star, sector and empire capitals each giving for example additional (level and adjacency or even empire wide) bonuses.

Colony Capital:
<InternalName>ColonyCapital</InternalName>
<ImprovementType>Special</ImprovementType>
<ImprovementGroup>SpecialCapital</ImprovementGroup>
<Limit>
<Target>
<TargetType>ImprovementGroup</TargetType>
<ImprovementGroup>SpecialCapital</ImprovementType>
</Target>
</Limit>

Star System Capital:
<InternalName>StarCapital</InternalName>
<ImprovementType>Special</ImprovementType>
<ImprovementGroup>SpecialCapital</ImprovementGroup>
<Limit>
<Target>
<TargetType>Star</TargetType>
</Target>
<Target>
<TargetType>ImprovementGroup</TargetType>
<ImprovementGroup>SpecialCapital</ImprovementType>
</Target>
</Limit>
<UpgradesFrom>ColonyCapital</UpgradesFrom>

Star Sector Capital:
<InternalName>SectorCapital</InternalName>
<ImprovementType>Special</ImprovementType>
<ImprovementGroup>SpecialCapital</ImprovementGroup>
<Limit>
<Target>
<TargetType>GalacticRange</TargetType>
<GalacticRange>20</GalacticRange>
</Target>
<Target>
<TargetType>ImprovementGroup</TargetType>
<ImprovementGroup>SpecialCapital</ImprovementType>
</Target>
</Limit>
<UpgradesFrom>StarCapital</UpgradesFrom>

Empire Capital:
<InternalName>EmpireCapital</InternalName>
<ImprovementType>Special</ImprovementType>
<ImprovementGroup>SpecialCapital</ImprovementGroup>
<Limit>
<Target>
<TargetType>Player</TargetType>
</Target>
<Target>
<TargetType>ImprovementGroup</TargetType>
<ImprovementGroup>SpecialCapital</ImprovementType>
</Target>
</Limit>
<UpgradesFrom>SectorCapital</UpgradesFrom>

Any constant values should be take as placeholders for whatever value will balance best and are there just to clarify the structure.

The above is just something to show the direction of my thoughts. I do not expect that this will be implemented literary, but i wanted to start a discussion about what might be possible and how to possibly implement it.

Comments are as always welcome.

Locked Post

Advanced Search

Watch this post

Do not email me updates for this post Email me updates for this post

Successfully updated karma reason!

Ok, so this would mod the game to raise the amount of tiles you could terraform while also changing how many improvements you can actually have at any one time based on current population?

Am I reading that right?

I am ok with production buildings or research or any others 'limited' by population. However what I would like to see is being able to place them where I want and they 'build' when population reaches the required goal to allow the building to be built.

Successfully updated karma reason!

Thecw

Join Date 08/2012

+84

Larsenex,

You are reading it correctly. For the terraforming you can then actually say something like: Soil Enhancement gives maximum 4 tiles instead of one, Terraforming plant gives maximum 3 tiles instead of one, ultra terraformer is limited to a maximum of 6 tiles instead of only being limited by the terrain land percentage.

The auto upgrade should work and automatically upgrade an improvement the moment population size allows it.

Building a new (extra) building when population reaches the required goal is not implement as such. But it could be implemented by introducing an improvement that does nothing (and has no target limit and no building cost) but is upgrade-able to the desired improvement. Think of it as a building lot.

Successfully updated karma reason!

On paper that sounds fine but we would need an auditory or visual cue while in game to remind me to visit Alderan IV after 35 turns when the population reaches 12.6 billion so I can also build two more factories, another Farm, a Research coordination center and the new Quantum power plant......

Over all I like the trade off of increased tiles limited by population. However, the over all feel, feels like limiting me in choices because I will have to wait on population prior to placement....

Successfully updated karma reason!

+1 starting off with basics, then limiting when I could expand further with a certain pop level but at least allowing me to greater develope a planet over time, sounds a good compromise to me. Discussed on previous threads. Again, it's the let me expand a planet as I want, but make it restrictable over time/ tech, plot. So I need to focus on an increased population, to unlock further hexes after the required Tech is gained, including sea hexes for some improvements.

But, I repeat, can we at least choose our own capital hex, and plop down that improvement manually??! Would possibly make for much better strategic planning IMHO.

Successfully updated karma reason!

Thecw

Join Date 08/2012

+84

Larsenex,

First my intention was to show a (xml) structure that allows for more flexibility and is more resistant to faults.

Quoting Larsenex,

reply 3

Over all I like the trade off of increased tiles limited by population. However, the over all feel, feels like limiting me in choices because I will have to wait on population prior to placement....

But in my given examples of the xml structure: Concerning the terraforming, you don't get more tiles, you get them at a different times (better distribution).

	Current System	Proposed System
Soil Enhancement	Max 1	Max defined in xml (4 in given example)
Terraforming Plant	Max 1	Max defined in xml (3 in given example)
Habitat Improvement	Max 1	Max defined in xml
Resequencing Station	Max 1	Max defined in xml
Ultra Terraforming	No limit	Max defined in xml (6 in given example)
Biospheres	Max 1	Max defined in xml

Because every tile has an (invisible) land percentage value these also limit the number of tiles that can be terraformed. You can see the (highlighted) tiles which have an eligible land percentage when you are given the choice where to place the given terraforming tile.

Quoting Larsenex,

reply 3

Firstly, you get a notification because the 'Planet Idle' which forces you to visit the planet anyway. Secondly, when your population grows to the point that an upgrade becomes possible the auto upgrade should kick in to schedule the upgrade for you. But you are absolutely right that extra (new) improvements are not build automatically and must be placed by the player.

Lastly, i used population limits in the examples because it is the easiest conceivable limiter, but if this (xml) structure would be in place it would be possible to use other factors as limiters. Instead of population you could use happiness, wealth, influence or what every 'target' might be supported.

Successfully updated karma reason!

Thecw

Join Date 08/2012

+84

Quoting Tony2488,

reply 4

+1 starting off with basics, then limiting when I could expand further with a certain pop level but at least allowing me to greater develope a planet over time, sounds a good compromise to me

Tony2488,

It is not my intention to create larger planets, but to have better control over the pace (of terraforming) in which the planet is developed. And by having the possibility of limits on improvements to have better balancing control.

Quoting Tony2488,

reply 4

including sea hexes for some improvements.

I used terraforming in my examples because it is one of the discussed topics and one i think deserves some pacing control. But to actually allow for improvements to be build on top of sea tiles would demand a completely separate xml infrastructure.

Successfully updated karma reason!

Dr Franknfurter

Join Date 08/2005

+22

I think a more robust system would be very welcome. It may be helpful to use an example other than population for clarification of the potential scope of such a change. e.g. a theoretical system where Population buildings can't be built or upgraded when the world is full of pollution (measured as planet class / number of factories or planet class/manufacturing output). I assume if you can require a certain population level you could make any interesting requirements.

Or a system where military buildings can be built cheaply or free, but one per planet and only if the planet isn't heavily developed. Allowing for 'outpost' or specialisation options. (e.g. 1 per planet option requiring building count to be <=2.)

Mechanically though I'd say there are a couple of issues to address:

What happens when the prerequisites are no longer met (e.g. population/PQ loss after an invasion)? (buildings destroyed, downgraded, derelict or continues functioning)
How would you line-up buildings? Would you still be able to line them up but not have them start construction until the requirements are met. Or, would the buildings be greyed-out, marked in red or hidden when the requirements aren't met. (and require significant additional micromanagement)
How would it handle upgrading buildings when you have x improvements but only y of them would technically be able to upgrade? (bugs, priority of upgrades)
Lastly. Interface clarity. How would you show the requirements in the tooltip/description?

Successfully updated karma reason!

Thecw

Join Date 08/2012

+84

Quoting Dr Franknfurter,

reply 7

What happens when the prerequisites are no longer met (e.g. population/PQ loss after an invasion)? (buildings destroyed, downgraded, derelict or continues functioning)
How would you line-up buildings? Would you still be able to line them up but not have them start construction until the requirements are met. Or, would the buildings be greyed-out, marked in red or hidden when the requirements aren't met. (and require significant additional micromanagement)
How would it handle upgrading buildings when you have x improvements but only y of them would technically be able to upgrade? (bugs, priority of upgrades)
Lastly. Interface clarity. How would you show the requirements in the tooltip/description?

Dr Franknfurter,

The points you raise are valid concerns, however my primary purpose was to start a discussion about the underlying data structures and not about the user interface, nevertheless i will try to give you some answers:

We could let it behave to same as when you currently conquer a planet with improvements which you can not build: Keep them and use them. This would be the simplest to implement (because it is already designed behaviour).
The same as currently is used would be fine (with me): to not show up in the selectable improvements.
Then only y should be able to upgrade. Currently when you place (build) improvements this is also the order in which the auto upgrade routine schedules upgrades for these improvements. If you change the build (or upgrade) order in the build queue (and when they are completed) this will also alter the order in which the auto upgrade routine will schedule their upgrades in the future. I believe this behaviour is quite acceptable.
Honestly i have not given that any thought, because i was focused on the data structures. Someone who is better than i on interface design (and language use) might come up with some good ideas.

Furthermore i admit it is quite likely that it will increase the management of the planets (for the given examples), but in return you get a lot of strategic depth for it. And i personally am not adverse to (micro) management.

My final point is that i gave these examples to show what would be possible with the given proposed (xml) structure change, not that these examples should be literary implemented. If the shown manufacturing examples would be dropped then this would cause no harm, and the manufacturing plants would simple function and behave the way they do now. But by having the underlying (xml) structure ready for it, someone (Stardock or a modder) can unlock these advanced features with simple changes to the xml files.

Successfully updated karma reason!

Dr Franknfurter

Join Date 08/2005

+22

Thank you for answering. I mention user interface issues only to iron out any bugs or quirks it could introduce that could otherwise put-off devs. It all seems logical and sensible as an idea. I do enjoy thinking about how it could be used to improve the game. And obviously it's nice to imagine what it'd be like in practice to avoid it being fiddly or annoying.

I can picture lots of interesting ramifications of such a change for future race customisation too. The requirements for each race could be different even when the buildings are the same, e.g. having a negative manufacturing pick could reduce the number of factories you can build or their upgrade level. + Research pick could increase the labs you can support etc.

I'd do that by making the number of factories be based on % manufacturing bonus /10. Research or starbase effects would allow for more buildings and specialisation of a world. (In turn allowing improvements to have larger effects without worrying about people filling every single tile until very late game or on forge worlds).

Successfully updated karma reason!

Gilmoy

Join Date 12/2009

+41

i.e. you're defining the concept of "region" as a scope for limits. Equivalently, you're promoting regions to second(?)-class values. (They're not first-class because they're still hard-coded, not definable on the fly.)

Then it becomes trivial to impose region-wide limits for various buildables. The region takes over the role of encapsulating the "1-per-me" idiom.

Of greater interest, you've further broken down the "region" construct into quarks , using the generic XML primitive of <Limit><TargetType><Target>. This suggests that the internal C++ meta-object protocol(?) engine need only implement <Limit> once, with maybe a small library of allowed <Target>s. That's conceptually no greater burden than the engine already implements, because obviously it already has internal code to enforce 1-per-X restrictions for various Xs. In this proposal, they simply expose those Xs as the enumeration of <Target>s.

Note that this is still a bit verbose in XML, which is both good and bad. It's good that it's scriptable. It's awkward that you must script it every time. Taking it to the logical extreme, we'd chunk all of these nearly-identical XML chunks into a new XML keyword, e.g. <LimitPerColony>6</> automagically expands to the equivalent block of XML.

To promote regions to first-class values, we'd need a scriptable way to define our own regions. For example, imagine modding a Singularity Cannon with the restriction that only 2 can exist within a 3-hex radius. You'd define "3 hex radius" as a region: <TargetType>Spatial</> with <Radius>3 and <Count>2. Then whenever you build a ship with this component, the component automatically enforces the 2-of-me-within-3-hexes limit. It'd be ... rich in utterly unforseeable ways. This is both the argument in favor of promoting things to first-class values in a language, and ... the argument against it

Successfully updated karma reason!

Thecw

Join Date 08/2012

+84

Quoting Gilmoy,

reply 10

using the generic XML primitive of <Limit><TargetType><Target>. This suggests that the internal C++ meta-object protocol(?) engine need only implement <Limit> once, with maybe a small library of allowed <Target>s. That's conceptually no greater burden than the engine already implements, because obviously it already has internal code to enforce 1-per-X restrictions for various Xs. In this proposal, they simply expose those Xs as the enumeration of <Target>s.

I tried to stay as close as possible to the already used xml schema layout pattern, so that the impact of the change on the engine would be as minimal as possible. By using the triad (<Limit>, <Target> and <TargetType>) you can specify a limit that has multiple targets each with a non-fixed condition. Like i show in the example sequence of the capitals (Colony, Star, Region, Empire).

With <LimitPerColony>6</> i assume you would mean this as an equivalence (macro) to:
<Limit>
<Target>
<TargetType>Colony</TargetType>
<TargetLimit>
<Count>6</Count>
</TargetLimit>
</Target>
</Limit>

My reason for the 'long' form is that the current 'short' forms (<IsPlayerWonder>true</IsPlayerWonder> and <IsColonyUnique>true</IsColonyUnique>) are to limited. So i have rather a 'long' versatile version than several more 'short' forms of limited usage.

Talking about quarks: If i would be a quark, i would be the strange charming one up on top looking down on the ones on the bottom, and no strong force would stop me from colliding with any hadron who would stand in my way of existence.

Successfully updated karma reason!

Thecw

Join Date 08/2012

+84

As advised in the Dev Stream (Friday, November 14th), i should yell for Alan, so here i go:

Hey Alan, take a look and tell me what do you think of this proposal? Is something along these lines possible?

I hope this was loud enough, i really don't like to yell.

Successfully updated karma reason!

DARCA1213

Join Date 01/2014

+106

I hate this, and not because it emphasizes population but its sorta boring confusing and meta compared to just building thing with the current standard. I don't think it is fun.

Also the current improvement upgrade system needs to be reworked if anything, it takes to long to upgrade to mid/late game improvements and wastes production.

DARCA

Successfully updated karma reason!

Thecw

Join Date 08/2012

+84

Quoting DARCA1213,

reply 13

I hate this, and not because it emphasizes population but its sorta boring confusing and meta compared to just building thing with the current standard. I don't think it is fun.

Again my purpose of this thread was the extension of the underlying XML structure, not the actual implementations of the given examples. I believe i use the word 'example' quite a few times in the original post and also in the later replies. I thought you as a proponent of modding would be happy with the additional control, versatility, and improved robustness this proposed xml structure alteration would grant.

Successfully updated karma reason!

DARCA1213

Join Date 01/2014

+106

Yea yea yea, I read all that stuff later, I just hate improvement limits, as was your confusing example.

Its a good suggestion in the way you proposed though, and I didn't know I was a known "proponent of modding" lol

DARCA. a proponent of modding since January 14th, 2013.

Successfully updated karma reason!