This project is a portable battery-powered video game based on the 1984 cult classic PC game “Rogue”.
I designed a hardware-based roguelike video game because I am a long-time Rogue addict and thought it would be cool to make a portable plug-and-play imitation. The project involved some basic hardware setup, including a Sega Genesis controller, an ECE476 prototype board, and an Atmel MEGA32 Microcontroller. The extensive software portion of the project created a similar game environment to the origial masterpiece, though it was necessary to design many differences from the original because of the nature of the NTSC signal generated by the MCU in contrast to the ASCII game environment of Rogue.
My desire to recreate Rogue stems from a childhood obsession with the original PC game by Michael C. Toy and Kenneth Arnold. Rogue is an 8-color ASCII-based game in which a player navigates a dungeon, fights monsters, finds and uses magical items, and collects gold. To gain an appreciation for the game, one should read the following:
Additionally, one may download the public domain MS DOS version of Rogue at Planet Mirror.
My interest in cramming electronics into breath mint tins began when I built a headphone amplifier that Chu Moy designed (popularized as the CMoy amp), which was commonly recreated in breath mint tins. The design of Dungeons of Doom combines these two passions. Details are available at the Tangentsoft DIY Audio Website.
II.b. Gameplay and Math
Like Rogue, Dungeons of Doom is a turn-based role-playing game. The object of the game is to collect as much gold as possible. The player has hit points, experience points, and an experience level. Killing monsters increases the player’s experience points, which leads to experience level increases, which in turn increase his maximum possible hit points and the rate at which they regenerate. By my design, players gain experience levels when they obtain experience points equal to the numbers in the Fibbonacci sequence starting with 10, 20, ie-10, 20, 30, 50, 80, 130,… Monsters have hit points as well, which are proportional to the dungeon level that the player is on. The player uses a Sega Genesis controller directional pad to move his character around a dungeon, and the “C” button to descend to the next dungeon level when standing on a staircase. At deeper dungeon levels, monsters have more hit points and have an increased chance of hitting the player, but killing the monster is worth more experience points to the player and the gold available on those levels is much greater than on earlier levels. There are four rooms on each level, each with two doors, one monster, one gold piece, and the possibility of a staircase (it will be in one of the four rooms). High scores are based solely on the amount of gold that a player collects during a game, and are stored in the EEPROM on the MEGA32 in order to preserve a running list of ten top players. Before the game begins, the user is asked to input his initials so that they can be linked to high scoring games on the high score list.
Screenshots from a game are shown in the following pictures:
Dungeons of Doom does not use any particularly difficult mathematic concept; however, some background on the coordinate system I used will help. The monsters, gold, and staircases that the user interacts with, and the user himself, are each effectively four “pixels” wide and five tall. In keeping true to the original game, I designed each object to be located in one 4×5 rectangle aligned on 25×17 grid. In other words, when you move right, you jump four pixels to the right; when you move down, you jump down five pixels. You may step on and off of staircases, collect gold by stepping on it, and attack monsters by moving towards a monster when already adjacent to it. Monsters, gold, stairs, and the player all have x and y coordinates that fall into the 25×17 grid and additionally have coordinates that these steps represent. For example, (x,y)=(4,4) refers to four steps to the right and four down from the upper left corner of the screen. These steps are four pixels wide and five tall, making the “real” coordinates (16,20).
In addition to the movement system, I used pseudo-random number generation to determine the outcome of combat, player skill advancement, and treasure placement. Pseudo-random numbers are created through a series of basic mathematical operations beginning with a “seed” value. Every time the sequence is generated with the same seed, it will be the same. I incremented a number every time the screen refreshed (every sixtieth of a second) and used that as a seed for my random number generation, knowing that it would produce reasonably random outcomes.
II.c. Logical Structure
The code used for the Roguelike game I designed is roughly based on Dr. Land’s AVR video generation code. Essentially the main function initializes variables, starts counters, then puts the MCU to sleep for video generation. Every time 230 lines have been generated, the program enters the code that I wrote. It has many flags that indicate to the program which action to perform; for example, generating random numbers for a monster attack, drawing the next room, updating the hit points, experience points, etc, and so on. Most of the time, button debouncing is also being performed on the Genesis controller. Almost all of the movement logic for the player is located in the debounce code, whereas the rest of the program is stored in main. This logic determines if a player is leaving a room and entering another, attacking a monster, moving around, or descending a staircase. I was concerned that all of this logic would be too much for the short period of time that I had complete the computation, but it proved to be fast enough.
II.d. Hardware/Software Tradeoffs
Having this video game programmed onto a microcontroller is advantageous because it can be taken anywhere and hooked up to a television and a Genesis controller and played over and over again. However, There are major tradeoffs in choosing the NTSC video format over the standard computer video format. As previously mentioned, the video generated by the MCU allowed me to create a 25×17 grid of low resolution (4×5) objects. The Dos version of Rogue uses a 74×20 grid of ASCII characters, which are much higher resolution than my 4×5 pixel objects. As a result, Rogue designers were able to create dungeon levels with up to six rooms and interconnecting hallways. My Roguelike game treats each screen as a room and the user enters another room by walking through the doorways located in two walls of each room. This is a major deviation from the original game, but it turned out to play well. An additional tradeoff of running the code off of an MCU is that it uses up the 9V batteries it requires. See the results section for more on that topic.
Dr. Land’s code, which is the foundation for this game, generates “an NTSC-rate, non-interlaced, video signal.” The National Television Systems Committee defines an NTSC signal to have a vertical and horizontal sync and a signal rate of 1/60 seconds. The signal I generate with the MCU consists of a sync and a video line hooked up to a DAC with output to a television.
II.f. Existing Patents
To the best of my knowledge, no one has built a hardware version of Rogue that outputs NTSC video before this. However, there are now Roguelike games even for cell phones! The Roguelike game Dweller is available for Sony Ericsson phones and can be played online at the roguelikedevelopment.org website. Although this game is portable and functionally stripped down from the original game, it is still vastly different than my game in that it uses ASCII characters rather than NTSC video.
M2012S2A1W01 SPDT Switch – $4
Atmel ATMEGA32 MCU – $8
Populated prototype board – $5
Sega Genesis Controller – $4.50
Free Parts From Lab: