Talk:FOCS Scripting Details

From FreeOrionWiki
Revision as of 05:08, 18 September 2004 by 130.15.126.81 (Talk)

Jump to: navigation, search

Suggested Changes (Sept. 17/18)

Stacking

Should change stacking to not involve object class. Stacking number should be the only consideration. If an two effects could fire on an object and they both have the same stacking number, only one can fire. How to decide which in cases of conflict isn't clear... For numerical effects, the larger could apply, but we haven't explicitly outlawed preventing stacking of non-numerical effects (with numericals or non-numericals).

Scope Conditions

Should remove inclusive / exclusive conditions. Should say that ideally all conditions could be used in either capacity, but programmers are free to put limits on this if they feel it is necessary / beneficial / easier to do so. Could suggest not using "expensive" to calculate conditions for inclusion (eg. distance from source).

Random Parameter Values

Remove!

Turn Processing Order

  • Set all max meters to 0. Current meter values remain unchanged from previous turn's values.
  • Fire all meter altering effects:
    • Max meter values are added to to by primarily effects that consistently fire every turn, establishing a consistent max meter value
    • Current meter values may be modified by effects as well, but rarely compared to current meter values, and 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.
  • Apply current meter growth formula (not based on effects)
  • 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 seveal times during a turn when a non-meter-altering effect can fire. This will occur before, after and between thing 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.

Technology as Game Object?

When a technology is researched / gained, it might be implimented as a game-created 0 duration game object that has effects which unlock other classes of game object for the player. A separate infinite-duration game object could simultaneously be created to give persistant benefits of the technology as well. Alternatively, a persistant actor labelled as a special could be attached to an empire, bestowing some benefits.

Technology could also not be treated as a game object at all, but rather as a special internal system unrelated to game objects, and having a separate content description scheme. Presumably it would be easier, efficient and faster to use the same system as much as possible though. In practice, construction of game objects like "buildings" through non-effects based planet production is probably quite similar to researching a technology treated as a game object through non-effects based research.

Effect Group Activation Conditions

Need to add a variety of conditions, similar to scope conditions, but dependent on properties of the source object (and dependencies via hierarchy), and which determine whether the effects group is "on" for a given turn. Should include conditions for:

  • properties of owner empire / presence of special attached to owner empire (for empire-wide special resources perhaps)
  • focus setting
  • stockpiles
  • co-located with object of type/class/category
  • within X distance/jumps

Actually... most of the scope conditions should be usable, though there'll be a few extras that only apply to source objects

Maintainance fees (or resource requirements and consumption while active) would also be nice to have as an acitvation condtion, as would some sort of player controlled turning on / off. How to do this is a bit unclear however, since effects fire at the very start of a turn, before the game would have a chance to deduct maintainance fees (or collect taxes with which to pay them). We could perhaps determine if fees will / can be paid before firing effects, or we could have have things deactivate at the end of a turn if their maintainance is unpaid, rather than deactivating the effect during the turn when the shortfall would occur.

Any effect group that includes an effect that modifies meter(s) cannot use meter value as an activation condition. As such, it seems that it will be necessary to not have meter values as an activation condition for effects groups.

Side Note: Effect Group Exclusivity

Should perhaps say that effect groups may only have effects that alter meters or that do not alter meters, not a mix...

Non-Effects Game Object Info

Yoghurt was going to work up some stuff about coding objects in Python... don't know what's happening with that...

Game object descriptions will need some non effects info. For v0.3, this could be:

  • Buildings require a prerequisite tech, a cost per turn, a construction time in turns, a name, and all the effects stuff.
  • "Specials" can be randomly assigned at the start of the game to planets. They require just a name and a list of effects.
  • Planets, ships, systems, empires, etc. all are treated effectively like they are in v0.2, except that they can be in the scope of an effect and have a few properties that can be modified by effects.

There is no player ship desgin in v0.3, so ships could be coded as a temporary class of scripted object (object class = MarkIV or somesuch). In future, presumably the ship design component will make internally self-scripted object classes (or something similar), which ship game objects will use as their object class.

For v0.3, only buildings and specials can have effects (?), which are encoded in Python XML. This might be extended to include technologies, if programmers are so inclined.

Unlocking?

Techs or specials or whatever that "unlock" things for empires to build (or research?) could work either of two ways:

  • The "unlocked" status of an object could be stored as part of the empire or the object itself, and be persistant. The "unlock" effect would only need to fire once, and the object is unlocks would stay unlocked until relocked by some other effect
  • The "unlocking" effect needs to fire every turn, and a persistant object needs to exist to hold and fire the effect.

I'm inclined to suggest the first option.

Some Explanitory Text?

Each effects group is a list of one or more effects. There can be more than one effects group in a game object, so the object description has "effects groups". The first quoted statement was a point in a list of things in an object description, one of which was the effects groups that the object contains. Similarly, the effects part of an effects group is a list of the classes and parameters for the effects in the effects group.

New Scope Condition?

Something along the lines of "has meter of type X" might be helpful, though this could probably be implimented automatically by the "set meter value" effect, which would only work on objects with the specified type of meter.

List of fired and unfired effects

It will helpful to have the game player client maintain a list (aka "ledger") of effects that are expected to fire or expected to not fire on object while the player is giving orders. Based on the current orders, the game will predict meter values for all meters for the next turn. If the player alters an order which changes the prediction, it's desirable to have an immediately accessible list of effects that could fire on the object. This is better / faster than having to iterate through all effects in the game every time a player changes an order that could cause a scope condition to change a particular effect form firing or not firing on a particular object or set of objects.

(For effect activation conditions, it's only necessary to check the effects of the object whose orders were changed. Any effects it has that are turned on or off as a result of the order change can be reapplied or unapplied to all relevant game objects)

Multiplication Factors?

Current there are no "modify meter multiplier" effects, which IMO is as it should be, but if we want one, we should specify how they'd work (so that ordering of additive and multiplicative bonuses doesn't matter).

"Multiplication should be stored separately from meter value, so if you start with a meter of 5, and a multiplicatin of 1, then make the multiplier 2, then add 5 to the meter, you end up with a meter of 10 and a multiplier of 2... ie. the multiplier is multiplied by the meter value only at the exact moment you evaluate the total meter value. Adding to a meter after adding to a multiplier only changes the root meter value, which is unaffected by changing the multiplier value."

Do we need to show the previous turn's meter values?

drek: "Maybe not on the sidebar, but it should be somewhere.

Otherwise, how can the player review the effects of events that only last a single turn?"

Geoff: "This probably needs to be dealt with on a case-by-case basis as well... I imagine most single-turn events would have sitrep notes though, or be something that the player knew about the turn before, so were already incorporated into the client UI's prediction of the relevant meter values during the previous turn (eg. in the case of ships which only modify a meter for one turn due to moving or somesuch)."

Explain Intention of Effects Groups

drek: Possibly rewrite the effect groups blurb to make it more obvious what the intention is. (grouping a bunch of effects together so that conditions only need to be calculated once)

Mockup for fake XML as reference (shouldn't be in actual design, probly):

ObjectClass WonderFarm {
    Category = Building
    Cost = 5
    Buildtime = 10
    PrereqTech = WonderFarming
    EffectGroup {
        Effect {
            EffectClass = ModifyMeter
            Meter = Farming
            Amount = 5
        }
        Effect {
            EffectClass = ModifyStockpile
            Resource = Food
            Amount = 113
        }
        ScopeCondition {
            ConditionClass = ObjectType
            ObjectType = Planets
        }
    }
    :EffectGroup {}
}