This is an old revision of the document!

Adventure Game (Inheritance)

Introduction

The adventure game first appeared in Case Study 1 in Lecture 4. There we showed how Lists and Maps can be combined to produce data structures to manage the book-keeping required in a game. There, the data maintained in the collections where simple strings. in Case Study 2 we enhanced the capabilities of the system by making use of procedural code and closures. A text-based menu was introduced to support user interaction. later in Case study 3, we used objects with more interesting state information and behaviours to represent the game, the players and items. We also removed any input/output responsibilities from them and introduces another action class for this purpose.

In the first two iterations of this case study, we revisit the same case study and use class inheritance to model not just items with a name, description and values, but items in general. As with the earlier versions, we use containers to help model the relationships established between objects. Similarly we continue to make use of unit tests. In the third iteration, we address the problem of error detection and user feedback as well as enhancing the functionality of the system. Finally, in the last iteration, we demonstrate how easy it is to use Groovy to police constraints placed on the model.

An index to the source code for all the examples in this case study is available.

Specification

As in Case study 3 we assume sufficient familiarity with the operation of a text-based adventure game to understand the following description:

The game has a name, holds a number of items that may be have either weight or magical potency. weighty items and magical items both have a name, optional description, value and a unique identification number. Each weighty item has a weight and each magical item has a potency. The system should be able to display the items that can be picked up and those that are being carried. A some point in the future, the game can hold other items such as food and clothing.

There are a number of registered players, each of which has an email address, a unique identification number and a nickname. A player may pick up an item and drop an item. The system should record each transaction. To record the collection of an item, the id of the player and the id of the item are required. To record that an item has been dropped, on the item id is required.

The system should also be able to display details of the items that are being carried by players.

These requirements are captured in the use cases as shown in Table 1.

Table 1: use cases for an Adventure Game <html> <table> <tr><td> <ul> <li>Add new weighty item to game inventory</li> <li>Add new magical item to game inventory</li> <li>Display game inventory</li> <li>Display items available for collection</li> <li>Display items being carried by players</li> <li>Register a new player</li> <li>Display all players</li> <li>Player picks up a weighty item</li> <li>Player picks up a magical item</li> <li>Player drops a weighty item</li> <li>Player drops a magical item</li> </ul> </td> </tr> </table> </html>

Iteration I: Confirm the Polymorphic Effect

The specification mentions two kinds of items held in the game: weighty items and magical items. Further, we are advised that, in the future, food and clothing will also be available. This suggests a class hierarchy for the various types of game items. It should be capable of extending horizontally to include new categories of items, and vertically to further specialize the items.

The initial class diagram is given in Figure 1. The Item class represents any item that may be present in the game. It is an abstract class and carries the properties and behaviours common to all game items: the item id, name, value and optional description as well as the toString method which provides a textual representation. The two subclasses represent the actual items currently available ion the game. in addition to the id and other properties inherited from the superclass Item, the subclass WeightyItem has a weight property while subclass MagicalItem has a potency property.

Figure 1: Initial class hierarchy

This leads us to develop the Groovy classes Item, WeightyItem, and MagicalItem held in the files Item.groovy, WeightyItem.groovy, and MagicalItem.groovy, respectively.

1| Item class (at-m42/Case-Studies/case-study-04/Item.groovy)

abstract class Item {
 
    String toString() { // redefinition
        def s = "${id}: name = ${name}; value = ${value};"
        if ( description.size() > 0 ) {
            s += " description: ${description};"
        }
        return s
    }
 
// ----- properties -----------------------------
 
    def name
    def description = ''
    def id
    def value
 
}

1| WeightyItem class (at-m42/Case-Studies/case-study-04/WeightyItem.groovy)

extern> http://www.cpjobling.org.uk/~eechris/at-m42/Case-Studies/case-study-04/WeightyItem.groovy

1| MagicalItem class (at-m42/Case-Studies/case-study-04/MagicalItem.groovy)

extern> http://www.cpjobling.org.uk/~eechris/at-m42/Case-Studies/case-study-04/MagicalItem.groovy

When deploying a class hierarchy, we need to be assured that we a correctly initializing the objects and that any polymorphic behaviour operates as expected. This is the aim of this first iteration. All all three classes refine the toString method (Item redefines toString from Object, WeightyItem and MagicalItem redefines toString from Item), we must ensure that we get the expected polymorphic behaviour.

