CS 161 Final Project

Due Mon May 11 at 11:59pm

Overview

You will be implementing a final programming project to demonstrate all of the programming and computer science skills you've mastered throughout the course. This is a chance to work on something that is of interest to you, while also reinforcing what you've learned. You should aim to make a project that you'd be proud to show off to your friends and family--an awesome "look what I made!" program that will make you the envy of everyone you know.

Schedule

You have until Monday, May 11 at 11:59pm to complete your project. (This is the Monday of finals week, letting you finish things up over reading period if needed). However, there will be some deadlines along the way to help keep you on track:

  1. Wed Apr 22, noon - Project Idea Approved

    By Wed Apr 22, you need to have come up with an idea for your project and gotten it approved by me. This step is intended to make sure that (a) you're starting early and (b) you aren't trying to build something that is too large or too small.

    • Project ideas should be submitted via email to me: title your email "CS161 Project Idea" so that I don't miss it!
    • Your "idea" can just be a few sentences (e.g., "I'm making a Pong game that players control using the keyboard"), or longer if needed (e.g., describing something total new and interesting you want to make). The goal is to effectively communicate to others (particularly the professor) what you will be working on!
    • Also let me know who you're working with (if anyone). Only one partner needs to send the email to get approval (approval is "per project").
    • I will let you know if your project is suitable, or if something seems like it might not work, or I have further questions. Approved projects will be explicitly marked as such in a reply email. You need to have submitted an approved description to me by the deadline; since I may ask you to clarify something, don't put this off until the last minute!
  2. Thu Apr 23 during lab - Project Design Proposal

    During lab on Apr 23 (the next day), you'll be creating a more detailed description of your project and its design. This will include both the design of what the user interface will look like (since a GUI is a major requirement), as well as how the classes will be designed (e.g., what classes & methods you'll have).

    • This will be a guided assignment (sort of like previous labs) that you'll be able to complete during the lab period. By the end, you'll have a good "outline" of your program, which will help you be able to get started on implementing it! More details can be found in the lab write-up itself.
    • Since your partner might not be in the same lab section as you, you may end up doing this one on your own and having two different designs. That's okay--multiple ideas is a good thing! (Though you'll need to pick one in the end).
    • Note that your Design Proposal will be graded as a lab (rather than as part of the project itself).
  3. Thur Apr 30 during lab - Alpha Demo

    During lab on Apr 30, you will be showing me an "alpha" version of your project---what you have completed so far. This version should have basic functionality: you should have something showing up on the screen, and probably some basic logic. I'm looking to see that you've gotten started and are making progress on the assignment. Being 50% done is a good goal for here.

  4. Wed May 06 during class - Beta Demo

    For our final class meeting, you should be ready to show off a "beta" version of your project to your classmates (like in small groups, not to the entire class!). This means your program should be basically functional, but might lack more advances features or polish. You should be 80-90% done at this point.

  5. Mon May 11, 11:59pm - Final Project Due

    Your final project is due at midnight on Monday, May 11 (the Monday of finals week).

Once more, in case you missed it: the project is due Monday, May 11 at 11:59pm.

Project Requirements

You are welcome to design your own project for this assignment. Pick something that you think would be fun to create, useful to use, or neat to show off!

However, no matter what you choose, your project should meet a few basic requirements:

  1. Your project should include a Graphical User Interface (GUI). This can either be a window with buttons and labels, or a painted graphical image. But it should not be just a command-line program [unless you can make a really good argument for it in your project proposal!]
  2. Along those lines, your project should include user interaction with the GUI: mouse and/or keyboard interaction, interaction with buttons, etc. Be sure and think about what makes the program easy and pleasant to use!
  3. Your project should include multiple classes: at least 3. This means the project should be large enough that it has more than one component, and that you'll be working with multiple objects. Of course, giving the program a GUI means that you'll likely need at least two classes just for that (one for the UI and one for the program model), so this shouldn't be hard to meet.
  4. ...that's about it really. :)

We have included a couple of suggestions for suitable projects below. You are encouraged to choose one of these projects, but are welcome to come up with your own idea!

Some Project Options

At this point you have the ability (the power!) to create full if simple applications. One great example of such applications are classic arcade games! These games follow very simple computational and graphical rules (since that was all that was available at the time), and so are quite feasible to put together. Some examples are discussed below.

Pong

Pong is a computer version of ping-pong, in which players control opposing "paddles" and try to knock a ball back and forth. If the ball gets past your opponent's paddle, you get a point. Whoever gets the most points wins!

Your game should allow two players to play using the keyboard (for example, one using the arrow keys and one using the 'w' and 's' keys). Players can move their paddles up and down on the screen, and when the ball hits the paddle it bounces off. The ball should also bounce off the floor and ceiling, and will need to detect when it has gotten past a paddle. An advanced program could have the ball bounce at a more extreme angle as it hits further away from the center of the paddle. Your game should keep track of the current score, and declare a winner (like first to 3 or first to 10).

A really advanced Pong game could include a computer-controlled paddle. This is not a normal requirement.

Getting started: Start by making two paddles that are able to move up and down based on keyboard input. You'll need to use a KeyListener for this. Start with getting the keyboard input, as it can be tricky (hint: make sure your target component is the "focused" window--the one the user is interacting with). Once you can move paddles, add a ball bouncing around the screen (look back at the BouncingBall lab for an example). Finally, you can then add in bouncing off the paddles and scoring points.

Alpha Demo: A program that can move two "paddles" (rectangles) on the screen in response to keyboard input.

