HyperRogue: a roguelike played on the hyperbolic plane

A world that grows because the geometry says it must

HyperRogue is a puzzle roguelike in the hyperbolic plane, written in C++ with SDL, and the geometric premise is the game rather than a setting.

The premise in the README is that the game dynamically generates new parts of the world as you move, and that because of the nature of the hyperbolic plane the chances of getting back to a place you have been before are very low, unless you go back exactly the same way. There is a blog post explaining the geometry used, and the README notes that very few games and works of art use hyperbolic geometry, the most well known being some of M.C. Escher's.

The play is straightforward enough to describe in a paragraph. You are a lone outsider in a strange, non-Euclidean world, moving with the numpad, the vi keys hjklyubn, or the mouse, and you can skip turns by pressing a period. As a Rogue your goal is to collect as many treasures as possible, and collecting attracts dangerous monsters, while killing the monsters allows more treasures to be generated.

The two rules that make it a puzzle rather than a grinder are worth calling out. You can kill most monsters by moving into them, and similarly, if a monster was next to you at the end of your turn it would kill you. And the game protects you from killing yourself accidentally, by ignoring moves that lead to instant death, which the README compares to the check rule from chess.

That last rule is a small piece of design generosity that changes how the game feels, and it is unusual enough that a player will notice it.

Sixty land types, orbs, and the road to Hell

The world is a combination of over 60 types of lands, and each land type has a specific style, meaning its own monsters, treasure, magical orbs and terrain features. The strategic consequence is stated plainly: collecting treasures only attracts more monsters in lands of the same type, so the correct play is to try to collect lots of treasure in several different lands.

That single rule turns the world into a routing problem. Greed in one land makes that land harder, so the interesting decision is when to move on, and the map is a set of land types with different economies rather than a set of rooms with different monsters.

Collecting enough treasure also lets you find rare magical orbs, which grant one-time or time-limited special abilities. Some lands are available from the beginning and others only if you have proven yourself, and the README says you can press Escape to find out what you should do to access more lands.

The endgame is named. Ultimately you will access Hell and look for the fabulous Orbs of Yendor, which are hidden there, and getting at least one of them proves you are a true winner. Only the best players face the challenges of Hell, and both the monsters and the challenges associated with the Orbs of Yendor are different from the rest of the game.

The release history shows a game still in active development. Versions 13.1m, 13.1n and 13.1o were published on 2026-08-01, 2026-08-02 and 2026-08-05, with the last push on 2026-09-17. The licence is GPL-2.0, and the README is explicit that it comes without any warranty.

RogueViz is the real project underneath

The most important thing to know about this repository is that the game is built on an engine that stands on its own.

HyperRogue uses RogueViz, described as the author's engine for non-Euclidean games, computations and visualizations. This repository includes the source code of the RogueViz demos in a subdirectory, but not the data, which is available on itch.io. RogueViz is funded by the National Science Centre in Poland, under grant UMO-2019/35/B/ST6/04456.

That funding detail matters. It means the engine is treated as research infrastructure with an institutional grant behind it, not as a side project of a hobbyist game, and it explains why the engine is separable from the game at all.

So the sensible way to approach this is in two steps. If you want to build non-Euclidean games, computations or visualisations, that is the engine, and it is the part with the wider audience. If you want to understand what a non-Euclidean world does to a game's design, HyperRogue is the worked example, and the world generation, the land types and the monster economy are all downstream of the geometry.

The game also shows what a roguelike can become when the map is not a grid. The euro, the world generator, the monster behaviour and the land types are each a separate source file at the top level, which is either a sign of a well organised project or of a large one, and the README's remark that the source code is not documented very well suggests the latter.

Building it, and the incremental build that catches people out

The build prerequisites are SDL and a handful of related libraries. On Linux with apt-get the README gives one command:

