Hey, everyone.
My name is Thomas Krogh-Jacobsen.
I am the lead for our Technical Content Marketing team.
And I'm based out of the Unity Copenhagen office.
In my team, focus on creating technical educational content
which helps you build better games.
We do that across many different formats,
from blog posts to video tutorials, ebooks,
and even demo projects.
Our primary focus is best practices for professional game
developers.
And so one of the cool things about working with that topic
is that I get to work with both internal and external Unity
experts.
Many of the tips I'll be sharing today
does come from one of these teammates.
For this presentation, I picked 20 actionable tips which I hope
can help you and your team be more productive.
I picked five tips from each of these four new ebooks which
we recently created in my team.
Some of the tips will focus on day-to-day workflows
and be very feature-specific.
Others will focus a little bit more on general best practices
and thus be more about long-term productivity games.
All right, so here's a full list of all the tips
I'll be covering.
Let's dig in.
First and foremost, keeping track
of all the new features in Unity can be a little overwhelming.
So let's get started by simply highlighting five features even
the experts might have missed, features
which I would recommend making part
of your day-to-day workflows if you haven't done already.
The Device Simulator makes it easy to simulate
how your game will appear and behave
on different mobile devices.
It's easy to test rotation, and it's
easy to simulate safe areas.
You can also test code that responds
to device-specific behaviors.
If you're working with mobile game development,
this is really a time-saver.
In the latest LTS versions of Unity,
you can also open as many focused inspector windows
as you like.
This makes it so much easier to compare values or make edits
to more than one game object at the same time.
Simply right-click object and select Properties,
to open a new inspector window.
You can then reposition and resize
the focused inspector in the same way as other windows.
If you're like me and like to use a lot of hotkeys
to speed up your workflows, you should also check out
the Shortcuts Manager.
It provides a nice visual overview
of your current key bindings.
That way, it's now much easier to assign new hotkeys
while avoiding conflicts with the existing.
As your scenes grow larger, it's easier for things
to get in the way of what you're working on right now.
And how to solve this was to simply deactivate game optics.
But the problem is, that can lead to unintended behavior
at runtime.
Instead of this old hack, try out
the new scene-visibility toggle.
That is the eye icon you see on the right in the animation.
By toggling this mode, you can hide
or you can show objects in the scene view
but without affecting visibility in the game mode.
You can also make game objects not selectable
in the scene view, using what we call "scene picking."
That's a hand icon you see in the scene hierarchy.
That way, you can avoid accidentally selecting
a certain object while working in the scene,
while still ensuring that everything works just
like normal when you go into game mode.
Unity presets allows you to save multiple changes
as preset template.
That makes it easy to apply the same settings
to many other assets in just a few clicks.
This can be particularly efficient
for configuration of import settings.
Not only is it a great way to speed up your workflows,
but it also helps consistent standards and format
constraints for your imported assets.
We recently released an ebook with more than 70 productivity
tips, including the ones I just mentioned here.
The tips are also available as a three-part blog post series
if you prefer that format.
We'll post links to both of those resources in the chat.
All right.
So, switching gears a little, also wanted
to talk to you about methodology and not just about features..
And while profiling will not speed up
your day-to-day workflows, short-term,
the long-term benefits of looking
to perform this optimization can really
be massive, particularly for really large Unity projects.
The best gains from profiling requires you to start early on.
You don't want to start the process just before you're
about to ship your game.
However, you also need to make sure
it's part of an ongoing process through the entire development
cycle.
One of the key benefits of starting profiling early
and doing it often is that you can establish a performance
signature for your project.
That way, it's also much easier to benchmark performance
as your product grows and identify when things go wrong.
Our second general tip for profiling
is the exercise of budgeting.
You want to start by defining your target-device hardware
tiers, both those which are high-end and low-end devices.
Based on that, you can then create a memory budget
so you know how much you can spend when
designing scenes and levels.
It can also be useful to go further and set content budgets
around mesh and shader complexity
as well as texture compression.
By agreeing on performance constraints
as a team early in the process, it's
much easier to control the development as a team.
It's also a great way to avoid potential conflicts
between program and artists.
Another good rule of thumb is to have a significant buffer
for frame idle time.
That way, you've got a little bit
of breathing room to account for real-world temperature
fluctuations.
On mobile, we often see that it's
recommended to have up to 35% of the buffer time.
That may sound like a lot, but that way, you
can assure you are avoiding thermal and battery
issues by giving the mobile chips adequate time
to cool down.
Profiling results are always most accurate
when you're profiling builds
on your actual target device.
I know it's easier just to profile in the editor
or use your own smartphone as a testing device,
but that simply won't be representative of how users
will experience your game.
You want to make sure you're profiling the actual target
device and mainly on the low-end hardware tiers.
Once you establish your hardware tiers
and define a memory budget, it's time
to look into where all the bottlenecks are.
There are many ways to approach profiling,
but consistency is really the key to get the best results.
So define a process for the profiling from the beginning,
and stick to it as a team.
A good general rule is that you want to start
with a top-to-bottom approach.
That means that you start with the deep profiling disabled,
and it means you want to focus on identifying the biggest
problems first so you focus on where there is the highest
impact.
From there, you can work your way into the specifics.
This flowchart you're seeing on the right side
is an example of a recommended profiling process.
It was actually created by one of our teammates, Steve
McGreil, who have profiled more
than 100 different projects.
And we'll post a link in the chat,
if you want to check out how Steve's
recommendation to a simple profiling process looks like.
All right.
So, profiling can feel a lot like detective work.
You need to have a consistent process,
and you need to have a methodology in place
for it to work.
But you also need to know all the tools
you have at your disposal to get the best results.
Unity offers a whole range of tools,
including the Memory Profiler, the Profile Analyzer,
Frame Debugger, and much more.
But they also have a wide range of free tools
available from partners such as Microsoft, Arm, Sony,
and Apple, to mention a few examples.
To get the best results, you want
to use a combination of both Unity
and platform-specific profiling tools.
We often hear from our customers
that profiling and performance optimization can
be a little bit of a daunting topic,
but it doesn't have to be that way.
We recently launched more than three ebooks
with more than 200 pages of optimization tips and best
practices.
A lot of those tips come from Steve and his team
and are very actionable in terms of doing performance
optimization on your own project.
They're also all free, and we'll post a link in the chat
to where you can download all of them.
The next five tips are about project organization.
And it's also about how to get set up
for success in the long run.
The tips are somewhat also related
to how you establish an efficient version-control
process by getting organized and staying organized.
Let's start with project structure.
You want to plan the folder structure carefully
from the beginning.
Define a taxonomy which works well here and now
but also one which scales well as your project
grows in the years to come.
Think of it as sort of like an internal agreement
that everyone in the team should organize their files by.
You also want to avoid creating folders you're not sure
if you will need for later or which you're likely to change.
The whole goal is to avoid too much refactoring.
In general, you also want to store your content files
within the Assets folder, whenever that's possible.
And finally, try to stay away from spaces in file and folder
names.
You can simply use CamelCase as an alternative for spaces instead.
There is no right way to organize your folder structure,
but a common approach which we often recommend
is organizing product folders by asset type.
Here are two examples of what that could look like.
There are many reasons for why this is a popular practice
for Unity games.
The main reason is simply that it scales well
as a project grows.
Another tip to consider is creating
a separate folder for nonproduction scenes
and testing.
That way, it's much easier to differentiate
between what is created for testing purposes
and what will make it into the final production.
You can then always add more subfolders
with usernames in certain areas, to ensure
you have a clean separation of the files you need
across different test areas.
Another thing to consider is using NameSpaces
to avoid conflicts between class names
you have declared in the production versus testing folders..
In general, a very general rule of thumb
is that you want to split up your larger complex schemes
and assets into smaller bits.
It's often better to assemble smaller scenes
than having one bigger scene.
The same thing goes for complex prefabs,
where you can leverage nested prefabs to create more modularity.
This way, artists and designs can better
collaborative in parallel while minimizing
the risk of merge conflicts.
It also makes tracking level design changes
much easier in version control.
And you can simply use the SceneManager
to load multiple scenes as you need them during runtime.
And similarly, you can also make use of ScriptableObjects
for storing data whenever possible.
That way, you can also separate logic and data
in a more clean and scalable way.
So this is probably the easiest tip I'll present today
but perhaps also the one which we all tend to forget,
and that is, you want to commit little
but you want to commit often.
Just like a task need to be broken down
into smaller chunks, commits should be exactly the same.
So that does mean committing little but doing it
for every single task you need to fix.
In general, we say that you want to make
a commit for each feature of each task
so it's easier to track your changes in your version
control--
not just here and now, but also further down the line.
You also want to make sure that your commit messages are
as meaningful as possible.
It should be easy for your teammates
to guess what the commit is all about.
And it should also be easy for you
to remember a year from now.
Using key words or perhaps even thinking
about how you might search for the commit later on
can be a really useful trick for creating good descriptions.
If you're using a system like JIRA,
you can also include the ticketing number
or even agree on a standard that works
for the team-- like in the example in the slide.
It's a good idea to agree on standards
that go beyond just the project folder and structure though.
You might want to agree on name standards for your game
objects, scenes, prefabs, et cetera, as well.
Just like with the commits, it's best to use descriptive names
and it's better to be specific than leave out
too many details.
Let me show you an example.
So in this example, it's tempting to use short names
to save a few seconds here and there.
But what might be logical for you today
may not be so straightforward a year from now--
or, more importantly, to another person in the team.
A good name is generally one which
everyone intuitively understands and which won't need renaming later on.
A good rule of thumb to achieve that is simply to choose a name
which you can pronounce.
Taking too many shortcuts and saving a few seconds
here and there on naming can be a really, really bad
long-term investment.
We've recently created a best-practice guide
on version control and product optimization.
So if you're looking for more tips,
check out the ebook if you want to learn more.
We also created several blog posts on the topic.
And we'll post links to both of them in the chat.
All right.
So you can also go one step further,
in terms of standardizing terms and terminology
across the team.
And you can do that by creating a code style for everyone.
A code style guide is essentially
about taking the guesswork out of the code
formatting and the code conventions for everyone
in your team.
It's about avoiding too many inconsistencies
and too much refactoring.
There are no set-in-stone rules, but the key
is that you need to decide what's best for your team
and then, once you decide it, have everyone stick with it.
A general advice when creating a style guide
is to not overcomplicate, though.
You need to balance simplicity with having
just enough details for everyone to understand the basic rules.
But there's no need to account for every possible edge case.
Again, I think the key objective is more
to make the code feel like it was written by one person
rather than having 20 different styles.
In terms of what it should cover,
most guides generally include something
like general naming conventions, guidelines
for using NameSpaces--
you may also want to have some rules on naming and indentation
styles, on how to do commenting, and, of course,
code casing rules for the team.
Microsoft and Google both offer very comprehensive C# code
style guides.
They're both excellent starting points
for creating your own guide, as well.
You don't have to use the whole thing, though.
You can simply cherry-pick the things which
makes sense to you or use it
as a source of inspiration.
With the help of a couple of Unity developers,
we actually also created our own Unity C# code style guide
specifically for Unity game projects.
It's available on our Unity GitHub.
And we'll add a link to that in the chat, as well.
Script templates allow you to customize what a new C# script
looks like.
Maybe you want to remove the start and update calls,
and maybe you want to add your product NameSpaces to it.
But once you establish formatting rules for your style
guide, you can also configure the script templates
to help you enforce some of those standards.
So, every time someone creates a new C# script file new project,
it will generate the placeholder code which your team defined.
Maintaining a clean code base and sticking
to the formatting rules you agreed on
can result in a lot of manual work.
But you can also automate a lot of the process directly
in your IDE.
Most IDEs, such as Visual Studio,
offer you tooling to enforce formatting rules.
And some tools can even help you convert existing project files
and reformat the code for you in just a few clicks.
If you'd like to learn more about code style guides
and how to create them, check out our new ebook.
I also recently published a blog post with a few expert tips,
if you prefer a more quick-read format.
We'll post links to that in the chat here as well.
That concludes the tips from today.
I know that was a lot in a short amount of time.
But if you're interested in more best-practice content,
check out some of our other ebooks.
Use the URL in the bottom of the slides to find
all of them.
We'll also post a link in the chat to it, as well.
With that, thanks so much for tuning in.
I hope some of these tips will be useful
and you can make use of them in your own project.
Feel free to connect with me on social media, if you like.
I hope you all have a great Unite.
And with that, I'd like to thank you for joining, once again.