|
This assignment is based on the matching Computer Graphics Assignment. All what is not explain here should be found there.
In this assignment you are asked to simulate a squash game in 3D, where the players, the terrain and the ball would be "alive" on different computers. More precisely, you begin to chose a computer where you run the terrain, then you start one or more balls 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 : easy to modify parameter in your code and option 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 port number, but each datagram would contain an ID that will point at a particular object, or either, that each object would listen to (or broadcast to) a different port number, based on the terrain port number, incremented by one for each new object entering the simulation.
NB. : in case you chose to let all objects listen to the same port number, it means indeed that you specify a special class that will take care of the networking on one given machine and that will dispatch each datagram to the matching class ... that means that all classes should be running in threads inside a common process ... that is a more complex configuration ...
Terrain is the dispatching server.
When an object login (TCP/IP), it received, if it is a player, the physical description of the terrain, if is a ball, its initial position and speed (or the status : still in the FIFO queue.
Each time a new object login, Terrain attribute it a new port number and send the information (port number, colour of the object, type of object) to all other current players. Note that the terrain is the first of the object to get a port number : the default one + 1.
The Terrain manage a list of all available components.
Each Component keep the coordinate of the terrain (in case it wants to leave the game).
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 for the ball).
Each component keep a list of objects/UDP port numbers it need to listen to. Players should listen both to players (display) and balls. Terrain should listen to ball. It seems that ball don't need to listen to any UDP broadcasting, except if 1) you plan to implement ball/ball collision, 2) ball want to take into account relative position/speed of players to decide about collision concurrences (when to players announce collision "almost" at the same time).
If you really are not confident with UDP, instead of each component listening to a set of UDP port number (Pull configuration), you could have each component sending its position to a list of IP number (TCP/IP connection) in a Push configuration. The architecture complexity remain the same, the implementation is just perhaps a bit more simple (no UDP layer) but less efficient in term of scaling.
Either the terrain knows the IP number of the balls and the players and distribute them (and then each element is responsible for sending update to all other listed elements), or we use local broadcasting ... In all case the updates (position, collision ...) are sent without going through the terrain. The terrain is here only to know who and what is around (list of players and balls with their IP number) and to propose different colours for the users/balls.
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.
Other important choice you will have to explain is how you deal with "concurrent" events : what choice do you make about priority (if a racket and a plane are in the same position for instance or if two rackets think they are hitting the ball at the same time).
When the terrain receive the position of the ball or when it compute it using the speed and the acceleration of the ball (because it would be time to do it), it checks by itself if there is a collision. If a collision is detected, it informs the ball and specify the point of impact, the normal to the plane and a kinetic energy reduction factor which value depend on the surface (0<value<=1).
The terrain should be able to send a BranchGroup (or Shape3D) object that would be used by the players only to display the surrounding (not to check against collision) and that describe the physical aspect of the terrain.
A ball should know its position, speed and acceleration and should broadcast this information to the terrain and the players every second.
Every part of the game (terrain, balls, player) should use the same equation to compute as often as possible the position of the balls in between and in the absence of any collision.
Each time a ball receive from the terrain or the players the information about a collision (point and normal and energy collision factor), it should compute its new velocity and position and broadcast immediately its resulting change of behaviour.
When launching a racket, one specify the IP number of the terrain (and optionally its port number), the size of the racket in centimetre (between two limits chosen in order to match the possible speed of the racket), and the colour of the racket. If the colour has already been chosen, then the next available one will be attributed automatically (by the terrain, amongst a predefined list of possible colour).
A player should know its position and speed and should broadcast this information to the terrain and the players every 500 ms.
The bigger is the racket, the slower it can be move (width x speed = Constant)
When the racket receive the position of the ball or when it compute it using the speed and the acceleration of the ball, because it is time to do it, it checks by itself if there is a collision. If yes, it informs the ball and specify 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 (just assume to simplify that this is a constant depending directly on the size of the racket, proportional to its speed).
The Player class is the one that deal with the display and the interaction with the game.
cd .. (go to the directory in which your 02IVRA3_UstudentID1_UstudentID2 is located)
jar cvf 02IVRA3_UstudentID1_UstudentID2.jar 02IVRA3_UstudentID1_UstudentID2/
Mail the file (02IVRA3_UstudentID1_UstudentID2.jar) as an attached
document. Be sure that the title of your mail is '02IVRA3_UstudentID1_UstudentID2.jar'
(3) The way to run the program is different for each part
java Terrain [-verbose|veryVerbose] [ numberWall width length height ] [ portNumber ]
numberWall : number of walls, default and minimum : 2 (floor and main one). Max : 6
width length height : dimensions of the box
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
or java Terrain 4 10 12 8
java Player [-verbose|veryVerbose] terrainIP [ colour [ portNumber ] ]
java Ball [-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 color
Ex : java Player 192.168.2.67
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)
|
| See the "Links" link above to find out the sources of the proposed informations Pascal Vuylsteker / eScience / Computer Science / ANU |
Last modified: 19/9/2002 | Send your comments at : <pvk@vuylsteker.net> |