Repository Guidelines

Project Structure & Module Organization

Unity assets live under Assets/Game/; Hero/, Enemy/, and Scenes/ store prefabs and scene content.
Gameplay code is in Assets/Game/Scripts/, grouped by domain: ThirdPerson* for locomotion, Combat/ for health & damage, and WeaponSystem/ for weapons, projectiles, and data assets.
Keep shared multiplayer logic in Scripts/ so both host and clients load identical behaviours; place editor-only utilities under an Editor/ folder to avoid runtime inclusion.

Open the project with the Unity Hub or run unity -projectPath ./ from the repo root to launch the editor.
Generate a standalone build with unity -projectPath ./ -buildTarget StandaloneWindows64 -executeMethod BuildScripts.BuildClient (create the BuildClient method in an editor script if missing).
Use the Unity Test Runner (Window > General > Test Runner) and run both Edit Mode and Play Mode suites before merging gameplay changes.

Follow standard C# conventions: PascalCase for classes, methods, and public members; camelCase for private fields; prefix serialized private fields with [SerializeField] and keep them private.
Organize namespaces under MegaKoop.Game.<Feature> to mirror the folder structure.
Prefer composition-friendly MonoBehaviours with explicit SerializeField dependencies; avoid singletons in gameplay code unless wrapped for network synchronisation.

Use Unity’s built-in NUnit framework for component tests; name files <Feature>Tests.cs and mirror the folder of the code under test.
Favour deterministic Play Mode tests that exercise Steamworks stubs or mock networking flows; document any non-deterministic behaviour in the test summary.
Aim for tests around new systems that affect combat sync, projectiles, or hero abilities so regressions are caught pre-merge.

Commit messages should be imperative and scoped (e.g., Add projectile lifetime clamps).
PRs must describe gameplay impact, list affected scenes/prefabs, and include replication steps for multiplayer behaviour.
Link to tracking tasks and attach editor or in-game screenshots/GIFs when modifying hero abilities, UI, or VFX.

Treat every feature as networked-first: verify authority flows, replication, and prediction before adding offline shortcuts.
Integrate Steamworks.NET for session management; keep wrappers in a dedicated networking layer so gameplay systems call high-level abstractions.
When adding hero abilities, ensure weapon firing, damage, and state changes trigger RPCs/events that work for host migration and client late-join scenarios.
Document any temp offline fallbacks and add TODOs to replace them with Steamworks-backed implementations.