User:Geoff the Medio/Musings

From FreeOrionWiki
< User:Geoff the Medio
Revision as of 15:53, 26 May 2005 by Geoff the Medio (Talk | contribs) (Rename Effect)

Jump to: navigation, search

Page Links

Buildings_Model_Quickpad
Translation_ScratchPad
Testing_Notepad
Techs.xml_in_progress
Eng_stringtable.txt_in_progress

Design

Colonization & Migration

Colony Ships & Building Empty Colonies

  • Colony ship can make new colony with population 1
    • in systems where you don't already have a colony
    • in systems where you do already ahve a colony
    • Colony ship has a race property. Colonies made with colony ships have the race that was loaded onto the ship when it was made.
  • Can also build new, empty colony on empty planets in systems where you already have a colony
    • "Build Colony" project takes ~5 turns, and produces an empty colony.
    • Empty colonies can be targets for immigration
      • Must select permitted race for colony before immigration order can be given to it
        • Permitted race of a colony can be changed freely during a turn if the colony has 0 population
    • Empty colonies can produce resources even without people if they have direct resource producing buildings or specials
      • Colonies with resources provide those resources to the empire, even if the colony has no population
    • Empty colonies can have buildings which function normally (assuming no activation conditions that require a minimum population)
    • Maybe call empty colonies "outposts" or somesuch, to distinguish them from "colonies" which have populations?
    • May be diplomatic issues relating to making new colonies on planet in co-owned systems, with colony ships or by building a new colony. Should "claim" a system before building a colony there.
  • Only need colony ships to make colonies in systems you haven't already colonized, but can use them in systems that you have if you want a colony immediately, have a ship available and are willing to accept the race on the ship

Race-Migration

  • Population centres can only be populated by one race at any time
  • Each population centre has a "race" property. All population in the popcentre is of that race.
  • Colonies can be marked, or not, for immigration or emigration.
    • Colonies marked for immigration have their populations increased each turn due to immigration from colonies marked for emigration
    • Colonies marked for emigration lose population each turn to colonies marked for immigration
    • Immigration destinations only get population from emigration sources that are of the same race
    • Colonies marked for neither emigration nor immigration only naturally grow their populations according to pop growth formula (and events may change population)
  • Discovered planets may contain natives, which are of a particular race.
  • Conquered planets will contain population of the race that was on them before they were conqured
  • Player might want to depopulate a planet, for strategic reasons, such as to allow repopulation with another race.
    • Can be done through emigration. (Planet A starts with race 1, player wants to replace with race 2):
      • Player marks planet A for emigration
        • May simultaneously order immigration to planet A with race 2
      • Player picks immigration destination for race 1
        • If player has available empty colony,
          • Player sets empty colony race to race 1
          • Player marks empty colony for immigration
        • If player has no availble empty colony,
          • If player has uncolonized planet in system that also contains colonized planet(s) controlled by player,
            • Player orders a new empty colony constructed on this planet
            • Player set new colony race to race 1
            • Player marks new colony for immigration
          • If player has no available uncolonized planets in systems with controlled planets,
            • Player orders colonization of planet, game automatically creates ship to do this
              • Player orders colonization of a planet in a known system in which player does not control a planet, specifying race 1 as as race of colony
              • New colony ship containing population of race 1 is added to production queue at nearest shipyard
              • When finished, new colony ship proceeds to destination, then makes a new colony with population of race 1
            • Player orders new colony ship, manually gives order to move / colonize new planet
              • Player orders construction of a colony ship with containing race 1 colonists
              • Player moves ship to system, builds new colony with population of race 1
            • Player marks new colony for immigration
        • On subsequent turns, immigration destination is filled with migrants from planet A.
        • Planet A's population begins to decrease due to emigration.
        • Eventually, planet A's population all emigrates, leaving an empty colony.
      • If given for planet A, race 2 immigration order only applies after emigration of race 1 is complete, at which time emigration order is removed, and immigration with race 2 begins
    • During immigration-emigration, player is notified in sitrep at imprtant steps, such as
      • When new empty colony is finished
        • That immigration has started if immigration was waiting for the new colony to finish
      • When emigration starts at a planet if was waiting for destination to become available
      • When emigration finishes and immigration starts at a planet if immigration was waiting for emigration to finish

