GoRogue: a .NET Standard utility library for grid-based and roguelike games

What the library is, and the ambition in the description

GoRogue is described as a modern.NET Standard roguelike and 2D game utility library, offering algorithms for calculating field of view, pathfinding, generating maps, drawing lines, generating random numbers, creating messaging system architectures, and more.

The repository description adds the constraint that shapes everything else: the algorithms and data structures are pertinent to roguelike and 2D game developers, specifically designed to be minimally intrusive upon the developer's architecture.

That phrase is the design brief, and it explains the strongest feature in the list, the unobtrusive algorithms. GoRogue's algorithms are based upon a simple abstraction for input and output data, so that the library can integrate into many different existing systems and libraries without requiring duplication of data or merging of data structures.

This is the difference between a library and an engine. A game engine gives you its own object model, its own map representation, its own entity system, and you fit your game into them. A utility library like this one gives you the hard parts and leaves your classes alone, which is what you want in a codebase that already has an architecture, or that has to interoperate with an existing one, or that is not a roguelike at all but just a 2D grid game with line of sight.

The primary language is C#, the licence is MIT, and the default branch is master. The last push was on 2026-09-13. The release history is worth noting, because the most recent tagged versions are all pre-release: v3.0.0-beta09 from 2024-02-04, v3.0.0-beta08 from 2023-07-29 and v3.0.0-beta05 from 2023-05-18. So the 3.0 line is still in beta, and the readme refers to GoRogue 3.0 not being out of alpha yet.

The package is on NuGet.

The documentation website at roguelib.com with getting started instructions, tutorial articles and the API documentation, which also shows up in your IDE. There is a subreddit at r/GoRogueLib and a Discord server.

Primitives, and why the coordinate types live in another package

GoRogue is based upon the SadRogue.Primitives library, which provides primitive types for coordinates, rectangles, grids and more, and which also ships integration packages for other common libraries that define those types, such as MonoGame and SFML, allowing easy integration with those libraries' equivalent types.

The split is worth understanding rather than treating as an implementation detail. A coordinate type is one of the most consequential choices in a 2D library, because if your library's Point differs from your game's Point, then every algorithm call needs a conversion, and the conversions are where the bugs live. By keeping the primitives in a separate package with adapters for MonoGame and SFML, GoRogue can support several graphics libraries without any of them adopting a dependency on a graphics library.

The primitives package also provides functionality for operating on and working with grids, including determining locations in a radius, moving a position around on a grid, and calculating distance.

The math utilities are split the same way. GoRogue adds to the mathematical utility functions provided by TheSadRogue.Primitives with methods to wrap numbers around array indices, to round to the nearest multiple of a number, and to approximate certain trigonometric functions, and the readme notes these may be moved to TheSadRogue.Primitives before GoRogue 3.0 is out of alpha. The line algorithms, currently Bresenham's and a few others for determining lines on a grid, carry the same note.

So the direction of travel is clear: the primitives package grows to hold the general-purpose maths and geometry, and GoRogue keeps the game-specific systems.

One other primitive decision is the nullable reference types support. GoRogue is fully annotated to support the nullable reference type feature introduced in C# 8, and the readme is careful about what that means: it does not affect or break code that does not enable the feature, but for projects using it it provides more compile-time safety.

That dual compatibility is worth pausing on, because a library that only worked with nullable enabled would exclude a lot of existing projects. The annotation discipline gives the safety to projects that opt in without imposing a requirement on those that do not.

Field of view, pathfinding and sense maps

The three systems most roguelike games actually need are field of view, pathfinding and a way to model spreading things like sound or light.

Field of view is a versatile implementation of recursive shadowcasting, supporting both distance-restricted and angle-restricted cones. Recursive shadowcasting is the classic technique for computing what a character can see on a grid, and the angle restriction is what lets you have a cone of vision rather than a full circle.

Pathfinding is broader. There is an extremely performant A* pathfinding algorithm, an implementation of goal maps, also known as dijkstra maps, and a flee map implementation. Dijkstra maps are worth understanding because they are not a pathfinder in the usual sense: a Dijkstra map is a field of distances from a goal point computed across the whole map in one pass, which lets any number of units ask how far they are from that goal without running a search each time. A flee map is the same idea in reverse, for finding the safest escape route rather than the shortest path to a target.

So the library covers both questions a game asks, reach this point and get away from that point, with the second implemented as a precomputed field rather than a per-agent search.

Sense maps build on the same idea for other properties. The readme describes a framework for primitively modeling the spread of sound, light, heat and so on, using various algorithms. The word primitively is doing work: this is a base for building more specific propagation models rather than a finished noise system.

