The Contender video game using Atmel Mega32

Introduction

The pitch
“The Contender” is an interacting boxing game in which the player actively participate in the game with real time punching, ducking, dodging, etc.
The Description and Motivation
This game is a twist of a popular arcade game called “Mocap Boxing”, short for Motion Capture Boxing. In this game, the players are asked to hold two boxing gloves and stand in the middle of a motion sensing environment. The screen in front of the player would display a virtual opponent who will throw different punches. Each player gets a life bar and knock outs. The player will have a chance after the opponent throw a punch to punch. After three knock outs, the player wins and advances to the next level. The goal of the game, of course, is to defeat all the boxers in the game and beat the “champion” and become the next boxing champion.

In our version of the VR boxing game, there’s only 1 stage, but with 3 levels of difficulties. The player also puts on boxing gloves equipped with accelerometers to measure the acceleration of the “punch”, and a weight training belt, also equipped with accelerometers to detect the dodging motion of the player when punches are thrown. The player gets a chance to punch the opponent after the opponent punches. The opponent, depending on the level of difficulty, would have different probability of dodging the player’s punch, thus prolonging the match, and tests both endurance and patience of the player. After the life of either the player or the computer is reduced to zero, a score board is shown to rank the player’s performance relative to the previous players.
We didn’t know what to make in the beginning. We were going to make a real time robot arm control with gloves, in which the user can control the movement and motion of a robot arm by wearing a gamepad glove with USB compatibility and moving in it. Unfortunately, the routine we had to write for the USB driver would be too time consuming. Thus we had to find some other projects to do.
After a trip to Florida and seeing Mocap Boxing in one of the arcades, we had so much fun with it that we decided to make our own version of this boxing game so we can play it all we want without having to feed quarters. Besides, both of us are avid video game players, we want to make something that we both would enjoy for the 4 weeks of our final project period. Thus, we aimed to create a game that is simple to pick up and learn, yet entertaining and fun to play. We also wanted to create a game in TV screen since it has a bigger display area than LCDs, and that it’s cheaper ($0!!).
This project was a fun and educational experience for the both of us. We enjoyed what we were doing and applied what we learned in class to make something playable.
The game was completed with Atmel Mega32 microcontroller and a TV from RadioShack. There are two gloves and a training belt equipped with accelerometers.
We are able to finish the game in 3 weeks and kept the cost of the project under the allowed budget ($50).

High-Level Design

Rationale and sources of your project idea
This boxing game simulates a real pro fight, forcing you to bob and weave to avoid your opponent’s punches, while throwing punches of your own. Konami’s motion capture system quickly reads where you stand, and the game screen shifts as you move. The player put on the special boxing gloves and can throw a hook, uppercut, or jab, while physically dodging punches from your opponent. Mocap Boxing also displays the number of calories you burn during game play, making it not just a video game, but a full-body workout. Besides, both of us are avid video game players, we want to make something that we both would enjoy for the 4 weeks of our final project period. Thus, we aimed to create a game that is simple to pick up and learn, yet entertaining and fun to play. We also wanted to create a game in TV screen since it has a bigger display area than LCDs, and that it’s cheaper ($0!!). Since we’re transplanting the idea onto Mega32 platform, we’re bringing the cost down significantly (from $6500 plus to under $50)
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.
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.
Discuss existing patents, copyrights, and trademarks which are relevant to your project.
We utilized couple things from other people.
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.
5. Stationary Helicopter Circuit:
We took the accelerometer from Tom Ling and Norbert Huber’s project from last year. The link can be found in the reference.

Parts List:

The Contender was completed within the allotted budget ($50)
A lot of the components are free because they’re readily available in lab. (resistors, capacitors, wires, etc)
The ADXL202JE accelerometer are free samples from analog devices (analog.com)
The training belts are from Raymond Lau.
The working accelerometer circuit (attached on the belt) is detached from the stationary helicopter project by Tom Ling and Norbert Huber from Spring 2004.

We could have done some extra things to avoid the costs in this project. The STK 500 can be easily replaced with a board we could solder by ourselves. We could also rearrange the amplifiers to make room for the extra TV output to avoid the extra breadboard.
 
For more detail: The Contender video game