Software Design


The software for our project was based off of the video generation code written by Professor Land.  We added several new functions to his code and modified some of his functions.  Using the microcontroller to generate a video signal requires several software sacrifices.  The first is that no code can be executed while a line is being drawn onto the screen.   Only a small amount of code can be placed at the end of the interrupt that blasts pixels on the screen.  Any significant code that must be run have to be done between the time that frames are drawn onto the screen.  This meant that we could not implement tasks, and that all game code had to be placed in the while loop within main. 



One of our first main tasks, after determining the how the outputs of the gun worked was to integrate this into our program and make its outputs usable.  There were some restrictions with the way the gun worked that influenced how it had to be used.  Holding down the trigger part way caused its output to go low, at which point it can be released and the output goes back high, or the trigger can be depressed all the way at which time the output goes back high.  Therefore we only tested for a trigger pull on the output going from low to high.  Additionally, the light sensor output only stays high for 2.5ms, and a frame is about 16ms long, meaning that we could not wait until the end of the frame to test the output, this required us to check on every line.  However, we realized we didn’t want to check on every line, so we just had it check the top portion of the screen, to avoid where information such as hits and shots remaining were displayed. 



Game play:


The player first has to choose whether they want to play with one duck or two, then they can choose their difficulty level.  The player gets (1 x difficulty x number of ducks per round) points per bird killed, so one duck on easy=1, medium=2, and hard=3, but with two ducks on easy=2, medium=4, hard=6. The player gets 3 shots per round, which can be either one duck or two.  The player has to kill at least 6 ducks in the first two rounds, 7 in the next two, 8 in the next two, 9 in the next two, and 10 from then on to continue the game.  When the player gets game over they will be told if they beat the high score.  Otherwise it will just display the score and after pausing go back to the introduction screens. 



To implement the game we had quite a few states.  The game itself however was only about 7 of our 19 states.  The first five states were used to display the introductory screens, the next 2 displayed the instructions, the next two were used to choose between one duck or two, and two were used to choose the difficulty.  The non game states are fairly simple and either just go back to the state that referenced it, or to the next state.  The game states are a little more complicated and will be better understood in a diagram. 


We used a switch statement that executed once per frame to determine which state to execute. 


Here is a quick explanation of the states


intro1: displays “Welcome to DUCK HUNTER”

intro2: displays “created by”

intro3: displays “LEONARD BERGSMAN

                        MICHAEL PESSIKI”

intro4: displays “shoot the screen to begin”

introflash: fills the whole screen white and determines whether there was a hit

             if there was it goes to choosetype1 else it goes back to intro4

choosetype1-2: display instructions

choosetype3: display game choices

choosetypeflash: flash screen to determine if there was a hit.  If so go to choosedifficulty1 otherwise toggle selection and go back to choices

choosedifficulty1: display difficulties                                                                                                                                     

choosedifficultyflash:  flash screen to determine if there was a hit.  If so go to waitstate otherwise toggle selection and go back to choosedifficulty1

waitstate: sets up the variables used in the game, and displays part of the bottom menu

duckflying: the duck flies around the screen at the appropriate speed,  and bounces off walls when it hits them.  When the flying time is exceeded it goes to the flyaway state.  The duck also flaps its wings by toggling the character ever quarter of a second.  The ducks direction is also calculated and determines which character to use.  If the user has shots left in the round he is able to try to shoot the duck, if so the area around the duck is filled in based on the difficulty, and it goes into duckflash.  The remaining ducks and hits are also incremented. 

duckflash: determines whether there was a hit, and updates the appropriate variables, and updates shots remaining 

duckfalling: updates variables, and causes the falling duck char to be displayed falling down the screen

duckflyaway: updates variables, and causes the flying away duck char to be displayed rising up the screen

roundover: resets round variables, sets random starting direction, and pauses briefly

results: determines whether the user shot enough ducks to continue, and outputs the results of the round

gameover: displays “gameover” and determines whether the user got the high score, which is then displayed  Variables are reset and the game starts over in intro1



We created 3 new functions:


video_clear() which cleared the screen;

video_fill() which filled the screen white;

and video_putchar2() which was functionally the same as the original video_putchar() which we modified to print out characters 8 bits wide instead of 5. 



Other program design involved the implementation of audio.  We implemented this by using the sound code found on the video page, and can be found here.  We used the audio portions of the code as the basis for ours.  We modified it so that we would only play certain things at certain times, and we modified the note string to play the Alma Mater. 



We also based our duck movement routine on Professor Land’s initial bouncing ball algorithm.  However we had each duck start at a random x position near the bottom of the screen, and would move diagonally up and left or right, the direction was chosen randomly. 



One of our biggest annoyances with this project was the difficulty of outputting text to the screen.  We were unable to output more than 6 big characters per frame, and only a few short lines of small characters.  To deal with this we would simply output less text per frame, and either do it on individual frames, or would print a couple of characters at a time.