HIGH LEVEL DESIGN
Rationale and sources of our project idea
Our project idea comes from the hugely successful 1985 Nintendo Duck Hunt game. We have all played that game and are interested in recreating the classic game using two Atmel Mega32 microcontrollers.
The math behind our duck hunt game is based on the lunar lander video game we did in our lab. We decided to express distance in our game in terms of pixels and time in term of frames, so the speed of a duck will be expressed as pixels/frames. For the video generation part of our game, we need to keep track of the speed, and direction of two ducks flying on the screen (in the two duck mode of the game). Each ducks can move in possibly 8 directions (up, down, left, right and four diagonal directions), and have a minimum speed of 0 and a maximal speed that is depended on whether if the duck is being controlled by a player or is it on a random movement course. When the duck is controlled by a player, the max speed is 1 pixel/frame in vertical and horizontal directions and slightly faster in diagonal directions. When the duck is uncontrolled, it moves at the same 1 pixel/frame for all 8 directions because we normalized the speed at diagonal directions to match that of the vertical and horizontal.
Our version of Duck Hunt included both sound effects and music. A second MCU was necessary for sound because we wanted to play back sampled sounds in flash and we were afraid that one MCU alone would not be able to handle the TV signal, game logistics, Sega controller, and sound at once. The high level design of the sound was based on Pulse Width Modulation performed on a second MCU. Music was created using the DDS method similar to the Cricket Call Synthesizer Lab. A sine table was loaded into memory and the width of the pulse on the output of the PWM (via the OCR) was determined by the sine table value. Stepping through the sine table more quickly produced higher frequency notes while stepping through the sine table slowly created low frequency notes. The speed at which the sine table was stepped through was determined by an increment value that was added to an accumulator, which was the index into the sine table. We used a timer interrupt that updated the accumulator every time the timer overflowed. The value of the increment to add to the accumulator in order to get the desired frequency is determined by:
1/frequency = (size of accumulator/increment)
x (# counts in a pulse/clk frequency)
An array of frequency values were loaded into flash corresponding to the notes in a song. The highest frequency note played was 2349 Hz. According to the formula above, this gives an increment size of 161,420,931. With this size increment, there would be about 27 samples taken from the sine table which is still pretty accurate for one cycle of a sine.
In addition to music, the sound portion of our game included sound effects. The sound effects of a gunshot and flapping noise were obtained online in wav format. The flapping noise had a sampling rate of 44kHz while the gunshot sound had a sampling rate of 11kHz both with 8 bits per sample. Since we only have 32K of memory on flash and thus a limited amount of space to work with, these sound files had to be resampled in Matlab. The resampling frequency we could choose was limited by the prescalar values on the timer on the MCU. In addition, we didn't want to choose a sampling frequency that was too low or else the sounds would degrade in quality. Since the fast PWM mode outputted a sample on 256 ticks and each tick had a duration of 1/(16,000,000/prescalar) seconds, we settled on a prescalar value of 8. This made each sample 1.28x10^-4 seconds in duration, or equivalently, produced a sampling frequency of 7813 Hz. Matlab was used to resample the sound files to this value. In addition to this, the samples had to be normalized to an integer range from 0 to 255 since we were working with 8 bits in the timer. To playback these sounds in the MCU in fast PWM mode, the sounds were loaded into flash and the output compare register was set equal to the sample value every time the timer overflowed.
This section will go through the rules of the game. The game starts at level 0 and round 0, with level representing the difficulty of the game and rounds representing which stage of the game a player is in. The in game menu allows players to select either one player or two players modes, as well as one duck or two ducks modes. All the selection are made by shooting the corresponding ducks on the screen. The round counter goes up during the menu selection stage, so by the time the game actually starts, the game is already in level 0 and round 3. There is a pre-round display which shows the current level and round, and the required score (number of ducks) needed to advance. A round will end when any of the following three things happen, all the ducks have been shot; the shooter has run out of bullets; or the shooter has run out of time. At this time the dog will come out holding the dead ducks if the player has shot all of them, or if the player loses the ducks will fly away and the dog comes out and laugh at the player. In two players mode the job of the other player will be to control one of the duck and try to evade the shooter. He can also press two buttons together on the controller to switch which duck he controls. The shooter will have a laser pointer attached to his gun so the other player can see where he is pointing at to make the game a little fairer. The shooter wins the game when he completes all 10 levels by shooting the minimum number of ducks required to advance each level, and the controller wins it if he is able to evade the shooter enough number of times that the shooter failed to advance. There will be a win/lose screen at the end declaring the winner and the loser. The game then restarts to the menu screen.
We originally thought about going all the way and make the game color, but that turned out to be impossible with just our mega 32 MCU. We needed a second MCU for the sound/music in our game because the first MCU can't handle everything all at once; it is already busy enough with drawing the TV and making all the calculations for the game.
We used the NTSC standard for generating video signal. We generated a non-interlaced, black and white TV signal, which means our game can be played on any standard NTSC CRT TV. To the best of our knowledge, our game didn't involve any IEEE standards.
Patents, copyrights, and trademarks
The patents relevant to our project are
all related to either the gun or the controller. The gun we used was
a NES light-sensitive zapper gun, it involved patient # 4813682-"Video
target control and sensing circuit for photosensitive gun" and
patent # 4395045-"Television precision target shooting apparatus
and method". We also used the Sega Genesis controller, which is
patented by NES.