Following the discussions of Lecture 8, we create the GroovyTestCases, WeightyItemTest and MagicalItemTest classes. In the WeightyItem class, we have:

1| WeightyItemTest class (at-m42/Case-Studies/case-study-04/WeightyItemTest.groovy)

extern> http://www.cpjobling.org.uk/~eechris/at-m42/Case-Studies/case-study-04/WeightyItemTest.groovy

The MagicalItemTest class is similar. Notice that the unit tests also guarantee the constructor usage since the toString methods make use of the object properties.

Because we also intend unit testing other classes, we have a runAllTests to run a GroovyTestSuite, as described in Lecture 8

1| GroovyTestSuite class (at-m42/Case-Studies/case-study-04/runAllTests.groovy)

import groovy.util.GroovyTestSuite
import junit.framework.Test
import junit.textui.TestRunner
 
class AllTests {
 
    static Test suite() {
        def allTests = new GroovyTestSuite()
 
        allTests.addTestSuite(WeightyItemTest.class)
        allTests.addTestSuite(MagicalItemTest.class)
 
        return allTests
    }
 
}
 
TestRunner.run(AllTests.suite())

We can easily add other GroovyTestCases later.

An execution of the script results in the following test report:

..
Time: 0.005

OK (2 tests)

It confirms that we have the correct object initialization and polymorphic behaviour. Therefore, we have achieved the aim of this iteration.

Iteration II: Demonstrate the Required Functionality

having established that we can make use of the polymorphic effect, the aim of this iteration is to demonstrate that we can achieve the required functionality described in the use cases of the Specification.

We have introduced the abstract class Item with the properties and behaviours common to all items in the game. Therefore we adjust the class diagram of Figure 3 from the previous case study to reflect this decision. It is shown in Figure 2.

Figure 2: Class diagram

Clearly, we can base the implementation of these classes on those of Case study 3. However, we can also incorporate the changes made to Game and Player as a result of the unit testing in Lecture 8. Happily we can also retain the GameTest and PlayerTest to the GroovyTestSuite in runAllTests.groovy although we have to replace Item in the test fixtures in both GameTest and PlayerTest with WeightyItem:

// class GameTest
// ...
    /**
     * Set up the fixture
     */
    void setUp() {
        game = new Game(name : 'School')
 
        book = new WeightyItem(id : 1, name : 'book', value : 5, 
            description : 'a maths text book', 
            weight : 1)    
        satchel = new WeightyItem (id : 2, name : 'satchel', value : 10,
            description : 'a carrier for school books and pencils', 
            weight : 5)
        item3 = new WeightyItem (id : 2, name : 'a different satchel',
            value : 10, weight : 5)
    }

(the PlayerTest setUp method is similar).

The Action class also needs some minor changes. For example, addItem will have to be changed to addWeightyItem:

// Action class
	void addWeightyItem() {
		print('\nEnter item id: ')
		def itemId = Console.readInteger()
		print('\nEnter item name: ')
		def name = Console.readLine()
		print('\nEnter item value: ')
		def value = Console.readInteger()	
		print('\nEnter item description (return for none): ')
		def description = Console.readLine()
		print('\nEnter item weight: ')
		def weight = Console.readInteger()
 
		def item = new WeightyItem(id : itemId, name : name, value : value,
		                    description : description,
		                    weight : weight)
 
		game.addItem(item)		
	}

We need a similar method addMagicalItem:

// Action class
	void addMagicalItem() {
		print('\nEnter item id: ')
		def itemId = Console.readInteger()
		print('\nEnter item name: ')
		def name = Console.readLine()
		print('\nEnter item value: ')
		def value = Console.readInteger()	
		print('\nEnter item description (return for none): ')
		def description = Console.readLine()
		print('\nEnter item potency: ')
		def poetncy = Console.readInteger()
 
		def item = new MagicalItem(id : itemId, name : name, value : value,
		                    description : description,
		                    potency : potency)
 
		game.addItem(item)		
	}

Finally, we modify the Groovy script that presents a menu to a user and actions user choices. It is shown as Game 01.

1| Game 01: An adventure game with weighty and magical items (at-m42/Case-Studies/case-study-04/game1.groovy)

extern> http://www.cpjobling.org.uk/~eechris/at-m42/Case-Studies/case-study-04/game1.groovy

