Sixty top-level entries and a sixty-word README: inside Remixed Dungeon

Sixty top-level entries, sixty words of documentation

Start with the shape of the repository, because it explains everything else. The README is about sixty words: a one-line description of a classic roguelike with pixel graphics, a simple interface and extensive modding features, a statement that this is a fork of Famous Pixel Dungeon, and a note that it ships English, Russian and many more localizations. The rest is a row of badges and links, including a Bitrise build, a CodeFactor grade, a Discord invite, a DeepWiki entry, a Star History chart, and a credit for PVS-Studio, the static analyzer covering C, C++, C# and Java. Then the top-level listing runs to sixty entries. That ratio is the first fact worth holding: a mature, translated, widely distributed game whose public documentation is essentially a link list, with the actual decisions sitting in markdown files that nobody outside the project reads.

One Gradle build sits behind four application directories

The build tells you more about scope than the README does. There is a single Gradle build at the root, with build.gradle, gradle.properties, a gradle directory holding the wrapper, gradlew and gradlew.bat for Unix and Windows, and local.properties for machine-specific settings. bitrise.yml defines the continuous integration and the README carries a matching Bitrise badge. Beside that one build sit four sibling application directories that read as the same game at four targets: RemixedDungeon, RemixedDungeonDesktop, RemixedDungeonHeadless and RemixedDungeonHtml, with an index.html at the root as well. The headless target is the one worth pausing on, because it implies the game loop is expected to run with no screen attached, which is what a server-side or automated playtest would need. A file called TestEndpoints.java at the root looks like the seam for that. platform.md is the only other top-level file whose name suggests a cross-target policy document.

Beta 11 and beta 12 shipped twenty-nine minutes apart

Read the release numbers rather than the description, because they say what stage this project is at. The three most recent tags are 32.4.beta.11, 32.4.beta.12 and 32.4.beta.13. The first two were published on 2026-09-25, twenty-nine minutes apart, and the third on 2026-09-26 at 00:58 UTC. That is not a release cadence, it is a fix session: problems were found, numbered betas were cut, and each was tagged as it was verified. The scheme also puts the major at 32, which suggests the version line is counted continuously from upstream rather than restarted at the fork, so a Remixed Dungeon number and a Pixel Dungeon number live in one sequence. The default branch is master rather than main, and the last push to it was 2026-09-30, four days after the newest tag. Nothing is archived, and 85 forks with 8 open issues points to a project still being worked on, but treat any specific build as a beta.

Five plan documents describe ports that are not finished

Several top-level markdown files describe work in progress, and together they are the clearest window into what is actually being built. HTML_PORT_PLAN.md, LUAJ_TEAVM_PLAN.md, LUA_SANDBOX_IMPLEMENTATION.md, PET_INVENTORY_PLAN.md and PET_INVENTORY_TOOLBAR_PLAN.md sit next to the source. Read alongside a top-level entry called luaj and the modding tree, the first three describe running Lua through LuaJ on the TeaVM virtual machine and sandboxing it so the game can be scripted. The HTML port plan has an obvious counterpart already in the tree, since RemixedDungeonHtml and a root index.html both exist, so for that one the plan and at least part of the implementation are present at the same time. The two pet inventory documents show the pattern most plainly, one for the feature and one for its toolbar. For a maintainer, keeping five plans and their status honest is real work; for a reader, it is the most reliable way to separate what shipped from what is merely intended.

The modding claim is a directory tree and no format spec

The promise of extensive modding features is the README's, and the tree is where you can measure how far it is specified. Five directories do the work: modding, mods, data, entities and processor, the last of which in a Java project is ordinarily an annotation processor. Alongside them sit TiledMaps for map assets, an annotation directory, a json_clone directory, a docs directory, a GameServices directory and a HiFiDLC directory, plus a mob-viewer that by its name alone is a way to inspect the creatures the data describes. What is missing is any statement of the format. The README does not document the modding interface, the directory contract a mod has to satisfy, or a version field that would tell a mod which build it targets, so the cost of publishing a mod is invisible from the public documentation. The honest summary is that the surface looks broad and the specification looks thin.

The repository is configured for coding agents, not just for people

One pattern at the root is unusual for a Java game and worth naming directly. AGENTS.md, QWEN.md, TASK.md, a second entry called Task, REPO_MAP.md, COMPLETION_SUMMARY.md and DEBUGGING_INSTRUCTIONS.md all sit at the top level, and four hidden directories match specific tools: .devin, .opencode, .qwen and .refact, with .beads beside them. That means changes to this codebase are at least partly produced by automated agents, and that the maintainers keep their instructions in the repository rather than in a chat window. The cost is self-evident and matters to anyone forking it: a plan that has been acted on and a plan that has merely been written look identical from outside. Three feedback findings documents, BETA10_FEEDBACK_FINDINGS.md, BETA8_FEEDBACK_FINDINGS.md and MINION_FEEDBACK_BETA6_FEEDINGS.md, sit next to them as a record of what testers actually hit, which is the closest thing here to a changelog for player experience.

Three distribution channels and a wiki that needs its own upkeep

Distribution is the part this project has arranged most carefully, and it explains why the repository looks busier than a sixty-word game. The mobile build is on Google Play under the package id com.nyrds.pixeldungeon.ml, and the desktop build is on Snapcraft as remixed-pixel-dungeon. The wiki at wiki.nyrds.net is the declared homepage, and the community links run to Discord, a VK group, a YouTube channel and a Telegram group. Translation runs through a Transifex project, consistent with the English, Russian and many more localizations the README claims. The root carries WIKI_TRANSLATION_MAINTENANCE.md next to two text files and pick_random_wiki_pages.sh, which shows the wiki is treated as translated content needing its own maintenance rather than as documentation that updates itself. The licence is GPL-3.0 in LICENSE.txt. In practice an adopter inherits the game and a translation and wiki pipeline maintained by hand.

Editorial conclusion

Remixed Dungeon fits a player who wants a classic turn-based roguelike on Android or Linux with mods and a maintained wiki, and who is comfortable tracking a beta-tagged build. It does not fit a modder who needs a documented format, because the public documentation stops at the word mods, and it does not fit a developer who needs a stable release cadence, since the newest three tags shipped within a day of each other. Before you build on it, read REPO_MAP.md and the plan files rather than the README, confirm which of the four application directories your target needs, and decide how much of the wiki and translation upkeep you are inheriting, because that pipeline is maintained by hand rather than by the build.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes