Skip to main content

Terminology A-Z

Refer to the following glossary for writing conventions for Unity-specific terminology. If you can't find a word on this list, then check the following resources:

If you still can't find a term, then post a question in the #unity-style-guide channel in Slack.

info

Using this terminology guide

Unless otherwise specified, write terminology as it appears in this list.

If you're not a writer, you might feel a bit lost while using this page. Here are the most common writing terms you can expect to find:

  • noun: A word to describe a thing, place, or person.
    • regular noun: A noun written in lowercase. For example, window, game, display.
    • proper noun: A noun written with a capital letter. Usually a name. For example, Unity, PlayStation.
  • adjective: A word that describes something. For example, fast/slow, primary/secondary.
    • compound adjective: two words joined by a hyphen to make an adjective. For example, third-party, head-mounted, GPU-bound.

#

  • 2D mode: Write "2D mode" with "mode" in lowercase. Specify if you are referring to the 2D mode within the Scene view. The button to enable or disable 2D mode in the Scene view is called the "2D button." If you are referring to both the 2D mode and the 3D mode at the same time, you can write "2D and 3D modes" or "2D or 3D mode."
  • 3D mode: Use the same guidance as for "2D mode."
  • 3D modeling software: When referring to software such as Maya or Blender, write "3D modeling software." Don't write "DCC software" or "Digital Content Creation software."

A​

  • abort: Use this term only if it appears as part of an API name. Use alternative language when describing the behavior of the API. For more information, refer to Microsoft Style Guide: abort, abortion.
  • above, below: Don't use when referring to content that precedes the text. For example, "the above table." Instead, link directly to the content, or use "previous." For example, "the previous section." Related term: below
  • activate: Use "activate" when referring to GameObjects. Write "enable" when referring to components and other settings. Don't write "turn on." Related term: deactivate.
  • Addressables:
    • When referring to the product, write "the Addressables system" or "the Addressables package."
    • When using as an adjective to describe things that are addressable, write in lower case without the "s." For example, "addressable assets," "addressable group," and "The assets are now addressable."
    • When describing items that are not addressable but belong to the Addressables system, use "Addressables" as an adjective. For example, "Addressables build scripts" and "Addressables settings."
    • When referring to text in the Editor that uses "Addressable(s)," write as it appears in the Editor.
    • Don't use "Addressables" or "addressable(s)" by themselves as nouns.
  • Addressables API: Write as a proper noun.
  • ahead-of-time (AOT): Write in lowercase. Write out in full on the first use. On subsequent uses, you can write the initialism in capital letters. If you use the initialism, define it on first use. For example, "ahead-of-time (AOT)." Related term: just-in-time (JIT).
  • ambient occlusion: Write as a regular noun (in lowercase) unless referring to the way it appears in the UI. Use lowercase when referring to the ambient occlusion post-processing effect. You can also write "ambient occlusion (AO)" and then refer to it as AO in the rest of the document.
  • Analytics Dashboard: The analytics section of the Unity Gaming Services dashboard. Write as a proper noun, two words.
  • Android Debug Database (ADB): Write in full the first time you use it, then abbreviate to ADB. Only use adb when specifically referring to actions taken in the command line.
  • animation clip: Write in lowercase when referring to the concept in general. When referring to a UI label, write in bold with the same capitalization as in the UI.
  • Animator Controller: Write as two words, with capitals.
  • app store: Write as a regular noun in lowercase unless specifically referring to Apple's App Store. Don't use "app marketplace."
  • application, app:
    • When referring to desktop programs, or if the platform is unknown, write "application."
    • When referring to applications on mobile devices, write "app."
    • If you are writing for a platform that uses different terminology to refer to a program, then use terminology consistent with the platform manufacturer instead. For example, some console platforms refer to games as "titles."
  • AR Foundation: Write this product name as a proper noun, with a space. Don't write "ARFoundation."
  • archetype: Write in lowercase when referring to an archetype in the Entities package.
  • asset: Write as a regular noun in lowercase.
    • Exceptions:
      • Capitalize it if it's a type name or member name in the API. For example, a class called Asset or a property called Assets.
      • Capitalize it if it's part of the name of a Unity product or service, such as Asset Store or the Asset Database.
  • Asset Store: Write as a proper noun.
  • AssetBundle: The name for a type of file that Unity users can export, containing a bundle of selected assets. Write as one word, with a capital "A" and "B."
  • audio: Write as lowercase when referring to the concept in general. When referring to a UI label, write in bold with the same capitalization as in the UI.
  • augmented reality (AR): Related terms: extended reality (XR), virtual reality (VR)
    • When referring to the general concept, write "augmented reality" out in full on first use as a regular noun in lowercase. For example, "produce an augmented reality environment." If you use the term multiple times in the same page, define the initialism on first use and write "AR" on subsequent uses.
    • Write with capitals and in bold when referring to UI elements that use "Augmented Reality."
    • If you are discussing topics that apply to both AR and virtual reality (VR), write "extended reality (XR)."
  • Avatar: Write as a proper noun when referring to an Avatar asset.
  • axis, axes: Singular "axis," plural "axes." For example, "Set each axis separately, or all axes at once." Write in lowercase, with a hyphen ("x-axis, y-axis, z-axis").

