Talk:V3 ScratchPad

From FreeOrionWiki
Revision as of 11:41, 10 July 2004 by 63.246.166.179 (Talk)

Jump to: navigation, search

The Term "Meter"

I don't see why we shouldn't use the term "meter" when explaining what determines the amount of resources / social effects on a planet. We don't need to have a big title on the meter display box that say "PLANET METERS" and subheading for "RESOURCE METERS" and "SOCIAL METERS" or anything... but refering to the "farming meter" is clear enough...

Range & Granularity

Instead of 0-10 with 0.25 or smaller increments, how about meter values range from 0-255. This way, there is good granularity, but we can have simple meter bonuses that are integers, eg. +20 or +1. We can have "soft limits" to meter values by including only so many sources of bonuses. Perhaps in practice, meters would generally stay under 100... but the extra range is there if needed for balance.

Resource Meter Effects, Consistency

Resource determine resource production like this:

(minerals mined) = (population) * (mining meter) / 10

or for farming,

(food produced) = (population) * (farming meter) / 10

Each population point needs 1 food / turn to not die, so (farming meter) = 10 is the break-even point. We need the (unfortunate) "/ 10" so that there are meter values other than 0 for which the planet doesn't produce enough food to be self sufficient. I think a "/ 10" in production is easier to understand that making people consume food at a rate other than 1 / turn... (consumption of 1 per turn is a good definition for a unit of food, imho).

Further, if there's a "/ 10" in food production, there should be one for all resource meter -> production formulas. This is essential so that different resources have the same relative value. The player can "think" under the assumption that +5 in mining is always just as good as +5 in farming -> +5 gives the same total additional production no matter what meter it is applied to or what the meter values are within a meter.

Growth Meter

Using the same 0-255 scale, I suggest population growth work like this:

(Pop Change) = (Pop) * ( (Planet Pop Limit) - (Pop) ) / (Planet Pop Limit) * (Growth Meter Factor)
(New Pop) = Min( (Pop) + (Pop Change), (Max Pop), (Food Available) )

Where,

(Growth Meter Factor) = (Growth Meter) * (0.002)

My previous spreadsheeting suggests this gives a decent rate of growth... balance testing will be needed to get a better number.

Focus Effects & General Meter Levels

Assumptions:
Meter range 0-255
Food meter break even at (farming meter) = 10
Farming secondary focus or balanced primary should give break even on food

Proposed:
Resource meters have default / initial value of 0
At start of game:
Primary Specialized Focus gives + 12 to one resource meter
Primary Balanced Focus gives + 4 to all resource meters
Secondary Specialized Focus gives +6 to one resource meter
Secondary Balanced Focus gives +2 to all resource meters

Techs/buildings can independently add or subtract to the default value, or the effect of any of the 4 focuses on each meter. Eg: WonderFarms gives +5 to farming on farming specialed primary focus, +2 to farming on balanced prim. focus, +2 to spec. sec. focus, and +1 to bal. sec. focus.

Farming Emergent Properties: primary/secondary focus, mining as "not farming" example focus

  • farming/farming -> 1.8 times need -> 0.8 more worlds' worth of food
  • farming/balanced -> 1.4 times need -> 0.4 more worlds
  • farming/mining -> 1.2 times need -> 0.2 more worlds
  • balanced/farming -> 1.0 times need -> break even point for world
  • balanced/balanced -> 0.8 times need -> must import 0.2
  • balanced/mining -> 0.4 times need -> must import 0.6
  • mining/farming -> 0.6 times need -> must import 0.4
  • mining/balanced -> 0.2 times need -> must import 0.8
  • mining/mining -> 0 times need -> must import 1.0

If there are 5 resources, 4 of them aren't farming, so having the "extra worlds" that can be fed by a farming/farming world at just under 4 seems reasonable. Maybe some tweaking could be done so that after you start getting bonuses, you still need a bunch of farming/farming worlds lying around... or maybe not.

Specific Meters for v0.3

Do we want meters in v0.3 that don't do anything until later versions? Trade, Happiness, etc. are pointless for now. It's probably better to have it well understood that there will be more meters added, so that UIs don't get desgined around the number of meters we think up now, only to have to be rebuilt later when we finalize other game systems and any meters that affect them.

