How to Design a Roguelike (On a Budget)
Over the spring break of my sophomore year of high school, I was obsessed with making my own roguelike game. I was in love with games like Binding of Isaac: Rebirth and Enter the Gungeon. It was my favorite singleplayer genre by far, and I decided that I would get to work on it right away. The problem was, I had no idea how to design a roguelike, much less program one. Now obviously, I was a high school student, not a professional, so I didn’t have access to the most expensive or high end equipment while making it. Therefore, I had to find cheap materials and tutorials that would help me get through the process. Through this article, I hope to share what I learned so that, if you’re interesting, you can take a shot at it.
The first thing to consider when designing your roguelike is your theme. Does your character fight the undead to infiltrate the layer of a zombie hivemind? Or will your character be fighting his way out of hell to reunite with his mother? Your theme is critical to how you will design your character’s abilities, weapons, upgrades, and foes. Don’t be afraid to go wild, however; a roguelike can fit almost any mold.
Now you want to start designing the aspects of your game. It’s important that you have certain principles in mind while designing roguelikes. The one word that should always remain in your mind is replayability. Well, it’s not really officially a word, but it describes exactly what your roguelike should entail. Every iteration or round of the game should be a totally new experience which keeps the player wanting to come back time and time again. The way to do this is by combining two other important aspects: randomness and progression. Your roguelike needs randomness so that the player can differentiate each attempt from the last and so it doesn’t become too repetitive. However, a player can even get bored of the total randomness if it doesn’t get any harder, or they can’t get any further. This is why your roguelike game also needs to implement a sense of progression. Give the player enough upgrades or challenges to keep them advancing. If you add enough depth to the game, roguelikes can be entertaining for hundreds of hours.
For instance, lets take a look at the recently released roguelike Hades. In this game, fight as Zagreus, the son of Hades, as he attempts to escape the wretched Underworld. However, he won’t make it out in one trip; there will be many deaths along the way. Since, canonically, Zagreus cannot fully die and will always return to the Underworld, this justifies the ability to replay
the story. Furthermore, there are four floors of the Underworld, each one with a different set of enemies and a new boss. Each floor has dozens of rooms, all with randomized enemies, rewards, and structures. With the randomness element covered, how does Hades approach progression? The driving factor of the progression is the incredibly deep lore. Each successful escape will give you a new insight into the lore of Olympus, while also learning more about your Olympian aunts and uncles. Another incentive for the player to continue playing is the game’s collectables. People often like to 100% roguelikes by obtaining every item, upgrade, weapon, etc., which is intended consequence of randomizing everything. The dream of chasing after the rarest of items and filling your pockets with everything possible is what keeps a lot of players hooked on roguelikes.
Now that we know how to approach designing a roguelike, let’s get into what we actually need to produce. There are aspects that your average roguelike should likely contain: rooms, floors, structures, enemies, weapons, bosses, upgrades, items, a health system, an inventory system, a hub world, NPCs. While these are all important in their own right, nothing is truly necessary. However, the more variants you have of each of these items, the more your game can be randomized.
Let’s look at this mathematically. I have two games. In the first game, the player has access to 500 different types of weapons, but every room and enemy type is the same. In the second game, I only have 50 weapons, but there are also 50 types of rooms, and 50 types of enemies. Now, which game will have more random outcomes? The first game will only have 500 different ways of playing, since nothing else about the game is really any different. However, the second idea will have a total of 50 x 50 x 50 = 125,000 different ways to play, and you made 70% less concepts and assets to get there. The lesson from this is to spread the wealth across different parts of your game; don’t bother focusing all of your energy into one aspect.
Once you’ve decided on what types of items will be in your game, you have to start working on creating unique concepts. Make enemies shoot tracking bullets at you. Have enemies that split in half after being killed. Add an item that gives you a small amount of health per kill at the cost of movement speed. Have an optional room that takes some of your health for a rare item. All of these idea have been in roguelikes before, but the point is to make your enemies and items unique from each other. If you have items or enemies that drastically change the gameplay, players will keep an eye out for them and try their best to run into them by playing over and over.
Once you’ve carefully planned out your game, it’s time to bring it to reality in an engine. When I first made my roguelike, I did it in plain Java, with no game engine, but I wouldn’t necessarily recommend doing so. However, if you were to do so, I would definitely recommend this playlist by RealTutsGML (https://www.youtube.com/watch?v=1gir2R7G9ws&list=PLWms45O3n--6TvZmtFHaCWRZwEqnz2MHa). I would recommend starting with a basic engine like Unity.
For creating assets, unless you’re an experienced game asset artist, I would recommend doing pixel graphics. While pixel graphics are definitely more difficult then they seem, pixel graphics definitely lend themselves toward the roguelike genre. If you were to use pixel graphics, I would use https://www.piskelapp.com/, a simple tool for creating basic tilesheets and animations. I would also recommend simple version control using GitHub if possible.
For the rest of the programming, I would say it’s up to whatever you’re comfortable with. If this information is helpful to you in any way while you make your roguelike game, thank you so much for reading, and best of luck in all your adventures of game design. Peace!
