Getting started

The quick way: let Claude Code do the setup

This is the same three-step start as your welcome email. Claude Code reads the setup file and walks you through every install below, checking what you already have. The only cost is a Claude account on the Pro plan ($20 a month); everything else is free.

1. Pick your developer folder and install Claude Code. Everything we install, and all your agents' work, lives in one folder. Choose a drive with plenty of free space (60 GB or more is comfortable). Any name works; we suggest Dev. Open PowerShell (Windows key, type PowerShell, Enter) and run these three lines, one at a time, changing D:\Dev if you picked another drive or name:

   New-Item -ItemType Directory -Force D:\Dev | Out-Null; Set-Location D:\Dev
   winget install --id Git.Git --source winget --accept-package-agreements
   irm https://claude.ai/install.ps1 | iex

2. Save the setup file into that folder: download GettingStarted.md. It is the same file attached to your welcome email.
3. Start Claude and hand it the file. Close PowerShell, open a new one, and run the two lines below. The second starts Claude on the studio's standard model, Opus 5.5 with medium reasoning. Sign in with your Claude account when asked, then type the sentence.

   Set-Location D:\Dev
   claude --model claude-opus-5-5 --effort medium

   Read GettingStarted.md and walk me through it step by step.

Prefer to do it by hand? Everything Claude would install is listed in the sections below, in the same order.

1. Accounts (everyone)

1. Team Google account. The lead creates a sign-in for you on the studio's Google Workspace, or adds the Google address you already use to the team list. Reply to the lead's email with the address you want to use.
2. Look around the site. You are already signed in with that Google account, since this page is behind the sign-in. Open Projects to see the games we are building and the task board for each, and People to find your own profile, where your points and the two signed documents show up. If anything says you are not on the list, tell the lead; adding you takes a minute.
3. Shared Drive, chat and calendar. These come with the Google account. The hand-off folders for art and audio, the team chat and the weekly playtest invite all live there.
4. GitHub account (coders, tools people and anyone making engine content). Create one at github.com/signup if you do not have one. Send the lead your username and accept the invitation to the GarrackGamingStudios organization when it arrives by email. Turn on two-factor authentication; the organization requires it.

2. Windows (coders and tools people)

The command line tools we use want a current Windows. Check these before installing anything else.

1. Windows 10 version 22H2 or Windows 11. Press Win + R, type winver, press Enter. Anything older: run Windows Update until it is current, restart, and check again.
2. Install all pending updates. Settings, Windows Update, Check for updates. Repeat until it says you are up to date. Several tools below (the Windows Package Manager in particular) depend on recent updates.
3. App Installer and winget. Open the Microsoft Store, search for App Installer and update it. Then open PowerShell and run winget --version. If it prints a version, you are set.
4. Developer settings. Settings, System, For developers: turn on Developer Mode (lets Git create symbolic links) and, under File Explorer, show file extensions.
5. Long paths. Game projects have deep folders. In an administrator PowerShell run the line below once, then restart.

   New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name LongPathsEnabled -Value 1 -PropertyType DWord -Force

6. Optional but recommended: Windows Terminal from the Microsoft Store, and WSL if you prefer a Linux shell: wsl --install in an administrator PowerShell, then restart.

3. PowerShell and the basic tools

1. PowerShell 7. Windows ships PowerShell 5.1, which works for our scripts, but 7 is nicer. In PowerShell run:

   winget install --id Microsoft.PowerShell --source winget

   Afterwards open PowerShell 7 (pwsh) from the Start menu for the rest of this guide.
2. Allow local scripts. Our task scripts are plain .ps1 files. Run once:

   Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

3. Python 3.12 or newer. The finish script and the bot scripts use it.

   winget install --id Python.Python.3.13 --source winget

   Close and reopen the terminal, then check with python --version.
4. Node.js 22 LTS. Needed for Codex, for the Mr. Mak tile installer and for some tools.

   winget install --id OpenJS.NodeJS.LTS --source winget

   Check with node --version.
5. A code editor. Visual Studio Code is the common choice: winget install --id Microsoft.VisualStudioCode --source winget. Any editor works.

4. GitHub, Git and Git LFS

1. Install Git and Git LFS.

   winget install --id Git.Git --source winget
   winget install --id GitHub.GitLFS --source winget

   Git for Windows includes Git Bash, which Claude Code needs on Windows. Open a new terminal and run git lfs install once.
