Practical Assignment CG 2

Let's play squash

In this assignment you are asked to simulate a squash game in 3D, where the players, the terrain and the ball would be instances of different classes.

The terrain class

The minimum terrain should be composed of a rectangular ground and one wall. A typical terrain would be more complex (2, 3, 4, 5 walls). The definition of the terrain include a "launcher" which initialises a ball's position, speed, and acceleration (earth gravitation by default) located in the middle of the wall at a height of one meter and pointed in such a way that the ball should be at a height of 1 meter when reaching the centre of the terrain. If there is more than one ball on the terrain, they are sent FIFO (First In First Out) at a 5 seconds intervals. If a ball reaches the outside of the ground it should be put back in the launcher queue.

When the terrain receives the position of the ball it checks by itself if there is a collision (a ball should always remain on the same side of a wall). If a collision is detected, it informs the ball and specifies the point of impact, the normal to the plane and a kinetic energy reduction factor, the value of which depends on the surface (0<value<=1).

Initial value of position of the thrown balls should be an easily accessible parameter of the terrain (constructor parameter for instance).

For a simple terrain, it should be possible to specify the following parameters : the size of the ground, and the height of the walls. Then you should be able to ask for up to 4 other walls, which will appear successively as the right wall, the left wall, the ceiling and the back wall.

The balls

A ball should know its position, speed and acceleration and should send this information to the terrain and the players every frame).

Each time a ball receives the information about a collision (point and normal and energy collision factor) from the terrain or the players, it should compute its new velocity and immediately send its resulting change of behaviour.

One of the ball parameters is the percent of kinetic energy the ball will lose after each collision with the ground or the walls or the racket. In fact the change in Kinetic energy (and therefore in speed) is defined both by the ball (loss of energy) and either the racket (gain of energy) or the wall (lose of energy) and the resulting effect is calculated by the multiplication of the two factors :

Effect = BallLost * WallLost or Effect = BallLost * GroundLost

or Effect = BallLost * RacquetGain (it will be either a lost or a gain)

