Requirements analysis and writing lays the foundation for building a good piece of software. The requirements defined for a program form the outline on which the rest of the project can be built. It’s usually a cooperative and ongoing process involving many conversations between the developers and intended users. Requirements documentation can take different forms depending on the intended audience and use.

While the requirements for this project are demonstrated through the original Rogue game, it is still important to review the expected performance of the new game. This gives a general idea of how the application will need to be organized in order to perform as needed while staying maintainable and open to later expansion. This chapter finishes by looking at some of the most basic features of the original console game from 1980 and how they’ll translate into a modern Windows application.

This post is part of a series on creating a roguelike game in C#. For the latest chapters and more information, please visit the Official Project Page on ComeauSoftware.com. The current code for this project is also available on Github.

Introduction

One of the most important tasks in software development is defining the software requirements – in detail. Architects have blueprints, writers develop outlines and smart programmers get an idea of what the finished program is supposed to look like before they start programming. It might be a basic version of the program that handles only basic functions and the requirements might change during development but they still work out the requirements up front. This prevents misunderstandings and other problems that can crop up.

Requirements analysis is often done through conversations and meetings with the customer. The customer can be an outside company or people from other departments within the same company. This can take weeks or more, especially if the software needs to work with other systems or if the people involved realize that some of the requirements need to be changed in order for the software to be usable or even safe. Once the requirements are complete, they’re often documented in different ways for use by the programmer and others in the process.

A Closer Look at Rogue

For this project, the requirements are actually demonstrated through two MS-DOS versions of Rogue – a public domain version released in 1984 and the commercial version released by Epyx, Inc. in 1985. The Epyx version is still available and playable through Steam for a small fee. Another online version was created by Donnie Russell II, an independent programmer, and is still available. The versions are mostly the same except for minor differences in graphics and names. You can also view playthroughs like this one on YouTube.

Before we start developing our own roguelike game, we still need to look at the existing game and put together an outline of its rules and gameplay in order to make one that’s similar. This is sometimes called reverse engineering – analyzing a finished product in order to create a new version. Reverse engineering is sometimes explicitly prohibited in software user agreements but, since there is no user agreement for this public domain game and with the large number of roguelike games that have been created over the years, it’s not an issue.

In these requirements and throughout the course, I’ll compare the original game operation to the requirements for the version we’ll be developing. Some of the notes on the operation involve background calculations that can’t really be deduced from playing the game. These come from invaluable analysis provided by StrategyWiki.org and George Sicherman.

The full requirements for this game are extensive so, for now, we’ll just start out with the most basic game elements – creating the dungeon environment and maintaining a character that can move around within it.

The Requirements Process

There are different types of requirements documents depending on who writes them and their intended use. Business requirements describe what the software needs to do, what business rules need to be applied and, possibly, parts of the user experience. These are often the first requirements written and can be created by the customer with the help of business analysts or tech writers.

Technical requirements focus on how the software will satisfy the business requirements and go into more detail about programming decisions and system resources to be used such as network requirements and databases. Different companies and teams will use different types of documentation depending on their needs. The requirements shown in this series are very informal and are meant to give a general idea of the kind of questions that should be asked.

As you might guess, requirements analysis can be a back and forth process as everyone, including the programmers, discovers new questions to be answered and this process should be encouraged. The questions and answers in the requirements below demonstrate some of that process. As we get further into development, you’ll see other types of documentation, including flow charts and examples of how the game should handle specific conditions, referred to as use cases.

These requirements will give us plenty to work with for now. They actually cover some of the most challenging aspects such as map generation. By the time these requirements are satisfied, the game should include 52 dungeon levels (26 down, 25 back up and one victory level or Level 0). The player should be able to explore all the rooms on each level and move all the way down to Level 26 and back up to Level 0 without any bugs such as isolated rooms, missing stairways, etc..

In this article, I’ll focus on the requirements for the mapping and graphics and look at the character requirements later. None of the monsters or items are defined at this point but we can scatter some gold here and there to make things more interesting and include the stairway on each level. In the following articles, we’ll explore how to turn these requirements into code while leaving the door open for additional features to be added later. The requirements below show the original operation, the resulting requirement for our clone and some screenshots from the original game to demonstrate various operations.

