Introduction | High Level
Design | Program/Hardware Design | Results
| Conclusions
Appendix A: Code Listing | Appendix B:
Schematics | Appendix C: Budget
Appendix D: Specific Tasks | References
A 4 player free for all of ball bouncing madness
Our final project was a modified version of the video game “Monkeyball” available for the Nintendo Gamecube. Our version of the game involves 2-4 players. Players control a circle on a rectangular playing field while trying to knock the opposing players off of this field by collisions. A point is scored each time a player knocks an opposing player out. The game ends when one of the players reaches a point limit, usually 10 points.
We decided to do this project because both of us enjoy playing video games and wanted to design one of our own. Monkeyball came about because it is a game we both enjoy and because no else has done that type of a game before for a final project. Also we wanted to design a game that is capable of four-player action because we both like playing multiplayer games.
Since Monkeyball involves collisions between the opposing players, we needed some calculations to determine the physics for our game. We attempted to simplify the physics for this game by making the following assumptions:
1. All collisions are elastic (i.e. momentum and kinetic energy are conserved)
2. All collisions assume head-on collisions.
Under normal conditions, since all of the players have the same mass, if we take the above assumptions into consideration, then the results only involves swapping the vx and vy values of the two balls in the collision which is easy to do in code without complex calculations.
One exception occurs from an advanced feature of our game when one of the players obtains a “heavy” power-up that allows that player to have twice as much mass. In that case, we still have a velocity swap, except the lighter ball gains twice as much velocity of the heavy ball in the opposite direction from the collision while the heavy ball only gains half as much velocity from the lighter ball.
Also, we need to determine when a collision actually occurs. Both of the following criteria must occur for a real collision:
1. The distance between the two balls must be less than two radiuses.
2. The dot product for the two velocity vectors must be negative (i.e. the two balls are heading towards each other, not one ball following close to another, for example).
Using these two criteria ensures that only one collision is recorded in our code when two balls collide, which prevents two slow-moving balls from getting stuck together in our program.
We have one overall state machine within our design. At reset, the state machine starts at a “titlescreen” state, which displays the title of our game along with game options that can be adjusted. The program then enters the “normal” state, which is the gameplay for our program. Once the game is over, the program enters a “gameover” state which displays the winner on the screen and cycles back to the titlescreen menu. See Appendix A for our code and Appendix B for our state machines.
We decided to stick with the Atmel Mega32 processor that we became familiar with throughout the semester. We also decided to do all of our own coding in C because it was more intuitive to code and because it saves us a lot of frustration from using assembly code.
Because of this and because we used Professor Land’s video generation code to generate NTSC signals, this required that our program must display all of our images within 1/60 of a second. This forced us to try to optimize our code for speed as much as possible because within a given frame we had to draw as much as four moving balls for each frame. One example of optimizing our code for speed was the simplified physics calculations mentioned above involving simple velocity swaps.
Since we used a black and white TV along with Professor Land’s video generation code, our program was required to comply with NTSC (RS-170) standards. NTSC is the standard for black and white TV, and is split into two frames per screen containing 262.5 lines per frame at a frame refresh rate of 60 Hz. Professor Land’s video generation code uses a modified version that produces 100 lines each displayed twice.
There already is a video game on the open market called “MonkeyBall” licensed by Sega and Nintendo which helped inspire our game design. Because of this, we do not intend to claim the “MonkeyBall” slogan or the gameplay as ours and give all credit to Sega and Nintendo for the gameplay used in our design.
Since the only people who will see this project are friends and ECE476 students and staff, they will be well aware that our game was created by us and will have no misapprehension that our game was created by Sega and Nintendo, which means we do not infringe on the trademark that Sega/Nintendo have on their licensed Monkeyball game.
Our title screen includes two options that can be adjusted by the first-player Sega controller: number of players, and number of points required to win. A cursor indicates the current option that can be edited. The up and down buttons adjust between the options, while left and right decrement or increment the numbers, respectively. The first-player controller can then press Button B in order to start the game.
As the game starts, each of the players start in one of four corners. Each of
the players then attempt to ram each other out of the rectangular border defined
on the screen. Each of the four players can press the four directional buttons
on their Sega controller to increase the velocity of their ball in that respective
direction. If a player goes out of bounds, then a point is awarded to the opposing
player that last came in contact with the out-of-bounds player. If the player
goes out of bounds on his/her own initiative without contact (aka suiciding),
then no point is awarded to anyone.
At given intervals, the letters “H” or “I” appear in the center of the screen. A player who runs over the “H” now gains “heavy” status marked with a horizontal line through that player’s circle, which means that they have twice as much mass compared with the other players. This player maintains the heavy status until the player is knocked off of the screen.
If a player moves over an “I”, that player gains “invincible” status marked with a vertical line through that player’s circle, meaning that this player can rebound off of the edges of the field without falling over. This “invincible” status last for 8 seconds, then that player returns to normal status.
A player cannot obtain both “heavy” and “invincible” statuses at the same time. If a player already has a status and then moves over a second status, the player loses their original status and gains the new status instead.
Once a player reaches the maximum point limit determined in the options menu, then that player has won. A game-over screen displays the winning player along with instructions to return back to the title screen.
Some parts of our program were surprisingly difficult to write. One issue is that we had trouble drawing the playing field borders without either running out of CPU time or having the balls erase these line whenever someone went out of bounds. At first we tried to use the video_line function provided by Professor Land’s video generation code but it turns out that the function requires an excessive amount of computation necessary to draw simple horizontal or vertical lines. We then tried conditional statements in the circle-ball drawing algorithm that ensured that these lines weren’t overwritten but that required an excessive amounts of if-statements. Eventually we decided to design our own horizontal and vertical line functions that only contained the minimum amount of code necessary to draw the respective lines to define our playing board.
Also, because the video_smallchar function can only place small characters at x-coordinates at multiples of 4, this meant that the numbers 1,2,3,4 labeling the four players didn’t move as the rest of the ball moved, instead, the circle acted almost like a “spotlight” while the character stayed in the same position. This is acceptable because these numbers are only used to identify between the four players, which this effect does not hinder in normal gameplay.
We used an STK-500 board with an Atmel Mega32 processor. Port D.5 and D.6 corresponded to the video signal, Port A is used for the Player 1 and Player 2 Sega controllers, while Port B is used for the Player 3 and Player 4 Sega controllers. Also, Port D.0 is used for the B button on the Player 1 Sega controller to start the game at the title screen.
We used the same schematic used to generate the video signal as the one from ECE476 Lab4 this semester which generates the 0.0, 0.3, and 1.0V signals needed for sync, black, and white NTSC signals, respectively. See Appendix B for our overall schematic design.
The four Sega Genesis controllers we use for our project were surprisingly easier to implement than we had originally thought. We used four DB9 connectors purchased from Radio Shack to connect the Sega controllers to wires which leads into Ports A and B. While looking through previous final projects, we found the Sega Genesis pin assignments from the Spring 2003 Cantneroid project by Chris Moschner and Matt Cantlon. The pin assignments are as below:
| Pin | Function (Select = GND) | Function (Select = 5V) |
| 1 | Up | Up |
| 2 | Down | Down |
| 3 | (none) | Left |
| 4 | (none) | Right |
| 5 | +5V | +5V |
| 6 | Button A | Button B |
| 7 | Select | Select |
| 8 | Ground | Ground |
| 9 | Start | Button C |
Since our game only uses the four directional buttons with the exception of Button B on the first-player controller, we could hardwire the select bit on Pin 7 of the controller to +5V. This allows us to directly hardwire the pins from the Sega controller directly into wires leading to the STK-500 ports because there is a one-to-one correspondence between the Sega controller pins and the STK-500 port bits.
Most of the code in our lab was directly modified from the video generation code provided by Professor Bruce Land for the ECE476 Lab4 assignment during the Spring 2004 semester. Prof. Land’s code contained methods to draw line and characters to the TV screen along with a basic template for video generation using NTSC signals which we used heavily throughout our project.
Also, we wired the Sega Genesis controllers to the STK-500 by modeling the setup from the Spring 2003 Canternoid project by Chris Moschner and Matt Cantlon. The Sega controller setup can also be found on many other development websites, but the Canternoid project contained a nice diagram that helped to wire the controllers.
There were two things we could think of that did not work very well. First was that the video_line function provided by Professor Land’s code took too much time in order to draw the horizontal and vertical lines to define our playing field. In order to solve that, we decided to implement our own horizontal and vertical line drawing functions that were more time-efficient.
Also, we attempted to connect the Sega controllers to our breadboard using wires only, along with tape to wrap the wires together. Although the actual connection was successful, it took a great amount of time to rewire the controllers every time we took our setup apart whenever the lab was closing. We eventually solved this by purchasing DB9 connectors from Radio Shack as mentioned above so that setting up did not involve too much hassle.
Our project successfully manages an NTSC screen. Since the refresh rate of an NTSC screen without interlacing is 1/30th of a second, the main portion of our code executes 30 times a second. It is able to perform location updates, collision detection, power-up sensing and all other tasks related to gameplay without any flicker or other visual artifacts.
The accuracy of our project is not that great. Namely, the physics behind the collisions is not very good (To refresh, we present all collisions as head on collisions between perfectly elastic spheres of equal weight, which results in velocity swapping). In practise from actually playing the game, we feel that this low physical accuracy is not important. Though we can engineer situations where behaviour feels non-natural, actual game-play feels very natural.
Our project is very safe. It is not in control of anything that is life-threatening. The most hazardous issues that could arise are the standard safety issues with all video games: If people play for too long eye-strain could occur. Similarly if people with predispositions toward epileptic seizures play our game, such a seizure could be triggered. Though these risks are in large part beyond our control, we have taken steps to minimize their occurence. Epileptic seizures are perhaps the most unlikely, as they tend to be triggered by very flashy and colorful sequences. As our design is black and white, and moves very smoothly, it does not qualify as high risk in this regard. As far as eye-strain and other problems from extended use, we feel that while our game is very fun to play, we do not see people spending hours playing it. Were we to actually distribute this game, we would place a warning to not play for more than half an hour at once.
To the best of our knowledge our project does not interfere with other projects to any appreciable degree. We have no elements whose intention is to radiate power. Though some power radiation is inevitable from any electronic design; in our case, we feel this is negligible.
We feel that our design is very usable. All options are very obviously labeled and feature an intuitive interface, with instructions on how to proceed. Gameplay is also very intuitive. During development, other students (or lab TA's) would come by and start playing our game with little to no instruction on our part.
Our results matched pretty well with our expectations. When we started out, we wanted to make a game that involved balls bouncing each other out of a playing field. We successfully achieved this. In truth we were afraid that our design was too ambitious and that we would have to scale back, or that the entire playing dynamic would not work out very well. Were we to restart this project with what we know now, we would start coding with a clearer idea of what the microcontroller is capable of. In this project, we started coding for the least acceptable project. When it came time to expand our project, it was needlessly complicated to do this because we did not leave an expandable base to build upon. I speak specifically about moving from a two player game to a multi-player game, where a big change was from variables named for player 1 and player 2 to variables based on arrays with the player number as index. Our current project can be expanded from 4 to N number of players by increasing the value of a define, specifying where the input for those controllers comes from, and specifying an initial position for that player.
As mentioned above our design does not conform completely to NTSC (RS-170), but instead follows a modified version made by Professor Land. It conforms to within the tolerance of a TV to enable our game to be viewed as designed.
The only code we used which was not our own was Professor Land's video generation code, which was provided for our free use for this class.
Though we claim to be inspired by the MonkeyBall series of games, our gameplay mechanics are sufficiently different to be infringement free. One issue could be that our title screen displays the name "MONKEYBALL 0.1". Since MonkeyBall is a trademark of Sega and Nintendo, how we can use that name is defined by the Fair Use legislation of the US. In particular, since in the context in which we display this title, it is clear that the term is used as self-disparagement: a mocking claim to be a pre-release version of a popluar 3D console game. Since the only people who will see this are ECE476 students and staff and our friends, there is no chance that it will be mistaken for property that belongs to Sega or Nintendo, thus not violating Fair Use. Were we to actually distribute this game, we would very likely have to change the title to avoid confusing people.
We do not believe our design is sufficiently innovative (or profitable enough) to patent, as we have not done a thorough search for prior art for this type of game.
From the IEEE code of ethics:
to accept responsibility in making engineering decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment;
We have been forthcoming about all hazards involved with our product.
We have minimized the risks asociated with it, and have made clear every danger
we believe could arise from its use.
to avoid real or perceived conflicts of interest whenever possible, and to
disclose them to affected parties when they do exist;
We have designed this project with two and only two goals in mind: two earn a decent grade in ECE476, and to have fun. We do not believe these goals to be in conflict. Thus our responsibilities to the course staff have been met without consideration for any compromising interest.
to be honest and realistic in stating claims or estimates based on available data;
Everything we have claimed is this report or in other locations about this game is true. We have not misrepresented our accomplishments or failures.
to reject bribery in all its forms;
We have received no compensation for this design other than our contractual compensation in the form of a final grade.
to improve the understanding of technology, its appropriate application, and potential consequences;
Through our discussion with friends, we have increased the understanding among non-technically oriented people of the capabilities of the technology used in our design.
to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations;
As the pupose of this project was training, the previous portion of the semester has prepared us to be technically competent to execute it. Through this project we have enhanced our embedded design skills.
to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others;
We have been very open during the development process to the criticisms of others. When others clearly saw that our input was inelegant and prone to error, we adjusted our input to a comfortable Sega Genesis controller. When approached by others for comment on their work we have given suggestions and helpful advice.
to treat fairly all persons regardless of such factors as race, religion, gender, disability, age, or national origin;
We ourselves are diverse group of people. We look forward to having people of any race, religion, gender, ability, age, or national origin play our game. We look forward even more to beating them.
to avoid injuring others, their property, reputation, or employment by false or malicious action;
We have displayed no malice in our actions in the lab. We firmly follow the adage: if you can't say anything nice, don't say anything at all.
to assist colleagues and co-workers in their professional development and to support them in following this code of ethics
We have encouraged and continue to encourage all fellow ECE476 students to abide by the principles in this code of ethics as it is to the greater good of all, so to do.
| Part |
Quantity | Unit cost | Actual cost |
| Atmel Mega32 CPU | 1 | $8.00 | $8.00 |
| 16MHz crystal | 1 | $0.62 | $0.00 |
| 330 ohm resistor | 1 | $0.01 | $0.00 |
| 1k resistor | 1 | $0.01 | $0.00 |
| 75 ohm resistor | 1 | $0.01 | $0.00 |
| DB9 connector (male) | 4 | $1.49 | $5.96 |
| Sega Genesis controller | 4 | $5.00 (estimated) | $0.00 (we previously owned the controllers for a Sega Genesis system). |
| Total | $13.96 |
We worked closely together throughout the project, so that we could agree upon decisions more readily and discuss problems as they came up. Although we worked together most of the time, both of us did make a few specific contributions to our project.
James worked primarily on the majority of the software code and devised the majority of the software functions and algorithms we needed while the two of us were coding together. James also found time to purchase the DB9 connectors we needed from Radio Shack, and soldered wires to the DB9 connectors to make it easier to plug in our controllers. In addition, James helped out with the hardware setup and project documentation.
David helped to proofread the code while the two of us were working together, and offered suggestions for gameplay that we wanted to see in our project. David found time to research how we could setup the Sega controllers, and brought back four Sega controllers from his Sega Genesis system back at home. David was also responsible for directing documentation, and taking pictures of our project setup.
Atmel Mega32 data sheet:
http://instruct1.cit.cornell.edu/courses/ee476/AtmelStuff/full32.pdf
Professor Land’s video generation code:
http://instruct1.cit.cornell.edu/courses/ee476/video/index.html
http://instruct1.cit.cornell.edu/courses/ee476/video/Video32v2.c
Sega Genesis controller setup:
http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2003/mbc23/HardwareDesign.htm
Monkeyball for the Nintendo Gamecube:
http://www.nintendo.com/gamemini?gameid=m-Game-0000-617
http://dvd.amiga32.com/gamecube/supermonkeyball/supermonkeyball.htm