B​

  • back end, back-end: Whenever possible, don't use in content for a general audience. Instead, use a more specific term, such as server, operating system, database, or network. Use these terms only in content for a technical audience. Related term: front end.
    • When using as a noun, write as two words. For example, the Mono scripting "back end."
    • When using as an adjective, write as two hyphenated words. For example, "back-end development," "back-end server."
  • back face, back-face: Related term: front face.
    • When using as a noun, write as two words. For example, the "back face" of the GameObject.
    • When using as an adjective, write as two hyphenated words. For example, "back-face culling," "back-facing geometry."
    • When referring to the name of a property in the Editor that uses "Backface," write as it appears in the Editor.
  • below: Don't use when referring to content that follows the text. For example, the section below." Instead, link directly to the content, or use "the following." For example, "the following code." Related term: [above][#a].
  • billboard: Write "billboard" as a regular noun. Write "Billboard Renderer" as a proper noun whenever you refer to the Billboard Renderer component.
  • bits per pixel (bpp): Write in lowercase when you write it out in full ("bits per pixel"), and in lowercase as an acronym ("bpp"). Use "bpp" only as a unit when you are referring to a specific numeric color depth. Write it out in full the first time you use it, followed by the acronym in brackets.
  • Bitwise operations: Write the names of bitwise operations in all-caps. For example, "bitwise XOR operation," "bitwise AND operation."
  • Blackboard: Write as a proper noun when referring to the visual scripting tool.
  • blacklist: Don't use. Instead, use "blocklist." For more information, refer to Microsoft Style Guide: blacklist.
  • blend shapes: Write as a regular noun, two words.
  • Boolean: Write in full as a proper noun. In content related to scripting, write "bool" in lowercase and monospace font to refer to the Boolean type.
  • bootstrap: Don't use. Explain the process that the user needs to go through to carry out the action.
  • brand names: Write brand names, product names, and company names exactly as that brand or company presents them. Make sure to provide the necessary trademark attribution and follow any required approval processes. For more information, refer to Copyright and trademark attribution.
  • bug fix: Write as a regular noun, two words. Don't write "bug-fix" or "bugfix."
  • build: Only write when referring to the process of compiling files to create a runnable application file (usually via the Build Settings window). Don't use to mean develop, create, or publish.
  • built-in: Hyphenate as an adjective. For example, "a built-in camera." Don't hyphenate as a verb. For example, "This game was built in Unity."
  • Built-In Render Pipeline: Write "the Built-In Render Pipeline" in full every time you use it. Use an article. Don't write "Built-In RP" or "BIRP."
  • Built-in Particle System: Write "the Built-In Particle System" in full every time you use it. Use an article. Don't write "Particle System," "Built-In PS," or "BIPS."
  • Burst compiler: Write "the Burst compiler" in full every time you use it. Don't write "burstable" or "bursted." For example, you can write "To make your code compatible with the Burst compiler,..." or "This code has been compiled with the Burst compiler." If you need to, you can write "Burst-compiled" as an adjective.

C​

  • C#: Write as "C#." Don't write "C sharp" or "c#."
  • calculate: When discussing the act of a computer evaluating a process, use "calculate" to refer to purely arithmetic operations that don't use logic and provide an exact output. Use "calculate" also to refer to the act of a human evaluating a formula. For other types of processes, use "compute." Related term: compute.
  • call stack: Write as two words, as a regular noun in lowercase.
  • camera:
    • When discussing cameras in general, write in lowercase.
    • When referring to the Camera component, capitalize the C in camera.
    • When referring to the main camera concept, write "main camera" in lowercase. When referring to a specific main camera GameObject, write the name as it appears in the Editor in monospace font. For example, "The main camera in the scene is called Main Camera."
  • changelog: Write as one word, as a regular noun in lowercase.
  • checkbox: Write as one word, as a regular noun. For Learn content, refer to a checkbox as being "enabled" or "disabled," and direct the user to "enable" or "disable" checkboxes.
  • child: Always specify what the child item is. For example, "child GameObject" or "Item 1 is a child GameObject of Item 2." Don't use "children." Related term: parent.
  • codebase: Write as a regular noun.
  • collider:
    • When referring to colliders as a generic concept, write as a regular noun in lowercase.
    • When referring collectively to the various types of collider components, write "collider components."
    • When referring to a specific type of collider component, write Collider with a capital letter. For example, "Box Collider component," "Capsule Collider 2D component."
  • components:
    • Write component names as proper nouns in the same way they appear in the UI. Follow with the word "component" in lowercase every time. For example, "Rigidbody component," "Transform component."
    • For components in the Entities package, write in lowercase. If there is any possibility of confusion with regular GameObject components, then make sure you are explicit about what you mean.
  • compute: When discussing the act of a computer evaluating a process, use "compute" to refer to processes that are complex or long, that use logic or loops, or where the evaluation method is unspecified. For most processes carried out by Unity products, prefer the term "compute" over the related term "calculate." Related term: calculate.
  • connector (visual scripting): Write as a regular noun in lowercase.
  • core platform: Write as a regular noun in lowercase.
  • coroutine: Write as a regular noun in lowercase.
  • could: Don't use this word because it can cause ambiguity. Be more precise about what the user can do or can expect. Rarely, when you can't be explicit because something is uncertain, use "might."
  • cross-platform: Write with a hyphen.
  • cubemap: Write as one word in lowercase when referring to both the general concept of cubemaps and cubemap assets in Unity.

