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. 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. 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. To help make nicer graphics I'm providing an image editor and you can read the help on it.
The state of the game advances roughly 20 times each second. 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 the 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 easily see them in action. Below is a list of the main interfaces you will be implementing. There is also one class that you will be rewriting for the project. It is called GameSetup and it determines what actual classes are used in the game. By changing it to use your classes, you will effectively be making the game your own.
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 directly instead of extending types. Technically you could subtype this and override the important methods, but in some cases you are only doing partial method rewrites and this serves to help in that.
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 that could change nature if you have scaling 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.
Proviso for scaling
Part of what we study in this class is the efficiency of different algorithms and data structures. Because of the speed of modern computers, it can be difficult for you to actually see the speed differences between these things. In order for that to be noticable, the "input size" has to be quite large. In this project, the input size relates somewhat to the number of screens, but more directly to the number of entities in the game. This typically scales with the number of screens. For this reason, your program will also have a random mode where you can specify a very large number of screens and the program will use the screens you have designed, but link many of them together in a random way. This way you can do a run with tens of thousands of screens and entities without having to draw that many by hand.
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.