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. Normally each entity (and the player) will be one grid cell in size (you can get around this restriction, but it complicates your coding job). 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 and also customize a starter GameSetup class. 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 and class 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. To reduce the risk of your homework getting lost in my regular mailbox, I have set up a separate address for homework submission, cs1321@cs.trinity.edu. Please use this address for turning in homework, but for questions about the homework or other messages, use my regular address (bmassing@cs.trinity.edu). Mail to the cs1321@cs.trinity.edu mailbox will generate an automated reply, so you know it has arrived, but it likely will not be read until I start grading an assignment. 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 Together and the Javadoc standard make it pretty easy: When you write your code, you will include Javadoc-style comments. Together has a feature (similar to Sun's javadoc command) that takes these comments and your UML class diagram and turns them into HTML. (The API for the project framework was generated in this way.) From Together's toolbar, select Project, then Documentation, then Generate HTML. You will get a prompt box with some checkboxes and a space to type in the directory where Together will put the generated HTML.
First, unselect the ``Include navigation tree'' checkbox. It appears that this option causes Together to generate something that cannot be read by the default browser setup on our Linux systems.
Next, fill in the text field for the output folder (directory). 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. 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 assignmentt). 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).
If you have the ``Launch HTML browser'' box checked, Together is supposed to launch a browser to let you view the HTML it generates. This does not currently work on the Linux machines, so you should uncheck the box and launch a browser separately. (This is probably a good idea anyway, just to check that you have put things in the right place.) Point the browser at http://www.cs.trinity.edu/~yourusername/CSCI1321/HW1/Design. If you get error messages saying you don't have permission to access files, you should be able to correct this by typing (in a terminal window) cd /Local/HTML-Documents and then chmod -R go=rX CSCI1321. (Type man chmod to read more about what this does.)
Once you are happy with your documentation, send a message to cs1321@cs.trinity.edu with a subject line indicating the assignment and phase -- e.g., ``homework 1 design''. Please leave the documentation files in place for the rest of the semester so I can track your progress.
A final note about the format of the comments from which Together will generate your documentation: 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 the cs1321@cs.trinity.edu address (exactly what files are needed will be described in individual assignments). You may use either of the following methods to do this.
/users/bmassing/Pgms/cs1321/sendfiles assignment
where assignment is some text that indicates which assignment this is (e.g., ``hw2'' or ``homework 2'').
This script will e-mail all files in the current directory except the ones that I don't need or will recreate. It also sends a copy of the e-mail to your Trinity account, so you can be sure about what was sent.
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.
This section summarizes what you will do in each assignment. Follow the links for more complete descriptions.