How to Make a Roguelike

I’ve always wanted to put together a comprehensive primer on how to make a roguelike, something that could hopefully be inspiring while including both general and specific advice. This year’s Roguelike Celebration seemed like the perfect opportunity to force myself to do that after having put it off for so long, so I gave a 30-minute talk on the subject.

I’ve got a fair bit of experience to draw from, having exclusively worked with the genre for the past seven years (Cogmind, Cogmind 7DRL, POLYBOT-7, REXPaint, X@COM), made it my full-time job for the past five, and over these years also helped build r/RoguelikeDev into the largest community of roguelike developers on the net.

The “How to Make a Roguelike” talk is available in video form below, but this article serves as a text version of that same talk for those who’d prefer a readable format, or to just take a closer look at the many images ;)

Intro

A couple years ago at the first Roguelike Celebration I did a talk about how I became a developer, but this time I wanted to talk about how anyone can go about making their own roguelike. It’s pretty common for roguelike players to at least dabble in development. We’re inspired by the games we play and want to make something better, something different, or just something of our own. My talk definitely isn’t a tutorial, it’s more about how to get started and general advice to help you along the way.

Making a roguelike can be pretty tough, not unlike journeying through a dungeon full of obstacles. In the diagram below, that’s you at the bottom starting out your journey. At the top is your target: a fun playable game.

It’s very easy for your path to end up like this, wildly developing in every which direction as you try to add every system you’re thinking of without a clear overall path:

Yes you might finish and barely reach your goal, but at what cost? Maybe years of wasted effort and all of your hair :P. On the way it’s more likely you’ll develop yourself into too many difficult corners then get stuck, demoralized, and quit.

What you need to do is make a beeline for your target. With a basic plan and understanding of where to go, you can start with strong fundamentals and then, when you have that fun core game, expand on it all you want!

In this article I’ll mostly be covering the fundamentals, how to travel through this dungeon with a greater chance of success, especially when you’re just starting out and full of enthusiasm, but also aren’t sure how to proceed.

General table of contents:

• Language
• Scope
• Core Mechanics
• 7DRL
• Resources
• Hooks
• Tips

Note that although this is an intro on how to start making a roguelike, it does not include how to stop making that roguelike. You’re on your own there ;)

Language

Let’s start by getting what is always the first and most common question out of the way: What language to use.

The answer is easy: Anything.

The slightly longer answer is that it doesn’t really matter a whole lot. If you already have experience with some language then that’s great, go ahead and use it. Language is a means to an end, and people have used just about every language to create a roguelike before.

Now that’s not to say there aren’t some easier options if you’re just starting out, so if you’re not sure then I’ll help you with a suggestion:

Python is often recommended for first-time roguelike developers because it’s pretty simple and straightforward to work with. Just look at that code. There’s not a whole lot of weird syntax, and if you don’t even know programming or python you can probably still figure out most of what’s going on here.

But don’t worry about “simple” being a limiting factor, as you can still do great things with python.

 

There are literally hundreds of python roguelikes out there. All said you’ll have a smoother ride if you start with python, and we’ll come back to how to get started with it later on.

More complex languages like C and C++ are good in that they’ve been popular for ages, meaning you’ll find numerous relevant resources and references out there. C++ is what I use, but that’s only because I was familiar with it to begin with. I wouldn’t recommend it for beginners, especially if your goal is to make a roguelike rather than spend all your time debugging! You’ll find a lot of other devs using python anyway, so you’ll still have access to plenty of resources.

Scope

Another issue that comes up often among new developers is that of building your “dream roguelike.” Should that be your first goal? Almost certainly not!

At first you’ll be learning a lot, making mistakes you don’t even realize yet, so it’s best to build up some experience first. More importantly, the focus of game development really changes from beginning to end, so it’s best to go through the entire process at least once or twice before starting larger serious projects. Keeping your scope small at first is also the best way to ensure you’ll actually have a complete something to show for your efforts.

Taking our dev map from earlier, that main path is what you need to focus on:

It can be both a complete game and a stable foundation on which to build more. All those other areas out there to explore are tempting, but try not to get drawn too far away from the main path early on. It’s like playing a roguelike: If you start by blindly running around in the unknown doing only what you feel like doing rather than what you probably should be doing, unless the RNG is totally on your side you’re probably going to die out there somewhere. Repeatedly. Sure this can be a fun way to play around, but building a roguelike is a different story and a bigger investment of time, so try to stay focused.

