Michael :

Updated topics list, note there has been some movement and that the dates are week commencing: 23 September 2013 Sensors & Scanners 30 September 2013 Updated In System Travel 07 October 2013 Faction Goals 14 October 2013 Docking & Stations 21 October 2013 Ship's Crew 28 October 2013 Vouchers 04 November 2013 Salvage Rules 11 November 2013 Wingmen 18 November 2013 DDF God Powers 25 November 2013 Ship Roles 02 December 2013 Ship Customisation 09 December 2013 Flight model controls Michael

Michael :

Обновленный список тем. Обратите внимание, что мы кое-что передвинули. Даты - с точностью до недели: 23 сентября 2013 Сенсоры и сканеры 30 сентября 2013 Обновленная тема о внутрисистемных полетах 07 октября 2013 Цели фракций 14 октября 2013 Стыковка и станции 21 октября 2013 Корабельная команда 28 октября 2013 Ваучеры 04 ноября 2013 Правила сбора трофеев (спасибо H-Arck) 11 ноября 2013 Ведомый 18 ноября 2013 DDF Божественные силы (? ) 25 ноября 2013 Роли кораблей 02 декабря 2013 Кастомизация кораблей 09 декабря 2013 Управление полетом (полетной моделью) Michael (// Steel )

Tom Kewell :

Hello DDFers! It's Friday and time for an update on Injected Events! INJECTED EVENTS Injected Events allow Frontier to inject situations into the Elite: Dangerous galaxy, allowing us to be reactive to player habits and actions, and to influence and direct the community of players. GOALS Create large scale events for all players to enjoy within the ED universe, outside the scope of the background sim. Use player influences and system data from within the galaxy to feed into a meta-game system. Provide story and content for missions and other environmental encounters. Injected events rely on a number of systems and information: Background simulation – The background simulation manages changes to a systems status, based on player actions, nearby systems, events, and injected events Faction information – every faction will have status information, including relationships with other factions, assets owned, Government types, local specialisations & NPC hierarchy. System Information – Assets within a system are listed here as they are discovered. Discovery of new assets within a system may trigger different faction behaviours. Injected events may require, or create certain assets in a system Player influence – players will be able to influence a star system or faction through many different avenues (see Player Influence below). This information will be held & controlled by the meta-game, and then used by the developers to create these larger events and happenings. The idea is to create injected events that are relevant to the situation. In the future, we would hope to create a system that maintains a semi-autonomous approach to this, creating these events without the need for developer interaction, but also still allowing the team to inject separately. META GAME The entire system will be based off of rules dictated by a meta-game system, which will look at each location and calculate a set of factors by which an injected event can best be initiated. What this will mean is taking the influencing factors mentioned above and seeing where events would be best placed. For example: A colony with a large population, nearby to a newly found, uninhabited Earth-like world might colonise that planet. A colony suffering from famine or being under-populated would not. A star system with low wealth, low development or low standard of living levels would be more likely to suffer from pandemics, famines, governmental collapse and other serious planetary failures. Star systems that are contested by 2 opposing forces may suffer from war, be it civil or between factions. This shouldn’t stop the developers from injecting more random events, such as extinction level asteroid collisions or alien influences if the need arises. Its function is to create relevance and a sense of a living, evolving galaxy. OUTCOME OF INJECTED EVENTS These events have the ability to significantly affect the ED universe, changing systems and locations, allowing us to keep it as interesting as possible. The repercussions of injected events could cause long term changes to the background simulation in a system. Players may also get opportunities to mitigate changes to a system through events in the background simulation. E.g. An Injected Event causes two factions to go to war with each other in a system. As the background simulation now has influence from the warring faction, it will generate events and missions linked to that war. If players complete missions relating to negotiating peace and ending the war, and react in the right way to events, they could stop the war and mitigate the effects of the Injected Event. PLAYER INFLUENCE Players will be able to influence this system, since the meta-game will feed off of changes in the simulation from many different sources, including players. For example: Missions – generally these will have the largest positive or negative effect on the system, depending on faction, success or failure, nearby enemies or allies, the importance of the mission undertaken, and various unforeseen consequences. Trade – player trade will have a minor effect on the system, although a star system already under the effect of an injected event may be exploitable (i.e. food sold to a star system suffering from a famine would fetch a very good price). NPC interactions – attacking, defending, interacting and killing NPC’s within a star system or faction will have an effect. The everyday NPC’s met won’t be high level, so their influence will be limited to small changes. For example, killing a trader will negatively affect the wealth of his faction or star system, but not to a vast extent. Exploration – discoveries made by players, once sold into the system, will be unlocked for the system to use for injected events. Players news feed will regularly refer to Events and Injected Events that are nearby to, have been interacted with by, or pertain to the player. Injected Events can only be added to online players games. Offline players will still have changes applied by the background simulation, but will not get the broad influences of Injected Events. Several Injected Events can be occurring at the same time in the Galaxy. They may be linked together (such as a famine that affects multiple systems), or could be unrelated and seperate. Injected Events can be linked with each other and could form a sequence of events, creating a narrative around the events that are occurring. Backer influence over injected events will be a topic to be discussed at a later date. Please keep your examples of Injected events coming and any feedback on the system coming!

Mike Evans :

Here is the updated proposal. I've tried to streamline the whole thing and included some missing points. We're quite happy with this system however any mention of VFX are to be discussed and decided upon later (any ideas are welcome). SENSOR MECHANICS Default Sensors for all ships Upon arrival to a new location a picture of potential contacts around the player based on their distance and signature appears (see Signature and Sensors below) More detailed sensors are located in a forward facing arc that have better range capabilities thus resolving contacts where the default all-around sensors cannot (usually a multiplier to the default sensor range) In addition to the above false positives are put into the mix depending on the quality of the sensors and/or any environmental factors (see Signature and Sensors below) To resolve a contact the distance between the ship and the contact needs to be reduced and/or the signature of the contact needs to increase (see Signature and Sensors below) A low signature contact won’t resolve until it’s quite close where as a high signature contact can be resolved from quite a long way away Signature can be based on several factors including heat and engine emissions Only contacts that have been validated can be targeted by the targeting computer so that weapons can provide assistance/gimballing/lock-on etc. Advanced Passive Sensors These are deployable sensors that dramatically improve the ship’s forward facing detection abilities by significantly increasing the range at which a specific signature value can resolve a contact As they are deployable they take up a valuable hard point on the ship Passive sensors like these don’t affect the ship’s current signature to other ships sensors other than the potential heat increase through power used Advanced Active Sensors These are deployable sensors that actively search for contacts using strong EM pulses and other forms of detection that dramatically increase the ship’s own signature as a result They are extremely powerful in that potential contacts within their sensor range can be validated instantly at the cost of also lighting the ship up to everyone else They come in both forward facing only and in fully spherical configurations Forward facing typically operate to much larger ranges and are quicker than the all around types Activating an active sensor will “ping” the area and instantly reveal any potential contacts that the sensor is able to detect The further away a contact is the less likely it will be able to be detected After activating a contact will be told they have been “pinged” and can then look out for possible new sensor contacts that have just resolved to find the likely suspect SIGNATURE AND SENSORS Sensors are tuned to be able to fully resolve a contact at a specific distance providing the signature is equal to 1 For example a sensor with range 8000m will be able to fully resolve a contact at 8000m with a signature of 1 If the contact was instead at 4000m away then it would only require a signature of 0.25 to be resolved Likewise a contact at 16000m away would require a signature of 4 to get resolved The environment can affect the stats of the sensors such that ranges are reduced, default signature values increase or lowered, arcs widened etc. Additionally special equipment could be used to affect other players scanners such that effective ranges or signatures are reduced when they being scanned If the contact is unresolved because their signature isn’t high enough for the range they’re at to be detected instead a scalable VFX is applied on the sensor UI to indicate the possibility of a contact The close the contact is to being resolved the more focussed and consistent the VFX is so the player can try to get closer or turn to point their more powerful frontal sensors at them to finally resolve the contact Distant and low signature contacts might have zero VFX applied or barely show up as a sensor glitch at all False positives are mixed into this to add a layer of uncertainty to the above TARGETING MECHANICS Once a ship has been resolved on the sensors the player can target them to provide a more detailed readout on the type and status of the ship Targeted ships are highlighted on the sensors as well as on the HUD Detailed readouts of the ship are displayed in a dedicated panel on the cockpit whilst the ship is targeted By having a ship targeted several other mechanics can come into play based on the equipment installed and/or deployed on the player’s ship: Missile lock (described below) Subsystem scanning (described below) Cargo Scanning (Mechanically identical to subsystem scanning) Bounty Scanning (Mechanically identical to subsystem scanning) Weapon gimballing (ability for gimballed weapons to provide aiming assistance on targeted ships) MISSILE LOCK To begin the missile lock sequence the player must... ...have a ship targeted ...have a seeking missile weapon deployed Once the above conditions are met the HUD will indicate an acquiring lock symbol which will, over time, move from the centre of the HUD to the onscreen position of the targeted enemy When the acquiring lock symbol is maintained on top of the targeted ship icon for a short time the missile system will acquire a lock and the symbol will change Whilst a lock is acquired the symbol will overlay the target providing the enemy is within the FOV of the player’s ship If the enemy ship ever moves outside the FOV of the player’s ship any missile locks will be lost and will need to be reacquired Players can speed up missile lock by aiming their ship such to bring the acquiring lock symbol on their HUD on top of the intended target faster than if just leaving it to do it automatically Firing a seeking missile with a lock acquired will result in the missile being able to either: Independently track the target and no further action by the player is required (they can break lock without affecting the launched missile) Track the target providing the player maintains a lock throughout the missiles flight path (losing lock will result in the missile maintain its last heading until the lock is reacquired or the missile runs out of fuel) SUBSYSTEM TARGETING To begin the subsystem targeting sequence the player must... ...have a ship targeted ...have a subsystem scanning module installed and/or deployed if necessary The scanning sequence will take time based on the quality of the module and also requires that the target ship to be in the FOV of the player’s ship the entire time (like with missile lock) The target ship will know they’re being scanned unless the player is using specifically stealthy scanning modules If the target ship moves off screen or the lock on is disengaged for whatever reason the scanning will be cancelled Only when a full scan for the required time is made will the enemy subsystems be available to target through the cockpit interface and other appropriate input Once a full scan is completed the player doesn’t need another scan to reacquire the subsystem list if they change targets in the mean time (i.e. the ship remembers the results of the scan on a per target basis) CARGO SCANNING Mechanically identical to subsystem targeting, cargo scanning just requires the specific scanning module to be installed to enable it Subsystem scanners, cargo scanners and bounty scanners can both be installed at the same time and will also run at the same time provided they are both powered and/or deployed if necessary BOUNTY SCANNING Mechanically identical to subsystem targeting, bounty scanning just requires the specific scanning module to be installed to enable it Subsystem scanners, cargo scanners and bounty scanners can both be installed at the same time and will also run at the same time provided they are both powered and/or deployed if necessary DISCUSS!

Sandro Sammarco :

Hello, you lovely backers! Our initial proposal for in-system fast travel raised almost universal concern from the DDF. As developers, we of course make the calls and live with the consequences, but it's fair to say that even in such a small, fanatical (in a good way!) demographic, the response was clear enough to make us step back and take another look at what we were trying to achieve. Well, it turns out that look become a long, unyielding gaze into the abyss of design. Brains were racked until you could use them for pizza base, stones were turned until the insects had nowhere to sleep, and teeth were gnashed until we were forced to drink our dinner. The often conflicting issues of multiplayer and scale made this an extremely thorny issue, requiring compromise between many disciplines, but we pushed through to the other side, and I think we found something pretty darn good along the way. Now it's time let our concept out into the wilds and get some feedback. This is a fairly meaty proposal update, so it's split into two posts. Have a gander, have a think, and let us know. THE FRAME SHIFT DRIVE 1 GLOSSARY 1.1 POWER PLANT A ship’s power plant is an internal module. It consumes fuel and converts it into energy that is used by powered modules when they are turned on. As each powered module is turned on the power draw of the power plant increases, meaning that fuel is consumed at a higher rate. Power plants have maximum draw levels; once reached, the commander will have to turn off powered modules to turn on new ones. 1.2 ENGINES A ship’s engines consist of the following elements: One or more powered, internal modules, that consume fuel and generate thrust The greater the thrust produced the higher the fuel consumption A series of external thrusters that direct the thrust to provide ship movement A ship’s engines allow it to travel at speeds of several hundred metres per second. 1.3 FRAME SHIFT DRIVE A frame shift drive is a powered internal module. Basically a cut-down version of a hyperdrive, it consumes fuel to allow a ship to travel at a significant fraction of the speed of light. 1.4 HYPERDRIVE A hyperdrive is a powered, internal module. It consumes fuel to allow a ship to perform hyperspace jumps, travelling vast distances (light-years) in seconds, and to frame shift. The hyperdrive is the name given to the whole assembly, but essentially a frame shift drive is an intrinsic part of it. 2 MODES OF TRAVEL There are three modes of ship locomotion in Elite: Dangerous, allowing commanders to travel around the galaxy. Both super-cruise and hyperspace travel are inertia-less. Both are closely related, and involve shifting the frame of reference such that distances become very much contracted – essentially distorting space-time in the immediate vicinity to achieve this effect. This means people travelling on such a ship do not feel an acceleration when doing so (though that’s not to say it doesn’t involve jolts and some violent motions so people should be strapped in!): Conventional Travel: Conventional travel allows it to attain speeds in hundred of metres per second. Conventional travel uses a ship’s engines. The following activities are possible: Docking Combat Trading Mining Some methods of exploration Super-Cruise Travel: If fitted with a Frame Shift drive, a ship is able to travel at speeds approaching significant fractions of the speed of light, colloquially known as super-cruise. The Frame Shift Drive is a discrete, powered module. The following activities are possible whilst at super-cruise: Freeform travel between in-system bodies Freeform high speed orbit around in-system bodies Freeform travel to arbitrary in-system locations High-speed pursuit and artificial mass locking of targeted ships Some methods of exploration Hyperspace Travel: If fitted with a Hyperdrive, a ship is capable of near instantaneous travel between gravity wells, either within a system or between systems. These journeys are known as hyperspace jumps. A Hyperdrive is an upgraded Frame Shift Drive. As such, it retains all Frame Shift functionality. The following activities are possible: System-to-system jump In-system jump to in-system body 3 THE FRAME SHIFT DRIVE The Frame Shift Drive (FSD) is a module that has grid, ship class, mass and power requirements like any other module. It allows a space ship to travel at super-cruise: 3.1 INITIATING SUPER-CRUISE When fitted, the FSD allows a ship to engage super-cruise: There is a wind up time when engaging the FSD, with associated visual, audio and sensor effects The FSD cannot be engaged when the ship is within a calculated distance of another vessel or structure that has a large mass– the greater the mass the greater the required distance – conventional flight using engines must be used to clear the distance Modules and consumables exist that can delay/prohibit/cap speed and allow FSD engagement, creating an arms race between those who want to engage super-cruise and those who want to prevent them doing so 3.2 TRACKING AND MATCHMAKING When a ship successfully engages the FSD it is removed from the session and joins a super-cruise session: The act of engaging the FSD leaves a brilliant particle trail that dissipates over time – other vessels which match the position and vector when engaging their own FSD increase their chance of being matched in the same super-cruise session Any players in the session that is left will see the commander having engaged FSD dart off at an incredible speed in their initial super-cruise direction and then disappearing – enabling such a ship to be followed. Targeting a ship which then engages its FSD increases the chance of being matched with the vessel if engaging super-cruise within a window of opportunity Allies can slave their FSD to guarantee that they enter super-cruise in formation at the same time and in the same session When slaving the FSD, all vessels use the capabilities of the weakest drive The vessel that others slave to has flight control during super-cruise, though slaved ships may break off at any point (and re-slave if they are within a set distance) As with all matchmaking, there is no guarantee of being successfully matched with a particular session beyond slaving FSDs 3.3 SUPER-CRUISING Once super-cruising, a commander can employ the following ship systems: They can linearly accelerate up to the ship’s maximum super-cruise speed (though in practice this will almost never be reached) and decelerate down to a standstill (these two rates will most likely be different – it will be easier to come out of super-cruise than enter it), at which point they drop out of super-cruise and into normal space Commanders that drop out of super-cruise far from any gravity well may broadcast their location directly to known ships which can use the data as a hyperspace destination They can manually control the direction of the vessel If outfitted with the correct sensors they can attempt to scan for un-mapped celestial bodies, phenomena and other points of interest using associated sensor interface options They can use long range sensors to track other ships super-cruising nearby If they have the correct modules or consumables they can attempt to mass-lock a targeted ship or nearby ships, dragging them all out of super-cruise into normal space relatively near each other Ships do not automatically mass lock each other out of super-cruise no matter how close they visually get – the process must be commander initiated Ships that have a slaved FSD will be dragged out of super-cruise when they are in proximity to a slaved FSD ship that is mass locked, even if they were not targeted themselves Whilst in super-cruise a ship with a hyperdrive can engage a hyperspace jump to a gravity well within the system (a micro jump) or to the major gravity well of a different system (a hyperspace jump) assuming they have the fuel Whilst travelling in super-cruise, the effects of gravity will be accentuated, so travel is both ‘bumpy’ and any gravity well will distort the player’s direction of travel. 3.4 SUPER-CRUISE EXPERIENCE When travelling at super-cruise the commander pilots the ship using standard controls. They can speed up, slow down, pitch, yaw and roll. However, several aspects of the flight model are significantly reduced in efficiency; pitch, yaw and roll are much slower. Although the ship accelerates and decelerates at incredible speeds, the range of acceleration and deceleration is such that it takes in excess of twelve minutes to reach maximum velocity. This fact combined with reduced manoeuvrability, places a greater emphasis on planning ahead. Because super-cruise relies on the frame shift drive rather than engines, manoeuvrability and acceleration are dependent on the capabilities of the frame shift drive, as well as the ship’s construction; some vessels are inherently better suited to super-cruising than others. When fitting a FSD/hyperdrive module, the various brands and models have different capabilities in terms of cost efficiency speed and resistance to debilitating effects. Travelling at super-cruise distorts space-time around the ship in a manner that effectively contracts distances – though this effectively greatly increases gravitational effects too. If these speeds were achieved in normal space the accelerations of many hundreds of ‘g’ would turn the occupants into jelly. It also alters the visuals from the cockpit significantly, for example other ships travelling at super-cruise are rendered as distorted flaring lights, visible way beyond normal visible range, and other astronomical effects, like magnetic fields become accentuated too, rendering them visible in many cases. Travelling at such speeds causes the ship’s HUD to engage a number of additional elements to help the commander correctly pilot the vessel: All celestial bodies and phenomena within a large distance are enhanced with AR elements, showing distances and collision warnings based on the commander’s speed Other ships travelling at super-cruise within a large distance are also highlighted with AR elements showing distance and direction of travel The commander may target these ships as in normal flight – this is a pre-requisite for some methods of using optional technology fitted to the ship dragging down ships out of super-cruise 3.5 RISKS OF SUPER-CRUISE Super-cruising allows a commander to theoretically fly their ship anywhere in a system under manual control. However, there are risks involved with travelling so quickly: Although ships cannot collide with each other, they can collide with celestial bodies and phenomena Because the FSD frame-shifts at a constant rate it is possible the player is forcibly ejected from super-cruise while still at a high level of frame shift when approaching a celestial body or phenomena. This can be damaging to the ship (and its contents) – in extreme cases resulting in their destruction. Manoeuvrability whilst in super-cruise is significantly less effective than under conventional drive, requiring earlier intervention to avoid collisions Celestial bodies and phenomena are still present regardless of whether a commander’s system map knows about them When travelling directly towards a known celestial body the ship interface will be able to provide collision course warnings Flying close enough to a celestial body, phenomena or point of interest will update the system map, though this will not necessarily leave the commander enough time to react Atmospheric/surface impacts will cause a ship to drop out of super-cruise – potentially causing damage or destruction to it depending on their degree of frame shift at that point. Although the FSD locally distorts space, effectively shrinking distances, it does not affect gravity, so the effect results in apparently massively increased gravitational forces: Gravitational influence from locations is significantly extended in both range and strength, dragging the commander’s vessel off course, but also allowing skilful slingshots around massive bodies. A skilled pilot is able to use gravitational effects to their advantage, skimming around locations to gain additional temporary gains to turning arcs Super-cruise consumes fuel; running out of fuel will cause the FSD to drop back down into conventional space, potentially leaving the vessel stranded Stranded vessels can use their escape pod or begin transmitting a distress signal Some consumable devices can be deployed by vessels and structures that create a “net” capable of dragging super-cruise vessels down to conventional drive speed if they get too close

Sandro Sammarco :

Part the Second (Apologies in advance for low quality designer art!) 4 THE HYPERDRIVE The hyperdrive is a module that has grid, ship class, mass and power requirements like any other module. As well as allowing a ship to travel at super-cruise, a hyperdrive also allows it to make hyperspace jumps (system-to-system) and micro-jumps (between points of interest within a system). Whilst travelling at super-cruise a commander may execute any hyperspace jump or micro-jump they have plotted beforehand. Separate documentation exists covering the hyperdrive, with the following additions: When the commander has plotted either a hyperspace jump or micro-jump destination, it will be present as an AR element in the cockpit interface When using a hyperspace jump to a system, the ship arrives nearby the largest mass present, normally the most dense star A hyperspace jump can only be initiated by a ship already at super-cruise A hyperspace destination can be programmed at any time (the ship does not have to be at super-cruise) Programming of hyperspace destinations can be done by (a) pointing at the destination object and selecting it, (b) using the galactic map and selecting an object, (c) by selecting a destination address that has been stored or sent electronically from another player and (d) by slaving the hyperdrive to another player, flying in formation. 4.1 PLOTTING A MICRO-JUMP The commander can directly select a known location using the cockpit interface, either before or whilst super-cruising : The cockpit interface allows the commander to interrogate and select the destination by directly highlighting the location in the star field Engaging the hyperdrive causes the vessel to micro-jump in a straight line directly to the location, arriving nearby at super-cruise speed The destination point is calculated to be at the centre of location on the edge facing the commander (imagine a snooker cue hitting a cue ball dead centre) There is some amount of arrival point fudging to maximise the chance of matchmaking with commanders already present at the location and nearby Using this method it allows no control over the destination point, but it is the fastest method of quickly reaching a point of interest and does not require use of the orrery system map The commander can use the orrery to plot a more precise micro-jump: In the orrery view the commander can select a location and move a cursor over its face to pick a destination point Much like aiming a snooker cue at the cue ball, the commander cannot select a destination point round the back of the location, only to a point that their ship has a direct line of sight to The arrival point is still subject to some amount of fudging as required by matchmaking The commander can use the system map (orrery view) to plot a multi-stage micro-jump, potentially allowing them to travel to locations and destination points that they do not have direct lines of sight to In the orrery view the commander can select a location and move the destination cursor to the edge of the location’s visible face This triggers a slingshot corridor to be displayed – this is a three dimensional volume that curves and expands around the location The commander can select a new destination point at any location that can be reached whilst staying within the limits of the slingshot corridor A micro-jump can consist of as many slingshots as the vessel has fuel for A micro-jump that contains slingshots is treated as a single journey; the vessel jumps to each slingshot, arriving at super-cruise, realigns for a few seconds then automatically jumps again However, the game checks all slingshot points when the micro-jump is initiated and is able to determine if the ship should be dragged down to conventional drive speed during the alignment stage 4.2 PLOTTED MICRO-JUMP RISKS When a commander plots a micro-jump there is potential for the route to become invalid: Various locations have orbits of different speeds If the commander plots a route to a location with an orbit, the route may eventually become invalid as the location moves out of alignment with the route The system map interface warns of potential miss-alignment issues with a route The ship will not be able to initiate a micro-jump with an invalid route OK, so, there it is. I personally think that our revised proposal is ambitious, exciting and inclusive, offering lots of game play opportunities and really supporting the concept that space is really big as opposed to a set of corridors and boxes. It's also hopefully a real positive result of opening up the design process and getting input from the community. But who cares what I think! Importantly, now, what do you guys and gals make of it? Does this proposal fan the fires of desire or is it too darn complex and unnecessary? Are we making the right call by mixing jumps and cruising or are we messing with balance. Whether it's issues you can see or potential, we'd really like to hear. Engage!

Tom Kewell :

Hi guys, It's Friday again, and we've got that Friday feeling that makes us post proposals! This weeks proposal ties in strongly with the background simulation, and how factions behave and change with regards to it, and what you, the players, can do to change the structure of the Galaxy. Hefty stuff I'm sure you'll agree, but have a careful read and then give us your thoughts. Deep breath, here we go: ELITE DANGEROUS – FACTION CAUSES AND THE BACKGROUND SIM GLOSSARY OF TERMS System – A collection of stars, planets or other astral bodies under a single collective name, e.g. “Lave”, and requiring a hyperspace jump to reach. Faction – An organisation that adheres to a single set of laws and that has a relationship with other factions. Factions can control single systems (such as independent systems) or multiple systems (such as the Federation) System Authority – All inhabited systems are controlled by a faction in the form of a system authority. System Authorities can adopt statuses and causes. System Statistics – Statistics and data about a system authority. System Statuses – Broad stroke conditions that effect a system, e.g. war, poverty, economic boom System Causes – Sets of missions and events with a theme relating to a specific Status. Tick – A variable amount of time that determines when background simulation data is collated, and system statistics are updated. System Assets – These are the various objects, resources, and points of interest in a system. WHO RUNS A SYSTEM? Every inhabited system has a system authority, representing the physical presence of the dominant faction in the system (or representing lack of governance in case where no faction is in control). The system authority has a number of system statistics: Wealth – a rating of the system authority’s capital Between 1 – 1000. 1 represents low average wealth, 1000 represents a high average wealth Standard of Living – a rating of the wellbeing for the population under the care of the system authority Between 1 – 1000. 1 represents a low standard of living in squalid conditions, 1000 represent utopian living standards Development level – a rating of how technologically and materially advanced the system authority is Between 1 – 1000. 1 represents very low development and facilities, 1000 represents the highest development and facilities Security – a rating of the system authority’s military capability Between 1 – 1000. 1 represents low security, with the faction owning few combat capable ships, 1000 represents a highly secure system with a large faction fleet Population – a representation of the number of inhabitants under the care of the system authority Between 1 – 1000. 1 represents severe under-population, 1000 represents severe overcrowding Government Type – a description of the method of governance used by the system authority (some factions specify a government type) None (the system is unpopulated) Anarchy Commune Communism Corporate State Religious Cult Democracy (Independent, Federal, Alliance) Theocracy Dictatorship Feudal Imperial Colony Imperial Protectorate (part of the Imperial interstellar faction) Major Economy Type – the most prevalent type of market controlled by the system authority Agri Industrial Criminal Extraction Military Services System Authority Owned Assets – a list of points of interest under the control of the system authority Non-System Authority owned Assets – a list of points of interest not under the control of the system authority Neighbouring Authorities – a list of nearby system authorities close enough to be deemed “neighbours” and able to affect the system Each entry logs the factional relationship between the two system authorities These system statistics can change based on player activity and statuses (described later). Importantly, they are collated and interrogated every meta-game tick to determine how the system evolves. The faction behind a system authority determines the laws of the system, as well as determining diplomatic status with other factions. Such diplomatic status affects all systems controlled by a faction. The system authority and its associated stats determine the welfare of the system and what things happen in it. WHAT HAPPENS IN A SYSTEM? Each tick, by interrogating system statistics, system authorities are assigned any number of statuses and a single cause. STATUSES Statuses give the player general information about the system authorities’ current system stats in the form of a broad, system-wide condition. Different combinations of stats will lead to different statuses being awarded to a System Authority. For example, in order to receive the ‘Famine’ status, the following conditions must be met: Populations Stat must be 9 or more Standard of Living Stat must be under 3 Agricultural Assets must be fewer than residential assets System authorities can be awarded any number of statuses, as long as their system statistics meet the requisite requirements when the tick occurs. A status can have discrete positive and negative effects: Adds one or more causes to the potential list from which a single cause is chosen each tick Determines a list of statuses that cannot be selected whilst it is in effect Generates stories added to the news feed CAUSES Causes add themed missions and events into the mission/event creator. Causes dictate what the majority of events and missions are that will be available in the system for that tick. They represent a theme associated to a status. For example, the “famine” status might have two associated causes: “exodus” where people are generally attempting to leave the system, and “food drive”, where people are making extra concerted efforts to obtain food supplies. Each tick a cause is chosen at random, with statuses adding weight to their related causes. Missions generated by a cause are in addition to other missions generated by the mission/event generator. RESOLVING STATUSES As players perform actions in the system, and react to the available missions and events, their actions will be recorded and logged. When the tick ends all the aggregated data for all player’s actions in that system are collated, and the system authority’s system statistics are updated accordingly. These updated system statistics are compared against exit thresholds values for active statuses. Each status may have a number of exit thresholds values that could result in different outgoing effects. If the system statistics match a particular set of exit threshold values, the status is removed and any outgoing effects are triggered. OUTGOING EFFECTS Status outgoing effects can have a positive or negative effect on a systems stats and assets. When a status is removed it may trigger outgoing effects: Automatic activation of a particular new status Alteration to system statistics Creation, destruction or alteration of a system asset Alteration to system statistics numerical values Changes to government type Changes to factional relationships NEWS FEEDS AND STATUSES Statuses and causes will determine the contents of a systems news feed. When a status is awarded to a faction, a story pertaining to that status is added to news feed for the system. The Stories headline gives a brief description of the details of the status, with the story itself adding information on locations involved, what kind of events and missions to expect, specific details of the status and give clues to what player actions can affect that status. When a status is resolved at the end of a tick a story should also be added to the news feed, giving players information on what the resolution of the status was as a headline, and details of the effect of the resolution and any changes to the faction’s stats and statuses in the article. The Faction’s Selected Cause should be the main story for that tick, with news stories updated every tick. EXAMPLE NEWS STORY Status: Aware of Mineral Resources. Cause: Secure Mineral Resources [CENTER]Federal Democracy of Sol Plans to Acquire Gold Resources A recent discovery in the Sol system (add ‘By <Player Name>’ if player was involved in discovery) has urged the Federal government to move to secure the Gold rich asteroid field at <Asset Location> for official government use. If successful they will put an end to the unofficial mining operations that have been taking advantage of the mining opportunities, and secure the resources for the Federation. In a statement, <NPC Government Spokesman> said, “We will be sending security forces to the area to ensure the area is safe while our construction crews begin work on creating mining facilities in the area. We’d like to ask any pilots in the area to co-operate with federal forces in their efforts to secure the area, and report any illegal mining operations to security forces.”. Several prominent pilots have spoken out against the Federations claim, saying that the resources should be free for private organisations to mine. Some extremists have threatened to attack federation forces in order to hinder the construction of mining facilities. Others are taking the opportunity to mine as much of the precious resource as they can before the federal clampdown takes place. With mining equipment readily available from a number of ship yards around earth, the Federal government must be expecting something of a gold rush.[/CENTER] EXAMPLE STATUS Status: Economic Boom A large amount of wealth distributed among a relatively smaller population leads to economic booms. Expect events and missions relating to trading, with players offered special prices and opportunities to acquire rare goods and services cheaply. Required Stats: Wealth >700 Population: <800 Associated Causes: Construct new Trading Post, Buy <Trade Good>, build trading ships, build navy ships, subsidise trade Resolution 1: The bubble bursts Required Stats: Wealth <800 Population >800 Effects: -250 to wealth, -100 to population Resolution 2: The Boom Continues Required Stats: Wealth >800 Population >900 Effects: +100 to wealth, +100 to population, Economic Boom status injected to next tick Economic boom increases a systems wealth and population. Players can help to prolong the economic boom, and will get missions and events that allow them to purchase things cheaply or sell for a high profit margin while it is active. When the bubble eventually bursts the systems wealth is greatly lowered, and the status is removed. Notes and Issues So, it's a complex system, apologies if it's a bit confusing. It should mean that systems are constantly changing and evolving. As statuses are acquired and resolved they should alter systems stats and create a narrative for systems as they change over time. Players should be able to perform actions in systems and have significant changes in a system. Players should be able to look at the statuses a system has and, with a little player knowledge, perform actions that promote the result they want. We need a good selection of statuses that System Authorities can get, with end conditions and associated causes. If you guys can suggest any ideas you have on those lines that would be a great help. If you have a good idea of what the stats would be associated with your example then all the better, but if not post it anyway, we can figure them out later. This attachment is a flow diagram of how stats, statuses, causes and player actions are processed. //Здесь был аттач - но он совершенно нечитабелен. Подождем пока появится более читабельный вариант. Thanks for reading, really looking forward to your feedback!

Tom Kewell :

DOCKING AT SPACE STATIONS IN ELITE: DANGEROUS Docking in Elite has a number of stages to it. This Proposal describes the docking process through each stage, from the player flying outside a station, to entering the station, to successfully docking on a pad at the station. 1.1 REQUESTING DOCKING Player Aim: To Communicate with their target station and gain permission to dock The player must Select the station as a target and must open communications The player can only communicate with a station if the station is in range of their communication equipment The player selects the ‘request permission to dock’ option from the communication menu, to request permission to dock at the station If the player is too far from the station they will be denied permission, and told to close to within 1.5km of the station and request permission again If the player is currently wanted for crimes against a faction the station is affiliated with the station will refuse to give them permission to dock Below a certain threshold a station may allow a player to dock The player may have the option to communicate that they are turning themselves in, in which case they will be given permission to dock Police may be dispatched to the player’s location if they’re wanted for serious crimes If the Player’s weapon bays are open they will be informed to close them before approaching the station The player is directed to fly to the stations entrance and informed to wait for clearance before approaching the entrance The player is given a waypoint outside the station to fly to (this is the holding area for entering the station) Once the player reaches this waypoint they are added to the queue of ships waiting to dock at the station 1.2 ENTERING A STATION Player Aim: Flying through the space station’s aperture to the stations interior When a player is given clearance they are communicated with and informed they have a short window to pass through the stations entrance Player ships are always given priority over AI ship in the waiting list Players can pay for premium docking rights with some stations to get priority docking Entering a station when not given clearance causes the player to receive a fine When the players window is open the station will open its docking bay doors to allow the player access to the stations interior The player must fly their ship through the stations aperture and into the station 1.3 INSIDE THE STATION AND LANDING ON A PAD Player Aim: Navigate the Stations interior and Land on a Landing Pad When the player is inside the station they will be told which pad they have been assigned to dock on The player will be given a waypoint marker in their hud that guides them to the area above their designated pad Once above the designated pad the player must activate their landing gear to enable the docking GUI On their main screen the player will be shown GUI showing the horizon, according to the landing pad, and the players height above the landing pad This allows players to quickly level their ship to the same orientation as the pad, and easily check their height and orientation at a glance On a secondary screen the player is shown a downward facing camera, showing the docking pad below This camera has an AR overlay that tracks the landing Pad below the player The player must keep the pad lined up below their ship and slowly decend onto it A marker on the front of the landing pad (perhaps a set of marking lights or an advertising billboard) shows the player when they are lined up with the landed pad at the correct height Once the player has aligned their ship to the landing pad they press a button to trigger magnetizing the pad If the player has aligned their ship correctly they will land safely If the player is too high off the landing pad the magnetization effect will cause the ship to hit the pad hard and will damage the player’s ships landing gear If the player does not trigger the magnetization soon enough their ship will graze the landing pad and damage the players ship The Players ship is now docked 1.4 LEAVING A STATION Player Aim: Request Permission to launch and Exit a Space Station From the landing pad the player selects ‘request permission to launch’ o If the player has remaining fines or charges to pay they will not be given permission to launch without paying them The players pad will de-magnetize and the player’s ship can now be powered up and flown The player must fly to a holding point near the stations exit Once the player’s ship reaches the holding area it is added to the list of ships waiting to leave Leaving ships are given priority over ship trying to enter the station The player is informed when they have clearance to leave The Station’s aperture will open to allow the player to leave If the player fails to use their window they are moved to the bottom of the queue to leave Once the player has flown out of the station the player has successfully un-docked 1.5 OTHER DOCKING CONDITIONS Some stations may have other rules and conditions that the player may have to adhere to in order to be allowed to dock. These may include: Speed limits For a set radius around a space station the player must adhere to a set speed limit Being observed breaking the speed limit can incur a fine from the stations’ faction The player’s throttle will limit itself to the speed limit, although the player can overrule the limiter and speed if they want to Scan before Access The player must submit themselves to a scan before being granted access to the station Toll The player must pay a fee in order to be allowed access to a station 1.6 DOCKING FOR FUEL Some stations may have exterior points where players can dock to refuel. Where this is possible, the player must follow the following procedure. The player must Select the station as a target and must open communications The player can only communicate with a station if the station is in range of their communication equipment The player selects the ‘request permission to refuel’ option from the communication menu, to request permission to dock at the station’s refueling point o If the player is too far from the station they will be denied permission, and told to close to within 1.5km of the station and request permission again o If the player is currently wanted for crimes against a faction the station is affiliated with the station will refuse to give them permission to dock Below a certain threshold a station may allow a player to dock The player may have the option to communicate that they are turning themselves in, in which case they will be given permission to dock Police may be dispatched to the player’s location if they’re wanted for serious crimes If the Player’s weapon bays are open they will be informed to close them before approaching the station The player is directed to fly to a point near the stations entrance and informed to wait for clearance before approaching When the player arrives at the waiting point they are added to the queue for refueling When the refueling point if free the player will be set a waypoint to dock with the refueling point The player must approach the point and stop in the correct place to trigger the docking process From this point the player can refill their fuel tank and purchase a limited range of fuels Once done the player must select the launch option from the refueling point o The player’s ship will then detach from the refueling point and the player will be free to fly away Notes and Issues This docking procedure should be useful in a number of docking procedures, including ship to ship docking (with the point of contact being a way point between the two ships) Where possible we want to include systems where player skill allows a good pilot to get docked quicker, or avoid penalties, but not create situations where a less skilled player is unable to dock. Any ideas on where we can expand this approach would be appreciated. What level of automation would players like to see from a module such as a docking computer. Should we have docking request automation on a communications computer, but the actual flight control of landing on the docking computer? Should I have to fly inside a station manually before I can activate the docking computer? Your opinions would be appreciated. Thanks for reading!

Tom Kewell :

Hello Backers. There's been a number of requests for a seperate place to list your example statuses, based on the [URL="http://forums.frontier.co.uk/showthread.php?t=8021"]linked Factions and Causes[/URL] Thread. I still think there's plenty of discussion to be had with the mechanics of statuses, and I'd like that to continue in the factions and causes thread. This thread should be used to give example statuses. As a reminder, Statuses are awarded to a system when a systems stats meet the required conditions. These stats include Population, Wealth, Development Level, Standard of Living, and security. Government type, Economy type and any assets in a system (like space stations, factories, habitable planets etc.) are also statistics. If a system has the required statistics it is awarded a status. A status can have discrete positive and negative effects: Adds one or more causes to the potential list from which a single cause is chosen each tick Determines a list of statuses that cannot be selected whilst it is in effect Generates stories added to the news feed Statuses help determine which causes are available to a system for a galactic tick. Causes determine what missions and events will occur in a system for that tick, and give the players opportunities to perform player actions. Player actions are recorded and will change a systems stats. Statuses will remain attached to a system until the systems stats match one of their resolutions. When a resolution is triggered it can: Automatic activation of a particular new status Alteration to system statistics Creation, destruction or alteration of a system asset Alteration to system statistics numerical values Changes to government type Changes to factional relationships We'd like you to use this thread to post your examples. Remember that statuses should be quite broad in their subject, and can resolutions can feed into new statuses, creating a narrative chain of statuses. Example Statuses The following are examples of statuses from the mechanics thread that we though make for good examples. If you don't have exact statistic numbers for your example please feel free to post it anyway, we'll figure out the set up for it if it's a compelling idea. Status: Scientific Breakthroughs Scientists in this system are having a golden age of discovery. With strong government funding and specially built scientific equipment, this faction could be on the edge of a scientific breakthrough. Required Stats Wealth >700 Development Level >600 Population <900 Scientific research station Government Type: Not Anarchy Resolutions Cure Diseases Requires: Population >800 Wealth >800 Development Level >500 Result: Standard of Living +200, Population +100, Wealth -100 Improve Weapons Requires: Wealth >800 Security >700 Result: Security +200, Wealth -100, Add 'Expanding Navy' Status Terrorists Attack on the Research Station Requires: Security <400 Result: Security -100 Standard of Living -100 Destroy Scientific Research Station Add Terrorism status Status: Nuclear Meltdown At least one of the System Authorities settlements is suffering from a nuclear meltdown, either from a generator or an attack. Required Stats Development level 600 Security <400 Scientific research station Resolutions Evacuate Survivors Requires: Wealth >700 Population >600 Result: Standard of Living -100 Population -100 Development Level -100 Nuclear Clean up Requires: Wealth >900 Development Level >900 Result: Standard of Living -100, Wealth -100, Evacuation Sabotaged Requires: Security <400 Result: Security -200 Standard of Living -200 Destroy of affected colonies Please add your examples to this thread. Any discussion of the systems mechanics should be in the other thread. Thanks!

Как напоминали, статусами награждаются системы, когда их статистические данные соответсвуют требуемым условиям. Статистические данные включают "Population" (население), "Wealth" (богатство), "Development Level" (технический уровень), "Standard of Living" (уровень жизни), и "security" (уровень безопасности). Тип правительства, экономики и любые
активы в системе(например станции, заводы, обитаемые планеты и т.д.)

Если система соответствует требованиям, ей присваивается статус, который может иметь дискретные положительные и отрицательные эффекты:

• Добавляется одна или несколько причин в список потенциальных из которого каждый тактовый период выбирается 1
  
• Определяет список статусов, которые не могут быть выбраны пока они действуют
  
• Генерируются статьи, добавляемые в ленты новостей
  

Статусы помогают определить, какие причины доступны для системы за время тактовый период галактики. Причины определяют какие миссии и события будут происходить в системе за этот тактовый период, и дают игрокам возможность совершать "действия игрока". Действия игрока записываются и влияют на статистику системы.

Статусы будут прикреплены к системе до тех пор, пока её статистические данные не совпадут с условиями одного из "способов решений кризиса".Когда решение определено, оно может:

• Автоматическое включение определённого нового статуса
  
• Изменение статистических данных системы
  
  • Создание,разрушение или изменение активов системы
    
  • Изменение цифровых статистических данных системы
    
  • Изменения в способе управления системы (тип правительства)
    
  • Изменения в отношениях между фракциями

Мы хотели бы использовать эту тему для примеров. Помните, что статусы должны быть достаточно широки по своим субъектам(хм..), и иметь в своих решениях пищу для новых статусов, создавая цепь повествования.

Примеры статусов
Представленные ниже статусы из темы "Игровая механика" (сам придумал%)) мы посчитали хорошими примерами. Если у вас нет точных цифр статистики для вашего примера, пожалуйста разместите его где угодно. Если это будет стоящей идеей, мы подумаем над настройками.

