The assignments for this course will be part of a single project that spans the entire semester. For this project you will write code that integrates with code that I have already written to implement a game. The exact design of the game will be quite flexible so you will have significant freedom in deciding what type of game you want to actually create. There are restrictions on what you can produce. This page outlines those restrictions and what the basic requirements are for the game that you create.
Project requirements
The game that you will be writing is what you might call a "screen" based game. Your game will have a character that the player controls and moves around on various screens (some games do not have the player appear as a visible entity). The screens link to one another such that when the player moves to certain portions of a screen he/she will be taken to another screen (some games only involve a single screen and this is not an issue). Each screen is composed of a regular grid of blocks where each block can represent different things that the player can interact with (floor, wall, ladder, etc.). The only limitation on these things is that they are fixed in location (you could have some that change their nature depending on player actions, but this causes some other restrictions for you). Each screen can also be populated by various entities. One of these will be the player, but there can be others. These entities can move and interact with the player as you decide fit. All entities, including the players are only one grid cell on the screen (you can avoid this but I don't recommend it). This is more to simplify your life than anything else. To help with "drawing" the screens for your game I am providing you with a screen editor.
The state of the game advances roughly 20 times each second by default but this is a setting you can change. This time interval is what can be called a "tick". Each tick, the part of the code that I have written will go through and find all entities that have "said" they need to be updated in that tick. It will call the update method on each of those entities. Each entity then is placed back on a priority queue at a position corresponding to the next time it needs to be updated.
You should note that there is a lot of flexibility here. You have significant control over exactly what you produce in the end. I encourage you to be creative in this, but keep in mind that whatever you decide upon, you need to be able to implement it. Also, don't spend all of your time making it look pretty, your grade is based upon funcionality first.
General layout (Javadocs for the project)
To create your game, you will be making your own subclasses of a number of interfaces that I am giving you. I have written the main GUI for the game and other tools that are designed to interact with objects following those interfaces. By writing classes that use those interfaces they will plug easily into what I have written so that you can see them in action. Below is a list of the main interfaces you will be implementing.
GameSetup - This class is what is used by the code that I have written to decide where to get the main pieces of information that it needs. This is the one place where you will actually be editing code that I give you. You should make your implementation of this be a singleton class (a class that only allows one instance of itself to be made). The reason for this is that you will need to access parts of the GameSetup object from many locations in your code.
Screen - You will likely create one single subclass of this interface that will represent all of the screens in your game. It basically gives access to a two dimensional array of Blocks that define a screen and a list of the Game Entities that are on it.
Block - You will likely create several subtypes of this. They are simple classes that represent the building pieces that you will make your screens out of. These can't move, but they could change nature if you have draw optimization turned off.
GameEntity - This interface represents anything that is dynamic in your game. If it changes form or moves during the game it will be a subtype of GameEntity. You will create several subclasses of this as part of the creation of your game.
Player - You will make one player subclass. It is also a subclass of GameEntity.
Note that pretty much all of these things are generic and they have to be provided with two types: a Block types and a Game Entity type. For this reason, you will wind up creating a type that is a supertype for all the Blocks and all the GameEntities in your game. Methods that are specific to your game can be put in these types.
Design Submission
You will be turning in design documentation prior to every assignment for this class. You will also post modified/finalized designs when you turn in each of the assignments. This might sound difficult, but Eclipse and the Javadoc standard make it quite easy for you. Just go to Project > Generate Javadocs under the menu when the project or package is selected. Don't have a single file selected or you will get javadocs for that one file only. This will ask you for a directory to output the documentation in and you can pick the first javadoc or the first Eclipse option. To make it easy for me, I want you to follow some simple rules for posting this documentation. I want all of it to be in web directories on the CS machines. This only applies to the documentation, your code should not be placed there. Anything that you put in the Local/HTML-Documents directory on your account is generally visible to all users. You will also need to make sure that all files are world readable and all directories are world readable and executable. You can use "ls -l" to see if it is automatically the case. If not, use the chmod command to set those rights. chmod a+r * in a directory makes all the files world readable and chmod a+rx dirname makes dirname readable and executable (man chmod for more info). You could also set all right recursively through directories (Eclipse does create subdirectories) using a command like chmod -R go=rX PAD2Project/Assn1.
I want you to use very specific naming and organization to help make my life easier. Create a PAD2Project driectory under Local/HTML-Documents. In it you will make directories named Assn1, Assn2, ... Inside those you should have a Design directory and a Final directory. The capitalization does matter. The documentation that you generate for your design submission should go in the Design directory. What you generate from your final code for the assignment goes in the Final directory. You should not alter your design after it is posted. Any alterations you make can be put in the Final directory. You will leave all of this up the entire semester so that I can see the progression of your project through the semester.
As a note on the design documents and formatting. If you are fluent in HMTL you can put HTML tags into the comments in your code and add things like tables or other special formatting. If you want multiple paragraphs then using <p> and </p> and force that the way you want it.
You will be able to use the same program to check your grades and submit your assignments for this class. There is a web interface available for checking the grades, but the submissions can't be done through an applet. To do the submissions you will need to run the program directly. There are many ways that you can do this. If you are on a CS machine, you can run /users/mlewis/Local/HTML-Documents/Grades/GradeCheck.sh from the command line. Alternately, you can run the program from any installation of Eclipse by adding the GradeCheck.jar file into your project. That file is in /user/mlewis/Local/HTML-Documents/Grades or http://www.cs.trinity.edu/~mlewis/Grades/GradeCheck.jar if you pull it off the web for home use. If you run it under Eclipse, you want to run the main in SubmissionApp and you have to give it one command line argument: rmi://titania.cs.trinity.edu:1099/SubmitServer.
Once you have started the program, it will bring up an interface that asks for a username and password. Use your standard Linux username. Your password on this system starts off as your student number. You can change it and you probably should. Once you have logged in you will get a list of the courses you have on the system. Simply double click on one or select one and choose View Section to see your grades. While that is up, you can also click on the cell for one of the coding assignment. To submit code you either double click it or do Edit > Submit. This will bring up a dialog box for doing the submission. Currently the only options from it that work are Select Files and the two Submit Options. Because you can't test there is little reason to submit something for testing. When you select files you can either select the files you want to submit individually, or just select the directory that you want to submit. It will show you what files you have selected in the tree display. Clicking Submit for Grading will send it to me. You can do multiple submissions, but I'd ask that you not abuse that fact. My computer will record the time of each submission, but submissions you make after the deadline could result in a late penalty.
Assignment Descriptions (click the link at the beginning for a more complete description)
#1 - Main - For this assignment you will be writing the main routine for your program. This will be a very simple class that you create that initiates the game itself and it is primarily intended to give you a little experience in writing a simple Java program.
#2 - Screen, some Blocks, and GameSetup classes - In this assignment you will begin to personalize your game. This is where you need to begin thinking of the design for what you want to create. You will modify the GameSetup class so that it uses a few of your classes. In particular, it will begin to use your version of the Screen class. In order for that to work you will have to have some subclasses of the Block class for your screen to be composed of. For this assignment you only need two Block types and the Screen only has to handle those two. For the Block graphics I will provide some code that allows you to do some simple graphics.
#3 - Player - Now you will add your own subclass of the Player class. This will be the single largest class you write. For this assignment you will put in some code so that it can interact with the blocks that you wrote for the last assignment.
#4 - GameEntities and EntityList - Here you will write the subclasses of GameEntity that you need for your game and add an EntityList class that will be a member to your Screen class for keeping track of the entities on each screen. You will have to extend your Player class to handle interacting with these entities. The Entities added at this point can be stationary though having one or two that move would help out for the next assignment.
#5 - PriorityQueue and Moving Entities - For this assignment you will implement your own subclass of PriorityQueue and have your GameSetup use it. At this point you also need at least one moving entity that gets updated every so often and does certain things. Animated entities would also work well here. If you can get multiple moving entities working, that would be good, but you have to have at least one.
#6 - Game Status Panel and Edit Properties Panel - This assignment has you writing some GUI components. One of hte things you will write is the Game Status Panel returned by your player which gets put at the bottom of the window to show things like score, lives left, etc. You will also write code so that at least one of your GameEntities will have a property panel that it can be edited with in the game editor. Since you also have a bit of knowledge about drawing graphics in Java, you can make it so that these panels include some custom graphics that go beyond just putting components into them. You can make custom components (extend JPanel or something similar) that have overridden paint methods that explicitly draw what you want them to see.
#7 - Heap based priority queue and "random" maze generation - For this assignment you will write a new priority queue that is more efficient than what you had written previously. You will also write a method to randomly generate a "maze" of abritrary size so that you can test out the scaling on this.
#8 - Final touches on the game - In this assignment you will go through and make your game more playable and better looking. When you turn this in you should have something that can actually be played and hopefully it won't hurt too much for someone to do it.