The assignments for this course are all parts of a single project that spans the entire semester. For this project you will write code that integrates with code written by Dr. Lewis. His code forms a framework for arcade-style games, but is flexible enough to allow for a lot of variation, so you have considerable freedom with regard to exactly what kind of game you want to create. This page outlines the game framework and describes other requirements common to all the assignments.
The game that you will be writing is what you might call a screen-based or arcade-style game. Your game will have a ``player'' character controlled by the human player. The player moves around a playing field consisting of one or more two-dimensional ``screens''; the screens can be linked together such that when the player moves to a particular part of a screen it automatically jumps to another screen. Each screen is composed of a regular grid of blocks; blocks represent different things that the player character can interact with -- floor, walls, ladders, etc. You can have as many or as few kinds of blocks as you need for your game; blocks represent things that do not move but can change based on the player's actions (though this imposes other restrictions). In addition to the human-controlled player character, the playing field can be populated by other characters or entities. These entities can move around the playing field and interact with the player and each other. You can have as many or as few kinds of entities as you need for your game. It is simplest to make each entity (and the player) one grid cell in size, but recent changes to the framework allow some flexibility in this regard. You will have access to two tools, a ``screen editor'' program program to lay out the playing field and an ``image editor'' program to create graphics for your blocks, player, and other entities.
The state of the game advances roughly 20 times each second; we'll call this interval a ``tick''. Each entity (including the player) has a method that gives the next tick in which it wants to be updated and a method that describes how it should be updated. Using these methods, on each tick the game framework identifies all the entities (player and others) that want to be updated in that tick and then updates them.
You should note that there is a lot of flexibility here, and you have significant control over exactly what you produce in the end. I encourage you to be creative, but remember that you need to be able to implement your design, and it will probably be more satisfying to finish something not too complicated than to tackle something overly ambitious and not be able to finish it. If you want to try something ambitious, try to think of a way it can be scaled back into something still playable if the original design turns out to be more difficult than anticipated. I also encourage you to focus your creativity on functionality rather than appearance; your grade will be based mostly on functionality, and I think you will learn more by making your game do interesting things than by focusing too much on the details of appearance.
To write your game, you will need to create subclasses of several interfaces defined as part of Dr. Lewis's game framework. If you do this, your code will fit together neatly with the framework code that defines the main GUI for the program and provides the 20-updates-per-second functionality, The main interfaces for which you need to write code are as follows. Refer to the project framework API for details.
Each assignment consists of two phases, design and code. For each phase, you will turn in something by e-mail, which you should just send to my regular e-mail address (bmassing@cs.trinity.edu). When you do this, please use a subject line that mentions the course number and which assignment you're turning in (e.g., ``csci1321 hw1 design''). Assignments are due at 11:59pm on the date given on the ``Lecture topics and assignments'' page; I will use the timestamp on the e-mail to determine whether they are on time.
You will be turning in design documentation prior to every assignment for this class. You will also turn in modified/finalized designs when you turn in each of the assignments. This sounds like it might be a lot of work, but with Java documentation comments and Eclipse it is pretty easy. When you write your code, you will include documentation comments (``Javadoc comments''); you can then use Eclipse's built-in feature or the javadoc command to turn these comments into HTML. (The API for the project framework was generated in this way.)
To make it easy for me to find everyone's documentation, I want you to put yours in a specific place in your home directory on the department's Linux fileserver. (You can have Eclipse put it there directly, or you can copy it there later.) Anything you put in Local/HTML-Documents in your home directory can be accessed from the Web (assuming it is world-readable). Within this directory, create a subdirectory CSCI1321; within CSCI1321 create directories HW1, HW2, etc. (one for each assignment). Within each of these directories create directories Design (for the design phase) and Final (for the code phase). So, for example, your documentation for the design phase of Homework 1 should go in Local/HTML-Documents/CSCI1321/HW1/Design. Notice that case is significant on Unix systems (e.g., Design and design are different). To make everything in this directory world-readable, you can use the following command (from a terminal window):
chmod -R go=rX CSCI1321(Type man chmod to read more about what this does.)
To check that you've done everything right, point a browser at http://www.cs.trinity.edu/~yourusername/CSCI1321/HW1/Design.
Once you're happy with your documentation, send me e-mail telling me your design is ready to be graded. Please leave the documentation files in place for the rest of the semester so I can track your progress.
Notice that unless you want your code to also be world-readable (which I think you don't at this point), you probably should not put it in Local/HTML-Documents.
A final note about the format of the documentation comments: Since they will be turned into HTML, you can use HTML tags to do any formatting. For example, if you want multiple paragraphs, you can get this by enclosing each paragraph in <p> and </p> tags. If you know more HTML, you can incorporate additional formatting such as tables, if you think that will make your meaning clearer.
For the code phase of each assignment, you will be turning in code and also generating a final (for that assignment) version of your documentation. To turn in code, I want you to e-mail all the relevant files to me (exactly what files are needed will be described in individual assignments). It is probably simplest to just use your favorite e-mail program and attach the desired files as attachments. Please do not try to cut and paste code into the body of a mail message; this is not only tedious but often results in garbled code.
If there are so many files that this becomes tedious, it may make sense to just send me your whole Eclipse project for an assignment. An easy way to do this under Linux (and this should work under Mac OS X too), is to (in a terminal window) cd to your Eclipse workspace directory and then use the tar command to create an archive file. If your project is called AssignmentN, typing
tar czf assignmentN.tgz AssignmentNcreates a file assignmentN.tgz containing everything in directory (project) AssignmentN. (Type man tar to read more about what this does, and tar tzf assignmentN.tgz to get a list of files in the archive file.)
You can then send me the single file assignmentN.tgz.
To include only the Java source files, you can do this slightly more complicated version:
tar czf assignmentN.tgz `find AssignmentN -name "*java"`(Notice that the outermost quotes are backquotes.)
This section summarizes what you will do in each assignment. Follow the links for more complete descriptions.
Creating a project using Eclipse was demonstrated in class. Some things to keep in mind:
Remember, too, that you can compile and run Java programs and even generate HTML documentation using command-line tools, if for whatever reason you can't or don't want to use Eclipse. See Java Without an IDE for details. If you do this, the next time you open the project with Eclipse, it should pick up any changes you made with other tools. (If it doesn't seem to, right-click on the project name and select Refresh.)
Dr. Lewis has written two programs that you may find helpful, a ``screen editor'' program program to lay out the playing field and an ``image editor'' program to create graphics for your blocks, player, and other entities. To run one of these programs, you have two options:
java -classpath .:jarfile.jar edu.trinity.cs.gamecore.ScreenEditor yourscreenclass binfile
for the screen editor, or
java -classpath jarfile.jar edu.trinity.cs.gamecore.ImageEditor
for the image editor.
jarfile.jar is the JAR file for the assignment, yourscreenclass is the fully-qualified name of your screen class (e.g., edu.trinity.cs.yourusername.YourScreen), and binfile is the file where you want to store the results (for the screen editor only).
(Of course you won't want to type this in often; if you want to take this approach, ask me how to make a small script or alias so you don't have to type the whole command every time.)