Arcane University:Unified Style Guide

The unified style guide is a set of guidelines for any game writing for the Beyond Skyrim or Nirn Uncharted Projects. Adhering to the rules here is paramount for both consistency and to allow for the easy automation of dialogue and quest implementation. Note that some projects deviate slightly, but the format and examples presented here will be accepted by any project aforementioned. This text is copied from the document found here. It is up to date as of May 2024.

The purpose of this style guide is to maintain consistency within and across the projects using it. It integrates the disparate style sheets that have been used in the past in order to present a unified overall style. Please familiarize yourself with the rules and conventions. When in doubt, look to vanilla Skyrim. This page has all dialogue found in vanilla, and it can help you see how words and phrases have been used. Be aware, however, that Bethesda was not always consistent in how they worded things. If that isn't sufficient, ask the writing lead for your specific project. Additional resources that writers and editors may find useful may be found in the Universal Resource List. Each project has its own special requirements, so be sure to consult your project's addendum for further information.

General Notes

• There is a character limit of 80 characters per line for player dialogue and 149 for NPC lines. Use Ctrl+Shift+C to quickly check character/word count on Google Docs.
• Spelling should default to American English (AmE). On Google Docs select File → Language → English (United States). Google Docs will flag non-standard spellings that can then be changed to American spellings: "color" not "colour", "utilize" not "utilise", "traveled" not "travelled", "center" not "centre", etc.
• Avoid modern idioms and terms, especially if associated with popular modern media of some sort. Try to keep the dialogue immersive. If in doubt, ask.
• To minimize both form counts and VO duplication, consider reusing the same NPC response lines multiple times so that they can share assets during implementation. Write all repeated dialogue lines (known as "sharedinfos") in cornflower blue.

Document Formats and Requirements

1. All writing needs to be written directly into Google Drive with the third numbering tool used to auto-number dialogue lines.
2. DISABLE auto-substitution of "..." and turn off smart quotes in Google docs before you begin:
   1. Tools → Preferences → Substitutions [for ellipses]
   2. Tools → Preferences → General [for smart quotes]
      
3. All player lines should be in bold, and NPC lines in plain text. All text on player lines--such as # implementation notes and skill check levels--should also be bold.
4. Text colors are used to denote the following:
   1. [Implementation notes] e.g. [end dialogue] [go to ...] [start combat] All text is purple, lowercase, and enclosed in square brackets.
   2. [Voice Acting notes] e.g. [happy] [sad] [angry] All text is orange, lowercase, and enclosed in square brackets.
   3. Identical lines (known as "sharedinfos") are set in cornflower blue so that implementers and voice actors know if a line is used more than once.
   4. [success] in green, within square brackets, indicates that a skill check has been passed.
   5. [failure] in red, within square brackets, indicates that a skill check has failed.
5. At the end of each NPC response thread, there should be an implementation notation directing where the conversation should go next (whether back to general dialogue, back to the previous options, or go down to a specific segment). Please do not leave them blank.
6. All documents should have the name of the writer(s) at the top left of the document. Use the Discord tag you are recognized by on your project's server.

NPC Document Requirements

1. Include an overview of the character in every general dialogue document, (or in the quest doc if the character does not have general dialogue) that includes, if applicable:
   1. Brief bio that includes race, gender, and occupation; family members, if any; relevant backstory.
   2. Appearance (including outfit and other inventory items).
   3. A barebones schedule for the character, using 24-hour clock.
   4. Voicetype or the general demeanor for a voicetype to be chosen. (These may be added later by leads.)
   5. List of associated quests, with links to quest documents.