The cool thing is you can build roguelikes piecemeal. They’re basically a conglomeration of systems that can be tacked on if you think they’ll support the main game.

After that you can just repeatedly expand and iterate, hopefully with player feedback.

In the end you’ve got so much stuff tacked on that you have no idea where the last ten years went xD

Looking at a roguelike project as a whole it can seem really daunting, but all you really need is a plan and perseverance. Starting small is important because you’re going to make mistakes, and you’re much more likely to fail if you aim big right away.

Core Mechanic

So what does a small roguelike really need? A core mechanic. This is where the experience starts. It should be explainable in a single sentence and this is what you want to prototype first. Go straight for the fun.

What’s the game’s unique take on rogueliking? If your game only has this mechanic, is it fun? If you’re thinking a little bigger, could this mechanic serve as a core for the rest of the game to sit on? Think about what the player is doing from minute-to-minute, which presumably has something to do with this core mechanic. If that repeated process isn’t fun, it’s not going to matter what you build on top of it!

So in this initial proto-game, only implement as many of the outer elements as necessary to bring out and test the core mechanic. Again, the above visualization and its branches may look daunting, but it’s just a sample of what’s possible. Roguelikes can be really simple and yet really fun.

To explore core mechanics a little bit more, let’s look at 7DRLs.

7DRL

A “7DRL” is a roguelike made in 7 days. Every March or so there’s an event where lots of devs make their own 7DRL, already going on 14 years now. It’s great because as long as you finish you’ll definitely get at least a few people to play it and leave feedback. Judges will also score them in different areas, though most everyone treats 7DRL like a personal challenge (it’s not supposed to be a competition).

Over a hundred new roguelikes come out of this event each year. It’s a lot of fun, and while I wouldn’t recommend doing a 7DRL as your first game (you don’t need that kind of pressure so early), it’s a good idea to participate once you have at least some experience and know what goes into a roguelike, especially the technical aspects, because having a deadline really does help.

7DRLs are great examples of “start small and expand as necessary after you’ve confirmed your core mechanic seems like a good idea.” So 7DRLs naturally make good prototypes, and many are experimental in nature. We see so many cool innovative ideas each year!

Let’s take a look at a few examples…

Knight is all about controlling your momentum. You’re mounted on a horse most of the time and that little blue block in the center or so is all you can move, only one space per turn, and that’s where you’ll end up next turn. So you can only accelerate, turn, and slow down so quickly, meaning you have to plan in order to line up your attacks on moving foes to behead them with your sword as you pass.

I love how this 7DRL has its core mechanic right in the name (download). You’re a ship in space, and although you automatically attack enemies within range, enemy-fired projectiles move more slowly, and you can see their projected path for the next turn and need to maneuver so that you can both continue attacking and avoid being hit.

In Seven Day Band you create your own roguelike as you play it. Wandering around you’re faced with new unknown enemies and objects, and have to set their names and abilities as you encounter them for the first time, or when they start to matter. (“Band” here refers to making an Angband-like of your own.)

In Broken Bottle you play an alcoholic in a post-apocalyptic world where alcohol consumption ties in to most of the experience, for better or worse depending on your choices. (It’s a pretty story-focused 7DRL.)

Drakefire Chasm has you playing a young dragon fighting caverns full of monsters, adventurers, and other dragons, but there are no items, just upgrading your dragon abilities and eating your foes in order to grow larger and advance. This one still gets occasional updates.

In Golden Krone Hotel you take advantage of the differing abilities of your vampire and human forms, including their interaction with dynamic light. This one eventually turned into a bigger commercial roguelike and has done pretty well on Steam since releasing a year ago.

Here’s my original Cogmind 7DRL, where you’re a robot building yourself from scratch using parts found and taken from other robots, with rampant item destruction so you’re forced to rebuild pretty often. Obviously this also became a much bigger commercial project later. I never expected my little 7DRL detour six years ago would turn into my job, but I’m really happy that I participated because that was perfect for proving the core mechanic was fun.

This year for 7DRL I did POLYBOT-7, which is kinda like Cogmind but plays extremely differently because there was a significant change to the core mechanic. Instead of the player choosing what items to attach, nearby items automatically fly over and attach themselves to you, and you can’t even remove them. The only way parts are removed is when they’re destroyed. I originally planned for it to be a kind of scaled-down Cogmind, but as 7DRL got closer I kept feeling like that wasn’t really a game worth making--it needed to be something with a truly unique hook to it, a completely new core mechanic. It turned out pretty fun, and also became a good reason to design numerous additional mechanics that would support this new type of experience (comparison here, and I also did a huge postmortem covering the process behind its development from beginning to end).

