CMPUT 329
Lab #7
Type, Type, Revolution!
(2 Weeks, Pairs)
You may work in PAIRS for this lab.
In this lab you have the opportunity to make many of your own
design decisions. We recommend that you follow good design practices
and document such decisions both in your code and in the lab
report. You may want to add a special section to your report in order
to document your design decisions.
Background
Are you ready to start a revolution with your 1337 typing
skills? Although the final product of this lab may never attain
the incredible popularity of the arcade and playstation game "Dance, Dance,
Revolution" , it follows the same idea, and involves solving
design issues that have not been addressed in the previous
labs.
The original DDR game is quite simple: the player stands in a
central area, and "dances to the music" by pressing touch pads
to the front, back, left and right with his or her feet,
according to directions given on the screen (arrows that float
up the screen). The goal of the game is simply to push the
correct pads at the right time. If you get enough right, you
get to pick another song and continue, otherwise it will cost
you another dollar. This simple (and in some people's opinion,
silly) idea has become surprisingly popular (Try a google
search: in July, 2003, this generated 4,720,000 hits!) Like all
modern arcade games, DDR was implemented by a team of digital
systems and software designers. Maybe shortly you will be
designing and implementing the next arcade hit!
Lab
This exercise creates a simple game similar to DDR and builds on
the concepts introduced in Lab 4. Keyboard arrow keys replace
the footpads and the LED digits substitute for the arcade
screen. A sequence of "steps" are loaded into the RAM and are
subsequently displayed on the LEDs for a certain period of time.
The player must press the arrow key indicated before time runs
out and the next key is displayed. For simplicity, we will use
the last key pressed during the interval as the key to be
checked. The recommended interval for this game is 1/2
second.
The player starts with three lives and an incorrect key press
results in the player "losing a life." When the player has no
lives remaining, the game ends. At the end of the time period,
if the player is still alive, the game progresses to the next
"step" notwithstanding the last key pressed. For our game, the
player's goal is simply to play for as long as possible before
losing her/his "lives." The player loses one life for each
mistake. If the player reaches the end of the sequence, one
life is restored (to a maximum of three). Once the sequence is
complete, it starts over again. The number of lives the player
has willl be displayed on the bargraph LED. The number of bars
displayed should correspond to the number of lives
remaining.
RAM content specifications:
The RAM should contain a
sequence of ascii characters, from the set {U, D, L, R, E}. The
meaning of the letters are as follows (recommended display
characters (as in lab4) are in brackets):
- U: up arrow. (uP)
- D: down arrow. (dn)
- L: left arrow. (lF)
- R: right arrow. (rt)
- E: end and repeat. optionally, speed up (bonus). note
that an E in the middle of a sequence will in effect truncate the
sequence at that point. Depending on your design, you may need to
display something for the time slot when the E is read. In this case,
you might want to to display (ok).
Display specifications:
The displays must show the following information:
- Right XStend LED digit: When a key is required, the
letter name for that key (as specified above) should be
displayed. When the game is over (lives = 0), display some
indication (for example, the word "no"). Between instructions,
there should be a brief period during which nothing is displayed
on the LED. This will allow the player to know that the next
instruction is being displayed.
- Left XStend LED digit: While the player is still
alive, this LED shows the number of lives remaining (within
range 0 - 3 at all times.) When all the player's lives are used
up, this LED should show the number of sequences the player has
completed (up to 15, if you use hex digits.)
Functionality:
Glitch ATTENTION! You
need to use the arrow keys on the numeric keypad. The other
arrow keys generate a keepers event on release, as a consequence
you'll read in a "null" key!
(Note that partial marks may be awarded for partial functionality.
)
Required:
- Display number of lives remaining on left XStend LED. Lives
should not exceed 3, nor reduce below 0.
- Each incorrect key decreases number of lives by 1. The key
used for deciding correctness should be the last key typed
during the time interval. You may change the method of
determining which key to check, but you must document and
justify your change. The method proposed in this lab is not the
best, but it is probably the easiest to implement.
- Display the key sequence on the right XStend LED digit, as
read from RAM.
- Repeat the sequence when the ending "E" is encountered.
- Give 1 additional life (to a maximum of 3) for each
completed sequence (note, this is not "completed without error",
just completed).
- When the game is over (i.e., lives = 0), display the number
of completed sequences in the Left XStend LED.
- Reset with the reset button.
Bonus Functionality:
(Discretionary bonus marks may be given for other
significant improvements of the design.)
- Advanced Level: The sequence increases in
speed (by a noticeable amount) with each successive repeat.
- Master Level: The timing for each key in the
sequence is independent of each other, though still relative to
the "base" timing. You can accomplish this by inserting
additional symbols into the RAM. To create the required HEX
file, use the message generator from lab4. In this case, if
speedup on repeat is implemented, then the step time for each
key is a function of the base time (as in the original design)
and the new key time. Note: if you implement this
functionality, be sure to save your original (i.e. unit key
time) design as well (i.e. make this a separate
design).
Grading:
Resources:
[Return to CMPUT 329 Lab Home Page]