Book Image

Unity Game Optimization - Third Edition

By : Dr. Davide Aversa, Chris Dickinson
Book Image

Unity Game Optimization - Third Edition

By: Dr. Davide Aversa, Chris Dickinson

Overview of this book

Unity engine comes with a great set of features to help you build high-performance games. This Unity book is your guide to optimizing various aspects of your game development, from game characters and scripts, right through to animations. You’ll explore techniques for writing better game scripts and learn how to optimize a game using Unity technologies such as ECS and the Burst compiler. The book will also help you manage third-party tooling used with the Unity ecosystem. You’ll also focus on the problems in the performance of large games and virtual reality (VR) projects in Unity, gaining insights into detecting performance issues and performing root cause analysis. As you progress, you’ll discover best practices for your Unity C# script code and get to grips with usage patterns. Later, you’ll be able to optimize audio resources and texture files, along with effectively storing and using resource files. You’ll then delve into the Rendering Pipeline and learn how to identify performance problems in the pipeline. In addition to this, you’ll learn how to optimize the memory and processing unit of Unity. Finally, you’ll cover tips and tricks used by Unity professionals to improve the project workflow. By the end of this book, you’ll have developed the skills you need to build interactive games using Unity and its components.
Table of Contents (15 chapters)
Free Chapter
Section 1: Base Scripting Optimization
Section 2: Graphical Optimizations
Section 3: Advance Optimizations

Faster GameObject null reference checks

It turns out that performing a null reference check against a GameObject will result in some unnecessary performance overhead. GameObjects and MonoBehaviours are special objects compared to a typical C# object, in that they have two representations in memory: one exists within the memory managed by the same system managing the C# code we write (managed code), whereas the other exists in a different memory space, which is handled separately (native code). Data can move between these two memory spaces, but each time this happens will result in some additional CPU overhead and possibly an extra memory allocation.

This effect is commonly referred to as crossing the Native-Managed Bridge. If this happens, it is likely to generate an additional memory allocation for an object's data to get copied across the bridge, which will require the...