Статус: Научные прорывы
Учёные в данной системе вошли в золотой век исследований. Имея сильную финансовую поддержку государством и специально созданные научное оборудование, эта фракция может быть на пороге научного прорыва.
Необходимые статистические данные
Wealth >700
Development Level >600
Population <900
Научно-исследовательская станция
Тип правительства: Не Анархия

Решения
Лечение болезней
Требования:
Population >800
Wealth >800
Development Level >500
Результат:
Standard of Living +200, Population +100, Wealth -100

Усовершенствование оружия
Требования:
Wealth >800
Security >700
Результат:
Security +200,
Wealth -100,
Добавляет статус 'Расширение военного флота'

Террористические атаки на исследовательскую станцию
Требования:
Security <400
Результат:
Security -100
Standard of Living -100
Уничтожение научно-исследовательской станции
Добавляет статус "Терроризм"

Статус: Ядерный кризис(хм...)
Власти по крайней мере одного из поселений в системе страдают от ядерного кризиса, вызванного генератором (энергоблоком) или атакой.
Условия
Development level 600
Security <400
Научно-исследовательская станция

Решения
Эвакуация выживших
Требования:
Wealth >700
Population >600
Результат:
Standard of Living -100
Population -100
Development Level -100

Дезактивация заражённых территорий
Требования:
Wealth >900
Development Level >900
Результат:
Standard of Living -100,
Wealth -100,


