For example

							                                                                 10-1


                    CATAPULT CHALLENGE



                          Final Report



                          Submitted to

             The Faculty of Operation Catapult LXIII

              Rose-Hulman Institute of Technology

                      Terre Haute, Indiana




                               by

                           Group 10

John Allen                          Moline High School
                                    Moline, Illinois
Emanuel Coker                       Germantown Friends
                                    Philadelphia, Pennsylvania
Martin Pendergast                   Taylor High School
                                    Kokomo, Indiana

                         June 29, 2007
                                                                                                10-2


Introduction

        In order for someone to be an effective translator they have to spend years learning a
second language while continuing to be proficient in their own. This process may not be as long
for someone wanting to learn a computer language, but some popular languages such as Java,
C#, and C++ take a fair amount of time for someone new to computer programming to create a
simple game. The reason for this is that these languages are somewhat complicated, and so the
beginning programmer has issues with learning both basic programming concepts and the syntax
of the language. At Rose-Hulman it has been hypothesized by a committee headed by Professor
Claude Anderson, PhD, that Python is an alternative language that may be easier for beginners to
learn in a short period of time, while having enough power to accommodate experienced
programmers. To test this theory our group as well as one other was given the assignment of
creating a computer game after a four to five day instruction period at Operation Catapult. Our
group consists of two members who have absolutely no programming experience and one
member who has experience in C and some experience in QBASIC. With this group of three we
were able to implement a relatively advanced game while gaining a great deal of knowledge.
        Catapult Challenge is a game that is based on an older game called Artillery, where two
players enter velocities and angles to fire at each other. The goal of Artillery was to hit the other
player. In our game, a single player enters a velocity and angle to fire at a picture of one of the
camp counselors (a screenshot is shown below).
                                                                                                 10-3


        Python is easier to learn than other languages because it is „weakly typed‟, that is, the
language will make assumptions based on how one uses their variables (implicit definition of
variables), so that the user does not have to know as much about his/her data to use it. It requires
less effort to learn the syntax of the language, as it is designed to be readable. All of this allows
the language to be easy to learn, so someone new to programming can learn to work with
computers before learning a more complicated language.

The Graphics Package

        The four to five days of instruction that we received mainly focused on learning the
graphics package as well as learning how to use objects, classes, and methods. The graphics
package was written by John M. Zelle in Python. It is beneficial because a beginner to
programming can use it and get some things done fairly quickly (i.e. our game). The downside to
the graphics package is that it is very limited; for instance, once a user tries to animate too many
things, the graphics get rather jerky. Even with these distinct limitations, the graphics package
created by Zelle has proven itself by having simple functions to create simple geometric features
and animate them to some extent.

Project Tools: Objects and Classes

        When trying to create more complicated features with more complicated functions, the
programmer must now create what is called an object. An object is something that a user can
easily use without knowing exactly how it works. For example, in the physical world an
example of an object would be an mp3 player. Most people do not know how such a device
works, but the majority of Americans do know that if they press the play button music will
emanate from the earphones. In our program the catapult and water balloon are such objects,
because the user knows that that they can pick a certain angle and velocity to fire the water
balloon, but they do not know why it fires, other than the fact that they are pressing the “fire”
button. To create objects such as these one must create a class. A class can be described as a
blueprint that describes how something (i.e. an object) works. Then, a programmer can then add
methods to that class so that it knows how to behave. For instance, to create the catapult class,
our group had to tell the computer the overall dimensions of the catapult. We also had to place
the catapult by representing its coordinates as a function of the total screen size or a function of
the size of an object that was already placed on the screen. Once this was completed it was
necessary to create some methods for the catapult. One such method was to tell the computer
how to animate the lever arm when the catapult was fired. All of this was done in the class so
that the catapult could be referred to as one object, even though it was created in parts. A more
in depth look at this process will be described later. Using the graphics package in conjunction
with the principles that were taught helped to enhance the program that was created in a small
window of time with little experience.

Managing Variables and Constants

       The next thing we focused on was writing a program that had to be coalesced from
individual files while it was being written by different people. To combat confusion we tried to
avoid using numbers in our program; for example, rather than having the dimensions of our
                                                                                               10-4


catapult height of four „feet‟ (forty pixels, so a foot is 10 pixels) and a catapult width of eleven
feet, we defined two variables catapultHeight and catapultWidth to be four and eleven
respectively. This also worked well for graphic objects such as the ground that would change if
certain elements of our program were changed; for example, if instead of defining the ground as
twenty feet by 100 feet, we decide that these dimensions are accurate for the present screen size,
we can instead define the dimensions of the ground as screenHeigth/20 and widowWidth. We
decided to use this idea throughout the program to make sense of various constants. Another
reason why using names instead of numbers is good is because it prevents one member of our
group from, for example, representing the length of the catapult arm as five feet, when a different
member makes the length of the arm six feet, causing an error. It also forces us to take time to
unify variable names and thus communicate within out project group. After repeating this
process several times, we decided to compile all of our variables into a separate python file; this
allowed us to access and change information anywhere in our program. With this process we
saved vast amounts of time because at most only one or two numbers need to be adjusted to
make changes.