To complete this iteration, we run our unit tests. Happily, they all pass. Next, we use the menu to carry out functional testing. an obvious strategy is to make choices (assisted by the various display options) that correspond to the use-cases identified earlier. An illustrative session (with the user data input shown in bold italic) is: <html> <pre> e:\dev\at-m42-2009\Case-Studies\case-study-04>groovy game1.groovy

0: Quit 1: Add new weighty item 2: Add new magical item 3: Display inventory 4: Display available items 5: Display items being carried 6: Register new player 7: Display players 8: Pick up an item 9: Drop an item

      Enter choice>>>> <b><i>1</i></b>

Enter item id: 111

Enter item name: book

Enter item value: 5

Enter item description (return for none): a maths text book

Enter item weight: 1

0: Quit 1: Add new weighty item 2: Add new magical item 3: Display inventory 4: Display available items 5: Display items being carried 6: Register new player 7: Display players 8: Pick up an item 9: Drop an item

      Enter choice>>>> <b><i>2</i></b>

Enter item id: 222

Enter item name: potion

Enter item value: 10

Enter item description (return for none): a magical potion

Enter item potency: 5

0: Quit 1: Add new weighty item 2: Add new magical item 3: Display inventory 4: Display available items 5: Display items being carried 6: Register new player 7: Display players 8: Pick up an item 9: Drop an item

      Enter choice>>>> <b><i>3</i></b>

Game: The Discworld

WeightyItem: 111: name = book; value = 5; description: a maths text book; with weight: 1
MagicalItem: 222: name = potion; value = 10; description: a magical potion; with potency: 5

0: Quit 1: Add new weighty item 2: Add new magical item 3: Display inventory 4: Display available items 5: Display items being carried 6: Register new player 7: Display players 8: Pick up an item 9: Drop an item

      Enter choice>>>> <b><i>0</i></b>

Game closing … thanks for playing </pre> </html>

Having encountered no problems, we consider this iteration to be complete.

Iteration III: Reimplement the user interface

1| Reimplement the user interface (at-m42/Case-Studies/case-study-03/game3.groovy)

extern> http://www.cpjobling.org.uk/~eechris/at-m42/Case-Studies/case-study-03/game3.groovy

Notes…

Output: <html> <pre> e:\dev\at-m42-2009\Case-Studies\case-study-03>groovy game3.groovy

0: Quit 1: Add new item 2: Display inventory 3: Display available items 4: Display items being carried 5: Register new player 6: Display players 7: Pick up an item 8: Drop an item

      Enter choice>>>> <b><i>1</i></b>

Enter item id:1 Enter item name:Luggage Enter item value:Sentient pear wood with lots of little legs … Present menu to the user

      Enter choice>>>> <b><i>2</i></b>

Game: The Discworld

Item: 1; name = Luggage: value = 1000; description: Sentient pear wood with lo

ts of little legs;

… Present menu to the user

      Enter choice>>>> <b><i>5</i></b>

Enter player id:1 Enter player nickname:Twoflower Enter player email address:tf@discworld.com … Present menu to the user

      Enter choice>>>> <b><i>6</i></b>

Game: The Discworld : Player Details

Player: 1; Twoflower (tf@discworld.com)

… Present menu to the user

      Enter choice>>>> <b><i>7</i></b>

Enter item id:1 Enter player id:1 … Present menu to the user

      Enter choice>>>> <b><i>3</i></b>

Game: The Discworld : Available items

… Present menu to the user

      Enter choice>>>> <b><i>4</i></b>

Game: The Discworld : Items being carried

Item: 1; name = Luggage: value = 1000; description: Sentient pear wood with lo

ts of little legs;

… Present menu to the user

      Enter choice>>>> <b><i>8</i></b>

Enter item id: 1

… Present menu to the user

      Enter choice>>>> <b><i>3</i></b>

Game: The Discworld : Available items

Item: 1; name = Luggage: value = 1000; description: Sentient pear wood with lo

ts of little legs;

… Present menu to the user

      Enter choice>>>> <b><i>4</i></b>

Game: The Discworld : Items being carried

… Present menu to the user

      Enter choice>>>> <b><i>0</i></b>

Game closing … thanks for playing

e:\dev\at-m42-2009\Case-Studies\case-study-03> </pre> </html>

Exercises

Home | Lectures | Previous Case Study | Case Studies | Next Case Study

ICCT Wiki

Table of Contents

Adventure Game (Inheritance)

Introduction

Specification

Iteration I: Confirm the Polymorphic Effect

Iteration II: Demonstrate the Required Functionality

Iteration III: Reimplement the user interface

Exercises