bzzzthe18th/monkemodmanager

1. What this repo is

- Monke Mod Manager is a Windows desktop installer/updater for Gorilla Tag mods.

- Its main job is to fetch the latest GitHub releases for a curated mod list, then install or update those mods into the local game files.

2. Top-level application shape

- The app is a WinForms program in the MonkeModManager project.

- Program.cs is the entry point and launches the main UI.

- The main screens are FormMain and FormSelectPlatform, so the app is largely a UI-driven installer rather than a service or library.

3. User-facing flow

- The user starts in the main form, chooses a platform target when needed, and triggers install/update actions.

- The installer then resolves what mods should be present, downloads the relevant release artifacts, and extracts them into the target game directory.

- Re-running the app acts as an update mechanism as well as an initial installer.

4. Mod catalog and release source

- mods.json is the central catalog of supported mods.

- The README says mod versions are discovered through the GitHub API, so the app does not hardcode binaries; it pulls the latest release metadata at runtime.

- This creates a clean boundary between the installer and the mod authors’ repositories.

5. Package acquisition and extraction

- Internals/ReleaseInfo.cs likely models GitHub release data and the downloadable asset information.

- Internals/Unzip.cs handles archive extraction, which is the final step before files are placed into the game install.

- The installer therefore has a simple pipeline: metadata lookup → download asset → unzip to destination.

6. JSON and data parsing

- Internals/SimpleJson.cs is a custom lightweight JSON parser/serializer used instead of a larger dependency.

- This suggests the app keeps its runtime dependencies small and handles API responses or catalog data internally.

7. Platform selection boundary

- FormSelectPlatform indicates there is an explicit platform split in the install target, likely because different Gorilla Tag distributions or runtime layouts need different output paths.

- This selection is a key architectural boundary because it affects where files are installed and possibly which mod package variant is chosen.

8. Local state and app configuration

- app.config, Properties/Settings.*, and Properties/Resources.* support desktop-app configuration, saved settings, and embedded UI/resources.

- app.manifest shows the app is packaged as a classic Windows desktop executable with explicit Windows runtime behavior.

- update.txt files in the repo/project likely serve as version/update markers for the app itself or its release packaging.

9. External dependencies and environment

- The app depends on:

- the GitHub API for release metadata,

- the local filesystem for the Gorilla Tag install path,

- zip archives for mod distribution.

- The game installation is the primary external boundary: the manager does not host mods itself; it mutates a local third-party app directory.

10. Build and release process

- The .sln and .csproj define a standard Visual Studio build.

- .github/workflows/actions.yml indicates CI/release automation exists, likely for building or publishing releases.

- MonkeModManager.sln and the WinForms designer files indicate a conventional Windows desktop release pipeline rather than a containerized or server-based architecture.

11. How to diagram it

- A good architecture diagram would show:

- the WinForms UI layer,

- the mod catalog / GitHub API metadata source,

- the download + unzip installer pipeline,

- and the local Gorilla Tag installation as the final destination.

- The main data flow is from mods.json and GitHub release metadata into downloaded archives, then into extracted files in the game directory.