CSE 341 -- Smalltalk Project

March 4, 2002.
Due in quiz sections March 14, 2002

Introduction

For this project, you may work by yourself, or in groups of two. If you work in a group, just hand in one completed assignment with everyone's name on it. If you work in a group, you will be expected to undertake a project of larger scope. This meant to be a fun, open-ended project, and I am going to give accordingly few guidelines, rules, and regulations. I strongly encourage people to work in groups.

On March 14th, we'll have the quiz sections in the lab, and have a demo day. (We need to see these in operation to evaluate them for grading. Plus it will be fun to wander around and see what everyone has done.) Because this day is so close to the end of the quarter, there will be no late days for this project.

Your job is to write an arcade game in Smalltalk. While I will give you hints and setup code for writing the game of Asteroids, you are actually allowed to write an application of any sort, as long as it meets my criteria (talk to me first!). In the past, people have come up with all sorts of interesting, beautiful, fun games, so don't constrain yourself!

What we provide

If you wish to start with our starter code, please visit the Asteroids support page for more information.

Deliverables

Part 1: Due in section, Thursday, March 7

To encourage you to start early on this project and do a beautiful job, we'd like you to turn in a short document (two pages max) describing your proposed project. Think of this as a rough draft for the first part of the paper (see below) you'll have to turn in with the project. In particular we'd like to hear:
  1. What are you trying to do?
  2. If it's not Asteroids, convince us that your project will make good use of Smalltalk (ie. object-orientedness and inheritance).
  3. Give a high level overview of the structure of your code: what classes are you going to define, how will they interact, what will the inheritance hierarchy look like (give us a diagram or outline of your proposed class hierarchy, annotated with methods).
  4. If you've already done some implementation, tell us the status.
Remember that this is just a proposal: expect it to change as your project develops. The purpose is to get you to think before you start hacking. It also doesn't have to look like a work of art, but it should be well-written. As usual, if you're in a group, just turn in one paper with everyone's name on it.

Demo Day: Due in section, Thursday, March 14

On Demo day, please turn in a hard copy of your source code. If you file out the whole category, you should be able to print it as one nice file. We also want you (and your group, if you have one) to write a short paper. You are welcome to use the above document as the basis for the first part of this paper. The paper should have two parts:
  1. A technical summary. This should answer the questions we asked in Part 1, above. The purpose of this section is to give us better insight into what you did and didn't do. This section should comprise roughly one-third of the paper.
  2. An evaluation: Describe your design rationale (why did you structure your code the way you did), what you might do differently next time, and how Smalltalk was (or was not) appropriate for the task you undertook. This part should comprise about two-thirds of the paper. The purpose of this section is to get you to think after you're done hacking.
The paper should be 3 to 8 pages long and well written. I will read these and they will be part of your final grade.
dugan@cs.washington.edu (Last Update: )