Initial Requirements

Original

There are 26 dungeon levels.  Each level is depicted from above as a set of up to nine square or rectangular rooms drawn with ASCII graphics.  Each room must have a minimum interior space of 2 x 3 spaces and be connected to at least one other room by a hallway the player can travel through. 

In later levels, the hallways themselves might get complex and form mazes with blind alleys, etc.. One room in the dungeon must have a stairway that will grant access to the next level.  There’s only one stairway per level.

Requirement

In order to maintain the look and feel of the original, this game will also use ASCII graphics in a Windows Forms application in C#.

The dungeon map will be procedurally generated and defined with any items already present, whether visible or not, when the player first enters a level.  The code will need to define the rooms and ensure that they are connected.  There are enough requirements for the game map to justify a separate C# class to handle its generation.

The original game divided the screen into a 3 x 3 invisible “grid” in order to place the rooms within the dungeon level and still allow some randomness to the generation of the rooms. The rooms in this version will be a minimum of 2 x 2 spaces inside and will be limited by the size of the grid region, allowing a couple spaces between them for hallways.

The map will need to be maintained and edited in memory and updated on screen as needed.

---

Question:  ‘Up to’ nine rooms?  Is there a minimum?

Answer:  At least six rooms per level to provide enough play space and game time.

---

Original

Rooms are usually not shown until the player reaches them and might not be shown entirely until the player explores them.  Room exits might be hidden until the player searches for them using the search key (S).

Requirement

Portions of the map will need to be invisible when required.  Rooms will need to be defined as fully visible on entrance (lighted) or discoverable as the player moves around them. The map class will need to maintain values for the actual character a specific location and the character that’s displayed.

Room exits must be defined upon entering the dungeon level but could be hidden so the program must be able to determine if the player is near a previously defined exit and provide a 1 in 5 chance of showing the exit each time the search key is pressed, if it’s not already shown. 

---

Question:  How often should the rooms be lighted vs. dark.

Answer:  The majority should be lighted.  Let’s try 75% lighted and see how it works.

Question:  Should we use the same ratio for visible exits vs. lighted rooms?  75%?

Answer:  Yes

---

Original

Each level has a staircase that the player can use to proceed down to the next level. Players cannot go “up” to a previous level unless they have the Amulet of Yendor. The staircase must be present on the level or the player cannot proceed in the game.

The Amulet of Yendor can be found on Level 26 of the dungeon. After retrieving the amulet, the player proceeds upward on staircases until they exit the dungeon.

Requirement

The program will need to select a space within one of the rooms for the staircase during the initial generation of the map. This should be done as early as possible as it’s a basic dungeon feature.

The player or a monster can sit on top of a staircase just as they can sit on an item so the same functionality is needed here. Nothing else should be placed on the staircase.

The program must place the Amulet somewhere on Level 26 and the staircase must go up instead of down after the player reaches that level.

---

Question: When the player goes back “up” through the levels, do the maps need to be the same as they were on the way down? Does the program need to store past maps?
Answer: No. Make them different for an extra player challenge. Maybe the character goes up on a different path.

Question: On the way back up, what happens after the player completes the first level and exits the dungeon?
Answer: We should probably have a “light of day” level congratulating the player. The original game also allowed them to “sell” their inventory items for gold to increase their score.

Question: So the items need to have a specific value in gold. Will that be needed at any other point in the game?
Answer: No, just at the end.

Question: Does the Amulet take up inventory space?
Answer: No.

---

Exploring Further

Even if you’ve never played Rogue or any roguelike games, you could probably come up with some questions and requirements of your own based on what you’ve read so far and from watching playthroughs on YouTube. You should also take some time to at least skim George Sicherman’s analysis of the game which is a deep dive into the mechanics and strategies of the early versions of Rogue.

Using the requirements in this chapter as an example, I recommend that you come up with a few requirements that you would expect for a game like Rogue or your own favorite game and maybe even some features that you would like to see in your own version.

Finally, check out the video below more more information on software requirements gathering.