D​

  • D-pad: Short for directional pad. Write "D-pad," with a capital D.
  • data input, data output: When referring to the generic concept, write in lowercase. For Shader Graph, when referring to UI labels in the Graph Inspector window, write in bold as shown in the UI.
  • data-oriented technology stack (DOTS): The combination of technologies and packages that work together to deliver a data-oriented approach to coding in Unity. Write out in full on the first use. Use this term to refer only to Unity's collection of packages and systems that are based on the entity-component-system (ECS) architecture. Don't use this term to refer to data-oriented design or programming in general.
  • deactivate: Use "deactivate" when referring to GameObjects. Write "disable" when referring to components and other settings. Don't write "Turn off." Related term: activate.
  • decompressed: Use "decompressed" only in the context of an action happening to an item. For example, "the decompressed file" is a file that was compressed and has been processed so that it's no longer compressed. If you want to refer to a file that is not compressed, use "uncompressed." Related term: uncompressed.
  • descendant:
    • Use "descendant" as a noun to refer an item that is lower down in a hierarchy compared to another. For example, "The leaf GameObject is a descendant of the plant GameObject". Prefer using "child" where possible.
    • Use "descendant" as an adjective to describe something that moves downwards. For example, "The ball begins a descendant trajectory." While "descendent" is a correct spelling of the adjective form, for consistency, use "descendant." Prefer using another adjective, such as "downward," where possible.
  • deselect: Use "deselect" in user instructions to refer to canceling the selection of features or items such as checkboxes, keyframes, and GameObjects. Don't use "unselect."
  • #define directive: Write out fully as "#define directive."
  • deprecated: Use "deprecated" to refer to features and functionalities that are due to be removed in later versions of Unity, or packages that are no longer supported. Always direct the user to the newer or better functionality if possible. If a feature is currently supported and safe to use, but a replacement is planned for it in the future, use "marked for deprecation." For APIs that are unsupported or due to be removed, use "obsolete" instead.
  • dialog: Use "dialog" when you can't avoid referring to a specific dialog. Don't use "dialog box," "pop-up," or other alternatives. For more information, refer to Microsoft Style Guide: dialog box, dialog, dialogue.
  • digital twin: Write in lowercase when referring to a virtual model of a physical object. Write as a proper noun when referring to the Digital Twin team.
  • disable: Write "disable" when referring to components and other settings. Write "deactivate" when referring to GameObjects. Related term: enable.
  • display (verb): Use "display" instead of "show," unless referring to the name of a UI element.
  • docs: Use "documentation" instead of "docs," unless referring to the name of a UI element. If space is limited in the UI, use "Docs" instead of "Documentation."
  • dots per inch (dpi): Dots per inch is a unit of resolution or density for printed formats. Don't use this term unless referring to API names or UI elements that use it. Use "pixels per inch (ppi)" to refer to screen density. Related term: pixels per inch (ppi).
  • drag (verb): Use "drag" in user instructions. Don't use "drag and drop." If the user needs to drag with an alternative mouse button, use "right-click and drag" or "middle-click and drag." For more information, refer to Microsoft Style Guide: drag, drag and drop.
  • dummy: Don't use. Instead, use "placeholder" or "sample." For example, "placeholder text," "sample code."

E​

  • e.g.: Don't use. Instead, use "for example," "such as," or "like," as appropriate.
  • editor, Editor: Write as a proper noun when referring to the Unity Editor. Write as a regular noun in lowercase when referring to editors inside the Unity Editor, such as the Curve editor.
  • enable: Write "enable" when referring to components and other settings. Write "activate" when referring to GameObjects. Related term: disable.
  • Entities: The name of the package that contains Unity's data-oriented technology stack. Use this term only to refer to the package as a whole.
  • entity: Write in lowercase when referring to an entity type in the Entities package.
  • entity command buffer (ECB): A queue of commands used to schedule and replay changes in the Entities package. Write out in full on the first use, in lowercase. You can use the initialism on subsequent uses.
  • entity component system (ECS): The underlying architecture of Unity’s data oriented technology stack, delivered in the package named Entities. Use only when you need to specifically refer to the underlying technology. Write out in full on the first use, in lowercase. Hyphenate the full term when used as an adjective. For example, "entity-component-system architecture."
  • erroring out: Don't use. Instead, use "produces an error" or "results in an error."
  • Ethernet: Write as a proper noun, with a capital E.
  • extended reality (XR): XR is an umbrella term, encompassing virtual reality (VR), augmented reality (AR), and Windows Mixed Reality (WMR) applications. Write XR when discussing concepts that apply to more than one type of application. Related terms: augmented reality (AR), virtual reality (VR).
    • When referring to the general concept, write "extended reality" out in full on first use as a regular noun in lowercase. For example, "produce an extended reality environment." If you use the term multiple times in the same page, define the initialism on first use and write "XR" on subsequent uses.

F​

  • file name, filename: Write as two separate words as a noun. Hyphenate as an adjective. For example, "file-name conventions." When referring to a UI label that uses "filename," write in bold with the same capitalization as in the UI.
  • first-person shooter (FPS): Write in lowercase when you write it out in full ("first-person shooter"), and in uppercase as an acronym ("FPS"). Write it out in full the first time you use it, followed by the acronym in brackets. Don't use an acronym if the reader might confuse it to mean "frames per second."
  • flow (visual scripting): Write as a regular noun in lowercase.
  • the following: Only use phrases like "the following..." if the thing that follows is in the next line.
  • foo bar, foobar, fubar: Never write these terms as placeholders or example text. Instead, write something that is clearly an example, such as "ExampleFile.png" or "ExampleFolder/ExampleProject."
  • for example: The phrase "For example" typically appears at the beginning of a sentence. Write "For example" sentences so that they contain a verb and can stand as a full sentence without the phrase "For example." Don't use a semi-colon before the phrase "for example." Start a new sentence instead. The following sentence is an example:
    • "The overview displays information about what the user needs to do before they can access an interface. For example, if the user needs to open the menu interface, it displays prerequisites for accessing the menu interface."
  • frame rate: Write as two separate words, as a regular noun in lowercase.
  • frames per second (fps): Write in lowercase when you write it out in full ("frames per second"), and in lowercase as an acronym ("fps"). Use "fps" only as a unit when you are referring to a specific numeric frame rate. Write it out in full the first time you use it, followed by the acronym in brackets. Don't use an acronym if the reader might confuse it to mean first-person shooter. The following sentences are examples:
    • "Frame rate is expressed in frames per second."
    • "The target frame rate is 60 frames per second (fps). If your frame rate is less than 60 fps..."
  • front end, front-end: Whenever possible, don't use in content for a general audience. Instead, refer to the program by name, or use interface, application, app, or another specific and accurate term. Use these terms only in content for a technical audience. Related term: back end.
    • When using as a noun, write as two words. For example, the TreeView "front end."
    • When using as an adjective, write as two hyphenated words. For example, "front-end development," "front-end server."
  • front face, front-face: Write as two hyphenated words as an adjective. For example, "front-face culling," "front-facing geometry." Write as two words as a noun. For example, "the front face of the GameObject." Related term: back-face.
  • full screen, full-screen: Write as two words when using as a noun. Hyphenate when using as an adjective. For more information, refer to Microsoft Style Guide: full screen, full-screen.
  • function: Don't write "function" to refer to class methods. Try to avoid using the word "function" to mean "work," if the user might confuse it with the programming definition of the word. In property tables, use the headings "Property" and "Description" instead of "Property" and "Function" or "Method."
  • fuzzy finder: **Write as two words, as a regular noun in lowercase.

