Difference between revisions of "Buildings Model Quickpad"

From FreeOrionWiki
Jump to: navigation, search
Line 114: Line 114:
  
 
The galaxy would have a property: CurrentTurn, which would return the integer number of the current game turn.  The GalaxyTurn condition would match any object if the GalaxyTurn number was within the range specify in the condition, using <max> and <min>, similar to SetMeter.
 
The galaxy would have a property: CurrentTurn, which would return the integer number of the current game turn.  The GalaxyTurn condition would match any object if the GalaxyTurn number was within the range specify in the condition, using <max> and <min>, similar to SetMeter.
 +
 +
===New Effect: SetEnabling, New Condition: Enabled===
 +
 +
Simialar to the above Register property, 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.

Revision as of 11:06, 20 December 2004

This is a draft pseudo-brainstorming attempt to resolve some issues with the current buildings model. Nothing (new) here has been passed.

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 first
  • Requiring a particular special to be present, and/or be known to exists on or in the planet, system, empire or galaxy
  • Requiring a particular planetary environment, star colour, minimum population, meter values, etc. for a building to be produced
  • Future: Some sort of Civ3-like special resources model, of somewhat more complexity than the above requirements for particular specials

Limits

Similar to prerequisites, but opposite in effect, limits indicate when a particular building may not be built, despite all other requirements being met. Possible limits include:

  • A limit on the number of buildings of a particular type on or in a planet, system, empire or galaxy, or within a certain distance.

This could be implimented using some sort of "building stacking group", similar to the stacking groups used with techs.

Maintainance

We can already specify the maintainance cost for buildings, as indicated in the Effects page, but this idea needs to be extended to cover what happens if maintainance 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 buildings' effects groups for reasons such as:

  • unpained 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 already working on a way for effects to alter building descriptions for the purpose of refinements.

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 (New TechKnownToEmpire condition)
  • AND, OR & NOT combinations of conditions

It may be simplest to implement prerequisite conditions using many of the same conditions as are available in activation and scope.

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

Consequences for Production

The consequence of a production prerequisite not being met is not yet well defined. There are several options:

  • Buildings may not have any PP placed towards their completion while prerequisite conditions are not met. Any previously applied PP remain spent, and building may be resumed if and when prerequisites are met
  • Building production may not be initiated while prerequisite conditions are not met, but if already started, production may continue to completion.
    • This may mean that if a building is paused due to underfunding, it cannot be resumed until prerequisites are met
    • This may mean that buildings may be paused and resumed even if prerequisites are not met, and that the only restriction is on the intial first turn of funding, or even the very act of putting the building into the build queue (however this would be problematic, as it would give an incentive to fill the build queue with things you don't currently want to build, lest they become unbuildable due to prerequisites becoming unmet)
  • Building production may not be initiated if prerequisites are not met, and if prerequisites are not met during any turn after initiation but before completion, all progress in production is lost and building is removed from the build queue.

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: SetTimer, New Condition: TimerState

(To be fixed up...)

Set Timer: Sets building property: Timer, to natural number value (integer > 0).

Each turn, timer is reduced by 1 towards 0, or remains at 0 if already = 0.

TimerState condition has option: <Activated>

<Activated>1</Activated> means condition matches objects whose timer = 0

<Activated>0</Activated> means condition matches objects whose timer > 0

Optional: New Effect: SetRegister, New Condition: RegisterValue

(To be fixed up...)

This extends and replaces the SetTimer and TimerState Conditions.

Each object would have (at least) one externally readable and settable value known as a register. The value would be accessible like other object properties, as "Source.Register" or "Target.Register", for example.

The SetRegister effect would alter this value just like SetMeter alters meter values, using mathematic expressions where applicable, such as "Target.Register - 1", which would decrement the register by one each turn, replicating the functionality of a timer.

The RegisterValue would function just like the MeterValue condition. <max> and <min> values would be specified, and all objects whose Register's value is within these ranges would be matched.

New Condition: GalaxyTurn

The galaxy would have a property: CurrentTurn, which would return the integer number of the current game turn. The GalaxyTurn condition would match any object if the GalaxyTurn number was within the range specify in the condition, using <max> and <min>, similar to SetMeter.

New Effect: SetEnabling, New Condition: Enabled

Simialar to the above Register property, 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.