So while these games may have more than one system, it’s pretty clear where their core mechanic lies, and like many other 7DRLs they really stand out for it.

Non-7DRL Examples

While we’re at it let’s take a look at a few non-7DRL examples. These games took years to make, and certainly include a ton of systems and content, but you can still see how they revolve around their core mechanics.

There’s Mage Guild, which has the greatest alchemy system that let’s you mix any two items, be they potions, monster remains, or whatever, and get all kinds of interesting new items and effects.

In Demon you recruit a wide variety of autonomous follower demons and train them.

There’s The Ground Gives Way with its completely item-based progression.

Xenomarine is built around ranged combat and directional facing, not something you see in many roguelikes.

And one of the NetHack devs once told me NetHack’s core mechanic is “if it seems like it should be possible to do something, then you probably can.” (This almost seems like an anti-core mechanic and not the kind of example you want to follow as a new developer, but yeah :P)

Resources

One of the most important things you’ll need access to for roguelike development is information. That includes learning the basics, getting answers to questions, getting into more advanced topics later, or just food for thought.

Your specific pitfalls will be different from other devs, because everyone’s got a somewhat different skill set and personality, but you can use online resources and friends to overcome those obstacles. While you probably won’t have anyone actually working with you on your project, others can step in with advice when you need it. But you have to ask! It took me far too long to learn that, and my early progress was pretty slow because I never reached out to people. So I’m here to tell you, there’s tons of help just waiting out there!

Let’s look at some of the most useful resources…

r/RoguelikeDev

The RoguelikeDev subreddit is is the largest group of active roguelike developers in the universe. We’ve got a very welcoming and helpful community, and a well-organized sidebar pointing to a wide variety of useful resources.

Among those resources are tutorials in various languages and libraries, and we have members who’ve used them before and can help answer your questions.

Earlier I mentioned starting out with python, and the easiest way to do that is with the library known as “libtcod,” for which we have a tutorial (many, in fact).

Like most game libraries, libtcod handles basic features like your game window, mouse and keyboard support, bitmap fonts, and palette and color manipulation. But it also does a lot of the roguelike-specific heavy lifting, like map generation, FOV, and pathfinding.

Ultima Ratio Regum and Temple of Torment, two roguelikes I showed earlier, both started with the game they created using this tutorial, and eventually grew into their own things. libtcod is pretty great, and has been receiving updates for ten years now.

Another way to get started is to join the r/RoguelikeDev summer code-along event. It follows the libtcod tutorial alongside other developers, if you need the extra motivation and pacing handled for you.

We’ve done the tutorial for a couple years so far and interest has always been high. About 100 people participate each year. Technically you don’t even have to use libtcod or python to participate--many people use other languages and follow along with their own roguelike or similar tutorials.

At the end of two months you’ll have your own playable roguelike! Here are some of the games that came out of our event the past couple years:

It’s a really nice walkthrough you can tack onto--it basically gives you the required technical background for a functioning roguelike, then you do the part where you let your imagination run wild :D

Later on in your RoguelikeDev travels we have FAQs that cover different aspects of development in order to get you thinking about how to approach various topics. We’ve done a fair number of them :P

These include meta topics like planning and motivation, and details like common systems, design, all sorts of stuff! Over the years we’ve had quite a few devs contributing to these community FAQs, including many with well-known roguelikes.

Honestly we’ve got tons of developers hanging out in the subreddit in general, many with long-term hobby projects and who are knowledgeable and happy to help. We also have a Discord for real-time help and discussion. (We share the server with the r/Roguelikes subreddit, so you’ll also find lots of people playing and discussing all sorts of roguelikes in other channels.)

RogueBasin

Outside our subreddit, many years ago Santiago Zapata created this great website you may have heard of called RogueBasin. There you’ll find a whole section of development-focused articles.

There are quite a few articles (that list there is just the general table of contents!). Although a lot of the content is older, most of the articles are just as relevant today. This is actually where I got started years ago, and found the articles both inspiring and enlightening. (Also a little scary at first, but remember, roguelikes are developed piecemeal--take it one step at a time!)

Roguelike Radio

Darren Grey, Andrew Doull, Mark Johnson and others host the podcast Roguelike Radio.

Check out all those topics! They also include interviews with a wide range of roguelike devs. I’m even in two or three of them, including one where I say Cogmind might be done in 2016 or something like that. Hahahahaha… (The new year is 2019, but don’t hold me to that--more players keep finding it and I’m always adding new content and features because I can :D)