G​

  • game: In almost all situations, use "application" or "app" to refer to the software that the user is developing. Don't use "game" unless a game is the only thing a user can make with the information on the page, such as in some platform-specific documentation. Related term: application/app.
  • Game view: Use to refer to the Game tab or window in the Unity Editor, generally the view that the player sees when the game is playing. Write "Game" in bold with a capital letter because the Game view is part of the Editor UI.
  • GameObject: Write as one word, with a capital G and O.
  • GameObject header: The header of a GameObject is the topmost section of a GameObject’s Inspector window. It contains the name of the GameObject, the icon selection tool, and the Tag and Layer dropdown menus. Write "header" as a regular noun in lowercase.
  • gameplay: Write as a regular noun in lowercase, one word. Don't write as two words.
  • garbage collection: Write out in full. Don't abbreviate to "GC."
  • Git: Write as a proper noun when referring to the Git revision control system. When directly referring to the git command, format in lowercase and monospace font.
  • gizmo:
    • When referring to gizmos in general, write as a regular noun in lowercase.
    • When referring to a specific gizmo, capitalize the name of the gizmo but not the word "gizmo." For example, "Rect Transform gizmo," "Scene gizmo," "Camera gizmo," and "Light Direction gizmo." Always bold the name of gizmos, because they are UI items.
    • When referring to UI components such as the Gizmos menu or the Gizmos button, capitalize the G and bold the term.
    • When referring to the API class, write "Gizmos" in monospace font.
  • graph, Graph (visual scripting):
    • Write as a regular noun in lowercase ("graph") when referring to script graphs or state graph assets.
    • Write as a proper noun in bold ("Graph") when referring named UI elements such as the Graph window, Graph Inspector window, and Graph toolbar (the toolbar at the top of the Graph window).
  • Graph Inspector window: For the Visual Scripting UI, write "Graph Inspector" as a proper noun in bold, followed by "window." For example, "Graph Inspector window."
  • group (visual scripting): Write as a regular noun in lowercase.
  • grayboxing: Write as a regular noun in lowercase, one word. Don't write as two words.
  • grayed out: Write "grayed out" to describe UI elements that are disabled from use.

H​

  • hand coding, hand-coded: Use to refer to code typed by hand, as opposed to code generated via visual scripting systems. Don't use "handwritten" or "handwritten code." Hyphenate when using as an adjective. For example, "hand-coded script."
  • High Definition Render Pipeline (HDRP):
    • Write in full the first time you use it, with "HDRP" in parentheses directly afterwards. After that, you can just use "HDRP."
    • Write "the High Definition Render Pipeline," but write "HDRP" as a standalone noun, without the "the."
    • Don't write "High Definition RP" or "HD Render Pipeline."
  • head-mounted: Hyphenate as an adjective.
  • Hierarchy window: Write "Hierarchy" in bold with a capital H, followed by "window" in lowercase. For example, "Hierarchy window."

I​

  • i.e.: Don't use. Instead, use "in other words."
  • ID: You can write "ID" as shorthand for "identification." Write it in capital letters ("ID") unless it appears this way in the Editor or API you are referring to.
  • in-app purchase (IAP): Write "in-app purchase" (regular noun in lowercase), or "IAP" (all-caps) as an acronym. Write it out in full the first time you use it. The only exceptions are when you are talking about the Unity IAP service (because "Unity IAP" is the brand name of the service) or if it appears differently in the Editor.
  • inline values (visual scripting): Write as a regular noun in lowercase, two words.
  • input (visual scripting): Write as a regular noun in lowercase.
  • indices: Use "indices" only in the context of mathematical expressions. Don't use as the plural form of "index." Instead, use "indexes."
  • Inspector window: Write "Inspector" in bold with a capital I, followed by "window" in lowercase. For example, "Inspector window."

J​

  • job: Write in lowercase to refer to jobs in the parallel job system. When referring to specific API job implementation, use monospace and the same name as the specific implentation, for example, IJob.
  • job scheduler: Write in lowercase. When referring to the job scheduler API, write Schedule.
  • job system: Write in lowercase. You can also write "Unity job system."
  • just-in-time (JIT): Write in lowercase. Write out in full the first time. On subsequent uses, you can write the initialism in capital letters. If you use the initialism, define it on first use. For example, "just-in-time (JIT)." Related term: ahead-of-time (AOT).

L​

  • launch screen: An iOS launch screen is a file from which iOS creates a splash screen dynamically on the target device. Write as a regular noun in lowercase, unless referring to how it appears in the UI.
  • layer: Write as a regular noun in lowercase.
  • legacy: Don't refer to a feature as "legacy" unless it is part of the feature's name. For example, the Legacy Animation system, Legacy shaders. If the feature or functionality is unsupported, or due to be unsupported in a future release of Unity, use deprecated. If you are referring to an API that is unsupported or which has been replaced, use obsolete.
  • level of detail (LOD): Write in lowercase when you write it out in full ("level of detail"), and in uppercase as an acronym ("LOD"). Write it out in full the first time you use it, followed by the acronym in brackets.
  • lifecycle: Write as one word.
  • light, Light: Write as a proper noun only when referring to the Light component or when capitalized within a UI label. Write in bold only when referring to a specific UI label. Write as a regular noun in lowercase when referring to a GameObject that is a light and when discussing the general concept of lights.
  • light mode: Write as a regular noun in lowercase when discussing the concept in general. Capitalize and bold "mode" only when referring to the Mode property in the Light component UI.
    • baked lights: Write as a regular noun in lowercase to refer to Light components whose Mode property is Baked.
    • mixed lights: Write as a regular noun in lowercase to refer to Light components whose Mode property is Mixed.
    • realtime lights: Write as a regular noun in lowercase to refer to Light components whose Mode property is Realtime.
  • Lighting Mode: Write as a proper noun in bold to refer to the UI property in the Lighting Settings asset inspector that determines the behavior of all mixed lights in a scene.
  • lightmap: Write as one word, as a regular noun in lowercase.
  • Look Dev: Write as a proper noun. Don't refer to it as "LookDev," "lookdev" or "the Look Dev." However, you can refer to the window in which Look Dev opens as "the Look Dev window."

