Project 6: MUD Game

In this project, you will design and implement a text-based multiplayer game, commonly known as a MUD (Multi-User Domain). Players will be able to connect to the game using their web browser, and play by entering commands into an interactive web application. Traditionally, the world of a MUD consists of a graph of interconnected rooms, as well as items and characters. Using text commands, players control characters, which interact with the world around them. Your system will include both the back-end world of the MUD, and the web server that provides a text interface to clients.

Examples of MUDs can be found at Top MUD Sites.

Purpose

The purpose of this project is to give you experience developing a program with a rich, relational state, and in particular:

• Using object models to explore the conceptual structure of a program;
• Designing, implementing and testing mutable datatypes;
• Evaluating the dependency structure of a program with a dependence diagram, and using it to guide design improvements

You will also become familiar with the fundamental architecture of a web server, and with the use of XML as a machine-readable interchange format.

Architecture

Your MUD will be played in a web browser, which means your game world will function as a component in a web server. The MUD game's user interface will be interactive, continually accepting the commands of clients, and dynamically update their browser pages with new messages. One standard way to do this is to design an AJAX web application (Asynchronous JavaScript And XML) that uses JavaScript code running in each client's browser window to send and receive messages after the page has been loaded. With this technique, the user's web browser becomes the interface for an interactive web application, with the web server acting as the backend.

We've provided you with the essential code for a web server infrastructure, which you have experimented with in the project lab. You are free to use this code in your project, modifying it in any way you please. You may also reimplement the infrastructure if you prefer (but we do not recommend that you do).

Server/Game Interface

Your project will consist of two components: a MUD game, and a web server that lets users play the game using a web browser. The design of both components is entirely unconstrained. However, an important criterion that will be used to judge your design is how well you have decoupled the game and server components so that it would be possible to reuse the game component with a different server (and perhaps not even in a web context).

Text Interface

The text interface should provide the functionality of the game to its players in a helpful and understandable manner. Players should be able easily to determine which actions apply at a given time, and should be notified of important events in an informative and entertaining way. Erroneous input should be handled gracefully.

The MUD World

You have complete freedom to determine the content and behaviour of the MUD world. To ensure that your MUD is sufficiently challenging to design and implement, it should include at least these elements:

• Players: Users must be able to connect using a web browser, create a named character and control it as it moves around and interacts.
• Bots: In addition to the characters controlled by players, the world should contain computer-controlled characters that act spontaneously, in response to in-game events or the passage of time. For example, a thief bot might move around the game world taunting other characters and stealing their items.
• Items: The game world should be populated with items, which are objects that characters can pick up and carry. Some of these items should be able to interact with the game world in interesting ways. For example, a key item might enable characters to access places in the game world that would otherwise be inaccessible.
• Places: The game world should contain multiple locations. One common model is to view the game world as a graph of rooms connected by doors, but this is by no means the only structure possible.

XML Configuration

The structure and function of the game world should be configurable with an XML file that is read on initialization of the game. For example, the XML file might specify the layout of rooms and their interconnections, and an initial placement of items and bots. At least one XML file that results in an interesting configuration should be provided.

Synchronization

The provided web server will create a new thread to handle every request it receives, meaning that if you use the provided infrastructure, multiple threads will be calling the ApplicationServer's methods. In fact, you should not only assume that multiple clients may make concurrent requests, you should also assume that a single client may make multiple simultaneous requests. (One way this might happen is if a user enters a message at the same time that the page is requesting new messages to render.) Therefore, your MUD application must have a synchronization model to ensure correctness.

MUD Fair and Staff Awards

On the final day of class we will be holding an exhibition in which you will have the opportunity to show your group's MUD to your classmates and to see what other groups did. The staff will award two prizes: one for best software design, and the other for best gameplay experience.

Milestone Meetings

Since no extensions will be permitted on this project, and the project is expected to be challenging, you will have to start early. Two required milestones have been established to help you and your partner get started:

• Meet with your partner during lab, and get checked off afterward. The last half hour (12:30-1:00) of the Friday lab session will be devoted to a meeting with your partner. You must attend this meeting, and use it to start your design. At the end of the lab period, you will have to find and brief a TA about the progress you've made. Examples of progress include preliminary design drawings, ideas for the theme of your MUD and the objects it will have in it, plans for how to divide up the labor, and a scheduled time when you will meet with your partner again.
• Meet with your TA on Monday or Tuesday of next week. You and your partner must schedule a meeting with your TA to discuss the progress you've made by early next week. Before this meeting, you should complete the Define and Design tasks (described below). Bring your design documents (problem object model, code object model, and dependency diagram) to the meeting, and be prepared to discuss them. You should also have a plan for division of labor between you and your partner (who's going to do what over the remaining week of the project).

1. Define. Decide on the rules and objects in your MUD, and construct a problem object model that captures your design.

2. Design. Construct a code object model that shows how your problem object model will be realized as Java classes, and draw a dependency diagram showing what dependences you expect between the classes. Your code object model need not include existing classes in the web server component, but your dependence diagram should show how the web server and game components are connected.

3. Implement. Divide your MUD's functionality into sets of dependent features, implementing and testing one set at a time. Start with the most basic set of features, and move on to the next set only when the current set is complete and tested. You will likely want to review and update your design models as you refine the design.

4. Test. Design and implement a test strategy for the game as a whole.

5. Configure. Construct at least one interesting XML configuration file that shows off the features of the MUD.

6. Demonstrate. Record an interesting and representative transcript of a user playing your MUD. Though the transcript should be from the perspective of only one player, other players can be present on the server to present a more complete view of the game.

Your deliverables for the project are:

1. The code for your system as a compilable Eclipse project, along with JUnit test cases and Javadoc for all your classes. All classes should have a rep invariant and abstraction function, explained informally and implemented in code.
2. At least one configuration file.
3. A text file named transcript.txt that provides a transcript of a user playing your MUD.
4. A text file named readme.txt that briefly describes the following:
   • your MUD's design and what features it supports;
   • each file you have created;
   • your synchronization strategy;
   • your testing strategy
5. PDF diagrams of your problem object model, code object model, and dependency diagram.

All files should be in plain text or PDF with appropriate filename extensions.

90% of your grade will be allotted to the software design and implementation, of which 50% will be allotted to code (half for structure and half for correctness), 20% to the design models, and 20% to the testing strategy, test cases, and test output. The remaining 10% will be allotted to the quality of your game design, with an emphasis on uniformity, elegance and power rather than domain-specific creativity.

• The gameplay of your MUD has been left largely unconstrained, in the hope that each group will take the time to design their own unique game. You might use the Wikipedia MUD page as a resource to see what types of MUDs have been created, and as a jump-start for your own creativity.
• There are some subtle and fundamental specification issues you will need to resolve. For example, what happens if a player discovers the proximity of another player or item, issues an instruction to perform an action on it, but it moves out of range before the action can be completed?
• Introduce concurrency with great care, and make use of simple and robust patterns to minimize the risks of races and deadlock.
• The Javascript in the sample web page doesn't just draw the incoming messages it fetches as plain text. Rather, the web page inserts the text into the HTML of the page, meaning that the server can send marked-up text, images, tables, and even Javascript of its own. This feature can be used for creative effect.
• One intriguing possibility is to mesh your MUD's game world together with an external source. For example, a room in your world could display images from flickr, or players could log into the MUD using their Facebook identities, with Facebook profile information being imported through the Facebook API.

• Top MUD Sites
• Wikipedia's page on MUDs
• HTML and CSS reference, for dressing up your MUD's output
• XML on Wikipedia