In this assignment you are asked to simulate a pong-like game in 2D, where the terrain, the players, the balls and the targets (any number of both of them) would be "alive" on different (or not) computers. More precisely, you begin to chose a computer where you run the terrain, then you start one or more balls and targets on some other computers just specifying the IP number of the terrain (the port number is an optional parameter for all programs), then you start one or more players (again, only specifying the IP number of the terrain) on still other computers.
The default initial port number used by the terrain will be 9000 + 10 * yourGroupID . It is known by all component : there must be an easy way to modify this parameter in your code and an option to specify it in the in the command line.
Because all of your component could be either all on the same computer or all on different ones (but sometimes more than one for each computer), you could decide that every objects will listen to the same Multicast IP, but each datagram should contain an ID that will point at a particular object, or either, that each object would listen to (or multicast to) a different Multicast address, based on the Multicast address provided by the terrain, incremented by one for each new object entering the simulation. Or something in between.
Terrain is the dispatching server.
When an object logs in (it register to the terrain using TCP/IP), it receives the physical description of the terrain (typically, its size), its initial position/orientation and speed, a colour and the multicast address that the object should be listening/writing to. Players should send their name to the terrain to get an unique ID.
Each time a new object logs in, the Terrain sends the information (IP number, colour of the object, type of object) to all other current object that need to be informed. If any object wants to know the name of a player, it has to send a request to the Terrain
The Terrain manages a list of all available components.
Each Component keep the coordinate of the terrain (in case it wants to leave the game, or wants to get more information about another component).
Each component listen to an attributed TCP/IP port number for important notices (component entering or leaving the game, from the Terrain, or Collision events from the balls/targets).
The game board is a square defined by its size and the number of its cells.
The are 3 types of entities, moving on that board : balls, target and players.
The aim of players is to hit the balls to make them hit the moving targets. When a player hit a ball, the ball take the colour of the player, until it is hit by another player. If a ball hit a target, then a point is given to the player who "own" the ball at the time of the hit.
Balls are responsible for detecting when they hit a racket. They then have to broadcast to all there change of direction (and/or change of colour). Targets are responsible for detecting collision with balls and distributing point to the players (you could imagine to give different value of point depending on the precision of the hit, this is just an idea).
The updates (position, collision ...) are sent without going through the Terrain. The terrain is there only to know who and what is around (list of players, target and balls with their IP number), to propose different colours for the users/balls and to set the initial position/direction of the balls/targets/players.
Feel free to chose the way you want to implement the project but you have to describe and to explain your choice in the README file and don't hesitate to discuss the configuration proposed in the assignment.
Amongst important choice you will have to explain is how you deal with "concurrent" events : what choice do you make about priority (if two rackets try to reach the same position for instance).
A ball should know its position and speed, and should multicast this information. Balls are moving at regular speed. That speed could be changed at any time through the slider of a GUI on the machine on which the ball is launched. That same GUI should allow you to remove a ball from the game (quit). Balls move along 8 possible directions (horizontals, verticals, and diagonals) as would a queen on a Chess board.
Every part of the game that need it ( balls, player, target ?) should use the same equation to compute as often as possible the position of the balls in between any update and in the absence of any collision. A change of direction following a collision happen only when the ball reach the centre of the next board square.
Balls should detect when they collide with rackets/limit of the terrain and change their direction according to the following rules :
Note that these are a subset of the possible bounces You should
extrapolate each case with the symmetric paths. For instance in the bouncing
<12>, the ball could arrive from the opposite direction (following a diagonal)
and be bounced back along an horizontal line.
In the case <7>, there is no bouncing, just a change of ownership/colour of the ball.
When launching a player, one specify the IP number of the terrain (and optionally its port number), and the colour of the racket. If the colour has already been chosen (negotiation with the terrain), then the next available one will be attributed automatically (by the terrain, amongst a predefined list of possible colours). During that negotiation phase, the terrain provide a free position to the player (free meaning "nobody else is on that squarre at that time").
A player should know its position and speed and should broadcast this information to the other players.
A racket could do one 'move' per game cycle. A game cycle length is by default 1 second, but is defined by the Terrain which dispatch that value at login to the other entities. A 'move' is either a change of location towards one of the immediate squares next to its current position (see <3>), like a king on a chess board, or a change of its orientation towards one of its two closest ones (left or right) amongst the 8 possible ones. The player could press more than one key per cycle, but each of theses key pressed should be buffered in a FIFO queue and process in turn (you could for instance quickly press the move up key 4 times, then twice the move left, and see that full move happen within the next 6 seconds. There should be a specific key that would allow you to erase the FIFO queue.
The Player class is the one that deal with the display and the interaction with the game. The GUI will display the main view for a user : he should be able to observe the Whole Terrain, its racket, the one of the other users, the balls, the targets ... and of course to interract with the game. You will propose the organisation of the keys. So remember to make it easy to get information about such an organisation.
The targets are moving like the towers of a chess game : horizontally of vertically. When they run into a racket, they change direction. I let you chose the rules for those changes of direction, the only thing to keep in mind is that a target path should change from horizontal to vertical during some of these events.
The targets are responsible for detecting when they are hit by a ball. This happen when the centre of a target and the centre of a ball are located within the same square of the board. Nor the ball nor the target change direction. There should be a visual or auditory clue that tell the player that a hit happened and the score is updated accordingly. When a hit occurred, the involved ball should not be able to hit the involved target until a racket touches the ball again or 10 cycles elapse, whatever happen first.
There should be a score, and some winners, and the possibility to play again ... I let you organise that aspect as you wish, but you will have to explain your choice in your readme file.
If you really want to have fun, you could implement a way to organise players in team (their score could be added into a common total)
cd .. (go to the directory in which your IVR05_UstudentID1_UstudentID2_UstudentID3 is located)
jar cvf IVR05_UstudentID1_UstudentID2_UstudentID3.jar IVR05_UstudentID1_UstudentID2_UstudentID3/
Mail the file (IVR_A2_03_UstudentID1_UstudentID2.jar) as an attached document. Be sure that the title of your mail is 'IVR05_UstudentID1_UstudentID2_UstudentID3'
Send that mail before the 23rd of May 2005 at 16:00
The way to run the program is different for each part
java Terrain [-verbose|veryVerbose] [ portNumber ]
Regarding the number and type (beginning or not by a '-' ), the program should guess which set of parameter it is receiving
Ex : java Terrain -verbose 7799
java Player [-verbose|veryVerbose] terrainIP 'Player Name' [ colour [ portNumber ] ]
java Ball [-verbose|veryVerbose] terrainIP [ colour [ portNumber ] ]
java Target [-verbose|veryVerbose] terrainIP [ colour [ portNumber ] ]
colour : black, blue, cyan ... one of the colour defined in the Color class
port number : you may chose a port number only if you have chosen a colour
Ex : java Player 192.168.2.67 Pascal
java Ball -veryVerbose 192.168.3.45 yellow 7799
Verbose option : -verbose option display all important received packets (collision detection, login ...)
-veryVerbose option display all received packets (no more than one line of extracted information per received packet)