Programmer

You write the game code, and the tools the rest of the studio works in. The long-term goal is that
the team touches the Unity editor less and less, and most of what you build serves that.

Read these, in this order

Why
1 Version Control Branching, the commit format, and what is and isn't in the repo. Code is the one place we branch.
2 Builds Versioning, and why the commit format actually matters.
3 Scene Structure Multi-scene loading, and why cross-scene references don't serialise.
4 Core Concepts Bundles, assets, asset ids. The data model the Bubbly Asset Editor authors into.
5 Software UI Design & Consistency The shared style package, for anything with a UI.
6 Naming Conventions You will be writing validators and importers against it sooner than you expect.

Your tools

  • Unity
  • Gitea & Git LFS for projects, GitHub for shared packages
  • bubbly-asset-rules, the JSON every validator reads. Worth an hour of reading its README
    before you write anything that touches asset names.

Your first task

Nothing specific is written down for a new programmer yet, so ask your lead. Make a Build is worth
doing early whatever you are assigned, because it is the step that shows you how the commit format,
the changelog and the launcher fit together.

What actually goes wrong

Breaking the changelog. Changelogs are generated from commit messages since the last labelled
build, grouped by type. feat and fix are shown to testers, the rest are hidden. A commit
without a valid type is a change that silently never reaches a tester. Nothing else has to be
written for a changelog to exist, which is exactly why the format matters.
→ Version Control > Commit Format

Direct cross-scene references. They don't serialise, and they fail quietly. Registry, event
channel, or SceneManager lookup.

Hard-coding a rule. If it is an asset convention (a name, a folder, a budget, a format), it
belongs in bubbly-asset-rules and gets read from there. A rule that exists in two places has
already drifted; you just haven't noticed yet. Rebuild the add-on and the .exe after a rule
change, the same as any other consumer.

Leaving main unbuildable. Builds come from main and it has to be buildable at all times.
Code work happens on task branches and merges back after review.

Assuming everyone has Unity open. Most of the team doesn't, by design. If a workflow needs the
editor, that is usually a sign the tool is missing rather than that the workflow is fine.