2. Greetings and farewells:
   1. In general, greetings and farewells can be offered in any order, so use bullets rather than line numbering.
   2. Ideally each character will have between 1 and 3 unique greetings, and 1 to 3 farewells. Quest related greetings are not included in this count.
   3. In rare cases, unique greetings and farewells are not necessary in standard dialogue, as the NPC can just use generic versions. In such cases include "[No unique greetings]" or "[No unique farewells]" in the relevant sections.
   4. If you wish for a specific greeting to be the first greeting that the NPC says, it should be marked [initial]. If a second set of greetings follows a condition such as completion of a quest, a second [initial] may be used. Note: [initial] lines are never played again, unless specified.
   5. If you wish for a specific line to end a dialogue without triggering one of the standard farewells, you may end the line with [end dialogue] [no farewell].
   6. Passive/Active Greetings: Lines played when the player is within a certain radius of the NPC but does not interact with them actively.
      1. Normal greetings can be marked as [PASSIVE] to play only when no player interaction occurs.
      2. Normal greetings can be marked as [ACTIVE] to play only if the player interacts with the NPC.
      3. Normal greetings that are not tagged as Active or Passive will be used for both situations by default.
   7. Walk Away Farewells: If the player exits a dialogue with an NPC before it is complete, one of the NPC's standard farewells will play.
      1. Because not all farewells would be appropriate in such a situation, the writer can mark a general farewell as [WALK AWAY].
      2. If a specific line within a dialogue tree should serve as a walk away farewell appropriate only to that dialogue tree option, that line can be marked within the dialogue tree:
         1. Example:
            
3. Barks:
   1. Like greetings and farewells, barks can be offered in any order, so use bullets rather than numbering.
   2. NPCs have 3 types of dialogue that can occur outside of a dialogue tree, and these are known as barks.
      1. Idle Barks: Lines said by the NPC every x seconds.
      2. Entry Barks: Lines that trigger a scene or dialogue when the player enters an interior.
      3. Combat Barks: Lines said by an NPC during active combat.
      4. Follower Barks: Lines said by a follower when certain conditions are met, such as entering a cave. Ask your lead or a senior writer before including such barks.
   3. Merchants
      1. Merchant dialogue must include entry barks if the merchant is within a shop interior.
      2. Merchants located at a stall or outside a shop must have idle barks.
4. In rare cases, an NPC will have an initial encounter that then unlocks the standard dialogue. Describe this circumstance and then include the dialogue under the heading "Initial Dialogue". Follow with the section headed "Standard Dialogue".

NPC Document Example

Quest Document Requirements

1. All quests should have the following sections filled out at the top of the document before submitting for review:
   1. Quest Title and Type: The name of your quest and the type (Fetch, Misc., Side, etc.).
   2. Summary: A rough summary that outlines the events of your quest.
   3. Dramatis Personae: The main characters, with links to each. Indicate if there are any NPCs that are not pre-existing characters.
   4. Assets: A list of the unique assets required for the quest. Generally quests should try not to require assets. But when they do, make sure to ask a writing director.
2. All notes/journals/books referenced in a quest should have their own separate documents listed among the Assets, with links provided in the quest document.
3. Information on how to include objectives and journal entries can be found in "Quest Objectives and Journal Entries" in the Implementation Guide below.

Quest Document Example

Text Formatting Guide

Punctuation

1. Dashes: The em-dash (—) and en-dash (–) are banned. They don't show up in-game. Where these would ordinarily be used for pauses, stuttering, interruptions, or trailing off, use the following:
   1. Pauses: To indicate a pause between two connected clauses, use a singular hyphen (-) with spaces on either side.
      1. e.g. That's exactly what this is - a road to an early death!
   2. Interruptions: To show that someone has been interrupted or a line cut off, use two hyphens at the end of the word.
      1. EXAMPLE (Scene between two NPCs)
         1. NPC 1: What is the meaning of--
         2. NPC 2: Stop right there, criminal scum!
   3. Stuttering: To show that someone is stuttering, use a hyphen with no spaces on either side.
      1. e.g. Sh-she's sleeping, over there. I-I don't know what to s-say.
   4. Trailing off: To indicate that someone's speech has trailed off into silence, use three dots:
      1. e.g. I tried to tell her that I... Oh, I don't know what I mean!
