JOHN O'NEILL: Hello, and welcome to beginning your Android
development journey in Unity.
I'm John O'Neill, a senior software engineer
and part of the Accelerate Solutions team at Unity.
This presentation is going to consider Android development
in the following areas, best practices
with regards to Unity development
at various stages of your game, optimizations and areas
to focus on, and where to look for answers when you have
questions or need examples and help guiding you
through the process of implementing
your game in Unity.
When we talk about best practices,
these really come from a wide range of experiences
that I've had in developing multiple games
and distributing on the Android platform.
And these really start in planning your development,
not just when you're finished with a game,
but really as early as the initial concept and design.
And so we'll look at various stages and some of the things
you need to think about when you're preparing,
your developing, and then deploying your product.
We'll also look at a number of tools and resources
that helps make your life as a developer a little bit easier
as you're getting your game ready;
talk about some optimizations and when to do optimizations
and how to compare that information;
and then finally, a brief introduction
on performance and understanding what
it is that we're looking at, evaluating performance
and especially considering the mobile performance
items that you really need to keep in mind.
A little bit of planning at the beginning of your development
will make your life so much easier when
you're trying to deploy to an audience,
potentially around the world.
As fun as it is to jump right in and start implementing
our code, you might find that you set up a lot of bad habits
if you don't think about the implications of how you're
designing, implementing, and deploying
various aspects, from asset allocation
to sound compression, texture resolution.
All of these things will grow and escalate
if you don't have a plan in place at the design stage
so that you can set your structure up properly.
Unity does a fantastic job of giving you access
to the project hierarchy.
And if you organize your assets correctly at the design stage,
your entire team will find it much easier
when you're at the point of packaging,
deploying, and launching your game.
One example of a development timeline that you may
experience-- and this by no means is every case of game
development--
but one of the examples that we can talk about
is four stages of development that you'll
go through, starting with preproduction and planning.
This is really at the beginning when
you have the initial concept.
Team is coming together.
You have an idea.
You might start organizing from a design standpoint and even
technical prototype standpoint your game, your assets,
your folder layout, your structure, how you're
going to deploy, what types of issues that you might run
into as you're going through and thinking about
where is your target launch?
What is your audience?
When are you going to finish it?
Is there a good time to launch to the market
that you're targeting?
Getting into full-scale production and development,
this is the guts of building your game.
This is you're implementing your product.
You're going through and creating the art
assets, the code, the resources associated with what
makes the game your game.
As you get close to preparing to finalize and deploy,
this is typically where you're doing
more internal and external focus testing.
You'll take advantage of things on the Google Play Console
where you're able to distribute limited private or public
betas.
And then never forget that, once a game is launched,
the support and maintenance stage really
can be a very long-tail engagement, especially
now when it's no longer a fire-and-forget.
Launching a product, maintaining it, getting user feedback,
seeing how it's performing, reading results
from Android Vitals, understanding
what your users are having fun with through analytics
or having problems with through crash reports.
The faster that you're able to respond, patch, update,
and maintain, the bigger the engagement with your customers
you'll have.
So these are the four large areas
that have different thoughts and different implementation
methodologies when you're in them.
But collectively, you're building a game.
And ultimately, what you go through
may flow between these cycles.
Let's talk about a couple of the best practices when
it comes to mobile platforms.
Your screen size and orientation is immediately
something you're going to have to deal with when it comes to,
not only your user interface layout, but also the 3D
assets that potentially are going to be displayed.
The size of the screen doesn't necessarily
mean the resolution is going to be small.
And so while you may have the pixel density on a screen,
the size may dictate that you don't need as large a 3D
asset as what you would potentially
on a much larger monitor.
The orientation change that occurs,
you may be interested in supporting if a user changes
from landscape to portrait.
And these are things that you can respond
to in events in the Unity system when your user interface
canvas has to either reorient, take advantage of the anchoring
positions, or potentially change the active canvas so that you
use a portrait layout as opposed to a landscape layout.
Now, these are things that you should
think about when your team is designing
the interface initially as to whether or not
it's going to be flexible and dynamic enough,
or if you truly need to know which screen orientation is
going to be present and create your assets appropriately.
Performance requirements really come into play
when you have to consider the battery and thermal elements
of a mobile device.
So normally running something at a full 30 frames a second
or 60 frames a second would be fine
when it comes to a PC platform, for example.
But if you're running constantly at this high level
on a mobile device, you're potentially
going to drain the battery faster and create
a negative user experience.
So keep in mind that your target performance may actually
be lower, and it should be roughly 60% to 65%
of maximum throughput.
Asset organization, texture formats, and packaging,
another area that will affect you
all throughout the development life cycle.
If you, again, talk about and think about asset organization
when you start designing your game,
you will save yourself a lot of hassle
when you're having to reorganize assets right before launch.
And this comes down to the way that you potentially
are packaging textures, if it's something
that has to be immediately available when
the game launches, or if it's something that potentially
could be packaged separately and downloaded through Google Play
asset delivery.
Your texture format and compression
will vary based on the need of your assets.
But in general, it's a good idea to take
advantage of the hardware acceleration
through formats such as ETC2.
One of the biggest things in Unity
is the number of draw calls that occur.
And draw calls are basically a request to the graphics system
to draw something.
So minimizing and organizing draw calls
is one of the biggest savings that you'll
get when it comes to lowering that performance hit
and increasing the potential frames per second.
Now, I've talked about frames per second,
but many times the frame rate is not
as important as the frame time.
Frame rate is just a rough indication
of how fast the graphics system is presenting to the screen.
But the frame time is actually the amount of time
that the CPU and GPU are actively
working on preparing the next scene
to be displayed to the card.
So you need to look at, through the Unity
Profiler, how much time you're actually spending processing,
and look at the frame times in millisecond
of the various aspects of your game code and your draw calls
and how you can optimize that through proper planning.
There's some excellent tools that help you
in your development efforts.
Directly from the Unity Editor, there
are a number of embedded tools from the profiler, the frame
debugger, and the memory profiler
that allow you to get a good snapshot
of the actual performance without guessing
where your bottlenecks occur.
There's also a tool called the Unity Device Simulator, which
allows you to run in Editor, in place
of play mode, various device orientations and configurations
to allow you to get a better sense of how
your layout from a UI and camera perspective
will appear before you actually build and deploy it to a target
device.
In Android Studio, there's wonderful profilers
that allow you to view CPU activity
and traces with the CPU profiler,
Java Heap and memory allocations with the memory profiler,
network traffic with the network profiler,
and energy usage with the energy profiler,
keeping in mind that the thermal performance is extremely
critical to keep an eye on.
Touching in again on the concept of profiling
using tools such as the Unity Profiler,
the Unity Profile Analyzer, which
allows you to compare snapshots that you've
taken at various stages of development,
and the Android GPU Inspector, one of the biggest things
that can help you is to remember profiling
is not something you do just at the end of your development.
Profile early, profile often, and then compare your results.
This will give you an idea of recent changes
you may have introduced and allow you to identify
more effectively where you're having the performance
problems as opposed to guessing where you have performance
problems.
Don't wait until just before you're
trying to ship your game to go in and analyze
where issues may occur.
The more often you do this and take advantage
of the tools between what's available in Unity
and in Android Studio, the easier
it will be for you to hone your experience
to be very fluid and effective for your users.
Items you need to remember with regards to optimizations
in Unity when you're targeting Android,
keep your frame times in check.
Remember to optimize for about 60% to 65% of your budget time.
And this will allow you to keep those thermal throttling
and warnings at bay.
Watch for frequent string usage allocations.
These can crop up and ultimately cause problems with regards
to garbage collection.
Watch your serialization and data management,
especially if you're working with JSON and XML, text based.
Know when you're going to be doing this, when
you need to read information.
And consider going to alternative formats
as opposed to very text-heavy processing.
Your memory allocations and garbage collection
can have an enormous impact on the performance and stuttering
that may occur at random times.
Consider things like pooling your game objects.
Instead of instantiation on need,
pool and instantiate on startup.
And then reuse as opposed to doing the create destroy
loop that occurs.
Also, take a deeper view into any third-party plugins
that you may have downloaded and used from the Unity Asset
Store or other sites.
These need to be carefully examined
for any issues with performance, optimizations,
and needs specific to your target platforms.
There's nothing more incredible that when
you see your game being played everywhere around the world.
In order to do that, you really need
to think about your target audience, your demographics,
your genre, and the languages that you're ideally
going to be supporting when you are initially
designing your game.
You need to think about localization and options that
are available to you in Unity and in Google Play that
help you to target and distribute assets that
are specific to the region and locale
that you're going to be distributing in.
You can view information about how your application is
performing in the Google Play Console
and also determine how to distribute
and when to distribute your target
application to various regions of the world.
Planning always makes an enormous difference,
so the sooner that you can determine what is your audience
and prepare your assets appropriately,
the easier it will be when you reach that point of deployment
and you distribute this game and, ideally,
hit a worldwide market.
During each stage of development,
you will probably be looking for information
in a variety of places.
A lot of these will cross over, but your needs
will be dependent upon the type of information
that you're looking for.
For example, during the design stage,
when you're planning for your development
and you don't have everything completely laid out,
you'll be reviewing best practices, eGuides,
learning materials, sessions such as this.
And these are really designed to help
you prepare for the challenges that you might face and some
of the design ideas around your larger systems in a game.
A quick example would be if you were targeting the Android
platform and you're going to have a very intensive user
interface, you're going to want to look
for best practices related to the optimization of draw calls
and organization of your hierarchies of information
for the UI, how you reference textures,
how you store assets, how you're going to be loading it
into your game.
And preparing that at the design stage
will allow you to better implement the solution
before you run down the road of going and doing something
that you're going to regret when you're close to actually
deploying your product.
Once you get to the full scale of development,
you might run into smaller questions about features
in the Unity Engine as it relates
to specific Android settings and deployment options.
This is where you would look for places such as on the Android
Developer Relations site, Unity forums, even Stack
Overflow, and sites such as answers.unity.com.
This is often, if you search and find,
so going back to your old friend, googling it,
will certainly get you in a better place with regards
to finding answers from other experts, other developers who
are running through the same things that you are right now.
When you prepare for deployment, keep in mind
that having a LiveOps view, understanding
the analytics of your game, reviewing the content
on the Google Play Console is going to be very important
and especially touching in on a fantastic feature with Android
Vitals and getting a live pulse of how your application is
performing with your users and responding to that.
The user engagement, as we talked about
with a worldwide audience, makes an enormous difference
when you're actually able to address issues
that your players are actually facing rather than simply
guessing what might be going on with users in the wild.
And finally, once your game is deployed,
you have a wealth of knowledge available that you
should share and become active in your game development
community.
Attend hackfests, do game review postmortems, go to conferences.
Find ways to network and share this information,
and you'll find you build a larger audience and a group
of people that you can depend upon when
it comes to upcoming games and new technology
and sharing that learning experience.
So you can pass on all the tips and tricks, kind of like this,
with others who are going through their first journeys.
Game development is such a fun, invigorating,
and frustrating process at times.
Hopefully the information presented to you
in this overview is giving you a little bit
of an idea of where to look for help and information
when it comes to your journey developing games on the Android
platform using the Unity game engine.