# Mint Playground: Ten Three.js Experiences Built With Mint MCP and Mint Three.js Skills

> Mint Playground is a pnpm monorepo of ten open-source Three.js experiences, each built with Mint MCP as the asset pipeline and Mint Three.js Skills as the coding workflow. It is a reference collection, not a framework you install and import.

**mintdotgg/mint-playground** — Open-source Three.js experiences built with Mint MCP and Mint Three.js Skills

- Repository: https://github.com/mintdotgg/mint-playground
- Website: https://play.mint.gg
- Stars: 479 · Forks: 51
- Language: TypeScript
- License: MIT
- Published: 2026-09-17 · Updated: 2026-11-03 · Language: en
- Canonical page: https://hysenlabs.com/projects/mintdotgg-mint-playground

## What Mint Playground actually is, and who it is for

Mint Playground is not a 3D engine, a component library, or a starter template. It is a collection of finished browser experiences, published under the MIT licence, that double as worked examples. The README states that every app in the repository was made with Mint MCP as the 3D asset pipeline and Mint Three.js Skills as the coding workflow, so the repository is best understood as the output side of that pipeline rather than the pipeline itself.

The audience follows from that. If you are evaluating Mint MCP and want to see what its generated assets look like once they are placed in a real scene, the repository gives you ten of them with source. If you write Three.js and want to study how someone else structured a showroom, a first-person melee run, or a drag-to-shoot arcade game, the code is there to read. If you want a dependency to add to your own project, this is the wrong repository, and no amount of reading the README will change that.

## The ten experiences and what each one demonstrates

The README lists ten experiences, each with a path under experiences/ and a live demo on play.mint.gg. Vanguard Protocol is a cinematic five-character combat roster with animated fighters and reactive tactical staging. Helios Form is an orbital-vehicle showroom for inspecting six craft and their onboard systems, with audio. Neon Relic is a poster gallery where four sci-fi relics reshape typography, lighting, materials, and sound. Impossible Places is a travel magazine spanning five explorable Gaussian-splat worlds, which makes it the most technically distinctive entry in the set. Mint Hoops is a 60-second arcade basketball score attack with drag-to-shoot controls, combo multipliers, and a three-point finale. Mossbound is a first-person fantasy melee run through five escalating waves. Dynasty Index is a collector vault for six fictional sports trading cards. SF Tennis Atlas maps all 64 official San Francisco public tennis facilities and is described as source-aware, implying the civic data has provenance attached. Reef Rivals: Treasure Tide is a three-round projectile battler. CDX-2089 Music Player is a futuristic player with swappable skins.

Read as a set, the list is a coverage map of common WebGL tasks: character rosters, product showrooms, editorial layouts, splat rendering, arcade input, wave-based combat, data-driven maps, and skeuomorphic UI. That breadth is the point. A single demo tells you whether one technique works; ten demos tell you which techniques the toolchain handles without special pleading.

## How the monorepo is wired together

The repository root contains package.json, pnpm-workspace.yaml, pnpm-lock.yaml, LICENSE, README.md, .gitignore, and the experiences/ directory. The root package.json is marked private and versioned 0.0.0, and it declares a single script: build runs pnpm -r --if-present build. The --if-present flag matters here. It means the root build walks every workspace package and builds only those that define a build script, so a package without one is skipped rather than failing the run.

The package manager is pinned through the packageManager field to pnpm@10.6.2, and the lockfile is committed. The README does not document how assets move from Mint MCP into an experience, nor does it describe a shared runtime package. Based on the repository layout, each experience appears to be self-contained, with the shared surface being the tooling and conventions rather than imported code. That is a deliberate trade-off: it keeps each example readable in isolation, but it also means there is no single place to look for the common scene setup.

## Installing it and running your first experience

There is no published package to install. The README points at the repository and the live demos, so the workflow is to clone and build locally. The root declares pnpm@10.6.2, so use pnpm rather than npm or yarn if you want the lockfile to resolve as intended.

Clone the repository and install dependencies from the root. Because this is a workspace, the install resolves across all experiences at once.

```bash
git clone https://github.com/mintdotgg/mint-playground.git
cd mint-playground
pnpm install
```

Then run the root build script, which is the only script the root package.json defines. It delegates to every workspace package that has a build script.

```bash
pnpm build
```

