|
|
|
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.
II.a. Motivation
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:
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 4x5 rectangle aligned on 25x17 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 25x17 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 25x17 grid of low resolution (4x5) objects. The Dos version of Rogue uses a 74x20 grid of ASCII characters, which are much higher resolution than my 4x5 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.
II.e. Standards
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.
III.a. Genesis Controller
The Genesis controller connections were straight forward and easy to find on other ECE476 students' websites. I specifically used the pinout from the Nova Strike video game by Kalim Moghul and Kevin Oh, but changed the connections to the MCU as follows:
Since I only use the "C" button in my game, I tied the mux line to Vcc and did not use the "B" button connection.
III.b. Video DAC
I successfully built and used the video DAC designed by Dr. Land for NTSC video generation. That circuit is shown below:
The circuit is simply an additive voltage divider where the sum of the video signal (0 or 1V) is added to the sync signal (0 or .3V) to form the TV output.
III.c. Case Work
Possibly the coolest thing about my video game is that it is actually portable and playable. It fits inside a Penguin Mints' tin and takes a 9V battery, a standard RCA video cable, and a Sega Genesis controller to get it going. I heavily modified the ECE476 prototype board using a dremel tool and some cutting attachments, drilled and cut holes in the tin for the video jack, switch, and the DB9 connector, and soldered a programming cable to the proto board. It all barely fit in the tin and takes a bit of pressure and care to get it closed, but its looks certainly make up for the effort!
IV.a. Details
The software is described in some detail in section II, but I will expand on a few topics here. Speed is critical in this video generation code, because there is a sync pattern generated every frame and if all computation is not finished by the end of the frame, there will be glitches at best. However, since my game is turn based, I had as much time as I wanted between moves. My general approach was to keep a counter running and increment it once each frame, in addition to getting a portion of the computation-intensive code executed. As the counter stepped forward, the code stepped through long if-else statements with the incrementing counter as an argument. As can be seen in the Appendix, this code eventually became sloppy and burdensome, but it was critical in performing slow operations like writing to and reading from the EEPROM.
IV.b. Software Pitfalls
One of the biggest hurdles I faced throughout this project was keeping my code organized. The nature of the AI,movement, combat, and logic resulted in some code repetition and a number of long blocks of conditional statements. It was frustrating because at times I realized that there were better ways to code some things, but between the time crunch and the complexity of the code, it became very difficult to make those improvements without restructuring the entire code. I found that simple updates to the gameplay often required code revisions in four or even sixteen places. Some of this could have been alleviated by using better coding conventions from the start, but it was hard to predict what I would need and what I would not need to code for the game at the beginning.
V.a. Usability and Safety
My Roguelike game is highly unlikely to cause epileptic seizure because it has very little flashing in the video code. However, users are advised to use caution if they are prone to such trauma. The game is usable by anyone with at least one hand or prosthetic limb and decent eyesight. Because it is turn-based, the user may have poor reflexes and still play the game successfully.
V.b. Functionality
The video code executes properly and is always completed within the allowable time period. The portability also turned out better than I expected, as I was able to fit the entire design in a tin (including a 9V battery and a programming cable). Battery drain is a major problem of the present design and can likely be traced to the fact that the voltage regulator available in lab is not a Low DropOut (LDO) type, and therefore draws more current than is desirable. I installed an LDO voltage regulator but it would not set up the appropriate rail voltage, possibly due to oscillation. I didn't have a chance to change the capacitors on the prototype board before I had to remove the VR (destroying it in the process) to install a regular one.
VI.a. Expectations
The outcome of this project exceeded my expectations. I was not sure I would be able to make a fun Roguelike game, nor was I sure I would be able to do the casework for the board. However, I succeeded in both of these tasks and ended up with a very playable, very portable game.
Unfortunately, there is always extra functionality to include and not enough time to include it. I hoped to get the LDO voltage regulator working in order to limit battery use; I wanted to code in the ability to have more than one monster in a room and possibly even have them traverse between rooms. I would have loved to implement a player inventory with different weapons and items, but that task was too extensive to complete in the remaining time before the deadline.
VI.b. Standards
The Dungeons of Doom conforms to the NTSC standard for non-interlaced video generation. The MCU tin may be plugged into any composite video input on a video capture card or a television.
VI.c. Intellectual Property
All information sources are cited throughout this paper. Rogue is public domain software from 1984; I used no other unreferenced code in my design. Although I don't believe that the Dungeons of Doom would be given a patent, I think there is opportunity for a much more advanced design in the same housing to sell as a cheap alternative to buying a video game system for children.
IEEE Code of Ethics
The following are excerpts from the IEEE Code of Ethics and short responses about how my project conforms to the Code.
1. to accept responsibility in making engineering decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment;
My device is safe for the general public and the minor risk of epileptic seizure as a result of using my product has been disclosed with a warning in this report.
3. to be honest and realistic in stating claims or estimates based on available data;
This report states only what my video game has accomplished and its shortcomings have been properly disclosed.
6. to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations;
Like all other students in ECE476, I went through a series of well-supervised lab exercises to prepare for this final project. The experience has improved my technical competence.
7. to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others;
My video game has been tested by critical third parties and all contributions to this project are cited in this report.
9. to avoid injuring others, their property, reputation, or employment by false or malicious action;
I have been respectful of other people in lab, in order to uphold safety and human dignity.
Project Costs
M2012S2A1W01 SPDT Switch - $4
Atmel ATMEGA32 MCU - $8
Populated prototype board - $5
Sega Genesis Controller - $4.50
Free Parts From Lab:
Video Jack
DB9 Connector
TOTAL COST:
$21.50
Schematics
C Code