Background math

There is no mathematical calculation needed to design this game. The punches thrown by the opponents are randomized by using the rand function. The opponent has 1/3 of a chance to throw straight punches and 2/3 of chance to throw hook shots. The opponent also has a finite probability that it would dodge the player's punch, which is also implemented with the rand function. The delay is taken from the library. For score keeping, in order for us to display the scores properly, we first mod the number by 10000  to get the 5th digit, mod the number by 10000 and divide by 1000 to get the 4th digit, and so on.

Logical structure

This project consists of both hardware and software design. Software of the microcontroller was programmed in C, which includes video signal generation with results from the user controls, delaying and waiting for input, game flow, ADC results, level of difficulty, win / lose algorithm, score keeping, some randomized punches and dodges by the computer boxers, etc. The Hardware is consisted of microcontroller timers to maintain the signal timing, ADC conversion from the output of the accelerometer amplifier, amplifier circuit to amplify the accelerometer signal, and the accelerometer RC circuit, with the unit prototype board and two boxing gloves and a training belt.

The user, upon hitting reset, is brought to the title screen, then the player can choose between three difficulty levels and start playing. The computer would always punch first, and the player would have a chance to hit back after computer punches. After either computer or player's life is reduced to zero, game is over and the player is brought to a screen to enter his/her initials to be placed on the score board. For more information and state machine diagrams, please refer to the program design page.

High Level Project Architecture

Hardware/software tradeoffs

4 things regarding hardware and software tradeoffs.

1. C code instead of Assembly - this is a big time saver. While we could have achieved more and have better graphics in the game had we programmed in assembly, we have other obligations as a senior in ECE. It's true that coding in C restricted us  in terms of timing for creating stable video images and calculations, while coding in assembly can allow us to do more things.

2. Optimize for Speed instead of Size - this allows us to perform more tasks, but we won't have as much memory to use for score keeping and drawing things. Optimizing for size would generate flicker in our game, which is undesirable. Of course, this problem can be eliminated had we programmed in assembly. We did this to save time.

3. Using Mega32 instead of something else - we can reuse the video code provided by Professor. We didn't have to learn a new hardware. However, memory becomes an issue, as mentioned in the first and second tradeoff.

4. Using ADXL202 instead of something else - Many groups have designed their final project using the ADXL202. Since the prototype board is reasily available, we didn't want to use some revolutionary super accelerometers which we have to build our own board and solder by ourselves. This puts some limitation on the punch styles that players can throw, and perhaps limits some extra features such as punch speed, calorie used, etc. Had we used some other accelerometers with higher g or more axis, we could have eliminate this problem.

5. Using TV instead of LCD - TV gives better graphics, but LCD would make time budget a lot more flexible and making display control easier. But LCD are costly and would exceed the budget of this project.

Relationship of your design to available standards.

US standard video (RS-170A) manages to encode sync information, intensity, and color into a single analog signal, and thus into a single wire. TV frames is entirely a serial operation; dot after dot, line after line, frame after frame. The signal could use a changing voltage to indicate the intensity of pixels as the TV paints out each line, frame, and image.

Above is a depiction of four lines of video. Every line begins with a horizontal sync pulse which tells the television to begin a new line. After the sync, the majority of the video signal is simply a varying voltage, between 0.3V and 1V, which controls the intensity of the electron beam as it paints out the line.

A voltage of 0.3V gives black, while 1V corresponds to white. It takes 262 lines to make up a frame, of which only 242 are visible. The final 20 lines are vertical syncs. The vertical sync instructs the TV to prepare for the next frame by sweeping up to the top of the display again. You can create a vertical sync simply by sending 20 blank video lines with the horizontal sync inverted.

Since the signal is black and white, only one bit is needed for each pixel, allowing us to store the video buffer as a vector of 1,600 bytes.

1. The Name "The Contender":
    "The Contender" is a registered trademark of a NBC reality show. The logo of the homepage is from NBC.com. We do not take credit of the name, and all rights goes to NBC. We would change our name if they request us to, but that's unlikely to happen since this game will only be seen in ECE 476 lab and its personnel who know that this game has nothing to do with the show.

2. The Idea from "Mocap Boxing":
    Mocap Boxing is a registered trademark for an arcade game machine owned by Konami Inc. We believe that this game is different enough from the Mocap Boxing game to keep us out of trouble. We give all credits of any usage of the title "Mocap Boxing" to Konami Inc.

3. Professor Land's Video Code:
    We asked for permission before we utilized the code for our final project. The link can be found in the reference page.

4. Nova Strike's Score Keeping:
    We referred to the code and got ideas for our score keeping algorithm from Nova Strike, the project by Kalim Moghul and Kevin Oh from last year. The link can be found in the reference page.