Brogue CE: Building and Playing the Community Edition

What Brogue CE changes for roguelike players

Brogue CE addresses a specific problem in the original game project: continuing development of a minimalist, single-player roguelike after its original creator, Brian Walker. The repository describes Community Edition as a continuation rather than a separate game with a different central objective. The player still descends through a randomly generated dungeon, manages limited resources, encounters hostile creatures and traps, and attempts to retrieve the Amulet of Yendor from level 26.

The fork's stated goals are practical: fix bugs and crashes, add quality-of-life features and non-gameplay improvements, improve gameplay, ease development and maintenance, and provide a convenient base for forks and ports. That scope matters when choosing between the original Brogue and Brogue CE. The README does not provide a complete comparison, but it directs readers to CHANGELOG.md, the release history, and the Changes from original wiki page for the detailed differences.

This is not a game focused on cinematic presentation or real-time reflexes. Its appeal lies in decisions made from limited information: whether to explore a dangerous area, use a potion now, fight or avoid a creature, or trade time for safer equipment. The repository topics identify it as a dungeon game, roguelike, and Brogue project, while the primary implementation language is C.

The dungeon loop and C source architecture

Based on the repository layout, Brogue CE separates the game code from platform-specific code. The Makefile includes C sources from `src/brogue`, `src/variants`, and `src/platform`, with the default target producing `bin/brogue` on non-Windows systems. The game uses a C99-oriented compiler setup and includes headers from those three source areas.

The platform layer is selected through build variables. `TERMINAL=YES` adds `curses-platform.c` and `term.c`, defines `BROGUE_CURSES`, and links `ncurses`. `GRAPHICS=YES` adds `sdl2-platform.c` and `tiles.c`, defines `BROGUE_SDL`, obtains SDL compiler flags from `$(SDL_CONFIG)`, and links `SDL2_image`. `WEBBROGUE=YES` adds `web-platform.c` and defines `BROGUE_WBROGUE`. These switches indicate that the core game and its input or display platform are designed to be replaceable.

The README also documents graphical tiles that can be toggled with the `G` key. This suggests that the display can include graphical tiles without changing the underlying game rules. The repository does not, however, document the internal map generation algorithm, combat resolution, save format, or turn model in the listed files, so those mechanisms should not be inferred from the README alone.

Linux release packages and the first launch

For a first real use without compiling the project, the README gives operating-system-specific launch instructions. On Linux, download a release and run the `brogue` script from the same folder. SDL2 and SDL2_image must already be installed through the system package manager. The documented package names vary by distribution.

The package names are the first platform-specific prerequisite. Install the matching packages for the distribution in use. The README lists the Debian or Ubuntu names as:

libsdl2-2.0-0 libsdl2-image-2.0-0

For Fedora, the documented package names are:

SDL2 SDL2_image

For Arch, they are:

sdl2 sdl2_image

The README does not show the package-manager command for these dependencies, so the installation command is intentionally left unspecified. After the dependencies are present, start the downloaded Linux package with the script documented by the README:

./brogue

Run that command from the folder containing `brogue`. The first interactive check is the graphical tile toggle documented by the README. Pressing `G` toggles the included graphical tiles.

G

The README does not describe a required first save path, initial configuration file, or default display resolution. It does document that `brogue --help` lists supported command-line options. On Windows, output intended for the command prompt is available through `brogue-cmd.bat`, while the standard executable is `brogue.exe`.

Source builds and platform-specific constraints

Source distribution is supported, but the README deliberately points to `BUILD.md` for the complete procedure. The repository includes a `Makefile`, `config.mk`, platform directories, and a default `bin/brogue` target, so the project is not distributed as source alone. The visible Makefile supports Windows, OS/2, terminal, graphics, WebBrogue, RapidBrogue, macOS application, and debug-related build paths.

The core source build begins with the configuration file and Makefile. The repository Makefile includes these relevant lines:

include config.mk

sources := $(wildcard src/brogue/*.c) $(wildcard src/variants/*.c) $(addprefix src/platform/,main.c platformdependent.c null-platform.c)
.DEFAULT_GOAL := bin/brogue$(.exe)

This excerpt shows the default target and the main source groups, but it does not document every required `config.mk` setting. Those settings must be checked in `BUILD.md` before compiling.

The Makefile also shows that terminal builds are not merely a display preference. They compile the curses platform, define `BROGUE_CURSES`, and link `ncurses`; graphics builds compile the SDL2 platform, define `BROGUE_SDL`, and link `SDL2_image`; and WebBrogue builds compile `web-platform.c` and define `BROGUE_WBROGUE`. The exact configuration keys and dependency installation instructions are not included in the README, so a reader should not assume that every platform can be built with the same commands.

Maintenance, licensing, and fork decisions

Brogue CE is not archived. The last push was on 2026-10-11, and the repository records recent releases, including `v1.15.1` on 2026-02-12 and `v1.15` on 2026-02-09. The release history and `CHANGELOG.md` are therefore the first places to inspect for upgrade notes and behavioral changes. The repository does not provide a formal support window or compatibility policy, so version compatibility should be checked rather than assumed.

The project is licensed under AGPL-3.0, with the license text stored in `LICENSE.txt`. That matters for organizations considering a fork, a modified build, or a networked deployment, because the license may impose source-sharing conditions for covered use. This is a notice about the stated license, not legal advice. A downstream maintainer should read `LICENSE.txt` and assess the intended distribution and modification model.

Project direction uses a benevolent dictator model. The README says that tmewett is in charge, while contributors and testers participate through GitHub issues and a development Discord. The contribution guide describes ways to help. That governance model is useful to know when planning a fork, because it does not imply a voting-based release process.

Brogue CE versus maintaining a separate game variant

The closest alternative named by the repository is the original Brogue, rather than a different engine or a modern graphical roguelike. The practical difference is maintenance lineage. Brogue CE continues development with goals centered on bug fixes, usability, gameplay changes, and portability, while the README sends readers to its changelog for the exact feature-level differences. The original game's website and community resources also remain linked, but the README warns that the Brogue wiki may differ from CE.

Another alternative is maintaining an independent fork from scratch. Brogue CE explicitly aims to be a convenient base for forks and ports, which can reduce duplicated work for platforms that need a maintained source base. The trade-off is that a fork inherits CE's architecture, behavior, and license considerations. It also means that changes must be reconciled with CE's development direction rather than isolated indefinitely.

For a developer, the Makefile's platform switches are the main architectural distinction. A terminal build uses curses and `ncurses`, while a graphics build uses SDL2 and `SDL2_image`; WebBrogue has a separate platform source. For a player, the main decision is whether CE's community changes and release cadence suit the fork or port being planned.

Editorial conclusion

Brogue CE fits players who prefer a compact, keyboard-oriented roguelike and C developers who need a documented fork base. It is less suitable for people expecting a graphical action game, a large asset library, or a cross-platform build process beyond the release packages and BUILD.md. Verify the exact Linux dependencies, source build instructions in BUILD.md, and release-specific executable layout before adoption.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. tmewett/BrogueCE on GitHub