Make a Build

Builds are configured and executed from Unity by one of the people working in Unity, and uploaded to
our internal launcher for the testers.

1. Start from main

Every build comes from main, which is always buildable. Art and content work happens directly on
main; code work merges into it after review.

→ Version Control > Branching

2. Check the version

[Game]_[Major].[Minor].[Patch]_[BuildNumber]
TorturedHome_0.4.2_318
  • The version lives in Unity's Player Settings and is bumped deliberately, not per build.
  • The build number increments on every build.

The build number is the thing a tester quotes in a bug report, so it has to be visible in-game.
A report against an invisible build number is a report against nothing.

3. Build it

  • All scenes in the build list
  • Development build with the profiler enabled, unless it is a release candidate
  • Windows x64 for internal testing

4. Upload to the launcher

Publishing is done using our own Bubbly Games Publisher. Janis will grant you access on request, which enables downloading through the Bubbly Games Launcher.
Inside, you can configure what to publish and where. Right now, it supports publishing to the launcher itself, and to steam.

5. The changelog writes itself

Generated from the commit messages since the last labelled build, grouped by
commit type:

  • feat and fix are shown to testers
  • chore, refactor, docs, style, test, build and ci are hidden

This is why the commit format matters. Nothing else has to be written for a changelog to exist.
The data is already in the history, in the right shape. The cost is that a commit with no valid type
is a change that silently never reaches a tester.

Coming: builds without the editor

We plan an external build tool driving the Unity CLI, so a build does not require someone to have
the editor open. Until then, builds are a person in Unity.