ECEN 390 - Laser Tag Project

Implementing a Game with Sound, Having Fun With Your Laser-Tag System

To complete this final milestone, you will implement a complete game that supports play between two teams (of any number) Unlike your other programming assignments, you are free to implement the game as you like, as long as you meet the requirements for game functionality, including sound. The coding standard still applies.

The game functions as follows. The game is essentially a version of “last person standing”. The game ends when all of the members of either Team-A or Team-B have “died”. The winning team is the team that has at least one member remaining “alive” at the end of the game.

1. Only 2 frequencies are used. Team-A will use frequency 6 for shooting and will detect hits only on frequency 9. Team-B will shoot on frequency 9 and detect hits only on frequency 6.
2. Teams can consist of any number of persons; teams should start with the same number of members for fairness.
3. Each team member has their own system which consists of (1) the plastic box containing the electronics and (2) a gun.
4. Team membership is determined by the position of SW0 on the ZYBO board. If the switch is down, the person is part of Team-A. If the switch is up, the person is part of Team-B.
5. Each member starts the game with 3 lives. Once all lives are expended, the person's system disables shooting and the person leaves the game.
6. The game ends when all members of either team have lost all lives.
7. No inter-system communication is required. Each system functions independently and players drop out of the game as they lose lives. You can tell that the game is over when all members of one team have dropped out of the game and returned to base.

Note that the game details below have been refined over several playing sessions. The current configuration seems to provide a nice balance of fun game play and low complexity.

1. Each team member starts with 3 lives.
2. A team member loses a life when they accumulate 5 hits.
3. The gun has a “clip” that contains 10 shots. Once a player has fired 10 shots they must wait for the clip to “autoload”. Autoloading the clip requires 3 seconds.
4. The player may force a reload of the clip at any time by pulling and holding the trigger for 3 seconds (if the clip contains shots, the initial push of the trigger will fire a shot).
5. Immediately after losing a life, a player is invincible for 5 seconds thus giving them time to quickly scurry away. Note that you are not allowed to shoot while invincible.

Sound is essential to game play. It informs the player when they have been hit, when they have lost a life, and when they have expended all lives and must drop out of the game. In detail:

1. A laser-like sound is played each time a player fires a shot. If the clip is empty, a “click” sound is played when the trigger is pushed.
2. A “scream and die” sound is played when the player has lost a life.
3. A Gameboy startup sound will play when the system is first turned on.
4. A “reload” sound is played each time the clip is loaded (either automatically or manually).
5. An “ouch” sound is played each time a player is hit.
6. A Pacman “game over” sound is played once a player has lost all lives.
7. A voice will inform a player when they must drop from the game and “return to base.” This voice sound will be infinitely repeated, alternated with 1 second of silence.

These videos demonstrate when sounds should be played and also show more detailed behavior of the game.

1. Sounds related to the gun, how the clip works, reloading, etc.
2. Sounds made when hit by an opponent.
3. Sounds that occur at the end of the game.

Grades for Milestone 5 will be determined by the functionality of the game and the lack of observable bugs. Groups will get credit for each feature that is correctly implemented. Additional credit will be given for a completely bug-free game.

1. Game startup sound (5%): correctly generating the game startup sound.
2. Gun firing (10%): correctly implementing the gun firing sound, e.g., the gun fires a shot when the trigger is pulled and makes a clicking noise when 10 shots have been fired and the gun has not been reloaded (automatically or manually).
3. Auto- and manual reload (20%): correctly implementing the auto and manual load feature; the gun autoloads once the clip is empty and the user can force a manual reload by holding the trigger for the appropriate amount of time.
4. Lives (15%): correctly keeping track of lives and properly generating the death sound when 5 shots have been accumulated.
5. End of Game (5%): correctly generate the end-of-life game sound, and play the “return to base” sound as required.
6. Bugs (25%): No detectable bugs. Subtract 5% for each detected bug up to the total for this category. Bugs can include:
   1. False hits at any point.
   2. Incorrectly keeping track of lives.
   3. Undue static.
   4. Incorrect game play.
7. Code quality (see learning suite for grading details), based on the coding standard. Submit your code by invoking ./check_and_zip.py 390m5 to create a zip file that you submit to learning suite.

One of the best ways to find bugs in your system is to play it extensively. If the TA detects a bug during pass-off, the team can attempt to fix their system and pass off later. However, don't depend upon the TA to detect bugs in your system. You must test and fully debug your system prior to bringing it to the TAs for pass off. If pass-off attempts become excessive, we will institute a penalty of some sort.

For this milestone you will not use check-and-zip. Just create a zip file of your new files and submit that to learning suite. Do not include any older files that have already been graded. Otherwise, these older files will be double graded.

The instructor provides working sound code and sound data. All sound data are contained in the sounds subdirectory of the lasertag directory. While coding this milestone, the student needs to add the necessary calls to the sound code so that sounds are correctly activated during game play.

Please read the comments and the function sound_runTest() function in sound.c to see how to use the sound code (it is straightforward).

Note: Make sure to add sound_tick() to isr_function() along with all of the _tick() functions.

WARNING!!! WHEN SET TO ITS MAXIMUM VALUE, THE SOUND VOLUME MAY DAMAGE YOUR HEARING IF YOU PLUG EARPHONES INTO THE ZYBO BOARD. THE INSTRUCTOR STRONGLY RECOMMENDS USING THE ATTACHED SPEAKER WITH VOLUME SET TO ITS LOWEST SETTING WHEN IMPLEMENTING YOUR GAME. Volume can be controlled using the 'sound_setVolume()' that can found in the sound.c file. Please read sound.c for more detail on how to use this function.

These videos demonstrate when sounds should be played and also show more detailed behavior of the game.

1. Sounds related to the gun, how the clip works, reloading, etc.
2. Sounds made when hit by an opponent.
3. Sounds that occur at the end of the game.

In this appendix you can find additional information that can be used for creative projects.

The bluetooth modem is connected to the ZYNQ FPGA via a fixed-rate 9600 BAUD modem. Communication with the modem is simple enough: characters pushed out the Bluetooth UART are transmitted via the Bluetooth modem and vice versa for receive. You can get the base addresses for the Bluetooth UART in the xparameters.h file. I have included documentation for the UART below. Look in the Consolidated_330_SW_bsp/ps7_cortex9_0/libsrc/uartlite_v3_0 directory for the UART driver code.

• Adafruit Bluetooth Modem Info
• Xilinx UART Lite Documentation