# Shattered Pixel Dungeon: A GPL-3.0 Roguelike You Can Actually Build > Shattered Pixel Dungeon is an open-source traditional roguelike for Android, iOS and desktop, built on Watabou's Pixel Dungeon source. Here is what the repository gives you, what it explicitly refuses to give you, and where the build guides live. **00-Evan/shattered-pixel-dungeon** — Shattered Pixel Dungeon is an open-source traditional roguelike dungeon crawler with randomized levels and enemies, and hundreds of items to collect and use. It's based on the source code of Pixel Dungeon, by Watabou. - Repository: https://github.com/00-Evan/shattered-pixel-dungeon - Website: https://shatteredpixel.com/shatteredpd/ - Stars: 6,587 · Forks: 1,641 - Language: Java - License: GPL-3.0 - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/00-evan-shattered-pixel-dungeon ## What Shattered Pixel Dungeon Is and Who the Repository Serves Shattered Pixel Dungeon is a traditional roguelike dungeon crawler with randomized levels and enemies and hundreds of items, distributed on Google Play, the App Store, Steam, GOG and itch.io. The source is a fork of Pixel Dungeon by Watabou, written in Java and built on LibGDX. The repository is not a community project in the usual sense. Its README states plainly that it does not accept pull requests, and that the code is published so others may find it useful for their own projects. Bug reports and feature requests are welcome. That single sentence defines the audience. If you want to play the game, you install it from a store. If you want to read a mature, single-author roguelike codebase, fork it into your own game, or study how a LibGDX project is split across Android, iOS and desktop targets, this repository is aimed at you. If you want to send a patch upstream, it is not. ## How the Gradle Multiplatform Layout Is Organized The top level shows the shape of the build: core/, android/, ios/, desktop/, services/, SPD-classes/, metadata/, plus build.gradle, settings.gradle and the Gradle wrapper. The convention is the standard LibGDX one. Game logic and assets live in core/, and each platform module wraps that shared code for its own runtime. When you compile for desktop you are building the desktop wrapper around core, not a separate codebase. docs/ holds the guides the README points to: getting-started-android.md, getting-started-desktop.md, getting-started-ios.md and recommended-changes.md. The Android guide carries a warning that if you plan to distribute on Google Play you should read the end of it, which is where the project explains what to change before you publish under your own identity. recommended-changes.md is the document that tells you what to alter when you make your own version, and it is the one file in docs/ a forker should read before touching anything else. ## Installing and Running a First Build The README does not give a single universal install command. It points to per-platform guides in docs/, so the first real step is to open the guide for the platform you are on. What the repository does provide at the top level is the Gradle wrapper, gradlew on Unix-like systems and gradlew.bat on Windows, which is how the project is built without a separately installed Gradle. On a desktop machine, the wrapper is the entry point. The desktop guide in docs/getting-started-desktop.md is the document that describes the desktop toolchain, and the wrapper is invoked from the repository root: ```bash ./gradlew ``` If the desktop module is configured as the guide describes, running the wrapper in the repository root is how Gradle tasks are started. The README does not list the individual task names, so the desktop guide is where to look for the exact target. For Android, the README directs you to docs/getting-started-android.md, and the same wrapper pattern applies. The Android guide is also where the Google Play distribution note lives, so read the end of that file before you plan to publish. iOS is the third target; docs/getting-started-ios.md is the only place the repository describes that toolchain, and it requires Xcode rather than the command line alone. ## The Pull Request Policy Is the Real Constraint Most open-source projects measure health by how many outside patches land. This one inverts that. The README says the repository does not accept pull requests, and frames the published code as a resource for other people's projects rather than a shared codebase. Issue reports of all kinds are welcome, so bugs and feature requests do have a channel, but code contributions do not. For a forker this is actually clean: there is no expectation that your changes flow back, and recommended-changes.md exists precisely to help you diverge. For a contributor it is a dead end. You can file an issue, and you can fork, but you cannot get a patch merged here. Anyone evaluating the repository as a place to build a contribution history should understand that before spending a weekend on a fix. ## Where the Codebase Stops Being the Right Tool The platform story has a hard boundary. The README says the game currently compiles for Android, iOS and desktop, and that is the full list. There is no web build, no server component and no headless mode described. If your goal is a browser-playable roguelike or a game that runs in a CI pipeline without a display, this codebase does not offer that path, and adapting a LibGDX desktop target to the web is a project in itself rather than a configuration change. Licensing is the second boundary, and it is a real one. The project is GPL-3.0. If you fork it and distribute your version, the GPL applies to what you distribute. The README does not walk through the consequences of that, and it would be a mistake to treat a source-available game repository as a permissive template. If your plan requires shipping a closed-source derivative, this is the wrong starting point, and no amount of renaming assets changes that. ## Pixel Dungeon and Other Roguelike Codebases as Alternatives The obvious alternative is the upstream it came from. The README links to Watabou's Pixel Dungeon source at 00-Evan/pixel-dungeon-gradle, which is the base Shattered was built on. The difference in approach is one of scope and upkeep: upstream is the original codebase, while Shattered is a long-running derivative with its own release cadence, its own storefronts and a documented set of recommended changes for people making their own version. If you want the lineage rather than the derivative, start upstream. If what you actually want is a roguelike engine rather than a finished game to fork, neither repository is that. Both are complete games with their own content, balance and UI decisions baked into core/. Stripping that out to build something unrelated is more work than starting from a general-purpose engine, and the docs here are written for people compiling and reskinning this game, not for people building a different one on top of its internals. ## Release Cadence, Licence and What a Fork Owes The release history is steady rather than constant. v4.0.0 was tagged on 2026-09-09, v3.3.8 on 2026-03-23, and v3.2.5 on 2025-09-30. The last push to the default branch was on 2026-09-09, the same day as the v4.0.0 tag, so the repository is not archived and the code is being updated. Upgrading a fork means tracking those tags, and the gaps between them are measured in months, which gives you room to plan but also means a fork drifts if you stop pulling. The licence is GPL-3.0, and LICENSE.txt sits at the top level. The practical implication for a fork is that the GPL travels with the code you distribute. The repository does not spell out the obligations in the README, and this is not legal advice: if you intend to publish a modified build, read LICENSE.txt and get your own answer about what your distribution triggers. The translation project is hosted on Transifex, linked from the README, which matters if you fork and want to keep localizations current. The README also links an official blog at ShatteredPixel.com and a Patreon for support; neither affects what you can do with the code, but they are where project news is published. ## Conclusion Adopt the repository if you want a complete, GPL-3.0 LibGDX roguelike codebase to read, fork or ship a modified version of, and read docs/recommended-changes.md before you rename anything. Do not adopt it if you want to contribute patches upstream: the README states the repository does not accept pull requests, and issue reports are the only channel it welcomes. Before you build, verify that your Android SDK, Xcode or desktop JDK setup matches the guide you picked, because the three platform documents describe different toolchains and the README does not promise they stay in sync. ## FAQ ### Is Shattered Pixel Dungeon the same as Pixel Dungeon? No. Shattered Pixel Dungeon is based on the source code of Pixel Dungeon by Watabou, and the README links that original repository separately. Shattered is a derivative with its own releases and storefronts. ### Is Shattered Pixel Dungeon turn-based? The README describes it as a traditional roguelike dungeon crawler with randomized levels and enemies and hundreds of items. Traditional roguelikes are turn-based, and nothing in the README describes a real-time mode. ### How do I download Shattered Pixel Dungeon? The README lists official releases on Google Play, the App Store, Steam, GOG, itch.io and GitHub Releases. The source itself compiles for Android, iOS and desktop. ### How do I play Shattered Pixel Dungeon? Official releases are available on Google Play, the App Store, Steam, GOG and itch.io, so the game can be played without building it. Building from source is a separate path described in the docs/ guides. ### How do I update Shattered Pixel Dungeon? The README points to official releases on the app stores, Steam, GOG, itch.io and GitHub Releases, which is where new versions such as v4.0.0 are published. The README does not describe an in-game updater. ## Sources - [00-Evan/shattered-pixel-dungeon on GitHub](https://github.com/00-Evan/shattered-pixel-dungeon) - [License: GPL-3.0](https://github.com/00-Evan/shattered-pixel-dungeon/blob/master/LICENSE) - [Project website](https://shatteredpixel.com/shatteredpd/) - [README](https://github.com/00-Evan/shattered-pixel-dungeon/blob/master/README.md) - [Releases](https://github.com/00-Evan/shattered-pixel-dungeon/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/00-evan-shattered-pixel-dungeon