Эвакуация саботирована
Требования:
Security <400
Результат:
Security -200
Standard of Living -200
Уничтожение пострадавших колоний

блаблабла) Просьба добавлять свои примеры статусов и обсуждать их в другой теме.

It's Friday again, and we've got that Friday feeling that makes us post proposals!

Предложение этой недели жёстко связано с фоновой симуляцией и тем, как фракциям вести себя и изменяться по отношению к этому. А так же что можете сделать вы, игроки, для изменения структуры галактики.

Думаю, вы согласитесь, что это огромный массив информации, заслуживающий тщательного изучения и последующего обсуждения. Глубокий вдох, и начнём.



ГЛОССАРИЙ
System – Звёздная Система - Совокупность звёзд, планет и других астрономических тел под одним коллективным именем, например "Lave", и требующая гиперпрыжка для достижения как цели путешествия.
Faction – Фракция - Организация которая придерживается одного набора законов и имеет отношения с другими фракциями. Фракция может контролировать одну систему (как независимые миры) или несколько систем (как Федерация или Империя)
System Authority – Правительство системы - Все населённые системы управляются своей фракцией посредством правительства системы. Власти в системе могут принимать статусы и цели(не знаю как перевести causes в данном контексте, может "мотив" правильнее).
System Statistics – Статистические данные и данные о провительстве системы.
System Statuses – Статусы системы - Крупномасштабные условия, которые влияют на систему. Например война, бедность, экономический бум и т.д.
System Causes – Мотивы (хм...)системы - Набор миссий и событий, касающиеся конкретного статуса.
Tick – Назовём это тактовым периодом или интервалом перерасчёта (период квантования времени в масштабах галактики если есть идеи как это назвать удачней - делитесь) - Некоторое количество времени, которое определяет, когда данные фонового симулирования сопоставляются, и статистические данные системы обновляются.
System Assets – Активы системы - Это различные объекты, ресурсы и точки интереса в системе.