The list is make, g++, the SDL development packages for ttf, gfx and mixer, libglew-dev, libpng-dev and zlib1g-dev, installed in one apt-get command on Linux, and on macOS with Homebrew the equivalent is a brew install of sdl, sdl_ttf, sdl_gfx, sdl_mixer, glew and libpng. The Makefile has the same information in its header comments, plus the per-platform notes for macOS, MSYS2 and MinGW with the pacman commands, and for Ubuntu with the single libsdl-dev package.

Building from source is three lines:

git clone https://github.com/zenorogue/hyperrogue.git hyperrogue
cd hyperrogue
HYPERROGUE_USE_GLEW=1 HYPERROGUE_USE_PNG=1 make

The two environment variables turn on the GLEW and PNG support, and the Makefile header explains that you set HYPERROGUE_USE_GLEW if you want to build with GLEW and HYPERROGUE_USE_PNG to 0 if you do not want to use libpng.

Then there is the second build path, and it is the one that will save you an afternoon. The mymake program builds HyperRogue in parts. It takes longer than the method shown above, but it uses significantly less memory during compilation, and when you change something mymake will only recompile the changed file. The flags are the useful parameters, with -O3 for an optimized build, -rv to include the RogueViz demos, -vr to build the VR version, and compiler flags like -Werror to treat warnings as errors and -march=native also working:

make mymake && ./mymake -O3

The caveat is stated in the same paragraph and it is the kind that produces a confusing bug. mymake is not perfect and will not work correctly if the internal layout of structs has been changed, so if you pull a new version after a long time you should probably force a clean build by doing rm -f mymake_files first.

There is also a devmods directory and an addons mechanism, with mymake.cpp holding example invocations and devmods holding example addons, so the game is built to be extended.

What else the game does, and where it is not the right choice

The modifications section is where HyperRogue stops being one game. You can change the geometry and topology, to Euclidean, spherical, or even nonisotropic 3D geometries. You can play challenges based on various in-game quests, and you can try other game genres in non-Euclidean spaces, listed as a roguelite, also known as a shmup, and peaceful puzzles.

So the same engine that renders a hyperbolic plane can hold a shoot-em-up or a puzzle, and the geometry is a parameter rather than the game. That is the strongest argument for treating RogueViz as the real subject and HyperRogue as the demonstration.

The interface details are ordinary. You see tooltips by placing the mouse over things, and you can right click for more information about game objects. You press v to configure the game, you can rotate the world with the arrow keys, PageUp and PageDn rather than the numpad, and you can centre on the player by pressing Home. Your scores and game statistics are recorded to a file hyperrogue.log, which in Linux is in the home directory, and your configuration is saved to hyperrogue.ini, in the same place.

The reasons to skip it are the usual ones for a solo-developed game with a long history. The source code is not documented very well, and the Doxygen-generated documentation is the fallback, hosted on a GitHub Pages site. The code is a large flat set of source files at the top level, which is navigable if you know what you are looking for and hard if you do not. The interface is keyboard and mouse only, with no touch support, which is normal for the genre and its era but rules it out on a phone.

And the licensing shape is worth understanding before you build on it. It is GPL-2.0, so a derived work is GPL, which is fine for study and for a personal copy and is a constraint for anyone planning to incorporate the engine into a closed-source product. The alternative in that case is to read the geometry papers and the blog, and write your own engine, which is what the author would probably prefer anyway.

Editorial conclusion

Adopt HyperRogue if you want to read about and study non-Euclidean game geometry, because the same engine, RogueViz, is separately funded, documented and used for non-game work, and the game itself is a complete roguelike rather than a tech demo. Keep away if you want a modern commercial game, since the release line stopped at 13.1o in August 2026 with the last push on 2026-09-17, and the source code is described as not documented very well. Before you build it, install the SDL development packages, because the Makefile needs them, and read the mymake note, since a stale incremental build can silently produce a wrong binary after a long gap.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. zenorogue/hyperrogue on GitHub