Senior Program Manager, GitHub Developer Relations. Open source hype man, AI whisperer, hackathon and game jam wrangler. I write && manage programs, support dev communities, and occasionally ship something.
I got nerd-sniped into the GitHub Copilot CLI Challenge and made a questionable decision: I turned my codebase into a roguelike dungeon.
It started with a simple prompt: Build a GitHub CLI extension in Go that takes the current repository and turns it into a playable roguelike dungeon, with dungeons generated with BSP [snip]. And then /yolo .
The result is GitHub Dungeons, a terminal game that generates a dungeon from your codebase. Rooms, corridors, and enemies, all built from your repo and rendered right in your terminal. You navigate with arrow keys, fight bugs, and hunt for the exit. Every repository produces a different map. Every commit reshapes the layout. And if your HP hits zero, you start over.
💡 Fun fact: /yolo (“you only live once”) is a Copilot CLI command (an alias for /allow-all). Fitting, since roguelikes are built around permadeath. You really do only get one life.
Roguelikes trace back to games like Rogue in the 1980s – terminal-based adventures where each run generated a new dungeon, and death meant starting over.
That combination of procedural generation, permadeath, and text-based interfaces (later formalized in things like the “Berlin Interpretation”) makes the genre feel surprisingly modern, and a perfect fit for the command line.
GitHub Dungeons leans into that tradition. It’s written in Go, which I don’t normally use, but working with Copilot meant I could focus on behavior instead of syntax.
Procedural generation (or “procgen” as the cool kids call it) is a way of creating content algorithmically instead of designing it by hand. In games, that usually means levels, maps, enemies, or items are generated at runtime using a set of rules plus a bit of randomness.
So instead of designing one dungeon, you design a system that generates many.
That’s what gives roguelikes their replayability:
In GitHub Dungeons, that system is tied to your repo. The layout is seeded by your latest commit, so the same code produces the same dungeon, and every change reshapes it.
At a high level, GitHub Dungeon layouts are generated using Binary Space Partitioning (BSP), seeded by your repository’s latest commit SHA (more on BSP in a bit). That means the same codebase produces a consistent layout, while still evolving as the code changes.
In practice:
It’s procedural generation—but tied directly to your codebase. That’s the idea.
The interesting part was actually building it.
Working with GitHub Copilot CLI meant describing behavior instead of writing everything from scratch. One command that made a big difference was /delegate. Instead of just generating code inline, /delegate hands the task off to GitHub’s Copilot coding agent running in the cloud.
I could describe what I wanted in plain English, kick it off, and then go do something else while it worked independently. When it finished, it opened a pull request with the results.
For example,/delegate Make each level progressively harder e.g. on level 2 there are extra baddies, but more health potions
Copilot generated a solid first pass asynchronously, and I reviewed and tweaked the PR from there until the balance felt right. I took the same approach to other features like adding cheat codes that make the player invincible (because why not).
I even had Copilot generate a “dungeon scribe” agent, a small helper that added documentation and ASCII art diagrams to explain how dungeons were generated, which felt very on-brand for a terminal roguelike.
I even had Copilot generate a dungeon scribe agent to create documentation and explain how dungeons were generated with ASCII art diagrams, which felt very on-brand for a terminal roguelike.
Using Copilot (especially with
Lee Reilly, Dungeon Master/delegate) is like having an army of NPCs available to do whatever I want them to do.
Working this way (describing features, delegating them to Copilot, and reviewing the resulting pull requests) meant I could spend less time on edge cases and boilerplate, and more time on the player experience, including adding easter eggs for players to discover. Iterating with Copilot let me stay in a game design mindset instead of constantly switching into implementation details. Because Copilot was handling most of the build and scaffolding, I could stay in the flow of designing mechanics, testing ideas, and figuring out what actually made the game fun.
At the heart of each dungeon design is a technique called Binary Space Partitioning (BSP), which is a great thing to casually mention alongside middle-out compression if you want to impress your friends and colleagues. It sounds intimidating, but the idea is surprisingly simple: keep splitting a space into smaller chunks until you have a bunch of rooms you can connect.
Roguelikes need maps that feel:
BSP hits a sweet spot. It gives you:
Here’s how it works…
Everything begins as one big rectangle: your entire dungeon.
We split the space into two regions.
Then split those again.
And again.
Each split can be horizontal or vertical.
We keep splitting until regions are too small to fit a room.
That creates a bunch of “leaf” regions, the final building blocks.
Each leaf becomes a room, but not perfectly aligned. We randomize size and position slightly.
That slight randomness is what stops everything feeling too grid-like.
Now we connect rooms by walking back up the tree and linking siblings.
Each connection is an L-shape:
Put it all together and you get something like this:
What I like about BSP is that it feels designed, even though it isn’t.
It avoids the two big problems of procedural generation: pure randomness (messy), and rigid grids (predictable, boring). Instead, you get something in between… and sometimes beautiful.
If you want to see what your own codebase looks like as a dungeon, and you already have GitHub Copilot CLI installed, you can run:
gh extension install leereilly/gh-dungeons After that, run gh dungeons to transform your repository into a custom dungeon, ready to be conquered. Control your hero with WASD, arrow keys, or Vim keys.
Your goal is to find the hidden door and escape from (and attack!) enemies over five levels. I’ve added fun features like fog of war that limit visibility, auto-attack, ability to track stats like kills and conquered levels, and more that you’ll have to discover yourself.
If you’re feeling reckless, play it on crazy mode: you can set up a pre-commit hook that deletes your saved changes unless you beat the entire game.
⚠️ WARNING: Do not do this unless you fully understand what this will do to your repository, you’ll lose saved work and probably some sanity as well.
# Create the pre-commit hook
cat > .git/hooks/pre-commit << 'EOF'
#!/bin/bash
gh dungeons
if [ $? -ne 0 ]; then
echo "You died! Your changes have been stashed into oblivion..."
git stash && git stash drop stash@{0}
exit 1
fi
EOF
# Make it executable
chmod +x .git/hooks/pre-commit
# To be clear, you’ll lose all your uncommited changes if you enable this
# and fail to beat the dungeon, adventurer. (Editor’s note: Please, please, please do not do this. We are not responsible for any lost work. But Lee definitely is.)
This started as a throwaway experiment, but it changed how I think about GitHub Copilot CLI.
I was able to MVP it quickly, iterate on the parts that mattered, and let Copilot handle the heavy lifting, things like BSP generation and even monsters and movement defined in a slightly cursed YAML file of Yendor.
Senior Program Manager, GitHub Developer Relations. Open source hype man, AI whisperer, hackathon and game jam wrangler. I write && manage programs, support dev communities, and occasionally ship something.
Build what’s next on GitHub, the place for anyone from anywhere to build anything.
Catch up on the GitHub podcast, a show dedicated to the topics, trends, stories and culture in and around the open source developer community on GitHub.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
