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?"
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!
A room in our MUD is really just an area that you get to
create. What defines a room will be its doors and its
ability to handle users. Each room must include:
- 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!).
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.)
Basically, we want your Part A to do the same thing the Part A sample solution does. Check the hw5.c file
and scan for TODO's. They should point you on your way to getting
Part A finished.
Why you're doing Part A:
- To begin thinking about your project.
- To familiarize yourself with the GP142 changes.
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.)
Those are the nitty-gritty details. The high-level picture is that
you'll need to implement your puzzle, and allow the player(s) in your
room to play your puzzle. If it makes sense for your particular
puzzle, you might also have an option allowing the players to reset
your room so they can play the puzzle again from scratch.
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.
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!
hw5.exe |
Self-extracting archive for MSVC. |
hw5.c
GP142.c
GP142.h
GP142LIB.h
|
Files for non-MSVC setups.
Important: You'll need these versions of the GP142 files. They've been
modified to include the MUD extensions.
|
There are a number of acceptable project ideas and some sample
solutions on the HW5 ideas page.
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).
You will not have to strictly adhere to this description or call graph
when you begin programming Part B. Part B will probably evolve into
something different once you begin working on it, but hopefully your
code will have something to do with the description and/or call
graph you turned in with Part A!
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)?
Submission
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:
Looking for more?
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..
Do you want your room to end up close to someone else's? Or to your
whole sections' rooms? Well, no guarantees, but try this: write three
haikus describing your experiences in CSE142 this quarter, on HW#5,
and your feelings about Dutch's hair. Try to make them as wierd as
possible (use bizarre or even made-up words!). Now, have you and
everyone you want close to you append your three haikus to your
READMEs for Parts A and B. Why would this possibly make any
difference? Ask Steve if you're really curious, but be prepared to
learn strange and wondrous facts about natural language processing!