Homework 9: Make Your Own Game

Component	Due Date
Project proposal document	Tuesday, December 1
Project code and README document	Tuesday, December 8
Game demo to your TA	Reading days (Dec. 9–10)

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.

• Project Proposal [Explanation: 12%]. This document will lay out your plan for implementing your game, and will be submitted at least a week in advance of the project due date. See below for more details.

• README.txt [Explanation: 4%]. You will submit another document along with your code, detailing your game and any changes you needed to make to your design.

• Instructions Window [Implementation: 3%]

  Your game must provide easy-to-find instructions, including:
  • A brief explanation of the game you implemented.
  • An explanation of how to play the game, including how the keyboard and/or mouse should be used.
  • This is also a great place to boast about anything cool you’ve implemented that you want to make sure we don’t miss.

  In their excitement of creating a new game, some students overlook this part of the rubric. However it is a really important component of your project, especially when it comes to grading. Don’t miss out on an easy 3 points!

• Mouse and/or Keyboard Controls [Implementation: 3%, Explanation: 3%]. You will need to implement mouse and/or keyboard game controls as appropriate for your game. The sample game demonstrates simple keyboard control using the arrow keys, but you will probably need to make this more sophisticated. Try to make the player’s experience a good one.

• Game Status Display [Implementation: 3%, Explanation: 2%]. The game should have a way of displaying the player’s running score, number of lives, etc., as appropriate to the game. Those values should be incremented/decremented appropriately as the game progresses. (Note that this criterion is separate from the game logic one listed next. The game logic determines, based on the game state, how points or player lives are awarded. The status display code is just about showing this information in the window.)

• Game Logic Correctness [Implementation: 6%]. This will be graded based on correctness of the overall game. Even if the design concepts are all implemented correctly, this encompasses everything else that is required to make the game playable (and bug free!).

• Design Concepts [16% per concept, 64% in all]. The point of the game project is to synthesize all the concepts that we’ve learned over the semester and apply them in the context of game design. In order to facilitate that, we have compiled a list of core concepts that we've covered throughout the semester. We’ve also made a list of additional concepts that are particularly relevant for game design that you may also choose to use. Some of these are more advanced topics that we have not covered in class.

  For your game, you must implement in a non-trivial fashion four of these design concepts. Just to be clear, you have to choose four distinct concepts; we will not accept any double counting.

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. Though you will not receive feedback on your proposal before you submit the project, you will use it 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 “hw09proposal” assignment by the proposal due date.

Design 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.

• Modeling state using 2-D arrays or collections. Pretty much every game will need to use data structures to model its state. You won’t receive credit just for using a data structure; what matters is choosing the appropriate data structure for the piece of state you are modeling. The collection you choose should make it easy to manipulate and retrieve the game state. For instance, most grid- or board-based games will be best modeled by a 2-D array which directly represents the rows and columns of the grid.

• Using I/O to parse a novel file format. You might choose to design your own text or binary file format, and have your game read and write files using that format. Note that this format must be one of your own design; if Java already has a library for parsing this format, then that is too much of an abstraction to be considered an appropriate use of this concept.

  Common uses of I/O include enabling peristent state between runs of your game; for example, you might write high scores out to a file and read them back in each time your game starts. I/O can also be used to create arbitrary levels, where a text format specifies features of the level (rather than hard-coding levels into your game).

• Object-oriented design using inheritance and subtyping. You can use Java’s subtyping features to group and organize different entities in your game. We require that you justify why you decided to design your classes and interfaces in this particualar hierarchy, and that your justification is reasonable. We will not accept simply the creation of an interface and a single class that implements it.

  One example for a valid use of inheritance and subtyping (while not the only way to implement the game) is an enemy inferface with multiple subclasses for a tower defense game. In this case, the enemies are restricted in similar ways, but attack or approach the tower in different ways. Another example would be for some board games where different pieces do different things (but this is not a general rule).

• Using JUnit to test some features of your model. A well-designed game should contain an encapsulated model that functions independently of GUI. There should be a consistent interface for the model, which is updated by calling methods. While we aren’t expecting exhaustive unit-testing of your entire game, there should be some reasonably complex, isolated piece of state which you can test.

  An example of a testable model is the chat homework assignment, where the ServerModel class stores the state but does not deal with any low-level components of the server’s networking.

  In your proposal document, you should choose a portion of your model (for instance, a particular class such as a player object), and justify why that is an interesting (non-trivial!) component to test. Make sure you consider edge cases and invalid inputs while doing so!

• Implementing recursive algorithms. There are several useful recursive algorithms you might wish to implement, including depth-first search of a graph, traversing a tree structure, or finding a path through a maze. You should consider whether a recursive implementation is strictly necessary for this algorithm to work—you may not implement recursion solely for the sake of recursion!

