From Prototype to Executable: Generating and Debugging Your Game

So, we have reached a point where the game is in good enough shape to test it with real people, a point where theoretical design meets practical application. The problem is that we can’t pretend people will install Unity, open a project, and hit Play. They want to receive a nice executable file to double-click and play right away. In this chapter, in the first section, we are going to discuss how we can convert our project into an easy-to-share executable format, and then in the second section, we will see how to apply the profiling and debugging techniques learned in the previous chapter, but this time, on the build. After reading this chapter, you will be able to detect potential performance bottlenecks and tackle the most common ones, leading to an increase in your game’s frame rate.

In this chapter, we will examine the following build concepts:

• Building a project
• Debugging the build...

Building a project

In software development (including video games), the process of taking the source files of our project and converting them into an executable format is called a build. The generated executable files are optimized to achieve the maximum performance possible given the configuration of the project. We can’t judge performance while editing the game due to the changing nature of a project. It would be time-consuming to prepare the assets in their final form while editing the game.

Also, the generated files are in a difficult-to-read format. They won’t have the textures, audio, and source code files just there for the user to look at. They will be formatted in custom file structures, so in a way, they’re protected from users stealing them.

Actually, there are several tools to extract source files from video games, especially from a widely used engine such as Unity. You can extract assets such as textures and 3D models, and there are even programs...

Debugging the build

In an ideal world, the Editor and the build would behave the same, but sadly, that isn’t true. The Editor is prepared to work in a fast-iteration mode. Code and assets have minimum processing prior to being used to make changes often and fast, so we can test our game easily. When the game is built, a series of optimizations and differences from the Editor project will be applied to ensure the best performance we can get, but those differences can cause certain parts of the game to behave differently, making the profiling data of the player differ from the Editor. That’s why we are going to explore how we can debug and profile the game we have built.

In this section, we will examine the following build debugging concepts:

• Debugging code
• Profiling performance

Let’s start by discussing how to debug the code of a build.

Debugging code

As player code is compiled differently, we can get errors in the build that...

Summary

In this chapter, we learned how to create an executable version of the game and properly configure it so we can share it with not only our friends but potentially the world! We also discussed how to profile our build; remember that doing that will give us more accurate data than profiling the editor, so we can better improve the performance of our game.

Now that we have finished our game, let’s get a glimpse of how your next project could easily be an augmented reality application in Unity by exploring the AR Foundation package in the next chapter.

Learn more on Discord

Read this book alongside other users, Unity game development experts, and the author himself. Ask questions, provide solutions to other readers, chat with the author via Ask Me Anything sessions, and much more. Scan the QR code or visit the link to join the community:

https://packt.link/unitydev