You’ll also see that a number of the podcasts cover the 7-day Roguelike Challenges, which are a pretty big thing in the community.

So we’ve got knowledge covered pretty well now, but another major consideration when it comes to game development in general is assets…

Assets

Here are our assets:

Seriously though, ASCII is wonderful in so many ways, and makes it so easy to add new content. With the right combinations of foreground and background colors you can create some really pretty games.

If familiar with roguelikes already you’ll probably recognize that as Brogue, but over the years I’ve collected a large number of inspiring ASCII screenshots, and want to share a selection of those here to give you an idea of the breadth of possibilities:

The variety is just amazing--there’s just so much room for unique styles!

When working with ASCII or ASCII-like monochrome tilesets you can also use my editor, REXPaint (and it integrates with libtcod--bonus!). For me it’s become a totally indispensable tool, and quite a few other roguelike devs rely on it now, too, for things like interface design, mapping, and art.

Tilesets

Of course, if you want more people to actually play your game (:P), or if it’ll help you get into your project, there are also some nice tilesets you can use, even if they’re just a placeholder. Many are free, or at least available at a reasonable price. You can find links to a bunch of tilesets in the r/RoguelikeDev sidebar.

For some people tilesets have the advantage of sparking your imagination, if you need that to help with development. That said, you may have seen some of these tiles in other roguelikes before, and that can be one of the drawbacks (the visual style not necessarily being uniquely associated with your project), but good-looking free/inexpensive art is invaluable for indie devs.

Good Starting Points

For this last segment I want to take a look at where to start your real design process, what you want to focus on. You might be satisfied with just moving a little @ across the screen smashing into letters, or you might want to go a bit further than that, and hope that others enjoy it as much as you do.

Of course you’ll want some kind of hook to get people interested in the first place, but this hook can take a number of forms…

We already talked about having a core mechanic, which is one of the easier hooks since it ties most directly into the gameplay itself, and roguelikes first and foremost are all about gameplay. All those permadeaths aren’t going to be worth it if there’s no replayability.

Amazing audiovisual features aren’t traditionally as common, although we’re seeing more roguelikes headed in that direction, which is great because it attracts even more players to the genre. So that’s a useful hook.

But the one I want to emphasize now is theme, which is an excellent hook, but not taken advantage of nearly enough.

Theme

We have lots and lots of fantasy dungeon crawlers, so naturally if you want to really distinguish your project, go for any unique theme that’s not a fantasy dungeon crawler.

Roguelikes are generally based on good/interesting gameplay, but having a unique theme not only makes the entire experience unique, it also gives you a source from which to readily draw brand new mechanics. (A unique theme almost forces you to take this route.) In particular, historical and mythological themes offer a huge range of established material to explore and expand upon. People also always seem to want more sci-fi roguelikes than what we already have, a relatively underexplored group of themes compared to how broad it is, and how much sci-fi content we see out there in other genres and mediums.

We’ve seen some really unique themes in recent years.

 

These are the kinds of themes that really turn heads, especially of course once they reach a fully playable state (both of the above are still in early development).

One that’s already a very complete game is Lone Spelunker, where you explore the natural and sometimes dangerous wonders of subterranean caves.

As for some other themes frequently asked about in the roguelike community which haven’t been satisfied yet, pirates come up pretty often. We did have one game pop up, Pirate Rogue, which is among the highest ever voted threads on the Roguelikes subreddit.

But Pirate Rogue was just a concept they were prototyping and the developer put it on hold since they realized their dream game was a bit beyond their experience level. The demand is clearly there, though.

Superheroes and cyberpunk are other themes that come up all the time. Someone do them.

There have been a lot of great stories coming out of the RoguelikeDev subreddit, just so many awesome projects in there, both new and long-term. But I wanted to share one in particular which I consider a pretty inspiring story, and that’s Armoured Commander.

You’re in control of a single WW2 tank, within which you lead multiple crew members in overland campaigns. Gregory Scott, the developer, started this project with only limited programming experience, and just went at it with the libtcod python tutorial.

One year later it was finished and featured in Rock, Paper, Shotgun.

That’s from no gamedev experience to a complete game featured in a top PC gaming opinion site in one year. Sure there’s luck involved in this sort of thing, but having a unique theme and sharing it around guarantees that more people are going to take notice.

So pick a unique theme and own it. This gets more people interested, and in turn that will help keep you motivated.