Beta Demo: A program in which the paddles can bounce a ball back and force, and that registers when the paddle has missed the ball.

Breakout

Somewhat like a one-player version of Pong, Breakout is a game that involves using a paddle to bounce a ball around. However, instead of trying to knock the ball past your opponent, you are trying to aim the ball to hit and destroy a grid of different colored "bricks". If the player destroys all the bricks, they win! If they miss bouncing the ball too many times, they lose.

The paddle in this game could be controlled either with the keyboard (e.g., the arrow keys) or with the mouse (tracking only horizontal movement). The ball will need to bounce off of the walls and the bricks, but after it bounces off the brick the brick should be removed. You will need to deal with removing a brick, and if all the bricks have been removed let the player know that they won!

This project may be slightly more challenging than Pong (since you need to deal with bricks as well as paddles).

Getting started: You might start by making a ball that bounces around the screen (you can use the BouncingBall lab as a launching point). Then add in a row of bricks, making sure the ball can bounce off them (note that you can track what bricks exist by using a list (either an ArrayList or an array--perhaps a 2D-array to represent the grid!). Add the functionality to remove the bricks when they are hit. Finally, add in the moving paddle at the bottom so that the ball can bounce off that.

Alpha Demo: A program that has a ball bouncing around the screen, including bouncing off of positioned bricks.

Beta Demo: A program in which the ball bounces around the screen and removes the bricks when it hits them. Likely with a paddle it bounces off of as well.

Snake

Snake is another classic arcade game, and a staple of simple programming systems (my old graphing calculator came with a Snake game). In Snake you control the head of a snake, moving it in different directions based on user input. Note that the snake doesn't stop moving: you just indicate what direction it is going! You try to move the head to eat a "pellet" or "dot", without crashing into the tail of the snake or any walls. Each piece of the tail follows the head exactly where it went---like a conga line! In addition, the tail gets longer each time a pellet is eaten, making the game increasingly difficult. The goal is to eat as many pellets as possible before you crash.

Your program should allow the player to control the snake via the keyboard--different keys should tell the snake to turn in different directions, but otherwise the snake will move one step each "frame" of the animation. The hard part will be tracking each individual piece of the tail: I suggest making an ArrayList of "segments", and then having each segment move to the position of the segment in front of it (with the "head" being the first segment, and moved in whatever direction it is facing).

Getting started: Start by making the head that runs across the screen in a particular direction--this should be relatively simple. You can then add the "tail", programming it to follow the head. Then add in the ability to change the head's direction using the keyboard, and finally add in the ability to collect pellets (as well as scoring).

Alpha Demo A snake that moves across the screen in different directions based on keyboard input.

Beta Demo The snake is able to turn around and have the tail follow. Snake should also be able to pick up randomly positioned "pellets".

Pac-Man (Challenging!)

If you're feeling ambitious, you can also try to implement a simple version of the greatest arcade game of all time: Pac-Man! Your Pac-Man game won't necessarily follow the exact details of the original (and it shouldn't, due to copyright restrictions), but can do some of the same things. The player should be able to control Pac-Man using the keyboard--Pac-Man can move around the screen (which may or may not look like a maze), collecting pellets when he steps on them. In addition, there should be "ghosts" that wander randomly around the screen; if Pac-Man runs into a ghost, he gets eaten! The goal of the game is to eat all the pellets.

Getting started: Start by getting Pac-Man to draw on the screen, and to be controlled with the keyboard. Add in pellets, and make sure Pac-Man collects pellets when he walks over them. Then add in the Ghosts (who can step in a random direction), who have the ability to eat Pac-Man. If you wish to use a maze, add in that before you get to the Ghosts: just having Pac-Man maneuver through the maze and not being able to walk through walls can be a challenge in itself!

Alpha Demo Pac-Man can be moved around the screen and collects pellets he steps over.

Beta Demo Ghosts wander around and chase Pac-Man.

Other Options

There are of course many other options for projects. These include other classic arcade games (Space Invaders, Asteroids, etc.). And again, you can also pick a different project. It's possible to make board games (e.g., Chess, Checkers, Backgammon) the same way we made Hangman. Or maybe you want to extend a previous homework or lab in an interesting way (such as making the PianoPlayer into a GuitarHero game or a full-featured synthesizer, or making the Painter support shapes or images). Or maybe you have another idea in mind--feel free to be creative! You can pick any project that sounds interesting to you. Come up with an application that seems fun and impressive and make that.

Submitting

There are multiple components and requirements in submitting your project: be sure to read them carefully!

  1. First, your project idea pitch needs to emailed to me. The approved idea needs to be sent by noon on Wed Apr 22.
  2. Your Project Design Proposal will need to be uploaded to the appropriate submission dropbox on Moodle (details will be in the proposal write-up available during the lab period).
  3. Be sure that your code is extensively documented so that I can follow what is going on. Include plenty of inline comments, and JavaDoc comments on all your methods. Since you're making your own program, I'm coming at your code fresh, so help me to understand the work that you did!
  4. Your will need to upload your entire final project to the Final Project submission dropbox on Moodle. Your zipped submission must include:
    1. A README.txt that acts as an instruction manual for your program. Explain how it works from the user's perspective!
    2. The entire project folder for your program, including all source code and assets (images, etc).
    3. An executable .jar file that can be used to run your program outside of BlueJ. Just put this file inside your project folder before you submit.
  5. Only one partner needs to submit a copy of the final project (like with labs!)

Grading

This project will be graded based on approximately the following components:

Note that because this project is more open-ended, there is not a clean point break-down of functionality; rather the grading is more of a "rubric" for what your code should do!