Shipping the Empty Box: Outline

by John "Seg" Seggerson

Context & Terminology

Every build process is different.

This lecture is about general philosophy of build engineering.

Specific Job Titles, even if the team is only of one.

Smaller teams can assume one person with more than one position.

Plan for the current and future platforms.

Assumes you will be rolling out the game on all currently planned and unplanned platforms.

• Start with one platform. Then rewind and reuse for other platforms.
• Making a strong build process will make cross-platform development easier!

Architecting a Build Process

The Goals of Build Engineering

• Create a deliverable game, repetitively.
• Able to re-create a delivered game build, repetitively.
• Create a “Clean Room” for the build process.

The Rules Of Build Engineering

ALWAYS act like you’re making the shipping build.

Make the empty box first! Sure the actual build may be broken, but don’t make the build process the reason for a broken build.

• Build failures caused by the build process itself begin a slippery slope.
  • No confidence in your build process leads to uncertainty. Uncertainty leads to fear. Fear leads to a Star Wars reference.
  • Trying the build again with no changes is making no changes and expecting different results.
• Build with all supporting assets.
  • Game icons, strings, meta data, and all other supporting assets.
  • Use the worst of art to start with. “Inspire” your artist to create good art.

EVERY machine is able to make the build.

The steps to prepare and run a build should be clearly documented and run with ease.

• "Hit by a truck" test. (Do not actually injure yourself!)
  Can the build be re-created if the author of the process was away?
  • Can the build re-created without the primary build engineer?
  • Can the build be modified without the primary build engineer?
• README to get the machine to build.
  • Steps to get a machine’s environment up to speed.
    Include links to obtain environment software.
  • Every step to run the build process.
• Make the script check the environment; Notifying problems with clear error messages.
  If you’re explaining “If this happens…” in your README, invest in checking and adjusting for these conditions in your scripts.
  • Are all supporting executables, libraries, etc found? If not, what’s missing?
  • All all source and build target file spaces defined and present?
• Make “Doctor” scripts to check up on build environment.
  • A pre-flight check with more information on what’s wrong and how to fix it.

NEVER make shipping builds on a developer’s environment.

The developer created a tool to fit their needs. A dedicated build machine creates a “clean room” to standardize the environment and analyze problems.

• Note: VMs are OK.
• Developer environments may have custom modifications which result in “Works for me” or “build is different” issues.
• Programmers: Tell your build engineer if you’ve done any work which alters building!
  If a library isn’t included into the build and/or environment settings are needed, tell your build engineer ASAP.

Identifying Build Phases

Inventory the steps needed to go get your game to release.

Build Environment

• What are the software requirements to make a build?
  • Package Management: Bower, NPM, CocoaPods, etc.
    • Prefer non-global when possible.
    • DON’T COMMIT IN THE SUPPORT PACKAGES! Commit only the configuration files.
  • Global support software
    • Make the script check for existence of specifically needed support tools.
    • Show error message of missing elements clearly, stopping the build from proceeding.
  • One script to handle all platforms.
    • How do these differ for different platform targets?
    • Grunt, Gulp are good cross-platform task runners / build systems.

Source Control Management (SCM)

• Planning your version tagging process.
  • Local vs. Public Versioning
    • Consoles have strict version requirements at conflict with production needs.
    • Find your process to correlate SCM tags with public versions.
  • Semantic Versioning
• One code base. Period.
  • Do not commit your core codebase more than once. Do not use more than one repo.
    If needed, copy files per build task.
  • Tags/branches should contain all the scripts in the repo.
    Rollbacks will include the proper scripts to re-create the build.
• What Not to Commit to SCM.
  • NEVER commit your final output builds.
    • Use cold file storage for final builds.
      Use folder and file names to identify build with SCM tag.
  • Ignore package support files.
  • Ignore individual user’s build preferences.
  • See GitHub’s GitIgnore repository.
• Build script works with SCM on build machine.
  • Make the script automatically pull, tag, and push tags to your source control.
  • … but make sure development teams aren’t tagging for their development building.

Asset Preparation

• Start with the highest quality possible.
  Always request and save the highest quality asset possible. Much easier to process to shipping quality than get stuck with attempting to “enhance.”
• Re-compile in each build process.
  While you may *save* time with caching images, you’ll miss changes in code or art and get backed into a wall.

Platform Preparation

“All the things outside of the game.”

• The Game Icon Every. Platform. Uses. One.
  • Request the highest quality possible.
  • Re-design for sizes less than 64px, as needed.
  • Lowest is 16px square.
• Strings & Metadata
  • Titles & Descriptions
    • Common elements between platforms, but some with different requirements.
    • A ‘wort’ about localization. (That’s German for ‘word’.)
  • Achievements, Trophies, and related
• Ultra Platform Specific
  • Note and do analysis on each platform’s specific needs.

The Building of the Builds

• Try to build all platform targets in one build process… but that won’t happen.
• Use the same build script code base for building per platform.

Platform Finishing

“How do I make this build easy to install and uninstall on the target platforms?”

• General Platform Notes
  • Pre-Flight Checks
    • Enforce known compatibility requirements.
      If the game will not run on Windows 95, make sure the installer won’t install the game on Windows 95.
    • Bundle and execute required supporting runtimes.
      “The Problem with DirectX”
  • Uninstalling
    • Make the uninstaller!!!
      Don’t be a jerk. Make the uninstaller.
    • Allow for clean installs on top of existing installs.
      Invoke the uninstaller to remove the game, then install.
  • Code Signing
    While incurs a financial cost on some platforms, it may be effectively required on certain platforms.
    • Sign both executable & installers.
      • Remember to timestamp!
  • Mac:
    • Developer certificate ($99/year), includes Mac App Store
  • Other
    • Mobile platforms usually provided with the program.
    • Consoles platforms incorporated as apart of platform. Usually.
• Desktop: Always create the installer or proper bundling procedure.
  • Windows: NSIS or Inno Setup
  • Mac: DMG or PKG
  • Steam: SteamPipe See Valve documentation.
• Mobile: Create the final bundle. Look into local distribution systems.
  • Android
    • Include all forms of the executable: Debug, release, and signed/unsigned.
  • iOS
    • Keep tabs on devices on the team’s whitelist, or use third-party distribution system like TestFlight.
• Console: Disc
  • Create an ISO ready for QA or others to burn.
  • If different, create ‘store on hard drive’ files.
  • If you have the hardware, automate burning to discs.
• Console: Downloadable
  • Create automated scripts for developers and QA to use once a bundle is given to them.

Discipline in Managing a Build Process

The Build didn’t break because the Build Engineer touched the build last.

Possible problems can include:

• Toolchain differences between platforms (MSVC vs. GCC).
• Asset requirement differences.
• Debug build relaxes requirements that fail on release build.

Know how long it takes to make a build.

Schedule the build time into your production timeline.

Canceling builds makes build systems less effective.

Many steps, especially 3rd party and console tools, can’t stop in the middle of a build. Even a system with stop points built in may take longer to cancel.

Dust off your previously released title and build it.

Already shipped the product a few months ago? Got a few moment to spare? Fire up a build!

• Checks to make sure you can go in an make fixes or ramp up a new platform with ease.
• Lessons can be learned when you take a look back at your pervious work.

A note about Continuous Integration

CI answers the question: “Does the codebase work, right now?”

Focus on speed of build, rather than rigor.

Builds answers the question: “Can the codebase ship, right now?”

Focus on the shippable state of the game, rather than speed of the build process.