КТО УПРАВЛЯЕТ СИСТЕМОЙ?
Каждая населенная система имеет систему власти, представленную физическим присутствием доминирующей фракции в системе (или выраженной отсутствием управления в случае, когда ни одна из фракций не у руля). Правительство системы имеет ряд статистических данных системы:

• Wealth – Богатство/Благополучие - рейтинг капитала правительства системы
  
  • Принимает значения 1 – 1000. 1 соответствует богатству ниже среднего, 1000 выше среднего
  
  
• Standard of Living – Уровень жизни - рейтинг благополучия населения системы под присмотром правительства
  
  • Принимает значения 1 – 1000. 1 - низкий уровень жизни в ужасных условиях, 1000 - утопия
  
  
• Development level – Технический уровень - рейтинг технологического и материального развития системы
  
  • Принимает значения 1 – 1000. 1 - очень низкий уровень техники и низкое количество заводов, 1000 наиболее продвинутые технологии и производства
  
  
• Security – Безопасность (возможно даже защищённость?) - рейтинг военного потенциала властей системы
  
  • Принимает значения 1 – 1000. 1 всего несколько боеспособных кораблей, соответственно низкая безопасность, 1000 отлично защищённая система с большим флотом фракции
  
  
• Population – Население - число жителей под властью правительства системы
  
  • Принимает значения 1 – 1000. 1 очень низкая плотность населения, 1000 перенаселённая система
  
  
