Rogue C# – Going Back to the Requirements

Updated June 2, 2026

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 AndrewComeau.com. The current code for this project is also available on Github.

This chapter contains a list of the official requirements for this project and will be updated as needed

From the original explorer’s notes …

“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.”

Writing the Programming Requirements, February 18, 2023

Sometimes, the biggest challenge with a project is trying to get past the temptation to just start coding because it’s fun and requirements gathering can be tedious. That’s the part of software development people don’t talk about with all the hype around A.I.. An LLM is not going to gather your requirements for you or ask the really hard questions. When used correctly, it can give some great suggestions that you might not have thought of but It’s still up to the developer to ask the questions and communicate with the people who will use the software.

The explict requirements developed for this project were actually kind of sparse and focused mostly on the structure of the dungeon, its levels and rooms. There were more requirements from the original game that were filled in during later chapters but, coming back to the project, I want to get a more complete listing of the requirements for a roguelike that will guide us through the remainder of the project.

G.L. Sicherman’s Rogue’s Vade-Mecum (Latin for “Go with me”, loosely ‘companion’ or ‘guidebook’) is also still available online and provides an excellent amout of detail into the game and all its elements. It is the primary reference I use for such things as monster stats and inventory effects.

A Guide to the Dungeons of Doom was written by two of the creators of the game, Michael C. Toy and Kenneth C.R.C. Arnold and is available as a PDF.

---

(Requirements in red have not been completed as of the most recent update.)

The Project

This project involves the creation of a roguelike game closely based on the original Rogue RPG for the purpose of demonstrating the C# programming language. This version will be designed as a Windows Forms application to allow for more flexibility in UI design than the original console format.

Data saved by the application, including reference data, game scores and saved game sessions will be stored in a SQLite database to be packaged with the application.

The development process for the game will be documented online through ongoing articles on the ComeauSoftware.com website.

The Game

Rogue is a dungeon-crawler game in which a single player wanders through dungeon rooms, fighting monsters, collecting gold, food, weapons and other useful items and searching for the Amulet of Yendor which will permit the player to ascend back to the surface and complete the game.

The dungeon in the game consists of 26 levels, each with progressively difficult challenges. The game maintains stats on the player including hit points, strength, experience level and amount of gold collected. These are updated with each move.

The player moves around the map using the four directional keys or diagonally within a room using the number keys. In normal mode, each key press moves the player one space. A fast mode will enable the player to move continuously until an obstruction is reached.

(6/1/2026 – the original games allows diagonal movement but I didn’t implement this for simplicity sake. I want it although it might be some work.)

Each space moved by the player will initiate a turn which will be completed by subsequent movements from any monsters on the map and a recalculation of all statistics. Fast movement will consume multiple turns.

The game includes specific commands triggered by key presses. This includes commands to eat, drink potions, read scrolls, throw or drop items, etc..

The game will have an ending at which the player exits the dungeon and is able to exchange his or her items for gold or points.

Character death during the game is permanent and the player must start over from the beginning.

Progress may be saved in order to continue the game later but this ends the game session. When save files are loaded, they are deleted.

The game maintains a scoreboard of game sessions showing the player’s name, the gold collected and how the player died.

The Map

As with most roguelikes, this project presents the dungeon levels as maps that are viewed from above and drawn with basic graphics. This version uses ASCII graphics to depict walls and items within the room, including the player.

Each level map and its contents is procedurally and randomly generated when the player enters the level. This makes every game unique in its play. Maps are not stored and the maps presented on the player’s “ascent” to the surface can be different than the ones shown on the descent.

The map is plotted in a 25 x 80 grid. Each level map will consist of anywhere from six to nine rooms, laid out in a 3 x 3 arrangement and connected by hallways, also drawn at random. Each room must be connected to at least one other room and the map generator must not allow groups of rooms to be isolated from the rest of the map. Each room must be at least 2 x 3 grid spaces on the interior to allow for movement within. Maximum room size must allow for exterior hallways to run between the rooms.

Game messages are displayed at the top of the map and player stats are displayed at the bottom.

Maps are discoverable with only the player’s current room visible at the start of each level. Rooms may be “lighted” or fully visible on entry or “darkend” requiring exploration. Certain items, including room exits, may be hidden and require the player to search by holding down a key near them.

One room on the map must have a stairway that will allow access to the next level. Only one stairway should be placed on each map. The player can only descend through the dungeon levels until collecting the Amulet of Yendor which permits ascent. The player and monsters can sit on top of the staircase without using it. Nothing else should be placed on them and they are discoverable but not hidden.