What you should see is pnpm walking the workspace and reporting a build result per package, with packages that lack a build script skipped silently. The README does not document a dev server command, a preview command, or per-experience scripts, so if you want to run one experience interactively you will need to read that experience's own package.json under experiences/ and use whatever scripts it defines. Treat the live demos at play.mint.gg as the reference for intended behaviour, since the README does not describe local serving.

## Where this repository stops being useful

The README is a catalogue, not documentation. It gives each experience a title, a one-line description, a category tag list, a code link, and a demo link. It does not describe the shared conventions, the asset export format from Mint MCP, the expected directory structure inside an experience, or how to add an eleventh one. Anyone hoping to extend the collection will be reading source rather than instructions.

The root build script is also thin by design. It runs pnpm -r --if-present build, which means a broken or missing build script in one package produces no root-level error. If you are using this repository as a template for your own monorepo, that is a failure mode worth knowing about before you copy it.

Finally, there is no release history. The repository has no published GitHub releases, and the root version sits at 0.0.0 with private set to true. There is nothing to pin against, nothing to upgrade between, and no changelog to consult. The last push was on 2026-08-31, which is recent, but a recent push is not the same as a versioned artifact.

## Mint Playground against a generic Three.js example repository

The obvious alternative is the long tail of Three.js example repositories: collections of isolated scenes, usually one technique per file, with no asset pipeline behind them. The difference is where the work happens. A generic example repository typically starts from primitives, procedural geometry, or freely licensed models, and the interesting content is the rendering code. Mint Playground starts from assets produced by Mint MCP, and the interesting content is how those assets are staged, lit, animated, and made interactive.

That distinction determines which one helps you. If your problem is understanding a shadow technique or a post-processing pass, a conventional example repository isolates the variable better, because there is no asset pipeline in the way. If your problem is what a generated character or vehicle looks like once it is animated and lit in a finished scene, Mint Playground answers a question that primitive-based examples cannot. Conversely, if you do not use Mint MCP and have no intention of using it, you lose the part of the repository that makes it distinctive, and you are left with ten Three.js apps of varying complexity.

## Licence, maintenance, and what upgrading costs you

The repository is MIT licensed, and the root package.json repeats the MIT identifier. MIT is permissive: it allows use, modification, and redistribution with the licence and copyright notice retained. That covers the code. It does not automatically cover the visual assets, which the README sources from play.mint.gg and which may carry their own terms. The README does not state a licence for the experience assets, so if you plan to reuse a model, texture, or splat, treat that as unresolved and check before shipping. This is not legal advice.

On maintenance, the last push was on 2026-08-31, so the repository is not dormant by the six-month measure. There is still no release and no version to track, which means an upgrade is a git pull against main and a re-read of whatever changed. Because the root build uses --if-present, a pull can leave a package silently unbuilt if its build script was removed or renamed. The practical cost of following this repository is low, but the practical cost of depending on it is undefined, because there is nothing stable to depend on.

## Conclusion

Adopt mint-playground if you want working Three.js scene code to read and adapt, or if you already use Mint MCP and want to see what the asset pipeline produces when it is wired into a finished app. Do not adopt it if you need a library to import, a documented API, or a project with a published release history; the README describes experiences, not a package. Before you commit to it, clone the repository, run pnpm install and pnpm build at the root, and confirm that every workspace package you care about actually resolves and builds on your machine.

## FAQ

### Is mint-playground a library I can install with npm or pnpm?

No. The root package.json is marked private and versioned 0.0.0, and it exposes only a build script that runs pnpm -r --if-present build across the workspace. The README presents the repository as a collection of experiences with code links and live demos, not as a published package.

### How do I run a single mint-playground experience locally?

The README does not document a dev or preview command. The root build script is the only script declared at the root, so running one experience interactively means reading that experience's own package.json under experiences/ and using the scripts it defines.

### What tools were used to build the mint-playground experiences?

The README states that every app was made with Mint MCP as the 3D asset pipeline and Mint Three.js Skills as the coding workflow. The experiences themselves are Three.js, written in TypeScript, and the repository is a pnpm workspace.

## Sources

- [Issues](https://github.com/mintdotgg/mint-playground/issues)
- [License: MIT](https://github.com/mintdotgg/mint-playground/blob/main/LICENSE)
- [mintdotgg/mint-playground on GitHub](https://github.com/mintdotgg/mint-playground)
- [Project website](https://play.mint.gg)
- [README](https://github.com/mintdotgg/mint-playground/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mintdotgg-mint-playground