Informatics 45 Spring 2010, Project #4: Games Without Frontiers

Introduction

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:

It must have a custom-drawn board, rather than one that's constructed using only built-in Java GUI components. Precisely how you draw it is up to you — one approach is to do something similar to the Othello board we drew in lecture, though you're free to do anything else you'd like that clearly represents the state of the game board.
It must have a straightforward user interface for playing the game. Of course, "straightforward" is in the eye of the beholder, but it should be possible for us to figure out how to play a game of Connect Four without much experimentation. (Feel free to include a brief message here or there that explains how to use it. The Flash version of Connect Four linked above does a nice job of this.)
It should be clear, at any given time during a game, whose turn it is.
When the game ends, it should be clear which player won, without the user having to scan the entire board looking for four checkers in a row.
It must implement its game logic separately from the user interface; in other words, the model (the game logic) must be separated from the view (the user interface).
Unlike the Othello example from class, it should be possible to play more than one game of Connect Four without having to restart the program. (Ideally, it should also be possible to restart the game at any time, even if the current game is not over, though this is not a requirement.)

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.

Client contacts server
Server accepts connection
Client sends I45CONNECT4
Server responds with GO, which causes both sides to start a game, with client playing as black (and moving first) and server playing as red
Client and server alternate moves by sending messages in the form MOVE columnNum, where columnNum is a number between 1 and 7
When the game is over, both participants disconnect

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 must have a custom-drawn board or game state. (Animation and sound are optional.)
It must have a straightforward user interface, or at least enough in-game documentation to make it clear how to play it.
It must implement the game logic separately from the user interface.
It should be clear what the current state of the game is (e.g., the score, whose turn it is, how much time is left, etc.). This is a somewhat nebulous requirement, since it depends heavily on what game you've chosen, but keep this in mind.
It must not be a game that we're developing in lecture, in whole or in part.

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:

What game you plan to build — be detailed enough that I can assess whether the problem is solvable in the time allowed. Also, don't assume that I've ever heard of the game you plan to implement, so please either describe it or provide a link to a description of it.
Roughly what you expect your user interface will look like when you're done

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

Describe in a fair amount of detail what problem you plan to solve. (If you plan to work on the provided problem, you can just say "I plan to work on the provided problem" and move on, unless you plan to extend it, in which case you should specify how you plan to extend it.)
How will your user interface be designed? What will the drawing of the board or game state look like?
List the tasks you expect to have to complete before you've finished your implementation. We're not expecting you to break them down at the level of individual methods or classes; we'd just like to see what the big-picture tasks are. Which tasks are dependent on which others?
What features did you prototype, if any? How did you prototype them?
Guided by your prototyping and past experience, what aspects of the project pose the biggest risk to your success? Where do you anticipate having the most difficulty?
Guided by your prototyping and past experience, what aspects of the project pose the least risk to your success? What parts do you expect to be able to handle with relative ease?

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.

To what extent did you follow your project plan while implementing the program? What features did you implement differently than you specified in your plan? Why did you decide to implement them differently?
What are a couple of your biggest successes on this project — features that you felt turned out well, challenges that you were able to overcome? What forces do you think helped you to be so successful in these cases?
What are a couple of aspects of this project that could have gone better? Why do you think they were problematic and what could you have done differently so that they would have gone better?
In what ways did you find game development to be different from the other kinds of programming we did this quarter?

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.

Deliverables

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:

The project plan, which is a Microsoft Word (.doc or .docx), Rich Text Format (.rtf), or PDF document. This is due on Friday, May 28 at 11:59pm.
The program, which is three things: a collection of .java files comprising your program, a document explaining how to use it, and any JAR files containing open source libraries that you used (if any). Please submit a zip file containing all of your these things, but no other files (e.g., compiled .class files, other parts of your Eclipse workspace). Be sure to zip the .java files while still in the folder structure imposed by Eclipse and Java when you use packages. The program is due on Sunday, June 6 at 11:59pm.
The lessons learned document, which is another Microsoft Word (.doc or .docx), Rich Text Format (.rtf), or PDF document. This is due on Tuesday, June 8 at 11:59pm.

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.