Sensors / Fog of War

  • All stars visible on the galaxy map, but additional information is hidden from players unless they are actively scanning to reveal it
    • Where the player is scanning in a given turn indicated on galaxy map with Fog of War
      • Greyed out / darkened regions indicate a player cannot see in a region
      • Coloured / light regions indicate a player can see in a region
    • Area where a player is scanning determined mainly by location and scanning radius of objects owned by player
      • Scanning objects ("Scanners") such as Ships, Planets, Bases, Specialized Sensor Buildings all have a scanning radius
      • The galaxy map within the radius of a scanner is revealed / scanned for a player who owns the scanner
        • Scanners generally just work / are always on
        • Specialized scanners could be turned on / off and have significant costs while on
      • The contents of systems at which a player does not have a scanner are not revealed to the player, even if they are within the radius of the player's scanners
        • Fluff: Interference from star prevents scanning into a system from afar
        • Things can be hidden in systems, and are only exposed if moved between systems...
    • Within scanned regions, a player can see ships moving on starlanes, but contents of systems are hidden unless a player has a presence in the system
      • Option: Ships are detected / scanned either:
        • At any time during a turn
          • Ships passing through a scanner's radius any time during a turn are detected
        • Only at the end of a turn
          • Ships that are fast enough to jump between systems in a scanner's radius, or don't actually end the turn in the scanner's radius cannot be detected
    • Starlanes hidden until a player detects them.
      • A player must have a ship in a system on a given turn to detect starlanes connecting to the system
        • Cannot remotely detect starlanes with scanners
        • Detecting a ship moving on an unknown starlane does not reveal the starlane, only that the ship is at a given location / moving / moved past a given location

