Press, Carl
Math 198 &G1
Progress Report I
04/07/04

Thus far, the greatest challenge in creating Illipong has been to
understand the collision detection that will be involved in the game's
design.  This in combination with Steve Kommrush's hcube will be the
the basis for which the game operates on.  After I reached a thourough
understanding of these two things, I was able to formulate a list of
ideas and functions that will be needed in Illipong.

First, I need to design an object in Open GL/GLUT that will act as my
paddle.  Essentially, I will design a paddle object, which will occupy
one entire surface of my game cube.  Within this paddle object, I then
need a paddle, which will be able to move in 2 dimensions anywhere
within the paddle object's scope and will function like a wall in terms
of collisions with the wiresphere (ball) that will be used for game
play.

 Next, I need a function that will differentiate the behavior of
 interactions between the ball and the paddle object depending on which
 portion of the paddle object the ball hits.  For all portions of the
 paddle object that are not the paddle, interactions between the ball
 and the paddle object will result in a loss of turn.  However,
 interactions between the ball and the user-controlled paddle will
 essentially be the same as interactions between the ball and another
 surface of the cube.  In designing Illipong, the topic of infinite
loops is one that should be dealt with.  There is a possibility (though
due to the nature of the design of the game and the the computers being
used, a very small possibility) that the game ball will fall into a
continuous pattern of collsions with the paddle and the walls of the
cube.  To correct for this, I am creating an addition to my paddle
object.
 The behavior of interactions between the ball and the edges of the
 paddle itself will be slightly different than being just like
 collisions of the ball against the wall.  Rather than reversing only
 the component of velocity that is causing the collsion, I will reverse
 all components of the ball's velocity upon these "edge" collisions.
 This will give the game user the ability to break such continuous
 loops.  Once these basic game issues are addressed and the game is
functional in 3-dimensions, the extension to 4, and eventually n
dimensions can be made.  This extension would involve adding more
components of velocity and position to the pos and vel arrays (this
value of the # of dimensions desired  will be a predefined macro, whose
value needs to only be changed once to enforce the change throughout
the program).

Within the next two weeks, I hope to have most of, if not all of these
basic functions and objects created that will allow the game to run in
3-dimensions.  I then will go back and manipulate Kommrush's hcube as
well as the program itself to add more dimensions to the game as well
as allow gameplay with multiple balls at a time.  This requires
collision detection between two balls, such as in the program "bnc1."