lcfyhr/minigames

1. This repository is a collection of standalone mini-game applications, not one shared product. Each game lives in its own top-level folder with its own source tree, IDE metadata, and build output. There is no shared library layer between the games.

2. The codebase splits cleanly by runtime:

- Java projects: ChessGame, Clingy Wall, Jumpy Ball, Mario Game

- Python projects: snakegame, MouseController

Each project appears to be independently runnable and packaged.

3. A repeated Java pattern shows a simple desktop-game architecture:

- a Main.java entrypoint starts the game

- a small set of domain classes model the core objects

- the main loop likely owns input handling, updates, and rendering

The file trees suggest these are compact, self-contained game loops rather than layered apps.

4. Jumpy Ball is the most minimal Java game structure:

- Main.java orchestrates the game

- Ball.java models the player-controlled object

- Wall.java models obstacles

The core data flow is likely input → ball movement → wall movement/collision → game state update.

5. Clingy Wall follows the same game-loop pattern but with more entities:

- Main.java

- Ball.java

- Blocks.java

- Platforms.java

This implies a vertical platforming/climbing game where the main loop coordinates physics-like movement, collision with blocks/platforms, and scrolling progression.

6. Mario Game is another Java desktop game, but it includes a persistent file:

- Main.java

- Highscore.txt

The presence of a text file indicates a simple file-based persistence boundary for score tracking, separate from the in-memory game state.

7. ChessGame is structured as a board-state model:

- Main.java

- Board.java

- Square.java

This suggests a local, two-player chess implementation where the board and its squares are explicit state objects, and Main drives interaction and turn flow. The README notes unfinished check/checkmate and move validation logic, so the current architecture likely centers on board representation more than complete rules enforcement.

8. The Python side is similarly self-contained. snakegame has a single snake.py, which likely contains the full game loop, state, and rendering/input logic in one file. That makes it a monolithic script rather than a multi-module app.

9. MouseController is not a game but an automation tool:

- cprautomine.py

- venv

The script is isolated in its own environment, which suggests external library usage and/or OS-level automation. Architecturally, it is a separate utility program with no dependency on the game code.

10. The main architectural boundary across the repo is therefore per-game isolation. There is no visible inter-process communication, shared assets, or reusable engine layer. Each folder is its own runtime island with its own entrypoint and state.

11. Input/output is mostly local and interactive:

- inputs: keyboard/mouse events for the games

- outputs: game rendering and state changes

- persistence: only clearly visible in Mario Game/Highscore.txt

- automation: MouseController likely interacts with another application via simulated input rather than internal APIs

12. For an architecture diagram, the top-level structure should show:

- repository root

- six independent application boxes

- Java vs. Python runtime separation

- a small file-persistence side channel for Mario

- no shared backend, database, or network service