Java, java or java.

Java?

You can download the Java Software Developer's Kit (SDK) from the Sun web site: http://java.sun.com/j2se/1.3/

There are excellent Java tutorials everywhere you look, but I found the Sun tutorials on how to use the Swing library (which is where you get button objects and window objects and other such user interface components) really useful. The tutorials include compilable examples that I downloaded, changed the variable names to protect the innocent and used in my game. That tutorial is at http://java.sun.com/docs/books/tutorial/uiswing/TOC.html - events

There are two basic ones: (1) it has to be web accessible, that is, you have to be able to play it from a browser and (2) it has to run on either the Sun machines or the Windows machines in one of the Baskin Engineering labs.

I'm sure we'll think of more as time goes on.

Tell me more about the project

The topics covered in the project part of this course are those required to support the development of a group program design and development project. You are to design and develop a computer game of your choice. It can be a board manager for human competitors of a game such as checkers, poker, bridge, Othello, backgammon, mancala, Nine Mens Morris, chess, go, or an invented one of your own. Or the game can be one in which the computer is one of the competitors, using one of the before mentioned games or one of your choosing. You will work in groups of 4 or 5 people. You are required to choose the software platform upon which the game will be developed and run. The game MUST be operable on the machines in one of the JBE labs. All project documentation MUST be in your group's project notebook.

To help you with the project, examples of all the deliverables, templates for them and additional information that seemed relevant are available via the class web site. The last class day has been reserved for project demonstrations and grading to be held in the lab. A working version of your game is due and your project notebooks MUST be up-to-date and ready to be graded on that date.

The following documentation is to be prepared and submitted at indicated times (milestones) and RE-SUBMITTED on the last day of classes (in the lab):

Software Requirements Document, team meeting notes, logs;

User Manual, team meeting notes, logs;

Design Documentation, part 1, team meeting notes, logs;

Design Documentation, part 2, team meeting notes, logs;

Code, Coding Standard, team meeting notes, logs;

System Test, team meeting notes, logs and properly documented, debugged, and tested program - submit disk or CD, team meeting notes, logs; entire project notebook including project file on disk.

You will be given guidelines and grading criteria for each of these milestones. Each milestone is to be turned in outside Professor Kaplan's office by 5 PM on Friday of the week that the milestone is due, except for the last one which is due in lab at the last class.

How is the project graded?

There are three major issues involved with project grading: assigning credit to the project, assigning credit for individuals within groups, and assigning credit for difficulty differences among projects. The following will describe how the project grading addresses each of these three issues.

You will receive separate grading sheet for each of milestone. The total possible points on the entire project is equal to 100 * (# students in group). Call this value Total. For example, if you have 5 group members, Total = 500. Each of the milestones are given the same weight: 10% of the project points.

Ideally, each of you will contribute equally to the effort needed for your project and each of your grades will be (1/# students in group) * Total. Realistically, some of you are more motivated or more organized than others and will put in more time on the project. Some are more talented or knowledgeable than others and produce higher quality work. In other courses, students who do more or do higher quality work get better grades than students who do less or do work of a lesser quality.

At each milestone, you may turn in secret email ballots on which you rate your own and all other of your group members' efforts and credit on the documents due at that milestone. For example, immediately after you have turned in your requirements specification, you are to divide 100 percentage points among all your group members in proportion to the effort and credit each deserves. For example, if each of the 5 group members worked equally on the requirements specification document, then you should assign each one 20%. Professor Kaplan will average these votes and assign an individual project score based on this average. Professor Kaplan will assume that the percentage points are divided equally if he does not receive mail from a group member.

Professor Kaplan reserves the right to request the TA/instructor responsible for the group to vote in the group. The motivation for this addition is to prevent you from working on the project up to the point where you or some number of the students in a group have earned a passing grade, then quit working on the project. Project members who 'flake out' on their teammates will experience the consequences.

Professor Kaplan will assign up to an additional 10% to your project score based on a difficulty factor that I assign to your project. A group that chooses to implement a simple game such as Tic-Tac-Toe will probably get no additional points. Having a computer opponent option on a complex game could add to the difficulty factor. Work on an implementation of a game similar to Tetris could get an additional 10% added. You are encouraged to keep the game SIMPLE.

Each group gets one "Get Out of Jail Free" card. That means that each group gets to delay turning in one milestone with no penalty. You have to take the consequences, though: if that means that you have to do your demo AND turn in a milestone in the same week, that's just the way it is. Use this capability to your advantage. You don't get extra credit if you don't use it, in fact, if you do a lousy job on a milestone and, at the end of the quarter, haven't used your GOOJF card, it will mean that you didn't take advantage of opportunities to improve your product - a negative.

In any case, turn in what you have. If you turn in nothing, the BEST you can do if you turn it in late is 50%. If you turn in something, even if it's ugly, you'll probably get at least 50% (remember, 10% for time logs and agendas - that's free money!), so you can resubmit and get up to a 75% - something that doesn't wreck your grade.

Yes. You can always fix a document and turn it in for a regrade. However, the most you can get on the regrade is your original grade plus 50% of the difference between your original grade and 100. For example, if you get a 70 on a milestone and then you fix it and turn it in to me. I'll grade the resubmission as if it was the first time through, so maybe you'll get a 95 - so the difference between you're original grade and what your second submission would have gotten is 25, so the grade you get for the milestone is 70 + (25/2) = 82.5.

I'd suggest around Week 3 - as soon as you, as a group, have just beat the living daylights out of the requirements and user interface, and you all think you understand where you're going. Assign your most eager coders to start prototyping You may end up throwing away lots of the code that you generate as your design matures, but you'll learn a lot about what your design should be by identifying risk areas and quickly coding them up. As a matter of fact, you have to demonstrate some functionality just after the middle of the term as a risk reduction exercise. And you describe the functionality you'll demonstrate in your System Requirements Document.

If you can answer the questions from the 3 quizzes, then you will be well prepared for the final exam. You can expect questions very similar to those you have already had.