2. Tell Git who you are. Use the same name and email as your GitHub account.

   git config --global user.name "Your Name"
   git config --global user.email "you@example.com"
   git config --global core.autocrlf true
   git config --global init.defaultBranch main

3. GitHub CLI. The task scripts use it to update the board for you.

   winget install --id GitHub.cli --source winget
   gh auth login

   Choose GitHub.com, HTTPS, and sign in through the browser. Check with gh auth status.
4. Clone the game repo into a short path such as D:\Dev or C:\Dev. Spaces and OneDrive folders cause trouble with engines.

   mkdir D:\Dev; cd D:\Dev
   git clone https://github.com/GarrackGamingStudios/game.git
   cd game
   pip install -r requirements.txt
   python -m pytest

   If the tests pass, your machine is ready for the task scripts.
5. Read the rules. AGENTS.md in the repo is one page: what you may edit, what you must not, how branches and pull requests are named. It applies to people and to coding assistants alike.

5. Claude Code and Codex CLI (optional)

You may use either or both. They follow the same AGENTS.md rules you do, and the board asks on the plan form which one you used. Two things never change: a person submits the plan, and a person presses Ready to test.

Claude Code

1. Needs Git for Windows (installed above) and a Claude account with a Pro or Max subscription, or an API key from Anthropic. The studio does not provide one yet; ask the lead what the team is using.
2. Install the native Windows build in PowerShell:

   irm https://claude.ai/install.ps1 | iex

   Alternative through Node: npm install -g @anthropic-ai/claude-code.
3. Open a terminal in the game folder and run claude. Sign in when asked. Try /help, then ask it to read AGENTS.md and draft a plan for a task number. Paste its answers into the plan form yourself.
4. Check your usage with /usage inside Claude Code. Headless runs by the studio's own tools count against the lead's account, not yours.

Codex CLI

1. Needs Node.js 22 or newer (installed above) and a ChatGPT account (Plus or above) or an OpenAI API key.
2. Install:

   npm install -g @openai/codex

   Run codex in the game folder and sign in. On Windows, Codex works best inside WSL; native Windows support is newer and may ask you to approve more actions.
3. Codex reads AGENTS.md on its own. Ask it to draft a plan the same way.

6. Mr. Mak Workspace (optional)

Mr. Mak is the personal workspace some of us use to run coding assistants and keep notes and tiles in one place. If you use it, the studio board can sit inside it as a tile. If you do not, skip this; the website board is the same thing.

1. Set up your own Mr. Mak workspace repo following its README (the lead can send you the link). It stays personal; only you push to it.
2. Add the board tile as a submodule and register it:

   cd <your mr-mak-workspace>
   git submodule add https://github.com/GarrackGamingStudios/studio-tile.git workspace/studio
   node workspace/studio/tools/install-tile.mjs
   powershell -File workspace/studio/tools/sync.ps1

3. Optional: powershell -File workspace/studio/tools/register-sync-task.ps1 creates a scheduled task that pulls the latest board every 15 minutes. It asks before creating anything.
4. Inside the tile, pick your name once from the "Choose who you are" menu; it is remembered on that device only. Buttons there open GitHub, since there is no sign-in inside the tile.

7. Blender (artists, animators, tech art)

1. Install Blender 4.x LTS from blender.org or winget install --id BlenderFoundation.Blender --source winget. We will pin one exact version once the engine is chosen; until then any current 4.x is fine.
2. Units and scale. Scene units metric, unit scale 1.0, one Blender unit equals one meter. Apply scale before exporting.
3. Naming. Lowercase, underscores, no spaces: hero_idle_v2.blend, sm_wall_01.fbx. The validators in Phase 2 will enforce this, so starting now saves renames.
4. Hand-off. Source .blend files and exports go in the task's hand-off folder on the shared Drive, in a subfolder named after the task number. Press Ready to test on the board when the folder is complete.
5. The art direction and palette are in docs/vision.md in the game repo; ask the lead for a copy if you are not on GitHub.

8. Unity (your own sandbox, starting now)

We are starting with Unity 6.3 LTS. The shared studio project arrives with Phase 2; until then every developer sets up Unity on their own PC, makes a personal sandbox project and builds their own ideas. That is real practice for the studio project, and good sandbox work can become a task plan later.

