XML Processing - a text game

Design due Oct 16

Partially Working version Oct 21

Complete Version Oct 28

Goal

To learn how to process XML by creating a text adventure game like Zork.

Introduction

For this assignment you will create a program for a game like Zork. Zork was one of the first interactive role-playing, text based adventure computer games. You can place it here: http://zorkonline.net/

You will design a simpler variant of this game which will be able to read as input an XML file with complete information of a specific adventure and create the set of objects to interact with the player in that environment.

This specification is given "as it is". If anything is incomplete, inconsistent, or incorrect, please explain your interpretation or improvement of the specification in a document that you turn in with your assignment.

One of the goals of this assignment is to provide you with an opportunity to learn how to handle an imperfect specification, as all specifications are eventually found to be.

Aou may ask the course instructor about what things mean, and you may discuss any part of this assignment with your classmates or others, including tools, algorithms, what a pain it is, and so forth. You must write your own code however -- code sharing is strictly forbidden.

You can find a simple start of the game in Python here: https://repl.it/@JimSkon/ZorkDemo,

Or in C++: https://repl.it/@JimSkon/ZorkDemoC

This includes starting XML. TheXML

Here is a sample run through of the game: SampleRunThrough

Commands in the game

  • n, s, e, w - movement commands to put the player in a different room. If a room is bordered in the direction indicated, the description of the new room is to be printed to the screen. Otherwise print "Can't go that way."
  • i - short for "inventory", lists all items in the player's inventory separated by commas (if more than one). If there are no items in the inventory, print "Inventory: empty".
  • take (item) - changes item ownership from room or container to inventory. If successful print "Item (item) added to inventory". (Hint: this can be written as shortcut for put command)
  • open (container) - prints contents of container in format "(container) contains (item), (item), ..." and makes those items available to pick up. If empty, should output "(container) is empty."
  • open exit - if room is of type exit prints "Game Over" and gracefully ends the program.
  • read (item) - prints writing on object if any available, else prints "Nothing written." if command is executed on an existing item in the player's inventory that does not contain writing.
  • drop (item) - changes item ownership from inventory to present room and prints "(item) dropped."
  • put (item) in (container) - changes item ownership from inventory to declared container if container is open and prints "Item (item) added to (container)."
  • turn on (item) - activates item if in inventory printing "You activate the (item)." and executing commands in "turnon" element.
  • attack (creature) with (item) - prints "You assault the (creature) with the (item)." and executes "attack" elements if item matches creature's "vulnerability" and existing conditions are met.

Behind the Scenes Commands

  1. Add (object) to (room/container) - creates instance of object with specific owner (does not work oninventory)
  2. Delete (object) - removes object references from game, but item can still be brought back into the game through the 'Add' command. Rooms will have references to them as 'borders' removed, butthere is no means at present for adding a room back in.
  3. Update (object) to (status) - creates new status for object to be checked by triggers
  4. Game Over - ends game with a declaration of "Victory!"

Order of Operations

When the user enters a command:

  1. Check if command is overwritten by any triggers.
  2. Execute command if not overwritten.
  3. Check if effects of command activate a trigger.
  4. If so, continue to check if new status effects activate additional triggers ad infinitum.

Objects

If element is followed by [ ] there may be multiple objects.

  • Room - may contain the following elements: name, status, type, description, border[ ], container[ ], item[ ], creature[ ], trigger[ ]. Type is assumed 'regular' unless specified.
  • Item - may contain name, status, description, writing, status, turn on, and trigger[ ]. If item has turn on element and "turn on" command is issued by user, action elements in 'turn on' are to be executed if any given conditions are met.
  • Container - may contain name, status, description, accept[ ], item[ ], trigger[ ]. If an 'accept' element is added, only specific items may be put into the container and the container need not be opened to insert them (cannot be opened until one of those items is inserted, in fact).
  • Creature - may contain name, status, description, vulnerability[ ], attack, trigger[ ]. If "attack" command is issued by user with creature's vulnerability, action elements in 'attack' are to be executed if any given conditions are met.

Special "Objects"

  • Triggers - contains one or more condition including special conditions of type command (all of which need to be satisfied for the corresponding actions to take place), type, one or more print, and one or more action. Type is assumed to be 'single' (only used once) unless specified as 'permanent' (unlimited use). Order of execution is to output any 'print' action first, then other 'action' commands in the order given in the file.
  • Possible conditions: owner, status
  • Possible commands are any user command, recognized for the entire string (i.e. take sword). The trigger will pass the 'command' portion of of it's condition if there is no command element or if any one of the command element's contents are matched.
  • Owner - will have object, has, and owner elements. Status - will have object and status elements.
  • Also, context is very important. Only triggers in the present context of the game should be checked. This includes the inventory, the present room, and any items, containers, creatures, and items in containers in the present room. The actions those triggers perform, however, can act on any object in the game.

XML Formatting

Root element:

Each type of object will have elements associated with their given descriptions above with the addition of a 'name' element.

Triggers will have the additional complexity of containing a condition and action elements, with the condition having three additional elements to create an 'if' statement of the form "if (object) is/isn't in (owner)" with the is/isn't being determined by the element.

Grading for Part One (Design)

Give a complete Object Oriented Design, using Lucidchart. Include all data structures for storing game data.

Requirement Points Comments Score
Class diagrams for each class 20    
Specification of variables in each class 20    
Specification of each method in each class (name, funciton, parameters) 20    
Diagram showing and explaining relationships amoung classes (composition, interaction, inheritance) 20    
Explainations of any data structures to be used 20    
Total 100    

Grading for Part 2 - Partial Functionality

An working implementation of the Object Oriented Design

The system must fully support at least 5 of the 10 basic game commands:

  1. n, s, e, w
  2. i
  3. take (item)
  4. open (container)
  5. open exit
  6. read (item)
  7. drop (item)
  8. put (item) in (container)
  9. turn on (item)
  10. attack (creature) with (item)
The game should have support for all 4 object types:
  • Room, Item, Container, Creature

You should have XML to support at least 3 rooms, and three of each kind of object.

Grading On complete Game (total 200 points)

Function (100)

I will ask you do demo these actions on your program during the time you set up to do this.

Requirement Points Comments Score
rooms - movement between entrance, regular room(s), and exit 24    
items - take/drop, read, turn on, and add/remove 24    
containers - take, put in, open, restrictions (accepts element) 16    
creatures - attack and add/remove 8    
triggers - permanence and activation with each other object type 28    
Total 100    

Design (100)

Requirement Points Comments Score
Complete class implementation - should completely impliment you class design 25    
Functionally modular. Functions should be concise with a single cohesive operation. 25    
Commenting: Headers on all functions, commenting in code as useful. 10    
Good Variable Names/Function names 10    

Complete. Must have 10 rooms, 12 items, 5 containers, 5 creatures, 8 triggers.

30    
       
Total 100    

NOTES

Commands are case sensitive.

Triggers always take precedence over default actions, and are only relevant in their given contexts (ie

trigger associated with a room should not be tested if player is not in that room). When testing for triggers,

test only triggers of objects in your present context (present room, objects in present room, objects in

containers in present room, inventory), however, they can affect any object in the map.

Initial room will always be named "Entrance".

If an error message is not specified, the general error message is "Error".

Tips

A good structure might have classes corresponding to each object type, with all objects inheriting from a

common class which can be searched for triggers

your project! It is for ease of reading only!!!

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2019-10-17 - JimSkon
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback