CSC 207 Introduction to Software Design 代写案例

0. • 1 Introduction

     In this assignment is to write a simple text-based adventure game in the tra- dition of the console-based “Adventure” games of the early 1970s. In games of this sort, a player wanders around a map, picks up objects, and solves simple puzzles. To start, you will be coding a relatively simple version the original “Adventure” game, which was written by Willie Crowther in 1976 and which has the title “Colossal Cave Adventure”. If you are interested in the history of this particular game, you can read more about it on Wikipedia.
     
     

     There are a few features that will distinguish your game from the original, however. The most important one, perhaps, is that your game will allow for the inclusion of audio descriptions of the rooms and objects that define a given adventure. We include these features because sound can improve users’ gaming experience and make games more accessible.
     
     

     Note also that we will be working with adventure games throughout this term, including on group projects. While you cannot work in groups to complete this assignment, we encourage you to work in groups to draft novel adventure sto- ries. Moreover, in your group projects, we will be asking you to add features that enhance both engagement and accessibility, with a focus on accessibility to people with low vision. Toward this end, you may want to start researching the World Wide Web Consortium’s Technical Report on Accessibility Requirements for users with low vision. In addition, you may want to look for engaging sound resources that you might include in your games. An excellent repository of open source gaming resources, which includes both sound and music, can be found at this URL: https://opengameart.org/ . If you find others, please share these on the course Piazza and make sure to appropriately credit the artists when you make use of their work. In addition, the following resource may help you get better acquainted with some of the best existing work in accessible gaming: https://caniplaythat.com .
     
     

     2 Game Overview

     Adventure games see an explorer move from room to room through a set of interconnecting corridors. Each room has a number, a description and a name, and there are (typically) up to four corridors that leave the room. The directions for travel are generally north, south, east and west. Normally, corridors can be traversed in both directions, but not always. You move about in the game by giving commands, most of which are simply an indication of the direction of motion (i.e. ’North’, ’South’, ’East’ or ’West’).
     
     

     For some games, users may traverse from environment to environment via trails instead of from room to room via corridors. In this case, we will consider a “room” to be a particular location or environment and the “passages” are paths that lead to or from that location.
     
     

     In the classic adventure game developed by Willie Crowther, you might move about as follows:

     You are standing at the end of a road before a small brick building. A small stream flows out of the building and down a gully to the south. A road runs up a small hill to the west.

     > WEST
     You are at the end of a road at the top of a small hill. You can see as mall building in the valley to the east.

     > EAST
     You are: Outside building.
     
     

     In the example above, you started outside a building, moved to the WEST, and arrived at a new location on the top of a small hill. You then went back EAST and ended up outside the building again. As you will see, the complete description of a location appears only the first time you enter it; the second time, the program displays a much shorter identifier. You can however although you can get the complete description by typing LOOK, as follows:

     > LOOK
     You are standing at the end of a road before a small brick building. A small stream flows out of the building and down a gully to the south. A road runs up a small hill to the west.

     In some rooms or locations, there may be objects as well. An example is below:

     You are inside a building, a well house for a large spring. The exit door is to the south. There is another room to the north, but the door is barred by a shimmering curtain.
     
     

     The following object(s) are here:
     a set of keys
     a bottle of water.
     
     

     You can pick up the object (which in this case is a set of KEYS) by using the TAKE command. The TAKE command requires that you specify what object you’re taking, as follows:

     > take keys

     YOU HAVE TAKEN: KEYS You are here: Inside building. The following object(s) are here: a bottle of water

     > inventory
     THESE OBJECTS ARE IN YOUR INVENTORY: [KEYS]
     
     

     You can also drop an object that you currently are holding with the DROP command, which also requires that you specify what object you’re dropping. The object you drop will remain in the location you drop it, unless you elect to TAKE it once again.
     
     

     2.1 Adventure Files

     Every adventure game is driven by a set of files which the program uses to control its own operation. Each set of files that define a specific game will be located in a folder that bears the name of the adventure. If you run the program with different data files, the program will guide its players through a different adventure game.
     
     

     To indicate which data files you would like to use, the adventure program will begin by asking you for the name of your adventure. The starter folder also con- tains an adventure called ”SmallGame”; this contains files for a small adventure. To load this game, type ”SmallGame” as the name of your adventure. You can also download files for the original 1976 adventure game that was written by Crowther from the course Quercus website. For every adventure game that you can load, there are five text files that will be required, which are as follows:
     
     

     • rooms.txt, which defines rooms or environments in the adventure and the connections between them. In the example above, you visited three ”rooms”: ”outside of the building” and ”the top of the hill”.

     • synonyms.txt, which defines several words as synonyms of other words so you can use the game more easily. For example, the compass points N, E, S, and W are defined to be equivalent to NORTH, EAST, SOUTH, and WEST. Similarly, if it makes sense to refer to an object by more than one word, this file can define the synonyms.

       • objects.txt, which specifies the descriptions and starting locations of the objects (like keys) in the game.

       • introduction.txt, which holds an introduction to the game, and which will be displayed to the user at the outset of the game.

       • help.txt, which contains help information that is specific to a given game.

         
         Each adventure also contains a ’sounds’ folder which contains both long and short room descriptions in an audio format. Your program, once it is complete, will therefore be able to print word descriptions to the console and it will also be able to play room descriptions so they are audible. Again, note that you will be encouraged to enhance this game in your group project with other sounds, to make for a more engaging and accessible user experience.

         Your program must be able to work with any set of data files that adhere to the correct format. Your program should work correctly with this ”SmallGame” adventure as well as with other adventure game that you or your friends design. At the end of the course we will ask if you might be willing to share any original games that you script, so that others can play them as well.
         
         

       3 Adventure Classes

       The adventure game is divided into the following principal classes:

       • AdventureGame, which is the main program class; several public methods are specified in the starter files. You may add any additional private methods as you see fit.

       • Room, which represents a single room in the game. This class is also yours to modify. Again, the public methods used to communicate with other modules is specified but you can write the private methods as you like. This class is closely linked to the PassageTable class, which is provided as part of the starter project.

       • AdventureOb ject, which represents ob jects in the game. Again, public methods are specified.

       • Passage and PassageTable, which define directions of travel and the rooms one reaches by moving in those directions, as well as the various objects or Trolls that may block given passages. We will discuss Trolls in more detail later in this specification.

       • Player, which stores information about a given player (i.e. their current room and inventory).

         
         

         0. 4 To Dos

            In the AdventureGame class you will complete:

            1. The constructor, which should initialize relevant instance variables.

            2. setUpGame, which will populate the rooms, objects, help text, etc. from input files in the specified game folder.

            3. convertCommand, which will translate an input string into command to- kens, after applying synonyms. 
               

               4. executeAction, which will check if a given input is a valid action and will then perform the action. Actions that correspond to moves will be dele- gated to the movePlayer method, below.

               5. movePlayer, which will move a player in the direction specified, taking into account any passages that may be blocked. 

     
     

     In the AdventureObject class you will complete:
     1. readObject, which will will read and return a single object from an input buffer. This should throw FormattingExceptions appropriately.
     
     In the Room class you will complete:

     1. readRoom, which will will read and return a single room from an input buffer. This should throw FormattingExceptions appropriately.

     
     In the Player class you will complete:
     1. takeObject, which will add an object to the inventory of the player.
     2. dropObject, which will remove an object from the inventory of the player.
     
     

     Finally, we ask that you implement .... your own Troll! This will require that you:

     1. Complete the GameTroll class, which implements the Troll interface and lives in the Trolls package. Make it a simple Troll, or a complicated Troll; whatever you like! You can use your Troll in your Adventure game, or the default Troll as you prefer. Note that when you submit your code, we will ask if you might be willing to add your Troll to a Troll repository so that we can share your Troll with others in the class. More Trolls, more better!