Difference between revisions of "Buildings Model Quickpad"
m (→Consequences for Production)
|Line 51:||Line 51:|
* For buildings, add a separate <availability> condition...? (Still need to think about this)
* For buildings, add a separate <availability> condition...? (Still need to think about this)
Revision as of 20:28, 9 March 2006
- 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: Can't call these "races" since each in-game empire could have multiple races: different ones on each planet. It 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.
Building Location Conditions & Availability
- Want to be able to write conditions that determine the valid locations where buildings can be produced
- Want to be able to write conditions or effects that determine whether already-unlocked buildings can be built at all
- 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 condition field to Building definitions: <location>. All valid production locations for a building would have to pass the <location> condition.
- Add a new effect: SetBuildingAvailability effect, which would act essentially the same way as the SetTechAvailability effect.
- Add a new condition: Number (distinct from NumberOf), which has a sub-condition and two parameters: <min> and <max>. If the number of objects that match the sub-condition is in the range <min> ... <max>, then the Number condition matches all objects. Otherwise, it matches no objects.
- 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, add a separate <availability> condition...? (Still need to think about this)
UI / Consequences Details
Available buildings may be placed in the build queue (enqueued) at any time, regardless of whether their location prerequisites are currently met. If a building has been enqueued, and its location prerequisites are not met, it remains on the queue. If a building has been enqueued, and it becomes not available, it is removed from the queue.
Every turn, if an enqueued building is prioritized high enough on the queue to receive PP, its BuildLocation and Availiblity conditions is checked. If the build location and producing empire's homeworld meet their conditions, then the building receives its PP for that turn. If either condition is not met, the PP are passed to the next item on the queue for (potential) use.
PP may be spent on a building (and a turn of its build time completed) only if the building's prerequisites are met on a given turn. There is no distinction between the first or subsequent turns, and no distinction between player-paused, pasued due to underfunding on previous turns, or paused due to prerequisites not being met; any of these causes the building to not have any PP spent or build time completed for a given turn.
If a building has been partly finished, and it is paused due to player choice, insufficient funding or prerequisites not being met, the spent PP and completed turns are retained. If in future, the prerequisites are met, there is suffient funding and the player so choses, the building is resumed from where it was when building was halted.
No spent PP are lost due to pausing, underfunding or unmet prerequisites. However, this does not preclude the possibility of sabotage or accidents destroying a partly built building (all production lost) or setbacks in production (one or more turns toward completion time lost).
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 Condition: TechKnownToEmpire
This condition would match all objects owned (exclusively or not) by an empire which knows a particular tech. This would allow effects groups to be activated or not, or their scopes to include or not based on whether they or other empires know a particular tech. This would be useful for:
- specials that only work if you know a particular tech, such as space anomalies that give bonuses
- making buildings obsolete / partly obsolete after discovering a particular tech. A building could have one function, then stop the old or start new functions when a particular tech is discovered
- having effects that fire on other empires than the source's owner if the other empire does/doesn't have a particular tech
There should be a "Location" condition for building types, similar to scope conditions for effects. This condition would include all valid production locations for the building type.
There should also be a "Availiblity" condition, similar to activation conditions for effects. This would start with just the homeworld of the empire who is trying to produce the building in its scope, and would apply the condition indicated. This would whether buildings are available to be built, regardless of location.
New Effect: ResetTimer, New Condition: TimerValue
Note: This section may be redundant with the tzlaine's events system. Based on his description of that system however, this effect and condition seem like they would still be useful.
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.