• Government Type – Тип правительства - описание методов управления, используемых правительством системы (некоторые фракции имеют специфические типы управления)(не знаю, надо ли переводить)
  
  • None - Отсутствует (система не заселена)
    
  • Anarchy - Анархия мать порядка
    
  • Commune - Коммуна
    
  • Communism - Коммунизм
    
  • Corporate State - Корпоративное управление (Под управлением корпорации)
    
  • Religious Cult - Религиозный культ
    
  • Democracy (Independent, Federal, Alliance) - Демократия разного разлива
    
  • Theocracy - Теократия
    
  • Dictatorship - Диктатура
    
  • Feudal - Феодальное общество
    
  • Imperial Colony - Имперская колония
    
  • Imperial Protectorate - Имперский протекторат (часть Империи)
  
  
• Major Economy Type - Основные типы экономики – преобладающий тип рынка, контролируемый правительством системы
  
  • Agri - Сельскохозяйственный
    
  • Industrial - Индустиальный
    
  • Criminal - Криминальный
    
  • Extraction - Добыча полезных ископаемых
    
  • Military - Военный
    
  • Services - Рынок услуг
  
  
• System Authority Owned Assets - Активы в собственности правительства системы – список точек интереса под контролем властей системы
  
• Non-System Authority owned Assets - Активы, не принадлежащие правительству системы – список точек интереса не под контролем властей системы
  
