Karthik Karkala (kck23)
Vijay Paruchuru (vkp4)
ECE 476
Scorched Earth: The
Mother of All Games
Table of Contents
Rationale,
Sources, and Hardware/Software Tradeoffs
Patents, Copyrights, and
Intellectual Property
Safety, Interference, and Usability
Conformity
to Applicable Standards
Intellectual property
considerations
Introduction
For our design project, we decided to replicate the video
game known as “Scorched Earth: The Mother of All Games” where two tanks fire
missiles at one another by adjusting angles and power while adjusting for
variable wind.
The
objective of Scorched Earth is to destroy the enemy tank before your tank is
destroyed. Two tanks are randomly positioned on their respective sides on
a randomly chosen terrain. Through a trial and error process of adjusting
angles and the strength of the tank’s turret, each user can manipulate the
trajectory of the bullets to eventually target the enemy tank. With three
different weapons of different blast radii and three unique difficulty levels
that incorporate variable wind speeds, the users can test their abilities as the
most accurately firing tank. We wanted
to recreate this game to allow players to relive childhood memories.
High Level Design
Rationale, Sources, and
Hardware/Software Tradeoffs
The foremost reason we chose to simulate Scorched Earth
was because no one had recreated this game as a final project during past
years. Furthermore, we wanted to create
a video game because we would not have any limitations within our budget
regarding additional hardware. Since we
do not have many sources for additional parts, an advantage that other groups
possessed, a project that consisted entirely of code would allow us to make a
project that was still fun and still extremely complex and challenging. The necessary hardware to run our project was
simply the digital to analog converter circuit that displayed our program onto
the television. After completion of the
project, we also added sound (a pitch that gradually decreased as a bullet was
in motion), which required very simple circuitry that also connected to the
television.
Background Math
We originally had other video game ideas in mind, but
with the help of fellow ECE and housemate, Brandon Richter, we rediscovered
this particularly entertaining game that immediately found its way to our
hearts. During the brainstorming
processes of recreating this game, we basically decided to implement everything
that we successfully completed. We
wanted to randomly draw terrains at the start of each game; however, this would
have been too complicated since our code was dependent on the arrays of
previously created terrains.
Logical Structure
Upon starting the game, a startup screen displays a
sample terrain and the two tanks as normally seen during an actual game. “Scorched Earth” and a difficulty of “easy”
as its default setting are also shown on the screen. By pressing the debounced button C.6, the
difficulty levels rotate from “easy” to “med” (medium), “med” to “hard”, and
then “hard” back to “easy”. An easy
difficulty level has zero wind effect on the bullets during the game, while a
medium difficulty level has a constant wind throughout the entire game, and a
hard difficulty level has a variable wind after both players have completed a
round of firing a bullet.
To begin the game, the user must press C.7 to clear the
screen and display a randomly chosen but previously created terrain. Player 1’s tank will always be located on the
left half the screen while player 2’s tank will always be located on the right
half of the screen. Along the top of the
screen is an information bar that displays which player’s turn it is to fire,
the power of that player’s shot, the angle at which that tank’s turret is
pointing, the weapon chosen, the number of remaining shots of that weapon, and
the speed and direction (east or west) of wind.
By using buttons C.4 and C.5 to increase and decrease the angle of the tank’s
turret and by using buttons C.2 and C.3 to increase and decrease the power of
the tank’s shot, the user can adjust the trajectory of their shot. At the default setting, weapon 1 is displayed
on the screen with infinite number of shots.
Using C.1, the user can cycle through to weapon 2 or weapon 3, of which
each tank only has 3 and 1 bullets available during each game. As the user uses either weapon 2 or weapon 3,
availability of the bullets, denoted with single pixels, will decrease in
number. The user must then use button
C.6 to fire the bullet. The settings
used for the first player to go are saved and the second player can now perform
the same procedure with the original default settings that will also be saved
upon firing a shot as well.
Once a tank has been hit, a message that reads who is the
winner will show up. To play another
game or to simply see the number of accumulated wins each player has since
reset, the user must press C.7. This
clears the screen and displays the number of wins that each player has. “Play Again” is also displayed on the screen,
and to do so, the user must press button C.6 to clear the screen again and
redisplay another randomly chosen map and random starting positions for each of
the tanks.
Project Standards
The
standards that we used are the same as those in Lab 4 (
Patents, Copyrights, and Intellectual
Property
The foremost important copyright that must be addressed
is the person(s) who originally created the game known as Scorched Earth. Unfortunately, since we are not able to find the
names of those who deserve our appreciation, we can only publish the official
website for the game: http://www.classicgaming.com/scorch/. However, must also thank
Hardware and Software
Design
Hardware Design
Since our final project is a video game, our sole
hardware necessary was the microcontroller unit, located on the STK500,
pushbuttons to operate the game, also located on the STK500, and the video
digital to analog converter shown in the design schematic below. We used PORT C for the pushbuttons and PORT D
for the circuit to implement the television.
The circuit was connected was wired to the yellow connector on the TV
using clip leads and a RCA phone jack. The TV was set to video input.
Design Schematic
Software
Design
Since we were able to use Professor Bruce Land’s video generation code, all we had to do was write the code for the game and were able to use the video generation code to output all our date. In general the code was pretty straightforward to write and we didn’t have any major problems with it. Our biggest problem was timing restrictions which forced us to break up our output into multiple frames/states so that we would not get artifacts.
Start Screen
The start screen has the game name, “Scorched Earth”, and a map with two tanks as the background. At this screen you are allowed to choose the difficulty of the game. There are 3 difficulties: Easy which has no wind, Medium where wind is randomly generated but doesn’t change for the rest of the map, and Hard where wind changes after each player has shot.
Clear Screen/Draw Map
One of the trickier parts of the code were erasing the screen and drawing a new map. It took us a few tries to figure out how many lines we could draw or erase in each frame without causing artifacts to occur. We finally decided on only drawing or erasing 3 lines per frame to ensure that no artifacts would occur. We have 5 pre-generated maps that have been stored into memory of our cpu. We used a random number generator to randomize which map would be chosen. We also used a random number generator to randomize the starting location of P1 and P2.
Player Turn
We used a random number generator after drawing the maps to
randomize which player gets to go first.
At the start of the players turn, the player is allowed to change his
power, angle and weapon, and fire when he feels he is ready. The values for power went from 0 to 99, the
values for angle go from 0 to 180 and the weapon is cycled from 1 to 3. We debounced all the buttons used to
increment/decrement the power, angle and weapon. We used a timed increment so that power and
angle would be changed by one every quarter second. First we had it such that each button press
would result in a change of one, but we found it tiresome to press a button 15
times, and it was much easier just to hold the button down. And for the weapon since it was only cycling
through 3 possible values, we just decided to leave it as a simple debounced button
where each press increments the value by 1.
Also weapons 2 and 3, which are considered super weapons, have a limit
on the number of shots available. Weapon
2 only has 3 shots while Weapon 1 only has 1 shot. Once the bullet is fired the
trajectory of the bullet is calculated, how this is done is explained in the
next section. Also you are not allowed
to fire if you have no more shots left of the selected weapon.
Bullet Trajectory
First thing we did to determine the trajectory of our bullet was to divide the power of our shot into x and y components (xpow, ypow) using the sine and cosine functions. We had a start position (xpos, ypos) which was at the top of the turret of the tank and we changed these values by a factor of the power (xpos = xpos+xpow/25, ypos = ypos-ypow/25). Once we changed the position variables we changed the power variables, the xpow would be changed by a factor of wind/25 and ypow was reduced by one every frame to account for gravity. This caused us to skip a few points because at our highest power of 100 it was possible to skip 3 pixels ever frame and it was possible that our shots would skip over the top of the tank or not hit the top of the terrain but instead hit somewhere lower. In order to correct this we scaled our changes by ¼ so that we wouldn’t skip any points, for example xpos now equaled xpos+xpow/100 and xpow = xpow + wind/100 and ypow = ypow - ¼. This ensured that at full power we would only be moving one pixel, and though this increased the time it took for the bullet to travel from one point to other, it made the point of impact much more accurate. Also the xpos and ypos variables were stored into other variables (prevx,prevy) so that we know what the last position of the bullet was and delete it.
Walls
We decided to make the left and right walls absolute boundaries. If any of the shots hit these boundaries that players turn would end, we assumed that if the shot has passed the edge of the screen that it was shot too far and thus will not hit. The top of the screen however was not an absolute boundary, any shot went higher had a chance of coming back. We just stopped our program from drawing new points or erasing old points if the bullet went higher than the top of our screen, and we resumed drawing and erasing once the bullet re-entered the screen. This allows the player to take high shots to get over hills that they might be next to without worrying about hitting an absolute boundary.
End of Round
The round ends when one of the tanks is struck by the bullet. Regardless of which player shot the bullet, the player whose tank is hit loses and the other player wins. At this point we print out a message letting the players know which player has won the round. Then by pressing fire you go to another screen, where you have the option of changing the difficulty, this screen also shows the number of games each player has won. By pressing start at this screen you can start a new game. At this point all your weapons are refilled and once again which player starts is randomized.
Music
The final part of our code that needs to be talked about is the sound effects. During the shot when the trajectory is being calculated we have a note which increases in pitch every quarter second. The timebase of quarter second was achieved by using a variable to count up to 15, and since each time it increments corresponds to one frame and each frame is 1/60th of a second, the counter hits 15 at approximately quarter second. We set OCR0 to 60 and ran timer0 without interrupts enabled on a prescaler of 100, to generate our initial note and every quarter second we incremented OCR0 by 1, to increase the pitch and thus make our sound a little more realistic. Also when a player tank is hit we have a much higher pitched sound with an OCR0 starting and 195 and going to 193 in order to create a sound for three-quarters of a second to simulate the explosion of a tank getting hit. Though since I, Karthik, did the sound in my free time and am not musically talented the sound is most likely quite a bit lacking in their effect.
Challenges
As I mentioned earlier in this section we had no major
problems with this code. The only part
of the code that was tricky to figure out was trying to keep the artifacts from
occurring when our bullet crossed our boundaries. When the bullet left the top it would erase
part of the line or the last bullet location drawn would not be erased. This was a little tricky for us because we
tried to play with which point we called our boundary, this was usually the pixel
before the actual line itself, and we still ended up with the stray unerased
bullet. We finally fixed this problem
when we noticed that when we ended the turn due to the boundaries we would not
erase the previous point because we would be skipping a state when compared to
if the bullet had hit terrain. Once we
figured this out it was easy to make the change and remove the stray unerased
bullet point. Other parts of our code
such as timing constraints for drawing the map, though they weren’t tricky took
some experimenting to make sure that they were efficient.
Results
Speed of Execution
Most of our code executes with no delay. The only part of our code where you might see a bit of delay is in our drawing of the map or clearing the screen, since each of this program is divided over approximately 42 frames which equal three-quarters of a second you will see a scrolling effect when the screen is being cleared or a map is being drawn. This is the only part of the program where the desired output isn’t output to the screen all at once but instead is broken up into smaller pieces over a lot of frames, and therefore the only part where any delay recognizable by the human eye can be seen.
Accuracy
The only issue of accuracy in our program was in the trajectory calculation. Since with our original idea it was possible to skip a few points, it was not very accurate. But we changed it so that it wouldn’t skip any points and thus the point at which the bullet hit is now close to 100% accurate. However this slowed down the speed at which the bullet traveled by a factor of 4.
Safety, Interference,
and Usability
We enforced safety in our design by following the
applicable standards for NTSC rate and RS170.
By also carefully wiring our circuits and using low voltages, no one can
be harmed by our project. Players of the
game will use the pushbuttons, located on the STK500, that cause no threat to
safety. By adhering to the no food and
drink policy in the lab, we also prevented careless accidents from
occurring. Since our program was mostly
software based and we did not create any RF interference or CPU noise, our project
did not interfere with any one else. Our
project is usable by anyone who has the ability to watch a television screen
and push buttons. However, the ability
to logically determine how to win a game by firing a missile at the enemy tank
by adjusting the tank’s power and angle would also greatly help in using this
project.
Conclusion
Analysis of Our Design
We were completely satisfied with our project on all
levels. Everything that we planned to
implement within the video game was achieved: a startup screen; the option to
choose difficulties of no wind, one wind, or variable wind throughout the game;
randomly chosen terrains, tank positions, and starting player; the ability to
increase and decrease the power and angle of the tanks; the ability to choose
one of three weapons that created different blast radii in the terrain and two
of which that were limited in number; the ability to save each player’s most
recently used angle, power, and weapon settings; a line that indicated the
strength and direction of the wind; and a “Play Again?” screen that would allow
the players to change the difficulty level again. As far as we know, the only thing about our
project that we would have changed was the implementation of Sega Contollers to
play the game. This is extremely simple
and given the access to controllers and a little more time, we would have
completed this task as well.
Conformity to Applicable
Standards
As stated earlier in this report, we conformed to
applicable standards as well as possible.
The standards that we used are the same as those in Lab 4 (
Intellectual property considerations
Also stated
earlier in this report, the foremost important
copyright that must be addressed is the person(s) who originally created the
game known as Scorched Earth.
Unfortunately, since we are not able to find the names of those who
deserve our appreciation, we can only publish the official website for the
game: http://www.classicgaming.com/scorch/. However, must also thank
Ethical Considerations
1.
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;
Our video game has not impact on society that will produce any negative effects on the safety, health and welfare of the public. Given that we are using a television to display our game, we are following all protocols compliant with NTSC and RS170 standards.
2.
to avoid real or perceived conflicts of interest whenever possible, and
to disclose them to affected parties when they do exist;
If there was ever a conflict of interest between the group members, such as a difference in opinion as to what additional features should be added to the game (should missiles reflect off of the side walls), we rationally discussed our problem and reached a solution. We did not have any conflicts of interest outside of the group.
3.
to be honest and realistic in stating claims or estimates based on
available data;
During the entire duration of this project, we projected realistic goals and successfully completed those goals within our knowledge and budget constraints. Furthermore, the project as well as the report was created in the utmost honest manner
4. to seek, accept, and offer honest criticism
of technical work, to acknowledge and correct errors, and to credit properly
the contributions of others;
During the creation of our project, we sought advice from
our teaching assistant, Vladimir Kozitsky,
5.
to assist colleagues and co-workers in their professional development
and to support them in following this code of ethics.
We offered our support to other teams by offering constructive criticism and advice that would help other groups succeed. We did not break any of the rules discussed in the IEEE Code of Ethics.
Societal Impact
Our project will have a tremendous societal impact since playing this game will bring create hours upon hours of video gaming pleasures. Reliving many childhood memories is priceless. There are very few safety considerations. If we decide to encase the breadboard and the exposed wires, there will be no risk to health in any way. Furthermore, since we are using the RS170 standards with very few modifications, there is no need for problems such as epilepsy. Two humans will be able to play the game; each player will alternate firing the tank until one of the tanks has been destroyed. The user will solely need the ability to press buttons on a keypad in addition to being able to turn on the microcontroller unit and the television. The ability to make appropriately adjust the strength and angle of each shot will also help in winning at the game. The copyrights for this game have yet to be found but will be properly acknowledged soon.
Appendix
Schematics
The drawing below shows the state diagram used for our video game. Nested within this state diagram was the state diagram for button debouncing, shown later in this section.
State Diagram for Scorched Earch: The Mother of All Video Games
The following diagram illustrates the basic schema used to debounce buttons used during the execution of the game. Two of the eight buttons used are shown below, but the same basic schema was used for the remaining six buttons. We used this schema for use of the buttons while playing the game, as well as C.0 during both the startup and game over screens to change the difficulty settings.
State Machine for
Button Debouncing
Pictures
Project Setup
Title Screen
Game Screen
Win Screen
Play Again Screen
Parts List
Given our budget constraint of $40.00, we were well within our limitations, as seen:
STK500 Development Board $0.00
Television $0.00
Breadboard $0.00
Wires/Cables $0.00
Total $0.00
Specific Tasks
During the entire design of our project, we split up most our tasks equally. Once the project was complete, Karthik implemented the sound of the video game during his spare time. Since he also has more experience in programming and thus has a stronger background, Karthik was therefore slightly more responsible for creating some of the program code. However, to compensate for this, Vijay was responsible for writing a slight majority of this written report.
References
Atmel Mega32 Data Sheet:
http://instruct1.cit.cornell.edu/courses/ee476/AtmelStuff/full32.pdf
http://instruct1.cit.cornell.edu/courses/ee476/video/index.html
http://instruct1.cit.cornell.edu/courses/ee476/video/Video32v2.c
Code
//video gen and
sound
//D.5 is
sync:1000 ohm + diode to 75 ohm resistor