Crash Course to Roguelike Development

Written in 23. April 2007 by Paul Pekkarinen (


This article is not much about how to do a roguelike than what things you need to consider in roguelike development. Those things are like traps waiting for inexperienced developers to fall into them and slow down the development.

This article is written by an experienced roguelike programmer who made almost all mistakes there ever was, so if you want to be a smart one read this article carefully before proceeding to making a roguelike of your dreams.


1. Programming skills
2. The programming language
3. Class design
4. Programming tools
5. Platforms and portability
6. Burden of the past
7. Planning
8. Feature hog
9. Theory vs. practice
10. Teamwork
11. Psychological issues

1. Programming skills

Learning programming while making a roguelike can be a huge mistake, because the more-than-average amount of source code makes maintaining and re-writing really hard. I know some people want to start from roguelikes even they don't have a clue how to write code or anything like that. In that case I suggest making a 7DRL which is basically a simple roguelike. You can pretty much forget your dream project if you are not experienced in programming.

Learn programming FIRST. Learn it good. Learn all the good ways to write code and maintain projects. Forget any bad programming styles. You need to be consistent or the source code will explode right on your face. Making a roguelike is all about how good you are in programming, because it's the only way to make the dream game design to come true.

If you thought you were a good programmer a roguelike project will break that illusion quickly. Stop dreaming and admit the facts about your true skills as a programmer. Then begin to improve your skills. I know it's very hard for young people to admit they might be wrong about their views, whatever those are. I know I was so wrong about thinking (for example) that procedural programming style with C was the best thing ever. I stick to that thought for a very long time and it did hurt only myself. I couldn't win, because I was wrong.

2. The programming language

It's possible to write a roguelike using any programming language. Some people even prove that by using very exotic languages, but they really forget two important things: 1) How much does the language have resources to handle a large project and 2) How good the language is when maintaining a large project.

What is maintaining? It's something you will be doing most of time, because a large project usually needs re-factoring (making the source code better). Some people believe in entire re-writing from scratch, but I know it's possible (and desirable) to avoid that. Instead you will be re-factoring the source code to make it work.

You need a language designed for large projects. How simple is that? It's not that simple. People will believe to the language they are used to work with, even if it will suck in large projects. I can't really help them, they are beyond any help. They, like I did, need to figure it out.

You don't need to waste your time in that. Go for object-oriented language right away! OOP (Object Oriented Paradigm) was designed for large projects. One of the most common OO-languages, C++, was invented when it became clear that VERY large projects were HARD (in fact too hard, even impossible) to maintain in procedural C. The benefits of OOP has been proven many times and only true language-believers refuse to listen those facts. Using OOP doesn't have to be complex. In fact few simple mechanisms will do the trick: public interface (hiding the internal working of a class), inheritance and object instances only will emphasize the modularity of the project. If you never tried those in practice this might sound like an advertising talk. Try OOP for a while and see the difference! (No money back quarantee.)

Don't forget that the difference between paradigms is more obvious when the project becomes large. You can write a small project using pretty much any programming style and language. The difference between small and large projects is not just the size but the complex net of dependences. This true difference is something all roguelike programmers will face even they didn't know it existed. It's also the most common reason to stop making a roguelike. Many people will abandon the project when they meet this strange monster.

The language doesn't have to be C++, but C++ is not that bad either. It has problems with memory management (being non-automatic in that area) but it's also flexible and doesn't force to use OOP all the time (this can be bad or good).

The language is very important because all good and bad sides of the language will be magnified in a roguelike project. You can't see those problems if you have programmed only smaller projects.

3. Class design

Strict class hierarchy can produce large amount of "messages" (data) sent between classes in clumsy ways. Non-strict OOP languages like C++ allows to break the strict ownership and access classes from wider range which can be easier to do than build a complicated class hierarchy.

In general you should have an ownership for a class, but in some situations global instances are easier to handle and faster to access. This applies especially to "singletons" which are classes with only one instance.

The class design itself is a skill where you can only get better. Beginners tend to overuse inheritance and create a number of inflexible classes (which often causes the overuse of inheritance).

I have developed a set of basic rules when creating a class:

1. Give the class and its instances a clear, descriptive name
2. Give the class a single purpose (it can be wide or narrow purpose)
3. Try to make the class as flexible and general as possible
4. Try to make the class modular, not using any external code from elsewhere
5. Use private and public members, don't expose private members
6. Use inheritance when data-driven approach is failing

The sixth rule means that the differences between class instances can be also determined using data members. For example class Item can have a member called type, which determines the type of the item (sword, potion, scroll, etc.). In inheritance overuse class Sword would be derived from class Item which would create a lot of subclasses when all item types are derived from the base class.

Class is a fundamental building block of OOP so learn to make good classes. In best case you only need to make a class once and then re-use it over and over again without any modifications to that class.

4. Programming tools

I think it's very important to choose proper tools. Use the best tools you can find. Try new compilers and compare them. I made yet another mistake when I was stuck with DevC++. It's quite cool free developer tool, but it was slowing down the development because it has a slow compiler and very poor debugging tools.

When I changed to VisualC++ free edition it was like enlightenment. VC++ has much faster compiler and a great debugger which caught many fatal bugs not detected by DevC++. VC++ really increased my productivity. I was very surprised to see that I got more motivation just by changing to another developer tool.

Don't under-estimate the importance of proper tools. Download any updates you can find and bombard the tool developers for improvements.

5. Platforms and portability

Writing portable source code is something you need to be aware of when you start the project. Even if you don't plan the game to be multiplatform you can later change your mind.

The basic things are pretty obvious. The first one is the programming language. Some languages are more multiplatformed by the nature (like Java) than others. This is something you should consider when selecting your programming language, but it's not that important, because most platforms support all common programming languages.

Use multiplatform libraries and try to avoid compiler/platform -specific library functions. Standard solutions and libraries will make porting much easier, not just for you but anyone who wants to port the source code in case you release it.

Modularity also increases the portability when you put possible compiler/platform -specific stuff in a closed module or class. It can be then replaced with other type of solution.

6. Burden of the past

The major roguelikes seems often dictate the course of a new roguelike project. Some things just belong to the roguelike canon like ascii interface. While sticking to old school is cool it can replicate also the problems of major roguelikes.

Ascii itself is a crude thing, disabling any user interface inventions that were discovered with graphic display modes. People who don't like graphic tiles in roguelikes forget that Nethack has an option to use tiles and it doesn't make the game different. The fight of ascii vs. tiles is actually ridiculous, because it doesn't really matter which one you choose. Using tiles offers more freedom, because it's not restricted in certain amount of letters. Using ascii can be a good solution if your roguelike doesn't need graphics.

Game design is another issue where you see a lot of old inventions like using AD&D or some other tabletop role playing system. It's boring! Computers can do more than that! Creating original gameplay content is a hard task, maybe even harder than anything else in game development, but in the end it's much better than parroting old farts.

Don't let the past dictate everything you do. Roguelikes can and will be improved. Don't just copy everything you see. Always try to improve the user interface and gameplay, because it's the only way to make better games.

7. Planning

Planning is considered a helpful tool in development, but in roguelikes it can become a waste of time. Don't try to plan too much in the beginning, because those plans will change. You can become better in planning, too! Your planning skills improves when you get better in programming, because you know what is required to implement a plan.

What to plan? There are things which are independent from the actual source code level implementation. Things like the game world (where it is, what kind of places it has, what monsters you will meet etc.) and the general gameplay. I think it's very useful to plan the game world. You can even write fictional stories about the game world to help in development.

Whatever you do, don't try to plan the whole game before writing source code. It's not going to work for a roguelike project. However if you are very experienced programmer and you have experience in making plans it might just work barely.

I think planning works much better in specific areas of the project. You should plan things like the dungeon creation and monster AI. Also, you can plan any time during the project to re-factor some areas that need improvement.

8. Feature hog

Roguelikes consist mainly of things called features. About everything you see in a roguelike is a feature. Confusion, digging walls, casting spells, riding a pony... every single feature requires some effort to implement. Some features are easy, others are very hard and may require large scale re-factoring.

Features usually also affect to each other. This relationship between features is the dangerous thing about them. You need to avoid feature hog in your gameplay before you know how to actually implement features and how to make them work in all situations.

If you are smart you "start small". It means you add one feature and test it very carefully. Start from main features and add fancy features later. This is also important in the case of gameplay objects. It's very stupid to add 500+ items in the gameplay before they work properly, because editing that amount of item data can become a real nightmare. Smart people add only one type of item (sword, dagger, spear, potion, scroll, etc.) and test it in all possible situations. When everything works nicely it's much easier to add that 500+ items.

Let's think it this way. You have made 100 items. Then, in some point you realize you need an extra data variable for the items, like some flag or something. You need to edit all items and check for any special cases for that flag. It's 100 times more work! New requirements for objects can be hard to predict, this is why you should create a minimum amount of objects (and features) and test them to see if you need anything else. You can always add more items and features later when the basic testing is done.

9. Theory vs. practice

There are basically two main styles to creating a project. In the practical way you implement features of the game in fast pace, probably using very hacky code. This can be nice for the speed of development, but it tends to lead the source code towards a maintaining disaster. The source code begins to have lots of repeated code (code that does almost the same thing in many places) and it can become difficult to maintain.

In "theoretical" way the entire project is programmed and planned carefully before adding the actual game content. In this kind of approach you create a roguelike engine which can then handle complex data to create the content of the game. Also the engine is often heavily data-driven to minimize the amount of content-creating source code. Creating a roguelike engine can take a long time and during that time you don't see much happening. In worst case you can spend endless time tweaking the source code, if not perfecting it.

I believe the combination of these two is the best approach. You need to combine the firm engine-based and data-driven source code to fast paced creation of playable game content. Don't try to perfect the source code and also try to avoid too fast coding which leads to poor solutions that can require more re-factoring than well-planned source code.

10. Teamwork

Roguelike project requires a lot of work so it would be logical to form a development team. The change from solo development to teamwork can be difficult, but you might as well give it a try.

When you are in team you need to know what is your role and what you can and can't do. These things should be made clear when a team is formed. Usually it's best to have only one team leader who will decide what the game is all about. However sharing the creative work is also possible if the team has made rules which everyone accept.

Usually the biggest problem in team development is the commitment. People are willing to help, but they can also lose their interest easily. Try to keep them interested by telling how the project advances. Try to be friendly and charismatic leader who knows what he is doing. Stay in contact to team members, because it's your task to make them work for you.

When searching for team members you may notice that people seem to have more will than talent. They want to join the team because it sounds cool, even they don't have skills required in roguelike development. I call them "average people". Don't hire anyone just because they want to join. Check out their skills first so you won't be surprised by the dumbness of an average person. I know, it frightens me to realize that most people are average.

Teamwork works best in "real life" where you can actually meet the team members and talk about the game. Teamwork with internet people you don't know is most probably going to fail, but it really helps to have a decent project! No one wants to waste their time to make a crappy game. It's probably best to have a demo version of your game before trying to hire people, because it proves you can do more than just talk about your dream project.

11. Psychological issues

Roguelike programming is not for everyone. Don't start a project unless you absolutely love roguelikes. You are going to spend a lot of time with your project and the love may be lost forever. There is a also the developers dilemma: when you make games instead of just playing them you begin to see games different way. You may lose your interest in playing and become more and more just a developer.

Roguelikes are demanding and in the same time you don't get much back from your effort. You can try to make a commercial (shareware) roguelike, but it's just not cool and you can't expect it to become a best selling game. You don't even become a popular figure like commercial game developers and you don't get girls by making a roguelike (except that one lucky bastard). Even your closest friends may not understand the amount of work a roguelike takes and that can be very hard to live with. You can look like a complete fool with your funny looking game project.

The community of roguelike developers at is your safe haven. There you will meet people like you. We roguelike developers are the jedi knights of programmers. The task of making a roguelike is everlasting battle against the dark side of commercial games. Only knights with true devotion will last in that battle! Join us and together we will rule the galaxy!