Building uniqueness and limits

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. 

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.

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....

+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. 

Larsenex,

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

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).

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.

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.

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.

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.

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:

1. What happens when the prerequisites are no longer met (e.g. population/PQ loss after an invasion)? (buildings destroyed, downgraded, derelict or continues functioning)
2. 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)
3. 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)
4. 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:

1. 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).
2. The same as currently is used would be fine (with me): to not show up in the selectable improvements.
3. 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.
4. 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.

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).

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

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.

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.

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

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.

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.