M​

  • may: Don't use this word because it can cause ambiguity. Be more precise about what the user can do or can expect. Rarely, when you can't be explicit because something is uncertain, use "might."
  • machine (visual scripting): Write as a regular noun in lowercase.
  • macOS: The current Mac operating system. Apple stylizes the name as one word with lowercase m and uppercase OS. Don't write variations such as MacOS, Mac OS, Mac OS X.
  • Made with Unity splash screen: Refer to it as the "Made with Unity splash screen" the first time you refer to it. After the first use, you can just write "the splash screen."
  • Main Stage: Write as a proper noun when referring to the Main Stage in Unity that contains all the current scenes. Write "MainStage" when referring to the API class.
  • manifest: Write as a regular noun in lowercase "manifest." For example, refer to the file AndroidManifest.xml as the "Android manifest."
  • master: Don't use. For more information, refer to Microsoft Style Guide: master/slave.
  • Matchmaker: Write Unity Matchmaker to refer to the multiplayer matchmaking service in Unity Multiplay. Write "matchmaker" in lowercase to refer to the general concept of matchmakers.
  • material: Write in lowercase, unless referring to the exact names of APIs, UI, or dialogs that capitalize this word.
  • Mecanim: The old name for Unity's animation system. Unity no longer uses Mecanim, so where possible avoid using the word, except where it might be relevant. For example, in legacy documentation.
  • mesh: Write in lowercase, unless you are referring to a UI label in which is it capitalized. In that case, write in bold and use the same capitalization as the UI.
  • methods: When you write a C# method, write only the name, without empty brackets. For example, "A Create method activates the subsystem."
  • microfacets: Write as one word, as a regular noun in lowercase.
  • might: Use this word rarely and only when you can't be explicit because something is uncertain. As much as possible, avoid this word because it can cause ambiguity.
  • minimap: Write as one word, as a regular noun in lowercase.
  • mipmap: Write as a regular noun in lowercase.
  • model: Write as a regular noun in lowercase unless referring to instances in the Editor UI where it appears as a proper noun. In that case, write in bold and use the same capitalization as the UI. For example, the Model tab.
  • modules: Write the name of the module as a proper noun, and the word "module" in lowercase. For example, write "Noise module," not "noise module" or "Noise Module."
  • multi: Don't hyphenate words that begin with multi. For more information, refer to the Microsoft Style Guide: multi-.
  • multiplatform: Write as one word, "multiplatform," not "multi-platform" or "multi platform."
  • multiplayer, Unity Multiplayer: Write as one word, "multiplayer." Don't write "multi-player" or "multi player." Only write as a proper noun if you are referring to the Unity Multiplayer service.

N​

  • navigation bar: Write when in full when referring to a vertical or horizontal menu on a webpage. Don't abbreviate to "navbar." Only use this term in the doc when absolutely necessary. Make sure that you are also following the general guidance to avoid references to locations within the UI. For more information, refer to User interactions.
  • NavMesh Agent, NavMeshAgent: Write "NavMesh Agent component" when referring to the component. Write "NavMeshAgent" when referring to the class in the API. Write "NavMesh agent" when referring to the GameObject that has the NavMesh Agent component attached.
  • new, currently: Avoid these words. Wherever possible, aim to make sure that content is not time-sensitive. For more information, refer to Past, present, and future tense.
  • node: Write as a regular noun in lowercase, unless referring to an element in the UI where it is capitalized. In that case, write in bold and use the same capitalization as the UI.
  • normal: Write as a regular noun in lowercase.
  • normal map: Write as a regular noun in lowercase, two words.

O​

  • once: Don't use as a conjunction to mark a point in time. For example, "Once you've done X, do Y." Instead, use "after" or rewrite your sentence to be more direct.
  • object: Don't use if there is the possibility of ambiguity between GameObjects and the type of objects you're writing about. Good alternatives are "item" or "instance" (when referring to a specific example of a class).
  • obsolete: Use only to refer to APIs that have been marked obsolete in code. Obsolete means that either the API is unsupported and no longer in use, or that it is due to be removed. For features and functionalities that are no longer supported, or due to be removed in later versions of Unity, use "deprecated." If a feature or functionality is currently supported and safe to use, but a replacement is planned for it in the future, use "marked for deprecation."
  • output (visual scripting): Write as a regular noun in lowercase.