The Player

The player will be asked for a name at the beginning of the game and will be provided with a basic inventory including food, armor and some basic weapons. The player’s inventory is limited to a specific number of items / slots. The player can add to this inventory by moving onto map spaces that contain items and can drop items to make room for more. Some items are stackable in slots and many are lost as they are used.

(6/1/2026 – The amount of inventory that can be held still needs to be worked out. Different versions of the game have handled this differently and sometimes inconsistently.)

The following statistics are maintained for the player:

• Hit points (maximum and remaining)
• Strength (maximum and remaining)
• Gold collected
• Rating of current armor
• Experience points and level

The experience level is calculated by the number of points on a geometric scale that can be used to increase the player’s abilities during the game. Each increase in experence level increases the player’s maximum hit points by a random number within a defined range.

The player must collect food during the game in order to eat and survive. Any food eaten will provide sustenance for a specific number of turns. At the end of that period, if more food is not consumed, the player will progress through states of hunger, weakness, fainting and then death which ends the game. Fainting spells prevent the player from moving for a number of turns while any monsters continue their turns, including attacks on the player.

Inventory

Some items such as scrolls, potions, staves / wands and rings will be identified with descriptions or code names until specifically identified by the player. Afterward, that specific item and any further instances of it will be renamed in the player’s inventory.

The following item categories may be found on the map.

• Food – Rations or pieces of fruit consumed by the player.
• Gold – Used to keep score in the game. The player can collect an unlimited amount and it does not take up space in inventory.
• Scrolls – These have various effects, mostly helpful, when read and are removed when used. Refered to by a code phrase until identified.
• Potions – When drank (“quaffed”), these items have their own effects – some good, some bad. Can be thrown as a weapon and may shatter for effect on a monster. Consumed when used. Marked by color until identified.
• Rings – A ring can be worn on each hand to provide various enhancements. These will often cause the player to require more food. Refered to by stone type until identified.
• Staves and Wands – Can be pointed, usually at a monster, to cast an effect. These have a limited number of uses, after which they become inert. Refered to by material until identified.
• Armor – May be worn by the player to provide protection from monsters. Armor must be removed before other armor can be worn. This involves separate commands. The player can go without armor and have an armor rating of 1.
• Amulet of Yendor – Allows the player to ascend out of the dungeon. This item does not consume space in inventory.

(6/1/2026 – The types of items available still needs to be expanded and it will be a long process. Each item type needs special coding.)

An inventory screen will show the items currently in the player’s posession. Items of the same type (e.g. scrolls or potions with the same effect) will be grouped into a single slot and a count of them will be shown.

The player can access different items with specific commands such as to read a scroll or zap using a wand or stave. A special inventory screen will enable the player to choose the item to be used.

Monsters

The game features 26 different types of monsters, each one represented on the map by a different letter of the alphabet.

Each monster type has its own attributes and statistics that are set when the monster is placed on the map.

• Initial hit points – Set randomly within a specific range.
• Armor class
• Experience reward – Experience points given to the player on defeating the monster.
• Min and max level – Map levels on which the monster can appear.
• Min and max attack – Range of hit points that can be taken from the player in each attack.
• Aggression level – Likelihood of monster attacking on sight or remaining passive until provoked.
• Appearance probability
• Special attack and likelihood of use

Different monsters can launch unique attacks such as freezing the player or rusting their armor.

A specific number of monsters are placed on the map when the level is created. Additional monsters can spawn based on the number of turns taken during that level.

Fights

Fights between the player and monsters in the game will encompass multiple turns. Each attack by a player will initiate a turn and be followed by a reciprocal attack from the monster.

The player will attack monsters using the movement keys (essentially colliding with them), by throwing objects or by zapping with wands and staves. When throwing or zapping, the game will ask for the specific item to be used and the direction of the attack.

The success of each attack and damage dealt will be procedurally calculated based on respective strength, armor and other statistics of the player and the monsters.

Monster on monster fights are a possible feature to be worked into the game, maybe in response to the use of a scroll or potion by the player.

(6/1/2026 – The fight mechanics still require a lot of testing.)

---

Changelog

May 21, 2026

See the article Better Graphics through the TextRenderer Class for a major improvement to the look of the game. The old method of throwing a string into a label control was removed and I used the TextRenderer class to draw the text. We have colors!