User:Geoff the Medio/Musings

From FreeOrionWiki
< User:Geoff the Medio
Revision as of 02:23, 23 February 2008 by Geoff the Medio (Talk | contribs) (Resource Production Formula)

Jump to: navigation, search

Page Links

Buildings_Model_Quickpad
Translation_ScratchPad
Testing_Notepad

Design

Colonization & Migration

Colonies and Races

  • Populated colonies have a set race. All population in a colony is of that single race.
  • Unpopulated colonies have no set race, or can have their set race changed by players freely.
  • Newly discovered planets may contain natives, which are of a particular race.
    • Players generally cannot change the race of a colony while it has population (though advanced techs might allow this. To change a planet's race, the planet must be depopulated and recolonized with the new race.
    • Natives have to be accepted or removed for a colony to be populated with another race of a player's choosing
  • Planets with a different race from the "ruling race" of an empire (ie. the race of the empire's capital / homeworld at the start of the game) have happiness and loyalty penalties.
  • Conquered planets will contain population of the race that was on them before they were conqured. These planets will thus be less happy (in addition to any short-term happiness penalties about the invasion itself).
Mutation
  • A planet's race might change (without depopulation) during the game due to genetic drift or mutation or other such events.
    • Mutations happen randomly, though some warning should be given to players that it is starting to occur, so that they may make efforts to prevent it.
      • Races are still fixed labels for a planet / population, and there is no transition race that is some fraction one race and the remainder another race (for the population overall, or for each individual member of the population)
    • Various factors affect the liklihood and/or speed of mutation on a planet:
      • A race never mutates on its homeworld
      • If a planet's environment, size or star type are different from the homeworld of the race on it, it is more likely to have mutations occur.
      • Presence of a "mutogenic environment" special could cause mutations
      • Mutogenic plagues, either randomly / naturally occurring, or due to other players infecting a planet with a mutogenic virus as a form of politically-destabilizing biological warfare, could cause mutations
      • Planets with small populations are also more prone to mutation than high population planets.
      • Planets that are further from their empire's homeworld are more prone to mutation than closer planets.
    • When a mutation occurs, the planet's race changes to another race. Generally this should be an entirely new race, but some way to make a mutation happen such that the planet mutates into an already pre-existing race could be added.
    • After a mutation occurs, the planet on which it occurs is set to be the homeworld of the new race created (or made an additional homeworld of the race if this is not the first time the race has appeared).
    • If the race is newly created (not preexisting elsewhere), the new race's preferred environment is set to the environment of the planet on which it was just created.
      • If the mutated-to race already existed, then the environment of the planet should already be the preferred environment of that race.
    • For large empires, having lots of planets, particular different types of planets, colonized increases the chances of mutation happening. This results in reduced overall happiness in the empire, promotes revolutions and secessions, and otherwise hinders particuarly large empires.

Making New Colonies

  • Colony ships can make new colonies
    • in systems where the player doesn't already have a colony
    • in systems where the player already has a colony
  • Colony ships have a set race. Colonies made with colony ships have the race that was loaded onto the ship when it was made.
  • Making colony ships costs PP, like any other ship, but may also cost Trade, representing your influence, depending on the race you want to put in the ship, the availability of population of that race to fill the ship, and how far the ship is being built from the source planet(s) of that race
  • Colony ships may have a size or capacity, depending on how ships work, which determines how many colonists fit onto the ship, and thus how many colonists are initially on new colonies made by those ships.
  • Players can build new, empty colonies on empty planets in systems where they already have a populated colony, without need for a colony ship
    • The "Build Colony" project produces an empty colony (with 0 population)
      • Takes several turns, and costs PP, like any other build project
    • Saves the time and (higher) cost of building and moving into position a new colony ship.

Migration

  • Colonies, empty or populated, can be made Immigration Targets by their owner.
    • Immigration Targets are a sink to which population of the race of the colony can go to, after emigrating from other colonies.
  • Populated colonies can be made Emigration Sources by their owner.
    • Emigration Sources are a source from which population of the race of the colony leaves, going to other colonies
  • Population can only move from a colony to another colony that has the same population race.
    • Colonies have only a single race, which cannot be changed, unless the colony is destroyed and recolonized, or all population emigrates from the colony or is killed in some way.
    • Players can freely change the set race of colonies they own which have 0 population
  • If more than one Emigration Source or Immigration Target is available, migrants are taken from or sent to the different planets in some ratio. The ratio may depend on political or cultural factors, happiness, the existing populations of the planets or other such factors.
  • Even if playes don't manually mark a planet for emigration, the planet may be marked automatically (and uncontrollably), due to various factors such as emergencies or to-be-determined political or cultural or happiness reasons.
  • Even if players don't manually mark a planet for immigration, population may immigrate to the planet in relatively small amounts on its own, if the planet(s) involved have the appropriate race.
  • Migration may occur between different empires in some situations, to be determined. This includes both automatic and player-ordered migration, whether ordered by neither, one, or both empires' players.
  • If a player marks a planet as both an Emigration Source and an Immigration Target, the planet acts as whichever of these is most needed, given the other marked planets with the same race in the empire. If there are more planets marked as sources, the double-marked planet will be a target, and vice versa.
  • Getting population to migrate may cost Trade, representing influence you have over your population. The distance of migration, and desire of population to do the migration affect this cost.
Migration Sequence Example
  • Planet A starts with race 1, player wants to replace with race 2.
  • Player marks planet A for emigration
  • Player picks immigration destination for race 1:
    • If player already has an unfull planet with population of race 1, player can mark this planet for immigration
    • If player doesn't have an unfull planet with population of race 1, player can use an available empty colony, setting its race to race 1 and marking it for immigration.
    • If player has no availble empty colonies,
      • If player has uncolonized planet in a system that also contains colonized planet(s) controlled by player,
        • Player orders a new empty colony constructed on this planet (no colony ship needed)
      • If player has no available uncolonized planets in systems with controlled planets,
        • Player orders or arranges for colonization of planet, specifying race of new colony in process
          • Details of this to be determined. Player might order the colonization, leaving the game to find an appropriate place to build a ship and do so and automatically move ship to new colony and do colonization, or player might manually find an appropriate place to build the colony ship and manually move it and order colonization.
      • Player sets empty colony race to race 1, and marks it for immigration.
    • On subsequent turns, immigration destination is filled with emigrants from planet A
    • Planet A's population is eventually depeted, leaving an empty colony.
    • Player changes planet A's race to race 2, and marks planet A for immigration
    • Player marks a planet populated with race 2 for emigration

Object Stealth, Visibility and Detection

All objects, specials and starlanes ("items") have a Stealth meter. Most player-owned objects have a Detection meter. A player should be able to know the Detection and Stealth meters, as applicable, of any item or object that is visilble to the player (that the player can "see").

To determine whether a player can see a particular item, a calculation is done. The basic form of the calculation is to compare the item's Stealth meter to the detecting object's Detection meter, after applying various adjustments to these meters, including adjustments for the relative positions of the item and object, situation-specific adjustments, and adjustments from effects. After these adjustments, if the detector object's Detection meter is greater than the item's Stealth meter, the owner of the detector object can see the item.

If the detector object's adjusted Detection meter is less than the item's adjusted Stealth meter, the owner of the detector object may not be able to see the item; the player does not gain the ability to see the item from the particular detector object in question, but if another detector object owned by the same player can see the item, then the player can see the item. Players cannot see items by default; items are only visible to a player if they are made visible by one or more of that player's detection objects in a given turn.

Detection and Stealth meters are capped at 0 and 100. The effective Stealth and Detection of items and detector objects are also capped at 0 and 100 (after all adjustments are made).

Each type of detectable item has a default stealth meter value. Stars might be 5, planets 10, and ships 20. Starlanes would have widely variable stealth meters, so that some lanes are easy to detect, and others are nearly undetectable. Various adjustments to item's Stealth meters would exist for gameplay purposes.

Adjustments to Stealth and Detection are calculated pairwise for each detectable item and detector object; an item might get a bonus or penaltly to Stealth when being detected by one detector object, but not for a different detector object. Detector objects similarly get case-specific bonuses to Detection for a detecting a particular item.

Adjustments to Stealth and Detection are mostly provided by effects and conditions from specials, technologies, ship parts, etc. One adjustment that always applies is the adjustment for distance:

  • +1 to Stealth for each unit of distance separating the detectable item from the detector object

Other adjustments might include things like:

  • A scanner gives its ship +5 to Detection if the detectable object is a ship
  • A stationary cloaking device gives its ship +25 to Stealth when located in a system, but no bonus if the ship is moving tha turn
  • A psychic antenna building gets +1 to Detection against planets per point of populating living on that planet for all planets within 40 distance units
  • A specialized weapons sensor that gives its ship +10 to Detection against ships that have a particular type of ship part

Normal effects may also alter objects' Detection and Stealth meters. These are applied directly to the Stealth and Detection meters, and are not dependent on the particular pair of detector object and detected item. These might include:

  • A multiship cloak generator gives +10 to Stealth for all ships in its fleet
  • A giant noisy engine gives its ship -20 to Stealth
  • A starlane cloaking building that gives +10 to Stealth to all starlanes connected to the system the building is in

If possible, but not absolutely necessary, it might be nice to be able to do "third-person" pairwise adjustments to Detection and Stealth. These would be adjustments by one object to another object's or item's Detection or Stealth meter, depending on what kind of item the second object is trying to detect or what kind of object is atttempt to detect it. This might include:

  • A fleet anti-cloak sensor-booster on a ship gives all ships in the same fleet +5 to Detection against enemy ships that are cloaked

(In this case, the bonus applies only to a ship if it is trying to detect a particular kind item, but the bonus is given by a part on another ship)

Applications

For balance purposes, large and powerful ship parts such as engines or weapons could have significant negative penalties to Stealth of the ship they are on. Specialized stealth-purpose weaponry would be more difficult and more expensive to make and would be less effective for the cost than normal weaponry, but would not have significant Stealth penalties.

Detection equipment could give bonuses to Detection against moving ships / fleets more so than stationary ones, making for some interesting cat-and-mouse dash-and-hide tactics across the galaxy map.

Cloaking technology would obviously give bonuses to Sealth. Active detection equipment would give penalties to Stealth and bonuses to Detection. Passive detection equipment would just give bonuses to Detection without reducing Stealth.

Stars that are far enough away from a player's planets and ships would not be visible. This allows for an interesting and fun revealing of the map as the player explores the galaxy.

Starlanes come with a variety of initial Stealth ratings. With technology, a player's ability to detect starlanes improves, revealing new connections between systems, with the resulting strategic consequences. Players with good lane detection might be able to escape form superior battle fleets which cannot see the lane they used to escape.

Eventually, players would gain the ability to alter starlane visiblity, giving them the ability to hide lanes and systems from other players, or to trap other players who cannot detect hard-to-see lanes. Players might eventually be able to create new starlanes, which would initially always have very low Stealth ratings.

With even more advanced technology, players could create new starlanes that have high Stealth ratings, allowing players to create an unexpected and unseen back door into a system that the system's owner cannot see.

The homeworld special could increase the Stealth rating of starlanes near the homeworld for all empires other than the homeworld's owner. This would make it hard to rush and kill an empire's homeworld right at the start of the game; it would be necessary to first research and build some basic starlane detection equipment for the invasion fleet.

Since item visiblity is determined each turn, a player might be aware of an object or starlane on one turn and then not on the next. If starlanes sometimes randomly or slowly change their visibility over time, or are sometimes destroyed unexpectedly by random events, the player would not know whether a previously visible starlane suddenly disappearing was due to its visilbity changing naturally, the lane being destroyed naturally, the lane being cloaked by an enemy ship in order to prevent the player form using it, or the lane being destroyed by an enemy ship.

Another always-on adjustment could be to give ships a bonus to Detection that increases with time if they stay in a system for several turns without moving. This would give a player a choice while exploring: to stay in a system for a few turns to get a bonus to Detection and possibly see specials or hidden items, including starlanes, or to keep moving and explore more systems less thoroughly.

Players could trade starlane maps with other empires. The trade could specify that information about starlanes only of a certain visiblity level are included in the trade (players are able to know the visibility rating of any item they can see).

Hiding all the lanes surrounding your systems would be a new strategy, which could counter another player's big powerful ships. If the player cannot get big powerful ships to systems to attack them, they are useless.

Starlane Construction / Destruction

  • With appropriate advanced tech, players can create and destroy starlanes
  • Ships travelling on a starlane when it is destroyed are lost
    • Players 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

Moved to: User:Geoff_the_Medio/Ships#Ship_Speed

Ship Cloaking

Moved to: User:Geoff_the_Medio/Ships#Ship_Cloaking

Espionage

If some concept of leaders exists, spies could assassinate enemy leaders, as has been done in other games. But later, with improved espionage tech, spies could impersonate and replace leaders, without the other empire knowing, in a manner similar to Face Dancers in the Dune series, or Changelings from ST:DS9. How this would work in practice would depend on how and what leaders do.

Micromanagement

Often detailed micromanagement is fun and interesting at the start of a game, when there are relatively few planets / cities to deal with and the player has more attention to spend on each, and thus cares more about each individually. Having lots of details and decisions for each city / planet at this time is good. However, the same level of micromanagement at the end of a game when there are dozens or hundreds of planets / cities bogs down the player and is tedious, rather than enjoyable.

As such, it is desirable to vary the amount of micromanagement each city / planet needs from a player during the game, from a lot at the start, to very little or none at the end.

In order to do this, using automation is not an ideal solution. It is better to actually vary the amoutn of micromanagement that is possible.

This could be done by having a number of things for the player to build and decide at the start of the game, which are still relevant later in the game, but which can only be decided a limited number of times or for a limited time at the start of the game.

This could be done by making available various buildings at the start of the game, but limiting the number of each buidling that can be made. At the start, the player would have lots of decisions to make about which buildings to build, and where. Later, the buildings would all be built, and the player wouldn't have any more of these buildings to make.

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 all ships of a fleet move, the net effect should be as if the fleet had been moved with a single effect.

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.

AddStarlane

Add starlane(s) to the target system, connecting to systems that match the parameter condition, with specified starlane Stealth meter value.

Has parameters: condition, and stealth

This condition is used to select one of the endpoint systems of the starlane(s) to be added. The other endpoint is the target system of the effect.

This effect adds starlane(s) to the target system, connecting to all systems that are matched by condition. The added starlane has a Stealth meter with value specified by the stealth parameter.

If a starlane already exists between target object and an object matching <Condition>, that object is ignored (no new starlane or change to existing starlane occurs).

RemoveStarlane

Removes starlanes connected to the target system, and matching the parameter condition.

Has a parameter: condition

All starlanes with one end at the target system, and the other end at a system matching condition are removed.

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

SetStarlaneStealth

Alters the Stealth meter of starlanes connected to the target system and which are connected to another system that matches the parameter condition

Has parameters: stealth, and condition

Since starlanes are not UniverseObjects, they probably need to be accessed through the systems they are attached to, rather than directly. If this can be changed, then this effect can be adjusted accordingly.

It will be necessary to be able to make a relative adjustment to the starlanes' Stealth meter, which might be complicated. Since the target object is actually a system, not the starlanes itself, Taraget.Stealth would be the system's Stealth meter. Some way to access the starlane's Stealth meter is needed, so that TheStarlane.Stealth can be used for effects such as adding +10 to Stealth of a starlane.

Rename

Sets the name of an object.

Rename newname = "SOMETHING_FROM_STRINGTABLE"

The utility of this effect would greatly incraese if there was a way to substitue into strings referenced in effect descriptions, or to combine multiple strings. This would allow changing something named "Happy City" to "Ruins of Happy City", or similar.

SetEmpireStockpile Extention

Has a new parameter, max, which is set to Max (or perhaps True?) to indicate that the effect alters the target object's owner's maximum stockpile, not the current.

SetEmpireStockpile stockpile = Minerals max = MAX value = Target.Owner.MaxMinerals + 5

Likely most resources would start out not stockpilable, and would be made stockpilable by various buildings / techs over the course of the game. All resources (food, minearls, trade, research, industry) should be treated equally as potentially stockpilable by the code, and if the designers decide that, for example, research shouldn't be stockpilable, then there would be no buildings or techs that increase the default max stockpile amount of research above 0 in the game.

SetResearchProgress

Sets an empire's progress in researching a tech. Could use to give small bonus once per turn:

SetResearchProgress tech = "TECH_NAME" progress = tech("TECH_NAME").progress

GenerateSitRepMessage

Causes a SitRep message to appear to the owners of target objects

GenerateSitRepMessage text = "STRINGTABLE_ENTRY"

Future Conditions

PlanetSlot

Matches based on which slot a planet is in in a system (orbital distance from the star).

Targetted

The Targetted Condition is mentioned above.

Sorted

It would be useful to be able to pick the top or bottom some number of objects sorted by some numerical criteria. I might want to fire on the top 5 planets by population in the galaxy.

Future Attributes

PlanetSlot

... in which slot (1 to 10) a planet it located in its system.

Strategic Resources

Ala Civ3, various buildable items (buildings, ship components) should require strategic resources to be available to the empire building the items, and the resource should be available (directly or via unblocked trade routes) to the actual location at which building is occurring.

With later tech advances however, synthetic / replacement sources of various strategic resources could become available.

Strategic resources could be either on/off like Civ3, or of fixed per turn output which limits how many items can be built using that resource in a given turn. Strategic resources should probably not be stockpilable, as this would effectively make the difficult-to-get regular resources (like industry, minerals, food, trade/influence, and research) which would be too complicated and require too much micromanagement.

If an empire has access to a resource, perhaps they should then has as much of it as they want, unlike the Civ3 system in which each source of the resource can be used by one civ, and additional sources an empire has access to can be traded. This is somewhat odd, as one source is enough for any amount a single empire wants to use, but two empires each building anything requires two separate resources. If resources are infinite capacity, fine, or if they are fixed capacity, fine, but they shouldn't be both inconsistently.

Various items could either require a resource to be available to have any PP put towards the project on a given turn, or could treat the availability of a resource as a bonus of some sort, perhaps increasing the allowed PP / turn that can be spent on a project and thereby allowing it to be built faster than normal, or alternatively by multiplying the actual PP spent, reducing the effective cost / turn but not changing the time taken to build the item.

Implementation

Strategic resources could just be a special. A building or ship could have a "buildlocations" field, which would be a condition that decides whether something is a valid build location for the building. To make a resource required to build something, a building's "buildlocations" condition could be withindistance( and(affiliation(source.owner), hasspecial(theresourcespecial, infinite distance)) ). This would make it more difficult to do resource trading later, but things can be changed when it comes to that. There could also be a "ConnectedSafely" condition, which would only return true for locations connected by "safe" starlane jumps (ie. between systems controlled by source.owner) used in place of the withindistance.

Strategic resources could also be a property of an empire. There could be an effect "GrantResource" that would give the owner of the source object access to a "resource". There would then be a condition "ResourceAccessible" that would match objects owned by an empire that has access to the indicated resource. This is a bit less intuitive to do connectivity with (ie. anyone owning the source would have the resource, regardless of whether they have a safe route to the source from their build locations).

Strategy Whatnot

  • Offensive Ships would neutralize or obliterate Econ by blockading or destroying planets, and help get Ground Troops into position, or could deliver Biowarfare or Espionage to its target, and if would generally overcome Defensive ships if used specifically for that purpose or for escort.
  • Defensive Ships can cut off Offensive Ships' supply lines, prevent Ground Troop landings, prevent delivery-dependent Espionage and Biowarfare, and are generally cheaper than Offensive Ships
  • Planet Defense would neutralize Offensive ships from destroying planets (but wouldn't help against Blockades, Biowarfare, Espionage)
  • Ground Troops capture planets, rather than destroying, and can bypass Planet Defense.
  • Cloaking would bypass Defensive Ships, allowing Espionage or Biowarfare, but also helps Defensive Ships disrupt Offensive Ships' supplies without themselves being destroyed by the Offensive Ships.
  • Biowarfare could eliminate Ground Troops, allowing easier planet capture, or could bypass Planet Defense to eliminate Econ or Industry.
  • Espionage would disable Planet Defense, and could neutralize Industry and thereby Offensive Ships or Defensive Ships.
  • Culture and Trade would neutralize Offensive Ships by making the attacker's population unhappy about the war.
  • Econ drives Trade and Culture, and is necessary for extended Offensive Ship action.
  • Space-Storm Control could cancel Cloaking
  • Starlane Manipulation could neutralize Econ, prevent or enable Offensive or Defensive Ship Movement
  • Most things neutralize themselves (eg. Biowarfare, Offensive Ships, Culture, Ground Troops...)

Some things would be more expensive and extensive than others, counterbalancing overall effectiveness.

Combat System Specials

Could have some planets or systems with a special that disables certain (or most) technology. For space battles, this would mean many otherwise powerful components on ships are useless. For ground battles, this would have the same effect, but would also mean that races with higher physical strength would have an advantage in ground combat that would normally be overwhelmed by technology.

Mutation

Way to penalize larger empires:

Planets have a particular race. Planets with a different race from the "ruling race" of an empire (ie. the race of the empire's capital / homeworld at the start of the game) have happiness and loyalty penalties. Captured planets (colonized by another empire) will have a different race from that of the capturing empire, so will be less happy (in addition to happiness penalties about the invasion itself).

A planet's race can generally only be changed by players by completely depopulating it and recolonizing with another race (latter tech may change this).

A planet's race might change (without depopulation) during the game due to genetic drift or mutation or other such events. Factors that increase the liklihood of mutation are if a planet's environment, size or star type are different from the homeworld of the race on it. Planets might also have a "mutogenic environment" special, or there might be a mutogenic plague, or players might infect a planet with a mutogenic virus. Mutation might also just happen randomly (though never on a race's homeworld). Planets with small populations are also more prone to mutation than high population planets. Planets that are further from an empire's homeworld are also more prone to mutation than closer planets.

For large empires, having lots of planets, particular different types of planets, colonized increases the chances of mutation happening. This results in reduced overall happiness in the empire, promotes revolutions and secessions, and otherwise hinders particuarly large empires.

Moral / Cultural Issues

  • Natural environements should be protected vs. Terraforming is good
  • Preserve genetic purity of race(s) vs. Embracing genetic engineering of race
  • Accepting of body modification (allowing cyborgs and their benefits) vs. Rejecting body modifications
  • Natives should be left on their planets and not disturbed vs. Natives should be contacted to give benefits of high tech and the empire's more-developed culture vs. Native should be enslaved / assimilated and put to work for empire
  • Prefer to leave lesser-developed races to natural evolution vs. Want to accelerate / uplift other races' development
  • Believe all sentient being have right to exist vs. Believe all other races, empires, and uncooperative planets may be destroyed or depopulated when convenient (genocide, civilian killing)
  • Prefer to be isolated from other races (unhappy if other races are on planets in same system, or (less so) in nearby systems) vs. Prefer to be close to a mix of races (happier if this-race-populated system or nearby systems contains multiple races)
  • Prefer to be part of large empire vs. Prefer to be part of small empire

Maintenance

Maintenance

Buildings cost a lot of trade to maintain. Having many buildings requires having lots of planets focused on trade to pain maintenance. Trade is used to convince workers to toil away in buildings (may be by paying them, but could be through other uses of trade as abstracted as influence). Some government or societal choices could remove or greatly reduce maintenance costs, however... though whether communism or mind control removes these costs, or actually increases these costs in order to maintain, is debatable.

Ships cost industry (not PP) to maintain.

Ship repairs cost PP.

RTS Non-Combat

Real Time Mode having consequences, and uses, other than just battles...

  • Exploring system reveals stuff in system faster than might otherwise occur
    • Any hidden bases / cloaked observers in system are somehow placed on RTS playfield, and if exposed by rules of RTS mode, are revealed in strategic mode, with whatever consequenses that entails
  • When an special event occurs, or when first exploring a system, the player might go into RTS mode and actually explore the system or deal with the event, if applicable
    • Space Monsters in System - Player locates and destroys them and their nest in system
    • Pirates Raiding System - Player finds and destroys their base in system
    • "Goody Hut" in system - Player initially sees some monolith or space debris or weird nebula or spatial anomaly on the RTS map. Player can investigate this or not, and deals with results in RTS mode as well, particularly for any resulting battles.
    • Player Meets Unknown Alien(s) / Fleet
      • Unknown Fleet is Newly-Met Foreign Empire - Players can meet and greet and form diplomatic relations, or can start shooting as soon as they see eachothers' ships
        • If one player has cloaked ships, and the other does not, or by some other means one player knows of the other but is hidden to that other, then the knowing player can choose whether or not to uncloak or otherwise reveal his/her ships' presence. If the cloaked player choses to stay hidden, there is no RTS encounter.
        • Unknown aliens might actually be an already known empire, which is hiding its ships' ownership. Players need to be cautious when meeting unknown ships in RTS mode, as they might be an enemy's (or an ally's) ships in disguise. Disguise might be to make owner of ships unknown, or to make ships look like they belong to another empire to frame them for some action.
      • Unknown Alien is intelligent nonplayer character - Players might meet alien heros or weird intergalactic aliens that are just passing through the galaxy and who might interact with the player some way. The player would meet these aliens in RTS mode, and how things go could affect their relationship later.
        • Heros might observe player's actions in some situation and join or not join the player's empire as a result.
          • Initially, battle might appear to be a simple space-monster cleanup, but the hero might like or dislike space monsters, so if the player kills / doesn't kill them, the hero might react differently
        • Aliens would be represented in RTS mode as a special-looking ship (though this ship might be cloaked or otherwise not obvious special while the alien observes the player's actions initially)
          • In some cases, the player might get use of the ship, or have to fight the ship, after the alien decides how to react to the player's action (ie. join up or fight or go away silently).

Misc.

  • Ala Dune, have prescience tech that can be voided by prescience-blocking tech or prescience-immune breeding program tech. Base prescience tech is prereq for both, but they have distinct other prereqs in other branches of tree.
  • Have planetary shields be strong, and ships' planetary bombardment be weak. This makes having ground troops (which can bypass the shield) important, or makes it useful to blockade a planet without actually attacking it (since you can cut off its supply inport / export without attacking)
  • Have techs record the turn on which they are learned by each empire (or empires record the turn on which they learn each tech). Can then have effects / conditions that check the date a tech was learned, and apply effects differently accordingly. One use might be to give a bonus to all ship designs created by an empire after the turn a tech is discovered, but not to ship designs created before that turn.
  • If observer clients are permitted, have option to prevent observers from same IP as a client - prevents player from joining same game as observer, but doesn't prevent multiple players from same IP form playing in the same game (eg. if behind a router)
  • Have some kind of fighter available of the name Foo Fighter
  • Molybdenum Trioxide = MoO3
  • "Slgorith", "Octopi", "Sarcomere"
  • Mining meter bonus buildings decline in effect over time: As each new mining technique is used, production increases. Over time, accessible minerals are depleted, reducing production, and necessitating new sources / techniques.
  • Hypercomputation: link "Digital Oracle"
  • Telepathic interrogation (cantact only)
  • Telepathic interrogation (remote)
  • Anti-telepathy conditioning
  • Galactic Genome Project
    • Have research-related wonders that give (decaying) bonus to research over time to builder, representing accumulated research knowledge & skill from completing project
  • Synesthesia
  • Social choice: comprehensive medical treatment to improve health, or penalty to health that result in natural selection improving race characteristics over long term
  • Holistic Pathology
  • Ecophagy
  • Have some buildings require their unlocking tech to function, and others not. This way some buildings would be useless to another empire that captures them if the required tech is not known, while other buildings would keep working fine. Could also be done as a refinement. "Lockouts", similar to "Self-Destruct" when captured. Requires a root tech to unlock all of the refinements for this type of building. When researched, refinements make building stop working unless owned by builder, or empires that known a certain tech... etc.
  • Have planets that are growing quickly have a negative penalty to current meter values, to represent the fact that new population can't be immediately trained to do the jobs of the preexisting population. The size of this penalty could depend on the infrastructure meter.
  • Certain star types, or certain buildings (acient ruins?) block sensors within some radius of them
  • Ion Storms follow starlane paths. Randomly choose new direction after arriving at a system. Can set up storm attractors or repellors (on ships?) that affect chance a storm will turn towards or away from a system. Eg. storm (#'s) moving towards A. Repellor at C makes storm more likely to move towards B. Attractor at C makes storm likely to move towards C. Could also make storm generators, and use them to attack enemies planets or uncloak their ships.
   |
 --B
    \      |
     \     |
      A----C
     /      \
   #/        \
  ###
  /#
 /
  • New Scripting properties - should probably make properties of target, to emphasize that they change depending on the target for a multiple-target effect
    • SourceTargetDistance - direct line distance between source and target being acted on
    • SourceTargetJumps - number of starlane jumps between source and target being acted on, using starlanes known of by source's empire
    • SourceTargetAngle - positive CCW angle between +X direction and direction of direct line between source and target
  • Add limit to number of a particular buildable item that can be enqueued per player. Particularly useful for buildings that are limited in number per empire. Probably allow player to override this... make it a warning...
  • Maybe food, after preventing starvation, increases max population, rather than the health meter. This would reduce the factors affecting growth rate to planet current population, planet max population, and planet health meter... sort of... I dunno

Design Changes past v0.3

Resource Production Formula

We should revisit the formula that determines planet resource production from current meter value and population numbers. Currently we do:

(Production) = (Planet Population) / 10 * (Meter)

With this, if the meter is 12.5 and the population 3, the resource production is 3/10*12.5 = 3.75. This is not very intuitive. It would be much more intuitive to have:

(Production) = (Planet Population) * (Meter)

With this, a change of X in the meter would result in a X * (Population) change in the resource production. So if your resource meter is growing by 0.18 this turn and your population is 3, you can more easily estimate the change in resource production that will result (0.54) as opposed to 0.054 with the currenet formula). Just omitting the 10 makes estimation and understanding much easier.

To do this, we'd need to rebalance things a bit. Currently for farming and health meters, a meter value of 20 is the break-even point. Health below 20 results in population loss, and farming below 20 result in the planet producing less food than it consomes. If the resource production formula is changed, then this will throw off the farming meter break-even point (which would now be 2 instead of 20, leaving little room below breakeven for variation).

Instead of 0 to 100, we could have all meters range from 0 to 10, and have the break even be 2. This would mean most bonuses to meters would be fractional numbers though. I'd much rather see a building with +5 to farming than +0.5 to farming.

Instead of each population point consuming 2 food for the baseline no-health penalty state, we could have them consume 20, so that we could keep then meter = 20 point for all meters, as well as their scale. Right now:

(population) / 10 * (farming = 20) = 2 * (population)

or breakeven if population each consume 2 food. It would be a relatively trivial change to make population consume 20 food, thereby keeping meters ranging from 0 to 100, bonuses integral (eg. +5) and making the relationship between meter values and resource production clearer.

There is still a downside to this though, which is that instead of techs costing 20, 50 or 200 research points per turn, they'll now cost 200, 500 or 2000 research poitns per turn. Smaller numbers are nicer in this case... though I suppose upping them all by a factor of 10 isn't too bad once players get used to it. Balancing works out the same in practice.

Reduce Population Numbers to Compensate

Currently the player's homeworld has a population of about 30 and meters of about 25 for a primary focused resource. Other well-developed planets have populations of 20 or 25 and meters of about 15 for a primary focused resource. These translate into primary focus resource production of 75 and 30 or 37.5 respectively. With three planets focused on a resource, including the homeworld, and a few other nonfocused planets, an empire can generate about 150 of a resource per turn near the start of the game, before effects that give bonuses to meters kick in. Later, an empire could be generating several hundred per turn, in the low tens of hundreds.

With these resource production numbers, if we have an empire researching or building three to five things at a time, the things will individually cost 30 to 50 resource per turn at the start of the game, and 300 to 500 resource per turn near the middle of the game.

If, however, we change the resource generation formula to give ten times as many of each resource, the costs given above will have to scale up by a factor of ten as well. In my opinion, those numbers would be less attractive and fun. It's much more difficult and less intuitive, for me, to think about thousdands of something, compared to hundreds. It's also more difficult to display empire and system resource production numbers in the thousands or tens of thousdands than the hundreds, as there are more 0's to display after each number, or we have to switch to writing how many k's of production there are, which is inelegant, IMO.

To fix this, however, we could reduce planet population numbers. If relatively big starting planets planets had populations of 5 or 10 instead of 20 or 30, and resource production per population was increased by a factor of 10, then the net change to resources compared to now would be an increase of about 2.5 to 3.33. Techs or buildings would cost 100 to 150 at the start of the game, and 800 to 1500 at the end of the game, per turn, to build. These numbers seem nicer...

Also, if planets have 5 or 10 population, then we can say that each population point represents 1 billion people, or the equivalent alien population that procues the work / resource output of 1 billion humans.

Selective Resource Meter Bonuses

Early Farming Tech gives to planets with Primary Farming Focus:
+4 for Terran Planets
+3 for Ocean or Desert Planets
+2 for Tundra or Swamp Planets
+1 for Toxic, Radiated, Barren or Inferno Planets

Early Farming Tech gives to planets with Primary Farming, Secondary Farming or Primary Balanced Focus:
+3 for Planets in planet slots 1 or 2 (innermost)
+2 for Planets in planet slots 3 or 4 (middle)
+1 for Planets in planet slots 5 or 6 (outer)
0 for Planets in planet slots 7 to 10 (fringe)

Something else could differentiate for trade... perhaps Early Economics Tech gives to planets with Primary Trade Focus a bonus dependent on the number of (populated?) planets in the system, or the number of starlanes connected to the system, or the number of other populated systems within 2 starlane jumps of the system. Perhaps foreign-owned systems count double? Or perhaps foreign-owned systems don't count for the early trade-bonus techs, but do count equal for middle-stage trade techs, and much higher than domestic systems for late-stage trade techs.

We could also techs which selectively give bonuses to planets based on other features of the planet's system. For example, an asteroid mining tech would only give bonuses to mining in systems that have an asteroid belt. This is simpler and easier than requiring the player to build an asteroid mining base or somesuch, which seems like unnecessary micromanagement.

We could also (in future) differentiate planets by how far they are from the

Buildings vs. Effects Techs

In order to make focusing on things other than production (for a whole empire, not just a planet) viable as a strategy, we (will) have some application techs that have effects that function as soon as the tech is researched by a player, in addition to application techs that unlock buildings which have to be then built before the effects function. This way a player who wants to focus on building stuff / high production can generate a lot of PP and build lots of buildings that s/he unlock via research, and another player who wants to focus on non-proudction stuff can still get bonuses to resource meters directly from techs that s/he researches.

In order to balance this, there needs to be some difference between effects-applications and unlocking-applications. Firstly, since an effects-application immediately gives a benefit (presumably), while an unlocking-application requires a building to be built after researching its tech, the effect size / tech cost ratio needs to be lower for the effects-techs.

The total cost of getting the effects from an unlocking-tech is really the cost of researching it and the cost of building (and maintaining) the building that it unlocks. Buildings should generally have larger bonuses to compensate for this.

Buildings also are different from techs in that buildings have additional player choices associated with them. Buildings have to be built at a particular location, and if the building has a limited range in which its effects function, the location is important for the functioning of its effects. Conversely, application are always taken to be located at the capital of the empire (how to deal with empires with no capital needs to be determined), and in general tech effects should act on the entire empire (or entire empires or the whole galaxy) rather than some spatially-dependent area like buildings.

This extra choice also means that buildings can have negative penalties / effects to counterweigh their bonuses / effects. For example, a building could give +3 to farming, but also take -3 from industry on all planets it acts on, or perhaps +3 to a meter to one gorup of planets, and -7 to another group. The choice of whether and where to build such buildings is thus nontrivial for the player, which is good for a strategy game, but producing building of this sort (which may initially seem to be net 0 benefit due to equal magnitude positive and negative effects) is still generally worth doing, as the player can specialize regions of his/her empire, or particular planets, for particular purposes. That is, if a building gives +5 to farming and -5 to industry on a planet that wasn't producing any industry anyway, the player is still better off than if they had not produced the building.

With techs however, all planets / possesions of a player are acted on by all effects, and the player can't turn the tech on or off after researching it. Consequently, all tech effects need to be "monotonically increasing" in a sense... that is, all effects of effect-techs need to positive bonuses, and none can be negative penalties.

Aside: There could also be some "neutral" effect techs, in which some change is made to the empire that is neither obviously positive or negative, but this does not mean that an effects-tech could have negative AND positive effects that are deemed to balance... Each individual effect of an effects-tech should be positive or neutral. The player could then choose to (or not to) research a particular "neutral-change" effects-tech, but we wouldn't have to deal with the annoying situation of getting a tech that has a big negative effect on an empire.

Buildings have to be built after their tech is researched, so unlocking-techs should genearlly be faster to research and less expensive than effects-techs for similar-size bonuses. Even though buildings have negative and positive effects, the player should be able to apply them strategically for a net larger benefit from their existance than a similar-cost effects-tech with its purly postive effects.

There also needs to be some consideration of how to make focusing on buildings or effects-techs and not the other actually a one-or-the-other choice, as opposed to it being possible to do both. Since buildings have an additional production cost, if a player if focusing on research for effects-techs, and not production, if they research a building-unlocking tech, they'll have little extra production to spend producing the building. In order to maintain this situation, effects-techs should give very small or very limited bonuses to the production meter. Similary, if effects-techs are both relatively expensive and take a long time to research, then if a player starts of with buildings and uses them to increase his/her research rate, s/he will still have to wait a long time to research tech effects. As well, if we make buildings give small or very limited bonuses to the research meter, then buildings-focused players will have little extra research to spend on effects-techs, and doing so would prevent them from unlocking potentially more-valuable higher-tech buildings.


UI

Perhaps meters should be hidden from the user in the UI. Instead only resource production numbers would be shown. In descriptions, a building that gave +4 to a meter would be described as giving a bonus to resource proudction of "+4 per unit of population". On the focus-selection UI, the current a max resource production numbers would be shown, not meter values. These could be shown as

cur/max

or

 cur
(max)

or

 cur (+ change)
     (max)

or

Cur: Cur (+ change)
Max: Max (+ change)

These numbers would be shown over top of the various possible focus selection icons.

By switching to a formula of

resource proudction = population * meter value

rather than

resource proudction = population * meter value / 10

it becomes much easier to hide actual resource meter values form the user, and instead only have the user work in resource proudction numbers, since the relation between population and bonuses is simpler, so can be easily put into all tech descriptions.