52 lines
2.2 KiB
Markdown
52 lines
2.2 KiB
Markdown
# Repository Guidelines
|
|
|
|
## Project Structure & Module Organization
|
|
|
|
- `hearthmod/` contains legacy orchestration scripts and original docs.
|
|
- Core C services live in `hm_gameserver/`, `hm_lobbyserver/`, and shared code in `hm_base/`.
|
|
- Web UI is in `hm_web/` (Python `web.py`, templates, and static assets).
|
|
- Card rendering lives in `hm_sunwell/` (Node-based renderer).
|
|
- TLS proxy and web server components live in `hm_stud/` and `hm_nginx/`.
|
|
- Database snapshot/seed data is in `hm_database/`.
|
|
|
|
## Build, Test, and Development Commands
|
|
|
|
- `make -C hm_base target=game` builds the shared base library.
|
|
- `make -C hm_gameserver` builds the gameserver binary.
|
|
- `make -C hm_lobbyserver` builds the lobbyserver binary.
|
|
- `bash hearthmod/host_ctl_ubuntu.sh start <ip>` starts the legacy stack.
|
|
|
|
When adding new workflows, prefer a single entrypoint script (e.g., `./dev`) or
|
|
container orchestration; keep legacy scripts untouched unless required.
|
|
|
|
## Coding Style & Naming Conventions
|
|
|
|
- C code uses 4-space indentation and snake_case identifiers.
|
|
- Python uses 4-space indentation; prefer explicit names over abbreviations.
|
|
- Avoid one-letter variable names except for simple loop counters.
|
|
- Centralize ports and credentials in config or env variables.
|
|
|
|
## Testing Guidelines
|
|
|
|
- There is no dedicated test suite today.
|
|
- If you add tests, keep them close to the component (e.g., `hm_web/tests/`).
|
|
- Favor smoke tests that validate service ports and Couchbase connectivity.
|
|
|
|
## Commit & Pull Request Guidelines
|
|
|
|
- Git history is limited here; use concise imperative commit messages.
|
|
- Pull requests should include a short summary and testing notes.
|
|
- If you touch configuration or workflows, update the README.
|
|
|
|
## Modernization Roadmap (Maintainability)
|
|
|
|
The long-term goal is to replace components one at a time while keeping protocol
|
|
compatibility. Suggested phases:
|
|
|
|
- Baseline: document current behavior and add logs/health checks.
|
|
- Gateway: add a thin protocol gateway to route traffic to legacy services.
|
|
- Lobby: reimplement lobby features behind the gateway with canary routing.
|
|
- Game: reimplement game loop and compare state snapshots for parity.
|
|
- Data: introduce a new data layer, mirror writes, then flip reads.
|
|
- Decommission: remove unused legacy components once traffic is migrated.
|