P​

  • package: Write in lowercase, except if it appears differently in the Editor. For example, "Package Manager."
  • page: Write "page" or "webpage" to describe one of a collection of web documents that make up a website. Write "page" to refer to the page the reader is on, or to a specific page, such as the home page or start page. Related term: site.
  • parent: Always specify what the parent item is. For example, "parent GameObject" or "Item 1 is the parent GameObject of Item 2." Don't use "parents" as a verb. Related term: child.
  • particle: Write as a regular noun when referring to individual particles.
  • particle system: Write in lowercase when referring to the general concept of particle systems, or to the collection of particle systems available in Unity. Write "Built-in Particle System" in full with capitals when you refer to the Built-in Particle System in Unity. Write "ParticleSystem" when you refer to the Built-in Particle System API. Don't refer to the Built-in Particle System as "Shuriken."
  • pass: A "pass" is a component of a shader. Related term: shaders.
    • When referring both to shader passes in general and to a specific pass within a shader, write as a regular noun in lowercase.
    • When referring to the code block in ShaderLab that defines a pass, write Pass.
  • PC: Don't write "PC." Where applicable, name the specific operating systems you're referring to.
  • Perspective gizmo: The gizmo in the top-right-hand corner of the Scene view which controls perspective. Write "Perspective" in bold with a capital P, followed by "gizmo" in lowercase.
  • Physics material, Physics Material:
    • Write "Physics material" when referring to the material type that determines the physical properties of colliders.
    • Write "Physics Material" in bold when referring to UI labels where both words are capitalized.
    • Write "PhysicsMaterial" when referring to the scripting API.
  • Physically Based Renderer: Write out in full the first time you use it on a page, and include the abbreviation in brackets. For example, "Physically Based Renderer (PBR)." Don't hyphenate.
  • Physically Based Shader: Write out in full the first time you use it on a page, and include the abbreviation in brackets. For example, "Physically Based Shader (PBS)." Don't hyphenate. Use Physically Based Shader only if you are specifically and exclusively discussing shaders and the materials that those shaders are applied to. In all other cases, write Physically Based Renderer.
  • physics system: Write in lowercase. Don't write "physics engine" or "PhysX."
  • pixel: Write as a regular noun in lowercase.
  • pixels per inch (ppi): Write in lowercase when you write it out in full ("pixels per inch"), and in lowercase as an acronym ("ppi"). Use "ppi" only as a unit when you are referring to a specific numeric resolution. Write it out in full the first time you use it, followed by the acronym in brackets.
  • Play mode: Write "Play mode" when referring to the view that lets users run their game in the editor.
  • playback: When used as a noun or adjective, write as one word. When used as a verb, write as two words. For example, "Use the playback controls to play back the video recording."
  • player: Don't use "player" to refer to the end-user of an application. Instead, use "user." The exception to this rule is for specific platforms that are exclusively used for games applications. Try to reduce the usage of "player" as much as possible in these cases.
  • Player: Write as a proper noun when referring to the Unity Player in general and when referring to Players for specific platforms. For example, "the Windows Standalone Player."
  • PlayStation 4, PlayStation 5: Write in full as "PlayStation 4" or "PlayStation 5" the first time you refer to it on a page. After the first use, you can write "PS4" or "PS5."
  • please: Don't use "please" except in situations where the user is asked to do something inconvenient or the application or site is to blame for the situation. For example, "The network connection was lost. Please enter your password again."
  • plug-in: Write as a regular noun in lowercase, with a hyphen, when referring to plug-in software components.
  • postmortem: Don't use this term. Use "root cause analysis" or "project retrospective" instead.
  • post-processing: Write "post-processing" unless you are referring to a feature name or UI label, in which case follow that style. For example, "Post Processing Stack package."
  • prefab: Write as a regular noun in lowercase.
  • prefab editing mode: Use this term to refer to the Unity Editor mode in which you edit prefabs. Write in lowercase. Don't use "Prefab Mode"—this term does not refer to any UI labels and is not descriptive.
  • prefab stage: Write as a regular noun in lowercase when referring to the editing context for prefab assets in the Unity Editor. Write "PrefabStage" when referring to the API class.
  • preview panel: Write in lowercase to describe the preview area in the Inspector window. If the specific preview panel you are discussing has a generic title that is not the name of the previewed item, then you can also use the title in bold to refer to the preview panel.
  • Progressive Lightmapper: Use this term to refer to both of the lightmappers available in Unity at the same time: the Progressive CPU Lightmapper and the Progressive GPU Lightmapper. Don't use Progressive Lightmapper to refer to one of the lightmappers; instead, be specific about which one you mean.
  • project: Write as a regular noun in lowercase, including when referring to a Unity project.
  • Project window: Write "Project" in bold with a capital P, followed by "window" in lowercase.
  • PS4 Pro: Write "PS4 Pro," never just "Pro." Following this guidance respects Sony's brand decision and avoids ambiguity with Unity's Pro subscription.

Q​

  • query: For queries in the Entities package, write in lowercase. When referring to a specific query API, use monospace font and the exact capitalization of the API. For example, "EntityQuery."
  • quickstart: Write as one word, as a regular noun in lowercase.

R​

  • ray cast, ray casting: Write as a regular noun in lowercase, two words, no hyphen, unless you are referring to the Raycast API.
  • ray trace, ray tracing: Write as a regular noun in lowercase, two words, no hyphen.
  • real time, real-time, Realtime:
    • "real time" is a noun. For example, "updated in real time."
    • "real-time" is a compound adjective. For example, "real-time lighting."
    • "Realtime" refers to the Realtime Light Mode.
  • real world, real-world:
    • "real world" is a noun. For example, "a surface in the real world."
    • "real-world" is a compound adjective. For example, "a real-world surface."
  • recommend: Don't write "we recommend" or "Unity recommends." Instead, use "The recommended best practice is..." or a similar construction. Use only if you can specify why we recommend a specific best practice.
  • Relay: Write Unity Relay when referring to the Unity Relay package. When referring to servers and services related to Unity Relay, capitalize the name of the service/server but not the word service/server. For example, "Relay server," "Relay Allocations service."
  • renderer: Write as a regular noun when referring to the renderer module of a particle system. Write as "Renderer" when referring to the API class.
  • repository, repositories: Write as a regular noun in lowercase, and write out in full. Don't shorten to "repo."
  • Rigidbody (plural): Avoid referring to a Rigidbody without a qualifying noun. Instead, write "Rigidbody component" or "Rigidbody GameObject." When discussing multiple Rigidbody components or GameObjects, write "Rigidbody components" or "Rigidbody GameObjects." Don't write "Rigidbodies" or "Rigidbodys."
  • roadmap: Write as one word. Don't write "road map" or "road-map."
  • rollback, roll back: As a noun or adjective, write as one word. For example, "Apply the rollback." As a verb, write as two words. For example, "Roll back the version."
  • root cause analysis: Write in full in all contexts. Don't abbreviate as RCA. Don't include a hyphen.
  • runtime: Write as one word in all contexts. Don't use "run time" or "run-time." For more information, refer to Microsoft Style Guide: runtime.

