└── README.md
/README.md:
--------------------------------------------------------------------------------
1 | # Unity Style Guide
2 |
3 | This article contains ideas for setting up a projects structure and a naming convention for scripts and assets in Unity.
4 |
5 |
6 | ## Table of Contents
7 |
8 | > 1. [Introduction](#introduction)
9 | > 1. [Project Structure](#structure)
10 | > 1. [Scripts](#scripts)
11 | > 1. [Asset Naming Conventions](#anc)
12 | > 1. [Asset Workflows](#asset-workflows)
13 |
14 |
15 | ## 1. Introduction
16 |
17 | ### Sections
18 |
19 | > 1.1 [Style](#style)
20 |
21 | > 1.2 [Important Terminology](#importantterminology)
22 |
23 |
24 | ### 1.1 Style
25 |
26 | #### If your project already has a style guide, you should follow it.
27 | If you are working on a project or with a team that has a pre-existing style guide, it should be respected. Any inconsistency between an existing style guide and this guide should defer to the existing.
28 |
29 | Style guides should be living documents however and you should propose style guide changes to an existing style guide as well as this guide if you feel the change benefits all usages.
30 |
31 | > ##### *Arguments over style are pointless. There should be a style guide, and you should follow it.*
32 | > [_Rebecca Murphey_](https://rmurphey.com)
33 |
34 | #### All structure, assets, and code in any project should look like a single person created it, no matter how many people contributed.
35 | Moving from one project to another should not cause a re-learning of style and structure. Conforming to a style guide removes unneeded guesswork and ambiguities.
36 |
37 | It also allows for more productive creation and maintenance as one does not need to think about style, simply follow instructions. This style guide is written with best practices in mind, meaning that by following this style guide you will also minimize hard to track issues.
38 |
39 | #### Friends do not let friends have bad style.
40 | If you see someone working either against a style guide or no style guide, try to correct them.
41 |
42 | When working within a team or discussing within a community, it is far easier to help and to ask for help when people are consistent. Nobody likes to help untangle someone's spaghetti code or deal with assets with names they can't understand.
43 |
44 | If you are helping someone who's work conforms to a different but consistent and sane style guide, you should be able to adapt to it. If they do not conform to any style guide, please direct them here.
45 |
46 |
47 | ### 1.2 Important Terminology
48 |
49 |
50 | #### Prefabs
51 | Unity uses the term Prefab for a system that allows you to create, configure, and store a GameObject complete with all its components, property values, and child GameObjects as a reusable Asset.
52 |
53 |
54 | #### Levels/Maps/Scene
55 | Levels refer to what some people call maps or what Unity calls Scenes. A level contains a collection of objects.
56 |
57 |
58 | #### Serializable
59 | Variables that are Serializable are shown in the Inspector window in Unity. For more information see Unity's documentation on [Serializable](https://docs.unity3d.com/Manual/script-Serialization.html).
60 |
61 |
62 | #### Cases
63 | There are a few different ways you can name things. Here are some common casing types:
64 |
65 | > ##### PascalCase
66 | > Capitalize every word and remove all spaces, e.g. `DesertEagle`, `StyleGuide`, `ASeriesOfWords`.
67 | >
68 | > ##### camelCase
69 | > The first letter is always lowercase but every following word starts with uppercase, e.g. `desertEagle`, `styleGuide`, `aSeriesOfWords`.
70 | > ##### lowercase
71 | > All letters are lowercase, e.g. `deserteagle`,
72 | >
73 | > ##### Snake_case
74 | > Words can arbitrarily start upper or lowercase but words are separated by an underscore, e.g. `desert_Eagle`, `Style_Guide`, `a_Series_of_Words`.
75 |
76 | **[⬆ Back to Top](#table-of-contents)**
77 |
78 |
79 | ## 2. Project Structure
80 | The directory structure style of a project should be considered law. Asset naming conventions and content directory structure go hand in hand, and a violation of either causes unneeded chaos.
81 |
82 | In this style, we will be using a structure that relies more on filtering and search abilities of the Project Window for those working with assets to find assets of a specific type instead of another common structure that groups asset types with folders.
83 |
84 | > Using a prefix [naming convention](#asset-name-modifiers), using folders to contain assets of similar types such as `Meshes`, `Textures`, and `Materials` is a redundant practice as asset types are already both sorted by prefix as well as able to be filtered in the content browser.
85 |
86 | > IMPORTANT: Development Assets (work in progress or testing assets contained in `_Dev`) should always be prefixed with a `_` to make it easy when configuring things in the inspector
87 |
88 | Assets
89 | _Dev(Use a `_`to keep this folder at the top)
90 | DeveloperName
91 | (Work in progress assets)
92 | ProjectName
93 | Characters
94 | Anakin
95 | FX
96 | Particles
97 | Vehicles
98 | Abilities
99 | IonCannon
100 | (Particle Systems, Textures)
101 | Weapons
102 | Gameplay
103 | Characters
104 | Equipment
105 | Input
106 | Triggers
107 | Quests
108 | Scene
109 | Vehicles
110 | Abilities
111 | Air
112 | TieFighter
113 | (Models, Textures, Materials, Prefabs)
114 | _Levels
115 | Frontend
116 | Act1
117 | Level1
118 | Lighting
119 | HDRI
120 | Lut
121 | Textures
122 | MaterialLibrary
123 | Debug
124 | Shaders
125 | Objects
126 | Architecture (Single use big objects)
127 | DeathStar
128 | Props (Repeating objects to fill a level)
129 | ObjectSets
130 | DeathStar
131 | Scripts
132 | AI
133 | Gameplay
134 | Triggers
135 | Quests
136 | Input
137 | Tools
138 | Sound
139 | Characters
140 | Vehicles
141 | TieFighter
142 | Abilities
143 | Afterburners
144 | Weapons
145 | UI
146 | Art
147 | Buttons
148 | Resources
149 | Fonts
150 | ExpansionPack (DLC)
151 | Plugins
152 | ThirdPartySDK
153 |
154 |
155 |
156 |
157 |
158 | The reasons for this structure are listed in the following sub-sections.
159 |
160 | ### Sections
161 |
162 | > 2.1 [Folder Names](#structure-folder-names)
163 |
164 | > 2.2 [Top-Level Folders](#structure-top-level)
165 |
166 | > 2.3 [Developer Folders](#structure-developers)
167 |
168 | > 2.4 [Levels](#levels)
169 |
170 | > 2.5 [Define Ownership](#structure-ownership)
171 |
172 | > 2.6 [`Assets` and `AssetTypes`](#structure-assettypes)
173 |
174 | > 2.7 [Large Sets](#structure-large-sets)
175 |
176 | > 2.8 [Material Library](#structure-material-library)
177 |
178 | > 2.9 [Scene Structure](#scene-structure)
179 |
180 |
181 |
182 |
183 | ### 2.1 Folder Names
184 | These are common rules for naming any folder in the content structure.
185 |
186 |
187 | #### Always Use [PascalCase](#terms-cases)
188 | PascalCase refers to starting a name with a capital letter and then instead of using spaces, every following word also starts with a capital letter. For example, `DesertEagle`, `RocketPistol`, and `ASeriesOfWords`.
189 |
190 |
191 | #### Never Use Spaces
192 | Re-enforcing [2.1.1](#2.1.1), never use spaces. Spaces can cause various engineering tools and batch processes to fail. Ideally your project's root also contains no spaces and is located somewhere such as `D:\Project` instead of `C:\Users\My Name\My Documents\Unity Projects`.
193 |
194 |
195 | #### Never Use Unicode Characters And Other Symbols
196 | If one of your game characters is named 'Zoë', its folder name should be `Zoe`. Unicode characters can be worse than [Spaces](#2.1.2) for engineering tools and some parts applications don't support Unicode characters in paths either.
197 |
198 | Related to this, if your project has and your computer's user name has a Unicode character (i.e. your name is `Zoë`), any project located in your `My Documents` folder will suffer from this issue. Often simply moving your project to something like `D:\Project` will fix these mysterious issues.
199 |
200 | Using other characters outside `a-z`, `A-Z`, and `0-9` such as `@`, `-`, `_`, `,`, `*`, and `#` can also lead to unexpected and hard to track issues on other platforms, source control, and weaker engineering tools.
201 |
202 |
203 | #### No Empty Folders
204 | There simply shouldn't be any empty folders. They clutter the content browser.
205 |
206 | If you find that the content browser has an empty folder you can't delete, you should perform the following:
207 | 1. Be sure you're using source control.
208 | 1. Navigate to the folder on-disk and delete the assets inside.
209 | 1. Close the editor.
210 | 1. Make sure your source control state is in sync (i.e. if using Perforce, run a Reconcile Offline Work on your content directory)
211 | 1. Open the editor. Confirm everything still works as expected. If it doesn't, revert, figure out what went wrong, and try again.
212 | 1. Ensure the folder is now gone.
213 | 1. Submit changes to source control.
214 |
215 |
216 |
217 | ### 2.2 Use A Top Level Folder For Project Specific Assets
218 | All of a project's assets should exist in a folder named after the project. For example, if your project is named 'Generic Shooter', _all_ of it's content should exist in `Assets/GenericShooter`.
219 |
220 | > The `Developers` folder is not for assets that your project relies on and therefore is not project specific. See [Developer Folders](#2.3) for details about this.
221 |
222 | There are multiple reasons for this approach.
223 |
224 |
225 | #### No Global Assets
226 | Often in code style guides it is written that you should not pollute the global namespace and this follows the same principle. When assets are allowed to exist outside of a project folder it often becomes much harder to enforce a strict structure layout as assets not in a folder encourages the bad behavior of not having to organize assets.
227 |
228 | Every asset should have a purpose, otherwise it does not belong in a project. If an asset is an experimental test and shouldn't be used by the project it should be put in a [`Developer`](#2.3) folder.
229 |
230 |
231 | #### Reduce Migration Conflicts
232 | When working on multiple projects it is common for a team to copy assets from one project to another if they have made something useful for both.
233 |
234 | By placing all project specific assets in a top level folder you reduce the chance of migration conflict when importing those assets into a new project.
235 |
236 |
237 | ##### Master Material Example
238 | For example, say you created a master material in one project that you would like to use in another project so you migrated that asset over. If this asset is not in a top level folder, it may have a name like `Assets/MaterialLibrary/M_Master`. If the target project doesn't have a master material already, this should work without issue.
239 |
240 | As work on one or both projects progress their respective master materials may change to be tailored for their specific projects due to the course of normal development.
241 |
242 | The issue comes when, for example, an artist for one project created a nice generic modular set of static meshes and someone wants to include that set of static meshes in the second project. If the artist who created the assets used material instances based on `Assets/MaterialLibrary/M_Master` as they're instructed to, when a migration is performed there is a great chance of conflict for the previously migrated `Assets/MaterialLibrary/M_Master` asset.
243 |
244 | This issue can be hard to predict and hard to account for. The person migrating the static meshes may not be the same person who is familiar with the development of both project's master material, and they may not be even aware that the static meshes in question rely on material instances which then rely on the master material. The Migrate tool requires the entire chain of dependencies to work however, and so it will be forced to grab `Assets/MaterialLibrary/M_Master` when it copies these assets to the other project and it will overwrite the existing asset.
245 |
246 | It is at this point where if the master materials for both projects are incompatible in _any way_, you risk breaking possibly the entire material library for a project as well as any other dependencies that may have already been migrated, simply because assets were not stored in a top level folder. The simple migration of static meshes now becomes a very ugly task.
247 |
248 |
249 | #### Samples, Templates, and 3rd Party Content Are Risk-Free
250 | An extension to [2.2.2](#2.2.2), if a team member decides to add sample content, template files, or assets they bought from a 3rd party, it is guaranteed that these new assets will not interfere with the project in any way unless your project's top level folder is not uniquely named.
251 |
252 | You can not trust 3rd party content to fully conform to the [top level folder rule](#2.2). There exist many assets that have the majority of their content in a top level folder but also have possibly modified Unity sample content as well as level files polluting the global `Assets` folder.
253 |
254 | When adhering to [2.2](#2.2), the worst 3rd party conflict you can have is if two 3rd party assets both have the same sample content. If all your assets are in a project specific folder, including sample content you may have moved into your folder, your project will never break.
255 |
256 | #### DLC, Sub-Projects, and Patches Are Easily Maintained
257 | If your project plans to release DLC or has multiple sub-projects associated with it that may either be migrated out or simply not cooked in a build, assets relating to these projects should have their own separate top level content folder. This make cooking DLC separate from main project content far easier. Sub-projects can also be migrated in and out with minimal effort. If you need to change a material of an asset or add some very specific asset override behavior in a patch, you can easily put these changes in a patch folder and work safely without the chance of breaking the core project.
258 |
259 |
260 |
261 | ### 2.3 Use Developers Folder For Local Testing
262 | During a project's development, it is very common for team members to have a sort of 'sandbox' where they can experiment freely without risking the core project. Because this work may be ongoing, these team members may wish to put their assets on a project's source control server. Not all teams require use of Developer folders, but ones that do use them often run into a common problem with assets submitted to source control.
263 |
264 | It is very easy for a team member to accidentally use assets that are not ready for use which will cause issues once those assets are removed. For example, an artist may be iterating on a modular set of static meshes and still working on getting their sizing and grid snapping correct. If a world builder sees these assets in the main project folder, they might use them all over a level not knowing they could be subject to incredible change and/or removal. This causes massive amounts of re-working by everyone on the team to resolve.
265 |
266 | If these modular assets were placed in a Developer folder, the world builder should never of had a reason to use them and the whole issue would never happen.
267 |
268 | Once the assets are ready for use, an artist simply has to move the assets into the project specific folder. This is essentially 'promoting' the assets from experimental to production.
269 |
270 |
271 |
272 | ### 2.4 All [Scene](#terms-level-map) Files Belong In A Folder Called Levels
273 | Level files are incredibly special and it is common for every project to have its own map naming system, especially if they work with sub-levels or streaming levels. No matter what system of map organization is in place for the specific project, all levels should belong in `Assets/ProjectNameName/Levels`.
274 |
275 | Being able to tell someone to open a specific map without having to explain where it is is a great time saver and general 'quality of life' improvement. It is common for levels to be within sub-folders of `Levels`, such as `Levels/Campaign1/` or `Levels/Arenas`, but the most important thing here is that they all exist within `Assets/ProjectNameName/Levels`.
276 |
277 | This also simplifies the job of cooking for engineers. Wrangling levels for a build process can be extremely frustrating if they have to dig through arbitrary folders for them. If a team's levels are all in one place, it is much harder to accidentally not cook a map in a build. It also simplifies lighting build scripts as well QA processes.
278 |
279 |
280 |
281 | ### 2.5 Define Ownership
282 | In teams of more than one, define ownership of zone/assets/features. Some assets like scenes or prefabs do not handle simultaneous changes by multiple people very well, creating conflict. Having a single person who can change (or give the right to change) a given assets helps to avoid that problem.
283 |
284 |
285 |
286 | ### 2.6 Do Not Create Folders Called `Assets` or `AssetTypes`
287 |
288 |
289 | #### Creating a folder named `Assets` is redundant.
290 | All assets are assets.
291 |
292 |
293 | #### Creating a folder named `Meshes`, `Textures`, or `Materials` is redundant.
294 | All asset names are named with their asset type in mind. These folders offer only redundant information and the use of these folders can easily be replaced with the robust and easy to use filtering system the Content Browser provides.
295 |
296 | Want to view only static mesh in `Environment/Rocks/`? Simply turn on the Static Mesh filter. If all assets are named correctly, they will also be sorted in alphabetical order regardless of prefixes. Want to view both static meshes and skeletal meshes? Simply turn on both filters. this eliminates the need to potentially have to `Control-Click` select two folders in the Content Browser's tree view.
297 |
298 | > This also extends the full path name of an asset for very little benefit. The `SM_` prefix for a static mesh is only three characters, whereas `Meshes/` is seven characters.
299 |
300 | Not doing this also prevents the inevitability of someone putting a static mesh or a texture in a `Materials` folder.
301 |
302 |
303 |
304 | ### 2.7 Very Large Asset Sets Get Their Own Folder Layout
305 |
306 | This can be seen as a pseudo-exception to [2.6](#2.6).
307 |
308 | There are certain asset types that have a huge volume of related files where each asset has a unique purpose. The two most common are Animation and Audio assets. If you find yourself having 15+ of these assets that belong together, they should be together.
309 |
310 | For example, animations that are shared across multiple characters should lay in `Characters/Common/Animations` and may have sub-folders such as `Locomotion` or `Cinematic`.
311 |
312 | > This does not apply to assets like textures and materials. It is common for a `Rocks` folder to have a large amount of textures if there are a large amount of rocks, however these textures are generally only related to a few specific rocks and should be named appropriately. Even if these textures are part of a [Material Library](#2.8).
313 |
314 |
315 |
316 | ### 2.8 `MaterialLibrary`
317 |
318 | If your project makes use of master materials, layered materials, or any form of reusable materials or textures that do not belong to any subset of assets, these assets should be located in `Assets/ProjectName/MaterialLibrary`.
319 |
320 | This way all 'global' materials have a place to live and are easily located.
321 |
322 | > This also makes it incredibly easy to enforce a 'use material instances only' policy within a project. If all artists and assets should be using material instances, then the only regular material assets that should exist are within this folder. You can easily verify this by searching for base materials in any folder that isn't the `MaterialLibrary`.
323 |
324 | The `MaterialLibrary` doesn't have to consist of purely materials. Shared utility textures, material functions, and other things of this nature should be stored here as well within folders that designate their intended purpose. For example, generic noise textures should be located in `MaterialLibrary/Utility`.
325 |
326 | Any testing or debug materials should be within `MaterialLibrary/Debug`. This allows debug materials to be easily stripped from a project before shipping and makes it incredibly apparent if production assets are using them if reference errors are shown.
327 |
328 |
329 |
330 | ## 2.9 Scene Structure
331 | Next to the project’s hierarchy, there’s also scene hierarchy. As before, we’ll present you a template. You can adjust it to your needs. Use named empty game objects as scene folders.
332 |
333 |
334 | @System
335 | @Debug
336 | @Management
337 | @UI
338 | Layouts
339 | Cameras
340 | Lights
341 | Volumes
342 | Particles
343 | Sound
344 | World
345 | Global
346 | Room1
347 | Architecture
348 | Terrain
349 | Props
350 | Gameplay
351 | Actors
352 | Items
353 | Triggers
354 | Quests
355 | _Dynamic
356 |
357 |
358 | - All empty objects should be located at 0,0,0 with default rotation and scale.
359 | - For empty objects that are only containers for scripts, use “@” as prefix – e.g. @Cheats
360 | - When you’re instantiating an object in runtime, make sure to put it in _Dynamic – do not pollute the root of your hierarchy or you will find it difficult to navigate through it.
361 |
362 | **[⬆ Back to Top](#table-of-contents)**
363 |
364 |
365 |
366 | ## 3. Scripts
367 |
368 | This section will focus on C# classes and their internals. When possible, style rules conform to Microsoft's C# standard.
369 |
370 | ### Sections
371 | > 3.1 [Class Organization](#classorganization)
372 |
373 | > 3.2 [Compiling](#compiling)
374 |
375 | > 3.3 [Variables](#variables)
376 |
377 | > 3.4 [Functions](#functions)
378 |
379 |
380 | ### 3.1 Class Organization
381 | Source files should contain only one public type, although multiple internal classes are allowed.
382 |
383 | Source files should be given the name of the public class in the file.
384 |
385 | Organize namespaces with a clearly defined structure,
386 |
387 | Class members should be alphabetized, and grouped into sections:
388 | * Constant Fields
389 | * Static Fields
390 | * Fields
391 | * Constructors
392 | * Properties
393 | * Events / Delegates
394 | * LifeCycle Methods (Awake, OnEnable, OnDisable, OnDestroy)
395 | * Public Methods
396 | * Private Methods
397 | * Nested types
398 |
399 | Within each of these groups order by access:
400 | * public
401 | * internal
402 | * protected
403 | * private
404 | ```
405 | namespace ProjectName
406 | {
407 | ///
408 | /// Brief summary of what the class does
409 | ///
410 | public class Account
411 | {
412 | #region Fields
413 |
414 | [Tooltip("Public variables set in the Inspector, should have a Tooltip")]
415 | public static string BankName;
416 |
417 | ///
418 | /// They should also have a summary
419 | ///
420 | public static decimal Reserves;
421 |
422 | public string BankName;
423 | public const string ShippingType = "DropShip";
424 |
425 | private float _timeToDie;
426 |
427 | #endregion
428 |
429 | #region Properties
430 |
431 | public string Number {get; set;}
432 | public DateTime DateOpened {get; set;}
433 | public DateTime DateClosed {get; set;}
434 | public decimal Balance {get; set;}
435 |
436 | #endregion
437 |
438 | #region LifeCycle
439 |
440 | public Awake()
441 | {
442 | // ...
443 | }
444 |
445 | #endregion
446 | #region Public Methods
447 |
448 | public AddObjectToBank()
449 | {
450 | // ...
451 | }
452 |
453 | #endregion
454 | }
455 | }
456 | ```
457 |
458 | #### Script Templates
459 | To save some time you can overwrite Unity's default script template with your own to automatically setup the namespace and regions etc. See this Unity [support](https://support.unity3d.com/hc/en-us/articles/210223733-How-to-customize-Unity-script-templates) article to learn how.
460 |
461 |
462 | #### Namespace
463 | Use a namespace to ensure your scoping of classes/enum/interface/etc won't conflict with existing ones from other namespaces or the global namespace. The project should at minimum use the projects name for the Namespace to prevent conflicts with any imported Third Party assets.
464 |
465 | #### All Public Functions Should Have A Summary
466 |
467 | Simply, any function that has an access modifier of Public should have its summary filled out.
468 |
469 | ```
470 | ///
471 | /// Fire a gun
472 | ///
473 | public void Fire()
474 | {
475 | // Fire the gun.
476 | }
477 | ```
478 |
479 | #### Foldout Groups
480 | If a class has only a small number of variables, Foldout Groups are not required.
481 |
482 | If a class has a moderate amount of variables (5-10), all [Serializable](#serializable) variables should have a non-default Foldout Group assigned. A common category is `Config`.
483 |
484 | To create Foldout Groups there are 2 options in Unity.
485 |
486 | * The first is to define a `[Serializable] public Class` inside the main class however this can have a performance impact. This allows the use of the same variable name to be shared.
487 | * The second option is to use the Foldout Group Attribute available with [Odin Inspector](https://odininspector.com/).
488 |
489 | ```
490 | [[Serializable](https://docs.unity3d.com/ScriptReference/Serializable.html)]
491 | public struct PlayerStats
492 | {
493 | public int MovementSpeed;
494 | }
495 |
496 | [FoldoutGroup("Interactable")]
497 | public int MovementSpeed = 1;
498 | ```
499 |
500 | #### Commenting
501 | Comments should be used to describe intention, algorithmic overview, and/or logical flow.
502 | It would be ideal if from reading the comments alone someone other than the author could understand a function’s intended behavior and general operation.
503 |
504 | While there are no minimum comment requirements and certainly some very small routines need no commenting at all, it is hoped that most routines will have comments reflecting the programmer’s intent and approach.
505 |
506 | ##### Comment Style
507 | Place the comment on a separate line, not at the end of a line of code.
508 |
509 | Begin comment text with an uppercase letter.
510 |
511 | End comment text with a period.
512 |
513 | Insert one space between the comment delimiter (//) and the comment text, as shown in the following example.
514 |
515 | The // (two slashes) style of comment tags should be used in most situations. Where ever possible, place comments above the code instead of beside it. Here are some examples:
516 | ```
517 | // Sample comment above a variable.
518 | private int _myInt = 5;
519 | ```
520 |
521 | #### Regions
522 | The `#region` directive enables you to collapse and hide sections of code in C# files. The ability to hide code selectively makes your files more manageable and easier to read.
523 | ```
524 | #region "This is the code to be collapsed"
525 | Private components As System.ComponentModel.Container
526 | #endregion
527 | ```
528 |
529 | #### Spacing
530 | Do use a single space after a comma between function arguments.
531 |
532 | Example: `Console.In.Read(myChar, 0, 1);`
533 | * Do not use a space after the parenthesis and function arguments.
534 | * Do not use spaces between a function name and parenthesis.
535 | * Do not use spaces inside brackets.
536 |
537 |
538 | ### 3.2 Compiling
539 | All scripts should compile with zero warnings and zero errors. You should fix script warnings and errors immediately as they can quickly cascade into very scary unexpected behavior.
540 |
541 | Do *not* submit broken scripts to source control. If you must store them on source control, shelve them instead.
542 |
543 | ### 3.3 Variables
544 | The words `variable` and `property` may be used interchangeably.
545 |
546 | #### Variable Naming
547 |
548 | ##### Nouns
549 | All non-boolean variable names must be clear, unambiguous, and descriptive nouns.
550 |
551 | ##### Case
552 | All variables use PascalCase unless marked as [private](#privatevariables) which use camelCase.
553 |
554 | Use PascalCase for abbreviations of 4 characters or more (3 chars are both uppercase).
555 |
556 | ##### Considered Context
557 | All variable names must not be redundant with their context as all variable references in the class will always have context.
558 |
559 | ###### Considered Context Examples:
560 | Consider a Class called `PlayerCharacter`.
561 |
562 | **Bad**
563 |
564 | * `PlayerScore`
565 | * `PlayerKills`
566 | * `MyTargetPlayer`
567 | * `MyCharacterName`
568 | * `CharacterSkills`
569 | * `ChosenCharacterSkin`
570 |
571 | All of these variables are named redundantly. It is implied that the variable is representative of the `PlayerCharacter` it belongs to because it is `PlayerCharacter` that is defining these variables.
572 |
573 | **Good**
574 |
575 | * `Score`
576 | * `Kills`
577 | * `TargetPlayer`
578 | * `Name`
579 | * `Skills`
580 | * `Skin`
581 |
582 | #### Variable Access Level
583 | In C#, variables have a concept of access level. Public means any code outside the class can access the variable. Protected means only the class and any child classes can access this variable internally. Private means only this class and no child classes can access this variable.
584 | Variables should only be made public if necessary.
585 |
586 | Prefer to use the attribute `[SerializeField]` instead of making a variable public.
587 |
588 | ##### Local Variables
589 | Local variables should use camelCase.
590 |
591 | ###### Implicitly Typed Local Variables
592 | Use implicit typing for local variables when the type of the variable is obvious from the right side of the assignment, or when the precise type is not important.
593 | ```
594 | var var1 = "This is clearly a string.";
595 | var var2 = 27;
596 | var var3 = Convert.ToInt32(Console.ReadLine());
597 | // Also used in for loops
598 | for (var i = 0; i < bountyHunterFleets.Length; ++i) {};
599 | ```
600 |
601 | Do not use var when the type is not apparent from the right side of the assignment.
602 | Example
603 | ```
604 | int var4 = ExampleClass.ResultSoFar();
605 | ```
606 |
607 |
608 | ##### Private Variables
609 | Private variables should have a prefix with a underscore `_myVariable` and use camelCase.
610 |
611 | Unless it is known that a variable should only be accessed within the class it is defined and never a child class, do not mark variables as private. Until variables are able to be marked `protected`, reserve private for when you absolutely know you want to restrict child class usage.
612 |
613 | ##### Do _Not_ use Hungarian notation
614 | Do _not_ use Hungarian notation or any other type identification in identifiers
615 | ```
616 | // Correct
617 | int counter;
618 | string name;
619 |
620 | // Avoid
621 | int iCounter;
622 | string strName;
623 | ```
624 |
625 | #### Variables accessible in the Editor
626 |
627 | ##### Tooltips
628 | All [Serializable](#serializable) variables should have a description in their `[Tooltip]` fields that explains how changing this value affects the behavior of the script.
629 |
630 | ##### Variable Slider And Value Ranges
631 | All [Serializable](#serializable) variables should make use of slider and value ranges if there is ever a value that a variable should _not_ be set to.
632 |
633 | Example: A script that generates fence posts might have an editable variable named `PostsCount` and a value of -1 would not make any sense. Use the range fields `[Range(min, max)]` to mark 0 as a minimum.
634 |
635 | If an editable variable is used in a Construction Script, it should have a reasonable Slider Range defined so that someone can not accidentally assign it a large value that could crash the editor.
636 |
637 | A Value Range only needs to be defined if the bounds of a value are known. While a Slider Range prevents accidental large number inputs, an undefined Value Range allows a user to specify a value outside the Slider Range that may be considered 'dangerous' but still valid.
638 |
639 | #### Variable Types
640 |
641 | ##### Booleans
642 |
643 | ###### Boolean Prefix
644 | All booleans should be named in PascalCase but prefixed with a verb.
645 |
646 | Example: Use `isDead` and `hasItem`, **not** `Dead` and `Item`.
647 |
648 | ###### Boolean Names
649 | All booleans should be named as descriptive adjectives when possible if representing general information.
650 |
651 | Try to not use verbs such as `isRunning`. Verbs tend to lead to complex states.
652 |
653 | ###### Boolean Complex States
654 | Do not use booleans to represent complex and/or dependent states. This makes state adding and removing complex and no longer easily readable. Use an enumeration instead.
655 |
656 | Example: When defining a weapon, do **not** use `isReloading` and `isEquipping` if a weapon can't be both reloading and equipping. Define an enumeration named `WeaponState` and use a variable with this type named `WeaponState` instead. This makes it far easier to add new states to weapons.
657 |
658 | ##### Enums
659 | Enums use PascalCase and use singular names for enums and their values. Exception: bit field enums should be plural. Enums can be placed outside the class space to provide global access.
660 |
661 | Example:
662 | ```
663 | public enum WeaponType
664 | {
665 | Knife,
666 | Gun
667 | }
668 |
669 | // Enum can have multiple values
670 | [Flags]
671 | public enum Dockings
672 | {
673 | None = 0,
674 | Top = 1,
675 | }
676 |
677 | public WeaponType Weapon
678 | ```
679 |
680 | ##### Arrays
681 | Arrays follow the same naming rules as above, but should be named as a plural noun.
682 |
683 | Example: Use `Targets`, `Hats`, and `EnemyPlayers`, not `TargetList`, `HatArray`, `EnemyPlayerArray`.
684 |
685 | ##### Interfaces
686 | Interfaces are led with a capital `I` then followed with PascalCase.
687 |
688 | Example: ```public interface ICanEat { }```
689 |
690 |
691 | ### 3.4 Functions, Events, and Event Dispatchers
692 | This section describes how you should author functions, events, and event dispatchers. Everything that applies to functions also applies to events, unless otherwise noted.
693 |
694 | #### Function Naming
695 | The naming of functions, events, and event dispatchers is critically important. Based on the name alone, certain assumptions can be made about functions. For example:
696 |
697 | * Is it a pure function?
698 | * Is it fetching state information?
699 | * Is it a handler?
700 | * What is its purpose?
701 |
702 | These questions and more can all be answered when functions are named appropriately.
703 |
704 |
705 | #### All Functions Should Be Verbs
706 | All functions and events perform some form of action, whether its getting info, calculating data, or causing something to explode. Therefore, all functions should start with verbs. They should be worded in the present tense whenever possible. They should also have some context as to what they are doing.
707 |
708 | Good examples:
709 |
710 | * `Fire` - Good example if in a Character / Weapon class, as it has context. Bad if in a Barrel / Grass / any ambiguous class.
711 | * `Jump` - Good example if in a Character class, otherwise, needs context.
712 | * `Explode`
713 | * `ReceiveMessage`
714 | * `SortPlayerArray`
715 | * `GetArmOffset`
716 | * `GetCoordinates`
717 | * `UpdateTransforms`
718 | * `EnableBigHeadMode`
719 | * `IsEnemy` - ["Is" is a verb.](http://writingexplained.org/is-is-a-verb)
720 |
721 | Bad examples:
722 |
723 | * `Dead` - Is Dead? Will deaden?
724 | * `Rock`
725 | * `ProcessData` - Ambiguous, these words mean nothing.
726 | * `PlayerState` - Nouns are ambiguous.
727 | * `Color` - Verb with no context, or ambiguous noun.
728 |
729 | #### Functions Returning Bool Should Ask Questions
730 | When writing a function that does not change the state of or modify any object and is purely for getting information, state, or computing a yes/no value, it should ask a question. This should also follow [the verb rule](#function-verbrule).
731 |
732 | This is extremely important as if a question is not asked, it may be assumed that the function performs an action and is returning whether that action succeeded.
733 |
734 | Good examples:
735 |
736 | * `IsDead`
737 | * `IsOnFire`
738 | * `IsAlive`
739 | * `IsSpeaking`
740 | * `IsHavingAnExistentialCrisis`
741 | * `IsVisible`
742 | * `HasWeapon` - ["Has" is a verb.](http://grammar.yourdictionary.com/parts-of-speech/verbs/Helping-Verbs.html)
743 | * `WasCharging` - ["Was" is past-tense of "be".](http://grammar.yourdictionary.com/parts-of-speech/verbs/Helping-Verbs.html) Use "was" when referring to 'previous frame' or 'previous state'.
744 | * `CanReload` - ["Can" is a verb.](http://grammar.yourdictionary.com/parts-of-speech/verbs/Helping-Verbs.html)
745 |
746 | Bad examples:
747 |
748 | * `Fire` - Is on fire? Will fire? Do fire?
749 | * `OnFire` - Can be confused with event dispatcher for firing.
750 | * `Dead` - Is dead? Will deaden?
751 | * `Visibility` - Is visible? Set visibility? A description of flying conditions?
752 |
753 | #### Event Handlers and Dispatchers Should Start With `On`
754 | Any function that handles an event or dispatches an event should start with `On` and continue to follow [the verb rule](#function-verbrule).
755 |
756 | Good examples:
757 |
758 | * `OnDeath` - Common collocation in games
759 | * `OnPickup`
760 | * `OnReceiveMessage`
761 | * `OnMessageRecieved`
762 | * `OnTargetChanged`
763 | * `OnClick`
764 | * `OnLeave`
765 |
766 | Bad examples:
767 |
768 | * `OnData`
769 | * `OnTarget`
770 |
771 | **[⬆ Back to Top](#table-of-contents)**
772 |
773 |
774 |
775 | ## 4. Asset Naming Conventions
776 | Naming conventions should be treated as law. A project that conforms to a naming convention is able to have its assets managed, searched, parsed, and maintained with incredible ease.
777 |
778 | Most things are prefixed with the prefix generally being an acronym of the asset type followed by an underscore.
779 |
780 | **Assets use [PascalCase](#cases)**
781 |
782 |
783 |
784 | ### 4.1 Base Asset Name - `Prefix_BaseAssetName_Variant_Suffix`
785 | All assets should have a _Base Asset Name_. A Base Asset Name represents a logical grouping of related assets. Any asset that is part of this logical group
786 | should follow the the standard of `Prefix_BaseAssetName_Variant_Suffix`.
787 |
788 | Keeping the pattern `Prefix_BaseAssetName_Variant_Suffix` in mind and using common sense is generally enough to warrant good asset names. Here are some detailed rules regarding each element.
789 |
790 | `Prefix` and `Suffix` are to be determined by the asset type through the following [Asset Name Modifier](#asset-name-modifiers) tables.
791 |
792 | `BaseAssetName` should be determined by short and easily recognizable name related to the context of this group of assets. For example, if you had a character named Bob, all of Bob's assets would have the `BaseAssetName` of `Bob`.
793 |
794 | For unique and specific variations of assets, `Variant` is either a short and easily recognizable name that represents logical grouping of assets that are a subset of an asset's base name. For example, if Bob had multiple skins these skins should still use `Bob` as the `BaseAssetName` but include a recognizable `Variant`. An 'Evil' skin would be referred to as `Bob_Evil` and a 'Retro' skin would be referred to as `Bob_Retro`.
795 |
796 | For unique but generic variations of assets, `Variant` is a two digit number starting at `01`. For example, if you have an environment artist generating nondescript rocks, they would be named `Rock_01`, `Rock_02`, `Rock_03`, etc. Except for rare exceptions, you should never require a three digit variant number. If you have more than 100 assets, you should consider organizing them with different base names or using multiple variant names.
797 |
798 | Depending on how your asset variants are made, you can chain together variant names. For example, if you are creating flooring assets for an Arch Viz project you should use the base name `Flooring` with chained variants such as `Flooring_Marble_01`, `Flooring_Maple_01`, `Flooring_Tile_Squares_01`.
799 |
800 |
801 | #### Examples
802 |
803 | ##### Character
804 |
805 | | Asset Type | Asset Name |
806 | | ------------------------ | ------------ |
807 | | Skeletal Mesh | SK_Bob |
808 | | Material | M_Bob |
809 | | Texture (Diffuse/Albedo) | T_Bob_D |
810 | | Texture (Normal) | T_Bob_N |
811 | | Texture (Evil Diffuse) | T_Bob_Evil_D |
812 |
813 | ##### Prop
814 |
815 | | Asset Type | Asset Name |
816 | | ------------------------ | ------------ |
817 | | Static Mesh (01) | SM_Rock_01 |
818 | | Static Mesh (02) | SM_Rock_02 |
819 | | Static Mesh (03) | SM_Rock_03 |
820 | | Material | M_Rock |
821 | | Material Instance (Snow) | MI_Rock_Snow |
822 |
823 |
824 | ### 4.2 Asset Name Modifiers
825 |
826 | When naming an asset use these tables to determine the prefix and suffix to use with an asset's [Base Asset Name](#base-asset-name).
827 |
828 | #### Sections
829 |
830 | > 4.2.1 [Most Common](#anc-common)
831 |
832 | > 4.2.2 [Animations](#anc-animations)
833 |
834 | > 4.2.3 [Artificial Intelligence](#anc-ai)
835 |
836 | > 4.2.4 [Prefabs](#anc-prefab)
837 |
838 | > 4.2.5 [Materials](#anc-materials)
839 |
840 | > 4.2.6 [Textures](#anc-textures)
841 |
842 | > 4.2.7 [Miscellaneous](#anc-misc)
843 |
844 | > 4.2.8 [Physics](#anc-physics)
845 |
846 | > 4.2.9 [Audio](#anc-audio)
847 |
848 | > 4.2.10 [User Interface](#anc-ui)
849 |
850 | > 4.2.11 [Effects](#anc-effects)
851 |
852 |
853 | #### Most Common
854 |
855 | | Asset Type | Prefix | Suffix | Notes |
856 | | ----------------------- | ---------- | ---------- | -------------------------------- |
857 | | Level / Scene | * | | [Should be in a folder called Levels.](#levels) e.g. `Levels/A4_C17_Parking_Garage.unity` |
858 | | Level (Persistent) | | _P | |
859 | | Level (Audio) | | _Audio | |
860 | | Level (Lighting) | | _Lighting | |
861 | | Level (Geometry) | | _Geo | |
862 | | Level (Gameplay) | | _Gameplay | |
863 | | Prefab | | | |
864 | | Probe (Reflection) | RP_ | | |
865 | | Probe (Light) | LP_ | | |
866 | | Volume | V_ | | |
867 | | Trigger Area | | _Trigger | |
868 | | Material | M_ | | |
869 | | Static Mesh | SM_ | | |
870 | | Skeletal Mesh | SK_ | | |
871 | | Texture | T_ | _? | See [Textures](#anc-textures) |
872 | | Visual Effects | VFX_ | | |
873 | | Particle System | PS_ | | |
874 | | Light | L_ | | |
875 | | Camera (Cinemachine) | CM_ | | Virtual Camera |
876 |
877 |
878 |
879 | #### 4.2.1a 3D Models (FBX Files)
880 |
881 | PascalCase
882 |
883 | | Asset Type | Prefix | Suffix | Notes |
884 | | ------------- | ------ | ------ | ----- |
885 | | Characters | CH_ | | |
886 | | Vehicles | VH_ | | |
887 | | Weapons | WP_ | | |
888 | | Static Mesh | SM_ | | |
889 | | Skeletal Mesh | SK_ | | |
890 | | Skeleton | SKEL_ | | |
891 | | Rig | RIG_ | | |
892 |
893 | #### 4.2.1b 3d Models (3ds Max)
894 |
895 | All meshes in 3ds Max are lowercase to differentiate them from their FBX export.
896 |
897 | | Asset Type | Prefix | Suffix | Notes |
898 | | ------------- | ------ | ----------- | --------------------------------------- |
899 | | Mesh | | _mesh_lod0* | Only use LOD suffix if model uses LOD's |
900 | | Mesh Collider | | _collider | |
901 |
902 |
903 |
904 | #### 4.2.2 Animations
905 | | Asset Type | Prefix | Suffix | Notes |
906 | | -------------------- | ------ | ------ | ----- |
907 | | Animation Clip | A_ | | |
908 | | Animation Controller | AC_ | | |
909 | | Avatar Mask | AM_ | | |
910 | | Morph Target | MT_ | | |
911 |
912 |
913 | #### 4.2.3 Artificial Intelligence
914 |
915 | | Asset Type | Prefix | Suffix | Notes |
916 | | ----------------------- | ---------- | ---------- | -------------------------------- |
917 | | AI / NPC | AI_ | _NPC | *Npc could be pawn of CH_ !AI_ |
918 | | Behavior Tree | BT_ | | |
919 | | Blackboard | BB_ | | |
920 | | Decorator | BTDecorator_ | | |
921 | | Service | BTService_ | | |
922 | | Task | BTTask_ | | |
923 | | Environment Query | EQS_ | | |
924 | | EnvQueryContext | EQS_ | Context | |
925 |
926 |
927 | #### 4.2.4 Prefabs
928 |
929 | | Asset Type | Prefix | Suffix | Notes |
930 | | ----------------------- | ---------- | ---------- | -------------------------------- |
931 | | Prefab | | | |
932 | | Prefab Instance | I | | |
933 | | Scriptable Object | | | Assigned "Blueprint" label in Editor |
934 |
935 |
936 |
937 | #### 4.2.5 Materials
938 | | Asset Type | Prefix | Suffix | Notes |
939 | | ----------------- | ------ | ------ | ----- |
940 | | Material | M_ | | |
941 | | Material Instance | MI_ | | |
942 | | Physical Material | PM_ | | |
943 | | Material Shader Graph | MSG_ | | |
944 |
945 |
946 |
947 | #### 4.2.6 Textures
948 | | Asset Type | Prefix | Suffix | Notes |
949 | | ----------------------- | ---------- | ---------- | -------------------------------- |
950 | | Texture | T_ | | |
951 | | Texture (Base Color) | T_ | _BC | Diffuse / Albedo |
952 | | Texture (Metallic / Smoothness)| T_ | _MS | |
953 | | Texture (Normal) | T_ | _N | |
954 | | Texture (Alpha) | T_ | _A | |
955 | | Texture (Height) | T_ | _H | |
956 | | Texture (Ambient Occlusion) | T_ | _AO | |
957 | | Texture (Emissive) | T_ | _E | |
958 | | Texture (Mask) | T_ | _M | |
959 | | Texture (Packed) | T_ | _* | See notes below about [packing](#anc-textures-packing). |
960 | | Texture Cube | TC_ | | |
961 | | Media Texture | MT_ | | |
962 | | Render Target | RT_ | | |
963 | | Cube Render Target | RTC_ | | |
964 | | Texture Light Profile | TLP_ | | |
965 |
966 |
967 |
968 | #### 4.2.6.1 Texture Packing
969 | It is common practice to pack multiple layers of texture data into one texture. An example of this is packing Emissive, Roughness, Ambient Occlusion together as the Red, Green, and Blue channels of a texture respectively. To determine the suffix, simply stack the given suffix letters from above together, e.g. `_ERO`.
970 |
971 | > It is generally acceptable to include an Alpha/Opacity layer in your Diffuse/Albedo's alpha channel and as this is common practice, adding `A` to the `_D` suffix is optional.
972 |
973 | Packing 4 channels of data into a texture (RGBA) is not recommended except for an Alpha/Opacity mask in the Diffuse/Albedo's alpha channel as a texture with an alpha channel incurs more overhead than one without.
974 |
975 |
976 | #### 4.2.7 Miscellaneous
977 |
978 | | Asset Type | Prefix | Suffix | Notes |
979 | | ------------------------------- | ------ | ------ | ----- |
980 | | Universal Render Pipeline Asset | URP_ | | |
981 | | HD Render Pipeline Asset | HDRP_ | | |
982 | | Post Process Volume Profile | PP_ | | |
983 | | User Interface | UI_ | | |
984 |
985 |
986 | #### 4.2.8 Physics
987 |
988 | | Asset Type | Prefix | Suffix | Notes |
989 | | ----------------- | ------ | ------ | ----- |
990 | | Physical Material | PM_ | | |
991 |
992 |
993 |
994 | #### 4.2.9 Audio
995 |
996 | | Asset Type | Prefix | Suffix | Notes |
997 | | -------------- | ------ | ------ | ------------------------------------------------------------ |
998 | | Audio Clip | A_ | | |
999 | | Audio Mixer | MIX_ | | |
1000 | | Dialogue Voice | DV_ | | |
1001 | | Audio Class | | | No prefix/suffix. Should be put in a folder called AudioClasses |
1002 |
1003 |
1004 | #### 4.2.10 User Interface
1005 | | Asset Type | Prefix | Suffix | Notes |
1006 | | ---------------- | ------ | ------ | ----- |
1007 | | Font | Font_ | | |
1008 | | Texture (Sprite) | T_ | _GUI | |
1009 |
1010 |
1011 | #### 4.2.11 Effects
1012 | | Asset Type | Prefix | Suffix | Notes |
1013 | | --------------- | ------ | ------ | ----- |
1014 | | Particle System | PS_ | | |
1015 | **[⬆ Back to Top](#table-of-contents)**
1016 |
1017 |
1018 |
1019 | ## 5. Asset Workflows
1020 |
1021 | This section describes best practices for creating and importing assets usable in Unity.
1022 |
1023 |
1024 | ### Sections
1025 |
1026 | > 5.1 [Unity Asset Import Settings](#unityimport)
1027 | >
1028 | > 5.2 [3ds Max](#3dsmax)
1029 | >
1030 | > 5.3 [Textures](#textures)
1031 | >
1032 | > 5.4 [Audio](#audio)
1033 |
1034 |
1035 |
1036 | ### 5.1 Unity Asset Import Settings
1037 |
1038 | Unity's [AssetPostprocessor](https://docs.unity3d.com/ScriptReference/AssetPostprocessor.html) lets you hook into the import pipeline and run scripts prior to or after importing assets. This allows you to enforce import settings when assets are first imported into the project. For example textures that end with `_N` can be marked as a Normal Map on import.
1039 |
1040 | Example guide for Import Settings:
1041 |
1042 | https://github.com/justinwasilenko/Unity-AssetPostProcessor
1043 |
1044 |
1045 | ### 5.2 3ds Max
1046 |
1047 | Unity guide on importing from 3ds Max:
1048 |
1049 | https://docs.unity3d.com/2017.4/Documentation/Manual/HOWTO-ImportObjectMax.html
1050 |
1051 | Unity tutorial on the FBX Exporter Package for FBX roundtrip:
1052 |
1053 | https://learn.unity.com/project/3ds-max-to-unity-pipeline
1054 |
1055 | #### Setting up 3ds Max
1056 |
1057 | Unity uses 1 unit = 1 meter. Setup 3ds Max to use Meters by going to ```Customize/Units Setup/System Unit Setup``` and set to 1 Unit = 1 Meter. Using the correct scale is very important for correct Physics / GI / and VR interaction.
1058 |
1059 | Animation frame rate in 3ds Max should be set to 30fps. The ```Time Configuration``` dialog box has 3ds Max's FPS settings
1060 |
1061 | ##### Working with Small Objects
1062 |
1063 | * Set ```Customize > Customize User Interface > Mouse Wheel Zoom Increment``` to 0.1m to stop over zooming
1064 |
1065 | * Turn on Viewport Clipping and set the slider on the side of the viewport to be able to zoom in on small meshes. (https://knowledge.autodesk.com/support/3ds-max/learn-explore/caas/sfdcarticles/sfdcarticles/Viewport-Clipping.html)
1066 |
1067 | #### Modeling in 3ds Max
1068 |
1069 | * Follow the [asset naming convention](#anc-models)
1070 | * Avoid super long thin triangles (Speeds up tile based renderers & helps with proper GI baking)
1071 | * Use Area and Angle Weighted Mesh Normals (Unity Import Setting or Create in 3ds Max)
1072 |
1073 | #### Exporting from 3ds Max into Unity
1074 |
1075 | ##### Export Settings:
1076 |
1077 | - Triangulate On
1078 | - Tangents and Binormals Off
1079 | - Smoothing Groups On
1080 | - Preserve edge orientation On
1081 | - Units - Automatic Off / Scene Units converted to Meters
1082 | - Axis Conversion Z-up
1083 |
1084 | Models created in 3ds Max use a different coordinate system then Unity. Models need to have their pivot point rotated +90 degrees on the X axis to import into Unity correctly.
1085 |
1086 | To do this quickly, open the MaxScript editor, paste this code and select and drag this code on to a Toolbar in 3ds Max to create a button that will run this script. It applies a Xform modifier to rotate the pivot before exporting.
1087 |
1088 | ```
1089 | fn RotateCreationPivot obj rot =
1090 | (
1091 | select obj
1092 | modPanel.addModToSelection (XForm ()) ui:on
1093 | obj.modifiers[#XForm].gizmo.rotation += rot as quat
1094 | rotate obj (inverse rot as quat)
1095 | )
1096 | RotateCreationPivot $ (eulerToQuat(eulerAngles 90 0 0))
1097 | ```
1098 |
1099 |
1100 | Script to rotate all objects in 3ds Max scene for export
1101 |
1102 | ```
1103 | (
1104 | mapped fn ProcessObjectsForUnity node =
1105 | (
1106 | resetxform node
1107 | tm = rotatexmatrix 90
1108 | tm.row4 = node.pos
1109 | node.transform = tm
1110 | node.objectoffsetrot = eulerangles -90 0 0
1111 | )
1112 |
1113 | ProcessObjectsForUnity geometry
1114 | )
1115 | ```
1116 |
1117 | * Batch Exporter for 3ds Max (http://www.strichnet.com/improving-the-fbx-workflow-between-3ds-max-and-unity3d/)
1118 |
1119 | ##### Exporting CAT Animation to FBX
1120 |
1121 | Bind normal bones to the CAT rig for use in skinning and exporting
1122 |
1123 | ###### Bind Pose
1124 |
1125 | Set Motion Panel/Layer Manager/"Setup/Animation Mode" Toggle to ```Red```
1126 | Select only the bones and the mesh you wish to export
1127 | Export naming: ModelName.FBX
1128 |
1129 | ###### Animation
1130 |
1131 | Set Motion Panel/Layer Manager/"Setup/Animation Mode" to ```Green```
1132 | Select ONLY the bones required in your hierarchy (These should match the exact same bones used for Bind Pose), don't include the mesh.
1133 | Export naming: ModelName@AnimationName.FBX
1134 | The @ symbol is a special Unity naming convention allowing the animation to be bound to the Human.fbx in the Unity editor
1135 |
1136 | #### Importing from 3ds Max into Unity
1137 |
1138 | If importing only animation or bones from a FBX:
1139 |
1140 | * Set ```Preserve Hierarchy Model``` import option to ```True```
1141 | * Set ```Rig > Avatar Definition``` to ```Copy From Other Avatar```
1142 |
1143 | MaxListener Window, set width and height of selected bones, maybe objects too?
1144 | $.width = 0.01
1145 | $.height = 0.01
1146 |
1147 | **[⬆ Back to Top](#table-of-contents)**
1148 |
1149 |
1150 | ### 5.3 Textures
1151 |
1152 | * Textures follow the [naming convention](#anc-textures) found above.
1153 | * They are a power of two (For example, 512 x 512 or 256 x 1024).
1154 | * Use Texture Atlases wherever possible.
1155 | * 3D software should point to the Unity project textures for consistency when you save or export.
1156 | * It is better to resize the texture in Photoshop then to use Unity’s compression options when the in game texture resolution is already known. This reduces the file size and import time of the texture into Unity.
1157 | * When working with a high-resolution source PSD outside your Unity project use the same name for both the high-resolution and the imported Unity file. This allows quick iteration when swapping between the 2 textures.
1158 |
1159 | More information for importing textures can be found here: [https://docs.unity3d.com/Manual/ImportingTextures.html](https://docs.unity3d.com/Manual/ImportingTextures.html)
1160 |
1161 | Textures requiring the use of a Alpha channel should follow this guide: [https://docs.unity3d.com/Manual/HOWTO-alphamaps.html](https://docs.unity3d.com/Manual/HOWTO-alphamaps.html)
1162 |
1163 | ##### Texture File Format
1164 |
1165 | All textures should be of the .PSD format. No layers should be included and only one Alpha channel in the imported file.
1166 |
1167 | **[⬆ Back to Top](#table-of-contents)**
1168 |
1169 |
1170 | ### 5.4 Audio
1171 |
1172 | Only import uncompressed audio files in to Unity using WAV or AIFF formats.
1173 |
1174 | Great guide on [Unity Audio Import Optimization](https://www.gamedeveloper.com/audio/unity-audio-import-optimisation---getting-more-bam-for-your-ram)
1175 |
1176 | **[⬆ Back to Top](#table-of-contents)**
1177 |
1178 |
1179 |
1180 | #### Article References:
1181 | https://unity3d.com/learn/tutorials/topics/tips/large-project-organisation
1182 | https://github.com/Allar/ue4-style-guide
1183 | http://www.arreverie.com/blogs/unity3d-best-practices-folder-structure-source-control/
1184 |
--------------------------------------------------------------------------------