EffectsG

From FreeOrionWiki
Revision as of 19:37, 19 April 2005 by Wraith (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

Introduction

Terminology

"Effects" are changes/modifications to game objects.

"Game Objects" include the player-visible parts of the game simulation, such as empires, systems, planets, buildings, ships and specials. Game objects may also be invisible to the player, and be used internally by the game to simulate / maintain the gamestate.

Game objects also each contain a list of groups of effects. A particular game object's effects groups determine many of the ways it iteracts with the other game objects. For example, a building might have an effects group containing an effect which alters a meter of a planet. Alternatively, a special attached to a system might have an effect in a group which makes all ships in the system have nonfunctional shields. A player-visible game object may contain no effects groups, and a player-invisible game object may contain multiple effects and groups, allowing for flexible in-game collection of effects that work together.

General Conception

The basic goals of effects are:

  • To influence how the game calculates basic game functions such as production, population, ship movement (not in v0.3), etc., but not to actually calculate or impliment these results in most cases
  • To permit additional manipulations of the game state beyond those provided by basic game functions
  • To do both of the above in a very customizable and moddable way, using data files external to the program to define relevant game content

To achieve these goals, the effects system requirements in this document allow (and require) the creating, in XML files (or similar), of template classes of game objects in various categories, which provide all of the "content" of the game. The specifics of the non-effects details of the content system are not relevant to the effects portion of the design, so will be described in detail elsewhere.

Game Objects

Game objects are of a particular class. The class description of a game object is contained within an XML file (suggested). For a given class, this description indicates all the groups of effects and the effects they contain, contains all information about how the effects function, a category or "type" (eg. building, special, ship...) into which the game object falls (to enable to the game to deal with the object internally other than through effects), indicates how the object is represented to the player (if it is visible) and indicates any other necessary information about the object. The other "necessary information" is quite substantial, and is intentended to provide the majority of the game content in XML format (see below).

The "type" of an object is a general category, whereas class is a detailed, specific case of a type. "Building" is a type, whereas a "Level 5 Farming Enhancer" would be a specific class of object, defined in an XML file, and buildable by players in the game, assuming they have the appropriate in-game prerequisites (which falls under "other necessary information").

Game Object Descriptions include the following information which are relevant to the effects system (as well other necessary information):

  • Type - the type of a game object determines how the object is managed by the game code in general. Specific types may be determined by programmers, but suggestions include buildings, specials, ships, technologies, planets, systems etc. In practice, "type" may be an object property, or treated as a particular programming code-class. In either case, "type" needs to be an settable property for objects in XML files, and accessibe for effects in game (see below).
  • Duration - how many turns the game object remains in the game before disappearing on its own. This may be nonzero positive, indicating a limited duration in turns, or may be zero, indicating an infinite duration game object, that never disappears unless destroyed by an effect (of its own, or another object).
  • Effects Groups - a detailed list of groups of effects and information about their functionality (see below).

Effects Groups

Effects are listed in groups. Each effects group contains one or more effects that work together on the same game objects simultaneously, subject to the same activation and scope conditions.

A given effects group may contain either a) effects that modify meters or b) effects that do not modify meters, but not both (a) and (b).

Effect Group Descriptions

For each effects group for a game object, the following are indicated:

  • Effects - a list of effect classes for the group. Particular classes may be duplicated, optionally have different parameter values. See below.
  • Scope Conditions - a list of scope building and limiting conditions that determine what game objects the effect of the group fire upon, in addition to any restrictions implied by the individual effects classes. See below.
  • Activation Conditions - a list of conditions that determine whether the effects of a group will be fired on a given turn. See below.
  • Parameters - for individual effects in a group, and for scope and acitvation conditions for the whole effects group
    • Effect Parameters - details about how each individual effect should work. Indicates individually for each effect in the group.
    • Scope Condition Parameters - details about how each inclusive or exclusive condition used to determine the scope of the effects group should work.
    • Activation Condition Parameters - details about how each activation condition determines whether the effects of the group will fire during a turn

Note: In the following, the "source object" or "source" or "effect source" of an effect is the object which contains the effect in question.

Effects for v0.3

Modify Planet Max Meter

(Specified Amount, Specified Meter) - Adds or subtracts from a planet's max meters this turn. Does not affect current meter values. Aside: Max meter values are modified primarily by effects that consistently fire every turn, establishing a consistent max meter value

Modify Planet Current Meter

