# Rogue 5.4.4: the original dungeon crawler, archived and buildable

> Davidslv/rogue is a preservation archive of Rogue version 5.4.4, the game that defined the roguelike genre, kept as a C89 codebase with an autotools build, DOS and Windows support and a separate modern-rogue branch for changes. The README is careful about the distinction between the archive and the modernization work, and the build is a period-correct one rather than a modernised one.

**Davidslv/rogue** — Original Rogue Game (5.4.4)

- Repository: https://github.com/Davidslv/rogue
- Stars: 554 · Forks: 143
- Language: C
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/davidslv-rogue

## An archive with a policy, not a fork in progress

Rogue is the original graphical dungeon-crawling adventure game that spawned an entire genre, and this repository holds version 5.4.4, a classic roguelike where you explore procedurally generated dungeons, fight monsters, collect treasure, and attempt to retrieve the Amulet of Yendor. The original authors are given as Michael Toy, Ken Arnold, and Glenn Wichman, with the dates 1980 to 1983, 1985, and 1999.

What makes this repository different from the many Rogue forks is that it says plainly what it is for. The maintainer states that they are not one of the original authors, and that they are simply maintaining the repository as an archive of the original game. The intention when it was created in July 2016 was to archive the codebase for learning purposes.

The repository policy is a two-branch arrangement. The main branch will remain unchanged to preserve the game exactly as it was in 1999, so the original codebase stays available in its historical state, and modernization efforts, bug fixes and improvements are directed to a separate branch called modern-rogue. Forking is explicitly encouraged as an alternative route.

That policy is the reason to pick this repository over a fork. A fork of Rogue 5.4.4 is a starting point for a game; this one is a starting point for reading history. The last push to the repository was on 2026-05-14 and the only release is 5.4.4, dated 2016-07-23.

## What the source tree reveals about a 1999 codebase

The top level of the repository is one flat directory of C files, which is exactly what a 1980s and 1990s Unix program looks like before packages arrive.

The files map to the subsystems of the game in a readable way. move.c and chase.c handle movement and monster behaviour, fight.c the combat, monsters.c the monster catalogue, rooms.c and passages.c the level generation, new_level.c the level lifecycle. The items are split by type into armor.c, potions.c, rings.c, scrolls.c, sticks.c and weapons.c, with things.c holding the shared handling. io.c is the terminal input and output, command.c the command loop, options.c the configuration, list.c the inventory display, and save.c the save and restore. The two standouts for a modern reader are daemon.c and daemons.c, which implement the game's background daemons, and xcrypt.c, the crypt file encryption used for saved games.

The infrastructure is equally period. configure.ac and configure, with config.guess, config.sub, config.h.in, install-sh and Makefile.in, is a hand-maintained autotools setup. There is Makefile.std as a plain makefile for people who do not want to run configure, and the documentation templates in rogue.6.in, rogue.cat.in, rogue.doc.in, rogue.html.in and rogue.me.in, which is the troff documentation with a cat page, a man page, an HTML rendering and a plain text version.

There are also platform files that show how wide the original porting was. mdport.c and mach_dep.c are the machine-dependent layer, and there is a rogue54.sln and rogue54.vcproj for Visual Studio, a rogue.spec for RPM packaging, and a rogue.desktop file for a Linux desktop entry. The primary language of the repository is C.

## Building it, and which executable name you get

The quick start is three commands, and the configure step is conditional on whether the generated script is present.

```bash
# Configure and build
./configure
make

# Run the game
./rogue
```

The executable name note that follows is the detail worth reading. The name defaults to rogue, but may be different if configured with --with-program-name, and you should check the output of make to see the actual executable name. The README repeats the point later in a stronger form: the executable name and other build outputs are determined by the configure script, while a manual build with Makefile.std defaults to rogue54, so the two build methods produce differently named binaries.

If the configure script is missing, which the README says happens with a fresh git clone without generated files, the autoconf tools generate it first.

```bash
# Generate configure script (requires autoconf, automake, m4)
autoreconf -fiv

# Configure the build system
./configure

# Compile
make

# Optional: Install system-wide (requires root)
sudo make install
```