Game Mechanics

        There are several important components needed to make the game work. The game was
broken up into individual parts and each group member was assigned specific tasks. Then after
one part was finished it was added to the larger program and modified until it functioned
correctly within the whole program. Three of these parts were the physics (i.e. gravity and
motion), collisions, and the movement of the catapult arm.

Game Mechanics: Catapult Arm

        To move the catapult arm at the correct speed we had to utilize the module „time‟ and the
undraw method for lines. To animate the catapult, the program had to repeatedly draw and
undraw the arm until it (the arm) reached a set angle (perpendicular to the launch angle of the
water balloon); therefore, the more frequently the arm was drawn within this angle the longer it
took to finish the animation. Therefore, on a higher velocity provided by the user, the arm will
be drawn fewer times to create the effect that the arm moves faster, imparting greater speed to
the water balloon.


Game Mechanics: Physics

        Writing the physics and motion code for this game was very straightforward, as only one
object would be moving at any given moment. The water balloon object had a field (variable)
that would keep track of its own velocity (broken down into x and y components to make the
program more simple). From the time the water balloon was fired until the time it collided with
something, a loop would run. In this loop, the ball would move to the right by the x component
of its velocity, and move up by the y component of its velocity. In that same loop, the value of
gravity would be subtracted from the y component of the balloon‟s velocity.
        The motion system we used caused one major difficulty: if the balloon is fired at a high
enough velocity, it will travel by large jumps across the screen. This can cause problems when
                                                                                               10-5


the balloon is drawn on one side of the target, then on the next cycle is drawn on the other side,
creating the appearance of a collision, while never detecting one.


Game Mechanics: Hitboxes and Collisions

        Hitboxes are invisible boxes around an object that allow those objects to participate in
collisions. Specific to our game, the water balloon and the image object have hitboxes to
calculate collisions (collisions with the ground and the side of the window are measured
differently).




        There is one major downside to putting a hitbox on a round object- there is an amount of
„solid space‟ in each corner of the box, which, although it has no visible elements, will still
interact with other hitboxes.
                                                                                                 10-6


        In our game, this is not a major issue, because the circle is small, and so the solid space in
its hitbox is negligible.


         Our algorithm for detecting collisions is fairly straightforward, and could easily be scaled
to three-dimensional applications. It checks each side of a hitbox to determine if it has passed
the opposite side on the other hitbox (e.g. it compares the location of the left side of one hitbox
to the right side of another). If one side has passed the opposite side of the other hitbox, then the
algorithm finds that a collision is impossible. In the two-dimensional version of the code, the
algorithm only has to perform four checks. If all four checks indicate that a collision is possible,
then there is a collision, and the algorithm sends a True value back to the program that was using
it.

def check_collision(box, circle):
     box_left_bound = box.p1.getX()
     box_right_bound = box.p2.getX()
     box_lower_bound = box.p1.getY()
     box_upper_bound = box.p2.getY()
     circle_center = circle.getCenter()
     circle_left_bound = circle_center.getX() - radius
     circle_right_bound = circle_cetner.getX() + radius
     circle_upper_bound = circle_center.getY() + radius
     circle_lower_bound = circle_center.getY() - radius

       collision_count = 0

       if box_left_bound < circle_right_bound:
            collision_count = collision_count +                         1
       if box_right_bound > circle_left_bound:
            collision_count = collision_count +                         1
       if box_upper_bound > circle_lower_bound:
            collision_count = collision_count +                         1
       if box_lower_bound < circle_upper_bound:
            collision_count = collision_count +                         1

       if collision_count == 4:
             return True
       else:
             return False


Game Mechanics: Button
        Vital to the user-friendliness of our program was the button. Python has no built-in button
object, so we had to make one of our own. The information that the constructor needs includes
the text that is written on the button, the coordinates of the lower-left corner of the button, the
length and the width of the button. Inside the class, the button is made of a rectangle object and a
text object. The class also has a method to check if the button had been clicked; the method was
                                                                                              10-7


a modified version of the collision code. The button class is fairly adaptable. We adapted this
code to create a hidden button that can be set to select a specific counselor. We also gave a copy
of a code to another project group so they could have buttons in their game.

Future of the Project
        There are many logical extensions of the game. One extension to the game within Python
would be to improve the collision code to eliminate „solid‟ space. Another major extension
would be to improve the motion code to prevent the balloon from jumping over the target.
Porting it to a faster language, like C++ or Java, or implementing a faster graphics package,
would also improve the game. Another ideal modification would be to give the game educational
value (like including relevant physics equations in the instructions, and giving the coordinates of
the target in the game). It could also be made into a two-player game with network or Internet
functionality.