The random number generation is built on the Troschuetz.Random library, which provides generators using various methods for generating random numbers and sequences, with the capability to serialize those generators. GoRogue adds facilities for easily providing a custom generator to the functions that require one, along with some custom number generators that may be useful in debugging and unit testing.

That last part matters more than it sounds. Serializing the generator means a reproducible run, and the ability to inject a generator into every function that needs randomness means a test can make a dice roll deterministic without reaching into the library's internals.

Map generation, the GameFramework and the object model

GoRogue offers two levels of help with map generation, and the difference matters.

The quick ways are the generators that get you started, producing maps in common shapes. The class framework is the serious part: it makes it easy to design debuggable, distinct custom map generation steps and apply them in sequence to generate a final map. Each step is a distinct object that is usable in custom map generation as well as within the framework.

That step-based design is what makes map generation debuggable. A monolithic generator that produces a whole dungeon in one function is hard to test and harder to tweak; a pipeline where each step is separable can be inspected, swapped, and unit tested independently.

The other half is the GameFramework, described as a concrete system for map and object representation. Where the generic core algorithms work on whatever abstraction you give them, GameFramework provides a ready-to-use way to represent a map and objects on it, and integrates core GoRogue features such as field of view, pathing and the component system so that they work out of the box.

So the choice is between the two halves of the library. Use the generic algorithms with your own object model and GoRogue stays out of your way. Use GameFramework and you get a coherent map and object system with the algorithms already wired together, at the cost of adopting its representation.

The component system is what makes objects extensible in that framework. It implements a performant, type-safe component container structure that lets you attach instances of arbitrary classes to objects as components and retrieve them by type or tag. That is the standard answer to the problem of a game object that needs to carry a dozen different behaviours without a base class with a dozen fields.

Two more systems round out the object model. The factory framework provides an object-oriented implementation of the factory method pattern, defining blueprints and instantiating an object by its name. The message bus system is a simple, type-safe way to send messages across a bus where various systems subscribe and respond to messages of the appropriate type, which is how you decouple a UI event from the thing that reacts to it.

The effects system models effects with or without duration in a turn-based game, providing methods for dealing with effects with duration in arbitrary units, instant effects and infinite effects, plus a structure to group and automatically trigger effects that also supports effect cancellation.

Dice notation, spatial maps and where the library stops

Three smaller systems are worth naming, because each removes a piece of work that every roguelike needs and each is a candidate for being done badly by hand.

The dice notation parser takes complex dice expressions, simulates them using the random generators, and returns the results. A game with a loot system almost certainly wants something like 3d6+2 with modifiers and rerolls, and a parser for it is a small thing to write and an easy thing to get subtly wrong.

Spatial maps are an efficient way to store and layer objects positioned on a grid, which is the data structure question behind any game that has items on the floor. The disjoint set structure with path compression implements union-find, which is the right tool for tracking connected regions, and it is one of those structures where using the standard implementation is much better than writing your own.

The utility functions are described as miscellaneous helpers added as extension methods to various classes, and the first example given is selecting random items or indices out of lists.

Where the library stops is worth being concrete about, since the readme is generous in what it claims.

It is not a game engine. There is no rendering, no input handling, no audio and no scene management, and the GameFramework is a map and object representation rather than a runtime. If you need those, you need MonoGame, SFML or Unity alongside it.

It is not grid-agnostic either. The primitives are coordinates, rectangles and grids, and the algorithms operate on a grid. A game with a continuous world and no grid gets little from this library.

And the dice notation parser, while a pleasant inclusion, is not a rules engine. The factory framework instantiates objects by name; it does not interpret conditions, schedule turns, or resolve a game loop.

The repository layout reflects that this is a library with a real development process around it, not a single project directory. There is a GoRogue/ directory for the library itself, a GoRogue.UnitTests/ project, a GoRogue.PerformanceTests/ project, a GoRogue.Debugger/ project, a GoRogue.Docs/ project, a GoRogue.Profiler/ project and a GoRogue.Snippets/ project, alongside GoRogue.sln, a nuget/ directory for packaging and a changelog.md.

A separate performance test project and a profiler are the two entries that tell you what the maintainer considered worth measuring, and both point at the same claim the readme makes about the A* implementation being extremely performant.

Editorial conclusion

GoRogue fits a .NET developer building a grid-based 2D game who wants field of view, pathfinding and map generation already implemented and who wants to keep their own object model rather than adopt a framework's. It does not fit a project already committed to a full game engine, or a developer who wants a single screen with no grid at all, since the primitives are grid-centric. Before adopting it, check the release channel, because the newest tagged version is a 3.0.0 beta and the documentation site at roguelib.com is where the getting started instructions and API reference live.

Frequently asked questions

Official sources

1. Chris3606/GoRogue on GitHub
2. Issues
3. License: MIT
4. README
5. Releases