Homework 9: Make Your Own Game

xkcd game pointers
Component Due Date
Project proposal document Tuesday, April 19
Project code and README document Tuesday, April 26
Game demo to your TA Reading days (April 28-29)

Assignment Overview

In this assignment, you will be creating your own game using the Java Swing GUI framework. Though you will be choosing the game and implementing it from scratch, your implementation must be well-designed and integrate several programming concepts from this course. Use this project as a chance to show off everything you’ve learned, and to build a large-scale application of your own design. You will be demonstrating your game and explaining your program design to one of your TAs in a one-on-one session during reading days.

Have fun doing this assignment! This has historically been students’ favorite project of CIS 120, and you are more than welcome to go a little overboard if you would like. Many students invent a totally new game as part of this project, and these are always a ton of fun to show off.

Project Requirements

You are completely free to either choose to implement an existing game or to come up with your own, unique, super-awesome game.

No matter what kind of game you build, it must meet the following criteria. For each of these criteria, you will receive an implementation score and, possibly, an explanation score. The implementation part of your score will be based on our evaluation of the correctness of your code. The explanation part of the score will be based on your justification of core concepts (explained in the section below) and your explanation of how the code works during the demo session.

NOTE: Your code must compile for you to recieve more than 16% on this assignment! Do not wait until the last minute to make huge changes to your code, and make sure you save working versions as you progress through your implementation.

Part 1: Project Proposal

A component of your grade for this assignment will come from a project proposal which you will submit in advance of the project deadline. As you come up with game ideas, and as you choose your design concepts, you must attend office hours to verify with any TA that your choices are valid. This is the only (reqiured) way to get feedback on your proposal before you start implementing your game. If you cannot make it to any of the office hours before the proposal is due, you can reach out to your recitation TAs and set up a special meeting time. Overall, you will use the proposal to document your initial design process and plan your implementation.

Your proposal will break down into two main sections.

  1. A description of how your game will be structured. Outline any classes and interfaces that you plan to use. Provide justifications for your proposed design. If you are planning to use any collections, make note of those and justify your choices.

  2. An explanation of which core concepts you will be using. Your explanation for each concepts should indicate what feature of your game takes advantage of this concept.

Your game should demonstrate that you have a practical understanding of the core concepts you learned this semester. To do this, think about a few of games you might want to implement, and break each of them down into the concepts they demonstrate.

If you can’t think of four, or at least three, don’t give up! Ask on Piazza or in office hours how you might extract more concepts from the original game you’ve chosen, or what features you might be able to add.

It’s important to choose the game that you feel would allow you to focus on demonstrating your knowledge. A poorly designed implementation of a complex game is worse than than a well-done implementation of a simpler game.

Example Proposal

You can find an example game proposal which we have written for the game Tetris. Note that because we have used it as an example, you are not allowed to choose Tetris for your game.

Writing your Proposal

Open the proposal template document provided in the assignment download, and answer the questions it contains. You should submit this in the “hw09prop” assignment by the proposal due date.

Design Concepts

Decompose your game design so that it makes use of four of the following concepts. Justify your choices in the game proposal document. You are free to choose any four distinct concepts from among the "core" CIS 120 concepts and those more specific to game design, though a typical game implementation will rely on two or three "core" concepts and just one or two "game" concepts.

Core Concepts from CIS 120

These concepts have been covered in class or in past homework assignments. You should feel comfortable using any of them in your game design.

Game Concepts

These design concepts, though not directly covered in class, should be relatively straightforward to use in your game design.

Advanced Game Concepts

These concepts do not touch on programming techniques that are explicitly covered in CIS 120. If you already have experience with these topics, or want to challenge yourself, you may propose features making use of these techniques. Be warned: these are difficult and time-intensive to get right, and there is no guarantee that the course staff will be able to help you debug any issues you run into.

Choosing which Design Concepts to Implement

When choosing which concepts to implement, we advise you not to get too ambitious. Again, it is much better to implement a simpler game well than to attempt a more complex game and execute it poorly. The point of this assignment is to demonstrate your understanding of the concepts taught in this course, not just to show the most difficult, complex thing you can make.

You should feel free to post on Piazza if you have an idea that no one else has suggested before! We strongly suggest that you do so to be sure that your design concepts will receive full credit.

NOTE: Posting to Piazza is not a substitute for attending office hours to get your proposal approved.

We will not be lenient in giving partial credit to a design concept that is not suited for the feature it is implementing, or if it is a trivial use of the concept. You should clear up any questions/confusions in office hours before the proposal is due, so that there are no misunderstandings when it comes time to submit/grade your game. If you post to Piazza, please make such posts public so that we do not have to field repeat suggestions!