• Neighbouring Authorities - Соседние правительства – список правительств систем расположенных достаточно близко, чтобы считаться "соседями" и оказывать влияние
  
  • Каждая запись(хм...) фиксирует фракциональные взаимоотношения между двумя правительствами систем

Эти статистические данные системы могут изменяться опираясь на активность игроков и статусы (описанные ниже). Важно отметить, что они сопоставляются и опрашиваются каждый тактовый период мата-игры, чтобы определить, как система развивается.

Фракция стоящая за правительством системы определяет законы системы, а также дипломатический статус с другими фракциями. Дипломатический статус влияет на все системы под контролем фракции.

Правительство системы и связанные с ним статистические данные определяют благосостояние системы и какие вещи происходят в ней.


ЧТО ПРОИСХОДИТ В СИСТЕМЕ?

Каждый расчётный период путём опроса статистических данных системы, правительство может выставить любое количество статусов и один "мотив".

Статусы
Статусы дают игроку общую информацию о текущей системе и о условиях в ней.
Различные сочетания статистических данных будут вызывать установку правительством различных статусов.Например, для того чтобы получить статус "Голод", должны быть выполнены следующие условия

• Populations - должно быть 9 или больше
  
• Standard of Living - должно быть меньше 3
  
• Сельскохозяйственных активов должно быть меньше чем жилых активов

