Working Effectively as a Team

Game jams are won by communication as much as by code. A small team that has agreed on file ownership, a git workflow, and a daily check-in will out-ship a more talented team that hasn't. s&box projects play well with git, but you need to ignore the right folders and watch out for binary asset conflicts.

Set up the repo with a good .gitignore

Track Code/, Assets/, the .sbproj, and any .scss/.razor/.shader source files. Ignore obj/, bin/, .vs/, .idea/, and .vscode/ (unless you specifically want to share VS Code settings). Also ignore the auto-generated .sln if your team uses different IDEs — it can be regenerated by opening the project. Don't ignore .meta or .scene files — those are your scene graph and prefab references; lose them and your scenes break.

# .gitignore for an s&box project

# IDE / build output
obj/
bin/
.vs/
.idea/
.vscode/
*.user
*.suo

# Auto-generated solution (let each dev regenerate)
*.sln

# OS junk
.DS_Store
Thumbs.db

# Local-only logs and caches
*.log
logs/

Treat scenes and prefabs as locked files

.scene and .prefab files are JSON, so git can technically merge them, but a real merge of two people's scene edits almost always corrupts something subtle (missing GameObjects, broken component references). The pragmatic rule for a jam: only one person edits a given scene or prefab at a time. Communicate before you open Main.scene. Use git LFS or just git for binary assets like .vmdl source FBXs and textures, and again coordinate edits.

Split work along Component boundaries

Components are the perfect unit of ownership. Designate one person per major Component (PlayerMovement, EnemyAI, ScoreManager, HudPanel) and they own that file. Multiple Components on the same GameObject can be edited by different people in parallel without merge conflicts, because each is its own .cs file. Reserve scene wiring (dragging Components together in the Inspector) as a synchronous, one-person-at-a-time task.

Use small, frequent commits

Commit every working change — when a feature compiles and the game still runs, push. Don't sit on a branch for six hours; you'll either step on a teammate's edits or lose work. If you must do a big risky refactor, branch, but rebase onto main daily. Small commits also make it trivial to revert when the polish phase reveals that yesterday's 'cool' system actually broke the win condition.

Talk every few hours

Open a voice channel and stay in it. Every few hours, do a thirty-second sync: what are you on, what's blocking you, what's next. This catches problems while they're cheap — the artist who's been blocked for an hour because they don't know the texture naming convention, the programmer who didn't realise design changed the win condition. Async docs help too: pin a list of agreed mechanics, controls, and asset specs somewhere everyone can see.