Bamort ist ein Ersatzwerkzeug für MOAM mit dem Schwerpunkt auf Charakterverwaltung für Rollenspiele. Das Projekt bietet ein einfaches, erweiterbares System zur Charaktererstellung, zum Erlernen neuer Fertigkeiten und zur Charakterentwicklung. Langfristiges Ziel ist es, die Regeln für Charaktererstellung und -weiterentwicklung aus dem Code zu extrahieren und ein austauschbares Regelwerk‑Framework bereitzustellen.
## Ziele
- Ein modernes, wartbares Ersatzwerkzeug für MOAM mit Fokus auf Charaktere bereitstellen.
- Langfristig: Regeln für Generierung und Fortschritt im Code abbilden und ein Framework anbieten, mit dem verschiedene Regelwerke implementiert und gewechselt werden können.
## Architekturüberblick
Monorepo mit zwei Hauptteilen: Backend und Frontend.
Bamort is a replacement tool for MOAM focused on character management for role‑playing games. The project aims to provide a simple, extensible system for character creation, learning new skills, and character development, with a long‑term goal of extracting the rules for character generation and advancement from code and exposing a pluggable ruleset framework.
## Goals
- Provide a modern, maintainable replacement for MOAM focused on characters.
- First-class focus on:
- Character creation (attributes, derived values, starting skills).
- Character development (learning new skills, improving existing skills).
- Long-term: encode generation & progression rules in code and offer a framework so different rulesets can be implemented and swapped.
## Architecture overview
Monorepo with two primary parts: backend and frontend.
- Backend
- Language: Go (1.25+)
- Frameworks: Gin (HTTP), GORM (ORM)
- Responsibilities: API, business logic, rules implementation, PDF export
- Typical layout: modules per domain (character, pdfrender, equipment, ...)
- Entry point: cmd/main.go
- Frontend
- Framework: Vue 3 + Vite
- State: Pinia stores
- i18n: locale files under src/locales/
- Responsibilities: character UI (creation, edit, development), admin tools
- Data & Devops
- Database: MariaDB for dev/prod; SQLite used for tests
- Containers: Docker Compose with separate dev containers for backend, frontend, and DB
- PDF rendering: chromedp in the pdfrender module (requires Chromium in container)
## Quick dev notes
- Protected API routes live under `/api` and require JWT auth.
- Templates for character export are stored under `templates/` and the directory can be configured via env var TEMPLATES_DIR.
- Use the included docker-compose dev setup for live reload:
- Backend: `bamort-backend-dev` (Air, port 8180)
- Frontend: `bamort-frontend-dev` (Vite, port 5173)
- DB: `bamort-mariadb-dev` (MariaDB)
## Testing
- Backend tests use `testutils.SetupTestDB()` and a test environment (`ENVIRONMENT=test`).
- NEVER add a `main()` to test files; tests must end with `_test.go`.
- Example commands:
- cd backend && go test -v ./character/
- cd backend && go test -v ./pdfrender/ -run TestExportCharacterToPDF
## Extensible ruleset plan
- Core idea: move rules for generation and progression from ad‑hoc code into modular, versioned ruleset packages.
- Rulesets should:
- Define validation and generation steps for a character.
- Expose hooks for skill learning and progression algorithms.
- Be selectable at runtime (config or per‑campaign).
- Early work will hardcode canonical rules; later refactors will extract interfaces and provide example alternate rulesets.
## Contributing
- Follow KISS and TDD: write failing tests first, implement minimal change.
- Add translations to both `src/locales/de` and `src/locales/en` for new UI strings.
- Keep changes modular per domain module (see backend module pattern).
## Where to look first
- backend/character — character handlers and routes
- backend/models — data models
- backend/pdfrender — PDF template system and rendering logic handlers and routes
- frontend/src/views — primary UI entry points for character workflows
