zeroxm/pokemon-roulette

1. This is a client-side Angular 19 single-page game. The app shell lives in app.component, with route setup in app.routes.ts and global configuration in app.config.ts. There is no backend in the repo; gameplay, content, and state management are handled in the browser.

2. The top-level experience is split into route-like screens: the main game, trainer-team management, items, coffee, settings, credits, and a not-found screen. The app uses reusable button components such as the main game button, restart button, settings button, coffee button, and credits button to move between these areas.

3. The core gameplay loop is centered in src/app/main-game. That subtree contains the main game container plus a roulette system that drives most game events. The wheel component is the spinning interaction surface, while roulette-container selects and renders a specific roulette scenario.

4. The roulette system is the main architectural boundary. Each roulette component represents a different Pokémon-themed event or encounter: battles, item discovery, evolution checks, starter selection, fishing, fossils, caves, legendary encounters, paradox catches, gym/champion/elite-four battles, Team Rocket, shiny encounters, trades, and special story sequences. These are mostly isolated presentation/interaction modules that plug into the same container.

5. Most roulettes are data-driven from static tables in the repo rather than remote services. Generation-specific datasets such as pokemon-by-generation.ts, starter-by-generation.ts, champion-by-generation.ts, and similar files provide the content each roulette needs. This makes generation, region, and event selection a key content boundary in the design.

6. The domain logic is concentrated in src/app/services. These services encapsulate game rules and shared data such as Pokémon, Pokédex, generation, items, evolutions, type matchups, trainer sprites/forms, badges, rare candy behavior, and mega-stone handling. In the diagram, these services sit between UI components and the underlying static datasets/models.

7. Game state is managed separately from the UI. game-state-service, settings-service, badges-service, pokedex-service, and related services likely own the persistent browser-side progress and preferences that multiple screens need. This is the main cross-cutting state layer that ties gameplay, collection screens, and settings together.

8. Audio and feedback are part of the gameplay architecture. The public/ folder contains sound effects such as item found, PC login/logout, clicking, and Mega Evolution audio. sound-fx-service is the orchestration point for these assets, so sound is triggered by gameplay events rather than embedded directly in each component.

9. Internationalization and appearance are first-class concerns. Translation bundles live in src/assets/i18n for several languages, and the dark-mode/theme subsystem is implemented under services/dark-mode-service and services/theme-service, with matching UI in settings/dark-mode-toggle and settings/theme-selector. These are presentation-layer concerns that influence many screens.

10. The trainer and collection features form a second major user-facing subsystem outside the main game. trainer-team contains Pokédex, badges, and storage-PC views, backed by Pokémon/trainer data services. This area is distinct from the roulette loop: it is where accumulated game progress is inspected and managed.

11. Shared types and constants keep the content model consistent. The interfaces/ folder defines domain entities like Pokémon, items, gym leaders, forms, languages, wheel items, and type matchups, while constants/ holds fixed IDs and lookup values. This is the schema layer used by the services and roulette components.

12. Build and delivery are standard Angular CLI/GitHub Pages. The repository includes a GitHub Actions workflow, production/environment files, and angular.json. The README shows deployment to GitHub Pages with a /pokemon-roulette/ base href, which means the app is intended to run as a static hosted SPA.