1. Check your PC. 64-bit Windows 10 or 11, a GPU with DX11 or newer and current drivers, 16 GB RAM is comfortable, and about 40 GB free on a fast drive for the editor plus a project.
2. Install Unity Hub. Download from unity.com/download or run winget install --id Unity.UnityHub --source winget. Open the Hub and sign in with a Unity ID (make one if needed). Choose the free Personal license when asked; it covers what we do.
3. Install the editor. In the Hub: Installs, Install Editor, pick the newest Unity 6.3 LTS release (it shows as 6000.3.x). Tick these modules: Microsoft Visual Studio Community 2022 (unless you already have an editor you prefer), Windows Build Support (IL2CPP), and Linux Dedicated Server Build Support (our game servers will run on Linux). Documentation is optional. Let it install; this takes a while.
4. Script editor. If you installed Visual Studio, make sure the Game development with Unity workload is selected. If you use VS Code instead, install the C# Dev Kit extension and set Edit, Preferences, External Tools in Unity to VS Code.
5. Make your sandbox project. Hub, Projects, New project, template Universal 3D (URP). Name it after yourself or your idea, and put it under D:\Dev next to the game repo, never in OneDrive or Documents.
6. Put the sandbox in Git from day one. In the project folder:

   git init -b main
   git lfs install
   curl -o .gitignore https://raw.githubusercontent.com/github/gitignore/main/Unity.gitignore
   git add .gitignore
   git commit -m "Unity sandbox"

   Then in Unity: Edit, Project Settings, Editor, set Asset Serialization to Force Text and Version Control to Visible Meta Files. Push it to your own GitHub account if you like. This is your repo; the studio repo is separate.
7. Learn by building something small. Good first targets: a character that runs and jumps on a greybox level, a capture point that fills when a player stands on it, a simple lobby. Unity Learn's Essentials and Junior Programmer paths are free and solid. Save short clips of what you build; they make great plan material later.
8. Multiplayer when you are ready. Window, Package Manager, Unity Registry: add Netcode for GameObjects and Multiplayer Play Mode. Multiplayer Play Mode runs several players from one editor, which is how we will test locally. Unity's Get started with NGO tutorial is the right first read.
9. Keep to the team conventions now. Lowercase folder names under Assets/ by type (Scripts, Prefabs, Scenes, Art, Audio), meters as units, one scene per idea, and commit often. Dedicated server, server-authoritative gameplay is the studio rule, so get used to the idea that the server decides.

9. Your first task

1. Read the board once. Tabs along the top: Tasks by role (folded by default, open the roles you care about), My tasks, Who has what, Plan inbox, Trains. Every task opens to a page with its description, every plan on file and the comments.
2. Comment freely. You do not need to hold a task to leave an idea, report a bug or suggest an improvement. Open the task and write in the comment box; it is posted under your name.
3. Plan before or after claiming, your choice. You can submit a plan for any open task. Several people may plan the same task; the lead picks one, and approval assigns the task to that plan's author. Or claim first to show you are on it, then plan.
4. Wait for the reply, usually within the hour. Each plan gets a written answer with a reason: approve, needs a small change, queued behind overlapping work, or waits for the lead. High risk areas (networking, build settings, shared data) always wait for the lead; that is normal.
5. Work. Coders: .\scripts\task\start.ps1 <task> makes your branch and moves the task to In progress; sync.ps1 at the start of each session; finish.ps1 before the pull request. Everyone else: work in your tools and upload to the hand-off folder.
6. Hand it in. Pull request with Closes #<task> in the description, or a complete hand-off folder. Press Ready to test. Finished work goes into the next test train and onto the shared server, where the whole team plays it.
7. Drop anything, any time. Life happens. Press Drop and the task goes back to the pool with no questions. After three quiet days you get a reminder; after seven the task frees itself.

Help

• Stuck on a step: write in the team chat or comment on your task. Say which step and paste the exact error text.
• Sign-in to the board fails: the lead adds your email to the list; it takes a minute.
• A script says your working tree is not clean: commit or stash first, then run it again. Every script has a dry-run switch that shows what it would do.
• Tell the lead which part of this page confused you. It gets fixed for the next person.

Open Projects The game repo on GitHub