Informatics 45 Spring 2010
Project #4: Games Without Frontiers

Project Plan due: Friday, May 28, 11:59pm
Program due: Sunday, June 6, 11:59pm
Lessons Learned due: Tuesday, June 8, 11:59pm

You are required to work on this project individually


My first exposure to computers, as a kid in school, was in the context of computer games; some were educational games (it was school, after all), though some were not. The first time I remember sitting behind a computer — a Radio Shack TRS-80 Model I — I played a game called FASTMATH, which pitted two players against one another, trying to solve arithmetic problems as fast as possible. Sure, it was just a boring educational game, but at the time I was captivated, and I still remember it. (I especially loved winning, though I didn't always win.)

It wasn't long before I had my own computer, complete with its own collection of games. None of the games I played on my own computer could be classified as educational, in a direct sense, though those games were sneaky: they taught me a surprising collection of lessons and motivated me to ask many interesting questions about computing, as I endeavored first to win them outright, then to modify them and cheat, and finally to write them from scratch. Games in those days, of course, didn't have the same photorealistic, surround-sound appeal that they have today, but they were nonetheless fun and exciting; their simplicity made writing one's own game seem more possible than it does today, in an era of tremendously complex games built by gigantic teams of programmers, designers, and artists. (In truth, it's easier to build simple games now than it was then, because the computers have become so much more powerful and the tools have gotten better. It's just harder to compete with the large-scale, professionally-developed games.) Unfortunately, my skills didn't develop quickly enough — I always aimed too high, relative to what I knew how to do, but it was tougher when there was no Internet to search when you got stuck on something — and I never realized the goal of writing my own games before I became interested in other things, though I certainly learned a lot trying.

This project offers you the opportunity to build your own game. As with the previous project, I'll allow you to propose your own problem, or you can take the option of working on a problem that I'm providing. The provided problem will require you to explore some of the things that we've been discussing in lecture recently — overriding a paint() method to do your own drawing, converting low-level user input (like mouse clicks or key presses) into higher-level actions. If you'd like to take it further, though, or if you'd like to work on a different game of your own choosing, you're encouraged to do so.

Games may seem frivolous to some of you — I know that not everyone likes to play them — but they provide a fascinating combination of problems to be solved: software engineering, human-computer interface, networks, psychology and cognition, and even (in multiplayer online games) economics and sociology. Game developers push the envelope in a wide variety of areas, and many of these lessons can be applied in more "serious" contexts. Even if you're not that interested in games, you'll be surprised what building games can teach you about software.

Reminder: Do not partner up!

For this project, your work is expected to be completed individually, so do not partner up and do not use pair programming.

The problem

This project provides you with a choice of problems to work on. You're asked to choose between a problem that I've posed or a problem of your own. The choice is entirely yours; while we encourage you to explore your own ideas if you have them, there's neither a penalty for deciding to solve the provided problem instead nor extra credit for choosing your own. Follow your instincts.

Connect Four

Connect Four is a well-known board game (also known by other names, like Four-in-a-Row or The Captain's Mistress) in which two players drop checkers alternately into a 7x6 grid in an attempt to line up four in a row (horizontally, vertically, or diagonally). If you're unfamiliar with the game, an excellent online version of it, which includes a visual demonstration of how the game is played, can be found at this link (which requires Flash, which can be found at this link).

The provided problem for this project asks you to implement your own version of Connect Four in Java. If you choose to implement Connect Four, you have a fair amount of freedom in terms of how you implement it, though your program should meet the following requirements:

Extending the Connect Four problem

You are free to extend your Connect Four program somewhat arbitrarily, so long as it meets the above requirements. One possible extension might be to implement a network protocol to allow two instances of your Connect Four game to play against one another; in case more than one of you wants to go that route, here is a proposed protocol that you can implement, so that your programs will be interoperable.

You can also implement a different protocol, if you'd like, though you may sacrifice interoperability with other students' programs (unless you and the other students agree on a protocol). It's probably not worth coming up with your own protocol unless you want it to support something that this protocol doesn't, such as in-game chat, or the ability for client and server to negotiate about who will play as which color or what the size of the board will be.

(I should point out that there is a limitation in this protocol: there is no handling for the problem of one player making an invalid move. In a more practical implementation, this would be a problem worth solving; for example, each side can respond with a YES or NO message whenever it receives a move, with YES indicating that the move is okay and NO indicating that it's not.)

You are permitted to extend the Connect Four problem without consulting me first, so long as your program meets the original requirements; however, feel free to contact me ahead of time if you'd like to discuss your ideas and get help assessing their scope, so you can feel more assured that you're not biting off more than you can chew.

Coming up with your own problem

Rather than working on the Connect Four problem, you are free to come up with your own problem instead. In general, anything goes, though it does have to be a game, and it must meet some of the requirements specified for the Connect Four game above, specifically:

It doesn't have to be a board game, though be aware that more interactive games are more difficult to implement, so they pose a bigger risk.

If you're working on your own problem, you'll need to get it approved by me early in the process. By Thursday, May 27 at 8:00pm, you'll need to send me an email that describes:

A word about the use of outside resources

I am aware that there are existing versions of Connect Four written in Java that are available online. It should go without saying that you are not permitted to download these and submit them as your own, in whole or in part, but prior experience has taught me otherwise; I generally like to keep a pretty open policy about outside resources when it's pedagogically wise, but other implementations of Connect Four are off-limits in your work on this project.

I am also aware that there are a variety of other games implemented in Java, any one of which you could theoretically choose as your problem, download, then submit as your own. Be aware that other existing game implementations are also strictly off-limits in your work on this project.

The planning phase

The planning phase, as always, will be crucial, since you'll need to think about your problem (Connect Four or otherwise) and decide what approach you'll take, where the risks lie, and so on.

The project plan

You're required to write a project plan that summarizes the planning you did, addressing at least the following questions. (You're free, as always, to include any additional information you'd like.)

The project plan is due on Friday, May 28 at 11:59pm. See the section titled "Deliverables" below for more information about how to submit the various parts of your project.

Writing the program

The program should be written entirely in Java. The GUI should be built using the Swing library, with an overridden paint() method used to paint the board or game state. In addition to Swing, you are free to use any part of the Java library that you would fine helpful. Additionally, you are permitted to use other components (e.g., open source components) to help you realize your goal, though you are not permitted to use parts of other people's programs specific to your game (e.g., game logic or visualization code).

In addition to delivering your program, you'll also need to submit a brief document that explains how to use your program. You won't need to say much here — a page or so will suffice for most of your programs, I'd guess — but we are going to need to be told enough information that we can understand and use your program.

Lastly, if you used any open source libraries provided as JAR files, you'll need to include those JAR files in your submission.

The program is due on Sunday, June 6 at 11:59pm. See the section titled "Deliverables" below for more information about how to submit the various parts of your project.

Assessing the lessons learned

Once you've completed your implementation and submitted it, take a little time to reflect on your experience by writing a lessons learned document. Your lessons learned document should reflect on, at least, the following questions.

The lessons learned document is due on Tuesday, June 8 at 11:59pm. See the seciton titled "Deliverables" below for more information about how to submit the various parts of the project.


You are required to deliver the three parts of the project to Checkmate, an ICS-built online assignment submission system. Follow this link for a discussion of how to submit files via Checkmate. Be aware that I'll be holding you to all of the rules specified in that document, including the one that says that you're responsible for submitting the version of the project that you want graded. We won't regrade a project simply because you submitted the wrong version accidentally.

There are three parts to this project, each with its own due date:

If you partnered up, be aware that it is only necessary for one of the two partners to submit the project; we would prefer that the same partner submit all three parts, so that they will all be identified together in Checkmate. Your TA is aware of the partnerships and will figure out which project submissions belong to which pairing. Put the names and student IDs of both partners in a comment at the top of each of your .java files and documents. Afterward, take a moment to be sure that you submitted all of the files you intended to; if you missed one, we won't be able to compile and run your program, which can result in a substantial penalty, since we won't be able to evaluate your program's correctness.