Власти могут добавить любое количество статусов, каким удовлетворяют статистические данные системы в конце расчётного периода. Статусы имеют дискретные положительные и отрицательные эффекты:

• Добавляется одна или несколько причин в список потенциальных из которого каждый тактовый период выбирается 1
  
• Определяет список статусов, которые не могут быть выбраны пока они действуют
  
• Генерируются статьи, добавляемые в ленты новостей

МОТИВЫ
Мотивы добавляют тематические миссии и события в генератор событий/миссий игры. Мотивы диктуют основное направление доступных в системе событий и миссий за данный расчётный период, и связаны со статусом. Например, статус "Голод" создаёт 2 мотива, связанных с ним: "исход" - люди пытаются покинуть систему; "поставки еды" - когда люди прилагают дополнительные согласованные усилия для получения продовольствия.

В начале расчётного периода мотив выбирается случайно. Статусы добавляют вес связанным с ними мотивам.
Миссии, генерирующиеся исходя из мотивов, добавляются к остальным миссиям созданным генератором миссий/событий.

РЕШЕНИЯ ДЛЯ СТАТУСОВ

Все действия игроков в системе их реакции на доступные миссии и события будут будут записываться и регистрироваться.

В конце расчётного периода собираются все сводные данные о действиях игрока в этой системе, и соответствующим образом обновляются статистические данные системы и её правительства.

