in pdf
CSUS page 1 of 9 CSUS COLLEGE OF ENGINEERING AND COMPUTER SCIENCE Department of Computer Science CSc 133 – Object-Oriented Computer Graphics Programming Spring 2022 - Dr. Muyan Assignment #3: Interactive Graphics and Animation Due Date: Monday, April 25th 11:59 PM 1. Introduction The purpose of this assignment is to help you gain experience with interactive graphics and animation techniques such as repainting, timer-driven animation, collision detection, and object selection. Specifically, you are to make the following modifications to your game: (1) the game world map is to display in the GUI (in addition to the text form on the console), (2) the movement (animation) of game objects is to be driven by a timer, (3) the game is to support dynamic collision detection and response, (4) the game is to support simple interactive editing of some of the objects in the world, and (5) the game is to include sounds appropriate to collisions and other events. 2. Game World Map If you did Assignment2 (A2) properly, your program included an instance of a MapView class which is an observer that displayed the game elements on the console. MapView also extended Container and it was placed in the middle of the game form, although it was empty. For this assignment, MapView will display the contents of the game graphically in the container in the middle of the game screen (in addition to displaying it in the text form on the console). When the MapView update() is invoked, it should now also should call repaint() on itself. As described in the course notes, MapView should override paint(), which will be invoked as a result of calling repaint(). It is then the duty of paint() to iterate through the game objects invoking draw() in each object – thus redrawing all the objects in the world in the container. Note that paint() must have access to the GameWorld. That means that the reference to the GameWorld must be saved when MapView is constructed, or alternatively the update() method must save it prior to calling repaint(). Note that the modified MapView class communicates with the rest of the program exactly as it did previously (e.g., it is an observer of GameWorld). As indicated in A1, each type of game object has a different shape which can be bounded by a square. The size attribute provides the length of this bounding square. The different graphical representation of each game object is as follows: Flags are filled isosceles triangles; food stations are filled squares; the ant is a filled circle; and spiders are unfilled isosceles triangles. Hence, the size attribute of the ant indicates the diameter of the circle, size of a flag or spider indicates the length of the base and height of the isosceles triangle, and size of a food station indicates the length of equal sides of the square. Note that as before, the initial capacity of a food station is proportional to its size and the size of a food station remains the same even as its capacity decreases. page 2 of 9 Flags should include a text showing their number; food stations should include text showing their food capacity. Use the Graphics method drawString() to draw the text on flags and food stations. The appropriate place to put the responsibility for drawing each shape is within each type of game object (that is, to use a polymorphic drawing capability). The program should define a new interface named IDrawable specifying a method draw(Graphics g, Point pCmpRelPrnt). GameObject class should implement this interface and each concrete game object class should then provide code for drawing that particular object using the received Graphics object g (which belong to MapView) and Point object pCmpRelPrnt, which is the component location (MapView’s origin location which is located at its the upper left corner) relative to its parent container’s origin (parent of MapView is the content pane of the Game form and origin of the parent is also located at its upper left corner). Remember that calling getX() and getY() methods on MapView would return the MapView component’s location relative to its parent container’s origin. Each object’s draw() method draws the object in its current color and size, at its current location. Recall that current location of the object is defined relative to the origin of the game world (which corresponds to the origin of the MapView in A2 and A3). Hence, do not forget to add MapView’s origin location (relative to its parent container’s origin) to the current location while drawing your game objects since draw...() methods (e.g., drawRect()) of Graphics expects coordinates which are relative to the parent container’s origin. Also, recall that the location of each object is the position of the center of that object. Each draw() method must take this definition into account when drawing an object. Remember that the draw...() method of the Graphics class expects to be given the X,Y coordinates of the upper left corner of the shape to be drawn. Thus, a draw() method would need to use the location and size attributes of the object to determine where to draw the object so its center coincides with its location (i.e., the X,Y coordinate of the upper left corner of a game object would be at center_location.x – size/2, center_location.y – size/2 relative to the origin of the MapView, which is the origin of the game world). 3. Animation Control The Game class is to include a timer (you should use the UITimer, a built-in CN1 class) to drive the animation (movement of movable objects). Game should also implement Runnable (a built-in CN1 interface). Each tick generated by the timer should call the run() method in Game. run() in turn must invoke the “Tick” method in GameWorld from the previous assignment, causing all moveable objects to move. This replaces the “Tick” button, which is no longer needed and should be eliminated. There are some changes in the way the Tick method works for this assignment. In order for the animation to look smooth, the timer itself will have to tick at a fairly fast rate (about every 20 msec or so). In order for each movable object to know how far it should move, each timer tick should pass an “elapsed time” value to the move() method. The move() method should use this elapsed time value when it computes a new location. For simplicity, you can simply pass the value of the timer tick rate (e.g., 20 msec), rather than computing a true elapsed time. However, it is a requirement that each move() computes movement based on the value of the elapsed time parameter passed in, not by assuming a hard-coded time value within the move() method itself. You should experiment to determine appropriate movement page 3 of 9 values (e.g., in A1, we have specified the initial speed of the spider to be a random value between 5 and 10, you may need to adjust this range to make your spiders have reasonable speed which is not to too fast or too slow). In addition, be aware that methods of the built-in CN1 Math class that you will use in move() method (e.g., Math.cos(), Math.sin()) expects the angles to be provided in radians not degrees. You can use Math.toRadians()to convert degrees to radians. Remember that a UITimer starts as soon as its schedule() method is called. To stop a UITimer call its cancel() method. To re-start it call the schedule() method again. 4. Collision Detection and Response There is another important thing that needs to happen on Tick method in GameWorld. After invoking move() for all movable objects, your Tick method must determine if there are any collisions between objects, and if so to perform the appropriate “collision response”. You must handle collision detection/response by having GameObject class implement a new interface called “ICollider” which declares two methods boolean collidesWith(GameObject otherObject) and void handleCollision(GameObject otherObject) which are intended for performing collision detection and response, respectively. In the previous assignment, collisions were caused by pressing one of the “pretend collision buttons” (i.e., “Collide With Flag”, “Collide With Spider”, “Collide With Food Station”), and the objects involved in the collision were chosen arbitrarily. Now, the type of collision will be detected automatically during collision detection, so the pretend collision buttons are no longer needed and should be removed. Related menu items, key bindings, and command classes should also be removed. Collision detection will require objects to check to see if they have collided with other objects, so the actual collisions will no longer be arbitrary, but will correspond to actual collisions in the game world. There are more hints regarding collision detection in the notes below. Collision response (that is, the specific action taken by an object when it collides with another object) will be similar as before. Hence, handleCollision() method of a game object should call the appropriate collision handling method in GameWorld from the previous assignment. Collisions also generate a sound (see below) and thus, collision handling methods in GameWorld should be updated accordingly. 5. Sound You may add as many sounds into your game as you wish. However, you must implement particular, clearly different sounds for at least the following situations: (1) when the ant collides with a spider (such as a squeaking sound), (2) when the ant collides with a food station (such as a crunching sound), (3) when the ant collides with a flag (such as a cheering sound), (4) some sort of appropriate background sound that loops continuously during animation. Sounds should only be played if the “Sound” attribute is “On”. Note that except for the “background” sound, sounds are played as a result of executing a collision. Hence, you must play these sounds in collision methods in GameWorld. page 4 of 9 You may use any sounds you like, as long as we can show the game to the Dean and your mother (in other words, they are not