S​

  • sanity check: Don't use. Instead, depending on the context, use one of the following alternatives: "consistency check," "logic check," "final check," or "final pass," "quick check," "confidence check," "preliminary check," or "coherence check."
  • scene: Write as a regular noun in lowercase when referring to a scene.
  • Scene view: Use this term to refer to the Scene tab or window in the Unity Editor: the main view users use when building games. Write "Scene" in bold with a capital S, followed by "view" in lowercase.
  • screen space: Write as two words, as a regular noun in lowercase.
  • script graph, Script Graph: Write as two words. Write in lowercase when referring to script graphs as a general concept. Write as a proper noun with capitals and in bold when referring to the Script Graph window or UI labels that use "Script Graph."
  • script machine, Script Machine: Write as two words. Write in lowercase when referring to script machine as a general concept. Write as a proper noun with capitals when referring to the Script Machine component.
  • script state: Write as two words, as a regular noun. Write in lowercase when referring to script graphs as a general concept. When referring to UI labels that use "Script State," write in bold and use the same capitalization as the UI.
  • shaders: The term "shader" is commonly used as a synonym for many things, such as "shader program," "Unity shader," "shader asset." This term can be ambiguous when used without qualification. It's okay to use "shader" in titles and headings. Otherwise, use more precise terms to clarify meaning, especially in introductions.
    • shader: Write in lowercase, unless referring to APIs, UI, product, or feature names that capitalize this word.
    • Unity shader: Capitalize "Unity" but not "shader." Use to refer to the Unity-specific concept that contains shader programs, commands to set the render state, and other information.
    • shader program: Write in lowercase. Use to refer to a program that runs on the GPU. For shader programs that perform compute work, refer to "compute shader."
    • compute shader: Write in lowercase. Use to refer to a program that runs on the GPU outside of the rendering-related shader stages and doesn't necessarily perform rendering-related tasks.
    • Standard shader: Write as two words, with "Standard" capitalized and "shader" in lowercase. Use to refer to the built-in Unity shaders used in the Built-in Render Pipeline.
    • subshader: Write as one word in lowercase. Write "SubShader" to refer to the scripting block that defines a subshader. A "SubShader" is a specific part of a "Unity shader."
    • Related terms: Pass, material.
  • ShaderLab: Write as a proper noun, capital S and L, as one word
  • shader graph, Shader Graph: Write as two words, as a proper noun when referring to the name of the package and the tool for visual shader development. Write in lowercase to refer to the output graph that defines the shader.
  • shadow map: Write as two words in lowercase.
  • shadow mask, Shadowmask: Write as two words in lowercase when referring to the concept of shadow masks and shadow masking, including the specific shadow mask lightmap. When referring to UI settings and properties, write in bold exactly as it appears in the UI, typically "Shadowmask."
  • should: Don't use this word because it can cause ambiguity. Be more precise about what the user can do or can expect.
  • show (verb): Use "display" instead of "show," unless you are referring to the name of a UI element.
  • SIE: Write "Sony Interactive Entertainment (SIE)" in full on first use. On subsequent uses, you can use the initialism "SIE." SIE was formerly known as Sony Computer Entertainment (SCE). Never write "SCE."
  • simmed: Don't use. Instead, use "simulated."
  • since: Don't use the word "since" because it can have multiple meanings. Use "because" instead as it has one clear meaning.
  • site: Use "website" instead of "site" to refer to a collection of web documents located under a single domain. Don't use "site" to refer to a single webpage. Use "webpage" or "page" instead. Related term: page
  • size (image): There are two different types of image size: the size of the image in pixels, and the size of the image in bytes.
    • When referring to the image size in pixels, refer to it as such. For example, "The image size must not exceed 600×600 pixels."
    • When referring to the image size in bytes, write "file size." For example, "The image file size must not exceed 2 KB."
  • slave: Don't use. For more information, refer to Microsoft Style Guide: master/slave.
  • SpeedTree: Write as one word, capital S, capital T.
  • sprite: Write as a regular noun in lowercase, unless referring to an element in the UI where it is capitalized. In that case, write in bold and use the same capitalization as the UI. For example, "Sprite Editor window."
  • standalone:
    • When using as an adjective to refer to specific software and devices, write "standalone" as one word. For example, "standalone application."
    • When using as an adjective in more general context, write "stand-alone" as two words joined by a hyphen. For example, "stand-alone feature."
    • When using as a verb, write as two separate words. For example, "The feature must stand alone."
    • When referring to UI elements that use the word "Standalone", write in bold exactly as it appears in the Editor.
  • Standard Assets: Write as a proper noun when referring to the Unity Standard Assets asset package.
  • state (visual scripting): Write as a regular noun in lowercase.
  • state graph, State Graph: Write as two words. Write in lowercase when referring to state graphs as a general concept. Write as a proper noun with capitals and in bold when referring to UI labels that use "State Graph."
  • state machine, State Machine: Write as two words. Write in lowercase when referring to state machine as a general concept. Write as a proper noun with capitals when referring to the State Machine component.
  • subasset: Write as "subasset" when referring to an asset which is dependent on another asset.
  • subgraph (visual scripting): Write as a regular noun in lowercase when referring to the general concept of subgraphs. Write as a proper noun when referring to a specific type of subgraph. For example, "System Subgraph," "Block Subgraph," "Operator Subgraph."
  • subemitter:
    • When referring to the general concept of subemitters, write "subemitter."
    • When referring to the Sub Emitter module or other UI elements that use a variation on this term, write in bold, exactly as it appears in the Editor.
  • subscene: The GameObject authoring context for the Entities package. Write as a single word, in lowercase.
  • super unit: The old term for a subgraph. Don't use this term. Replace this term in your content, except in legacy documentation.
  • system: Write in lowercase when referring to a system in the Entities package. When referring to a specific system API, use monospace font and the exact capitalization of the API. For example, "ISystem" and "SystemBase."