Starlane Visbility

  • Starlanes not always visible to player
    • Even if a player has a ship in a system, not all starlanes are necessarily visible to the player
    • Starlanes must be detected and known to a player to be used for travel
    • If one player knows about a starlane, and another does not, this provides a tactical advantage
      • One player can escape via the starlane uknown to the other
      • One player can arrive in an unexpected location via a starlane unknown to another
      • In both the above cases, ship detection can still work for ships travelling on unknown starlanes, so ship cloaks become important
      • Without a cloak, a starlane uknown to another player still provides a useful escape route that cannot be followed, or a path to attack that might be much quicker than the other route, allowing an enemy fleet to be bypassed temporarily
    • Starlanes have a visibility rating that determines whether they can be seen
      • Maybe a levels system:
        1. Obvious - Easily detected just by having a ship at an endpoint. About half of starlanes are of this visibility naturally.
        2. Obscured - Requires a first level of enhanced detection equipment on ship / building in system. About one quarter of starlanes are of this visibility naturally.
        3. Hidden - Requires a second level of enhanced detection equipment. About one eight of starlanes are of this visibility naturally.
        4. Secret - Requires a third level of enhanced detection equipment. Just under one eighth of starlanes are of this visibility naturally.
        5. Undetectable - Cannot be detected normally (may be revealed by events). A small number of starlanes are of this visibility naturally, usually connected to very important systems.
    • Starlane natural visibility is probably strongly tied to lane length
      • Longer lanes are much less visible than short lanes
        • This means that at the start of the game, with weak detection abilities, long lanes that cross between sections of the galaxy are not visible, so exploration and motion are constrained to the shape of the galaxy
          • Exception might be for homeworlds near large sections of open space. The increased visiblity of lanes near homeworlds provides access for empires to regions of the galaxy on the other side of the open space, possibly counterbalancing the reduced number of nearby systems for systems on the edge of open space (at least galactic internal open space)
    • Over the course of the game, players get improved detection equipment, and more starlanes are revealed
      • Exploration remains important, as the terrain of the galaxy map (starlanes) can effectively change
        • The major galaxy-wide changes are limited in number however, and only occur when you research the next level of starlane detection, so continuous reexploration of everything you've already discovered with slews of survey ships for the whole game is not necessary.
    • Starlanes near a player's homeworld are easier for that player to see, and lanes near other players' homeworlds are harder to see.
      • Lanes immediately adjacent to a player's homeworld are treated as Obvious for that player
      • Lanes one jump away from a player's homeworld are treated as one level of visibility better for that player (Hidden if normally secret, Obscured if normally Hidden, Obvious if normally Obscured, Undetectable stay Undetectable)
        • Should avoid having Undetectable lanes near homeworlds
      • Lanes immediately adjacent to other players' homeworlds are treated as two levels of visiblity harder to see for a player
      • Lanes one jump removed from a homeworld are treated as one level of visibility harder to see for other players
    • Starlanes may change in visibility over the course of the game (independently of players' ability to detect them)
      • Changes may be due to random events or player action
      • After a player discovers a starlane, if the starlane's visibility changes to a to a less visible level, the player must rediscover the starlane, even if the lane was discovered with a degree of detection good enough to detect the lane's new harder to see visibility
      • After a player fails to detect a starlane, if the starlane's visibility changes to a more visible level, the player must still rescan the system to detect the lane (this will happen automatically if the player happens to have ships in the system at the time)
      • If a player has a presence in a system and has detected a lane, and the lane becomes less visible such that the player can no longer detect the lane, the player is informed that the lane disappeared. There is no indication why the lane became less visible or disappeared. Random changes in lane visibility should be sufficiently common that players can change lane visibility without it obviously being due to player action.
      • If a player has previously detected a lane in a system, but does not have a presence in a system when lane becomes less visible such that the player could no longer detect the lane, the player is not aware of this change until the player next has a presence in the system.
      • If a player knows of a lane, and does not have a presence in a system when the lane becomes less visible, and the lane is returned back to its previous visibility by the time the player establishes presence in the system, the player is not made aware of the occurance
    • Players may trade maps which contain knowledge of starlanes
      • Player may specifically trade only lanes of certain visibilities or in certain regions of the map
    • Players can hide lanes to provide a unique strategy: The Lane Isolationist
      • By making all lanes surrounding your systems difficult for others to detect, you can prevent players who have not researched lane detection technology from gaining access to your systems
      • You can also make lanes leading into another player's systems less visible, thus making it possible for you to have an escape route from their systems that they would not be able to use to follow you, allowing you to raid their systems behind their front lines
      • Could also trap players into regions of the galaxy by making all lanes out of the region too difficult for them to detect
    • Land hiding can be done with ships or buildings
      • Buildings are cheaper / easier to set up, but must be built in the system where they are to function, which thus must be populated and have appropriate prerequisites
      • Ships are more expensive / higher tech, but can work far from home, possibly even cloaked inside enemy territory (hiding their lanes, wrecking their supply / infrasturcture)
    • Lane hiding can be done temporarily or permanently
      • Temporary requires upkeep
        • Effect is lost if upkeep not paid, or building or ship doing hiding is lost
      • Permanent more expensive, slower
        • Especially with permanent lane hider ships, greater costs are involved than temporary effects to get the effect to happen

Starlane Construction / Destruction

  • With appropriate advanced tech, players can create and destroy starlanes
  • Ships travelling on a starlane when it is destroyed are lost
    • Can set up traps for enemy fleets: Lure them onto a long starlane and destroy it as they travel along it
  • If a starlane was previously known to a player, and it is hidden or destroyed, the player cannot tell which has occured if they did not have ships on the lane at the time
  • Starlanes can be made with varying levels of visiblity
    • Less visible starlanes require higher tech levels to create
    • It is more expensive to create a harder-to-detect starlane
      • Making a cheap obvious starlane has logistical benefits to provide shortcuts for supply or trade or moving troops
      • Making an expensive hidden starlane has much greater tactical benefits, as you can attack without warning from a surprise direction that an enemy did not expect

Partial set of Effects for this purpose here: User:Geoff_the_Medio/Musings#SetStarlaneVisibility

Ship Speed

  • Large powerful ships have much slower movement speeds and cost much more to move around than small ships
    • Creates important roles for small, medium and large ships
      • Small ships scout (like frigates, destroyers)
      • Medium ships project force rapidly (eg. cruisers)
      • Large ships are moved deliberately and carefully (eg. battleships, carriers).
      • Keeping large ships around home for defence is the cheapest, until you can pin down the enemy and know you won't waste too many resources moving your large fleet to destroy them
    • Large fleets that move slow are easier to catch on a starlane when you destroy it, destroying the fleet
      • To be fully safe, secure both ends of the starlane with cruisers / destroyers before risking sending your big ships across

Ship Cloaking

  • Could make cloaking require ships to travel more slowly than they otherwise would / could in order to stay cloaked
    • Provides a nice tradeoff to using a cloak, in addition to cost and fuel (if applicable)
  • Should probably have an on/off cloak setting, rather than a more complicated reduction in sensor effectiveness or somesuch...
  • Could have classes or degrees of cloak, and classes of specialized sensors which can detect cloaked ships on the galaxy map
    • Need a higher level cloak detector to detect a cloak of a given level
    • Similar to starlane visiblities?
  • Alternatively, could have standard sensors detect cloaked ships if good enough
    • Maybe using a rule like sensors level N can see through cloaks of less than N/2
    • Again, should have discrete classes or levels of sensors and cloaks in this case
  • Travelling on a starlane unknown to another player, while cloaked, ensured complete secrecy of fleet movements, though is quite expensive to be able to do, as you must research the necessary cloak and lane detection technology, as well as build ships with cloaks and move more slowly and more expensively than other ships

UI-Effects Integration

Many effects would be much more useful in-game if there were conditions available to base their scope, activation and <Condition> parameter values on user-input.

A unified interface mechanism is likely desirable.

The fleet-movement destination UI system might be a basis for this system, though there should be stronger feedback to user commands.

Examples

  • A "Starlane Hiding Ship" can activate its effect to make nearby starlanes harder to see.
    • In the fleets window, the ship's box (which the correct fleet is selected) would have an "ACTIVATE" button that would cause the effect to begin firing.
    • When clicked, and in subsequent turns, the button would change to "DEACTIVATE", and would cause the effect to stop if pressed.
    • There would also be some text on the ship's box to indicate the status of the effect (independent of the UI button to change that status). Possible states could include:
      • Inactive - Ship did not use effect in the previous turn and will not use effect in the next turn
      • Activating - Ship did not use effect in the previous turn, but ACTIVATE has been clicked, and the ship will start using the effect in the next turn
      • Active - Ship used effect in the previous turn, and will continue to use effect in the next turn
      • Deactivating - Ship used effect in the previous turn, but DEACTIVATE has been clicked, and the ship will stop using the effect in the next turn
  • A "Planet Killer Ship" can activate its effect to destroy a planet
    • In the fleets window, the ship's box would have "FIRE" (not "ACTIVATE", which is for continuous while on effects) that would case the effect to fire once, in the subsequent turn processing.
    • After clicking "FIRE", the cursor would change to a targetting crosshair, and the user would select a planet in the system to target.
    • There would also be some text on the ship's box to indicate that the effect is firing or not:
      • Inactive - Ship not ordered to fire during next turn
      • Firing: <Target> - Ship ordered to fire during next turn, with target planet name indicated
    • There might also be an icon next to the targetted planet to indiacate that the planet has been targetted by an effect by the player. When clicked, all effects that are expected to fire on the building in the next turn would be listed, with hyperlinks to the effects' respective source objects.
  • A "BIG GUN" building can fire on one enemy fleet within range every 10 turns. ** The user must activate the building, then select the enemy fleet.
      • The system sidepanel might show the buildings in a special Buildings-View, similar to the fleets view.
      • Alternatively, a "Buildings Window" could pop up, just like the fleets window, not attached to the sidepanel, showing all buildings in a system.
        • This could be used for more than just effects targetting
        • The buildings could be grouped by planet, in a manner equivalent to grouping by fleet for ships
        • The buildings could be just listed, not grouped as fleet, to avoid extra clicking. In this case the planet on which the building is located would need to be indicated on the building's box.
    • Whether in a separate fleets window, or on the system sidepanel, the firing UI of a building would work the same as the above description for a targetted ship...
      • Except that the target fleet is selected on the galaxy map, at a distance, rather than by clicking on a planet in the sidepanel
    • The fleet should be marked as targetted, perhaps with an icon in the UI.
      • Clicking the icon should provide a list of all objects owned by the player that are targetting the object in question, as with the fleets targetting example above, except that the icons appear on the galaxy map for targetted fleets, rather than next to individual targetted planets.

Targetted Condition

This condition would match the object that is targetted by the source object.

Future Effects

On Buildings Model Quickpad

Some new effects are listed on the Buildings Model Quickpad.

MoveObject

Moves an object to the location of another object.

Has parameter: <Condition>

The target object is moved to the location of the object(s) matching <Condition>. If more than one object matches <Condition>, the target object may move to the location of any of them (preferably randomly, but may be implemented arbitrarily).

If a ship is moved, a new fleet should be created containing the ship. If several ships are moved, ships should be in fleets at the new with the same ships they were in fleets with before they moved (excluding ships that didn't move).

If a planet is moved, there must be an empty planet slot in the new location. If not, the planet could either not move, or be destroyed, or a planet at the new location could be destroyed and replaced with the new planet.

(Similar issues for buildings will also need to be considered)

CreateStarlane

Creates a starlane.

Has parameter: <Condition>

This condition is used to select one of the endpoints of the starlane to be created. The other endpoint is the target object of the effect.

The effect should probably only produce one starlane per target object, even if the <Condition> parameter matches more than one object. The starlane produced can be to any object matching <Condition>.

If a starlane already exists between target objects and the (randomly?) selected object matched by <Condition>, either nothing happens or another object matched by <Condition> is selected.

DestroyStarlane

Destroyes a starlane.

Like CreateStarlane, except that a starlane is destroyed, not created.

If a fleet is on a starlane that id destroyed, the fleet should also be destroyed.

SetStarlaneVisibility

Alters the visibility rating of a starlane.

A lane's visibility can be set explicitly, eg:

<Effect::SetStarlaneVisibility>
  <value>VIS_OBSCURED</value>
</Effect::SetMeter>

And hopefully this will also allowing numerical treatment of discrete non-numerical visibility levels, eg:

<Effect::SetStarlaneVisibility>
  <value>Target.Visibility + 1</value>
</Effect::SetMeter>

Which would change lane visibility from:

  • Undetectable to Secret
  • Secret to Hidden
  • Hidden to Obscured
  • Obscured to Obvious
  • Obvious to Obvious (no change)

Note that lane visibility can be different for each empire. However, it may be sufficient to store lane visibility as a single value for each lane, and treat the variations for each empire as special cases, which does not depend on effects to function. In this case, the exploration code would decide when to reveal lanes to a player based on the lanes' visibility, the identity / empire of the player, and the proximity of the lane to the player's, and other players' homeworlds. The visibility value used would be the same in all cases / for all empires / players.

Rename

Sets the name of an object.

Has a parameter <Name>, which is a string.

Object names, before the effect executes, such as Target.Name or Source.Name, should be accessible and usable in the name, allowing modifications and additions to names, such as prepending "Ruins of " before a planet name. Simple fixed strings should also be valid names.

Future Conditions

On Buildings Model Quickpad

Some new conditions are listed on the Buildings Model Quickpad.

Targetted

The Targetted Condition is mentioned above.

Number / Sorted

It would be useful to be able to pick some number of objects that meet some other condition, or the top or bottom some number of objects sorted by some numerical criteria.

For example, I might want to fire an effect on at most 3 planets per turn. If 3 or fewer are available, all are fired upon. If 4 or more are available, then 3 are randomly selected.

Alternatively, I might want to fire on the top 5 planets by population in the galaxy.

Whether these should be done as one condition with a subcondition or as two or more similar conditions, I'm not sure.

ContainedWithin

Ways to filter objects based on whether other objects meet conditions would be useful. For example, one might want to:

  • Delete all ships in systems that have a planet of type Barren and is owned by a the source empire
  • Add +1 to farming to planets that are in systems that have a particular special
  • Do something to ships contained within the same fleet as a ship

To do these, a condition that checks whether objects are contained within objects that meet some other condition would be useful: Ships and planets are contained within systems, and ships are contained within fleets.