[music playing]
[Thomas Krogh-Jacobsen]: Vision control can be a daunting topic,
particularly if you're an artist coming from a non-technical background.
But it doesn't need to be that way.
Agreeing on how to organize your project assets
and manage your code across a team can help it get off to a great start.
My name is Thomas Jacobsen.
And in this video, we'll share some tips on unity project organization.
We'll show you how you can define certain standards that makes it easier
to work the version control.
These tips all apply regardless of what system you prefer using.
We've recently also created a best practices book on version control.
You can find more details in the book, if you'd like to learn more.
You can find a link in the description below.
Let's start with project structure.
You want to make sure to plan a good folder structure carefully
from the beginning.
Define a taxonomy which works well here now.
But also one which scales well as your project grows in the years to come.
Not only is a folder structure an internal agreement
on how you organize your project files.
It also helps you avoid version control issues later on.
Don't create additional folders at the project's root level
unless it's absolutely necessary.
In general, you want to store all your content files within the asset folders
whenever it's possible.
You also want to avoid spaces in the file folder name.
Instead, consider using camel case notation as an alternative for spaces.
And finally, you want to avoid creating empty folders
so you can create issues in some version control systems.
If you need them, do remember to use a .keep file inside that empty folder.
While there is no right way of organizing your folder structure,
a common approach is organizing project folders by asset type.
Here are two examples of what that could look like.
You are not limited to this approach.
But it's a great starting point, and there's
a reason why it's a popular practice for many Unity games.
If you're looking for more inspiration, check out the Unity templates
under projects for examples on how to organize a folder structure.
What works best, of course, always depends on your specific project needs.
The most important thing is just that you
take the time to analyze your current needs,
as well as those needs you'll have in the future.
The idea is to have a plan for your project organization.
It shouldn't be something which is just happening organically and randomly.
You also want to consider creating a separate folder
for non-production scenes and testing.
That way you can easily differentiate between what
was created for testing purposes and what
will make it into the final production.
You can provide even more clarity by simply adding some soft folders
with usernames or certain areas too.
And you can also consider using namespaces
to avoid conflicts between class names declared
in the production versus system namespaces.
Naming things is really hard, but it's even harder if you as a team
haven't agreed on a standard on how to do it.
How you name your game assets is probably
one of the most important aspects to keeping
your project elegant and efficient as it grows over time.
Agreeing on standards across team doesn't
stop at the project folder structure.
You want it to find a naming standard for all the assets across the team
to make things easier because sooner or later,
we all end up working in in each others files.
As an example, it's tempting to use short names
to save a few seconds here and there.
But what might be logical to you today may not be logical a year from now.
It also might not make sense for another person on the team.
Think of a good name as one which everyone intuitively understand
and where you don't need to rename it later on in the process.
Taking too many shortcuts in naming can be a really bad long-term investment.
Do use descriptive names whenever you can.
What's a description name then?
Well, a simple trick is just to follow the design document
and be really specific.
That way everyone will know what you're talking about.
As an example, rather than saying, "dragon location,"
you might want to say, "the red dragon lair."
According to studies, using Camel case and Pascal case improves readability.
It also addresses a problem by having spaces
in your object names, which can cause conflicts.
Consider picking one of the two.
In general, Pascal case is the most widely used standard
for naming folders and objects, but feel free
to pick whatever aligns best with your code style standards.
Just ensure that you and everyone else sticks to it
so you're always consistent.
Underscores and hyphens can be useful, but the general advice
is to try to avoid using them.
One of the useful and recommended ways is
to use them to denote variants of a specific objects such as dates,
texture maps, or entities.
As a general rule of thumb, you also want
to split up your large and complex assets into smaller bits.
Same thing goes for complex prefabs where you can also
leverage nested prefabs as one of the power tools available for
creating modularity.
This way artists and designers can better
collaborate while minimizing the risk of conflict.
You can then use the scene manager to load
multiple scenes using the load scene parameter as you need them
during runtime.
Also make sure to use the power ScriptableObjects
for storing data whenever possible.
Finally, while a lot of these tips is all about
avoiding merge conflicts in the first place, if you do end up with conflict,
use the smart merge tools.
You can find more information about that in the documentation.
You can also make user presets to enforce consistent standards
or to apply reasonable defaults to new assets.
If you're not familiar with presets, they essentially
allow you to customize the default state of anything in the specter.
Obviously, we all want to write code in a way
so everyone can see that we care about our work similar to how
naming standards for your project assets can help make your projects easier
to navigate in, the same thing applies to a code.
Creating a code style guide is often a great investment
for maintaining a clean code base as a project grows.
With more consistent code standards, you won't need to do as much refactoring.
It's going to improve the readability, and it's
going to make it easier for everyone to swap
between the different areas of your project or even involve new teammates.
Consider creating a code style guide that removes the guesswork out
of most of the coding conventions and formatting.
Then they'll set in stone rules for what a code style guide should cover.
But in general, we want to make sure that most decisions have already
been made upfront.
The key is to make decision on whatever works best for your team.
And then once you decided, that everyone sticks with.
A classic example of formatting where there
may be different opinions in the team is presentation style.
There's the element style where you place
an opening curly brace on a new line.
And then there's a K&R style which keeps an opening brace
on the same line as the previous item.
It's up to you whatever you want to do for your team.
But that's an example of something which you may want to include in your guide.
You may also want to consider things such as,
does your team use PascalCase for enums, or is everything in capitals?
Do you want to have a rule about using regions standards in all scripts?
Do you have a policy for using tooltips to replace comments,
for inspector properties, and so on.
Again, think of the code style guide as an agreement
on what your team should be doing.
A great guide makes a project feel like the work of a single author,
regardless of how many people actually worked on it.
Microsoft and Google both offer fairly comprehensive code style guides for C#.
Both are excellent starting points if you want to create your own or just
as a source of inspiration.
Outside of the code style, you can also line up certain practices
such as design patterns and namespaces.
Namespaces, in general, is a great way to help organize your code better.
Namespaces is a great way to separate test content from production code.
But it can also help avoid conflicts with third-party assets
by class names may end up repeating.
You can also take advantage of namespaces
in your code to map back to the folder structure you
define for a bit organization as well.
Once you define the formatting, you can automate a lot
of the process of keeping track of it.
Most IDEs, including Visual Studio, offer
tooling to enforce formatting standards.
And even converting existing project files follow those guidelines.
Unity also employs a template script to read from whenever you
create a new one within the project.
You can modify these script templates to override the default values
and that way customize your scripts however you want to do it.
That wraps up the tips which we picked from the guide for this video.
Check out the e-book for many more tips.
If you're interested in more tips and tricks,
check out some of the other e-books which we made available as well.
[music playing]