Milestone 5

Table of contents

  1. Overview
  2. Resources
    1. Source Code
    2. Making Sound
  3. Game Specifications
    1. “Last Person Standing”
    2. Configuration Numbers
    3. Sounds
  4. Implementation Details
    1. Game Code Sketch
  5. Pass Off and Grading
  6. Code Submission

Overview

For this milestone, you will implement a complete game with sound and hopefully have fun with your laser tag system. The game is to support play between two teams of any number of players. 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.

Resources

Source Code

Note that the following files are provided in your ecen390 project directory. Refer to the comments above each function for more detail.

  • ltag/main/main.c
  • ltag/main/game.h

You are expected to create and implement the following file. See the provided header file (.h) for more detail.

  • ltag/main/game.c

Making Sound

You are provided working sound code and sound data. While coding this milestone, you need to add calls to these sound functions so that various sounds are made during game play.

Game Specifications

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.

“Last Person Standing”

  1. Only 2 frequencies are used. Team-A will use frequency 6 for shooting and will detect hits only on frequency 8. Team-B will shoot on frequency 8 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 laser tag unit.
  4. Team membership is determined by navigating a menu with the buttons.
  5. Each member starts the game with 3 lives. Once all lives are expended, shooting is disabled and the person leaves the game.
  6. The game ends when all members of either team have lost all lives.
  7. No communication between laser tag units is required. Each tag unit 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.

Configuration Numbers

Note that the numbers 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 tag unit has a “clip” that contains 10 shots. Once a player has fired 10 shots they must wait 3 seconds for the clip to “auto-load”.
  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.

Sounds

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 laser tag unit 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.

Implementation Details

Game Code Sketch

A sketch is given below as a starting point for an implementation of game.c. You will need to finish the implementation.

#include <stdio.h>

// This game supports two teams, Team-A and Team-B.
// Each team operates on its own configurable frequency.
// Each player has a fixed set of lives and once they
// have expended all lives, operation ceases and they are told
// to return to base to await the ultimate end of the game.
// The tag unit is clip-based and each clip contains a fixed number
// of shots that takes a short time to reload a new clip.
// The clips are automatically loaded.
void game_twoTeamTag(void) {
  uint16_t hitCount = 0;

  // Configuration...

  // Implement game loop...

  // End game loop...
}

Pass Off and Grading

Grades for Milestone 5 will be determined by the functionality of the game and the lack of observable bugs. Teams will get credit for each feature that is correctly implemented.

  1. Game startup sound (5%): correctly generating the game startup sound.
  2. Tag unit firing (20%): correctly implementing firing sound, e.g., the tag unit fires a shot when the trigger is pulled and makes a clicking noise when 10 shots have been fired and the unit has not been reloaded (automatically or manually).
  3. Auto and manual reload (20%): correctly implementing the auto and manual load feature; the tag unit auto-loads 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 (20%): correctly keeping track of lives and properly generating the death sound when 5 shots have been accumulated.
  5. End of Game (10%): 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:
    • False hits at any point.
    • Incorrectly keeping track of lives.
    • Undue static.
    • Incorrect game play.

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.

Code Submission

You will use ./check_and_zip.py 390m5 to prepare your zip file for submission to Learning Suite. It will be checked for adherence to the coding standard.