For v0.3:

  • Farming
  • Mining
  • Industry
  • Money
  • Research
  • Construction
  • Health/Growth

Resource Meter Growth / Construction Meter

The whole construction meter accumulator business is kinda thrown out of wack if there are 0-255 and +1 a small amount.

It was suggested to use a population-like growth, but this is not a good idea. Population grows as (simplifed):

(New Pop) = (Cur Pop) + ( (Max Pop) - (Cur Pop) ) / (Max Pop) * (Growth Meter Factor)

This doesn't work for resource meters, though, since you can change the "Max Meter Value" with focus settings, meaning you can change the rate of growth by changing the focus setting, meaning you have to to be competitive. (eg. Set max high to grow, then lower when you reach where you want it to be. This would be faster than just leaving the meter at the desired level)

I think resource meter growth should depend on the construction meter and fall with the current meter value somewhat like so:

(Meter Value Change) = (Construction Meter) / ( (Current Meter Value) + 1)
(New Meter Value) = Min( (Meter Value) + (Meter Value Change), (Max Meter Value) )

All meters grow simultaneously, a little bit each turn.

Update: Changed "+ 10" to "+ 1". +10 would have required too high a construction meter to get any resource meter value growth. ... This formula still isn't very good. Since meters are integers, rounding will basically prevent meter growth for small construction meter values... providing another limit in addition to the "max meter value" we already have. This is probably not a good idea. I really don't want to go to fractional meter values... Any other suggestions?

Actors, Events & Effects

Effects are changes/modifications to game objects. Actors and Events are lists of Effects that function as a group.

Effect types are hard-coded into the game (ie. the actual code that makes the changes is not in a script/xml file), and have very limited variable functionality through a few parameters that are coded into Events or Actors with the list of effects. An Actor/Event's list of effects might contain multiple instances of the same effect, but with different parameters.

Events are immediate: They are created, and all the effects they contant are "fired" immediately. The event does not continue to exist for the remainder of the turn, or into subsequent turns. An instantaneous in-game event, such as a meteor strike, would have an associated code "Event" whose effects are appropriate for the type of in-game event, such as loss of population.

Actors are persistant: A persistant game object such as a building or special would have an associated code "Actor", with several effects listed in it. All existing actors are iterated through several times while processing a turn. On each iteration, a particular effect may or may not be fired, depending on the type of effect it is.

Definition of an Actor or Event

Probably done in an XML file. Programmer comment/tweaking encouraged.

Consists of:

  • Class: Actors/Event
  • Name: (Text String)
  • Duration: (integer)
  • Number of Effects: (Integer > -1)
  • Definitions of Effects (see below)

For Duration: Could use -1 = infinite duration after created, 0 = effect, 1..whatever = actor with fixed duration. In this case, could omit "Class" field and not make a distinction between actors/events in code.

Definition of an Effect in Event or Actor

The list of effects in an actor or event consists of the following information:

  • Effect Type: EffectTypeID#
  • Turn Phase: PreMovementPhase/PostMovementPhase enumeration
  • Effect Chance: (float 0..1)
  • Effect Target: ObjectID#
  • Effect Scope: Galaxy/Empire/Distance/StarLaneJumps/System/Personal enumeration
  • Effect Scope Range: (integer > 0)
  • Effect Affiliation: TargetEmpireOnly/TargetAllies/TargetEnemies/All enumeration
  • Stacking Group ID: (integer > 0)
  • Misc. Parameter: (integer)

Details:

  • Effect Type: The hard-coded id number for the particular effect
  • Turn Phase: When to "fire" the effect. See Effects System. Meter Modifying effects ignore this parameter
  • Effect Chance: If an object meets all restrictions on the effect's scope, this is the chance that the effect will "fire" on that object
  • Effect Target: Works with Affiliation to determine which objects effect will "fire" on.
  • Effect Scope: Physical location restrictions on what objects will be "fired" on by effect
    • Galaxy -> All objects (planets only in v0.3)... no restriction
    • Empire -> All objects in a system with a planet owned by empire of target object
    • Distance -> All objects within Scope Range parameter distance of target object
    • StarLaneJumps -> All objects within Scope Range parameter starlane jumps of target object. Partial starlane jumps count as a full jump (eg. if target is a ship on a starlane, not at a plant)
    • System -> All objects in system of target object (later: or in fleet travelling with target ship)
    • Personal -> Target Object Only
  • Effect Scope Range: How many "lightyears" or starlane jumps for respective scope restrictions
  • Effect Affiliation: Restricts list of objects effect will fire on based on the empire that owns them.
    • TargetEmpireOnly -> objects owned by empire of target object only
    • TargetAllies -> objects owned by empire of target object, or owned by ally of empire that owns target object (meaningless in v0.3)
    • TargetEnemies -> objects owned by empires that are enemies of the empire that owns the target object
    • All -> object owned by any empire (no restriction)

