Buildings Model Quickpad
- 1 New
- 2 Future
- 3 Solutions?
- 4 Other Ideas
- Want to be able to have some buildings unlocked at start of game.
- In future, want to be able to have different empires start with different buildings unlocked at the start of the game, so "unlocked at start" shouldn't be a property of the building, but of something attached to each in-game empire.
- Want to reduce amount of hard-coded game numbers, to be replaced by effects
- In future, want to be able to have different empires have different effects groups for those that replace the hard-coded game numbers
Have a new xml file that contains "empire template" definitions.
Aside: Could perhaps be called a "culture", but this term might be used for something else as well. It probably can't be called just "empire" since in game, "empire" already refers to the set of planets and ships and related info that a player controls; I'll call this set the "in-game empire".
An empire template would be a attached to a player's in-game empire. At the start of the game, all players, Human and AI, would be assigned empire templates for their in-game empires. Multiple players' empires could have the same template. This would be like having two empires in MOO3 that are of the same race. They would be separately in-game empires, but based on the same empire template and thus would have the same starting techs and empire-specific bonuses or penalties.
Empire templates would act like techs that their associated in-game empire knows. They would have effects that would work just like tech effects, and they could unlock buildings. They would be different from techs in that they wouldn't appear on the tech screen, wouldn't be reserached, and in future, wouldn't be tradeable or stealable, and would never be referred to by in-character game text. By that, I mean that other empires in the game will probably specifically offer to trade for particular techs you know, so in-game characters know that "Techs" as a game concept exist. In-game characters would not know about "empire templates", however, and would perceive their effects as inherent to the in-game empires they are associated with.
To make a building unlocked at the start of the game, it would be added to the <unlocks> tag of the template.
Empire templates could, and IMO should, also replace many of the current hard-coded effect-type bonuses to planets. Until we add races, empire templates should include a set of effects that determine the maximum population numbers and default meter levels of planets. Planets should default to 0 for all their max meters, and would get the current hard-coded increases to max meters of planets from the effects of its empire template.
For now, since empires haven't been decided on and aren't scheduled for a while, there only needs to be a single "Default" empire template.
A similar mechanism should be created to replace all hard-coded adjustments to meters that occur in the game with effects-defined adjustments. These include:
- Setting max population of planets due to type, size, environment, etc.
- Bonuses to meters due to focus effects
- Bonuses to planet health meters due to environment type
- Bonusus or penalties to planet health due to availabilitly or lack of food. (This will require a new "FoodSupply" condition that matches planets in a particular range of food supply levels.
- Population, Resource and Construction current meter growth
Placing all these in effects makes modification simple, and allows variation between races or empires.
- Want to be able to write conditions or effects that determine whether already-unlocked buildings can be built at all (distinct from location conditions)
- Want to be able to limit the number of buildings of a particular type on or in a planet, system, empire or galaxy, or within a certain distance or number of starlane jumps.
- Add a new effect: SetBuildingAvailability effect, which would act essentially the same way as the SetTechAvailability effect.
- Want to be able to have buildings' or techs' availability to be built or researched depend on things other than whether the player has researched a particular tech or set of techs.
- Want to have "OR" as well as "AND" prerequisites for techs. eg. must research (at least two of these three techs) AND (this other tech)
- Want to be able to do various cases and combinations:
- Make a tech become available after researching all its prerequisites, or after being made available by an effect. eg. can research prerequisites, or can find special resource/special that makes tech available without its prerequisites
- Make a tech become available only after researching all its prerequisites and having an effect make it available. eg. must research prerequisite and must have certain resource/special make tech available; just effect, or just prereqs alone isn't enough.
- Make a tech that has no prerequisite techs, but which is not available at the start of the game: it must be unlocked or granted by an effect
- For techs, create a flag to put in <prereqs> which prevents the tech from ever becoming available due to researching other techs. This flag might be something like NONEXISTANT_TECH. The only way to make such a tech available to be researched would be to use the SetTechAvailability effect. This might be used by a planet special that acts on its source object, to allow the owner of the planet with the special to research a particular tech.
- For buildings, could add a separate <availability> condition, or can just use existing <location> condition.
Should have some concept of strategic resources. Should be able to requiring an empire to have access to a special resource and be able to supply that resource to the build location (ie. not being blockaded) See User:Geoff_the_Medio/Musings#Strategic_Resources.
We can already specify the maintenance cost for buildings, as indicated in the Effects page, but this idea needs to be extended to cover what happens if maintenance is not paid. This may be integrated with the following section, Building Enabling.
Building Enabling / Disabling
Buildings mostly (exclusively?) do their jobs through their effects groups, which already have activation and scope conditions. These are very useful and versatile, but they have some limitations that are problematic for buildings. In particular, we need ways to enable to enable or disable or change buildings' effects groups for reasons such as:
- unpayed maintainance
- player choice (requiring UI integration)
- technology prerequisites (new ones gained or previously known ones lost)
- non-tech prerequisites, as discussed above
- unmet limits, as discussed above
- after a fixed delay, or at a certain time
A mix of new effects and conditions and non-effects methods will likely be needed to impliment the desired functionalitly.
New Effect: ResetTimer, New Condition: TimerValue
ResetTimer: Sets building property: Timer, to 0
Each turn, timer is increased by 1 (automatically)
TimerValue: Works like MeterValue conditions. Has <max> and <min> fields. UniverseObjects with Timer properties between <min> and <max> are matched.
The timer value gives the number of turns since it was last reset. The TimerValue condition could be used to determine if a fixed number of turns has passed, or to schedule a series of effects groups on different turns.
New Effect: SetEnabling, New Condition: Enabled
Objects would have a new binary property "Enabled".
The SetEnabled effect would set Enabled to true or false (1 or 0).
The Enabled condition would match all objects which have Enabled = True.
The Enabled flag of an object would be altered in a manner similar to the meter values of production centres through various non-effects mechanisms. For example, if a building's maintainance is not paid, or a player uses the UI to disable a building, then Enabled would be set to false. The activation condition for the building's effects would have <Condition::Enabled/>, meaning the effects would only work for enabled buildings.
Sidenote: Turn off Maintainance
It would also be useful to be able to turn off or alter maintainance fees for buildings that the player has disabled through the UI. This could be done via fields in the building description like <enabledmaintainance> and <disabledmaintainance>, or through a more complicated effects-based system. The enabled / disabled flags should be sufficient, though.
Being able to set whether a building is visible to non-allied empires of the owner would be useful. This would ideally be separately settable while the building is under construction, and after it is finished. This would mean that some buildings are always visible to empires that can see into a system (before and after the buildigns are completed), but some are visible only when complete (not while under construction), or are never visible, or visible while under construction but not when complete. This could also be represented as a visibility rating, rather than just on/off, similar to the proposed starlane visibility system.
Having buildings be invisible would be useful for setting traps, or honeypot-systems, that look tempting, but which have major negative consequences for any invaders who capture it. Having buildings be visible while under construction and not when finished, or vice-versa, could make for interesting / fun races against the "clock" to keep something hidden, or sudden surprises when a finished building pops up unexpectedly... and also makes for a strong justification for espionage and detection technology, like with starlanes.