|
|
| Line 1: |
Line 1: |
| − | This is a draft pseudo-brainstorming attempt to resolve some issues with the current buildings model. Nothing (new) here has been passed.
| + | Unfortunately, this project has been closed due to lack of activity and our recent troubles with our domain. We thank all those that supported us. Perhaps we can meet again in a new project. |
| | | | |
| − | As an aside, some of the suggested additions discussed here would be useful for things discussed on the [[SpecialsEvents]] page that Drek made. Also see [[Talk:SpecialsEvents]] for some discussion that lead to some of the ideas presented here.
| + | Tyreth and Aquitaine |
| − | | + | |
| − | ==Issues==
| + | |
| − | | + | |
| − | The non-effects details of the buildings model need to be worked out. Some isses to consider include:
| + | |
| − | | + | |
| − | ===Prerequisites (non-Tech)===
| + | |
| − | | + | |
| − | Besides the technologies that unlock a particular building, we may want to be able to restrict where and when a building can be produced. Possible restrictions include:
| + | |
| − | * Requiring the presence of another building at the build location
| + | |
| − | * Requiring a particular special to be present at the build location
| + | |
| − | * Requiring a particular planetary environment, star colour, minimum population, meter values, etc. at the build location
| + | |
| − | * Requiring the empire to be in control of planets or systems that contain
| + | |
| − | ** Specific special(s)
| + | |
| − | ** Specific building(s)
| + | |
| − | ** Certain numbers or combinations of the above
| + | |
| − | * Requiring the empire to have access to a special resource and be able to supply that resource to the build location (ie. not being blockaded)
| + | |
| − | | + | |
| − | ===Limits===
| + | |
| − | | + | |
| − | We will want to be able to limit on the number of buildings of a particular type on or in a planet, system, empire or galaxy, or within a certain distance of other (same or different?) buildings.
| + | |
| − | | + | |
| − | It may also be desirable to prohobit a building from being placed at or within a range of a non-building object or special.
| + | |
| − | | + | |
| − | If limits are not met, it is (presumably) already possible to disable the offending building(s) effects groups for those conditions which are already available. It should be similarly possible to disable effects due to any added limits.
| + | |
| − | | + | |
| − | ===Maintenance===
| + | |
| − | | + | |
| − | 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
| + | |
| − | | + | |
| − | ===Refinements===
| + | |
| − | | + | |
| − | tzlaine is has added the ability to add additional effects groups to buildings, in order to "refine" them. This should be extended to allow removal or deactivation of effects groups as well.
| + | |
| − | | + | |
| − | ==Solutions?==
| + | |
| − | | + | |
| − | 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
| + | |
| − | | + | |
| − | ===Production Prerequisites===
| + | |
| − | | + | |
| − | ====Conditions====
| + | |
| − | | + | |
| − | Various conditions would be good to have to restrict or enable building of buildings at particular locations. Immediately relevant ones include many of the current Effects conditions, including:
| + | |
| − | * Presence of Building on same planet
| + | |
| − | * Presence of Special on same planet
| + | |
| − | * Distance-dependent versions of the above
| + | |
| − | * Empire Affiliation-dependent versions of the above
| + | |
| − | * Planet Environment
| + | |
| − | * Star Colour
| + | |
| − | * Planet Focus Type
| + | |
| − | * Meter Values
| + | |
| − | * Techs Known to Empire doing building (suggested TechKnownToEmpire condition)
| + | |
| − | * AND, OR & NOT combinations of conditions
| + | |
| − | | + | |
| − | Additional conditions concerning the presence and number of buildings in the empire or galaxy would also be useful. These may be implimentable using the already available conditions, however. It will be necessary to restrict and enable building production by:
| + | |
| − | * Presence of same building elsewhere in empire
| + | |
| − | * Presence of same building anywhere in galaxy
| + | |
| − | | + | |
| − | Ideally it would be possible to extend these conditions so that they can check for any number of instances of a building, not just one or more. For example, an empire could have at most 5 of a particular building, after which, no more may be built.
| + | |
| − | | + | |
| − | ====Consequences for Production====
| + | |
| − | | + | |
| − | Buildings may be placed in the build queue (enqueued) at any time, regardless of whether their prerequisites are currently met. If a building has been enqueued, and its prerequisites are not met, it remains on the queue.
| + | |
| − | | + | |
| − | 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.
| + | |
| − | | + | |
| − | Note that 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).
| + | |
| − | | + | |
| − | ====Note about Tech Condition====
| + | |
| − | | + | |
| − | Regarding the above mention of a building prerequisite based on "Techs Known to Empire doing building (New TechKnownToEmpire condition)": This is distinct from the idea of a tech which unlocks / locks a particular building. With lock / unlock, the availablility of a building is set by an effect, and is on/off.
| + | |
| − | | + | |
| − | This prerequisite would be an additional requirement above and beyond being unlocked. A particular technology would be required to be researched in order for the building ot be built. An unlocked building could not be built if this, or any other, prerequisites are not met.
| + | |
| − | | + | |
| − | ===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 Condition: GalaxyTurn===
| + | |
| − | | + | |
| − | The galaxy would have a property: CurrentTurn, which would return the integer number of the current game turn. This could be referenced in effect magnitude expressions.
| + | |
| − | | + | |
| − | The GalaxyTurn condition would match any object if the CurrentTurn number was within the range specify in the condition, using <max> and <min>, similar to MeterValue.
| + | |
| − | | + | |
| − | ===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.
| + | |
| − | | + | |
| − | ===New Condition: NumberOfObjects===
| + | |
| − | | + | |
| − | This condition would have have parameters: <max>, <min>, and <Condition>.
| + | |
| − | | + | |
| − | <Condition> would be another condition within this condition, similar to that of the [[Effects#WithinDistance]] condition.
| + | |
| − | | + | |
| − | <max> and <min> are integers.
| + | |
| − | | + | |
| − | This effect would match all objects if the number of objects that match the inner condition is between the extends specified by <min> and <max>.
| + | |
| − | | + | |
| − | For example, if the inner condition is <Condition::PlanetEnvironment>, the number of planets of the specified environments in the galaxy would need to be between the specified <max> and <min> values.
| + | |
| − | | + | |
| − | The inner condition determines whether the NumberOfObjects condition matches all or no objects in the universe. If the inner condition matches some objects, but this number is not in the range specified by <min> and <max>, all objects are not matched by NumberOfObjects, including those that are matched by the inner condition.
| + | |
Unfortunately, this project has been closed due to lack of activity and our recent troubles with our domain. We thank all those that supported us. Perhaps we can meet again in a new project.
