Table of Contents
The game Ascendancy is:
The world of Ascendancy has a European high medieval to renaissance level of technology, but magic works. Magical practitioners, some of whom are extremely powerful, can achieve effects unknown to medieval (or even modern) times, but magic is only rarely used on an industrial scale. There are fantastical beasts. The gods are real, if remote, but some take an active interest in the affairs of men.
Players control characters in the world of Ascendancy which start out as uncommon and over time rise to the level of heroic. Some will be warriors, others mages, priests, thieves, or any combination thereof. These characters may undertake fantasy quests, such as investigating dungeons or hunting monsters.
Players who so choose may acquire dwellings, towns, provinces, or even empires. They may raise armies and fight wars. Or they may choose to follow the paths of exploration or commerce. With enough time and effort, there is nothing in the world that may not be ultimately done or controlled by player characters.
The mechanics of the world of Ascendancy are complex and intricate. All a player needs to know to start playing is set forth in this guide. This includes all the commands units can execute and some of the most basic items, skills, and interactions between them.
But like the proverbial iceberg, most is hidden. This includes the parts of the world’s map that have not been explored and most items, advanced skills, and their properties. These can only be discovered through exploration, experimentation, and examination or learned from more experienced players. Moreover, new ones may be added at the game progresses.
Players may join, leave, or return during the entire length of the game. Games will last for dozens or hundred of turns, covering decades in game time and years in real time. Players who join late will be at some disadvantage compared to established players, but will be awarded some bonuses to allow them to catch up more quickly.
It is possible for players to win at Ascendancy. Winning players will not end the game, but greatly reduce their involvement. The means and conditions for winning are not discussed herein. Very advanced characters will have to discover how to win for themselves.
Each active game of Ascendancy should have at least hundreds of active players and can accommodate thousands of players and locations, tens of thousands of units, and a near-unlimited number of items.
Ascendancy is played via e-mail. Players send in orders for the characters they control. Whenever a turn is run, typically once a week, these orders are processed and the results mailed back to the players. A player with just a small number of adventurers should be able to create their orders for each turn within 15 minutes or less. As unexecuted orders carry over from turn to turn and it is possible to enter conditional orders, even missing a turn or two is not necessarily disastrous. However, a player who has set his sights on running a continental empire may need hours to assemble his orders and may spend many more on diplomatic palavers with allies, minions, and rivals.
Ascendancy caters to everybody who like big, long, complex games with emergent phenomena; whether they have just a few minutes or many hours to invest every week; whether they prefer role-playing or grand strategy; whether they are lone wolves or social butterflies; whether they want to explore, build, or rule the world; whether they prefer their graphics in cool, retro ASCII or fancy HTML markup. For those that like this sort of thing, this will be the sort of thing they like.
As soon as I set down the pen for the first version of this manual, I was overcome by a none-too-pleasant shock: This pamphlet promised at
few pages—after all, it is a discoverable game and most of the mechanics should not be set down here—had grown to nearly a hundred in a stylistic cross between a MilSpec and the offering document for a moderately complex Collateralized Debt Obligation.
The reason for this deficiency was obvious. It was written with the initial play testers in mind, rule lawyers each and, in distressing numbers, of the legal variety too. They would blame me whenever something went wrong, as it is apt too in a game like this. (One of them in particular is prone to react to rules mishaps with shouts of
WTF in your humble scribe’s direction, except she does not use abbreviations.) So I needed chapter and verse to cite to for every eventuality. Even worse, it turns out the document was written by a lawyer too.
Unfortunately that meant that nobody would read these rules unless paid lawyers’ hourly rates. Which is rather a shame as the game would be a lot of fun for many intelligent gamers even outside the legal profession and paying would rather defeat the purpose of making this a paying, or at least not money-losing, venture. So I decided to rewrite the rules and, more importantly, start with this simple informal introduction to get people hooked before they need to study.
So don’t read this manual. Just grab yourself an account from www.ascendancyonline.com and start playing. It’s free! (For now.)
By now you should have received all you need to play: A an emailed template for your first orders and an initial report attached thereto. Reply to the e-mail and copy and paste the contents of the template as the contents of your email. Then open up the report in a different window.
Look in the report. You should find your initial guy (or gal) listed inside a peaceful province outside a city. Make a note of the little code in square brackets () behind their name. That is called your ID. There should already be a line in your order template which reads like
ORDER your-id [your-name] It is right after that (and before the END lines following it) that you’ll insert your initial orders.
First thing you probably want to do is go to the city, both for safety and to recruit your first followers. Look at the name of the city in your report. Right after the ORDER line in your template, insert a new line with MOVE followed by a space and the name or ID of the city. That will make you go there on the first day of your turn.
Next, you’ll want to recruit a couple of followers. Have a look at the report and find all the guys in the city who are proudly flying the unaffiliated banner. Those guys are mercenaries and only too happy to join your cause. Pick one and after the MOVE insert a new line with RECRUIT and that character’s name or ID. This will recruit them to your faction.
Your new guy probably has zero skills and no orders. Rather than having him waste most of his first turn, order him to study something, so he is not quite so useless any more. After the RECRUIT line insert these lines:
ORDER your-new-guys-ID-or-name STUDY something END
Instead of something, you probably want to pick an actual skill like mage, priest, rogue, or warrior, according to taste. Note the END; that means that this ends your commands to your new underlying and we are back to discussing your own next steps.
You probably want to have at least three or four followers to start with, so repeat the above steps with more likely candidates in the city.
In fact, you probably want to try to recruit more followers than you actually want. Why? Because the world of Ascendancy is full of other players doing their own thing who are not your friends, sometimes decidedly so. In particular, if you started right at the beginning of a new game, there are probably a bunch of other new players trying to do exactly the same thing you are trying to do. And if they get to one of your candidates first, they’ll recruit them and your recruitment will fail. So will your following ORDER because they won’t be your guys and in no mood to take orders from you!
That’s ok. Intentional or unintentional interference between players and resulting failed commands are a perfectly normal part of play.
Your first trick is to try to anticipate what others will do and write your orders accordingly. So pick the ugly recruits far down the list with stupid names. It doesn’t matter; they are all the same and you can always change their names later.
The second, more important trick is to write your orders so that you will end up doing something useful and productive even if some of your orders fail. Tactical failure is an option; arrange things so that, if things do not go as planned, the commands you wouldn’t want done just fail. Failure is cheap. So recruit more people than you think you need and chances are that you will end up with just what you need. And even if you don’t, there is always next turn to fill up your roster with the leftover runts.
One last thing to do before you hit send on your first orders. You notice that all your main guy has done is try a couple of RECRUITs (taking one day each) and pass on some ORDERs (taking no time at all). That should leave you with most of the rest of the month which you can use to study yourself. So append this to your orders (where something is something you want your main guy to learn):
That will consume your main guy’s time for the rest of the month and should get him to level 1 and most of the way to level 2 in his métier. Note that it is important that you put your STUDY command at the bottom of your main guy’s orders (right before its own END). As they say, ars longa, vita brevis, and STUDY goes on forever or until another ORDER is sent. So if you had put the STUDY further up in your orders, your main guy would have continued to study forever and never reached the following RECRUITs and ORDERs.
Now hit send. Do not wait. It is OK. You have the opportunity to send new, overriding orders until the game turn is actually run and, if you send your orders right now, you should receive an acknowledgment and a new order template reflecting what you did within a few minutes.
If you get some crummy error messages, do not despair. Most everybody gets them on their first turn. Try to figure them out and send new orders (either based on the original order template you got at the beginning or on the new order template you get whenever you send in orders). If you can’t figure it out, ask somebody. There are plenty of people happy to help and there is plenty of time to fix any errors before the turn runs.
If eventually you don’t get any errors, excellent! Now you can just wait for the turn to run and you to get your first real turn report with all the exciting developments.
If you now are interested in playing Ascendancy, have a look at this revised manual. Read about units, items, skills, and game play. Subscribe to the announcement mailing lists. Have a look at some of the most important commands, like MOVE, TRAVEL, COLLECT, MAKE, and any others which strike your fancy. And if you are feeling misanthropic (or misplasmic, as the case may be), read about combat and ATTACK. Just be sure to skip all the advanced subject sections (they are hidden anyway unless you click the check box in the corner).
Always remember: You do not need to know all the rules to enjoy playing Ascendancy—in fact, most of what can happen is not even in this manual but can only be discovered by playing.
The basic component of an Ascendancy game are units. Each unit represents an agglomeration of possibly a character and items (including architectural structures and the like). A lonesome warrior wandering the wilderness, a mansion, a hidden cache, a grand army or fleet, a town, a gang of bandits, or even a geographical area—all of these are examples of units. The only commonality between all units is that each one is in exactly one place and under the control of (at most) one player.
Most units are stacked inside other units which defines their location. Only some units, known as provinces, are located by geographical coordinates in the world itself (or perhaps even outside of it). All other units are stacked inside provinces or inside units which themselves are in a province or inside units inside units in provinces, etc.
For example, the province of Mathrolen Plains, located in the temperate zone, may contain a bunch of bandits, an invading army, a hidden cache of gold, the dungeon of Bogden, and the town of Carlock. The town of Carlock may contain a few traders, a city guard, and the Vitalder library. The Vitalder library, in turn, may contain the archmage Kemer, a few students, and a library guard. Such an arrangement might be represented as follows:
- Mathrolen Plains:
- Army of Durrley
- Dungeon of Bogden
- Town of Carlock:
- Trader Ahman
- Vitalder Library:
- Archmage Kemer
- Student Cault
- Student Ferger
- Trader Lesky
- Lair Beslan
This can go on forever as there is no limit on the depth of stacking.
The unit in which a unit is directly stacked is called its parent. The units which are directly stacked inside a unit are called its children. Units which are stacked directly in the same unit are called siblings. A unit and all its children, their children, and so on, is called a stack.
For most purposes, units can only interact if they are adjacent. Two units are adjacent they are siblings or one is the other’s parent (i.e., is its child). For example, the Vitalder Library is adjacent to the Town of Carlock (because it is directly inside of it), Trader Ahman, the First_Guard, and Trader Lesky (because they are all directly inside Carlock), and Kemer, Cault, Ferger, and the Vitalder_Guard (because they are inside the library). But Cault is not adjacent to Ahman; for Cault to give Ahman an item, he would have to leave the Vitalder Library first.
There are no size restrictions on units or their stacking. Any unit can be arbitrarily large and
contain units which are physically much larger. Think of such situations as the larger inside-unit overflowing or surrounding the smaller unit it is logically inside of. In circumstances where these physical relations might matter, such as whether a large army
inside a small house will be protected from attack by the house’s walls, the mechanics of the game account for this properly.
Some units are characters. Characters are the main protagonists of Ascendancy. Characters have a gender (usually) and skills which define them and can live, die, and be captured. Most importantly, almost all interesting commands (such as attacking, traveling, collecting, or making items) can only be performed by characters (i.e., units which are characters). For a single player to acquire more than a few characters is difficult and expensive. See RECRUIT. This is the most significant limit on the scope of each player’s activities.
Death and Disability
Characters may die as a consequence of combat, execution, or other reason. The longer a character has been dead, the harder it is for the priest skill resurrection to bring them back to life. Once a character has been dead for a year (or if it was laid to rest by another priest), they become expired. Expired characters lose their faction and stop affecting the faction’s RECRUIT cost. It may not be possible to bring back expired characters.
Dead characters are considered uncontrolled units, even if they have sentients. In that regard non-character units, which will be controlled if they have sentients, are superior to characters.
Characters which have as many wounds as they have hits are disabled. Disabled characters cannot participate in combat and have to be carried when traveling, but otherwise can continue to execute character commands. Dead or captive characters are also deemed disabled.
Each controlled unit belongs to a faction. Most factions represent individual players which control the units of their faction by issuing commands for them and receiving reports from them. There are also non-player factions whose units wander the game world. Units which do not belong to a faction will generally sit idly without executing any commands, though they can still defend themselves if attacked.
Only controlled units can belong to factions. Non-characters which lose the last of their sentients automatically lose their faction and do not regain it, even if somehow replenished. Characters which expire also lose their faction.
Each faction has an ID pool. This is a list of unassigned IDs that can be used for various commands.
Every unit and faction has an ID. This is a code consisting out of one or more lower-case English letters (i.e., the letters
z) followed by one or more digits (i.e., the digits
9). IDs are unique and unchangeable. An ID is assigned when the unit is created and will never change (or be reused) over the course of the game. Unit and faction IDs usually consist out of three letters followed by three digits.
Units will also usually have names. For controlled units, the controller may change the name at any time using the NAME command. In orders, units can be referred to either by ID or name. Generally, using the ID is safer as it will not change.
Units may also have titles. For controlled units, the controller may claim any title for which the unit qualifies (which varies from title to title) using the TITLE command. Titles stick (even if the unit no longer qualifies). Only the controller can discard a title or claim a new title for which the unit is eligible. Titles are almost purely cosmetic; all they convey is that the unit qualifies (or, at some point, qualified) for the title. Titles are never used to identify units in orders.
Factions, too, have names, IDs, and possibly titles.
All characters are controlled units.
In addition, other units which have sentients are also controlled units. Sentients are items that are intelligent creatures, such as workers, soldiers, intelligent beasts, and the like. Examples of other controlled units would be a house or city with guardsmen, a fleet with crewed ships, an army unit with soldiers, or even a province with a garrison. Dumb beasts, even those who can fight (like war horses or hounds), are not sentients. Neither are peasants; while certainly intelligent, they are not inclined to take orders. Conversely, some seemingly inanimate items (like siege engines or ships) are sentients because they implicitly include their crew. If in doubt, EXAMINE the item.
All controlled units can belong to factions (i.e., players) and will report what they see to their masters.
Non-character controlled units have only a very limited subset of commands. Most of these are basically reactive, such as defending units being attacked or automatically skirmishing against hostile targets which cross their sight. Such units cannot travel, independently launch attacks, or perform most other interesting tasks.
There are few limits of the number of other controlled units a player can create. A player could subdivide an army unit of 100 swordsmen into a unit of one swordsman under which there are stacked 99 individual units of one swordsman each. As a practical matter, apart from being massively inconvenient, this stack would have the same effect as the single unit.
In much of the world of Ascendancy there are plenty of monsters to terrorize the populace and enrich adventurers. Monster units generally appear in one of three varieties:
There are roving bands of monster units that roam the countryside. They will typically be in provinces and attack or skirmish anyone they deem to be an easy target. They may also travel from province to adjacent province. Roving bands tend to consist out of smaller number of less powerful monsters and the loot they may carry reflects that. They spawn most places and tend to grow over time.
Some monster units are lairs. These lairs, usually located in provinces, themselves hold monsters of average power and number as well as walls and other immobile items. Because the lairs are immobile, they will not attack anybody on the outside. To conquer a lair, just attack it. New monsters occasionally take residency in uncontrolled lairs.
Finally, there are dungeons. Dungeons are uncontrolled immobile units located in provinces, but each dungeon may contain additional lower-level dungeons. Each dungeon level contains units of actual monsters. Unless you are very powerful or very suicidal, do not attack a dungeon from the outside—that will summon every monster in the dungeon, including all its lower levels, to fight you together and protected by the dungeon's fortifications. Instead, enter the top level of the dungeon, attack the monster units inside (though usually they will do you the favor of skirmishing you as soon as you enter), and work your way down. Dungeons, particularly at lower levels, contain the most powerful monsters and loot. Dungeons also tend to repopulate with new monsters when left uncontrolled.
Monster units, like other units, have factions. Most monster factions are hostile to most other factions in the game (including player factions).
Each unit can have or own items. Owned items may be conventional property like gold or food or swords. But it may also be larger
items like the peasants in a province, the galleons in a fleet, the soldiers in an army, or the walls in a city.
What a unit can do depends on what items it contains. A unit with many laborers can be considered a work gang. A unit with many swordsmen or knights may be an army. One with galleons can be a fleet. A unit with a few walls can be a house, one with many a city. Such a city will not be able to travel or move. A fleet will not be able to travel overland (unless it also has a lot of men or beasts of capacity to carry the ships).
Almost all items have a degree of encumbrance associated with them called the size. An item’s size is roughly based on its weight in pounds, though other factors such as unwieldiness or magical effects can vary this number up or down. For a typical human, the size is 150 (though armor and equipment can increase this number); for a horse, 1000; for a gold (the universal currency), 0.01.
Items capable of self-propulsion along land, water, or other modes of transportation (which includes most creatures, but also some inanimate objects such as wagons) will also have a carrying capacity and speed. The carrying capacity determines how much size the each item can transport. For a human, the carrying capacity is 300. That means that, for each unencumbered human in a unit, the unit can carry the human and an additional 100 size. Speed determines what distance the item can TRAVEL in a day. For a typical human the speed is 10 miles per day, though other factors (such as roads or weather) can modify this number.
An item, like a unit or faction, has an ID and name. In orders, they can be referred to by either and using names is perfectly safe as nobody (except the developers)
controls an item type and could change its name. Item IDs usually consist out of two letters followed by two digits
Common generally-known items include:
male. Non-descript human. Adventurers[zl37] are size 150.0 and can carry 50.0 size at 15.0 miles per day over land. Adventurers[zl37] attack at 10, can be retaliated against, defend at 10, and take 2 hits. Adventurers[zl37] are recruitable and sentient. Character adventurers[zl37] can equip on arms, feet, hands, head, left_hand, left_index_finger, left_middle_finger, legs, neck, right_hand, right_index_finger, right_middle_finger, and torso.
pl. adventuresses. female. Non-descript human. Adventuresses[za91] are size 150.0 and can carry 50.0 size at 15.0 miles per day over land. Adventuresses[za91] attack at 10, can be retaliated against, defend at 10, and take 2 hits. Adventuresses[za91] are recruitable and sentient. Character adventuresses[za91] can equip on arms, feet, hands, head, left_hand, left_index_finger, left_middle_finger, legs, neck, right_hand, right_index_finger, right_middle_finger, and torso.
These are soldiers equipped with bows which greatly enhances their combat attack, but not their defense. Archers[se03] are size 154.5 and can carry 45.5 size at 15.0 miles per day over land. Archers[se03] attack at 6, cannot be retaliated against, defend at 2, and take 1 hit. Archers[se03] are sentient. Archers[se03] benefit in combat from land leadership.
Archers[se03] can be made at a rate of one each day from a bow[wa62], a soldier[sn80], and ten gold[aa00] using up to 10 of sergeant[sn33], staff_sergeant[si91](2.0x), master_sergeant[st01](3.0x), and sergeant_of_the_army[su34](4.0x) and leadership[sw91] at 2.
Archers[se03] must be paid in gold[aa00], one each a week, or 1.0% defect each day and turn into soldiers[sn80].
pl. axemen. These are soldiers equipped with battleaxes which enhances their combat defense and, in particular, their combat attack. Axemen[se91] are size 155.0 and can carry 45.0 size at 15.0 miles per day over land. Axemen[se91] attack at 4, can be retaliated against, defend at 3, and take 1 hit. Axemen[se91] are sentient. Axemen[se91] benefit in combat from land leadership.
Axemen[se91] can be made at a rate of one each day from a battleaxe[wy81], a soldier[sn80], and ten gold[aa00] using up to 10 of sergeant[sn33], staff_sergeant[si91](2.0x), master_sergeant[st01](3.0x), and sergeant_of_the_army[su34](4.0x) and leadership[sw91] at 2.
Axemen[se91] must be paid in gold[aa00], one each a week, or 1.0% defect each day and turn into soldiers[sn80].
An axe for single-handed combat. Battleaxes[wy81] are size 5.0. A battleaxe[wy81] may be equipped on right_hand or left_hand. When equipped, a battleaxe[wy81] increases combat attack by 6.0.
A flexible wooden arc tied together with a string and used to hurl arrows in combat. Bows[wa62] are size 4.5. A bow[wa62] may be equipped on right_hand and left_hand. When equipped, a bow[wa62] increases combat attack by 7.0 and prevents retaliation.
A bronze shield to be held in one hand during combat. Bronze_shields[ah96] are size 18.0. A bronze_shield[ah96] may be equipped on right_hand or left_hand. When equipped, a bronze_shield[ah96] increases combat defense by 4.0.
A small wooden shield to be held in one hand during combat. Bucklers[as92] are size 5.0. A buckler[as92] may be equipped on right_hand or left_hand. When equipped, a buckler[as92] increases combat defense by 2.0.
pl. chain_boots. A pair of pieces of chainmail protecting the feet only. Chain_boots[aa66] are size 6.0. A chain_boots[aa66] may be equipped on feet. When equipped, a chain_boots[aa66] increases combat defense by 1.0.
A piece of chainmail protecting the entire head. Chain_coifs[ay30] are size 6.0. A chain_coif[ay30] may be equipped on head. When equipped, a chain_coif[ay30] increases combat defense by 2.0.
Pieces of chainmail protecting the hands only. Chain_gauntletss[an58] are size 5.0. A chain_gauntlets[an58] may be equipped on hands. When equipped, a chain_gauntlets[an58] increases combat defense by 1.0.
A piece of chainmail protecting the torso. Chain_hauberks[aq78] are size 15.0. A chain_hauberk[aq78] may be equipped on torso. When equipped, a chain_hauberk[aq78] increases combat defense by 4.0.
pl. chain_leggings. A pair of pieces of chainmail protecting the legs and feet. Chain_leggings[ad16] are size 12.0. A chain_leggings[ad16] may be equipped on feet and legs. When equipped, a chain_leggings[ad16] increases combat defense by 2.0.
pl. chain_vambraces. A pair of pieces of chainmail protecting the arms and hands. Chain_vambraces[aj96] are size 10.0. A chain_vambraces[aj96] may be equipped on arms and hands. When equipped, a chain_vambraces[aj96] increases combat defense by 2.0.
The simplest of all weapons; essentially a short staff, or stick, made of wood used single-handed in combat. Clubs[wj65] are size 2.5. A club[wj65] may be equipped on right_hand or left_hand. When equipped, a club[wj65] increases combat attack by 3.0.
A flexible wooden arch tied with a string, mounted horizontally on a heavy piece of wood, and used to hurl bolts in combat. Crossbows[wx45] are size 15.0. A crossbow[wx45] may be equipped on right_hand and left_hand. When equipped, a crossbow[wx45] increases combat attack by 10.0 and prevents retaliation.
pl. crossbowmen. These are soldiers equipped with crossbows which enhances their combat attack, but not their defense. Crossbowmen[so23] are size 165.0 and can carry 35.0 size at 15.0 miles per day over land. Crossbowmen[so23] attack at 4, cannot be retaliated against, defend at 2, and take 1 hit. Crossbowmen[so23] are sentient. Crossbowmen[so23] benefit in combat from land leadership.
Crossbowmen[so23] can be made at a rate of one each day from a crossbow[wx45], a soldier[sn80], and ten gold[aa00] using up to 10 of sergeant[sn33], staff_sergeant[si91](2.0x), master_sergeant[st01](3.0x), and sergeant_of_the_army[su34](4.0x) and leadership[sw91] at 2.
Crossbowmen[so23] must be paid in gold[aa00], one each a week, or 1.0% defect each day and turn into soldiers[sn80].
A knife with a very sharp point used as a thrusting or stabbing weapon. Daggers[wx81] are size 1.0. A dagger[wx81] may be equipped on right_hand or left_hand. When equipped, a dagger[wx81] increases combat attack by 3.0.
pl. gold. A small coin of questionable gold content. Still, it is the universal currency and makes the world go round. Gold[aa00] are size 0.01.
An axe for two-handed combat. Greataxes[wt04] are size 10.0. A greataxe[wt04] may be equipped on right_hand and left_hand. When equipped, a greataxe[wt04] increases combat attack by 12.0.
A long metal handle ending in a large blunt metal head for two-handed combat. Greathammers[wv19] are size 5.0. A greathammer[wv19] may be equipped on right_hand and left_hand. When equipped, a greathammer[wv19] increases combat attack by 12.0.
Plate armor protecting the entire head. Greathelms[aj32] are size 10.0. A greathelm[aj32] may be equipped on head. When equipped, a greathelm[aj32] increases combat defense by 3.0.
A long blade for two-handed combat. Greatswords[wd20] are size 8.0. A greatsword[wd20] may be equipped on right_hand and left_hand. When equipped, a greatsword[wd20] increases combat attack by 12.0.
Broken to the saddle. Horses[ze87] are size 1,000.0 and can carry cumulatively 10.0 size at 25.0 miles per day and 190.0 size at 20.0 miles per day over land.
An iron shield to be held in one hand during combat. Iron_shields[al15] are size 15.0. An iron_shield[al15] may be equipped on right_hand or left_hand. When equipped, an iron_shield[al15] increases combat defense by 4.0.
A light spear designed primarily to be thrown. Javelins[ww30] are size 2.0. A javelin[ww30] may be equipped on right_hand or left_hand. When equipped, a javelin[ww30] increases combat attack by 5.0.
Thanks to their heavy armor, shields, weapon, and training, these are the most effective. but also most expensive and slowest, soldiers on foot. Knights[sn82] are size 243.0 and can carry 7.0 size at 12.0 miles per day over land. Knights[sn82] attack at 12, can be retaliated against, defend at 12, and take 3 hits. Knights[sn82] are sentient. Knights[sn82] benefit in combat from land leadership.
Knights[sn82] can be made at a rate of one each day from a greatsword[wd20], a squire[sn99], a greathelm[aj32], a plate_vambrace[at23], two-hundred gold[aa00], a plate_leggings[ak70], and a plate_cuirass[an19] using leadership[sw91] at 5.
Knights[sn82] must be paid in gold[aa00], two each day, or 1.0% defect each day and turn into squires[sn99].
A long wooden pole with a pointed metal tip for two-handed combat on foot or horse. Lances[wp32] are size 6.0. A lance[wp32] may be equipped on right_hand and left_hand. When equipped, a lance[wp32] increases combat attack by 12.0.
pl. leather_boots. A pair of leather boots protecting the feet only. Leather_boots[ah55] are size 1.5. A leather_boots[ah55] may be equipped on feet. When equipped, a leather_boots[ah55] increases combat defense by 0.5.
Leather armor protecting the torso. Leather_brigandines[ay62] are size 3.5. A leather_brigandine[ay62] may be equipped on torso. When equipped, a leather_brigandine[ay62] increases combat defense by 2.0.
pl. leather_gloves. A pair of leather gloves protecting the hands only. Leather_gloves[ah62] are size 1.0. A leather_gloves[ah62] may be equipped on hands. When equipped, a leather_gloves[ah62] increases combat defense by 0.5.
A leather helmet protecting the entire head. Leather_helmets[ap24] are size 1.0. A leather_helmet[ap24] may be equipped on head. When equipped, a leather_helmet[ap24] increases combat defense by 1.0.
pl. leather_leggings. A pair of pieces of leather protecting the legs and feet. Leather_leggings[ah86] are size 3.0. A leather_leggings[ah86] may be equipped on feet and legs. When equipped, a leather_leggings[ah86] increases combat defense by 1.0.
pl. leather_vambraces. A pair of pieces of leather armor protecting the arms and hands. Leather_vambraces[ax20] are size 2.5. A leather_vambraces[ax20] may be equipped on arms and hands. When equipped, a leather_vambraces[ax20] increases combat defense by 1.0.
A long blade for single-handed combat. Longswords[wo73] are size 5.0. A longsword[wo73] may be equipped on right_hand or left_hand. When equipped, a longsword[wo73] increases combat attack by 6.0.
A type of club with a heavy head on the end of a handle used to deliver blows. Maces[wr34] are size 30.0. A mace[wr34] may be equipped on right_hand or left_hand. When equipped, a mace[wr34] increases combat attack by 5.0.
pl. militia. These are peasants which have taken up their tools as basic arms. While not very fearsome in small numbers, large mobs of them have reduced units of even the most elite solidery. Militia[sf39] are size 150.0 and can carry 50.0 size at 15.0 miles per day over land. Militia[sf39] attack at 2, can be retaliated against, defend at 2, and take 1 hit. Militia[sf39] are immobile.
These are knights which have been given a heavy warhorse to increase their travel speed, as well as further enhancing their already formadible combat effectiveness. Mounted_knights[so06] are size 1,335.0 and can carry 15.0 size at 18.0 miles per day over land. Mounted_knights[so06] attack at 15, can be retaliated against, defend at 15, and take 5 hits. Mounted_knights[so06] are sentient. Mounted_knights[so06] benefit in combat from land leadership.
Mounted_knights[so06] can be made at a rate of one each day from a knight[sn82], a warhorse[zv09], and hundred gold[aa00] using leadership[sw91] at 7.
Mounted_knights[so06] must be paid in gold[aa00], two each day, or 1.0% defect each day and turn into knights[sn82].
This is the yeomanry which forms the bulk of the human population. They are not very sophisticated and will not take orders or fight, but they provide the economic backbone of every jurisdiction. Peasants[zx58] are size 150.0 and can carry 50.0 size at 15.0 miles per day over land. Peasants[zx58] are immobile.
Peasants[zx58] can be collected at a rate of one each day. Peasants[zx58] held by non-characters generate taxes of one each six months.
pl. plate_boots. A pair of plate armors protecting the feet only. Plate_boots[ae89] are size 10.0. A plate_boots[ae89] may be equipped on feet. When equipped, a plate_boots[ae89] increases combat defense by 1.5.
pl. plate_cuirasses. Plate armor protecting the torso. Plate_cuirasses[an19] are size 25.0. A plate_cuirass[an19] may be equipped on torso. When equipped, a plate_cuirass[an19] increases combat defense by 6.0.
pl. plate_gauntlets. Plate armors protecting the hands only. Plate_gauntlets[az29] are size 8.0. A plate_gauntlets[az29] may be equipped on hands. When equipped, a plate_gauntlets[az29] increases combat defense by 1.5.
pl. plate_leggings. A pair of plate armors protecting the legs and feet. Plate_leggings[ak70] are size 20.0. A plate_leggings[ak70] may be equipped on feet and legs. When equipped, a plate_leggings[ak70] increases combat defense by 3.0.
A pair of plate armors protecting the arms and hands. Plate_vambraces[at23] are size 15.0. A plate_vambrace[at23] may be equipped on arms and hands. When equipped, a plate_vambrace[at23] increases combat defense by 3.0.
pl. quarterstaves. A short staff used as a pole weapon. Quarterstaves[wl70] are size 4.0. A quarterstaff[wl70] may be equipped on right_hand or left_hand. When equipped, a quarterstaff[wl70] increases combat attack by 5.0.
A long, pointed blade for single-handed combat. Rapiers[wm63] are size 3.5. A rapier[wm63] may be equipped on right_hand or left_hand. When equipped, a rapier[wm63] increases combat attack by 6.0.
A medium-length, curved blade for single-handed combat. Sabres[wl93] are size 4.5. A sabre[wl93] may be equipped on right_hand or left_hand. When equipped, a sabre[wl93] increases combat attack by 5.0.
These soldiers forms the backbone of soldier training. While they do not fight better than regular soldiers, they can assist in the training of basic soldier types. Sergeants[sn33] are size 150.0 and can carry 50.0 size at 15.0 miles per day over land. Sergeants[sn33] attack at 2, can be retaliated against, defend at 2, and take 1 hit. Sergeants[sn33] are sentient. Sergeants[sn33] benefit in combat from land leadership.
Sergeants[sn33] can be made at a rate of one each day from a soldier[sn80] and fifty gold[aa00] using leadership[sw91] at 3.
Sergeants[sn33] must be paid in gold[aa00], one each four days, or 1.0% defect each day and turn into soldiers[sn80].
A short blade for single-handed combat.. Shortswords[wa51] are size 3.0. A shortsword[wa51] may be equipped on right_hand or left_hand. When equipped, a shortsword[wa51] increases combat attack by 5.0.
A leather pouch designed to hurl projectiles. Slings[wc88] are size 1.0. A sling[wc88] may be equipped on right_hand or left_hand. When equipped, a sling[wc88] increases combat attack by 3.0 and prevents retaliation.
pl. slingmen. These are soldiers equipped with bows which enhances their combat attack, but not their defense. Slingmen[sb32] are size 151.0 and can carry 49.0 size at 15.0 miles per day over land. Slingmen[sb32] attack at 3, cannot be retaliated against, defend at 2, and take 1 hit. Slingmen[sb32] are sentient. Slingmen[sb32] benefit in combat from land leadership.
Slingmen[sb32] can be made at a rate of one each day from a sling[wc88], a soldier[sn80], and ten gold[aa00] using up to 10 of sergeant[sn33], staff_sergeant[si91](2.0x), master_sergeant[st01](3.0x), and sergeant_of_the_army[su34](4.0x) and leadership[sw91] at 2.
Slingmen[sb32] must be paid in gold[aa00], one each a week, or 1.0% defect each day and turn into soldiers[sn80].
These are the soldiers who have passed basic training, but not yet received any advanced equipment or instruction. Most advanced soldiers can be made, directly or indirectly, from soldiers. Soldiers[sn80] are size 150.0 and can carry 50.0 size at 15.0 miles per day over land. Soldiers[sn80] attack at 2, can be retaliated against, defend at 2, and take 1 hit. Soldiers[sn80] are sentient. Soldiers[sn80] benefit in combat from land leadership.
Soldiers[sn80] can be made at a rate of one each day from a worker[zp69] and ten gold[aa00] using up to 10 of sergeant[sn33], staff_sergeant[si91](2.0x), master_sergeant[st01](3.0x), and sergeant_of_the_army[su34](4.0x) and leadership[sw91] at 1.
Soldiers[sn80] must be paid in gold[aa00], one each two weeks, or 1.0% defect each day and turn into workers[zp69].
A single-handed pole weapon consisting of a wooden shaft with a pointed metal head. Spears[ww49] are size 9.0. A spear[ww49] may be equipped on right_hand or left_hand. When equipped, a spear[ww49] increases combat attack by 5.0.
pl. spearmen. These are soldiers equipped with longswords which enhances their combat attack and, in particular, their combat defense. Spearmen[sd71] are size 159.0 and can carry 41.0 size at 15.0 miles per day over land. Spearmen[sd71] attack at 3, can be retaliated against, defend at 4, and take 1 hit. Spearmen[sd71] are sentient. Spearmen[sd71] benefit in combat from land leadership.
Spearmen[sd71] can be made at a rate of one each day from a soldier[sn80], ten gold[aa00], and a spear[ww49] using up to 10 of sergeant[sn33], staff_sergeant[si91](2.0x), master_sergeant[st01](3.0x), and sergeant_of_the_army[su34](4.0x) and leadership[sw91] at 2.
Spearmen[sd71] must be paid in gold[aa00], one each a week, or 1.0% defect each day and turn into soldiers[sn80].
These are young soldiers which have been squired. They are expensive and only their defensive capabilities have been enhanced by the shield they are given. Squires[sn99] are size 165.0 and can carry 35.0 size at 15.0 miles per day over land. Squires[sn99] attack at 2, can be retaliated against, defend at 6, and take 2 hits. Squires[sn99] are sentient. Squires[sn99] benefit in combat from land leadership.
Squires[sn99] can be made at a rate of one each day from a soldier[sn80], hundred gold[aa00], and a steel_shield[aj28] using leadership[sw91] at 3.
Squires[sn99] must be paid in gold[aa00], one each day, or 1.0% defect each day and turn into soldiers[sn80].
A steel shield to be held in one hand during combat. Steel_shields[aj28] are size 15.0. A steel_shield[aj28] may be equipped on right_hand or left_hand. When equipped, a steel_shield[aj28] increases combat defense by 5.0.
pl. swordsmen. These are soldiers equipped with longswords which enhances their combat defense and attack. Swordsmen[sa81] are size 155.0 and can carry 45.0 size at 15.0 miles per day over land. Swordsmen[sa81] attack at 3.5, can be retaliated against, defend at 3.5, and take 1 hit. Swordsmen[sa81] are sentient. Swordsmen[sa81] benefit in combat from land leadership.
Swordsmen[sa81] can be made at a rate of one each day from a soldier[sn80], a longsword[wo73], and ten gold[aa00] using up to 10 of sergeant[sn33], staff_sergeant[si91](2.0x), master_sergeant[st01](3.0x), and sergeant_of_the_army[su34](4.0x) and leadership[sw91] at 2.
Swordsmen[sa81] must be paid in gold[aa00], one each a week, or 1.0% defect each day and turn into soldiers[sn80].
A wooden handle ending in a blunt metal head for single-handed combat. Warhammers[wt66] are size 2.0. A warhammer[wt66] may be equipped on right_hand or left_hand. When equipped, a warhammer[wt66] increases combat attack by 6.0.
Armored horse trained to battle. Warhorses[zv09] are size 1,100.0 and can carry 250.0 size at 18.0 miles per day over land. Warhorses[zv09] attack at 5, can be retaliated against, defend at 5, and take 2 hits.
An untamed horse. Wild_horses[zp79] are size 1,000.0 and can carry cumulatively 10.0 size at 25.0 miles per day and 190.0 size at 20.0 miles per day over land.
A wooden shield to be held in one hand during combat. Wooden_shields[ah48] are size 10.0. A wooden_shield[ah48] may be equipped on right_hand or left_hand. When equipped, a wooden_shield[ah48] increases combat defense by 3.0.
The basic unskilled laborer is a useful aide for many tasks not requiring advanced training and can be trained as a soldier or various types of specialist. Workers[zp69] are size 150.0 and can carry 50.0 size at 15.0 miles per day over land. Workers[zp69] attack at 1, can be retaliated against, defend at 1, and take 1 hit. Workers[zp69] are sentient.
Workers[zp69] must be paid in gold[aa00], one each a month, or 100.0% defect each day and turn into peasants[zx58].
The number of items a unit holds are integers and all processes take place on a day-by-day basis. But some processes have daily rates lower than 1/day and most processes can occur at fractional rates like 3.25/day. In order to reconcile this tension, Ascendancy uses stochastic rounding.
Stochastic rounding consists of randomly rounding the daily progress to an integer quantity. The chance of rounding up or down depends on the fractional part of the rate: rates close to the nearest lower integer are usually rounded down; rates closer to the nearest higher integer are usually rounded up. The net effect is that, on average and over the long run, the effective integer rate will approximate the fractional rate, but on a day-to-day basis there is no guarantee.
For example, a character who can MAKE swords at a pace of 3.25 per day would, in fact, produce 3 swords three-quarters of the days and 4 swords one quarter of the days. This works out to an average of 3.25 swords per day, but the exact number cannot be predicted. So, after four days, the character could not count on having made exactly 13 (3.25 × 4) swords; it could be as few as 12 or as many as 16.
For another example, a character performing a USE with a stochastic rate of 1/30 would every day have a chance of success of 1 in 30. On average that means that the character will spend 30 days before succeeding. But the character could succeed on the first day or require many months to achieve success.
The universal currency of Ascendancy is the gold coin, a small store of value of questionable content, but universal acceptability.
The uses of gold are myriad. Gold is necessary to RECRUIT new characters to your faction and, when you already have many character, the price of an additional one can be astronomic. Most of your workers, fighters, and other specialists will demand regular payment in gold or they will defect or degrade in performance. All trade commands require or obtain gold. And, because gold has so many other uses, it is a useful lubricant for interactions with other players or even AI factions.
The principal sources of gold are two: First, you can hunt monsters or even rob other players. Second, you can earn tax revenues by holding peasants (and other tax-paying items) in non-character units you control, such as provinces or cities. These will generate gold every day, if usually in small amounts. Peasants will even increase in number until their density reaches 100 per soil in the unit. You can affect the amount of gold above or below the base tax rate by setting taxes for your units. But beware that high taxes will cause peasants to migrate to nearby less predatory jurisdictions or even revolt.
Characters may have skills and each of a character’s skills has a level. A character’s skills determine whether he can function as a powerful mage, a warlord, a high priest, a master thief, any combination thereof, or is just a plain old bungler. Each skill typically has an ID consisting out of two letters followed by two digits
All character skill levels start at 0 and may be increased by using the STUDY command. Acquiring lower levels of skills is usually fairly fast, but higher levels may require much time and effort. Learning can be sped up by being adjacent to a character with a higher level of the skill who is teaching, owning books relevant to the skill, or being inside a unit with such books (think of it as a library or university). There may also be other ways to speed up study.
Some skills require other skills at as prerequisite. For example, the assassination skill may require the rogue skill at +2. That means that until the character has brought its rogue skill up to level 3, they cannot acquire the assassination skill even at level 1. Learn assassination to level 2 would require first bringing up the rogue skill to level 4, etc. Some skills may have multiple prerequisites, all of which must be fulfilled to advance, or alternative prerequisites, any of which must be met.
The use and effect of skills varies from skill to skill. Some skills, such as combat, will automatically be used in appropriate situations. Some skills, such as poisoning a unit, may be exercised by the USE command with parameters. Other skills, such as casting a fireball, may be set as active with the USE command and will then trigger in the appropriate circumstances (e.g., if the mage finds himself in combat). A character can execute the EXAMINE command on one of their current skills to find out more about how to use it.
There the four basic skill trees are related to classic fantasy classes: warrior, mage, priest, and rogue. But not all skills fall into one of these categories. Some, such as teaching and beast-mastery, are open to all regardless of their level in any of the basic skill trees. Others yet may require levels in multiple different skill trees. The only way to learn more is to experiment and observe.
Common generally-known skills include:
USEing this skill allows all adjacent characters who can observe you to STUDY all the skills you have faster. Teaching also sometimes gives you a book idea.
This skill can be USEd.
This basic skill grants access to many skills, known as miracles. Among these miracles are many forms of curing, protection, but also some combat options and many other useful capabilities. USE this skill to select your god, such as the AllFather or the AllMother. Other gods may grant you skill bonuses. Without a god, no miracles will work. You can forsake your god at any time, but the higher your level, the longer you can expect it to take. USE this skill without an argument to preach your current god to any adjacent observers.
This skill can be USEd.
This passive skill enhances the combat ability of your soldiers (and most derived advanced fighters). For each level, they gain 20% to their attack and defense ratings. The maximum number benefited in combat starts at 10 and doubles for every level thereafter. If you have more fighters subject to leadership than this number, the effect is diluted over their numbers. The description of any fighter will state whether it is subject to leadership. You also have a land travel speed bonus.
This skill allows you to observe what otherwise would be hidden, effectively counter-acting so many levels of the rogue skill. It also increases the accuracy of LOOK reports.
This skill can be USEd.
This skill can be USEd.
This is a passive skill that increases the number of catalysts you can use for MAKE or COLLECT.
This basic skill is concerned with everything relating to breaking people and things by violent means. Among the skills dependent on it are skills permitting sieges, advanced soldier training, and leadership on land and at sea. The skill itself has a passive effect of enhancing your personal attack and defense ratings in combat and granting extra hits. A well-equipped high-level warrior is one of the most powerful fighters in the world, fully the match for a mature dragon or demon lord and second only to a mature dragon or demon lord character who also is a high-level warrior. USE this skill to engage in battle during combat.
This basic skill hides you when sneaking. Hidden characters may not show up in LOOK reports and can GIVE or TAKE from others, or even MOVE into them, even though they would not otherwise allow it. This effect is greatly diminished by the size of the rogue's stack and the target's observe capability. USE of this skill without argument toggles sneaking; give the argument ON or OFF to set your sneaking state. This skill also grants access to all sorts of other sneaky, underhanded, mean, nasty, and downright disreputable skills.
This skill can be USEd.
This basic skill enables many skills, known as spells. Among these spells are different types of offensive magic as well as many other powerful spells.
Some skills are combat skills. USEing them directly usually only takes a day, but only primes the unit to use that skill whenever it gets to attack in combat. USEing another combat skill switches the character to the new combat skill.
At the heart of playing Ascendancy are commands. Each controlled unit has an list of commands (or orders) which it will execute in sequence. Almost everything that happens in the world is the result of some unit executing some command.
The sequence of commands for each unit is Ascendancy’s way of ensuring that not everything happens at once. Each command takes a specific amount of time measured in days. These fall into three categories:
An instant command takes no time at all. Whenever it is a unit’s turn all its instant commands are executed right away, only stopping when the unit’s orders are empty or it hits a day command.
A single-day command always takes a unit exactly one day. They may succeed or fail, but—regardless of outcome—they are dropped off the orders at the end of the day.
A multi-day command takes at least one day, but can take an indefinite period. If a multi-day command fails (for example, because the target of an attack is nowhere to be seen or the unit has run out of raw materials for its production), it just drops off the orders at the end of the day. Another reason a multi-day command may end is that it completed (for example, the enemy was defeated or the last tree in the area was chopped down).
Finally, multi-day commands accept a number of days as their optional first parameter. A multi-day command will end when it has tried the command for this many days. If no day parameter is given, or it is specified as 0, the command just keeps repeating until it either fails or succeeds (which for some commands, such as STUDY, may be never). Multi-day commands with a given number of days will never take longer than that; if incomplete at the end of that period, the command will still just end.
Single-day and multi-day commands are collectively referred to as day commands. All day commands always take at least one day, even if the parameters to them are not appropriate.
Commands which only change the unit’s own status or attitude tend to be instant. Commands to interact with other units tend to be single-day. Commands which actually do some work tend to be multi-day.
Stack commands occupy not only the active unit, but also all other units within the active stack. None of the units in the stack can not execute day commands until the command finishes.
Faction commands may be issued by factions as well as units. Faction-only commands may only be issued by factions and not units.
In the description of commands, the unit executing the command is referred to as the active unit (or a faction executing a faction command, active faction). The active unit and all the units it directly or indirectly holds are called the active stack.
|MOVE||destination||single-day, character, stack|
|Move the active stack into the destination stack|
Moving to the destination unit may involve successively moving out of each the active unit’s parent and then into each parent of the destination unit until the active unit ends up as the destination unit’s child.
For each unit moved into or out of, the active unit needs permission to enter or leave respectively. See attitudes and OPEN.
The active unit exposes itself to attacks of opportunity from units it enters, leaves, or passes by. See attitudes.
The active unit cannot move into a destination within its own stack.
A stack holding immobile items (like walls) cannot move.
A stack without immobile items can perform any otherwise legal MOVE in a single day, regardless of size, carrying capacity, or speed. Cf. TRAVEL.
If given multiple destinations, they will be tried in order until one becomes possible. If a faction is given, the first sibling which flies that faction's banner is tried. If INCOGNITO is given, the first sibling without a banner is tried. If ALL is given, the first sibling, period, is tried.
MOVE is a stack command. All other units within the active stack are occupied by the command and will not execute day commands until the command finishes.
Only characters may move.
|MOVETO||destination||single-day, character, stack|
|Move the active unit’s stack adjacent to the destination unit|
This command has the same effect and restrictions as the MOVE command except that, if the active unit not already in the destination’s stack, it moves adjacent to the destination (i.e., becomes its sibling). This is useful if the active unit wishes to execute some other action requiring it to be adjacent to the destination, but does not necessarily have permission to enter the destination.
|TRAVEL||[destination|direction]*||single-day, character, stack|
|Travel to the destination connected to the parent|
The active unit travels to the destination connected to tis parent via land, sea, or other routes.
If the active unit has turned on AUTOMOVE, it will move out of its current parent successively until it reaches the provinces, if necessary.
Travel time depends on the distance along the route, the weight and carrying capacity of the items carried by the stack, as well as their speed along the chosen mode of transportation.
Instead of a destination, the command may specify a direction (e.g.,
southwest). In this case, the active stack will travel along whatever accessible route closest to the specified direction, but less than 45 degrees off that direction.
If TRAVEL is given a series of destinations or directions, it will attempt them in order and execute the first one that works.
If there are multiple routes from the current province to the destination (such as via land or via river), the active unit will always choose the one that gives gets it to the destination the fastest (which depends on the size, the carrying capacity, and means of transportation of all units in the stack).
Traveling stacks will automatically pack themselves so as to maximize their possibility (and speed) of movement over the chosen mode of transportation:
For example, a character with two workers, a canoe, and another character stacked inside it will TRAVEL on land using the two characters’ and workers’ speed and carrying capacity, with the canoe only providing size. If that same stack attempted to TRAVEL via river, it would use the canoe’s carrying capacity and speed with the characters and workers only providing size.
For another example, a character with some items and a horse traveling over land will travel at the horse’s speed if the character, the items, and the horse’s size are no larger than the horse’s carrying capacity. If the size is too large, the stack will travel at the character’s lower speed with both the character and the horse providing carrying capacity.
For large or important TRAVELs it is advisable to have some spare carrying capacity available beyond that seemingly required. It is always possible that a friend gave the active unit some extra items, that a hidden rogue sneaked into stack, or some extra baggage was added via some other means. If the stack had just barely enough carrying capacity for its intended size, this extra size could cause the TRAVEL to fail. As, apart from gifts from friendly units, the total size of these extra items is fairly limited, prudence only requires a similarly small amount of spare carrying capacity.
A stack holding immobile items (like walls) cannot travel.
TRAVEL is a single-day command, but marks the units in the active stack as traveling until they arrive. Traveling units cannot execute day commands until they arrive.
TRAVEL is a stack command. All other units within the active stack are occupied by the command and will not execute day commands until the command finishes.
Only characters may travel.
|ATTACK||[days] defender||multi-day, character, stack|
|Initiate a full battle between the active stack and the defender|
As even a full battle does not guarantee that either side is wiped out. See combat. The ATTACK keeps repeating until either side destroyed or the given number of days runs out.
For unit attacker to attack unit defender, they must be adjacent (after a potential AUTOMOVE), but who else participates, the effective fortifications, and the location of the fight (which determines how many fighters on each side can participate) depends on how they are adjacent:
- If attacker and defender are siblings, the attacker’s entire stack will fight the defender’s entire stack. Both sides benefit from their fortifications. The location is their common parent. The parent will also join the defender’s side if it is at least friendly to the defender and not super-friendly to the attacker.
- If the attacker is a child of the defender, the attacker’s entire stack will fight the defender and all other children of the defender which are at least friendly to the defender. Only the attacker benefits from its fortifications. The location is the defender.
- If the attacker is the parent of the defender, the attacker and all its other children which are at least friendly to the attacker will fight the defender’s entire stack. Only the defender benefits from its fortifications. The location is the defender.
ATTACK is limited by the CAUTION setting. If the active unit has turned on caution and the target stack appears too strong, the attack will fail without any combat.
ATTACK is a stack command. All other units within the active stack are occupied by the command and will not execute day commands until the command finishes.
Attacking a captive character of the active unit is a special case. It does not result in combat, always succeeds after one day, and results in the captive dying.
If given multiple targets, they will be tried in order until one becomes possible. If a faction is given, the first sibling which flies that faction's banner is tried. If INCOGNITO is given, the first sibling without a banner is tried. If ALL is given, the first sibling, period, is tried.
Battle is chaotic and random. It is possible—if quite unlikely indeed—for a single worker to defeat a hundred dragons, even in a skirmish. So remember that whenever you ATTACK, you are placing your fate in the hands of the Random Number Gods. If you are prudent you will structure your following commands taking into account contingencies such as you (or your companions) having been killed or captured, even if you think the odds are in your favor. Or—at least—try to execute your ATTACKs late in the turn so that you will have an opportunity to respond to contingencies the next turn.
A stack holding immobile items (like walls) cannot ATTACK.
Only characters may ATTACK.
|GIVE||recipient [item quantity|unit]*||single-day, character, stack|
|Transfer the specified items (in the given quantities) and units from the active unit to the recipient unit|
The recipient unit must be adjacent to the active unit. But see AUTOMOVE.
If the quantity specified for an item is 0 or omitted, all items of that type are given to the recipient unit. If the quantity is preceded by an equal sign (=), the active unit will, if possible, GIVE a quantity sufficient that it ends with the stated quantity.
If a captive child unit of the active unit is given as parameter, it becomes a captive child unit of the recipient.
If the recipient unit is controlled, the recipient unit must be at least have a friendly attitude towards the active unit or the command fails. But see OPEN. Anybody can GIVE to an uncontrolled unit.
Giving intelligent creatures (such as soldiers or workers) to an uncontrolled unit causes it to adopt the faction of the active unit.
GIVE is a stack command. All other units within the active stack are occupied by the command and will not execute day commands until the command finishes.
Non-transferable and immobile items (such as walls or buildings) cannot be given.
Only characters may give.
|TAKE||source [item quantity|unit]*||single-day, character, stack|
|Transfer the given items (in the given quantities) and units from the source unit to the active unit|
The source unit must be adjacent to the active unit. But see AUTOMOVE.
If the quantity specified for an item is 0 or omitted, all items of that type are transferred from the source unit. If the quantity is preceded by an equal sign (=), the active unit will, if possible, TAKE a quantity sufficient that it ends with the stated quantity.
If a captive child unit of the source unit is given as parameter, it becomes a captive child unit of the recipient.
If the source unit is controlled, it must have a super-friendly attitude towards the active unit (e.g., be a member of the same faction) or the command fails. Anybody can take from uncontrolled units.
It is possible to TAKE a whole sibling of the active unit if the sibling stack has no immobile items and the sibling is uncontrolled or super-friendly (i.e. a member of the same faction as the active unit or uncontrolled). If successful, the sibling becomes a child of the active unit.
TAKE is a stack command. All other units within the active stack are occupied by the command and will not execute day commands until the command finishes.
Taking all the items of a non-character unit will cause it to dissolve.
Non-transferable and immobile items (such as walls or buildings) cannot be taken.
Only characters may take.
|DROP||[item quantity|unit]*||instant, unit|
|Drop the given items (in the given quantities) and units from the active unit to its parent|
If a child unit (captive or not) of the active unit is given as parameter, it is set free as a child of the parent unit.
The attitude of the parent unit towards the active unit does not matter.
If the quantity specified for an item is 0 or omitted, all items of that type are dropped. If the quantity is preceded by an equal sign (=), the active unit will, if possible, DROP a quantity sufficient that it ends with the stated quantity.
Items dropped while traveling are destroyed. Units dropped while traveling try to continue along the same path at their own pace.
Even immobile items (such as walls or buildings) may be dropped. Dropped non-transferable items disappear.
Any controlled unit may drop.
|Equip the specified items|
This command allows you to set which items, such as weapons, armor, or various magical paraphernalia, the character has equipped. Many items need to be equipped to be used in combat or otherwise be effective.
A character may equip up to one of each item he or she holds, up to the limit of equipment slots depending on the type of character. For humans, there are equipment slots for the head, the neck, the torso, the legs, the arms, the left hand, the right hand, the left index finger, the left middle finger, the right index finger and the right middle finger. Which type of equipment slot an item needs depends on the item (and can be seen using EXAMINE). For example, chest armor pieces only go into the torso slot, while rings go into any finger slot.
Into which of the permissible slots an item goes does not matter and all characters with multiple hands are ambidextrous.
Some items require more than one equipment slot. For example, equipping a two-handed weapon uses up both the left hand and the right hand slot.
If a character is ordered to equip incompatible items (for example, both a two-handed weapon and a shield), he or she will make the best effort to equip as many items as possible, but which will fail is not generally predictable.
Each EQUIP must specify all equipment you want to equip. Items not listed are unequipped. To un-equip all items, just give the command without any arguments.
Only characters may EQUIP.
|RECRUIT||[days] target||multi-day, character, stack|
|Recruit the target character to the active unit’s faction|
This command is the principal means of adding characters, beyond the initial starting character, to your faction.
Recruitment costs gold, starting cheaply and becoming exponentially more expensive. The base recruitment cost is set per game (by default, 10 gold) and doubles for each character currently in the recruiting faction. So recruiting a second character beyond the initial would cost 10 × 21 (or 20) gold. Recruiting a new character for a 10-character faction would cost 10 × 210 (or 10,240) gold. Recruiting an additional character to a 20-character faction would cost 10 × 220 (or 10,485,760) gold—better bring over a hundred wagon loads of gold.
The target character must be adjacent to the active unit. But see AUTOMOVE.
Recruiting characters without a faction (usually recognizable by flying the unaffiliated banner) is easy and usually succeeds in one day.
There may be magical or other means to recruit affiliated characters, but—if they exist at all—they are rare, expensive, and possibly temporary. Regardless, any recruitment, whether coercive, magical, or a return to the original faction, always incurs the full recruitment cost.
A RECRUIT command only terminates when the recruitment succeeds, the specified number of days runs out, or attempts would be futile (i.e., the chance of recruitment is zero).
It is ordinarily a good idea to follow each RECRUIT command with an ORDER command to wipe out any pre-existing commands and put the new member of the faction to work right away.
If given multiple targets, they will be tried in order until one becomes possible. If a faction is given, the first sibling which flies that faction's banner is tried. If INCOGNITO is given, the first sibling without a banner is tried. If ALL is given, the first sibling, period, is tried.
RECRUIT is a stack command. Not only the active unit, but all units within its stack, are occupied by it and will not execute day commands until the command finishes.
Only characters may RECRUIT.
|MAKE||[days] item||multi-day, character|
|Make new items from ingredients|
This is a command of great and various uses with the only commonality that they transform some items in the unit’s possession into some other item. Examples include converting stone or wood to stone or wooden walls, iron ore to steel, workers into soldiers, steel into swords, soldiers and swords into swordsmen, bullion into gold, etc.
The parameter to MAKE is the item to be made. Each item has a specific recipe, either described in the items section or to be discovered during play, listing the materials needed to make it and their ratios. These materials are consumed and the command terminates when the raw materials are exhausted.
Most recipes also have—in addition to the product and the ingredients—catalysts. Catalysts are not consumed but can greatly speed up the process of conversion. A typical example of a catalyst are workers which speed up most basic recipes. Each worker the character has will do once over the same work the character could do by itself. Most catalysts have a limit to how many may be beneficially employed. Moreover, some recipes also have advanced catalysts (think specialist workers) each of whom can down several times as much as a basic catalyst.
How many catalysts a character can use may depend on the character’s skills. If a character has more catalysts than he or she can use, it will use the best catalysts first.
Production using MAKE is stochastic.
Only characters may make.
|COLLECT||[days] item||multi-day, character|
|Gather items from the active unit’s parent|
This command, like its cousin MAKE, is of great and various uses with the commonality that they all collect some item from the active unit’s parent. Examples include harvesting wheat, mining ore, felling trees, recruiting workers, or hunting wildlife.
The parameter to COLLECT is the item to be collected from the parent unit. The item ending up in the unit’s hands may be the same item or some other item related to the collected item. (This is unlike MAKE where the parameter specifies the resulting item.) For example, COLLECTing peasants from the parent unit will result in workers for the unit. (This is one of the most basic and useful collection recipes.)
COLLECT may, in addition to the products the unit receives, create or transform items in the parent unit. For example, COLLECTing trees will result in wood for the active unit; it will also turn trees in the parent unit into tree stumps (which over the long run may turn back into trees).
Like with MAKE, COLLECTing specific items may benefit from catalysts—workers for many tasks with special bonuses for specialists for some tasks—and is stochastic.
Only characters may collect.
|USE||[days] skill parameters*||multi-day, character|
|Employ a skill|
This command allows a unit to exercise a skill it possesses. The exact effects, duration, or parameters of the USE commands varies greatly from skill to skill. For more information on the uses, if any, of a particular skill, EXAMINE the skill.
Some carried items and magical effects give boni and mali to a unit’s effective skill level. For purposes of active and passive uses, units are deemed to have their effective skill level.
Only characters may use (or even, have) skills.
|Receive report on the current province|
This command provides a report on the current state of the unit’s environs.
The report includes the unit’s current province and any units stacked therein which are at least the size of a typical adult human. For every unit included, the report also provides a list of all items carried which cumulatively at at least the size of a typical adult human.
Units with the rogue skill at sufficiently high level and sufficiently small size may be hidden. Units with sufficiently high observe skill who are actively LOOKing may be able to detect even hidden sneakers.
Every controlled unit receives the equivalent of an automatic free LOOK (without any observe) at the end of every turn. The main purposes of the express LOOK command are to catch a glimpse of (a) units just passing through during the turn, (b) provinces the active unit passes through, and (c) get a more thorough look by a character with observe skill.
Only characters may look.
|Examine an item or skill|
This command gives a brief report on the properties of an item or skill.
For an item, the report would typically include its name, ID, size, attack or defense value (if a fighter), its speed and carrying capacity along different modes of transportation, other relevant information, and some flavor text. It may also include recipes for collecting or making this particular item or what can be made of it. Characters may EXAMINE items they own or publicly known items, such as those listed in this manual. Character with high observe skill may also be able to examine items held by adjacent units.
For a skill, the report typically include the name, ID, its benefits and USEs at the current level, and some flavor text. It may also include skills it depends on or which depend on it and titles which the current level makes available. Characters may only EXAMINE skills they have (or publicly known skills, such as those listed in this manual) and the information will be limited to the effects up to the current level.
Only characters may examine.
|STUDY||[days] skill||multi-day, character|
|Learn or improve a character’s skill|
This command is the principal means of improving a character’s skills. A character may study any skill for which the name or ID is known and the prerequisites for the next level met. Reaching the first level of a skill generally requires 28 days of study per level sought.
Characters who hold books that teach the appropriate skill at the sought-after levels will learn much faster. Moreover, characters equally benefit from books held by their parent unit (think of it as a library or university).
Characters which are adjacent to another character that has the skill at a higher level and uses the teaching skill also learn much faster.
Benefits from teaching and different relevant books are cumulative. However, only the best teacher and one copy of each book will help.
Unaided study—essentially original research—is at a disadvantage of 20%, cumulatively, for each level sought. So, while studying from level 9 to level 10 with basic instruction takes 280 days, without any books or teachers, would require 280×1.210 days or almost five years of continuous study in game time. Meanwhile, reaching level 10 from level 9 with a level 10 teacher (i.e. one that has both the sought skill and teaching at level 10) would only take about three months (or three turns in a typical game). That is why high-level books and teachers are prized. Of course, great masters of a skill are often too busy with more pressing matters to instruct beginners.
Every time a character reaches a new level in a skill, he or she receives a report on the skill (the equivalent of a free, instant EXAMINE).
For purposes of STUDY (as well as teaching), only a unit’s base skill level matters. Boni and mali to effective skill level are ignored.
Skill level is a fractional number which accumulates little-by-little with every day of study. However, fractional progress to the next level does not confer any benefits. STUDY is not stochastic.
Only characters may study.
Waiting unit does nothing until specified days have expired. If no number of days is specified, the unit will wait forever (or until it is given different ORDERs).
Any controlled unit may wait.
|CREATE||newunit [item quantity|unit]*||single-day, character, stack|
|Create a new unit|
A new unit is created inside the active unit. The new unit will be given the stated items and units. See GIVE.
The ID of the new unit must be taken from the faction’s ID pool, allocated but unassigned IDs listed on each turn report.
After creation, the active unit may wish to immediately issue commands (such as NAME) to the newly created unit using ORDER.
Newly created unit should always be given at least one item because non-character units without any items dissolve.
Only characters may create new units.
|ORDER||target commands* END||instant, unit, faction|
|Replace target’s commands|
The target’s current orders—which must be super-friendly to the active unit—are replaced with the given new orders.
You can ORDER any units of your own faction from anywhere. To order somebody else, who for some reason is super-friendly to you, you must be adjacent to them.
The ORDER is a multi-line command with the commands to be given listed on subsequent lines and terminated by an END line. For example:
ORDER Cault GIVE Cache gold 1 STUDY magic END MOVE Mathrolen
These commands would instruct the unit Cault to give one gold to the unit Cache and then study magic indefinitely. The active unit would then immediately move to the Mathrolen province without waiting for Cault to finish its orders.
Indentation of the command lines is visually helpful for players, but ignored by the game which only goes by the END line.
Factions and any controlled unit may order other units.
|ORDERFIRST||target commands* END||instant, unit, faction|
|Add commands to the beginning of the target’s orders|
This command is similar to ORDER, except that—rather than replacing the target’s orders—it puts the new orders at the beginning of the target’s current orders.
|ORDERLAST||target commands* END||instant, unit, faction|
|Add commands to the end of the target’s orders|
This command is similar to ORDER, except that—rather than replacing the target’s orders—it appends the new orders at the end of the target’s current orders.
|POST||… END||single-day, character|
|Post an article to the Ascendant Times|
This command supplies an anonymous article to be posted to the game’s Ascendant Times, a newspaper which is assembled each turn and made available to all active players.
POST is a multi-line command terminated by the END keyword. For example:
POST Wood is available for sale in the town of Carlock at *unbelievably* low prices! Each wood is offered at only 0.15 gold! Only while quantities last! CHEAP! CHEAP! CHEAP! END
Articles should be in-character. To discuss the game out-of-character, use the mailing lists.
Articles should not be vulgar, juvenile, trademarked, anachronistic, or in violation of the laws of any First World jurisdiction. General badinage—including threats and curses as long as they are unambiguously in-character—is not only allowed, but encouraged.
Pieces up to a page or so in length are allowed, as long as they are not repeatedly posted. So are commercial appeals if they are either one-off or no more than a few lines each turn.
In an exception to the No Anachronism rule, it is permissible to unobtrusively include means of more direct and expeditious contact, such as e-mail addresses, IM contact information, or even telephone numbers.
Articles which do not meet these standards may be deleted by the editor.
Only characters may post.
|recipient* … END||instant, unit, faction|
|Mail a message to the recipients|
This command sends a message, identified by the name and ID of the active unit or faction, to the recipients unit. The faction of the recipient unit will receive this message with their next turn report.
MAIL is a multi-line command terminated by the END keyword. For example:
MAIL Secret_Army Who are you and what are you doing in my province? Leave, fly your banner, or face my wrath! To discuss, email HumungousMage@gmail.com. END
The standards of appropriateness for POST apply to the contents of the MAIL command as well.
Any unit or faction may send mail to any unit or faction.
Ascendancy has local, daily, anonymous, auction-based markets in all mobile items. The market is local because only sibling units—not parents or children—can trade with each other. Daily means that all trades are resolved at the end of every game day. Anonymity means that the parties to trades do not know their counter-parties and may even engage in doux commerce with enemies. The market is auction-based because every transaction occurs at the market clearing price for that item, location, and day.
Underlying all trading activity is the powerful, but tricky, TRADE command. Most players, for most purposes, should instead start their commercial endeavors using the much more straight-forward BUY and SELL commands.
|BUY||item quantity [price]||single-day, character|
|Buy up to quantity of items at up to price|
This command seeks to buy the specified quantities of the specified items by trading with the active unit’s siblings. No item will be bought at above the specified price. The actual price at which the item is bought may be lower than the specified prices, but will be no higher.
If no price is specified, the items will be bid for at any price, up to available funds.
As success depends on finding a counter-party in the same location willing to trade the item, it is important to only attempt to BUY at locations, such as cities, known to have active markets for the item or by prior arrangements with another party willing to buy.
Note that the specified price is for the first item you buy. If bidding for multiple items, the last one will be bid at a price 10% lower and the other items at prices in between. So, if you want to be sure to buy all of quantity, specify a price at least 10% higher than where you think the market will clear.
Only characters may buy.
|SELL||item [quantity [price]]||single-day, character|
|Sell up to quantity of items at least at price|
This command seeks to sell the specified quantities of the specified items by trading with the active unit’s siblings. No item will be sold at below the specified price. The actual price at which the item is sold may be higher than the specified prices, but will be no lower.
If no quantity is specified, the unit will sell all of the specified item. If no price is specified, the items will be offered at 0.0 gold.
As success depends on finding a counter-party in the same location willing to trade the item, it is important to only attempt to SELL at locations, such as cities, known to have active markets for the item or by prior arrangements with another party willing to buy.
Note that the specified price is for the last item you sell. If offering multiple items for sale, the first one will be offered at a price 10% higher and the other items at prices in between. So, if you want to be sure to sell all of quantity, specify a price at least 10% lower than where you think the market will clear.
Only characters may sell.
|TRADE||[days] [item [price quantity]+]*||multi-day, character|
|Make a market in one or more items|
The TRADE command underlies all commerce in Ascendancy and allows the implementation of sophisticated trading strategies. However, its details are complex and full of traps for the unwary. Beginning players should stay away from this advanced subject and stick to BUY and SELL instead.
After the usual day parameter (indicating how many days to trade), the parameters for the command are a list of pairs of item IDs (or names) and their demand curves which specify how many of the item the trader wishes to own at any given price.
A demand curve is specified by a series of pairs of increasing prices and decreasing quantities (due to the law of diminishing marginal utility). For prices between any set of given prices the quantity demanded is the linear (i.e., straight line) interpolation between the neighboring price/quantity pairs. For prices lower than the first price, the quantity demanded in the first quantity; for prices larger than the last price, the quantity demanded is the last quantity.
For example, a demand curve of "10.0 200 20.0 100" would specify that the unit wanted to own 200 of the item at prices of 10.0 or below, 100 at prices of 20.0 or above and an intermediate quantity in between. So at a price of 15.0, the unit would seek to own 150 of the item.
A demand curve consisting out of just a single price/quantity is not very useful. In effect, it will specify that you want to own the given quantity, no more and no less, at any price.
The BUY and SELL commands are only convenient shorthands for specific, simple TRADE commands. If the unit's number of items is current, the following two pairs of orders are equivalent:
BUY item quantity price TRADE 1 item price - 10% (current + quantity) price current SELL item quantity price TRADE 1 item price - 10% current price (current - quantity)
To resolve trades, at the end of every day, at every location, and for every item, all offered trades (including BUYs and SELLs) are compared and, for as long as there are available Pareto improvements, the traders’ items and gold are redistributed. All transactions are at the same clearing price.
If there is trading of a product at a location, adjacent units receive a full price report. This report includes clearing price, transaction volume, and the open interest at a higher and a lower price.
Only characters may trade.
|Move active unit’s children to the beginning of the stack|
This command changes the order of the active unit’s children. Any children specified will be moved to the top of the list of children (in the order specified). Specified units which are not children of the active unit are ignored.
Order of a siblings rarely matters. For example, the commands of children listed earlier are processed before those of later children. For another, combat in confined spaces will involve children listed earlier before children listed later.
|Move active unit’s children to the end of the stack|
This command is similar to PROMOTE, but the specified units are moved to the bottom of the active unit’s list of children. The first specified unit is moved to the bottom, the next specified unit is made next to last, and so on.
|instant, unit, faction|
|Give unit or faction a name|
The active unit or faction takes the specified name (which should be given inside quotation marks).
Names must begin with an English letters and only contain English letters and the underscore (_). No spaces are allowed in names; instead the underscore should be used.
If the name is already taken by a unit, faction, skill, item, or keyword, or could be an ID (i.e., it consists only of letters followed by digits), the command will fail.
Names are not case sensitive (i.e.,
sTeVeN is the same name as
Steven), but should be specified using title case. That means that the first letter of proper names should be a capital followed by lower-case letters, articles and conjunctions should be all lower-case, and words should be joined by underscores. Notwithstanding, apostrophized and other exotic names, as well as acronyms, can be capitalized accordingly.
Names should not be vulgar, juvenile, trademarked, or anachronistic. Subtle jokes and references to other worlds or materials are certainly allowed. Names which do not meet these standards may be changed to something embarrassing at the end of any turn. If you see a unit or faction with a name in violation of this policy, mail the administrators.
If given multiple names, the first one that is available is taken. This is useful because some other unit or faction somewhere in the world may already have your chosen name.
N.B. The game translates names in orders to their corresponding IDs when the orders are submitted, while units’ NAME commands are only executed in the regular order when a turn is run. That means that you cannot use newly given names in an order submitted before the NAME command has run, but must refer to the unit by ID until then. (Wise to do in any case as the NAME command can fail, for example, because the name is already taken.) This also means you can safely refer to a unit by the name you saw in the most recent turn report, even if the unit’s controller changes it during the upcoming turn.
But faction commands, including NAME are executed immediately upon turn submission. That means that a faction’s name may have changed between the end of your last turn report and the time you submit your new orders. So, unless you are confident that a faction will not change its name, it may be best always to refer to it by ID.
Any controlled unit and faction can NAME.
|instant, unit, faction|
|Claim a title|
The active unit adopts the specified eligible title (which should be given inside quotation marks).
There are many, many titles available in Ascendancy, all of which are almost purely cosmetic. The sole effect of titles is that they will appear in turn reports wherever the unit’s name appears. The only consequence is that observers will know that the unit qualifies (or, at the time the title was claimed, qualified) for the title. In orders, units should only be referred to by their name (or ID) without any title.
Many titles are available based on a character’s skill level. EXAMINEing a character’s skills will usually state which titles the skill provides.
Other titles, for example, titles of nobility, are available based on the total holdings of a unit’s faction. These titles usually have limits on the number of units in a faction that they can be awarded.
Some titles are available for geographical or architectural features, such as provinces, seas, cities, houses, and the like and are based on the unit’s contents.
Some titles for characters may be gender specific (like
Queen). Gender-specific titles come in pairs which are otherwise equivalent.
Each unit may have only one title. Executing a successful TITLE command discards the old title and adopts the new.
The requirements of a title are only checked when it is claimed. As long as the unit does not change its title, it will retain it even if loses the eligibility to claim it anew.
If given multiple titles, the first one that the unit is eligible for is adopted.
A TITLE command without an argument removes the unit’s title.
Any controlled unit may claim a title.
|Set the unit’s status message.|
The active unit adopts the specified status message (which should be given inside quotation marks). Status message are purely cosmetic; their only effect is to display the message to any other unit executing an express or implicit LOOK command.
Status messages should be short; messages long than a typical line may be truncated. As to substantive content, the same guidelines apply as with respect to POST and MAIL.
Status messages serve as many purposes as their authors’ whimsy can dream up. They may be advisories on provinces (
Incognito units will be attacked on sight), cities (
Only units with size up to 500 may enter), or signposts (
To reach imperial city, TRAVEL WEST then NORTHWEST). For characters, the may be claims about current or future activities (
... you’ll see. ... SOON you’ll ALL SEE!), a noble’s motto (
Fear Poseidon and Dread Naught), or anything else appropriate to the character and situation.
A STATUS command without an argument remove the unit’s status message.
Any controlled unit may have a status message.
|TAX||rate||instant, non-character unit|
|Set the unit’s tax rate to rate.|
Tax rates vary between 0.0 and 4.0. The default tax rate is 1.0. At this rate taxpayers (such as peasants) in the unit will generate gold at their base rate. Lower or higher tax rates will result in correspondingly more or less tax revenue.
Rates above 1.0 create an increasing risk of a tax rebellion. Moreover, even at rates of 1.0 or below, taxpayers are apt to migrate to adjacent units or neighboring provinces where taxes are lower.
Only non-character controlled units pay taxes. Taxpayers with a character are assumed to be working for that character in lieu of taxes. Taxpayers in non-controlled units are deemed free of any tax obligation.
|Automatically execute all characters taken captive|
If a unit with NOQUARTER leads a stack in combat (either as the attacker or defender) and takes captives, they will immediately be executed at the end of a battle.
NOQUARTER defaults to OFF. Some units of some non-player factions (such as roving gangs or monsters or dungeon dwellers) can be expected to have turned on NOQUARTER.
Any controlled unit may set an its NOQUARTER option.
|OPEN||[neutral_size [friend_size]]||instant, unit|
|Limit the size of units which can enter you or amounts they can give to you|
Ordinarily, units can only enter or give to controlled units with a friendly attitude towards them. (Anybody can enter any uncontrolled units.) The OPEN command can permit neutral units to enter or give or restrict the ability of friendly units to enter or give. Units deemed hostile are never allowed to enter or give and units deemed super-friendly (e.g., those of the same faction) are always allowed to enter or give.
The specified size limits control who can enter or how much they can give. A stack trying to enter is restricted to the stated size limit and will be denied entry otherwise. A unit trying to give will only be able to give up to the specified size in a single command.
One purpose of this command is to allow open entry of certain controlled units, such as cities, which the controller wishes to be generally accessible. The size limit permits the barring of large potentially hostile groups, such as unexpected enemy armies. But note that a clever adversary can smuggle larger groups in by repeatedly dropping off its forces inside, moving out, picking up new forces, and moving back in. This tactic of course requires a day for each GIVE and TAKE, limiting how large force one character can smuggle in.
The OPEN limits default to 0, i.e., neutral units cannot give or enter at all and friendly units can freely enter or give.
Any controlled unit may set open limits.
|Avoid attacking superior forces|
This command allows a unit to forgo attacks against superior forces.
Before every attack initiated by the unit (either by express ATTACK or due to hostile attitude by the unit), a measure of strength is calculated for each stack. If the ratio of this measure for the active unit over the target unit is less than the active unit’s CAUTION level, it will refrain from going through with combat. For example, an active unit with CAUTION 2.5 will never attack another stack unless it is at least two and a half times as strong as the target.
The measure of power used for each stack is fairly crude. It is based on the sum of all the attack and defense values of all characters and items in each stack. While this measure correlates with a unit’s success in battle, it does not take into account the exact mechanics of combat nor its random vagaries. Many a battle has been lost by a stack with a theoretically higher measure.
CAUTION does nothing to protect the active unit from attack by other units.
The CAUTION limit defaults to OFF (i.e., any ATTACK command or hostile attitude will be obeyed.)
Any controlled unit may adopt caution.
|Move automatically to targets of unit’s other commands|
A unit which has turned on AUTOMOVE will automatically try to reach non-adjacent target units of GIVE, TAKE, ATTACK and RECRUIT commands. It also affects the TRAVEL command. Skill USE that require an adjacent target are also affected by AUTOMOVE.
If the target of predicate command is already adjacent, the active unit’s AUTOMOVE status has no effect. But if the target is visible, but non-adjacent, to the active unit (which usually means in the same province) and the active unit’s AUTOMOVE is ON, the active unit effectively does a free, instant MOVETO the target first.
When the predicate command (other than TRAVEL) concludes, successfully or otherwise, AUTOMOVE will cause the active unit to move back to its original position.
If the predicate command takes multiple days, the active unit will perform its AUTOMOVEs every day.
The AUTOMOVE setting defaults to ON.
Only characters may move automatically (or otherwise).
Units and factions can have attitudes towards other units and factions which affect how they respond to them when they encounter each other or interact.
Friendly attitudes towards a unit allow that unit to MOVE in or GIVE. Super-friendly units (i.e., units of the same faction or uncontrolled) may also TAKE from each other.
Hostile attitudes cause the unit to be engaged in skirmish combat whenever it is encountered (unless the unit’s CAUTION would prevent an attack).
Attitudes towards (and by) units override their faction’s attitude if they conflict. Faction attitudes only are in effect for units flying their faction’s BANNER. The exact rules for which attitudes take effect is an advanced subject.
To determine what attitude the active unit takes towards the other unit, the following rules are applied in order. The first rule that is met determines the attitude.
- If the active and other units are of the same faction, they will be super-friendly towards each other.
- If the active unit is uncontrolled, it will be super-friendly towards all units.
- If the active unit has a specified attitude towards the other unit, it will take that attitude.
- If the active unit has a specified attitude towards the other unit’s faction and the other unit is flying its BANNER, it will take that attitude.
- If the active unit has a specified attitude towards INCOGNITO units and the other unit is not flying a BANNER, it will take that attitude.
- If the active unit has a specified attitude towards ALL, it will take that attitude.
- If the active unit is flying its BANNER and the active unit’s faction has a specified attitude towards the other unit, it will take that attitude.
- If the active unit is flying its BANNER and the other unit is flying its BANNER and the active unit’s faction has a specified attitude towards the other unit’s faction, it will take that attitude.
- If the active unit is flying its BANNER and the other unit is not flying a BANNER and the active unit’s faction has a specified attitude towards INCOGNITO units, it will take that attitude.
- If the active unit is flying its BANNER and the active unit’s faction has a specified attitude towards ALL, it will take that attitude.
- Otherwise, the active will be neutral towards the other.
In addition to the relation commands, attitudes are also affected by hostile actions, such as attacking (skirmish or full battle) and stealing (if caught). The victim will turn hostile to the offender. If the offender is flying its banner, the victim will also turn hostile to the offender's faction. If the victim is flying its banner, its faction will also go hostile to the offender and the offender's faction the offender is flying its banner. Use relation commands to change these attitudes back to neutral if you want to.
|FRIEND||[unit|faction|INCOGNITO|ALL]*||instant, unit, faction|
|Adopt a friendly attitude|
For each unit or faction given, the active unit’s or faction’s attitude is changed to friendly.
Units deemed friendly by the active unit can enter it and give it items. Moreover, if a child deemed friendly by its parent is attacked, the parent will come to the defense of the child (even if the attacker is deemed friendly too).
Reaction to otherwise unspecified units which carry no BANNER is given with the INCOGNITO keyword. Reaction to all other units is given with the ALL keyword.
A FRIEND command without any parameters removes all units and factions from the friendly list.
Any controlled unit or faction may adjust its attitude.
|FOE||[unit|faction|INCOGNITO|ALL]*||instant, unit, faction|
|Adopt a hostile attitude|
This command is accepts the same parameters as FRIEND, but the active unit’s or faction’s attitude is changed to hostile.
Units deemed hostile by the active unit will be attacked in skirmish mode whenever they are encountered. Children deemed hostile will be expelled.
Automatic skirmish attacks caused by hostile attitudes are not commands. They do not disrupt or even delay the unit’s actual orders. Rather, such skirmish attacks happen whenever the active unit and the unit deemed hostile happen to become adjacent which can happen multiple times a day:
In the Mathrolen Plains example above, assume that the First_Guard was hostile to Cault. If Cault tried to GIVE something to the Cache unit out in the province (and he had turned on AUTOMOVE), he’d leave the Vitalder Library, be skirmish attacked by the First_Guard, then—assuming he survived—leave the Town of Carlock, interact with the Cache, re-enter the Town, be skirmish attacked by the First_Guard again, and then—assuming he survived again—return to the library. All of this would happen within one day. If the First_Guard found itself visiting the library on its own errands that day, there could another skirmish battle between the same units.
Non-character controlled units which do not carry any immobile items can skirmish units they deem hostile, even though they cannot ATTACK. Units which carry immobile items can only skirmish their children.
Reaction to otherwise unspecified units which carry no BANNER is given with the INCOGNITO keyword. Reaction to all other units is given with the ALL keyword.
A FOE command without any parameters removes all units and factions from the hostile list.
Any controlled unit or faction may adjust its attitude.
|NEUTRAL||[unit|faction|INCOGNITO|ALL]*||instant, unit, faction|
|Adopt a neutral attitude|
This command is accepts the same parameters as FRIEND, but the active unit’s or faction’s attitude is changed to neutral (i.e., removed from both the friendly and hostile lists).
A NEUTRAL command without any parameters completely clears out the active unit’s or faction’s friendly and hostile lists.
Reaction to otherwise unspecified units which carry no BANNER is given with the INCOGNITO keyword. Reaction to all other units is given with the ALL keyword.
Any controlled unit or faction may adjust its attitude.
|Fly or furl the banner|
Each controlled unit has its faction’s banner. Using this command, the active unit can either fly or furl its banner.
A unit flying its banner will be identified by its faction in all reports and interactions. As a consequence all other units which see it will know its faction and may act according to attitudes towards the active unit’s faction. Units not flying a BANNER are referred to as INCOGNITO units.
Note that an INCOGNITO unit will only act on its own attitudes and ignore the attitudes of its faction. This prevents an INCOGNITO unit’s faction from being inadvertently revealed by its interactions.
BANNER defaults to OFF.
Any controlled unit may fly or furl its banner.
Conditional commands allow units to react to circumstances which may arise during a turn. They are both very powerful and unnecessary: powerful, because they allow units to respond to unforeseen or contingent events during a turn; unnecessary, because every task in the world can be accomplished without the use of conditional commands. As such, it is recommended that this advanced subject be skipped by all but devoted computer programmers.
Conditional commands trigger off conditions. Conditions consist out of a series of one or more of the following:
- Item Quantity. A condition consisting of an item ID or name and a quantity will be fulfilled whenever the active unit has at least the given quantity of that item.
- Skill Level. A condition consisting of an skill ID or name and a level will be fulfilled whenever the active unit has at least the given level of that skill.
- Unit. A condition consisting of a unit ID or name will be fulfilled whenever the active unit is adjacent to the given unit.
- Signal. A condition consisting of a signal ID will be fulfilled whenever the given SIGNAL has been raised.
A list of conditions will be fulfilled when all the listed conditions are fulfilled. An empty conditional is always fulfilled.
|IF||conditions commands* END||instant, unit|
|Adopt commands if conditions are met|
This command evaluates the conditional and if it is fulfilled adds the given commands to the beginning of the active unit’s orders.
For example, if a unit wanted to give Kemer all its gold, but only if Kemer is adjacent, it could have the following orders:
IF Kemer GIVE Kemer gold 0 END TRAVEL EAST …
If the Kemer was adjacent to the active unit, after the IF command, the orders would become:
GIVE Kemer gold 0 TRAVEL EAST …
If the signal had not been set, the IF command and its contents would just disappear instantly.
Any controlled unit may use the IF command.
|IFNOT||conditions commands* END||instant, unit|
|Adopt commands if conditions are not met|
This command is the same as IF except that the given commands are triggered if the condition is not fulfilled. The conditional commands always take at least one day.
For example, if a unit wanted to go hostile to the faction House_Burgon unless the signal abc123 is set, it could have the following orders:
IFNOT abc123 FOE House_Burgon END TRAVEL WEST …
If the signal abc123 was not set, after the IFNOT command, the orders would become:
FOE House_Burgon TRAVEL WEST …
If the signal had been set, the IFNOT command and its contents would just disappear instantly.
Any controlled unit may use the IFNOT command.
|WHILE||conditions commands* END||instant, unit|
|Repeat commands as long as conditions are met|
This command evaluates the conditional and if its is fulfilled adds the given commands and this command itself to the beginning of the orders. The conditional commands always take at least one day.
The effect of this command is to repeat the given commands for as long as the condition holds.
For example, if a unit wanted to fell trees while the signal abc123 is set, it could have the following orders:
WHILE abc123 COLLECT 1 tree END TRAVEL NORTH …
If the signal abc123 was set, after the WHILE command, the orders would become:
COLLECT 1 tree WHILE abc123 COLLECT 1 tree END TRAVEL WEST …
If the signal had not been set, the WHILE command and its contents would just disappear instantly.
The 1-day parameter for the COLLECT command is important. Without it, the triggered COLLECT command would have continued indefinitely and the signal would not have been checked again.
For another example, assume you want you have a unit that is supposed to collect peasants full-time and transfer the resulting workers to Ahman. You could do this:
COLLECT 1 peasants GIVE Ahman workers 0 COLLECT 1 peasants GIVE Ahman workers 0 COLLECT 1 peasants GIVE Ahman workers 0 …
But that is not very economical, either in your time—you have to enter an endless list of repetitive orders— or the unit’s—it spends half its time GIVEing and only half its time recruiting workers to your cause. A better way is this:
WHILE UNTIL workers 20 COLLECT 1 peasants END GIVE Ahman workers 0 END
This construct repeats indefinitely (remember, the empty conditional on the WHILE is always met. Moreover, the inner UNTIL (conditional commands can be nested) keeps collecting peasants until you have at least 20 and then gives them to Ahman as a bunch at once.
Any controlled unit may use the WHILE command.
|UNTIL||conditions commands* END||instant, unit|
|Repeat commands until conditions are met|
This command is the same as WHILE except that the given commands are triggered if the condition is not fulfilled.
For example, if a unit wanted to study magic until it reached level 5 and then go north, it could have the following orders:
UNTIL magic 5 STUDY 1 magic END TRAVEL NORTH …
If the active unit had a magic skill of less than 5, after the UNTIL command, the orders would become:
STUDY 1 magic UNTIL magic 5 STUDY 1 magic END TRAVEL NORTH …
If the unit had already been at magic level 5 or above, the UNTIL command and its contents would just have disappeared instantly. As with the WHILE example, giving a 1-day parameter to the STUDY command matters.
|WHEN||conditions commands* END||instant, unit|
|Adopt commands whenever conditions are met|
This command evaluates the conditional and if its is fulfilled adds the given commands to the beginning of the orders. Regardless of whether the condition is fulfilled, this command itself is added to the orders right before the next day command following the conditional commands (if any). The conditional commands always take at least one day.
The effect of this command is to trigger the given commands every day the condition holds.
For example, if a unit wanted to attack the Burgon_Army as long as signal abc123 was set, it could have the following orders:
WHEN abc123 ATTACK 1 Burgon_Army END NAME Burgon_Avenger STUDY magic …
If the signal abc123 was set, after the WHEN command, the orders would become:
ATTACK 1 Burgon_Army NAME Burgon_Avenger WHEN abc123 ATTACK 1 Burgon_Army END STUDY magic …
Note that the renewed WHEN command is inserted after the pending instant commands, but before the next day command.
If the signal abc123 was not set, after the WHEN command, the orders would become:
NAME Burgon_Avenger STUDY 1 magic WHEN abc123 ATTACK 1 Burgon_Army END STUDY magic …
Note that the multi-day STUDY command had a one-day version split off.
Any controlled unit may use the WHEN command.
|UNLESS||conditions commands* END||instant, unit|
|Adopt commands whenever conditions are not met|
This command is the same as WHEN except that the given commands are triggered if the condition is not fulfilled.
For example, if a unit wanted to be friendly to all units whenever signal xyz789 was not set, it could have the following orders:
UNLESS xyz789 FRIEND ALL END …
If the signal xyz789 was not set, after the UNLESS command, the orders would become:
FRIEND ALL WAIT 1 UNLESS xyz789 FRIEND ALL END …
Because the conditional commands include no day command, a WAIT 1 command has been inserted to ensure that the conditional commands take at least one day.
In the above example, the FRIEND ALL is executed if the signal is ever unset, but it is never undone, even if the signal was subsequently set. One could fix this by giving the following orders:
UNLESS xyz789 FRIEND ALL END WHEN xyz789 NEUTRAL ALL END
This would, however, occupy the unit full-time. While FRIEND and FOE commands are instant, each iteration of a WHEN or UNLESS always takes at least one day. To have the unit instead study magic while it is monitoring the signal, do this:
UNLESS xyz789 FRIEND ALL STUDY 1 magic END WHEN xyz789 NEUTRAL ALL STUDY 1 magic END
Any controlled unit may use the UNLESS command.
|RANDOM||commands* END||instant, unit|
|Adopt one of the commands at random|
This command is adds one of the commands listed at random, each with equal probability.
For example, if a unit wanted to travel the world forever at random, looking around in each new place:
WHILE RANDOM TRAVEL north TRAVEL south TRAVEL east TRAVEL west END LOOK END
Players can use this command if they want to make their units' behavior unpredictable even to themselves. As a practical matter, it is mostly used by non-player factions.
Any controlled unit may use the RANDOM command.
|SIGNAL||signal [ON|OFF]||instant, unit, faction|
|Send a signal for the world to see|
This command sets off a signal which any other unit in the world can see—as long as it is looking for it.
The signal should be an unassigned ID from the faction’s ID pool or a signal previously used by the faction.
The only purpose of sending a signal is to trigger conditional commands by other units which are waiting for the signal. While it is possible to use SIGNAL to coordinate between units in the same faction, it is generally easier to use the ORDER commands as a unit in a faction can order any other unit in the same faction anywhere else. The principal purpose of the SIGNAL command is to enable coordination between different factions.
Re-SIGNALing a signal turns it off.
Note that any other unit in the world—same faction, friendly, hostile, or indifferent—can see and respond to a signal. Prudent players will not share their signals’ IDs with anybody they would not want to be able to react to them.
Any controlled unit may signal.
Factions themselves can execute only faction commands. Faction commands are the general commands FRIEND, FOE, NEUTRAL, NAME, SIGNAL, ORDER, ORDERFIRST, and ORDERLAST and the following faction-only commands:
|FACTION||faction "password"||instant, faction|
|Begin a faction’s orders|
This command begins every set of orders submitted to an Ascendancy game. Its first argument is the ID (or name) of a faction. Its second argument is the faction’s password. If the password does not match the faction’s previously recorded password, the command will fail and so will the following faction commands.
All commands following FACTION until END are interpreted as commands of the specified faction. Typically they will mostly consist out of ORDER to END blocks for each of the units controlled by the faction.
|Set a faction password|
This command sets or changes the current faction’s password. It can only be given following a FACTION command (which of course needs to use the previous password, if any).
The password should be enclosed in quotation marks and consist exclusively out of the English upper- and lowercase letters, digits, and the underscore character. Passwords, in contrast to almost everything else in Ascendancy are case sensitive.
Setting a faction password is highly recommended. Without a password, anybody can mail in new orders for your faction, including changing the faction e-mail address and password, effectively locking you out. The game provides an automatically generated password for each faction which you will be given when creating the faction.
N.B. The Ascendancy server saves your password as plain text. This is necessary for it to generate a working template for your next turn and saves you the trouble of remembering it. That also means that in case of a security breach on the server, your password will be revealed. Do not set a password that you also use anywhere else!
|Set a faction’s e-mail address|
This faction command sets or changes the current faction’s email address.
The email address should be enclosed in quotation marks and otherwise be a legal e-mail address. This address is used to send both turn reports and order templates.
You can unset your e-mail address to stop receiving turn reports and order templates. To play, you'll have to go to www.ascendancyonline.com where you'll be able to retrieve your most recent turn report and edit your orders.
|Offer your faction’s vassalage to liegefaction|
This faction command allows your faction to become a vassal to another faction. By itself, it only provides an offer. Only once the liegefaction has included your faction in its VASSAL command, does the vassalage go into effect.
If your faction is a vassal to another faction, there are several effects:
Your liege lord's (and his lords') bannered units will automatically be friendly to your bannered units. That means that your bannered units can GIVE to them and ordinarily enter them freely. They will never be hostile.
Your bannered units will automatically be super-friendly to your liege lord's (and his lords') bannered units. That means that, in addition to what yours can do to theirs, their bannered units can TAKE anything they want from your adjacent bannered units and even given them ORDERs.
Your units can claim titles of nobility depending on your ultimate liege lord's holdings, rather than your own. Be aware that many of these titles are competitive (i.e., there is only a limited number available for each set of holdings), so do not claim those without coordinating with your liege lords.
Your non-bannered units are not affected by your faction's vassalage. Nor is there any effect on the attitudes between bannered units of fellow vassals.
You can at any time instantly renounce your vassalage by executing the LIEGE command without an argument.
|Accept the vassalage of vassalfaction|
This faction command allows your faction to accept the vassalage of another faction. By itself, it only provides an offer. Only once the vassalfaction has executed a LIEGE command with your faction as argument, does the vassalage go into effect.
The effects of a vassalage are described above under LIEGE.
Note that every time you execute the VASSAL command, you must list all your vassals. Vassals which are not included are renounced. To get rid of all your vassals, execute a VASSAL command without arguments.
|Reset your faction at a new location|
This faction command is your last resort once all of your characters are either dead or captive and you have no hope of recovering. It frees all your remaining units and eliminates all attitudes and relationships towards your faction.
In return, you receive a new starting character with the usual resources at the specified starting location valid for your server. If you do not specify a starting location, one will be picked at random. Once RESET executes, you can immediately begin issuing new commands to your new character.
|Receive reports of events with a verbosity up to the specified level|
Every event a unit can see has a verbosity level. For almost all ordinary events, that level is 0. For some less important or more repetitive events, it is 1. For reports of combat hits, the level is 2. For even less important event, such as misses in combat, it is 3 or higher.
Setting a faction verbosity level filters out all messages from the turn reports with a higher verbosity.
The default verbosity level is 2. That means that the faction will receive almost all reports, except combat misses and the like.
Verbosity levels do not affect what events are reported in the JSON data reports which are always exhaustive.
Combat is always between stacks; the attacking unit, its children, their children, and so on, against the defending unit, its children, their children, and so on. If a unit attacks its parent, or a parent attacks its children, the parent will fight alone; the child will fight with its full stack and the other children of the parent (the other combatant’s siblings) will not participate. If two siblings fight and the parent is friendly to the defender, it will join in its defense.
Combat will play out between the two combatant stacks, each fighter getting on average one attack during skirmishes and ten attacks during full-on battles. After the combat, each combatant—if it survives—will go about its other business as before, though in the case of battles using the ATTACK command, fighting may resume the next day if the combatants are still around.
Exactly how a battle is resolved is an advanced subject with which beginners or non-warlike players need not concern themselves.
Combat is between fighters in the combatant stacks. Fighters are the characters in each stack and all fighting items (such as soldiers or monsters) they hold.
Combat is resolved in rounds. The number of rounds depends on the type of combat and the number of fighters. For battles, the number of rounds equals the number of starting fighters times five. For skirmishes, the number of rounds equals the number of starting fighters.
Each combat round proceeds in the following steps:
- A random fighter of either side is picked as the attacker.
- The attacker picks a random accessible fighter on the other side as the defender.
- If the attacker defeats the defender, the defender is wounded (which will kill a defender with only one hit). The chance of defeating the defender is the attacker’s effective attack rating over the sum of the defender’s effective defense rating and the attacker’s effective attack rating.
Nameless fighters (i.e., items in one of the combatant stacks) have attack and defense ratings based on what they are. Character’s attack and defense ratings are determined by their skills and items they may carry (i.e., weapons or armor). Certain skills and circumstances (e.g., fortifications, weather, or leadership skill of the unit's leader) may modify these ratings to result in higher or lower effective ratings.
For example, if a nameless axeman (with attack 4 and defense 3) fights a nameless knight (with attack 12 and defense 12), its chance of hitting its target is 4 (the axeman’s attack rating) divided by 12 (the knight’s defense rating) plus 4 (the axeman’s attack rating) or 25%.
An overkill occurs when the attacker handily hits. When there is overkill, the attacker immediately gets another free attack against a new defender. While overkill is rare among fighters of similar strength, it allows certain powerful fighters (e.g., dragons or high-level warriors) to hit multiple enemy fighters every time they get an attack.
A retaliation occurs whenever the attacker (who is not using a ranged weapon) misses the defender. Under retaliation, the defender gets an immediate counter-attack on the attacker. There is no possibility of overkill or counter-retaliation in a retaliatory strike.
In the above example, the chance of the knight surviving the axeman’s attack and getting to retaliate is 1-(4/(4+12)) (or 75%). If the knight retaliates, its chance of hitting the axeman are 12/(4+14) (or 75%).
A few points about combat are worth noting:
Combat inside confined spaces, such as dungeons or cities, will only permit a limited number of fighters to participate. The total size of fighters on each side is limited by the area of the location. This works out to about one human-sized fighter per three units of area. Fighters participate in stack order (i.e., the defender, followed by its first child, its children, and so on, its second child, and so on). The character of a unit participates if about half of its fighters fit. Non-participating fighters will not attack or defend or suffer any of the effects of combat, but they can prevent their side from being defeated entirely. So, for example, if character Ahman with three other child characters and a thousand soldier army as and last child attacked a dragon in a dungeon with only enough size to allow for the four characters, only Ahman and the three characters would actually fight. But if the dragon hit all the characters without being killed itself, the army would pull them to safety after the fight; the characters would be wounded, but the battle would be a draw and the characters would not become captives of (or executed by) the dragon unit. Consequently, some backup, even if they cannot participate in the fight, is often invaluable.
Fighters cannot attack other fighters which cannot travel by any of the same means. So a knight, which can travel by land, could attack (and be attacked by) a dragon which can travel by land and air. But a combat between only land units and only sea units (such as war ships) would pretty much automatically be a draw. Be careful if attacking with a land-based character holding only a bunch of war ships against a bunch of land units: In effect, the character will be fighting the land units on its own.
The opportunity to attack is random. That means that in a typical battle, each fighter will on average attack five times; in a skirmish, only half a time. But there is no guarantee that any fighter will get a chance to attack at all or that fighters on both sides will get the same number of attacks.
Because skirmishes have only half a round per fighter, skirmishes between similarly matched forces will usually only result in both sides being roughed up, rather than either being wiped out. A large force can of course wipe out a much smaller one, even in a skirmish.
Wounded characters are unable to participate in combat until they heal, naturally or by magic. If a stack (defender or attacker) is completely defeated in combat, its wounded characters become captives or the victorious stack which claims all their items. If the leader of the victorious stack has set NOQUARTER, captives are immediately killed and the victor retains their bodies instead.
Characters who would be killed in combat may instead be marked as captured. They will not participate in the combat any further and, at the end of combat, if their side was wiped out, they will become the victor's captives. Captive characters transfer all their remaining mobile items to the victor, are stacked into it, cannot execute any commands, and will remain captives until released with the DROP command. Victors with NOQUARTER automatically execute all their captives instead.
After setting forth all the game mechanics in the previous sections, this section explains how to actually play the game.
How to Join a Game
To join a game, go to http://www.ascendancyonline.com and create a new faction on any of the available servers. Options include a preferred starting location, the initial name of your faction, the initial name of your starting character, and a faction password.
As soon as the new faction is processed, you will receive an email from your game server. The text of this e-mail will consist of a template for your first orders and have one or more attachments.
The order template will serve as the first draft of your first set of orders. The attachments will include an initial turn report in HTML format. This initial turn report will include a LOOK report for your initial location and should give you some ideas about what to do in your first turn.
You are now ready to submit orders.
How to Submit Orders
Playing Ascendancy consists out of submitting orders back to the server via email to firstname.lastname@example.org. Or just hit reply on your turn reports or order templates.
Each set of orders begins with a FACTION command and ends with an END. In between you may enter any number of faction commands. The most important of your faction commands will be ORDER commands for each of your controlled units. So a typical set of orders would look something like this:
FACTION my-faction-id-or-name password … # Some faction commands, for example, NAME or FRIEND ORDER my-initial-character-id-or-name … # Everything that character should do … # May include ORDERs from this character to your other units END ORDER another-character-you-control … END ORDER yet-another-of-your-characters … END ORDER a-unit-you-created … END ORDER another-unit-you-created … END … END
Most of this structure will already be in the template you received after setup or your last turn. In particular, the template will contain ORDER commands for all your current units filled in with their current, unfinished orders. So just sending your unmodified order template back as new orders would replace all your unit’s orders with themselves and accomplish nothing.
There are a few rules on how to format your orders:
Valid names for units, factions, items, or skills are translated into the corresponding ID.
Empty lines are ignored.
All parts of a line following a hash mark (#) or between square brackets () are ignored as comments. Brackets may not be nested.
Initial white space (space characters, tabs, and the like) is ignored. White space between words is collapsed to a single space each.
Text strings (such as the arguments for NAME, TITLE, and STATUS) should be enclosed in quotation marks.
Unrecognized text will automatically be enclosed in quotation marks. If what you intended as a name or ID comes back enclosed in quotation marks, there likely was a typo.
These rules are ignored from the line following a POST or MAIL command to the next END. Names are not translated to IDs. Comments and white space are left unmolested.
When generating your order template, the game will include additional useful information (such as a unit’s name) as comment between square brackets and provide some information about a unit’s current state as comment lines (following a hash mark) at the beginning of each ORDER section. These comments are purely informative and can be ignored; by no means feel obligated to enter them for commands you write yourself.
Your orders are processed immediately upon submission. All the base faction commands such as ORDER or NAME take effect right away. That means that units receive their new orders immediately; they not start processing them until the turn is actually run.
As soon as your orders are processed you will receive back a new order template reflecting the changes. You can then—should you wish to—submit new or revised orders. You can repeat this cycle as often as you want until your orders are perfect or the turn actually runs.
How Turns Are Run
Each game regularly processes turns. Typically turns are processed weekly at midnight between Saturday and Sunday, U.S. Eastern time. (Specific games may have other fixed or variable turn processing schedules.) That means that you should submit your orders no later than Saturday and can expect to receive the results by Sunday morning. (If processing a turn exposes bugs or other problems which require the developers’ manual attention, turn processing may be delayed.)
By default each turn consists out of 30 days (one Ascendancy month, twelve of which make up an Ascendancy year). Each day all controlled units execute all their pending instant commands. Then each controlled unit gets a chance to process one day command. Then the next day is run. (Exact order of processing is an advanced subject.)
Instant commands are run for each province (in unspecified order). Once a province has run all its instant commands, its children (in stack order) get to run all their instant commands. After a unit has run its instant commands, and before its subsequent siblings do, its children get to run all their instant commands.
This process is repeated until there are no more pending instant commands. This may require several iterations as one unit could have given ORDERs with new instant commands to another unit which had already run its instant commands for the day. Hence, while all of a unit’s pending instant commands usually run in one batch, it is possible for a unit to run instant commands in multiple batches, separated by other units’ instant commands.
After instant commands, all skirmishes caused by hostile attitudes between adjacent units are processed and parents drop children they are hostile to.
After the skirmishes, one day command for every non-traveling unit is run. The order of day commands is first by command type and then by the same order as the instant commands. The order in which day commands are executed is:
That means that, e.g., all ATTACKs will run before all STUDYs; if multiple units issue the same day command, units outermost and earlier in stack order will run their commands first (just like with instant commands).
As the day commands are processed, it is possible that further skirmishes are triggered by unit movement (such as MOVEs or other commands combined with AUTOMOVE).
After the day commands, natural processes occur for all items in all units. These include trees and fish schools growing, peasants having children, paying taxes or migrating, children becoming peasants, sentients collecting their pay (if any), unpaid sentients deserting, sentients in provinces reverting to peasants or the like, and much more.
After all days of a turn have run, a report is compiled for each faction. This report includes everything that faction’s controlled units saw or did turning the turn. It will also include a free, instant LOOK for each controlled unit. This report, formatted in HTML, is sent to the faction’s email address along with a new order template reflecting the state of affairs at the end of the turn.
On paid servers, each faction in each game has a number of credits. Every time a turn is run, one credit is consumed. Once a faction is down to zero credits, it will be unable to submit orders and will not receive turn reports. However, the faction’s units will continue to go about their preexisting orders.
To replenish a faction’s credits (or buy initial credits for a newly created faction), visit http://www.ascendancyonline.com.
Credits are not transferable between players on one server or between a player's factions on different servers.
Ascendancy is designed for large, populous worlds. Each world can handle hundreds or thousands of players, thousands of provinces, tens of thousands of units, and a nearly infinite number of items. In fact, the more the merrier. More players just mean more chances to interact.
But sometimes one world is not enough. New players may want to start out on a fresh world. Grognards may find that playing just one faction is insufficiently demanding. There could be overcrowding. Players may want to try games with different turn length, frequency, or other basic parameters. Or everybody could just have won the game.
For those reasons, Ascendancy provides for multiple game servers each hosting a separate world. Just check out the website when you are creating your faction and select the server which suits you best. Production servers are labeled g1, g2, g3, and on up.
There is also a unique test server. It differs from production servers in a few ways:
The prime purpose of the test server is to test new features for correctness and play balance. This means that features may be added, removed, or changed without notice. In some cases, this will require the test server to be reset or reverted to an earlier turn. The developers will try to compensate players adversely affected by such measures in gold or by other means, but they make no promises.
New items, skills, titles, and other features are first implemented on the test server and only migrate to the production servers once they have been tested here.
One consequence is that the test server is expected crash more frequently and require more manual intervention by the developers. Turn frequency may be less regular than on production servers.
Attempting to crash the test server is not only permitted, but positively encouraged. All the developers ask is that, after a method of crashing the server has been acknowledged, you won’t try that method again; at least until the developers claim the problem was fixed.
The test server is invitation only.
Playing on the test server will always be free.
Ascendancy is generally designed to allow its players to do everything that the manual and game code permit. So feel free to try out almost anything; the worst that can happen is that your orders fail or that you uncover a bug. However, there are a few things that are both hard or impossible to ban in software and would—if widely done—ruin the fun of the game. You shouldn’t do those things. They are considered cheating:
Creating multiple factions on the same server under different e-mail addresses. With multiple factions you could effectively avoid the per-faction character limitations and unfairly overpower other players or create defenseless robbery victims.
All players are very much encouraged to invite their friends and family to play Ascendancy. Nor is there anything wrong with pre-existing real-life alliances carrying over into a game of Ascendancy. However, if you are actually reading the reports or writing the orders for more than one faction, you have a crossed the line.
Bouncing random names or ids off the server to see if they exist. Names and ids may become revealed as a matter of course in the regular submission of orders; this is not considered cheating. But randomly generating ids or names, including them in orders, and see what comes back is considered cheating.
Deliberately bogging down the server. While no unit can execute more day commands in a turn than there are days in a turn, the number of instant command every turn (or even every day) is essentially unlimited. Generating useless but massive sets of instant commands is considered cheating. So is abuse of the conditional commands, in particular WHEN and UNLESS, each of which can generate massive number of commands. This will be fixed as soon as the developers have solved the halting problem.
Interfering with or intercepting other players’ turns or reports. Ascendancy is e-mail based and e-mail is famously insecure.Some protections, such as optional PGP encryption and authentication, may eventually be built into the game, but that does not remove all vulnerabilities.
Intentionally crashing or freezing a production server. This includes deliberately sending orders which serve no purpose other than to bog down the server and delay reports. Unintentional server crashes and freezes are of course on the developers.
Any form of cheating may be penalized in any manner, up to and including deletion of the involved factions and all their units and items, subject only to the developers’ unreviewable discretion.
Using any sort of tool to help you play Ascendancy is not cheating. Everything from battle simulators, to visualizations of your turn reports, to fully-fledged autonomous AIs to read your reports and write your orders are allowed unless they violate some other rule (such as crashing the server). Developing, sharing, or selling such tools is fine as long as they come with a prominent disclaimer that the Ascendancy developers have no responsibility for the tool.
Creating, posting to, or reading any third-party web sites (such as wikis) with information on Ascdendancy is also not cheating. But before you do, a few things to keep in mind:
Those who would read such sites should know that nothing on them is verified or guaranteed by the Ascendancy developers. Anything you read may be subject to change without notice, already outdated, apply to a different server, or just be plain—even maliciously—wrong. Do not rely on anything you read there.
Those who would post to such sites should remember that anything there may very well be read by their rivals and enemies in their current or future games. So exposing hard-won knowledge that way may be counter-productive. Instead, consider sharing your research only with trusted allies or, perhaps, even selling it in the game to those willing to pay the gold.
Finally, both groups should know that deliberately posting false, misleading, or incomplete information to such sites is not considered cheating either (by the Ascendancy developers—web site hosts may understandably feel different).
There are multiple mailing lists for Ascendancy which players and everybody else interested should consider subscribing themselves to.
The Ascendancy announcement list contains posts about new features or matters of general interest to all Ascendancy players. Everybody with any interest in Ascendancy should subscribe. Posting frequency should be no more than weekly and often rarer than that. The announcement list e-mail address is email@example.com.
While we cannot force you to subscribe, we would if we could. All players are presumed to have constructive knowledge of everything posted to this list. So if there was an announcement that the semantics of a hypothetical FIRE command were changed from
rain arrows of death on all who defy youto
set yourself on fire,complaints about an unexpected 2,000 archer_ash the next turn will not be entertained.
The Ascendancy players list is intended for player to player queries and help. If you do not understand a rule or need some advice about what to do, this is the place to post. Membership, at least on a digest or web-only basis, is recommended for all players. More lengthy discussions about how Ascendancy ought to work should be taken to the Ascendancy design list. The player list e-mail address is firstname.lastname@example.org.
The Ascendancy design list is for longer discussions about how Ascendancy ought to work. Rules debates, ideas for new features, and any discussions—as long as they are remotely civil and at least vaguely related to Ascendancy—are welcome. Joining the design list is for anybody who enjoys such discussions and doesn’t mind occasionally long e-mail threads. The design list e-mail address is email@example.com.
The Ascendancy developers list is for the current developers of Ascendancy. Anybody who has an issue which needs the designers’ attention (and which was not resolved on the players or design lists) can post to it, but only the developers can join or read its contents. The developer list e-mail address is firstname.lastname@example.org.