CSE142

Homework #5

Octothorpia or is that "#-ia"?

Electronic turn-in for Part A due: Sunday, May 20, 10:00pm
Paper receipt due in lecture Monday, May 21.

Electronic turn-in for Part B due: Thursday, May 24, 10:00pm
No paper receipt! Grading (by demo) begins Friday, May 25.

The Task  Room Description  Part A Details  Part B Details  Supplied code and files  Your Writeup  Submission  Extras  Changes to GP142  Project Ideas  Announcements

"As you move forward into the dank, dark dungeon, you are greeted by an unpleasant odor. You conclude it is merely the must of the labyrinth and the leavings of the dungeon's denizens. You decide to ignore it and look about. The signs of previous struggles of earlier adventurers leave you with an ominous feeling. Pushing forward, you reach a gigantic oaken door set in a granite archway. The archway is covered with mysterious and cryptic runes, seething with magic. You hesitantly push open the door with the tip of your sword. You're greeted by a...

GP142 application?"

The Task

A MUD (or Multi-User Dungeon) is a multiple-user game that allows each player to run around, navigate mazes, solve puzzles, slay monsters, interact with each other, and generally have fun. Most MUDs are text-based, but some recent ones--like EverQuest, Ultima Online, or The Realm--are graphical.

We're going to make our own MUD. Players will be able to move between areas, interact with rooms, and maybe slay monsters (if someone writes monsters!).

Your job: write the code for a room in the CSE142 MUD.

You'll work in partners again for this assignment (but they must be different partners than HW4!). We're going to put everyone's rooms together in one big MUD and you'll be able to navigate it! The goal of this assignment is for you to put together all you've learned in creating a program you design. Other students will see your finished product, so try to make it kick butt!

Room Description

• Four doors. These can look like real doors, or portals, or an area on the screen labeled "This is a door". What's important is that you have four of them, and that they can be recognized as gateways to your area.
• Smarts to handle players entering and leaving.
• Some sort of puzzle. The puzzle could be a sneaky trick a player needs to figure out, or a game, or a simple exercise of mouse clicks. It's entirely up to you, but it must have a goal and your room must let the user know when he/she succeeds.
• Displayed instructions on how to play your puzzle and navigate your room. If there is a lot of text, you may consider implementing a "Help" button that brings up a description screen.
• Your names and your team name.

In order to allow the rooms to be put together in one large MUD, we needed to make a few minor changes to GP142. Please carefully read over the GP142 changes. The code that we are providing will compile and run fine on a Windows or XWindows system. Unfortunately, no Macintosh version is currently available! There are plenty of publicly available Windows machines in the IPL, however. The changes to GP142 also allow us to have your code talk to our server. Note: you will be graded on your room individually. You will not be penalized if your room doesn't work well over a network (but you must still adhere to the specification!).

Part A Details

For Part A, you need to extend the sample code. This entails:

• Correctly handling users entering your room. You'll need to store the users and their info in the players and lastClicks array.
• Correctly handling when a player clicks on a door to leave. You'll need to remove the player from the array without disturbing the other players. (But, keep in mind that requesting an exit and actually having the player exit are two different things! See the GP142 guide on player exits.)

Why you're doing Part A:

• To begin thinking about your project.
• To familiarize yourself with the GP142 changes.

Part B Details

Part B requires you to fully implement your room idea. For compatibility with the MUD, each room must:

• Support up to MAX_PLAYERS players. This is a constant defined in GP142.h, and your room must correctly handle any number of players up to that many.
• Have four doors. They are numbered by the GP142 constants NORTH, EAST, SOUTH and WEST.
• Allow a player to enter by any of your four doors.
• It should be possible for any player currently in your room exit via any door. (It's OK if the player needs to work to get to those doors though!) Additionally, you must allow for players to "teleport" out. (This is to support "restarts" in the networked version; so, this must work at any time in your room.)

Use whatever you'd like from Part A to assist your development of Part B. However, Part B is not a simple extension of Part A as has been the case on previous assignments.

Supplied Code and Files

We are providing a basic framework for Part A of this assignment. The framework has a main event loop, some helper functions, and some TODO markers for part A. You must work from this for Part A, but you're free to do whatever you want (subject to the guidelines above) for Part B!

There are a number of acceptable project ideas and some sample solutions on the HW5 ideas page.

Your Writeup

In both parts, your README needs to include the following information:

• Your name and your partner's name
• Your student ID and your partner's student ID
• Your section and your partner's section (if different than yours)
• Approximately how many hours each of you and your partner spent on the assignment
• A breakdown of the work each partner did
• Acknowledgment of any help (other than the lectures/sections, the staff, or the course textbook) you received.
  Note: acknowledging cheating does not stop it from being cheating!

For Part A:

• A complete description of the puzzle your room will implement. The object of your puzzle, a description of what it will look like, and the solution to your puzzle should all be included.
• The help text that will be displayed in your room (i.e., the game instructions).
• You won't be submitting this in your README, but we'd like for you to draft and turn in a call graph of the functions you plan to write. Just think about your functions and how they should interact with each other, and then graph your thoughts out. You don't have to include GP142 function calls on your call graph (but certainly could if you'd like).

For Part B:

• If you had were to go back and redesign your project, what would you do differently and why?
• How did your finished product differ from the plans you had in Part A? Did you modify your design (call graph) a little or a lot? Why did you make those changes?
• What was the most interesting data structure or combination of data structures you used? How did you use it (them)?
• What did you enjoy about this assignment? What did you hate? Could we have done anything to make it better (either the assignment itself or the way we handled handing it out, clarifying it, or turnin procedure)?

You will only need to turn in one assignment for your team on Part A and one assignment for Part B. Only one person will need to fill out the web submission form, and only one will need to turn in your paper receipt (for Part A only).

Here are the turnin forms:

This project is open-ended enough that you should be able to think of all the enhancements you may desire. Email your TA for suggestions if you'd like more ideas! If you get done and submit a working (if not final) Part B by the Sunday deadline for Part A, we can even include you in the beta version of the MUD!

Oh, and PS..