truongtuan1312/blockblast-group2

1. Project type and runtime

- This is a desktop Java game that clones Block Blast.

- The architecture is centered on a Swing-style UI with an in-process game loop and no external backend or services.

2. Application entry and shell

- Main.java is the startup point.

- BlockBlastFrame.java is the top-level window/container.

- GamePanel.java is the main rendering and update surface where gameplay is likely run.

3. User input boundary

- InputHandler.java isolates keyboard/mouse interaction from game logic.

- Input likely feeds the panel/game state rather than manipulating board data directly, which keeps UI and rules separated.

4. Core game model

- Board.java represents the playfield and placement rules.

- Piece.java represents the draggable/placable block shapes.

- InvalidPlacementException.java is used to signal illegal moves, so placement validation is explicit in the domain layer.

5. Piece creation and variation

- PieceFactory.java is responsible for generating pieces.

- This is a clear creation boundary: the rest of the game consumes pieces without needing to know how they are assembled or randomized.

6. State management and undo

- GameState.java appears to capture the full mutable game snapshot.

- GameStateMemento.java supports snapshotting/restoring that state.

- UndoManager.java manages the history stack or rollback flow, making undo a first-class subsystem rather than ad hoc logic.

7. Scoring system

- ScoreStrategy.java defines scoring behavior as a pluggable policy.

- ClassicScoreStrategy.java provides the concrete scoring rules used by the game.

- This indicates the score calculation is intentionally separated from board mechanics.

8. Rendering abstractions

- Drawable.java suggests a shared render contract for on-screen objects.

- ScoreText.java is likely a UI overlay element for score feedback.

- LevelTheme.java implies visual theming is data-driven or at least abstracted from gameplay logic.

9. Visual effects subsystem

- Particle.java is the base effect type.

- AtmosphereParticle.java and DebrisParticle.java are specialized particle effects for ambient motion and placement feedback.

- These are presentation-only objects that enhance the game feel without affecting rules.

10. Object reuse / performance

- GameObjectPool.java indicates pooling for transient objects, probably particles or other short-lived render entities.

- This is a performance-oriented boundary to reduce allocation churn during gameplay.

11. Audio feedback

- SoundManager.java is a separate subsystem for sound effects.

- It likely reacts to game events such as placement, clears, invalid actions, or undo, instead of being called from rendering code.

12. Overall data flow

- The typical flow is: input → game panel/controller logic → board/piece validation → scoring/state update → visual/audio feedback.

- Undo works by restoring a prior GameState snapshot.

- Rendering consumes current model state plus transient effects like particles, score text, and theme data.

13. Main architectural boundary

- The code cleanly separates:

- game rules (Board, Piece, scoring, exceptions),

- state/history (GameState, memento, undo),

- presentation/effects (GamePanel, drawable objects, particles, score text, theme),

- support services (SoundManager, object pool, factories).

- That separation is the key to drawing an accurate architecture diagram for this repository.