instructions are in asst2 pdf, a2 zip file is my friend's code that will help you to do assignment and gagandeep zip is my code so far that has some issues.
CSUS 1 of 10 CSUS COLLEGE OF ENGINEERING AND COMPUTER SCIENCE Department of Computer Science CSc 133 – Object-Oriented Computer Graphics Programming Fall 2021 Dr. Muyan Assignment #2: Design Patterns and GUIs Due Date: Monday, October 25th 11:59PM Introduction For this assignment you are to extend your game from Assignment #1 (A1) to incorporate several important design patterns, and a Graphical User Interface (GUI). The rest of the game will appear to the user to be similar to the one in A1, and most of the code from A1 will be reused, although it will require some modification and reorganization. An important goal for this assignment will be to reorganize your code so that it follows the Model-View-Controller (MVC) architecture. If you followed the structure specified in A1, you should already have a “controller”: the Game class containing the play() method. The GameWorld class becomes the “data model”, containing the collection of game objects and other game state information. You are also required to add two classes acting as “views”: a score view which will be graphical, and a map view which for now will retain the text-based form generated by the ‘m’ command in A1 (in A3 we will replace the text-based map with an interactive graphical map). Single-character commands entered via a text field in A1 will be replaced by GUI components (side menu items, buttons, key bindings, etc.). Each such component will have an associated “command” object, and the command objects will perform the same operations as previously performed by the single-character commands. The program must use appropriate interfaces and built-in classes for organizing the required design patterns. The following design patterns are to be implemented in this assignment: • Observer/Observable – to coordinate changes in the model with the various views, • Iterator – to walk through all the game objects when necessary, • Command – to encapsulate the various commands the player can invoke, • Singleton – to insure that only a single instance of Ant can exist. Model Organization GameWorld is to be reorganized so that it has a GameObjectCollection which contains a collection of game objects. All game objects are to be contained in this single collection. Any routine that needs to process the objects in the collection must access the collection via an iterator (described below). The model is also to contain the same game state data as A1 (current clock time and lives remaining), plus a new state value: a boolean indicating whether Sound is ON or OFF (described below). 2 of 10 Views A1 contained two functions to output game information: the ‘m’ key for outputting a “map” of the game objects in the GameWorld, and the ‘d’ key for outputting current game/ant state data (i.e., the number of lives left, the current clock value, last flag number the ant has reached sequentially so far, the ant’s current food level, and the ant’s current health level). Each of these two operations is to be implemented in this assignment as a view of the GameWorld model. To do that, you will need to implement two new classes: a MapView class containing code to output the map, and a ScoreView class containing code to output the current game/ant state information. To implement this, GameWorld should be defined as an observable, with two observers– MapView and ScoreView. Each of these should be “registered” as an observer of GameWorld. When the controller invokes a method in GameWorld that causes a change in the world (such as a game object moving, or a new food station being added to the world, etc…) the GameWorld notifies its observers that the world has changed. Each observer then automatically produces a new output view of the data it is observing – the game world objects in the case of MapView, and a description of the game/ant state values in the case of ScoreView. The MapView output for this assignment is unchanged from A1: text output on the console showing all game objects which exist in the world. However, the ScoreView is to present a graphical display of the game/ant state values (described in more detail below). Recall that there are two approaches which can be used to implement the Observer pattern: defining your own IObservable interface, or extending the built-in CN1 Observable class. You are required to use the latter approach (where your GameWorld class extends java.util.Observable) and the tips for it are given at the end of the handout. Note that you are also required to use the built-in CN1 Observer interface (which also resides in java.util package). In order for a view (observer) to produce the new output, it will need access to some of the data in the model. This access is provided by passing to the observer’s update() method a parameter that is a reference back to the model (which is done automatically by the notifyObservers() built-in method when built-in Observable class is used). Note this has the undesirable side-effect that the view has access to the model’s mutators, and hence could modify model data (later in the lectures, we will discuss how to address this issue with the Proxy pattern). GUI Operations Game class extends Form (as in A1) representing the top-level container of the GUI. The form should be divided into five areas: one for “score” information, three for commands, and one for the “map” (which will be an empty container for now but in subsequent assignments will be used to display the map in graphical form). See the sample picture at the end. Note that since user input is via GUI components, flow of control will now be event-driven and there is no longer any need to invoke the play() method – once the Game is constructed it simply waits for user-generated input events. Note however that it is still a requirement to have a “Starter” class as described in A1. Hence, in this assignment, the play() method used in A1 which prompts for single- character commands and reads them from a text field on the form is to be discarded. In its place, commands will be input through three different mechanisms: on-screen buttons, key 3 of 10 bindings, and side menu items (we will also utilize a title bar area item to provide help as explained below). Each command will be invokable via a combination of these mechanisms. You are to create command objects (see below) for each of the commands from A1 (except “d” and “m” which are implemented as views in A2, and “y” and “n” which are replaced by an exit dialog box – see below) and for new commands introduced in A2 (i.e., sound, about, and help). You are to attach the objects as commands to various combinations of invokers as shown in the following table (a ‘+’ in a column indicates that the command in that row is to be able to be invoked by the mechanism in the column header): Command KeyBinding Side Menu (or Title Bar Area) Item Button accelerate + + + brake + + left turn + + right turn + + collide with flag + collide with food station + + collide with spider (g) + + tick + + exit + turn the sound on or off + give about information + give help information + For west, east, and south regions on the form (Game), you should have a different Container (another built-in CN1 class) object created. For north and center regions, you should have a ScoreView and a MapView object created, respectively. ScoreView and MapView classes should extend from Container. MapView will be an empty container whereas you should add appropriate labels (use CN1 built-in Label class) to ScoreView (see below for details). Adding the labels to the ScoreView should be done in the constructor of the ScoreView. For regions with buttons (i.e., west, east, and south), after you create their Container objects (which we will call as “control containers”), you should add related buttons to these containers. Each button is to have an appropriate command object attached to it, so that when a button gets pushed it invokes the actionPerformed() method in the corresponding command object (the execute() method in terms of the Command pattern), which in turn most of the case calls appropriate command method in GameWorld. Most commands execute exactly the same code as was implemented in A1. One exception is the “collide with flag” command. Previously this command consisted of a number (between 1-9) entered from the text field located on the form which we eliminate in A2. Now, this command is to use the static method Dialog.show() to display a dialog box that allows the user to enter the number on a text field located on the dialog box (please see the “Titled Form in CN1” slide of “GUI Basics” chapter in lecture notes for more information). Note that if the user inputs an invalid value; your program should handle this gracefully. 4 of 10 The “key binding” input mechanism will use the CN1 key binding concept so that the “a”, “b”, “l”, “r”, “f”, “g”, and “t” keys invoke command objects corresponding to the code previously executed when the “a”, “b”, “l”, “r”, “f”, “g”, and “t” single-character commands were entered, respectively. Note that using key bindings means that whenever a key is pressed, the program will immediately invoke the corresponding action (without the user pressing the Enter key). If you want, you may also use key bindings to map any of the other command keys from A1, but only the ones listed here are required. The “side menu item” input mechanism will use a side menu (see class notes for tips on how to create a side menu using CN1 built-in Toolbar class). Your GUI will contain a side menu that contains the following items: “Accelerate”, “Sound”, “About”, and “Exit”. “Accelerate” menu item should invoke “a” command. “Sound” menu item should include a check