CSE143 Winter 2003

Project 4B

Floaters,  Unite!

Due dates: Electronic parts are due on Wednesday evening, Feb. 26.  Paperwork and written parts due in class on the following day.

Overview

The requirements of Project 3/4 remain generally in effect, except as noted specifically below, or except to satisfy new requirements for Part B.

Starting Code

No solution to Part A is supplied.  Use your own solution as a basis for Part B.  If you didn't get Part A completely working, then your first priority is to do so!

You will still need the timer and the mouse listener (check the hint below).

Changes Compared to Part A

1. The floater characters that appear are not random.  They are taken, in order, from a message.  The message is a string.  The user can enter a message as the command line argument (note the singular: one argument).  If there is no command line argument, the program should have an internal default in some interesting character set.  It will be more interesting (eventually) if the message is a recognizable word or short phrase, but that is not required.  All characters of the string are processed as-is: no special handling for case, punctuation, spaces, etc.

2. When the mouse is clicked on the screen, on an empty space (not occupied by a floater), the next character of the message appears at that spot.  It should have a random initial direction.  When all the characters of the message have been used, then clicking on an empty space of the screen has no effect.

3. When two floaters collide, they join, and travel together from that point on.  You can think of them as constituting one floater.  "Collide" will be clarified a bit later.  For the current phase of the project, it doesn't matter whether or not these larger floaters combine further when the collide.

4. If the mouse is clicked on a floater (i.e., click on a non-empty area of the box), then no new character appears.  Instead, there should be some visual change in the floater that was clicked.  Up to you what that is, as long as a user would easily notice the change.

5. Do something at least a tiny bit interesting (but unspecified) with the visual appearance of the floaters or their environment.  No examples will be offered, and no questions about what is "interesting enough" will be answered.  Just think of something and do it.

Clicking "on" a floater and floaters "colliding".  Think of each floating character as either 1) occupying a small rectangular area,  or 2) being at the center of a small circular area.  Clicking "on" a floating character just means clicking anywhere on the small area containing it.  Two floaters "colliding" means that their areas intersect (or overlap) by any amount.  How you implement this is up to you (check hints below). 

RandCharDriver.java and RandCharController.java are still required, as before.  Names of other classes are optional.  You may define other classes and .java files as necessary.

Written part

1. Take a snapshot after all the characters of your default message are on the screen, but while at least some of them are still single.  Take another snapshot a bit later, showing some characters joined that weren't joined before.  Print both snapshots, and mark them up to point out the change that has occurred.
2. It may be difficult for a user (e.g., a TA) to know what special visual or other features to expect from your solution.  Write a paragraph (or whatever is needed) to describe such features.  If we don't forget, we'll have a special text area on the turn-in form for it; you may also print it out and turn it in with other written parts.
3. As you browse the Sun Javadoc, keep an eye out for descriptions of computational complexity (in the sense of Big-O or asymptotic complexity).  We have or will have talked in class about efficiency differences in List implementations -- ArrayList vs LinkedList.  See if you can find any discussion of this in the Javadoc; if so, print out one or two pages, circle the information, and turn in the pages.

Some rules (for this project):

In Project 3 a Model-View-Controller architecture was more or less mandatory.  In Project 4 Part A, it was also expected, but you may have had some legitimate questions about how to keep the parts separate, or even which was which.  In Part B, you may find it increasingly difficult to maintain MVC.  Don't stop trying!  But don't obsess over it, either.  Just try to keep aware of how or whether you solution adheres to an MVC approach to things.  At some future point of this project, you may be asked to comment on this.

Some advice:

Buona Fortuna!

Hints, Tips, and Corrections

More on mouse clicks: One interesting thing about Java's event structure is that more than one component may listen for events.  For example, several different components could add a mouse listener.  A single mouse click would be sent to all of the listener components (in no particular order).  You may or may not find this useful in Part B.  [Another note if you want or need to do this: it is simplest to create a separate listener object for each component that wants to listen.  It is also possible to create more than one class of listener, or you can create multiple instances of the same listener class; depends on the situation.]

 Rectangles, etc. Java has a Rectangle class, with methods suggestively named "intersection".  Also, AWT and Swing components have a "bounding box", which is a Rectangle delimiting the component (not necessarily visible as a border, though).  There is no Circle class -- you draw circles as Ovals.  Components do not have a "bounding oval".