And the relation between the square of the speed, before (v) and after (v') the collision is given by v'2 = Effect * v2

You should check that 0 < BallLost <= 1 ; 0 < WallLost<= 1 ; 0 < GroundLost<= 1 (a value of 1 exists only in perfect materials)

and 1 <= RacquetGain <= 10

If the total energy (kinetic+potential) of the ball is close to zero, it should be put back in the FIF0 launcher queue. ( E = 1/2mv2 + mgh).
If the ball goes to far away from the terrain (because it didn't touch any walls, it will be brought back into the FIFO launcher queue.

The players

When launching a racket/player, you specify the size of the racket in centimetres (between two limits chosen in order to match the possible speed of the racket), the colour of the racket, and the set of keys to manipulate the racket. If the colour has already been chosen, then the next available one will be attributed automatically (amongst a predefined list of possible colours).

The default controls for the first two players :

Move Left player Right player
Toward the main wall
W
 8
Backward
S
 5
Left
 A 4
Right
 D 6
Up
 Q 7
Down
 E 9
Positive rotation around x axis
 C O
Negative rotation around x axis
 V P
Positive rotation around y axis
 B [
Negative rotation around y axis
 N ]

Each player is represented by a square or disc racket ( the display look could be different, but the collision detection will be done against a square or disc surface, whatever you chose).

The bigger is the racket, the slower it can be move (Width x Speed = Constant)

When the racket receives the position of the ball, it checks by itself if a collision has occurred. If yes, it informs the ball and specifies the point of impact and the normal to the plane and the gain in kinetic energy ( 1<= gain <= 10) which is proportional to the speed of the racket (to simplify this, just assume that this is a constant depending directly on the size of the racket, and proportional to its speed).

For the direction and the speed of the ball after a collision, you should implement at least the "Mixed Treatment" of the "Generic 3D Ball Animation Model for Networked Interactive VR Environments" paper. The "Physical response" (taking into account the direction of the racket) would be a plus but is not compulsory.


Collision (if detected, Pafter will become Pintersection)

No Collision (this situation should be detected quickly)

One should be able to move the racket along the 3 translations (x, y , z) and to rotate it around the two axis parallel to the main wall. So 10

The game

The Game class is the 3D representation of the game. I will let you chose if there should be still another class to represent the 2D interface (just explain your decision in your REAME file). The idea is that there should be a class that will take care of organise the launching of the game (attribution of colours, set of keys,...), and take care of the organisation of the time in such a way that every class gets the time to do whatever it needs to do (event loop).

Ground Rules for all projects: 

To submit a project ...

you should put altogether, in a directory called 02CGA2_UstudentID1_UstudentID2

(Where 'studentID1'... your student ID !)

Here is its README.html file template

Use the jar command to put your directory into a single jar file based on the same name and mail this file to pascal.vuylsteker@anu.edu.au

cd .. (go to the directory in which 02CGA2_UstudentID1_UstudentID2 is located)
jar cvf 02CGA2_UstudentID1_UstudentID2.jar 02CGA2_UstudentID1_UstudentID2/

Mail the file (02CGA2_UstudentID1_UstudentID2.jar) as an attached document. Be sure that the title of your mail is '02CGA2_UstudentID1_UstudentID2.jar'

!!! Your jar file should not be more than 750 kB !!!

The minimum requirements

Your project should be composed of, at least, the following :

(1) A set of at least 4 to 6 well balanced large classes (there could some other small ones). Think about it in term of reusability of the code, and allocation of the work between members of the working group.

(2) One public class, whose name will be "Assignment" and that will contain the "main method" in such a way that, to test your project, I will only need to call 'java Assignment [command line arguments]' to run it. Because yours classes will be well documented, I should be able to write that "Assignment" class by myself without to much work. That means that the aim of that class is just to get and treat the command line arguments and launch the main one(s).

(3) You will explain the use of the arguments in your README file but the 2 first one will be

E.g. : java Assignment numberOfUsers numberOfBalls

With default values : 2  and 1

(4) When you write down "java Assignment -h" or "java Assignment -?", you are expected to receive a user's manual (an extract of your README file ?)

(5) Remember that sometime, users may be dumb and may not use the right number of arguments, nor the expected argument

(6) Your main classes should not have references to the com.sun.j3d.utils package. If you really want to use theses packages, you should encapsulate their use into some of your specific classes. You will then be able to use your personal specific classes in your main classes

(7) the usual comfort of an interface is the resizability of the main frame and the fact that the frame is well dimensioned and placed inside the display screen at the start.

(8) The scene should contain a background object and a horizontal plane.

(9) Your code should be well commented and presented (extracted comments for the documentation and some insides comment whenever there is an algorithm to comment.

(10) The main window should display the squash court from its back, looking at the main wall

(11) The second window (or 2D part of the main frame, whatever you chose to implement) will contain the GUI to allow you to start a new game (after changing the number of user/ball/walls) and to change the keys attributed for each users moves

(12) The compiled classes should be available at the root of your directory. During the marking process, I may :

(Not So) Optional Development:

You should do at least two ( 2 ) of theses options to get the maximum mark.

1) ViewPoints

At least two different other viewpoints amongst the following ones, rendered in another frame (we should have simultaneously : the main canvas3D with the "from behind" viewpoint and a second canvas3D where you should be able to switch between the additional views)

2) Shadowing

In order to improve the playability of the game, you should  add two "shadows" for each moving object (balls and rackets). One shadow will represent the position of the object on the floor and the other one on the main wall. They are projection of the object on those planes.

PS. : A additional option to this option (does not count in the mark : you do it only for the fun) would be to propose an additional helper that will display racket's orientation.

3) Computer play

You may decide that some (and sometimes all) of the players will be directed by the computer. You should include some different parameters for each computer player, and adjust the characteristics in such a way that the computer may lose (except if you chose the "invincibly set of parameter").

4) Physical modeling for the ball

Ball lifting : take into account not only the position of the rackets and its speed, but the orientation of its speed, and add a spinning characteristic to the ball, defined by a rotation axis and a rotation speed). Any collision (wall or racket) will have an effect on the Spin (change in speed and direction), and will be effected by this spin (the reflection won't be anymore of the same angle, in the same plane).You will have to well explain your physical model, both in your java comments and in the README file.

5) Mouse

One of the players should be able to use the mouse to move its racket (horizontal movement of the racket).

6) Real Squash rules

Addition of the official squash rules and score. I don't give you those rules here, but I've have some specialists around here who will be able to confirm for me if you have used the correct rules. In that option, you will have to display correct border lines on the walls, and check where and when the ball rebound occurs (You could for instance use a Finite State Machine to describe the rules). Again, document the rules in your README file.

7) Sound feedback

Each time a collision occur, one should hear it.

8) IVR

Do the internetworked VR assignment : Make the game be playable over the net (See the specification of this assignment within next week, on the IVR Web page). This option is of course not a valid one for IVR students !!! (nor for the group that will work with Shaun Press).

9) Wedge

An implementation of that project that would be usable on the Wedge (i.e. that uses the Tiwi package).
If you want  to do that option, you should tell me quite early in order to get some allocated time on the wedge computer.