eliaws/el_mon_tribala

1. What this repository is

el_mon_tribala is a standalone Java card game inspired by Balatro. It is an offline, single-player run-based game where the player must clear successive blinds by reaching score targets with poker hands.

2. Top-level architecture

The code is organized around a clear MVC split, but with game rules extracted into a separate domain/ layer. In practice: the controller coordinates the run, the model stores mutable game progression, the domain encapsulates all poker/economy rules, and the view layer renders the state in either console or “zen” mode.

3. Entry point and launch modes

src/Main.java is the application entry point. The README shows two runtime modes selected by command-line argument: console and zen. That means presentation is swapped at startup, while the underlying game logic stays the same.

4. Control flow through the game loop

controller/GameController.java is the main orchestrator. It receives player actions from a view, applies them to the game state, and produces a PlayResult that likely summarizes the outcome of a move or hand. This keeps the UI from directly mutating game rules.

5. Mutable game state vs. rule objects

model/GameState.java and model/GamePhase.java hold the evolving run state and the current phase of play. This layer is the bridge between UI and rules: it tracks where the player is in the run, what phase they are in, and what the controller should allow next.

6. Core domain entities

The domain/ package contains the game’s fundamental concepts: Card, Rank, Suit, Deck, Blind, and Shop. These are the data and rule objects that define the game without any rendering concerns. Blind represents the score challenge to beat, and Shop represents the between-blind economy.

7. Progression and economy

domain/consummables/Planet.java is the main upgrade item. The README says planets improve poker combinations, so the shop is not cosmetic: it is a gameplay subsystem that modifies scoring/progression between blinds. The run is structured around 8 antes, so progression is a sequence of increasingly demanding score thresholds.

8. Hand representation and evaluation

Poker logic is split into multiple layers under domain/hand/. HandType classifies a hand, hand/combinations/* contains concrete poker-hand implementations such as Pair, TwoPair, Straight, Flush, FullHouse, and RoyalFlush, and PlayedHand likely binds an actual set of cards to one of those recognized combinations.

9. Scoring pipeline

domain/hand/evaluation/HandEvaluator.java determines what kind of hand was played, and domain/hand/scoring/HandScorer.java converts that evaluation into a numeric Score. This separation matters: recognition of the hand is distinct from calculating its value, which makes balancing easier and keeps the scoring logic isolated.

10. Presentation layer

view/View.java is the abstraction, with ConsoleView.java and ZenView.java as concrete presenters. Rect.java suggests the zen interface uses positioned rectangular UI elements. The view layer reads state/results and displays them; it should not contain game rules.

11. Assets and theming

src/ressources/ contains fonts and image sets grouped by themes such as death, life, planets, space, and time. These assets are part of the presentation layer and reinforce that the game uses themed visuals rather than external services or dynamic content.

12. Important architectural boundary

The strongest boundary in this repository is between presentation/game flow and pure game rules. That makes the scoring, hand evaluation, and progression systems reusable across both console and zen views, and it keeps the architecture suitable for diagramming as: input/view → controller → state/domain → view update, with assets only touching the final rendering step.