# 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.

## Build, Test, and Development Commands
- 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.

## Coding Style & Naming Conventions
- 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.

## Testing Guidelines
- 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 & Pull Request Guidelines
- 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.

## Multiplayer & Online Rules
- 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.