Appendix: Build Process Fundamentals
Verificado com a versão: 5
This section will provide you with a high level overview of a game build process. By the end of this lesson, you will understand what a build process is and its components.
What’s a Build?
A usable version of your game. Players care about the build that goes on their device; often referred to as the public, live, or production build. For any given production build, there were hundreds - if not thousands - of builds generated by the game developer. These were made to ensure that the game works. Every one of these builds takes time to configure, compile, validate, and distribute.
What’s a Build Process (or Build Pipeline)?
A set of tools and steps that game developers use to create a build. If you’re a solo developer, the process is simple. Your code, assets, revisions, and build environment and machine, are all on your local computer. But a team environment requires tools and processes to determine the “authoritative” version of the game the team should be improving.
What does a Build Process consist of?
The typical elements are:
- Repository (or “Repo”) where assets and code is stored. In professional environments, all files in a project are stored in a Source Control Management (“SCM”) system, so multiple team members can work with the same resources with minimal conflicts.
- Build Environment pulls code and assets from the repository and compiles them into a working version of your game.
- Distribution Service gets builds to users. For most of the game development life cycle, builds are distributed internally as it is validated.
- Automation Engine monitors portions of the build process and takes automatic action; compiling builds as well as reports, notification, and distribution. In absence of an automation engine, the process is executed manually by one or more people on the team.
Here’s what a typical Build Pipeline looks like.
What’s Source Control?
Source Control (also commonly referred to as Version Control) is a system that gives you a way to ‘undo’ changes across multiple files, and collaborate on software projects with a team of people. Using source control is generally regarded as a ‘best practice’ for game development, since it protects you from accidentally losing hours of work, and makes it easier to try out different things with your code but roll back to a more stable version of your project if you need to rethink your approach.
How does Source Control work?
Depends on the specific Source Control Management system. A workflow for using Git for software development generally works like this.
- You make a repo (hosted somewhere) and put a Unity project in it
- You select a Git client (piece of software) that provides an interface for watching and tracking your changes
- You tell Git to ignore certain files (like your Library folder)
- You make some changes to your Unity project and save them in Unity
- You switch over to your Git client and it should tell you which files just changed
- Select those files and ‘commit’ then - this is basically akin to marking this version of your project so you can refer to it later.
- After 1 (or more) commits you ‘push’ your commits to the Gitl host / server, so that they are now backed up, and also visible to anyone else who is also working on the project. The final ‘push’ stage is what Unity Cloud Build sees when it is watching your project. That tells it to automatically kick off a new build.
Which Source Control Systems are supported by Cloud Build?
Unity Cloud Build supports the following Source Control Management systems (“SCM”):
- Subversion (“SVN”)
For more information about specific systems, visit the following resources:
- GitHub Bootcamp
- BitBucket 101
- Beanstalk - Getting Started with Subversion
- Gamasutra Blogs - Git For Unity Developers
- Using Version Control with Unity3D (Mercurial)
Do solo developers need a build pipeline?
Yes, even developers working by themselves can benefit from source control and a build pipeline. Source control gives you a backup of your project that you can recover from if your hard drive dies, or if you accidentally delete or break your project. And a build pipeline like Unity Cloud Build can save you tons of time by making builds for multiple platforms at once.