NOTE: Only a maximum of 100% may be earned for this project. Even if you implement more concepts than necessary, they cannot bring your total to over 100%, nor can they compensate for other missing criteria. For example, if you fail to provide instructions, the highest score you can get is 97%, even if you implement twelve different core concepts.

Part 2: Game Implementation

A Note about External Resources

For this project it is not necessary to use any external resources, such as images or third-party code libraries. However, you are welcome to use them, subject to the following conditions:

Starter Code: The Mushroom of Doom

It would be cruel to ask you to write a game completely from scratch; even experienced Swing programmers start new programs by starting with existing code, or by using a tool to automatically generate some starter code. So, we’ve provided you with a very simple example game that you can use as a starting point if you like. (Note that your game might quickly outgrow the provided structure, so you should create new files and reorganize your code as necessary.)

mushroom of doom

Our sample game is rather silly, really super cool. You can move the black square using the arrow keys. Then, there is this mushroom. If your black square touches it you die. Of course, you win the game by catching the golden snitch. Try it out by downloading hw09.zip and running the Game class. You’ll need to make sure that the image file poison.png is in the top-level project directory before you play the game.

The game doesn’t do anything fancy like allow multiple players or keep score, but even such a simple program already demonstrates a lot of the key concepts you will need to make your own game. You should read all of the code provided before beginning to write your own game, though you are not required to use any of this code in your own game.

Here’s an overview of each of the provided files:

NOTE: The intersect code in GameObj.java is only accurate for squares. Something a little more clever is required to accurately detect collisions between more interesting shapes.

Implementing Your Game

You’re on your own! Your game project will be graded partly on a set of implementation criteria and partly on your explanation of the implementation during the demo session (see grading).

Backing Up Your Code

For this assignment, we strongly recommend that you make snapshots of your code periodically. You might want to consider learning and using a source control system such as Git.

At the very least, each time you get a new feature working, create a folder with the date and/or a descriptive title in its name (so you can remember which version is which if you have multiple snapshots), and copy all of your files into it. If your next big feature causes huge problems (or if the deadline arrives!), you’ll have a way to recover a working version of your game to submit. Otherwise, you may find yourself a half hour before the deadline with a broken game that doesn’t compile, and only half a head of hair (having pulled out the rest).

Submitting Your Game

You must submit a single archive called files.zip. The most important requirement is that it must include a Game class with a main method:

public static void main(String[] args) 

This Game class must be in the default package so that we know where to look for it.

The archive must contain all your sources. If your project uses additional libraries, the archive must also contain the requisite .jar files. If your project needs data to run—game level information, images, sounds, etc.—the archive must contain these as well.

However, you should not just zip up your entire Eclipse project directory, as the paths will not be correct when we run your code. Furthermore, we don’t want to see your .class files.

Instead, when you are ready to submit, create a temporary directory and copy everything in your src/ subdirectory into that directory. Also copy over any extra files and libraries (e.g., .jar files) that your game needs. Once you have done that, create your zip file from inside that directory.

The submission page attempts to compile your code and checks for the main method. It will tell you if this compilation fails. The most common cause is forgetting to include a file.

For some projects that depend on external libraries, the submission tool might still complain, even if you are sure you included every file and they all compile. If this happens, it’s probably because the submission server isn’t able to include th external libraries. Please email your recitation TAs so they are aware your submission may not have compiled on the server.

There is no penalty for extra submissions on this assignment, so get started early and submit often!

Do not assume that we will be able to run your game just because your submission succeeds. You should test your game in Moore 100A before submitting to ensure that you haven’t made any Windows- or Mac-specific assumptions. If the code you submit doesn’t work properly on the SEAS Linux machines, you won’t receive full credit.

Your files.zip must include a text file called README.txt that gives an overview of your game implementation. It should briefly describe all of the classes that make up your game as well as give any special instructions (like additional libraries, etc.). We will look at this file first when grading your assignment.

To run your game, we will execute the following command sequence from a terminal on the Moore 100A computers in a directory containing only your submitted archive:

    unzip *.zip
    javac *.java && java Game

    # we will add a classpath argument that includes any bundled .jar files

If your code doesn’t compile, then the second command will never run your game… no compile, no credit!

Demonstrating your Game

Your game will be graded during a demo session with a TA. We will play the game so you can show us all of your features and we can look for bugs. We will also grade your code for style. We will expect you to walk us through your Java classes and explain how everything works during the demo session. Be prepared for questions about your implementation.

We will be compiling and playing the game on one of the SEAS Linux computers. You should test your game in Moore 100A ahead of time.

You must schedule a demo session with a TA. Sessions will be available throughout the final exam period. Each demo slot will be 15 minutes long.

Note: We will post more information about how to schedule your demo session to Piazza closer to the due date.