The prerequisites are a C compiler that is GCC or Clang and C89 or C90 compatible, make, and the ncurses library for terminal-based graphics. The make package differs by system, with gmake on FreeBSD where you can use gmake instead of make. Autotools, meaning autoconf, automake and m4, are only needed if the configure script is absent.

The compiler flags in the project confirm the era. The direct compilation fallback in the README is gcc -O2 -o rogue *.c -lcurses, and the fuller version adds defines for ALLSCORES, for a score file name and for a lock file name, which are the three compile-time switches the scoreboard mechanism needs.

## The configure options, and the wizard mode question

The configure script supports several options, and they are all in one block in the README.

```bash
# Enable wizard mode (debug/cheat mode)
./configure --enable-wizardmode

# Set custom scoreboard file location
./configure --enable-scorefile=/path/to/scoreboard.scr

# Disable scoreboard
./configure --enable-scorefile=no

# Set custom program name
./configure --with-program-name=myrogue

# Install as setgid (for shared scoreboard)
./configure --enable-setgid=games
```

The scoreboard is the interesting subsystem, and it explains most of these switches. Rogue keeps a persistent high score list, and the file is shared between users, which means the program has to create it with the right ownership, lock it so two players do not corrupt it at once, and update it atomically. The --enable-scorefile option chooses where the file lives, and no disables the feature entirely for anyone who wants a purely local game. The --enable-setgid=games option is the multi-user answer: the installed binary runs setgid to the games group, which lets a non-root user write to a scoreboard in a shared directory without giving that user write access to everything the games group owns.

The wizard mode is a debug and cheat mode, and its presence in a preserved 1999 codebase is a good sign about how the original was developed. It is not a cheat for the modern game, it is the author's testing aid.

The manual build path exists for people who would rather not run configure at all, and there are two routes. One uses the standard makefile, make -f Makefile.std, which creates rogue54 by default. The other compiles the sources directly, and the README warns that manual builds may require additional defines and that include paths may need adjusting if ncurses is in an unusual place.

## The scoreboard files and the compile-time switches

Two files in the repository explain the scoreboard mechanism more directly than the README does, and they are the reason a modern build often needs extra flags.

score.h and xcrypt.c together are the shared scoreboard implementation. xcrypt.c is the encryption applied to the score file, and score.h holds the definitions the rest of the game uses. The direct compile line in the README carries three defines for this subsystem, ALLSCORES to enable the shared high score list, SCOREFILE with the score file name and LOCKFILE with the lock file name. A build without those defines is a local-only game, which is exactly what the --enable-scorefile=no option produces.

That the shared scoreboard is a compile-time choice rather than a runtime one is characteristic of the period and of the portability goal. The same source compiles for DOS, for Cygwin, for Unix and for Windows, and on each of those the file locking and the ownership rules differ, so the project parameterised the mechanism at build time rather than implementing it four ways.

The consequence for a modern builder is the one the README flags. If you compile by hand and the scoreboard does not work, or the build fails on a missing symbol, the answer is usually that ALLSCORES or the file name defines are missing, and Makefile.std is the reference for the full list. There is also a configure option that handles it for you, which is the safer path if you do not need a specific executable name.

## Platforms, documentation tools, and the ncurses problem

The platform list in the README is longer than expected for a 1999 game. It supports Unix-like systems including Linux, macOS and FreeBSD, Windows through the Visual Studio project files or MinGW and MSYS2, DOS through DJGPP, and Cygwin.

The DOS and Windows support is the real find here, and it is not an accident that the visual studio files are named rogue54.sln and rogue54.vcproj, matching the manual build's default binary name. A DOS build through DJGPP is the closest thing to running the original game the way it was shipped, and the presence of the DOS tooling says the maintainers kept that path working.

The documentation is also buildable, which is unusual for a preserved codebase. The optional tools are groff and nroff, tbl, colcrt and sed, for generating man pages and docs. The README makes two points about the output. Documentation can be built later with make if those tools are available, and the generated documentation, meaning man pages and HTML, is adapted to match the actual codebase outcomes and build configuration, for example the executable name and the scoreboard file location. In other words, the docs are not a fixed 1999 text that contradicts what you just built.

