Nowadays in the video gaming industry, one of the most popular categories of game is music and motion simulation game. There are games where players are required to play the drum according to the matching signals and the music of the game; there are games where players play the midi keyboard according to the matching signals on the screen. However, the game that motivated all these games is called Dance Dance Revolution produced by Konami in 1998. We are inspired by this game to build our very own Dance Dance Revolution for our ECE 476 final project.
The game can be divided into three major parts. First, songs, which are usually popular soundtrack, are played by the gaming machine. Second, on the game display, arrows are shown indicating which direction the player should step on. These arrows are shown on music beat to tell how the player should dance. Last, there is a dancing mat with four big arrows which the player steps in accordance with the matching arrow step pattern on the screen.
Our game design follows the above specification very closely. So now, may we present our very own Dance Dance Revolution.
High Level Design
Our game design is based on the Atmel Mega32 microcontroller. Since Mega32 has more memory than Mega163, we choose to use Mega32 with STK 500 board as our main programming board. The main game logic and game display are stored in Mega32. The audio part of our game is stored in Mega163 on STK 200 board.
We need to display the arrows on the screen to indicate which direction button the player should step on. In addition, the display is needed for other animation or motion display. From our lab experience, we can choose to implement the game display with either LCD or TV. Initially, we have decided to choose LCD, Seiko G321D, over TV because LCD display offers more pixel than TV, which allows us to draw more complex graphics and more details on the game screen. Also, LCD display allows us more time to do the calculation and other major function in the game without worrying about flickers on TV. However, we encountered some technical difficulties with the LCD available in the lab, so we have decided to switch to TV instead.
To achieve reasonable frame rate on TV, we need to complete all logic calculation and draw all graphics in 60 lines. Otherwise, the video will not be in sync and there will be jitters and flickers on screen. In addition, we cannot use interrupt to detect button pushed with TV because it may affect the sync of the TV. Unfortunately, this lowers our accuracy in detecting when the buttons are pushed.
A dancing mat is needed so the players can step on to play in the original game. To simulate the dancing mat, we decide to use keypad as the game controller where the button 2,4,6 and 8 represent up, left, right and down buttons, and button D represents start button.
We need a scheme to store and produce songs. We need enough memory on board to allow us to store as much songs as possible to make the game more fun to play. With this in mind, we have decided to use Atmel Mega163 with STK 200 to store and play the music. Although we cannot use other high end music encoding scheme, we have built a DAC to produce sample sound wave to make the songs realistic enough. In addition, we need a scheme to convert this sound to music and broadcast through the audio output of TV. We store frequency of the sound note in flash memory and a lookup table in the program. Then, we store the songs by writing different functions storing the music note of the songs.
Once the player has chosen the song in the introduction screen, the game will start and our program will ask the sound board to start to play the music. According to music beat, our program will draw arrows on the TV. The arrows will gradually rise up to the top of the screen. Arrows (10 different combinations altogether) will be drawn continuously in different direction to ensure the continuity of motion (dance). When an arrow reach the top of the screen, the player has to press the corresponding directional button at the same time. Once the player has pushed the button, the scoring system will run and calculate how much time has elapsed between the arrow reach the top of the screen and the button pressed, much like the human reaction timer in the lab. When the reaction time is calculated, one of the 4 comments, “Perfect”, “Good”, “Bad” and “Missed” will be displayed on the left hand side of the screen. We define a scoring system which points will be awarded base on the reaction time. Once the song is completed, points will be added and an overall grade will be displayed. To avoid cheating, player who pressed any of the 4 directional buttons for more than 1 second continuously will be regarded as cheating. The game will terminate immediately with all the statistics before the cheating occurs erased.
After the song is played and all the arrows are shown, the game will terminate and the player will be redirected to a end game statistics screen where player can review the accuracy of his/ her game play and the score will be shown. When player presses start again, the game will reset and the introduction screen will be shown.
Points are awarded according to the following scheme:
- Perfect: 100 Points
- Good: 50 Points
- Bad: 25 Points
- Missed: 0 points
Highest score is stored in the memory so player can review their improvement over continuous game play and how their skills compare to other players.
Music is stored in the flash memory in the form of a 2-D array. One array stores the musical notes to be played and the other array stores the length of the notes to be played. The arrow pattern is also stored in the form of a 2-D array in the flash memory. One array stores the pattern of the arrow to be shown and the other array stores the frame number where the arrow will be displayed.
Besides the above, some phrase of English characters and numbers are stored in flash so they can be displayed on the game screen.
The highest score is stored in eeprom so the value will be saved even the programming board is switched off.
Display and Gaming Programming Issues
The program is based on two state machines: 1) Non-game time state machine, and 2) Game time state machine. When the game has started, the game time state machine is turned on while the other is turned off. Otherwise, the non-game time state machine is turned on. Since we use TV as our main display, we have to make sure all the game logic and calculation must fit in 60 lines of video code. Thus, the main structure of our code is placed after the line 231 and carried out in between line 231 and line 30 of the next frame.
The display part of our design is modified from Video Generation with AVR demonstration code. However, we have customized several functions and also added several others to accommodate our needs. We have modified all the characters drawing code to take in parameters from flash to save memory in SRAM. We have also added several arrows drawing related functions. In addition, we have added keypad polling code to poll the button pressed by the player.
To make sure the animation display seems continuous to human, we have to make sure there are 30 frames displayed in each second. Due to this restriction, we are not able to draw all the graphics on the screen in one frame. We have derived a scheme to divide the graphics to be drawn in multiple frame by making use of a state counter. Once the program switches to a particular state, the internal counter is turned on and portions of graphics are drawn according to the count of the counter.
To display moving arrows, we have to continuously draw and erase the arrows. However, due to the time limit restriction, we are able to draw two arrows and delete two arrows at the same frame. Because of the need of displaying multiple arrows on the same screen, we have to draw the arrows at different frame. The 4 different sets of arrows can be drawn on the same screen according to the game time internal counter. The first set of arrows are drawn at the frame which remainder of division by 4 is 1. The second set of arrows are drawn at the frame which remainder of division by 4 is 2, where the same logic follows for the others. This pattern recycles until the end of the song. The position of each set of arrows in the whole song pattern are stored in an array. When the arrows are displayed and moved, their value in the corresponding position array will be updated. If it has reached the top, the arrows will not be processed anymore. To read the arrays storing the array pattern and array showing time, the program will turn to its state internal counter. Once the specified frame number is reached by the counter, the program will draw the arrow specified by the same position in another array.
The arrows need to move 80 position to reach the top from their starting position. We tried to move it by one position every frame. However, the program is not able to draw more than two arrows per frame, meaning that only one arrow can be shown on the same screen at the same time which is quite demanding to the game play. Thus, we are settled with having the arrows move by one position every 6 frames.
Another gaming programming issue is to determine the cheating condition. If this is not implemented, the player can always pressed all 4 buttons all the time to achieve 100% accuracy. Thus, we make use of the state internal counter to make sure no same key is pressed continuously for a whole second (30 frames).
Sound Programming Issues
One main part of our game is the functioning of playing the sound track at the right time. Our design is inspired by the Russian Bloc game in Spring 2002 Final Project. When a song is chosen by the player, the game board sends a signal to the sound board through the input and output port. When the game ends, the game board will send another signal to the sound board to turn off the music. Otherwise, the same song will be played continuously. The musically notes are made by the specified frequency of the musical notes (which can be found here in the code). We have written 4 songs which is:
2) Boom Boom Dollar
3) Samba de Amigo
4) Chicken Run
To play the musical notes, the program will read the 2-D array storing the songs. The program will play the notes following the orders in the array. Once the data in the second array, which contains the length of the musical notes, reach the same number as the internal counter, the program will play the next notes. This scheme serves us well and we are able to play perfect melody resembled the real life music.
- STK 500 Development Board
- Atmel Mega32 Microcontroller
- STK 200 Development Board
- Atmel Mega163 Microcontroller
- 7-bit DAC
For more detail: Tap the Dance