(Specified Amount, Specified Meter) - Adds or subtracts from a planet's current meter values. Does not affect max meter values. Aside: Current meter values are modified rarely compared to max meter values. Current meter modifications are also primarily by one-shot effects, rather than effects that consistently fire every turn, as this would cause the current meter value to grow very much each turn.

Modify Empire Stockpile

(Specified Amount, Specified Resourse) - Adds or subtracts from one of empire's stockpiles.

Set Planet Size

(Specified Size) - Sets the size property of a planet to a specified value.

Optional: Modify Planet Size

(Specified Change) - Increases or decreases the size of a planet by a specified number of sizes. Planet sizes are ordered tiny, small, medium, large, huge.

Optionally, asteroid belts may be placed below tiny, and gas giants above huge.

Planet environment is normally unchanged during a size change. In the case of growing larger than huge, or smaller than tiny, environment should be set to the appropriate environment for those types of planets, though retaining the original environoment of the planet as a property of the planet while it is an asteroid belt or gas giant would be desirable. In the case of a planet that has always been an asteroid belt growing larger, the environment of the new planet should be barren. In the case of a planet that has always been a gas giant growing smaller, the environment should be toxic.

Set Planet Environment

(Specified Environment) - Sets the environment property of a planet to a specified value.

Create Object

(Specified Object Class) - Creates new game object(s). If applicable, location and empire ownership are the same as the game object being fired on by the effect. This is obviously a rather complicated and multi-functional effect, with numerous possible variations in behaviour depending on the types and number of game objects being created. As such, it may be more convenient to separate this effect into numerous separate effects in order to create objects of any given category (buildings, ships, specials, etc.) which appropriate parameters for each. The specifics of this are left for programmer judgement to decide.

Destroy Object

(No Parameters) - Destroys game object(s).

Set Empire Tech Availability

(Specified Technology, Specified Yes/No) - Sets a tech as available to be researched or not for empire. Implimentation note: the availability should be maintained as a property of the tech or the empire.

Set Empire Building Availability

(Specified Building Class, Specified Buildable / Not Buildable) - Sets a building type as buildable or not for empire. Implimentation note: the availability should be maintained as a property of the building class or the empire.

Set Ship Type Availability

(Specified Ship Class, Specified Buildable / Not Buildable) - Sets a ship class as buildable or not buildable for empire. Implimentation note: the availability should be maintained as a property of the ship type or the empire. Future note: In future, presumably this effect will be obsolete and replaced with effects to mark individual ship components as available or not. This will occur after a ship design system is designed (and implimented).

Set Star Colour

(Specified Star Colour) - Sets the colour of a star.

Future: Set Target

For v0.3, this effect is not required. It is largely dependent on some sort of user-interface which is capable of interacting with game objects and their effects, which is not yet specified in the requirements, and will likely be delayed until v0.4 or later.

(No XML Settable Parameters, possibly some UI/AI parameters or controls) - Sets the "target" property of a game object. "Target" would be a run-time-only settable property of a game object, which could be used to specifically and persistantly alter its behaviour and/or limit the scope of its effect(s).