T​

  • tag: Write as a regular noun in lowercase. Write the name of the tag in monospace, exactly as it appears in script. For example, "Pass tag."
  • tangent: Write as a regular noun in lowercase.
  • team: When you refer to a team at Unity, capitalize the name of the team, but not the word "team." For example, "the Documentation team."
  • template: Write as a regular noun in lowercase. Don't capitalize except when referring to a specific UI element. In that case, write in bold and use the same capitalization as the UI.
  • terrain, Terrain: Write as a regular noun in lowercase when referring to terrains as a general concept. Write as a proper noun when referring to the Terrain Tools package, the Terrain component and Terrain Collider component. Write as a proper noun in bold when referring to UI elements that use "Terrain."
  • terrain layer: Write as a regular noun in lowercase.
  • texel: Write as a regular noun in lowercase.
  • texture: Write as a regular noun in lowercase, except when referring to UI elements that use "Texture." In that case, write in bold and use the same capitalization as the UI.
  • theme: Use "Dark theme" and "Light theme" to refer to the two different color schemes in Unity. Don't use "skin."
  • third-party: Hyphenate when using as an adjective. For example, "a third-party feature." Don't hyphenate when using as a noun. For example, "A feature by a third party."
  • title: Don't use this term to refer to the final end-product. Instead, use "application" or "app" (mobile device products only). The exception to this rule is documentation for specific platforms such as PlayStation that use "title" to refer to the end-product. Related terms: application, game.
  • tile: Write as a regular noun in lowercase.
  • tilemap, Tilemap: Write as a single word. When referring to the general concept of tilemaps, write "tilemap" as a regular noun in lowercase. When referring to the tilemapping system components, write "Tilemap component" and "Tilemap Renderer component."
  • tone mapping, Tonemapping: When referring to the general concept of tone mapping, write "tone mapping" as a regular noun in lowercase, two words. When referring to UI elements that use "Tonemapping" as a single word, write in bold, exactly as it appears in the UI.
  • tooltip: Write as one word.
  • touchpad, trackpad: In general, don't talk about specific input devices unless absolutely necessary. If you can't avoid it, then use "touchpad." For more information, refer to Microsoft Style Guide: Computer and device terms.
  • transition, Transition: Write as a regular noun in lowercase when referring to the general concept of transitions, transitions in visual scripting, and animation transitions, state machine transitions, Animator Controller transitions, or UI transitions. Write with a capital in bold when referring to UI elements that use "Transition."
  • Transition timeline: Write "Transition timeline" to refer to the timeline graph in the Animator Transition Inspector window.
  • Trigger Input, Trigger Output: Write as shown in the Graph Inspector window.
  • true, false: Only use in an API context. Don't write true/false as a way to describe checkboxes. Instead, use "enabled" and "disabled." Don't apply any text formatting to "true" or "false."

U​

note

For terminology relating to Unity features, services, and teams, refer to Unity features and services.

  • uncompressed: Use "uncompressed" as an adjective. For example, "the uncompressed file" is a file that is not compressed. The history of the file (whether or not it has been compressed) is unclear or unimportant. Related term: decompressed.
  • unit (visual scripting): Don't use this term. It's the old term for a node and is no longer in use. Replace this term in your content, except in legacy documentation.
    • In Unity, unit names are not the same in the fuzzy finder and the unit headers in visual scripts. Refer to fuzzy finder names only in context of the fuzzy finder, and unit header names when referring to a unit that is already in a visual script.
    • Visual Scripting automatically inserts spaces in PascalCase names. Don't use PascalCase when referring to units unless it is used in the fuzzy finder or unit header.
  • Universal Render Pipeline (URP):
    • Write in full the first time you use it, with "URP" in parentheses directly afterwards. After that, you can just use "URP."
    • Write "the Universal Render Pipeline," but write "URP" as a standalone noun, without the "the."
    • Don't write "Universal RP."
  • utilize: Don't use this word. Instead, write "use."
  • user-friendly: Hyphenate as an adjective.

V​

  • variables (visual scripting): Capitalize the scope of the variable, but not the word "variable." For example,"Graph variable," "Object variable," "Scene variable."
  • Vector 3, Vector 2 (visual scripting): Write as shown in the UI when referring directly to the node name as it appears on the fuzzy finder or node header.
  • VFX Graph: Write as "VFX Graph" when referring to the package and to the output asset.
  • virtual reality (VR): Related terms: augmented reality (AR), extended reality(XR)
    • When referring to the general concept, write "virtual reality" out in full on first use as a regular noun in lowercase. For example, "produce a virtual reality environment." If you use the term multiple times in the same page, define the initialism on first use and write "VR" on subsequent uses.
    • When referring to UI elements that use "Virtual Reality," write in bold and use the same capitalization as the UI.
    • If you are discussing topics that apply to both VR and augmented reality (AR), write "extended reality (XR)."
  • visual scripting, Visual Scripting: Write as two words.
    • Write as a regular noun in lowercase when referring to the general concept of visual scripting, or to the activity of producing code with the Visual Scripting tool.
    • Write as a proper noun when referring to the Unity Visual Scripting package and tool.

W​

  • webpage: Write "webpage" or "page" to describe one of a collection of web documents that make up a website. Write "page" to refer to the page the reader is on, or to a specific page, such as the home page or start page.
  • website: Use "website" instead of "site" to refer to a collection of web documents located under a single domain. Don't use "site" to refer to a single webpage. Use "webpage" or "page" instead.
  • white label: Don't use this term to refer to blank or unbranded products or assets. Instead, use "unbranded."
  • whitelist: Don't use this term. Instead, use "allowlist." For more information, refer to Microsoft Style Guide: whitelist.
  • window: Write all windows in the Unity Editor with the name of the tab as a proper noun in bold, followed by the word "window" as a regular noun in lowercase in regular font. For example, write "Inspector window," "Project window," "Hierarchy window." The only exceptions are Game and Scene, which are written as "Game view" and "Scene view."
  • wish: Don't use "wish." Use "want" instead. For example, "if you want to select another scene..."
  • workaround: Avoid this word as much as possible. Instead give advice specific to what the user is trying to do. For example, instead of "For a workaround, refer to X," write "For details on how to do Y, refer to X."
  • workflow: Write as one word, as a regular noun in lowercase.
  • world: Write in lowercase when referring to a world in the Entities package.
  • world space: Write as two words, as a regular noun in lowercase.
  • would: Don't use this word because it can cause ambiguity. Be more precise about what the user can do or can expect.

X​