Search for question
Question

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 GameWorldis 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/nthe 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).

Fig: 1

Fig: 2