Эти обновлённые значения статистических данных сравниваются с порогами различных выходов для активных статусов. Каждый статус может иметь несколько пороговых комбинаций, которые приведут к различным последствиям. Если статистические данные системы соответсвуют конкретному набору значений для выхода (s]решения[/s], статус удаляется и устанавливаются соответствующие последствия данного решения.

ПОСЛЕДСТВИЯ
Последствия статусов могут иметь как положительные, так и отрицательные эффекты на статистику системы и её активы.
Когда статус удаляется, он может включить последствия:

• Автоматическая активация нового статуса
  
• Изменения с статистике системы
  
  • Создание, разрушение или изменение активов системы
    
  • Изменения в цифровых статистических данных системы
    
  • Изменение системы управления
    
  • Изменение взаимоотношений фракций

ЛЕНТЫ НОВОСТЕЙ И СТАТУСОВ
Статусы и мотивы будут определять содержание ленты новостей системы.

Когда статус добавляется к фракции, в ленту новостей добавляется соответствующая статья.

Заголовок статьи содержит краткое описание статуса, а сама статья добавляет информацию о местах проведения, миссиях и событиях, которые стоит ожидать, специфических деталях статуса.Также статья даёт ключ к тому, как игрок сможет повлиять на ситуацию.

Когда в конце расчётного периода ситуация разрешится, новая статья заголовком даст игрокам информацию о том, каким образом статус был решён. Детали последствий и любые изменения в статистике фракции и её новых статусах будут описаны в самой статье.

Мотив, выбранный фракцией должен стать главной темой в данном расчётном периоде и иметь продолжение в последующих.

Пример новой статьи //;это переводить что-то не хочется - в игре таких штамповок увидим тысячи...
Status: Aware of Mineral Resources. Cause: Secure Mineral Resources
[CENTER]Federal Democracy of Sol Plans to Acquire Gold Resources
A recent discovery in the Sol system (add ‘By <Player Name>’ if player was involved in discovery) has urged the Federal government to move to secure the Gold rich asteroid field at <Asset Location> for official government use. If successful they will put an end to the unofficial mining operations that have been taking advantage of the mining opportunities, and secure the resources for the Federation.
In a statement, <NPC Government Spokesman> said, “We will be sending security forces to the area to ensure the area is safe while our construction crews begin work on creating mining facilities in the area. We’d like to ask any pilots in the area to co-operate with federal forces in their efforts to secure the area, and report any illegal mining operations to security forces.”.
Several prominent pilots have spoken out against the Federations claim, saying that the resources should be free for private organisations to mine. Some extremists have threatened to attack federation forces in order to hinder the construction of mining facilities. Others are taking the opportunity to mine as much of the precious resource as they can before the federal clampdown takes place. With mining equipment readily available from a number of ship yards around earth, the Federal government must be expecting something of a gold rush.[/CENTER]

ПРИМЕР СТАТУСА
Status: Экономический бум
Большие капиталы распределённые среди относительно малого населения приводят к экономическому буму. Кроме событий и миссий связанных с торговлей, игрокам будет представлена возможность купить редкие и товары и услуги по специальным низким ценам.

Требования: Wealth >700
Population: <800
Связанные мотивы: Постройка нового торгового поста, Покупка <Наименование товара>, производство торговых кораблей, производство военных кораблей, субсидирование торговли

Решение 1: Пузырь лопнул
Required Stats: Wealth <800
Population >800
Effects: -250 to wealth, -100 to population

Решение 2: Бум продолжается
Required Stats: Wealth >800
Population >900
Effects: +100 to wealth, +100 to population, Статус "Экономический бум" устанавливается на следующий расчётный период.

Экономический бум увеличивает богатство системы и её население. Игроки могут помочь продлить экономический бум и брать задания и события, которые позволят им покупать дешёвые товары, или наоборот продавать с высокой прибылью. Это будет продолжаться пока пузырь не лопнет, серьёзно уменьшив богатство системы.

Notes and Issues

Таким образом, это сложная система. Примите мои извенения если немного запутано. Это должно означать, что системы постоянно меняются и развиваются. Каким образом статусы приобретаются и решаются должно изменять статистику системы и создавать повествование (историю?) для системы, как она со временем развивается.

Игроки должны иметь возможность совершать действия и видеть их результат в виде значительных изменений в системе. Игроки должны быть в состоянии посмотреть статусы системы, и проводить действия, которые приведут к требуемому им результату (правда немного знаний и опыта таких действий игроку не помешает).

Нам нужен хороший выбор статусов, которые правительство системы сможет установить, к которым нужны связанные с ними мотивы и конечные условия. Если вы, ребята(хе-хе, посоны), можете подсказать идеи, это было бы большим подспорьем. Если у вас есть хорошая идея о том какие статистические данные должны быть связаны с вашим примером, то это будет замечательно. Но если если вы их не озвучите, мы сможем подумать над ними позже.

This attachment is a flow diagram of how stats, statuses, causes and player actions are processed.
//Здесь был аттач - но он совершенно нечитабелен. Подождем пока появится более читабельный вариант.


Thanks for reading, really looking forward to your feedback!