33 lines
2.8 KiB
Markdown
33 lines
2.8 KiB
Markdown
# 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.
|