diff --git a/.gitignore b/.gitignore index f8892fd..9756264 100644 --- a/.gitignore +++ b/.gitignore @@ -1,6 +1,4 @@ -trac -output -_book -node_modules +venv +site *.orig diff --git a/README.md b/README.md index 1da1773..67fa908 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,29 @@ -Build the Design Document using GitBook: -``` -npm install gitbook-cli -g -gitbook build -``` +# Contributing + +Contributing to the Design Document is possible for everyone, and is in many +ways similar to contributing to the game. We want the contributions to be +easy to perform and easy to review. In the future, we will look for a person +able to manage the evolution of this document, and the quality of contributions +and interactions with the reviewers will be a decisive factor in the choice +of the person. + +Contributing is done by submitting a pull request to the DD repository. +NB: Update this part when this becomes official, in order to use the correct +vocabulary for the Phabricator workflow etc. + +Small contributions, for fixing typos or style, will be accepted. Copy-pasting +from a former version of the document or from other sources (see +[Links and References](book/links.md)) will be accepted if a link to the source is +provided in the commit message. + +Bigger contributions, like proposals of a new feature, will be reviewed if +they come with a proof-of-concept that allows us to test the proposal. It can +be a patch, a mod, an edited image, etc. The proof-of-concept does not need +to be committable to the game source repository, it only needs to display +accurately the feature proposal. Please be aware that those contributions will +be more difficult to review and might need lengthy discussions and refinements. + +# Building the DD +Build the Design Document using MkDocs: +- Install the tool with `pip install mkdocs` in a virtualenv or globally. +- Build the DD with `mkdocs build` diff --git a/book.json b/book.json deleted file mode 100644 index 0f0aa95..0000000 --- a/book.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "root": "book/", - "title": "0 A.D. Design Document", - "author": "Wildfire Games", - "plugins": [ - "-sharing", - "alerts", - "creativecommons"] -} diff --git a/book/CONTRIBUTING.md b/book/CONTRIBUTING.md deleted file mode 100644 index 2719be3..0000000 --- a/book/CONTRIBUTING.md +++ /dev/null @@ -1,25 +0,0 @@ -Contributing -============ - -Contributing to the Design Document is possible for everyone, and is in many -ways similar to contributing to the game. We want the contributions to be -easy to perform and easy to review. In the future, we will look for a person -able to manage the evolution of this document, and the quality of contributions -and interactions with the reviewers will be a decisive factor in the choice -of the person. - -Contributing is done by submitting a pull request to the DD repository. -NB: Update this part when this becomes official, in order to use the correct -vocabulary for the Phabricator workflow etc. - -Small contributions, for fixing typos or style, will be accepted. Copy-pasting -from a former version of the document or from other sources (see -[Links and References](LINKS.md)) will be accepted if a link to the source is -provided in the commit message. - -Bigger contributions, like proposals of a new feature, will be reviewed if -they come with a proof-of-concept that allows us to test the proposal. It can -be a patch, a mod, an edited image, etc. The proof-of-concept does not need -to be committable to the game source repository, it only needs to display -accurately the feature proposal. Please be aware that those contributions will -be more difficult to review and might need lengthy discussions and refinements. diff --git a/book/LINKS.md b/book/LINKS.md deleted file mode 100644 index e60d891..0000000 --- a/book/LINKS.md +++ /dev/null @@ -1,15 +0,0 @@ -Links and References -==================== - -This Design Document is still a work in progress and is based on several -iterations of the text, as well as scattered information across our -development forums, wiki, etc. - -Here is a collection of a few references that might be useful for the -contributor or the reader who is curious about the origins of the document. - -* Our Trac wiki: https://trac.wildfiregames.com - * [Previous version of the DD](https://trac.wildfiregames.com/wiki/Design_Document) - * [Attempt at an update](https://trac.wildfiregames.com/wiki/DDv3WIP) - * [Exhaustive list of all pages of the wiki](https://trac.wildfiregames.com/wiki/TitleIndex) -* Our forums: https://wildfiregames.com/forum diff --git a/book/README.md b/book/README.md deleted file mode 100644 index 8535105..0000000 --- a/book/README.md +++ /dev/null @@ -1,8 +0,0 @@ -# 0 A.D. Design Document - -## Licensing and Disclaimer - -{% creativecommons type="by-sa" %} -{% endcreativecommons %} - -The info contained in this Design Document is provided as-is. It represents the current plan for 0 A.D. but the final game might not be exactly as described here due to for example issues found when balancing the game or features cut to make it possible to release the game in a reasonable time. diff --git a/book/SUMMARY.md b/book/SUMMARY.md deleted file mode 100644 index 57d0199..0000000 --- a/book/SUMMARY.md +++ /dev/null @@ -1,35 +0,0 @@ -# Summary - -* [0 A.D. Design Document](README.md) - -* [Links and References](LINKS.md) - -* [Contributing](CONTRIBUTING.md) - -* [Gameplay Design](gameplay/README.md) - * Main concepts - * [0 A.D. - The Vision](gameplay/main/vision.md) - * [War Story](gameplay/main/war-story.md) - * [Territories](gameplay/main/territories.md) - * [Capturing](gameplay/main/capturing.md) - * [Formations](gameplay/main/formations.md) - * Elements - * [Maps](gameplay/elements/maps.md) - * [Structures](gameplay/elements/structures.md) - * [Entities](gameplay/elements/entities.md) - * Civilizations - * [Athenians](gameplay/civs/athenians.md) - * [Britons](gameplay/civs/britons.md) - * [Carthaginians](gameplay/civs/carthaginians.md) - * [Gauls](gameplay/civs/gauls.md) - * [Iberians](gameplay/civs/iberians.md) - * [Macedonians](gameplay/civs/macedonians.md) - * [Mauryans](gameplay/civs/mauryans.md) - * [Persians](gameplay/civs/persians.md) - * [Ptolemies](gameplay/civs/ptolemies.md) - * [Romans](gameplay/civs/romans.md) - * [Seleucids](gameplay/civs/seleucids.md) - * [Spartans](gameplay/civs/spartans.md) -* [Technical Design](technical/README.md) - * [General settings](technical/settings.md) - * [Game settings and setup](part2/gamesetup.md) diff --git a/book/gameplay/main/formations.md b/book/gameplay/main/formations.md index efb7ec2..43ae278 100644 --- a/book/gameplay/main/formations.md +++ b/book/gameplay/main/formations.md @@ -1,489 +1,489 @@ Formations ========== -> **[danger] Implementation status** -> -> This page is a work in progress. Assume that nothing described here is -> finalised yet and everything could work completely different in the end. +!!! warning + + This page is a work in progress. Assume that nothing described here is + finalised yet and everything could work completely different in the end. # Current state and Goal Fighting in 0 A.D. should be diverse, interesting and challenging. Good tactics should make it possible for a player with a smaller and weaker army to win against a stronger opponent. There should be multiple gameplay mechanics that enable the players to use a variety of tactics and to counter tactics of their opponents. Formations are a core element of battles, but there's currently just a placeholder implementation which does not have a real impact on how battles work in the game. # Battalions vs Single units Currently, all units in 0 A.D. are controlled individually. A battalion is a new concept where units can only be selected and moved as a group. Battalions can be put into a formation. ## Training ### Approach A: Single units only All units can be trained, selected and ordered individually. For fighting, you usually use a formation because that brings many tactical advantages and bonuses. This has some advantages compared to battalions: - Garrisoning still works as designed. It would have to be redesigned for the battalion approach because the number of units in a battalion would exceed the room in some buildings. - The battalion system would cause some inconsistencies that don't occur here because it was designed that way from the beginning. A few examples: * How would it work with female citizens in a battalion-only system? Are they also built in batches and how many units would be in such a batch? * How do you show which units are part of the same battalion? While collecting resources, the individual units could get separated a lot.  * When defining the size of a battalion, do we really want to depend on the economic factors too in addition to the military ones? For example, we would like a large battalion to make the formations work, be we want a small one for economic reasons.  * How much space for units is there around the different resource types (mines, forests, hunting, berries, fields etc.)? * We could still support mixing of different unit types in a formation if we want that. On top of that, most of the disadvantages can be mitigated: * The town bell takes away micro-management for garrisoning units and sending them back to work. * There could be a shortcut and/or a button to select only wounded units * Fighting happens in formations mostly, so the problem is solved on that part ### Approach B: Battalions only Units are trained in battalions already and they can't be separated. With a population cap of 300, it becomes quite a task to manage all the units individually. Such management tasks include: - Splitting units to collect different resources - Healing units or filtering out the insured units - Garrisoning units when the base gets attacked and sending the back to work afterwards Training all units in battalions reduces the tedious micro-management tasks and gives the player more time to do fun things. ### Decision Approach A will be used. It seems like Approach B only looks good in the beginning, but there are too many inconsistencies with how the game is designed and it would require too much changes for only little benefit. ## Fighting If we support fighting in formation as well as fighting as individual units, both need to be valid choices under some circumstances. ### Fighting as individual units * Garrisoning * Raiding. A single formation is not mobile enough to run after individual units. * Battles with few units. If all units are grouped into one or two battalions, it's hard for them to attack a scattered group of your units. If you have ranged units, you can keep attacking them while they try to catch all units one by one, wasting a lot of time. This tactic doesn't work well if the enemy has ranged units too. However, having just two battalions with one ranged and one melee, it's very hard to protect the ranged units. They can only be protected from one side at any given time. This is another case where you get an advantage by disbanding the battalion. ### Fighting with formations * Basically all battles between larger armies. # Number of units in formations * There is a minimum number of 6 units for a battalion. * There is a minimum number of units depending on the formation type. This is usually higher than the minimum battalion size. * There is a maximum number of units for each formation. * You get the same formation bonus irrespective of the formation size. * Morale: The panic-effect on other battalions is smaller for smaller battalions * Morale: You need to kill the same percentage of units in the same amount of time for all sizes of formations to cause panic-mode (assuming no other effects on morale). * Morale: Smaller battalions panic more easily because fewer units need to be killed and they are also more vulnerable to other negative effects on morale because their total morale is lower. # Unit types and formations We need a decision how we restrict the type of units that can form a formation together. ## Allowing ranged and melee mix Mixing ranged and melee units in the same formation is not allowed. An important aspect of the system is the challenge of protecting the ranged units against attacks from melee units and cavalry in particular. # Forming and disbanding a formation ## Forming a formation A formation is formed by selecting a number of units and clicking the button of the desired formation. Buttons only become active when all requirements are met. For example, a formation requires a minimum number of units or it requires units of a specific type. Formation bonuses start applying as soon as 90% (exact value TBD) of the units have reached their designated location in the formation. If the new bonus would apply instantly after ordering a different formation, players could switch to different bonuses instantly while in battle. This would be unrealistic and a problem for the visualization of the bonus. Why would you get a different bonus when none of your units actually move? ## Disbanding a formation ### Duration Disbanding is instant. Assuming a formation has a defense malus on the rear, you can instantly get around this malus by disbanding. The downside is that forming the formation again might not be possible if your units can't get into position for the formation anymore. The other obvious downside is that you also loose all bonuses. ### Conditions Formations can be disbanded if their morale is above 50% (exact value TBD). This prevents players from quickly disbanding a formation before it gets into panic mode. ### Forced fallback to default formation Different formations have different minimum requirements for the number of units. This is meant to be a higher value than the minimum battalion size because it should encourage players to make larger battalions without having to increase the lower limit for forced formation disbanding. As units in the formation die, this minimum requirement suddenly isn't met anymore. In this case, the formation falls back to a default formation. How this happens exactly is a bit tricky because it should be visualized well to the player and shouldn't look strange or unrealistic. - Revert animations to default (Example: units don't hold up their shields anymore in the testudo) - Without a move order, units stay where they are (they don't try to switch to default formation layout) - When moved, units are positioned according to default formation layout - Bonuses are instantly switched to default formation bonuses - The banner visualization is changed to the default formation visualization. This needs some clever artwork and GUI design. What we want to visualize here is "forced fallback to default formation". ### Forced disbanding Battalions have a minimum requirement for the number of units. As units in the battalion die, this minimum requirement suddenly isn't met anymore. This causes the battalion and therefore also the formation to get disbanded. Units can be selected individually again and they loose all formation bonuses. Considerations: - This means battalions close to the minimum size will usually disband before getting into panic mode. Because there are other ways to reduce morale than killing units, it's still possible that a battalion with minimum size gets into panic mode. It might also work to tune the system so that minimum-size battalions always go into panic mode when a unit dies. # Fighting in formation ## Default behaviour (melee) - Units stay in formation until they are very close to an enemy. - When the first unit in the formation starts fighting, the other units attack too. - The first row of the formation moves forward until they are close enough to attack. - Units try to keep their flanks protected, meaning that the first row will stay connected during attack, but it will not stay a straight line unless the two fighting formations attack perfectly frontal. - Rows after the first one follow the units in front of them - When a unit in the first row dies, units from behind catch up ## Ranged TODO ## Special behaviour There are some special formations that might need to stay in formation more strictly (TODO). # Movement in formation Formations have a larger obstruction than single units and have difficulties pathing through narrow gaps. The following approach is used to work around this issue. - When you issue a move order to a formation, the formation behaves differently depending on the distance from the destination - For a short distance it tries to move in formation and will query the pathfinder for the larger obstruction size. - If the distance is longer or if no path could be found with the large obstruction size of the formation, the units will change to column formation for the movement. - When moving in column formation, the units will re-establish the original formation when they are close enough to the target TODO: Some open questions: - How wide is the column for movement? It looks weird if the column is too narrow, but anything wider increases the risk that no path can be found. - How does the formation choose between shorter paths that require a more narrow column or longer paths that allow movement in a wider column. Can it switch to a more narrow column somewhere in the middle of the path? # Formation positioning You click to the spot where the left side of the formation should be placed and then drag your mouse to the right side. Going further right means your formation will have more columns but less rows. Clicking to the right and moving the mouse to the left on the screen will do the same, but the formation will be turned 180 degree (so the left side with respect to the formation is always where you start click-dragging the mouse). Some formations may have a limitation how many rows or columns they need as a minimum. Such restrictions will be reflected in a preview while you are dragging the mouse. # Directionality So far, formations basically just reduce the number of entities the player has to control and therefore make it possible to use the rock/paper/scissors concept. To offer real tactical depth for battles, we need some other means of getting an advantage over the enemy. ## Formation based Directionality for formations means that formations have an orientation and units get different modifications for their attack and/or defence values based on the direction they are facing relative to the formation orientation. This can be used to achieve two slightly different mechanics: ### 1. Surrounding Assuming a formation can change its orientation nearly instantly, the only way to take advantage of directionality is to attack from more than one sides. The formation can turn quickly, but it can't face two directions at the same time. It also feels quite apparent that surrounding troops or attacking them from two sides should give you some advantage and therefore the concept can be easily explained to players. ### 2. Outmanoeuvring If formations have a limitation how fast they can turn, there's also the possibility of outmanoeuvring slow formations. This could be applied to special formations like a Phalanx, which is very deadly against cavalry when attacked from the front but vulnerable when attacked from the back. ## Unit based Unit based directionality means that a unit has weaker armour on the back and the sides. If you attack a formation from the side, the units there will obviously turn to face the attackers. They have their defence values reduced because they are on the side of the formation (formation directionality), but their defence values aren't reduced further because the unit itself faces the attacker (unit directionality). Unit based directionality applies in the following situations: ### 1. Attacking units on formation-corners If you manage to attack a unit at the corner of a formation from the front and the side, you can benefit from unit based directionality. To prevent this, players want to close gaps between formations or make their formation wider than the enemy formation. If the attacker manages to break the line completely, this effectively doubles the number of corners and opens a way to get behind the formation. ### 2. Wide formation with few ranks As described above, formation directionality favours very wide formations to make it harder for the enemy to attack them from the side or from behind and to keep the corners protected. With unit directionality added, wide formations get more disadvantages. If the formation is so thin that you can not just attack the formation from behind, but also the units, the attacker get both bonuses. Unit attack range will have to be fine-tuned for this effect to work. It might be good if at least some units could reach further than one rank in the formation so that you also get a unit directionality bonus when attacking a formation which is two ranks deep. # Formation bonuses Different types of formations give different modifications to unit properties (attack, defence, move speed etc.). There can be positive and negative modifications and modifications can be directional (see directionality) or general. # Morale * The morale value for a battalion is the sum of the morale values of all its units. * Winning without killing all enemies (adding more depth to a battle by offering another way to victory) * Good for auras (heroes to boost morale, some units that scare the enemy and reduce their morale) * Interesting for technology choices: boost attack and defense or morale? * Morale is calculated per battalion * When a formation is disbanded, all units take over the morale value of the formation (the percentage). This prevents that players quickly disband and then form a battalion again to refresh the morale. It's still possible to mix units with low and high morale to get a battalion with a morale value somewhere in the middle, but that's probably fine. ## What influences morale? * Positive auras. Example: Hero close * Negative auras. Example: Enemy elephant attacking reduces morale regeneration rate * Experienced troops have increased morale * Heavily armoured champion units have more morale. TODO: More armour effectively means more morale already because units die slower. Do they really need more total morale in addition? Maybe yes, because that makes them more resistant to the other effects on morale. * Loss of units: The key here is that a dying unit reduces the morale points by more than the total number of points divided by the number of units. This means that a short and strong attack has a large impact on morale but a relatively low impact on the number of units in the battalion.  * Morale automatically regenerates slowly. Regeneration is faster when the battalion is not in battle (Not in battle meaning something like: "not attacked since x seconds" or "total attack in the last 10 seconds smaller than X points") * The battalion has a range. If another allied battalion within that range changes to panic mode, this also reduces the morale of the current battalion. This can cause a cascade effect which make the tactic of winning a battle by destroying the enemy morale stronger (this can be balanced by increasing or reducing the effect). ## What happens if morale reaches 0? * The formation changes to panic mode * This is indicated in some way (changed battalion banner, panic-animations playing for units from time to time, sound effects etc.) * Units in panic mode have reduced attack and armour values and they loose all bonuses they had from the formation they were in previously. They play the panic-animation from time to time and don't fight while doing that. * A formation in panic mode is so weak that it has to be pulled back from battle * Units are still grouped * Units keep their current positions, but they change to a panic mode formation (basically random grouping of units) which takes effect when the units are moved. * Battalions in panic mode can't be disbanded * Units recover from panic mode when their morale raises above 50% again (value to be adjusted during playtesting and balancing) ## Tactical considerations * If a formation presents a larger front to the enemy, it inflicts more damage but is also more vulnerable to loosing morale. You might want to use a different formation layout depending on how strong the morale of your units is and how easily you can retreat them. For example, if you are fighting a battle in front of your own gates, you might want to quickly deal a lot of damage to the enemy troops and then retreat your panicing troops behind the walls. # Stamina The question is if we actually need stamina in addition to morale because they are similar. Brainstorming... * Differentiate between light units that can move faster and further with their stamina and heavy units that can fight longer (different stamina use for movement and fighting) * Practically increase the distance between settlements without requiring larger maps (movement takes stamina) * Adding another aspect to battle. If you had a long march and then immediately start fighting, you have a disadvantage because of stamina # Charging TODO # Potential issues - The mix between fighting with single units and fighting as formations is very tricky. Especially the transition between the two is quite hard to get right design-wise. * Not enforcing minimum size requirements for formations and battalions could lead to "single-unit formations" or very small formations just to get the bonuses * If forced disbanding happens too early, the main part of the battle will be fought in single unit combat again. This is not what we want. * If formation bonuses are still applied for very small formations, that could be abused and could also lead to something similar as single unit combat.  - Confusion between forced fallback to default-formation and panic mode could occur. - Maybe it's too much to have panic mode, default-formation fallback and formation disbanding. - **Can more units attack at once if they aren't in a formation? Does this give formations a disadvantage that's hard to overcome?** # Fallback There are some parts of this design that could be removed completely if testing shows that they don't work as expected. ## Minimum units for formation and fallback to default formation Instead of having a minimum requirement for the number of units per formation, we could just have the minimum battalion size that applies to all formations and remove the whole logic about falling back to default formation completely. There would still be some good reasons to make formations larger than the minimum size. Making them larger protects them better against panic mode and forced formation disbanding. We might want to start implementing it this way and see how it works. # Movement in detail ## A: Corridor movement ![ImageA.png](formations/A.png) **Goals:** 1. The formation picks the direct path 1. No units must turn around and walk backwards 1. The formation movement looks natural **Decisions:** Nothing to decide, the expected behaviour is quite obvious. # B: Corridor movement marginally obstructed ![ImageB.png](formations/B.png) **Goals:** 1. Same goals a s with A 1. The formation moves around the small obstacle (fence) in the middle. Roughly half of the formation should move around the left and half around the right of the fence (when it's in the middle). **Decisions:** 1. Formations are allowed to split up in order to path around small obstacles. They don't require a path for the full formation obstruction. # C1: Too narrow target location (no alternative) ![ImageC1.png](formations/C1.png) **Goals:** 1. The formation is allowed to move to the flag, even though there's too little room for the whole formation obstruction. 1. The formation ends up with more ranks but less wide to fit into the narrow spot **Decisions:** 1. It's allowed to move formations to a target when there's not enough space for the whole formation at the target location.  * Different behaviour would be a problem, especially with large formations and unrevealed territory  * It doesn't seem too difficult to achieve a reasonable behaviour in the vast majority of cases # C2: Too narrow target location (alternative path) ![ImageC2.png](formations/C2.png) TODO: This is where it gets difficult. Maybe this needs another testcase that elaborates on the behaviour. 1. Does the formation use the same behaviour as in C1 or does it try to position units outside of the wooden walls too, trying to keep the formation shape?  * Different behaviour might be wanted depending on how much distance (real walk distance, not linear distance) units have to cover to reach that spot.  * The player might not want units to walk through the narrow gap and take the way on the front if enemy units are there. # D: Partially obstructed paths with alternative ![ImageD.png](formations/D.png) **Goals:** 1. The formation picks the direct path (where the trees are). 1. Movement looks natural (no units going back and forth for example).  **Decisions:** 1. Formations always pick the shortest path, even if it's partially obstructed (all individual units in the formation can pass, but not the formation as a whole) and even if a free (but longer) path is available.  * Different behaviour would not be predictable for the player and it would be very hard to implement a reasonable fuzzy logic that covers all the cases well. # E: Dense forests ![ImageE.png](formations/E.png) **Goals:** 1. The formation picks the direct path. 1. Units pick reasonable paths to get through the forest and keep close together as good as possible. They try to keep the formation shape if possible, otherwise they just try to keep as close together as possible. 1. Formation movement looks natural. **TODOs:** 1. If formations move through dense forests or similar obstacles and units separate too much, this should have an impact on formation bonuses. Is it enough to use a rule like "if less than x% of the units are in their designated location according to the formation shape, bonuses do not apply"? diff --git a/book/gameplay/main/territories.md b/book/gameplay/main/territories.md index cf25650..2f290fb 100644 --- a/book/gameplay/main/territories.md +++ b/book/gameplay/main/territories.md @@ -1,109 +1,109 @@ TERRITORIES =========== -> **[warning] Implementation status** -> -> This page describes a feature that is implemented, but the implementation -> significantly differs from the text here. The text is to be updated. +!!! warning + + This page describes a feature that is implemented, but the implementation + significantly differs from the text here. The text is to be updated. ![Territories3.jpg](territories/Territories3.jpg) PROVINCES --------- When this game mode is enabled, every map will be comprised of a number of Provinces. That number is determined during game session creation. Every Province will have a Settlement in it that players may 'settle'. When a player takes that action, they effectively declare ownership of that Province; which adds the Province to the player's Territory. Ideally, the Provinces will be evenly sized and have roughly equal available resources. They will also follow natural boundaries such as forest lines, roads, rivers, islands, etc. SETTLEMENTS ----------- Each Province is centralised around that Province's Settlement. If no player controls the Settlement, it is owned by Gaia. That means there are no penalties for traversing across it and it is free to be taken by any player. To take control of a Province, construct a Civic Centre on its Settlement. Destroying an enemy Civic Centre will cause it to revert back to being a Settlement. Because Gaia now owns it, all bonuses and penalties to players in the Province are now null. Settlements are indicated on the Mini Map using a unique symbol. CIVIC CENTRES ------------- A player gains control of a Province by building a Civic Centre upon the site of the Settlement. In Territory game mode, this is the only way to build additional Civic Centres. Each player begins the game with control of one Province, via a "starting" Village Centre (unless he is playing the Nomadic game mode, in which case he will begin with only starting units and will first need to hunt down an available Settlement to build his first Civic Centre). Destroying an enemy Civic Centre reveals the Settlement at its foundation, allowing the player to build his own upon the site and seize control of the Province (any structures and units will still remain in the Province). BENEFITS OF CONTROLLING A PROVINCE ---------------------------------- * The player sees no Shroud of Darkness in his own Provinces. * Expanding his Territory allows the player to control more of the game map.  * He cannot easily build structures on terrain unless he controls its Province.  * He cannot gather from resource objects unless he controls their Province. * Until the 'rush timer' has ticked down to zero, units will rapidly lose hitpoints whenever they are in an enemy's Province. (The starting time of the timer is specified at session creation.) * Faster construction time: In situations where the player can build around existing buildings in a Province he doesn't own (see the next section), he cannot build as quickly in the other player's Province as he could in his own. * Civic Centres increase population limit, so more units can be trained. * All of the player's entities gain a bonus to their armour value as long as they are in one of his Provinces. STRUCTURES IN PROVINCES ----------------------- To repeat, one of the big advantages of owning a Province is that you can easily construct structures in that province. However this is not the only way. Requirements to build: * Build a Civic Centre on the Settlement   This is your first initial step to construction of any structure in any Province. * Capture a structure from the enemy   If you cannot construct a structure and you really want to build a structure in that Province, another option is to weaken the enemy's structure to the point of capturablity. After it is captured you are capable of building structures in its proximity. * Have a structure already built in the Province   This is an issue when an enemy comes into your Province and destroys your Civic Centre. You are still able to build in this Province within the proximity of your existing structures. ALLIED PROVINCES ---------------- A player may build defensive and military (but not economic) structures within a Province controlled by an ally. It is not permitted to seize ally-controlled Provinces unless the player destroys their Civic Centre. If they take such an action, the player forfeits ownership of that province to their ally (or whoever builds on top of the settlement first). TERRITORIES ----------- A Territory is defined as a player's collection of Provinces. PROVINCIAL BORDERS ------------------ The outer edges of the terrain a player controls will be marked on the Mini Map in such a way for the player to visualise ownership of that Province. It will also be encouraged to represent this on the game map. diff --git a/book/index.md b/book/index.md new file mode 100644 index 0000000..f35b599 --- /dev/null +++ b/book/index.md @@ -0,0 +1,24 @@ +0 A.D. Design Document +====================== + +## Licensing and Disclaimer + +[![License: CC BY-SA 4.0](https://img.shields.io/badge/License-CC%20BY--SA%204.0-lightgrey.svg)](https://creativecommons.org/licenses/by-sa/4.0/) +This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. + +The info contained in this Design Document is provided as-is. It represents the current plan for 0 A.D. but the final game might not be exactly as described here due to for example issues found when balancing the game or features cut to make it possible to release the game in a reasonable time. + +## Links and References + +This Design Document is still a work in progress and is based on several +iterations of the text, as well as scattered information across our +development forums, wiki, etc. + +Here is a collection of a few references that might be useful for the +contributor or the reader who is curious about the origins of the document. + +* Our Trac wiki: + * [Previous version of the DD](https://trac.wildfiregames.com/wiki/Design_Document) + * [Attempt at an update](https://trac.wildfiregames.com/wiki/DDv3WIP) + * [Exhaustive list of all pages of the wiki](https://trac.wildfiregames.com/wiki/TitleIndex) +* [Our forums](https://wildfiregames.com/forum) diff --git a/mkdocs.yml b/mkdocs.yml new file mode 100644 index 0000000..7ad46a6 --- /dev/null +++ b/mkdocs.yml @@ -0,0 +1,37 @@ +site_name: 0 A.D. Design Document +site_author: Wildfire Games +repo_url: https://code.wildfiregames.com/source/design/ +repo_name: Contributing +use_directory_urls: false + +docs_dir: book +markdown_extensions: +- admonition + +nav: +- Gameplay - Main concepts: + - '0 A.D. The Vision': gameplay/main/vision.md + - 'War Story': gameplay/main/war-story.md + - 'Territories': gameplay/main/territories.md + - 'Capturing': gameplay/main/capturing.md + - 'Formations': gameplay/main/formations.md +- Gameplay Elements: + - 'Maps': gameplay/elements/maps.md + - 'Structures': gameplay/elements/structures.md + - 'Entities': gameplay/elements/entities.md +- Civilizations: + - 'Athenians': gameplay/civs/athenians.md + - 'Britons': gameplay/civs/britons.md + - 'Carthaginians': gameplay/civs/carthaginians.md + - 'Gauls': gameplay/civs/gauls.md + - 'Iberians': gameplay/civs/iberians.md + - 'Macedonians': gameplay/civs/macedonians.md + - 'Mauryans': gameplay/civs/mauryans.md + - 'Persians': gameplay/civs/persians.md + - 'Ptolemies': gameplay/civs/ptolemies.md + - 'Romans': gameplay/civs/romans.md + - 'Seleucids': gameplay/civs/seleucids.md + - 'Spartans': gameplay/civs/spartans.md +- Technical Design: + - 'General settings': technical/settings.md + - 'Game settings and setup': technical/gamesetup.md