Game Concepts

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

• A novel linked or recursive data structure. Some games might have states that aren’t easily modeled by an existing collection. For instance, you might have a maze or a network of rooms connected by corridors, and each node should know the others it is adjacent to. You might also find that a tree-like structure could be helpful for modeling a particular problem. Whatever you decide, your implementation must be a data structure not already available to you in the collections library.

• Complex search of the game state. Many games require a bit of work to detect a win or lose state, and might need to search over the whole state of the model in order to detect such a condition. Note that we don’t just mean retrieval of an element from a data structure; the search should involve some relatively complex logic. For instance, Connect 4 and chess are both instances of games that require searching of the game state, taking into account constraints on the placement of game pieces. You might wish to build an AI game player using similar searching of the game state; there are a few algorithms such as the minimax algorithm which require predicting future game states and choosing the move that guarantees the best outcome.

• Physics-based animations. There may be complex kinematics and dynamics to simulate in your game resulting from the interactions of more than two bodies. Your physics model should be more complex than simply including a downward gravitational force or implementing perfectly elastic collisions. Some ideas might include n-body simulation or orbital mechanics.

  Implementing physical simulations by using a simple library is not sufficient for this design choice. A non-trivial use of physics in your game must require signficant implementation effort on your part.

• Collision detection for complex shapes. The collision detection provided in the starter code is only valid for square-shaped objects. A more complex implementation of collision detection would treat objects as having borders which cannot intersect, and deflecting colliding objects in arbitrary (not just up-down-left-right) directions.

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.

• 3-D graphics. This feature would treat the Swing viewport as a "window" into a larger three-dimensional space, and allow the user to navigate in six (rather than four) directions.

• Network I/O. This involves creating a client-server or peer-to-peer architecture and writing to network sockets. Your game must do network I/O between instances of an application you wrote; communicating with a third-party server is not sufficient.

• Concurrency. If portions of your game state require concurrent execution, you may use Java threads. Note that there must be a sufficient justification for using multithreading, and you may not simply call Swing primitives for handling thread execution.

Choosing which Design Concepts to Implement

When choosing which concepts to implement, we advise you not to get too ambitious. 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.

We provide several examples of how various concepts map to game features, but you are welcome to do something else! We will post a list on Piazza of acceptable features that each concept could implement. We will also maintain a list of features that we are not going to allow (possibly because they are too easy or not interesting from a design perspective).

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.

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 may want to ask the TA who is grading you whether your implementation idea counts, so that there are no misunderstandings. 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:

• You may not read, follow along with, or copy anything from a tutorial that relates to any of your implementations for core concepts. We will be very strict in enforcing this policy because we want to make sure that everything we are grading is your work. This does not include explanations of algorithms, but as mentioned above, you are still not allowed to view any code for them. If you are implementing something external to the core concepts we are grading, then you are allowed to view a tutorial that explains concepts, but you must cite your sources in your README.txt.

• Any library code you use must work on the Moore 100 machines that we will use to test your project. (This rules out some platform-specific libraries or libraries that require the use of non-standard hardware.)

• Any library code that you use cannot itself count toward any of the graded components of your project (e.g. if you use a Java library for animations, you may not count the implementation of animations as a design concept).

• If you have questions about whether your use of a third-party resource is allowed, consult the course staff for help.

• For resources like images you should be fine using whatever you like, since this is a not-for profit educational project. However, if you plan to distribute your game more widely, you should keep in mind the rules about fair use of copyrighted material.

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.)

Our sample game is rather silly, really. 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:

• Game.java: This file contains a class with a simple main method, the basics needed to get a window up and running, and instructions to put a Reset button, Status line, and a GameCourt in the window.
• GameCourt.java: This is where the real action happens. The GameCourt is a JComponent on which the current game is displayed. It handles user keypresses, and sets up a Timer to generate an event every 35 milliseconds so that the screen can be redrawn. It also has a Square, the Poison mushroom, and a Circle (i.e. the snitch); it updates all of them before redrawing the screen.
• GameObj.java: GameObj is the base class which collects behavior common to the different objects in the game. A GameObj is a rectangular object which has a position, a size, a velocity and bounds. Game objects can be moved, drawn, and bounced based on collisions with walls and other GameObjs. This game creates three subclasses of GameObj:
  • Poison.java: A Poison is a GameObj that represents a poisonous mushroom. It doesn’t move, but demonstrates how to display game objects using images.
  • Square.java: A Square is a GameObj which looks like a black square. It is controlled by the keyboard in GameCourt.
  • Circle.java: A Circle is a moving GameObj which is displayed as a yellow circle and bounces off of the walls and the Poison.

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).

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.

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
    

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.