The one build hazard the README names is ncurses compatibility, and it points at BUILD_ISSUES.md for known issues and workarounds. That is a file worth reading before starting, since ncurses has changed its API over the years and a 1999 C89 program can trip over a header that a modern library expects to be used differently. The ncurses installs listed per platform are libncurses5-dev on Debian and Ubuntu, ncurses-devel on RHEL, CentOS and Fedora, brew install ncurses on macOS, and pkg install ncurses on FreeBSD.

## Where this repository is the wrong choice

Three cases point elsewhere. The first is a player looking for a roguelike to play. This is version 5.4.4 with its original interface, and the project is a preservation archive rather than a maintained game. A modern roguelike, of which there are many on every platform, is a different experience entirely, and the fact that the main branch is frozen by policy means nothing here is going to change.

The second is a developer who wants to modernise the game. The modern-rogue branch exists for that, and the maintainer directs contributors there, so a fork of this repository is the wrong starting point for a serious port. A team that wants a maintained C roguelike with modern tooling should look for a project that has already done that work rather than starting from 1999 C89 and dealing with the compiler warnings, the ncurses changes and the missing unit tests on top of the porting itself.

The third is a project that just wants a roguelike engine. The source here is a game, not a library. It has no plugin interface, no save format documentation, and no separation between the dungeon generation and the presentation, so extracting the level generator for another project means untangling it from curses rendering and the combat code.

The alternative worth weighing is the original 1999 distribution itself, or one of the many maintained Rogue derivatives, and the difference in approach is what the fork exists to capture. This repository's value is that the code is unmodified, so a reader can see what the genre started from, which is a different goal from playing a good roguelike. For learning purposes the same project serves a third role, since a small C89 codebase with a clear file-per-subsystem layout is unusually pleasant to read, and that is the motivation the maintainer gives for having created the archive in the first place.

## Conclusion

Rogue 5.4.4 fits a developer who wants to read the code that started the genre, a teacher who needs a C89 codebase small enough to hold in one head, or a retro platform maintainer who needs a build that still compiles for DOS. It does not fit a player who wants a modern roguelike, because this is the 1999 code with its original interface, and it does not fit a team that wants a maintained game, because the main branch is frozen by policy. Before you build it, install ncurses and check the executable name, since configure defaults to rogue while a manual build with Makefile.std produces rogue54, and read BUILD_ISSUES.md if the compile fails on ncurses compatibility.

## FAQ

### What is the Davidslv/rogue repository?

It is a preservation archive of Rogue version 5.4.4, the original graphical dungeon-crawling game by Michael Toy, Ken Arnold and Glenn Wichman, kept as a C89 codebase. The maintainer is not one of the original authors and describes the repository as an archive of the original game.

### What is the difference between the main branch and modern-rogue?

The main branch stays unchanged so the game remains exactly as it was in 1999, and the modern-rogue branch is where modernization efforts, bug fixes and improvements are directed. The default branch of the repository is master, and the last push was on 2026-05-14.

### How do I build Rogue 5.4.4 from source?

Run ./configure and then make, and if the configure script is missing from a fresh clone, run autoreconf -fiv first. You need a C89 or C90 compatible GCC or Clang, make (gmake on FreeBSD) and the ncurses library, and a manual build without autotools is possible with make -f Makefile.std.

### Why is my Rogue executable called rogue54 instead of rogue?

The executable name depends on the build method. The configure script defaults to rogue, while a manual build with Makefile.std produces rogue54 by default, and the README advises checking the output of make to confirm the actual name. The name can also be set with the --with-program-name option.

### Which platforms does the Rogue source support?

The README lists Unix-like systems including Linux, macOS and FreeBSD, Windows through the Visual Studio project files or MinGW and MSYS2, DOS through DJGPP, and Cygwin. The repository ships rogue54.sln and rogue54.vcproj for Visual Studio alongside the autotools build.

## Sources

- [Davidslv/rogue on GitHub](https://github.com/Davidslv/rogue)
- [Issues](https://github.com/Davidslv/rogue/issues)
- [README](https://github.com/Davidslv/rogue/blob/master/README.md)
- [Releases](https://github.com/Davidslv/rogue/releases)

---

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