Note: If an effect is included in v0.3 that modifies a property of the empire, rather than one of its planets, then the scope parameter is ignored, and the affilitation parameter determines which empire(s) are affected, based on the empire that owns the target object.

Future restrictions (not v0.3, not exhaustive):

  • Scope Type: Class of Object: Planets/Ships/Stars/All etc.
  • (others...?)

Some manner of restriction based on planet environment could be included, though I'm wary of putting in too many now that will make it harder later to have effects work on things other than planets. Planets have environment, size, focus setting... Stars have type. Ships will have lots of unique details. I'm not sure what the best way is to write restrictions for this sort of thing. Perhaps if a restriction is not mentioned exactly be name the it isn't considered...? Maybe wait until v0.4 to impliment this though...


Effects System

The processing of a game turn proceeds in this order:

  • Start of Turn Processing - all meters set to 0
  • Meter Accumulation Phase - All actors iterated through, any effect that modifies a meter is fired
  • Upkeep Phase - Production/resource creation, pop growth/starvation, creation of new ships, etc.
  • Pre-Movement Effect Phase - All Actors are iterated through. Any effect that is marked for this phase in its definition is fired. Any Events "summoned" by an Actor effect fire their effects immediately. Any new Actors created by a pre-existing actor effect do not fire now
  • Action Phase - Ship movement, battles, etc.
  • Post-Movement Effect Phase - All Actors are iterated through, any effect that is marked for this phase in its definition is fired. Actors created in the Pre-Movement Effect Phase are included in the iteration. Events can be created as in the Pre-Movement Phase. Actors created in this phase do not function this turn, but will function starting in the Meter-Accumulation Phase of the next turn.
  • End of Turn Processing

Specials, Techs, Buildings, Random Events

These are all treated as actors or events. When a building is constructed, an actor is created by the game. This actor contains a list of effects that impliment the advertised function of the building. Similarly, specials and techs have associated actors.

The game also has a "Random Event Generator" actor that is always exists. During the pre-movement and post-movement phases, various "SpawnEvent" effects with low % chances to fire are iterated through and given chances to do so. If the SpawnEvent effect fires, an event is created, which contains several other effects that impliment the function of the random event. The event acts as a grouping of related effects. The REG also has "SpawnActor" effects, which act like they sound.

Effects for v0.3

Unless stated otherwise, an effect can be set to work in either the pre-movement or post-movement phase.

  • Modify ___ Meter - Adds or subtracts from a planet's meter this turn. Only functions during the meter accumulation phase. Amount of change is the "misc. parameter" of the effect definition in an event/actor. Actually consists of multiple similar effects...
    • Modify Max Farming Meter
    • Modify Max Mining Meter
    • (etc. all resources)
    • Modify Current Farming Meter
    • Modify Current Mining Meter
    • (etc. all resources)
    • Modify Construction Meter
    • Modify Health/Growth Meter
  • Modify __ Stockpile - Adds or subtracts from one of empire(s) food stockpiles. Amount of change is "misc. parameter". Consists of a separate effect for each stockpilable resource.
  • Add Building to Planet - Adds a building to an empty building slot of a planet. "misc. parameter" is the typeid# of the building to add. If no slots are free, then effect does nothing.
  • Destroy Building - Removes all buildings of typeid# indicated by "misc. parameter". Multiple instances are all removed. If no such building exists at a planet, nothing happens.
  • Set Planet Environment - Sets the planet environment to that of typeid# indicated by "misc. parameter"
  • Destroy Planet - Self Explanitory
  • Modify Planet Population - Adds or subtracts from planet's population. Amount of change is "misc. parameter"
  • Set Researched Tech - Sets a tech as researched for empire(s). Tech that is set is indicated by "misc. parameter"
  • Unset Researched Tech - Sets a tech as not researched for empire(s). Tech that is unset is indicated by "misc. parameter"
  • Unlock Building - Sets a building type as buildable for empire(s). Building type to unlock indicated by "misc. parameter"
  • Lock Building - Sets a building type as not buildable for empire(s). Building to lock is indicated by "misc. parameter"
  • Unlock ShipeType - Sets a ship class as buildable for empire(s). Ship class to unlock is indicated by "misc. parameter"
  • Lock ShipType - Sets a ship class as unbuildable for empire(s). Ship class to lock is indiacated by "misc. paramter"
  • SpawnEvent - Creates a new event, which immediately fires its effects. Event type to spawn is indicated by "misc. paramter"
  • SpawnActor - Creates a new actor, which begins to function in the subsequent effects phase (see effects system). Actor type to spawn is indicated by "misc. parameter"