This would not be configurable from an XML file. Rather it would need to bet set at run time as either part of the Create Object effect, using the Set Target effect, or by some other means. For example, a building on a planet could fire Set Target on itself to target a particular ship with some effect every turn. Alternatively, a special space-monster controlling ship could use Set Target to cause space monsters to attack a specific enemy ship (assuming that a space monster game object's "Target" property was used to keep track of what ship it was current hunting).

The specifics of how this effect works with scope conditions is not yet fully conceived. A single scope is likely insufficient, as there needs to be some way to specificy both what object to fire the effect on, and what object to which to set the fired upon object's target. Limiting objects to only firing set target only onto themselves might work, using scope to determine the new target, however this is inconsistent with the standard use of scope to determine which object(s) to fire upon.

How to decide how and when to fire Set Target is also not clear, nor is the persistance of the effect between turns (must Set Target be used every turn to maintain its effect?).

In any case, in future design versions, it is likely that some degree of user or AI interface with the effects system will be necessary. The details of "Set Target" and similar effect classes can be fleshed out and refined at that time.

Effect Scope and Scope Conditions

The set of game objects (planets, ships, stars, buildings, specials) that are fired upon by an effect are collectively known as the effect's scope. Scopes are determined using scope conditions, which are described as part of an effects group (not individual effects). All effects in an effects group share the scope of the effects group, except that some effects may be incapable of firing on certain objects in their group's scope, in which case the unfirable effects are ignored for the objects in question. Other effects in the effects group still fire on such objects, and effects ignored for an object still fire on other objects in the scope, if they are able to do so.

The scope of an effects group is determined using conditions in two steps.

The scope is initially empty, and game objects are first put into the scope using 'inclusive' conditions. In this stage, a given game object is either included, or not yet included in the scope. Being included by more than one condition causes no further change (no multiple inclusion of a single object). A particular inclusive condition may either add objects to the scope, or may have no effect.

After all inclusive conditions have been applied, 'exclusive' conditions are used to exclude game objects from the scope. A given 'exclusive' condition may either exclude objects from the scope, or have no effect.

All conditions are evaluated at the time the effects of the group fire, so an object may be part of an effect's scope for one firing, but not another firing during another turn. A given effects group may only contain meter-altering or non-meter-altering effects, so a given effects group only fires effects once per turn (see below).

The scopes of each non-meter altering effects group is determined before any of the group's effects fire. The scope of the effects group is thus the same for all effects in the group, even if one effect in the group changes properties of a game object such that it no longer meets the group's scope conditions before all effects have fired. A special case of this rule is the firing of effects which destroy game objects. If an effect destoys a game object in the group's scope, then no additional modification to the destroyed game object are necessary, so the destroyed object may be removed from the scope.

Scope conditions are checks of various properties of game objects. Some scope conditions are based on properties of the object being checked by the condition, and others depend on other objects associated with the object being checked. For example, a building may be checked for exclusion from the scope according to a planet environment condition. The building itself has no planet environment, however the building is attached to a planet, so the environment of the planet is check for the purposes of determining whether the building is excluded from the scope of the effect. Attachments form a tree, so if the building was checked by a condition for a property that neither it nor the planet it is attached to have (such as star colour), the system in which the planet is located would be checked. If no objects in the tree of attached objects for a given potential scope object have a property being checked for, then the object is excluded by default. For example, if a ship was checked for star colour while it was not in any star system, the ship would be excluded from the scope of the effect.

If a condition description (below) states that it excludes objects from the scope by some property, or "their" some property, a hierarchy is used when necessary to attempt to determine what value of the property applies to the game object.

The hierarchy of attachment for scope condition purposes in v0.3:

  • Buildings are attached to the planet on which they are located.
  • Planets are attached to the system in which they are located.
  • Ships are attached to the system in which they are located (if applicable), or nothing (if not in a system).
  • Specials are attached to the game object they are associated with (as / if applicable)

Note that the hierarchy described above is only used when checking for a property not specified for a given game object. This means that the object does not have a particular property, but is distinct from some cases in which an object has a property, but that property is set to "none". (Example: A space monster or uninhabited system are owned by no empire, but both still have the empire ownership property) The hierarchy is thus used only when necessary to determine a property value for a game object.

Note also that targetting of empires, as opposed to other game objects owned by empires, may be "loose". By this, it is meant that an effect that is described above as setting some property of a particular empire may be targetted to that empire directly, or may affect all empires that own an object that falls into the effect's scope. The specifics of how this works can be decided by programmers, but it should be possible to target an empire directly, or target all empire's that own other objects objects in an effect's scope.

Scope Conditions for v0.3

Scope starts with no objects. Inclusive conditions are applied first, adding game objects into the scope. Exclusive conditions are then applied, removing objects from the scope, leaving a final set of objects in the scope, on which the effect is fired.

An effect can have multiple exclusive and inclusive conditions.

Prefereably, any scope condition described below will be usable as both an inclusive and exclusive condition. Limits to this may be made to this by programmers, by restriction some conditions as only usable in an inclusive or exclusive capacity.

Conditions

All

(No parameters) - Applies to all objects.

Empire Affiliation

(Specified Empire, Specifed one of: Empire Inclusive, Empire Exclusive, Enemies Inclusive, Enemies Exclusive) - Applies to objects based on the empire they are affiliated with, if any. The specified empire may be the source object's empire, a specific empire in the game, or may be "none". For an specified empire other than none, the second parameter specifies how the condition adds objects to the scope based on their empire according to the following criteria:

  • Empire Inclusive - Applies to objects owned by the specified empire (applies to objects shared by the source empire and another empire)
  • Empire Exclusive - Applies to objects owned by the specified empire only (does not apply to objects shared by the source empire and another empire)
  • Enemies Inclusive - Applies to objects owned by empires other than the source empire (applies to objects shared by the source empire)
  • Enemies Exclusive - Applies to objects owned by empires other than the source empire (does not apply to objects shared by the source empire)

If the specified empire is "none", the second parameter specifies how the condition adds objects to the scope according to the following criteria:

  • Empire Inclusive - Applies to objects owned by no empire (eg. space monsters)
  • Empire Exclusive - Applies to objects owned by no empire (eg. space monsters)
  • Enemies Inclusive - Applies to objects owned by any empire(s)
  • Enemies Exclusive - Applies to objects owned by any empire(s)

(An object cannot be shared between "no empire" and a particular empire, so the distinction between inclusive and exclusive does not apply if the specified empire is "none").

The "owner" of an object is generally clear, as in a ship or planet, which is clearly owned by a particular empire. In some cases however, objects are owned by more than one empire, such as systems containing planets owned by two or more empires are owned by all empires that own planets in the system. In other cases, objects are owned by no empire (eg. space monsters), no matter who owns the system in which they are located.

Self

(No parameters) - Applies to the source object only.

Object Type

(Specified Type) - Applies to objects if their game object type is the specified object type. The specified type may be an actual type (eg. ship, building, special, planet), or may be set relative to the source object for the effect. If programmers elect to do so, "empire" might be an valid object type, allowing an effect to target empires directly, as opposed to targetting other game objects owned by an empire to get at the empire itself.

Object Class

(Specified Class) - Applies to objects if their object class is the specified object class. The specified class may be an actual type (referenced by unique identifier and defined in an XML file), or may be set relative to the source object for the effect.

Planet Environment

(Specified Type, Range) - Applies to objects if they are within a specified range of environments types from the specified environment type. If the specified environment is not on the EP wheel (gas, asteroids), then the specified range is ignored, and the scope objects' environments must match the specified environment exactly for the condition to apply. If the specified environment is on the wheel, but a scope object's environment is not, then the condition does not apply.

Planet Size

(Specified Size, Range) - Applies to objects if they are within a specified range of planet sizes from the specified planet size.

Planet Focus

(Specified Focus, Specified Primary or Secondary) - If specified Primary, applies to objects whose primary focus is set to the specified focus. If specified Secondary, applies to objects whose primary or secondary focus is set to the specified focus.

Star Colour

(Specified Colour) - Applies to objects if their star colour matches the specified colour.

Chance

(Specified Probability) - For each object, a uniformly distributed random number between 0 and 1 is generated and compared to the specified probability. The condition applies to objects for which the random number is less than the specified propbability.

Future Note: In future, the chance-related condtions may allow the probability of excluding an object from the scope to depend on various properties of that object. This may involve expanding the functionality of the Current Meter Value Condition, or the creation of new conditions with specialized functions.

Meter Value

(Specified Meter, Specified Value, Specified Minimum or Maximum) - Applies to objects if their applicable current meter value meets the conditions indicated by the specified values. For Minimum, the condition applies if the specified meter value is equal to or larger than the specified value (and similarly for maximum). If an object does not have the applicable meter, the condition does not apply. This condition can only be used with non meter-altering effects groups. This condition could be split into "Current Meter Value" and "Max Meter Value" for the two cases of specified minimum or maximum.

Current Stockpile Value

(Specified Resource, Specified Value, Specified Minimum or Maximum) - Applies to objects if their applicable resource stockpile meets the conditions indicated by the specified values. For Minimum, the condition applies if the specified resource stockpile is equal to or larger than the specified value (and similarly for maximum). If an object does not have a stockpile of the applicable resource (not the same as a stockpile containing 0 of a resource), the condition does not apply.

Scope Object Visible To Source Object

(Specified True / False) - Applies to objects that can or cannot be seen by the source object, as indicated by the specified true or false (true means the condition applies to objects if they are seen, false means the condition applies to objects if they are not seen). In most cases, this will be equivalent to testing whether an objects can be seen by the source object's empire.

Source Object Visible To Scope Object

(Specified True / False) - Applies to objects that can or cannot themselves see the source object, as indicated by the specified true or false (true means the condition applies to objects that can see the source object, false means the condition applies to objects that cannot see the source object). In most cases, this will be equivalent to testing whether the source empire can see the tested object.

Direct Distance to Source

(Specified Distance) - Applies to objects if their physical location on the galaxy map is within a specified distance from the source object's location. If the source object does not have a physical location, then this condition does not apply to any objects. If a given scope object has no physical location, then this condition does not apply to that object. Distance can be 0, meaning the condition applies only to objects co-located with the source object (meaning in the same star system, or located at the same position on a starlane).

Starlane Jumps to Source

(Specified Number) - Applies to objects if their physical location is within a specified number of starlane jumps from the source object. If the source object is located at a system, then all systems connected to the source object's system by one starlane jump are at a distance 1, by two starlane jumps are at a distance 2, and so on. Objects on starlanes between systems count as being one jump away from either starlane at the end of the lane they are on. Objects are always considered to be the shortest number of starlane jumps away from the source as possible, whether or not the starlanes involved are known to the empire(s) involved. Distance can be 0, meaning the condition only applies to objects co-located with the source object (meaning in the same star system, or located at the same position on a starlane).

Object Class

(Specified Class) - Applies to objects if their object class is the specified object class.

Direct Distance to Object of Class

(Specified Distance, Specified Class of Game Object) - Applies to objects if they are within the specified distance on the galaxy map to an object of the specified class. Distance may be 0, indicating the objects must be co-located.

Starlane Jumps to Object of Class

(Specified Number of Jumps, Specified Class of Game Object) - Applies to objects if they are within the specified number of starlane jumps to an object of the specified class. Distance may be 0, indicating the objects must be co-located. See "Starlane Jumps to Source" for details.

Object Type

(Specified Type) - Applies to objects if their game object type is the specified object type. If programmers elect to do so, "empire" might be an valid object type, allowing an effect to target empires directly, as opposed to targetting other game objects owned by an empire to get at the empire itself.

Future: Targeted Object

See Future: Set Target effect.

Activation Conditions

Each effects group has a set of conditions that determine whether or not the effects group is "active" during a given turn. If active, all effects in the effect group fire on all objects in the effect group's scope. If inactive, the entire effects group is ignored for the turn.

An effect group must meet all of its activation conditions to be active during a given turn.

Activation Conditions for v0.3

Many scope conditions, or small variations thereof should be usable as activation conditions. In particular, the following scope conditions should be available (in all cases, the source object is being tested by the conditions):

Conditions

  • Always Active
  • Empire Affiliation
  • Planet Environment
  • Planet Size
  • Planet Focus
  • Star Colour
  • Chance
  • Current Meter Value (non meter-altering effects groups only)
  • Current Stockpile Value (non meter-altering effects groups only)
  • Direct Distance to Object of Class
  • Starlane Jumps to Object of Class

The following additional special activation condition should be available:

Special Activation Condition: Owned by Specfic Empire

(Run-Time Specified Empire, Specified Active / Inactive) - If specified Active, effects group is active only if the source object is owned by the specified empire. If specified Inactive, the effects group is active only if the source object is not owned by the specified empire.

This condition is special in that the specified empire needs to be specified at run time, by the game engine.

Effect Parameters

In the above lists of "Effects for v0.3", "Scope Conditions for v0.3" and "Activation Conditions for v0.3", parameters are indicated in brackets as part of the effect or condition description. Many of these are numeric parameters, which are discussed below under "Numeric Parameters". Others are non-numeric parameters, which are discussed below under "Non-Numeric Parameters".

Every effect also has an additional parameter not indicated in "Effects for v0.3". This is the effect "Stacking Number".

Parameters are generally specified as part of exteral data files that define most object classes. Along with the specific effects, conditions an non-effects related information in the external data files, the parameter values actually determine how game objects function. In some cases, however, it may be necessary for the game engine itself to generate parameter values (see Special Activation Condition: Owned by Specfic Empire).

Future Note: In future, additional parameters may need to be specifiable by the game enging according to user input. This may work through something like the Future: Set Target effect, or be handled directly by the game engine (for condition parameter or in general).

Stacking Number

Each effect has an integer parameter known as a "Stacking Number".

Stacking number functions similar to a scope condition, in that it determines whether an effect fires on a particular object or not, but differs in that stacking is checked for each effect individually, rather than for effects groups as a whole.

If the specified "Stacking Number" for an effect is 0, the effect always fires.

If the stacking number is nonzero, the effect does not fire on a particular game object if another effect with the same stacking number has already fired on the same game object previously during the current turn.

Terminology: Two or more effects with the same nonzero stacking number are referred to as "nonstacking effects", in that only one of the effects may be applied to a given game object in a given turn (they do not "stack").

Future Note: As described, this condition depends on the order in which effects fire. That is, if two different effects fire on the same object, but are nonstacking effects, then the effect which fires first will be the effect that fires, while the other effect(s) will not fire. The order in which effects fire might be controllable within a single effects group, depending on implimentation, but currently there is no precedence or ordering between effects groups that is accessible or controllable for content designeres. Future designs will require some way to specify which effect fires in the case of conflicting nonstacking effects. This may involve taking the largest, smallest or an average modification in the case of numerical effects. For non-numerical effects, some other system will be necessary.

Numeric Parameters

Numeric parameters for some effects and some effects group scope or activation conditions may take the form of expressions involving constants, arithmetic operations and references to meter values (max or current) of the source object and/or target (scope) object.

Parameter Expression Operators

The arithmetic operations in parameter expressions are represented by their corresponding standard operators, and may include:

  • Addition, +
  • Subtraction, -
  • Multiplication, *

Expressions take the form of a sum of terms, (having no mathematical brackets, () ). Terms are constants, references to meter values, or products thereof.

Programmers may restrict product terms to only having a single * operator each as in "5*3", or they may permit "chaining" of * operators, as in "5*3*2*5*1". Similarly, expressions may be limited to only a signle + or - operator, as in "4 + 2", or multiple +'s and/or -'s may be chained, as in "4 + 2 - 6 + 3".

Expressions are evaluated according to the standard order of operations rules, so multiplication operations (product terms) are evaluated first, then + or - operations between terms.

Example Expressions

References to meter values may take whatever format is deemed appropriate by programmers. The format used below is for illustrative purposes only, and need not be the format actually implimented.

Example expressions that should all be functional:

  • 5 (a constant without any operators)
  • 4 + SourceObject.CurrentFarmingMeter (simple addition of constant and meter reference)
  • 3 * SourceObject.MaxMiningMeter - 2 * TargetObject.MaxMiningMeter (multiplication of meter references by constants, subtraction)

If a referenced meter is not present on a source object, the meter value is taken to be 0.

When can use Meter Values be Used as Parameters?

Effects may use meter values in their parameters only if:

  • The effect does not modify a meter value
  • The effect's group's scope and activation conditions do not take parameters that refer to meter values.

Scope conditions and Activation Conditions may use meter values in their parameters only if:

  • None of the effects in the effects group modify meter values

Non-Numeric Parameters

Non-Numeric parameters for some effects and some effects group scope or activation conditions may be either constant values or references to various properties of the source object.

Non-Numeric parameters should not be able to refer to the target object's properties.

Example Expressions

References to non-numeric object properties may take whatever format is deemed appropriate by programmers. The format used below is for illustrative purposes only, and need not be the format actually implimented.

Example expressions that should all be functional for objects with the relevant properties:

  • PL_LARGE (constant parameter value)
  • SourceObject.PlanetSize (reference to source object property)

If a referenced parameter value is not a property of the source object, the hierarchy of attachment should be followed to find a value, if possible. If no value can be found after attempting to use the attachment hierarchy, a default value should be provided.

Effects System

Turn Processing Order

  • Set all max meters to 0. Current meter values remain unchanged from previous turn's values.
  • Fire all meter altering effects
  • Apply current-meter growth formula
  • Cap current meters by max meter values as applicable
  • Fire all non-meter-altering effects
  • Do rest of turn

Note that meter altering effects fire before ship movement, or anything else, so ship move orders given in turn N do not affect meter values in turn N+1, but do affect meter values in turn N+2.

In future there may be several times during a turn when a non-meter-altering effect can fire. This times will be before, after and between things like ship movement, production/popgrowth/research and combat. Effects-altering meters will always happen at the very start of a turn, however, before anything else, effects or otherwise.

Effect Processing

When processing effects during one of the effects ordering stages, the following occurs:

  • Game objects are being iterated through, and a particular game object is selected to have its effects processed during this ordering stage
  • If the selected game object has any groups of effects containing effects that can fire during this ordering stage, it is considered further
  • An effect group is selected that contains effects that fire during this ordering stage
  • The activation conditions for this effects group are checked. If the effects group is active this turn, it is considered further
  • The inclusive scope conditions for this effects group are applied, building up an initial scope of game objects
  • The exclusive scope conditions for this effects group are applied, excluding objects from the scope
  • All of the effects of the effects group are applied, in order listed, to all of the objects in the scope
  • The processing loops back to cover all effects groups and all game objects