Create a reusable framework for an adventure video game. Within a package named "adventure", define base classes Player, Monster, and Game. This package will form a reusable framework; clients of the framework will instantiate objects of these classes or subclasses. Design the classes to be extended. Clients can extend the adventure.Player, adventure.Monster, and adventure.Game classes and use their client-specific subclasses instead of the base classes.
There is always exactly one Player per Game. There may be an unlimited number of Monsters. By default, a game consists of Monsters appearing occasionally at random, chasing, and attacking the Player. Each time the Player is attacked, he or she loses a random number of "health points" and the Monster also loses a random number of health points. When a Monster's health points drops to 0, it is removed from the game. By default, when the Player's health points drop to 0, the player loses and the game is over. By default, if a player defeats 100 monsters, he or she wins the game and the game is over.
Together, the Game, Player, and Monster classes should implement these ground rules in a way which distributes responsibility logically among the classes and allows clients to override the rules in their own subclasses.
The Game should manage a window (either an applet or a standalone frame) with a graphical representation of the Player and Monster(s); each Player and each Monster should manage its own appearance via a draw() method. (See the ChaseGame.java sample for an example of drawing multiple objects.) Monsters can attack the Player only when they are touching the Player. You an use any reasonable method for making the Monsters chase the Player, and letting the user move the Player. The graphics can be very simple, as in the ChaseGame demo. You can also vary the appearance of different kinds of monsters to make it obvious which subclass you're dealing with.
For most clients, the default game play works fine, but they need to customize the Player and Monster classes (to change the chase behavior, the combat behavior, or the UI representation, for example). To do this a client would first subclass Player or Monster, and then tell the Game to use their subclass instead of the default.
To do this, use the Prototype pattern. The Game class should contain methods setPrototypePlayer(Player p) and setPrototypeMonster(Monster m). The Game will use the objects passed in as originals when creating clones for use in the actual game. Note that the objects passed in to setPrototypeXXX() are not actually used in the game themselves; you need to make copies using clone() in order to make the Prototype pattern work.
The game should still work (with default monster and player) if setPrototypeXXX() is never called.
You may want to consider using a common base class for Monster and Player, since they share a number of commonalities (they both move on the screen, they both engage in combat, etc.) This is an internal implementation detail that shouldn't matter to the client of the adventure package,
Along with the framework, create a test program that extends Monster and calls setDefaultMonster() at least once. Make sure that the framework is independent of the test program. Feel free to add additional monster subclasses, change them during the program's execution, etc. (The framework should support switching the type of monster that will appear next; for example, you could do this every 5th time the player moves.)
Turn in a class diagram, the code, any println output, and a screen shot of your program. (Under Windows, you can copy screen images to the Clipboard with Control-PrtScn, then paste to an application like Paintbrush for printing.)