Ninth Assignment, due 9th December 2002

Ninth Assignment, due 9^th December 2002

Electronic Submission, hw9

Submission Requirements: You must turn in a reasonable preliminary version by the main due date (9th December); this version may have a lot missing from it, but may not be just rubbish hacked together at the last minute, it must fundamentally work. If you meet this deadline, you may turn in a proper version on 16th December. Both versions should be submitted as hw9. The reason for this requirement is to ensure that you do not spend valuable time in the exam period working out how to do an assignment, you will only be making improvements to something already worked out.

The Assignment

Write a text-based adventure game. For a sample, log in to rabbit and type this command: ~data/game (note the wiggle at the beginning). Your game is not supposed to be exactly like this, which is just a simple demonstration to give you the idea. You can make the game be whatever you like. There are a number of requirements for how the programming is done, but very few requirements for how the game should play. To see the text file that defines the artificial world used by the demonstration program, follow this link. You absolutely do not have to use the same format as this file, it is for demonstration purposes only.

Requirements

A (simulated) little man/woman/robot/whatever should move around in an artificial world, under the control of a user. The user may type simply commands to tell the robot to do simple things, like moving in a particular direction or picking up an object.
Every time the robot moves to a different location, the program should print a description of that new location, together with any objects it contains.
The robot should be able to pick up objects in the current location (perhaps with weight limits) and put down objects in the current location.
When the robot moves to a new location, whatever it is carrying of course goes with it.
You should be able to put an object in a location, go away, come back later, and find the object still there (unless it has moved for some good, extra-credit, reason).
There should be no practical limit on the number of locations, the number of objects, or the number of objects in any location.
The entire artificial world should be completely defined by a text file. If somebody wants to completely change the world, they should only have to change the text file that describes it. There must be no need ever to edit the program.
To a certain extent, how you implement the game is up to you. Of course you must use good programming techniques, and it would be a good idea to make use of some of the things we have been studying in class (this assignment is designed to benefit from such things).
You must define class/struct/object types to represent locations and objects. When the program starts up it should read the text file, create all the appropriate objects in memory, and start accepting commands. Ideally, if there is anything wrong in the textfile, it should be reported as an error.

Extra Credit Possibilities

(some easy-ish, some difficult)

Do something clever with the programming.
When the user exits from the game allow (perhaps as an option) the text file to be overwritten with the current state of the game, so that next time it is played everything starts up from where you left off (objects in locations, etc)
Implement Monsters: objects that move around and do things all on their own, perhaps attacking the robot, perhaps moving objects when nobody is looking.
Make there be some goal to the game, so that plyers can win, or keep a "high score".
Make the descriptions that are printed seem natural, like well-written prose, adapted to conditions.
Implement windows (that can be seen through, but not walked through), and/or doors (that can be opened or closed and locaked or unlocked)
Make the robot accept instructions in a more natural way, like normal spoken English, rather that one word commands.

New Tricks

Unpredictability

To make things happen unpredictably, all you need is a ranom number generator. If you #include<stdlib.h> you can use the function random() it takes no parameters, and delivers a random int between 0 and 2147483647. If you want a random number between 0 and 6, just calculate random()%7. If you want something to happen with a 1-in-7 chance, say if (random()%7==0) something; Here is a small example program.

Normally the numbers aren't really random. Each time you run a program, random() will produce exactly the same sequence of 'random' numbers. That is a good thing. It means behaviour will be reproducable, whih means things are much easier to debug. Once you beleive it works, you can make the sequence really random by calling the function srandomdev(). Just call it once at the beginning of the program, not every time you use random().

Asynchronicity

For a technique that allows things to happen behind the scenes in a program, without any input from the user (e.g. how to make monsters move around unexpectedly) look at this little program. The method it uses will only work on unix systems, not windows. You can run the program, it is perfectly safe. When it is running, type very slowly: let it run for a few seconds before giving up and thinking nothing will happen.

There are two special functions involved (note the two new #includes too): alarm(x) tells the system to send your program an alarm call in x seconds (x has to be an int). signal(SIGALRM, fff) tells your program what to do when that signal arrives. SIGALRM is the official unixy name of the signal, fff is the name of a function defined in your program (it must take one int parameter (which will be useless to you, but it must be there), and return nothing). When the alarm signal arrives, your program will suspend what it is doing, run that function, then resume what it was doing, even if it was in the middle of waiting for user input, and even if it was in the middle of a long calculation. The function can do absolutely anything, but you need to be careful: if the function modifies some data that the program was already busy modifying when the alarm arrived, the results could be unpredictable.