Remember that your game doesn’t have to be a strict roguelike. I’m going to be a little blasphemous here and say it’s not worth getting caught up in definitions. We often see people come up with a game idea they’d like to make, but then worry about whether or not everyone agrees it’s a roguelike. It doesn’t really matter, because there are as many definitions as there are players! As long as it’s internally consistent and follows your own plan, you’re all set. (But don’t worry, the Roguelikes subreddit will continue to bring you weekly arguments about whether or not something is a roguelike xD)

XRLs

Now to do a total 180. There’s another approach you can try which has its own advantages, the so-called “XRL.” These are based on existing IPs, and save you much of the planning and design effort that goes into making a game, as most of those questions will already be answered for you. At most you have to come up with how to adapt it to roguelike formulas. With an XRL you can focus on implementation and other fundamentals while you get your feet wet.

Lots of devs do this. A while back I made a list of examples on RogueBasin. All the roguelikes listed below are based on existing IPs.

Personally I think this is a good way to start out your early development efforts.

Perhaps the most famous XRL is DoomRL, officially now called just “DRL” after they were hit by a C&D from Zenimax for the name.

Aside: Note you do have to be careful of particularly litigious companies, like Nintendo, for example (I’d advise against doing an explicitly Pokemon roguelike!), but in general roguelikes are so niche and under the radar that XRLs are fine for hobby projects. Only those that gain significant notoriety would have to worry about this sort of thing, and by that point you can either rebrand it to your own content, or should probably have enough experience to be comfortable working on your own ideas from scratch. XRLs are usually short-term, small-scale learning projects, although a number of XRLs have been in development over multiple years. (In any case, definitely forget having any commercial aspirations with an existing IP!)

Today DoomRL developer Kornel Kisielewicz is busy working on the DoomRL successor Jupiter Hell, a prime example of using an XRL to grow a large fan base, and then relying on them to support an even larger commercial roguelike.

In his early years Kornel also made two other XRLs: AliensRL, one of the first roguelikes I ever played, and DiabloRL.

 

Prolific roguelike developer Slashie has made roguelikes based on Castlevania, Metroid, Zelda, Star Wars, Megaman, and probably like ten others he hasn’t told us about :P

Even my own first semi-roguelike project, XCOMRL, belongs in this category. Based on the original UFO Defense, it started from an IP with mechanics I was already really familiar with and love, which helped a lot.

From there I was able to branch out and add a lot of my own mechanics and content, doing experiments on top of an already solid foundation.

Another major advantage to XRLs is that you have instant fans, other people who enjoy both roguelikes and that same IP. This is great for motivation since you’ll always have people cheering you on. A number of my core supporters today are the same people who followed my early work on X@COM.

Tips for the Long Run

So some tips to help keep you in this for the long run…

Release Early and Often

“Release early and often” is the roguelike development mantra. It’s good to quickly get everything into a minimally playable state--again, build that prototype. Doing this will probably net you some good feedback, which is valuable for the long term.

Sharing Saturday

Even before your first release, even with just a concept, and long after that, try participating in our weekly sharing threads in the RoguelikeDev subreddit.

For some this is a way to stay accountable to yourself, and it’s a nice way to review what you have, or have not, been up to. You can literally post about how your week was hell at work and you barely got anything done, and in the process make friends with others in the same boat. Or you can talk about the cool new feature you added or are thinking about. Or share funny bugs. Anything, really! It’s a great community :D

Keep a Blog

Besides Sharing Saturday it’s also nice to concentrate all the info about your development in one place. A public place. Blogging actually has a bunch of advantages; here’s a list of some of the major ones:

• organize your thoughts
• examine your work from a different angle
• document the process
• create a useful long-term reference
• get feedback
• build a community

I’ve been doing this for a while myself and found it to be incredibly valuable. Below are the topics I’ve covered over the years on my blog:

You’ll probably find a fair bit of useful info just sitting there for the taking :)

Accessibility is Important

Accessibility is important. Traditionally this wasn’t the case with roguelikes, but nowadays you have an opportunity to reach so many more players if you’re willing to put in the effort. This means sufficient documentation, a tutorial, full mouse support, a tileset, etc.

To demonstrate how valuable mouse support and a tileset can be, check out these player stats from Cogmind:

Note that some accessibility features are important to consider in your design from the very beginning, but don’t worry about all this stuff in your first roguelike. Starting with an ASCII/keyboard-only game is just fine.

The Beginning

This is the end of my article, and the beginning of your great new roguelike.

Get to it :D