SDK Team — Overview
You maintain the ProjectV-SDK: the ProjectV contracts, the Nakama binding and
the presenters the Client team builds on. You also take each release through
BuildOps to SDK-Packages and keep these docs matching the shipped API.
Repositories
| Repository (branch) | Owns |
|---|---|
GameStudio3/projectz-nakama (v3) | ProjectV Nakama V3 server: operations, catalogs, contract bundle |
GameStudio3/nakama-core-module (v3) | Shared Nakama Core used by the server |
GameStudio3/ProjectZ-CrossSDK (v3) | Shared SDK source (9 com.silvertiger.crosssdk.* packages) |
GameStudio3/ProjectV-SDK (v3) | ProjectV-SDK source (this repo): 5 com.silvertiger.projectv.* packages, plus purchasing, and this site |
GameStudio3/BuildOps (main) | Candidate build, retention, approval and delivery workflows; release catalog |
GameStudio3/SDK-Packages (main) | Binary Git UPM packages and delivery indexes; what the Client pins |
GameStudio3/ProjectV-Client | The game; consumes one pinned release |
Rules
- The Client surface is
IProjectV*Presenterplus snapshots. Everything else —IProjectVSdk, feature clients, adapters, Nakama binding — is internal. - Server truth first: a new behaviour starts with the server operation and its contract, then the typed client, then the presenter.
- Packages ship as binaries only; consumers never compile SDK source.
- Every release is immutable and pinned by commit.
Read next: Architecture → Add a presenter → Mutation projections → Local development → Release pipeline → Versioning → Documentation standard.