Graduate from Cornell Video Game Using Atmel Mega32

1 Introduction:
1.1 Project Summary
For our final project we implemented a Graduate from Cornell video game that puts the user through three challenges (one for each year of an accelerated three year program) which they must complete to earn credits toward graduation.  Our original plan was to simulate a typical four year program but memory constraints forced us to cut out a year.  The number of credits earned decides the fate of the user, whether its graduating with a Masters Degree or transferring to another school.

We decided to create this video game because we thought it would be something we could enjoy for years to come.  We envisioned ourselves playing the game a few years from now and having a chuckle at the small inside jokes only a Cornell Graduate could appreciate.  Since this is also our last year at Cornell, the game is also somewhat symbolic of our personal struggles to graduate.  But mostly its for our entertainment.
2 High Level Design
2.1 Rationale of Project
When deciding on a final project idea, we both agreed that we should try to find something more software oriented since neither of us has had much experience with hardware design.  We toyed with the idea of creating an electric keyboard since we are both interested in music but wanted to be able to express more creativity.  We also wanted something we could easily and cheaply make two of so we could each take something home at the end of the year.  Once we started thinking about possibly implementing a video game, we decided that it would be better to actually create something new since we could easily buy already existing video games.  The idea of a Graduate from Cornell video game was jokingly suggested and the more we thought about it the more we liked the idea.  Thus, we finally settled on a project idea that was creative, original, and required little hardware knowledge to implement.
Once we agreed upon a project, level ideas were quite easy to come by.  We both graduated from Cornell University with Bachelors in Electrical and Computer Engineering so we knew of small challenges that could easily be converted into video game format.  The four large challenges (language barriers, finding your advisor, keeping up with Delchamps, and balancing projects) became our four main levels.  Ideas on how to format each level came from games that are currently in existence such as tag and Dance Dance Revolution.
2.2 Logical Structure
The basic structure of our design is actually quite simple despite the fact that it appears to be complicated at first glance.  We begin with an overall state machine that controls the flow of the game from one level to another.  Inside each different level lies another state machine that controls the flow of that level.  Each level starts by displaying directions for game play on the screen and then progresses through initialization, game play, and an end screen.  Once each level is complete, the state for the overall state machine is incremented so the user can progress to the next level.  To make coding and debugging easier for ourselves we divided our code into separate .c files one that contains the main function and graduation functions, three that each contain a different level and its respective functions, one that contains all the video functions, and one that contains all of our flash variables. See Appendix A for our code listing and Appendix B for schematics of our state machines.
2.3 Hardware/Software Tradeoffs
To keep our stress levels down, we decided to use the Atmel Mega32 CPU that we had used throughout the semester.  This was a big time saver because it would let us reuse the video code provided by Professor Land and it meant that we did not have to learn to use a new piece of hardware.  Unfortunately this decision led to severe limitations on game sophistication due to a lack of memory.  We simply were not able to include everything we wanted (four main levels along with some fun transitional screens).
We also decided to do all of our coding in C rather than assembly since we had a lot of code to write and using assembly would have slowed our progress drastically.  Unfortunately, this placed great restrictions on us in terms of timing.  Creating stable video images requires all calculations to be done in a rather short amount of time.  With most of our code in C, fewer commands (compared to assembly) could be performed at calculation time.  This forced us to split our drawings between two to four frames to avoid video problems.
One final tradeoff was our decision to optimize for speed rather than size when compiling our code.  This allowed us to perform more tasks in each frame but cut back considerably on the amount of memory available to us.  We tried to optimize for size when we started running out of memory but our video images started to flicker.  We could have solved this problem by going to assembly or creating more frames for drawing but we decided to just cut back on game sophistication to save time and memory.
2.4 Design standards
Since we will be using a black and white television, we will need to follow the EIA RS170 and NTSC video standards.  As we learned in class, EIA RS170 is a standard that is used for generating black and white video signals for televisions in the US.  It specifies three different voltage levels (sync, black, and white) along with two sync pulses for horizontal and vertical alignment.  The voltages levels we will be using come from a slightly updated version of RS170.  These levels are sync=0V, black=0.3V, and white = 1.0V.  The NTSC standard details how the video signals will be used to create pictures.  It specifies 525 lines per frame and a frame rate of 30 frames per second.  To reduce flicker, it uses an interlacing of the 525 lines that displays first the odd lines then the even (odd field then even field).  We will use a modified version of this that has 100 lines in each field and displays each line twice.
2.5 Intellectual Property
While we doubt anyone has created a graduation based video game such as ours, there are many elements inside the game that do have copyrights and trademarks.  Obviously all of the songs that we use are most likely copyrighted and we use a phrase that has been trademarked by McDonalds.  Hopefully this will not be a problem if we give credit where credit is due and dont claim that the songs and slogan are ours.
3 Program/Hardware Design
3.1 Program Details
To create the word scramble, we first needed to decide on a topic to choose our words from.  Since we have both had trouble understanding our math T.A.s at some point during our Cornell career, we selected Math 192 as our representative class.  From there, we were able to create an array of 20 words to choose from.  At the beginning of each word scramble, a random number is generated that serves as the index into our word array.  A check is done to ensure that the selected word has not been used.  If it has, the random number is incremented until it indexes a word that has not been used yet.  Once a word is finally selected, the index of that word is stored in an array of used words and the word itself is stored an array called wordSelected.  Next, the letters of the word are scrambled and stored in another array (wordScrambled) which is blasted to the screen.  Game play can now begin.
As the user presses the left and right arrow buttons, the cursor position (box around the selected letter) is incremented or decremented as appropriate to move the box.  Once the A button is pressed, the selected letter is stored into the next index of wordGuessed.  To allow for backspaces, the index of the letter in wordScrambled is also stored.  This allows us to retrieve the last letter selected and place it in its original scrambled position when the B button is pressed.  When the B button is pressed, the last letter to be displayed on screen is also removed from the screen and the wordGuessed array.  Finally, when the C button is pressed, the letters in wordGuess and wordSelected are compared.  If they match a message stating that the word is correct is displayed on screen.  Otherwise, the word incorrect is displayed.
The heart of Thumbelina Tag lies within the low-level A.I. we programmed into Thumbelina himself.  This is what allows Thumbelina to avoid the student and make the level more interesting.  To make things easier for ourselves (and probably for game users), we force Thumbelina to move along a specific path through Phillips.  To make the game less predictable, we also selected several decision points at which Thumbelina can change his direction based on the student’s general location.  It is up to the student to find ways to trick him into taking a path that will allow him to be tagged.  The student can also move slightly faster than Thumbelina since it was nearly impossible to catch him otherwise.

In order to catch Thumbelina, the user must use the arrow buttons.  At each button press, an imaginary line is created that is perpendicular to the direction the user wants to move.  We then check to see if there are any obstacles that cross that line.  If there aren’t, the student moves one step in the desired direction.  For example, if the user presses the up button, an imaginary horizontal line is created above the student’s head.  If any of the pixels in this line are white, an object resides there and the student is not allowed to move.  If all the pixels are black, his path is clear and the student moves up.  Once the student is within a specified distance from Thumbelina, he “tags” Thumbelina and the level is completed.  For every 5 seconds that Thumbelina averts the student, one credit is subtracted from the student’s possible level credits.

parts List:

 
For more detail: Graduate from Cornell Video Game Using Atmel Mega32