2. Quotation Marks:
   1. Use quotation marks ("), not apostrophes or inverted commas (') for quoted material.
   2. As per American English, quoted material at the end of the sentence includes punctuation within the quotation marks, not without. For a full explanation, see: Grammarly
3. Apostrophes:
   1. When using the possessive apostrophe with a name that ends in "s", use a second "s" to denote it, rather than a lone apostrophe. (This also helps for lip sync generation.)
      1. e.g. Arrys's ship
      2. Not Arrys' ship
   2. For other rules regarding apostrophes, see: Grammarly.
4. Commas:
   1. Please follow standard usage. For a full explanation, see: Grammarly
   2. Avoid comma splices. This means not joining two separate independent sentences with a comma.
      1. e.g. That mer had better watch out. I've got my eye on her.
      2. Not That mer had better watch out, I've got my eye on her.
   3. Use a comma before "and" only if what follows is an independent clause.
      1. e.g. I'm going to Roscrea, and I'm going to mine mithril
      2. Not I'm going to mine mithril, and copper.
   4. Use serial (Oxford) commas throughout; that is, when you are listing three or more items, commas should separate each element of the list.
      1. e.g. I'm going to mine mithril, copper, and gold.

Capitalization

In addition to commonly-accepted capitalization rules (e.g. proper nouns), there are usages specific to our game-writing conventions. There are two sets of rules for capitalization: general rules that apply to all of our written text, and rules which are contextual depending on where the text will appear and what function it serves. When in doubt, ask a lead or consult the word list.

1. General rules
   1. Gods/gods
      1. Non-specific references to gods are lowercase, as are pronoun references to gods in game.
         1. e.g. May the gods watch over your battles, friend.
         2. Not May the Gods watch over your battles, friend.
         3. e.g. May Mara bless you with her love.
         4. Not May Mara bless you with Her love.
      2. Specific references to individual gods (Mara, Akatosh, Shor, Molag Bal, etc.) and the "Eight/Nine Divines" should be capitalized, as should the names of totems (Bear, Whale, Owl, etc.)
      3. Daedra/Daedric should be capitalized.
         1. e.g. Those Divines don't have Daedric artifacts.
         2. Not Those divines don't have daedric artifacts.
   2. Race names
      1. Capitalize correct as well as Imperialized versions of specific names of races (Dunmer, Orc, Bosmer, etc.).
         1. e.g. Any Dunmer worth their weight in ash would say the same.
         2. e.g. I'm a Dark Elf and I live in Windhelm.
      2. Lowercase slang, colloquial, or derogatory terms.
         1. e.g. You damn gray-skin. Go back to Morrowind!
      3. Lowercase references to macro-species names such as "human", "elven", or "beastfolk".
   3. Faction names
      1. When referring to a specific faction, capitalize all words in the faction name, even if they are not proper nouns: the Thieves Guild, the East Empire Company.
      2. When using a short form of the faction name, also capitalize: the College [College of Whispers], the Company [East Empire Company]. If the full faction name could be said in place of it, it's valid to capitalize the partial.
      3. Bandits and corsairs are not included as factions, though their specific clan names are.
         1. e.g. Those corsairs are getting out of hand.
         2. e.g. I hear the Claws are operating out of Bravil.
   4. Titles
      1. Capitalize a title such as "count" when it is part of the name of the person and acting as a modifier.
         1. e.g. Count Pertinax sends his regards.
      2. Capitalize a title when it is being used as part of a formal title.
         1. e.g. He is the Count of Kvatch.
      3. Capitalize a title when it is used in direct address.
         1. e.g. Hello, Canonreeve, how do you like the weather we're having?
      4. Do not capitalize when the word is used in other general senses as an ordinary noun.
         1. e.g. The count came to see me yesterday.
         2. e.g. In a world before emperors ruled...
      5. EXCEPTION: "Emperor/Empress" is a special case and should be capitalized, even when not used as part of a full title.
         1. e.g. We must speak with the Empress.
      6. Refer to project-specific guidelines or word lists for other exceptions. The top of this document contains links for each project.
   5. Species names
      1. Use lowercase unless used as part of another proper noun.
         1. e.g. Make love like a sabre cat.
         2. e.g. Bring me the Cloak of Sabre Cats.
      2. If a proper noun exists in the species name, capitalize only the proper noun.
         1. e.g. Kill the Atmoran wolf.
         2. Not Kill the Atmoran Wolf.
         3. Not Kill the atmoran wolf.
   6. Herbs and Ingredients
      1. When used in dialogue, objectives, and journal entries, capitalize only the proper noun portion of an ingredient name. Otherwise, ingredient names are lowercase.
         1. e.g. Can you bring me some Jerall flowers?
         2. Not Can you bring me some Jerall Flowers?
         3. e.g. Can you bring me some blue mountain flowers?
         4. Not Can you bring me some Blue Mountain Flowers?
      2. When used in implementation notes or other out-of-universe text, capitalize ingredient names:
         1. e.g. [add Corundum Ore]
   7. Currency references are always lowercase:
      1. e.g. You need to work for your septims.
   8. Diseases should always be capitalized:
      1. e.g. I think that wolf might've given me Rockjoint.
   9. Locations and Regions
      1. Specific location and region names should always be capitalized:
         1. e.g. Sunnyside Vineyard is on the cliffside just outside Anvil.
         2. e.g. The Morae Isles are unlike any other place in Alinor.
      2. General terms for locations and regions should be lowercase.
         1. e.g. Is he going to the mine today?
         2. e.g. These islands hold many secrets.
2. Contextual rules
   1. Capitalization can vary depending on whether the text in question is in-universe text (e.g. lines of dialogue, a note or book) or out-of-universe text (e.g. text of objectives, loading screens, tooltips).
   2. Out-of-universe text assigns significance to game systems and mechanics and so capitalizes important terms like names of specific quest items, attacks, skills, or stats. Do not capitalize when referring to something general or non-specific, such as "a sword" or "her bow."
      1. e.g. (Tooltip) Hold left-click to perform a Power Attack.
      2. e.g. (Objective) Steal Barnaby's Journal
      3. e.g. (Loading Screen) Ayleid Wells can be used to give you a Magicka boost once per day.
   3. In-universe text does NOT assign significance to game systems and mechanics, and so does not capitalize such terms.
      1. e.g. (Readable Book) His enthusiasm makes up for his lack of stamina.
      2. e.g. (Dialogue) Go to the castle and steal Barnaby's journal.
      3. e.g. (Dialogue) I've often found that the lesser-known schools of magicka bear the most fruit.

Numbers

1. Write out ALL numbers, no matter how large, for anything said out loud (either by a character or theoretically by the player, even though the player doesn’t actually speak). This aids in lip syncing for voice generation files.
2. Numbers contained in parenthesis, such as at the end of a line to denote a price in game terms, should be written with numerals.
   1. EXAMPLE (NPC and PC barter)
      1. That'll be five hundred septims for the item, please.
         1. Sure, here's the money. (500 gold)
   2. This rule also applies to titles.
      1. e.g. That was in the time of the great Titus Mede the Second.
      2. Not That was in the time of the great Titus Mede II.
3. EXCEPTION: Books or written texts can use either Titus Mede the Second, OR Titus Mede II as they are not spoken by the player nor a character.
4. Numerals may be used in the text of objectives, as these are not spoken.
   1. e.g. Bring 10 fire salts to Balimund

Implementation Guide

Implementation refers to anything that instructs someone on how to read a line, when to show a line, where to go after a line is said, or other procedural matters. Because it involves elements larger than the written dialogue itself, it has precise rules that must be followed. Please read this section carefully. If you have questions about implementation, consult your writing lead.

ALL IMPLEMENTATION NOTES ARE REQUIRED TO BE EITHER AT THE BEGINNING OR THE END OF THE LINE IN SQUARE BRACKETS OF THE CORRESPONDING COLOR.

Implementation Notes

1. Implementation notes can be used for a variety of purposes:
   1. Something taken from PC
      1. e.g. I'd like to rent a room. (10 gold) [remove 10 gold]
      2. e.g. I found the tome. (Give tome) [remove Ancient Tome]
   2. Something given to PC
      1. e.g. Thank you so much for all of your help. [add 100 gold]
      2. e.g. You'll need permission from the Jarl. [add Permission Papers]
      3. e.g. It's at Frost Maw Cave. I'll mark it on your map. [place quest marker on Frost Maw Cave]
   3. Dialogue progression
      1. Concluding a dialogue with NPC
         1. e.g. I will look forward to your return. [end dialogue]
      2. Returning dialogue to the first set of options
         1. e.g. There isn't much else to say about that. [back to root]
      3. Returning dialogue to the most recent set of options.
         1. e.g. Did you have any other questions about that? [back to options]
      4. These progression instructions should be the final instruction given when there is a group that is stacked. See examples below.
   4. Disposition of NPC toward PC
      1. e.g. Thank you so much for all of your help. [increase disposition by 1]
      2. e.g. This is awful! What am I going to do now? [decrease disposition by 1]
      3. e.g. You are the best of them, friend. [set disposition to 3]
      4. e.g. I can't stand the sight of you. [set disposition to -3]
   5. Quest granted or completed
      1. e.g. I will look forward to your return. [Quest granted: Old Friends]
      2. e.g. Good work, my friend. [Quest completed: Old Friends]
   6. Objective granted or completed
      1. e.g. I need that gold as soon as possible. I have debts of my own to pay. [Objective granted: Recover payment from Reslyn]
      2. e.g. Ah, there's the gold I'm owed! Good work, my friend. [Objective completed: Recover payment from Reslyn]
2. Implementation notes can be stacked next to each other when multiple indications need to be made at the end or beginning of a line:
   1. e.g. I will look forward to your return. [Quest granted: Old Friends] [Objective granted: Recover payment from Reslyn] [end dialogue]
   2. e.g. Good work, my friend. [Objective completed: Recover payment from Reslyn] [Objective granted: Recover payment from Mattieu] [end dialogue]

Keywords

1. Directional notes can require a lot of cross-references to move the dialogue forward or backward to a particular point. Rather than using line numbers (go to 2.3.1.2.2.1.1.), use keywords. These will remain the same, even when text is added or deleted, while line numbers will change and need to be corrected each time a document is edited.
2. Set keywords as bold and uppercase so they can be easily located. Do this both within an implementation note and where a keyword is placed.
3. The placement of the keyword matters, so pay close attention to where they occur in the examples that follow.
   1. If you place the keyword before a list of dialogue options, the NPC will not speak and that list of dialogue options will be presented to the player. See the HERE example below.
   2. If you place the keyword before a line, you will be indicating that the NPC speaks that line of dialogue. See STEPS example below.
4. Referencing a list of options
   1. Keywords can be used to reference a list of dialogue options, when [back to root] or [back to options] would not send the dialogue to the correct point.
   2. In this example, the keyword HERE is used in this way:
      
5. Moving forward or backward within a dialogue branch
   1. Use the words "go to" followed by the keyword to continue dialogue within the dialogue tree.
   2. You may add "below" or "above" for clarity. This is especially helpful when the keyword is located far from the line where the implementation note is.
   3. In this example, the keyword STEPS is used to direct the implementer to other dialogue points in the same branch.
      
6. Continuing text when you run out of room
   1. Use "go to" when you need to reset the text to the left side of the document because Google Docs refuses to allow the writer to continue indenting.
   2. In this example, the keyword PLAN directs the implementer to where the dialogue continues.
      
7. Branching
   1. Keywords can be used to create branches of a quest. Use the words "go to" followed by the keyword to indicate that the dialogue diverges.
   2. Here the keyword KILL BRANCH is used to go to a larger division in the quest.
      
8. Locking and unlocking dialogue
   1. Use [locked] to indicate that an option should not be shown to the player until another portion of dialogue has been completed. Then [unlock] the option by reference to a keyword, not a line number (even if the lines are near one another). Line numbers change if text is moved during editing; keywords stay the same.
      
      

Conditional Dialogue

1. There are occasions where a player option or dialogue line should only be available if certain conditions have been met. In these cases, the condition should be placed at the beginning of the line, in purple type and within square brackets.
2. Conditions can be achieved easily by implementation but it should be noted that they will not be attached to the script that handles persuasion and intimidation because they will not reward XP.
3. When conditioning a line of dialogue, you must specify every condition:
   1. e.g. [if PC is Khajiit] Kin of kin! Khajiit welcomes his own.
   2. e.g. [if PC is not Khajiit] Warm sands, friend.
4. When conditioning a line of dialogue as either one thing or the other, write out the separate lines in their entirety.
   1. e.g. [if PC is male] Get him, before he gets away!
   2. e.g. [if PC is female] Get her, before she gets away!
   3. Not Get [him/her], before [he/she] gets away!
5. An option or line can be conditioned to be available only under certain circumstances. Once the condition is met, the option will always succeed, so there is no need to provide a failure line.
   1. Thresholds
      1. An option can be conditioned to be available only once the player has passed a threshold of having a certain skill level or gold level.
         1. e.g. [if PC gold > 100] Fine, I'll pay. Here. (100 gold)
         2. e.g. [if Smithing > 50] I know your steel is poor quality.
   2. Specific items found in player inventory
      1. e.g. [if PC has Dragonstone] I found the Dragonstone you were looking for. (Give Dragonstone) [remove Dragonstone]
6. An option or line can be conditioned to show up only if the player is in a certain place in the worldspace or in the progression of a quest.
   1. Completion of objectives/quests or specific outcomes of quests
      1. e.g. [if Iron Lung is complete] Gaeridil is breathing much easier now.
      2. e.g. [if A'alani is dead] You'll have to ask Indur for a reading of the stars.
   2. Specific locations
      1. e.g. [if at forge] Need your blades sharpened, do you?
7. Dialogue can also be conditioned on the player's three primary attributes, Health, Stamina, and Magicka. These are much more rare as there are limited circumstances when an action or persuasion would be dependent on these attributes.
   1. e.g. [if Health > 250] I know how to take a hit. (Brawl)
8. For multiple dialogue lines that fulfill the same condition, use ["] in purple.
   1. In the example below, the player will get lines 1.1 and 1.2 if one condition is met, or lines 1.3 and 1.4 if the other condition is met. In either case the player will also get line 1.5.
      

Player Actions, Skill Checks, and Rewards

1. Actions: The player can take a number of actions in dialogue:
   1. Place all player actions shown in in-game text such as (Persuade), (Intimidate), (Give X), (Illusion), (Brawl), (Lie), etc., at the end of the line within parentheses and in the same type as the player line (bold and black). This is what the player sees, and the characters in these notations are counted toward the character limit of 80 for a player line.
      1. e.g. You can tell me. I'm only here to help. (Persuade)
      2. e.g. You feel the urgent need to open the door for me. (Illusion)
   2. (Persuade) is an action based on the player's Speech skill. As such, Speech perks will decrease these thresholds when they are acquired. Very Easy can only be failed if the player has a Speech-reducing disease.
   3. (Intimidate) is an action based on the player's Speech skill, while also taking into account the NPC's confidence level. Avoid specifying different difficulty levels for different Intimidate checks on the same NPC for implementation reasons.
   4. (<BribeCost> gold) is an action dependent on the player having enough gold, and, as such, has the potential to succeed or fail. Please do not specify an amount, as this will be calculated by the game.
   5. (X gold) is an action dependent on the player having the amount of gold specified by the numeral X, so it has the potential to succeed or fail. This action is to be used whenever you want the player to pay a flat amount of gold.
   6. (Lie) is an action that is not tied to any skill. The single outcome of this action is entirely dependent on the narrative circumstances.
   7. (Brawl) is an action used to indicate that an option will result in a (non-lethal) brawl. As such, there are success and failure options for this action.
   8. (Attack) is an action used to indicate that an option will result in combat.
   9. (Give X) is an action presented whenever the player has an item to give. This action follows the rules of out-of-universe text:
      1. Quest items require capitalization:
         1. e.g. Oh, you mean this old stone? (Give Dragonstone)
      2. Generic items do not require capitalization:
         1. e.g. Here's the spell tome you asked for. (Give tome)
      3. Do not quantify the amount given in parenthesis:
         1. e.g. I have five samples right here. (Give Netch Jelly)
      4. Do not include the recipient of the item:
         1. e.g. Here's the sword. (Give sword)
2. Skill checks
   1. Skill checks are denoted as actions, but also include the relevant skill and the conditions necessary to pass the skill check.
   2. Difficulty
      1. Skill checks have a difficulty range of Very Easy, Easy, Average, Hard, and Very Hard. Denote this in words in boldface purple type within square brackets at the end of the line.
         1. e.g. You feel the urgent need to open the door for me. (Illusion) [easy]
      2. The values for passing the skill checks, from Very Easy to Very Hard are:
         1. Speech skill checks: 10, 25, 50, 75, 100
         2. Illusion skill checks: 20, 35, 50, 75, 100
   3. Passing a skill check
      1. Success and failure on a skill check or action are indicated in dark green and red and placed before the NPC line, as shown in the example below.
      2. Because passing a skill check rewards the player with XP, it is important to lock the skill check so that the player cannot farm the dialogue for infinite XP.
      3. If the NPC has multiple lines of dialogue in response to a success/failure check, you may use ["] in the appropriate color.
      4. However, if a player line follows the success or failure dialogue, you must use a full merge with a keyword. This also applies to reward dialogue, or any dialogue that changes the player's inventory: "Give me that. [remove artifact]". This only applies if the player has subsequent lines.
         1. EXAMPLE:
            
      5. If dialogue continues after a skill check, it must start in a new dialogue tree so the player can select the dialogue without passing the skill check again.
         1. EXAMPLE:
            
   4. Auto-pass and Auto-fail
      1. In lieu of assigning difficulty, you may also use [auto-pass] or [auto-fail]. There is only one outcome in this kind of check, so there is no need to include a line for [failure] for an auto-pass or [success] for an auto-fail. (See the example above.)
3. Rewards and Payments are placed at the end of the line where they are received, in purple and within square brackets:
   1. EXAMPLES:
      1. Here's the potion you asked for.
         1. Thank you. Now let me give you something for your trouble. [add 50 gold]
      2. I'd like to rent a room. (10 gold)
         1. Okay, it's yours for a day. [remove 10 gold]
4. Leveled Rewards
   1. Writers can either indicate a specific reward or scale the reward to reflect the difficulty of a task, using the leveled rewards built into Skyrim.
      1. e.g. [add Potion of Minor Stamina] to give the player a specific potion.
      2. e.g. [add Leveled Stamina Potion] to give the player a potion commensurate with the player's level in the game, such as a Minor, Plentiful, Extreme, or Ultimate Potion of Stamina.
   2. Generally, the amount of a leveled reward depends on the player's level, but in the case of gold rewards, the magnitude of the reward can be indicated within the implementation note, using all caps.
      1. e.g. [add SMALL leveled gold reward]
      2. The leveled list for gold rewards is:
         
      3. The full range of leveled rewards can be found at Leveled List page on UESP.

Voice Actor Notes, Vocalizations, and SharedInfos

1. All notes for the attention of the voice director/actor at the beginning of the line in orange text, within square brackets.
   1. VA notes are copied into a separate box in the CK which is attached to the line as a whole. The VA will only get the notes as an addendum to the line they need to read. The position of the notes will not be preserved through this process, so placing them within a line is pointless.
2. Voice Actor Notes can be used for a variety of purposes:
   1. Stress To emphasize a certain word or phrase. (Do not use italics for this.)
      1. e.g. [emphasis: still] Is that a chapel up there? Really? We're at the end of the world, and we still can't escape those damned priests!
   2. Homophones To clarify any homophones that could be confusing.
      1. e.g. [all past tense] He saw me and he gave me the book and I read it.
      2. e.g. [all present tense] And now I read it over and over. It... changes.
   3. Pronunciation If the pronunciation of a name in a dialogue line could be confusing or complicated, include a phonetic breakdown of the name in orange, in parentheses, to assist the voice actors. Capitalize the stressed syllable(s).
      1. e.g. [KATH-noh-kway, YIN-slay-ah, EZZ-ree-oh-nyet] During his reign, Uriel the Fifth conquered Cathnoquey, Yneslea, and Esrionet as well.
   4. Emotion To indicate a particular emotion the line should convey or a change in emotion.
      
   5. Other languages If the NPC is speaking in a conlang (e.g. Roscrean, Ta'agra), the translation in orange type tells the VA what the line means, and thus how to deliver the line. The player will only see and hear the foreign language.
      1. e.g. [Ta'agra: Hello, brother] Dras'kay, liter.
3. Vocalizations Do not use VA notes in orange type for anything that is actually voiced.
   1. Use black type and parentheses to add vocalizations that are part of an NPC's line of dialogue: (sigh) (laugh) (chuckle) (sob), etc.
   2. Use nouns, not verbs, for vocalizations, and do not capitalize them.
      1. e.g.(sigh) I suppose you’re right.
      2. Not (sighs) I suppose you’re right.
      3. Not (He sighs) I suppose you’re right.
      4. Not (Sigh) I suppose you’re right.
   3. When a vocalization is put at the end of a line or between sentences, it should follow the terminal punctuation.
      1. e.g. He fell flat on his back. (chuckle)
      2. Not He fell flat on his back (chuckle).
      3. e.g. He fell flat on his back. (chuckle) You should have seen it.
      4. Not He fell flat on his back (chuckle). You should have seen it.
   4. The examples here are taken from Skyrim. Writers should feel free to create their own vocalizations as long as they follow the above rules.
4. Sharedinfos
   1. Reusing the same NPC response lines multiple times saves on form counts and voice actor work, so this practice is both useful and economical.
   2. Write all shared dialogue lines in black the first time they are used, and in cornflower blue for every instance of exact repetition of the line.
   3. Keeping the first use of the line in black enables voice actors to know that a line has not already been recorded. Blue shows them that a line does not need to be recorded again.

Quest Objectives and Journal Entries

1. Progress through a quest is shown through objectives and journal entries.
   1. Fetch and Misc. quests require only a "Misc. objective", but no journal entries.
   2. Longer or more complex quests require both objectives and journal entries.
2. Implementation notes within dialogue trees or instructions tell when objectives are granted and completed.
   1. Put each notation in square brackets in purple type. These can be stacked with other implementation notes.
      1. e.g. [Objective completed: Bring corundum ore to Indirel] [Objective granted: Meet Indirel to conduct the ritual to Azura] [end dialogue]
3. Objectives begin with a capital letter but end without a period, and they follow the capitalization rules for sentences, not titles.
4. Objectives are set in bold type in both implementation notes and lists of objectives. Ideally, they should not exceed 60 characters.
5. The objectives show up in-game so they must be written in a way that reminds the player of the progression of tasks that have been completed and what still needs to be done.
   1. e.g. Bring corundum ore to Indirel
   2. Not Get ore
6. Objectives completed, failed, and current should be specified whenever a quest updates.
   1. Indicate completed objectives with <x>
   2. Indicate failed objectives with strikethrough (ALT + SHIFT + 5)
   3. Indicate current objectives with < >
      
7. If an objective is not required for the quest to be completed "(Optional)" may be added before the wording of the objective:
   
8. If there are two choices that the player can make, each with its own objective, they may be shown like this:
   
9. If the objective involves collecting multiple items that the game will count to determine when the objective is fulfilled, use the form x/10:
   
10. Journal entries follow the quest update and are set in italics.
11. Journal entries show up in-game and serve as reminders to the player of what has already been accomplished in a quest and what the next step is. Since a player may wait hours, days, or even months before continuing a quest, these must be specific.
    1. e.g. Azura has spoken to me. The priest in Jehanna will want to know this.
    2. Not I need to tell the priest what happened.
12. In general, try to avoid using "must" and "should" in journal entries so that the player can decide what actions need to be taken.

Miscellanea

1. Naming conventions
   1. Redguard heritage naming goes: Name at-Ancestor or Name al-Location, or Name af-Relative, e.g. Marona at-Orane.
   2. Orcs are always Name gro-Fathersname for males and Name gra-Mothersname for females (chieftain society), e.g. Grakzul gro-Khaarn.
   3. Khajiit names in Skyrim do not have capitalization after an apostrophe: M'aiq, J'zargo, Ma'randru-jo. We follow this precedent, despite names from earlier titles such as Oblivion having inconsistent rules in this regard.
   4. Argonian names should have all parts of the name capitalized, e.g. Stands-In-Shallows.
2. Player Name Use <Alias=Player> when you need to insert an instance of the player's name. This should only be used in player options, as NPCs will never say the player's name.
   1. e.g. Nice to meet you. I'm <Alias=Player>.