Feel free to add "random" or "all" sentinel values for things using the "misc. parameter", like destroy building of type, or modify __


Notes


Drek's notes:

Human's have ten fingers, so I'd like to keep the meter range a multiple of ten. 1-100? 255 is a famlier number to binary savvy people, probably looks arbitrary to everyone else.

I'll make it clearer that Happiness/Security are suggestions for the future and not meant to be implemented.

>If there are 5 resources, 4 of them aren't farming, so having the "extra >worlds" that can be fed by a farming/farming world at just under 4 seems reasonable.

You are forgetting the effects of buildings, techs, and specials. How about, without technology, secondary and balanced don't feed the planet completely? A bonus to the Homeworld special (and the Terran enviroment) makes up for the shortfall early game.

Food has always been a bit unbalanced, I'm happy to see you working on the problem.

>All meters grow simultaneously, a little bit each turn.

That's probably a cleaner way of doing things. Since it's your system that passed, that's how we'll do things. Feel free to update the actual wiki page with Geoff's infra growth formula, or I'll do it soon.

btw, at tzlaine's request, Infra Events are going away. Instead Construction, Health, Entertainment, etc. will become like the resource meters: with Current and Max values.


Geoff's Comments on Drek's Notes

255 was chosen so that a single byte could be used to store the data. The 255 number would not appear in the game, or be a factor in the design / balancing. We would only put in enough buildings/specials/techs to give as many bonuses as we want... being carful that it doesn't go over 100. If we have so many bonuses that we're getting over 100, then we should remove or reduce bonuses, rather than put on an arbitrary limit, imho.

--

So... it takes a while for the construction meter to grow, and in the meantime your resource meters grow really slowly? What controls how the construction meter grows? Itself? ... Does the health meter also grow? That seems kinda odd to me... and it'll need some other meter to determine the rate... (?)

Are there no "nascent colonies" and such then? No specials at all? I guess that means most other actors are out... and probly the whole effects/events/actors system...

--

Focus effects on meters and resulting food stuff updated...

--

Drek's notes on Geoff's comments on Drek's notes:

Re: 255, 100. From tzlaine's words, I would guess that meters would be stored as floats, like most other pieces of game data in FO. Which hardly matters for the purpose of this document. I think we need an upper bound, and either 100 or 10 sounds fine to me.

My fear with making meters 100 (as opposed to 10) is the display on the UI. Though I suppose the boxes could strech in size to fill available space. When there's less than X infra, the boxes are larger. At upper bounds, the boxes are tiny.

There will be specials. There will be events. There will not be the infrastructure events as currently listed on the scratchpad. Good point re: construction. It will have to raise at a steady rate independant of, well itself.

I like a lot of your wording in the the Actor/Event section. Will steal and edit it.

Re: Modify Planet Meters. I'm expecting that a single effect can modify multiple meters (albeit by the same value). Plus, a general object/xml tag that modifies meters seems cleaner to me than one implementation per meter. Finally, one effect class'll make adding and subtracting meters less of a bitch.

Events are Actors. No need for the distinction, imho.

> The event does not continue to exist for the remainder of the turn, or into subsequent turns.

Why not? Some events should have durations. (unless we declare that an event with a duration is a "special", but that's splitting hairs.)

Definition-wise, I'd say an Actor with a limited duration is an Event.