How the original Rule Roundup Game was made

Classes:

QuizLauncher -- the actual applet - responsible for loading the graphics.

Quizzer (extends Panel) --the class that really contains the game. It is added to the QuizLauncher (or an application frame when running as an application).

QuestionManager -- responsible for getting the question file from either disk (if running as an application) or a URL connection (when running as an applet). It reads in a question file, tokenizes it to break down the individual pieces of each question, then randomizes the questions into a question database (String array). This class always knows the state of the current game's questions, and includes methods for returning the location of the correct answer, the explanation, the question text, etc.

("tokenize" is the technical term for "break things up into little pieces". You can use it to parse a simple flat-file database. If you have no idea what "parse", "flat-file", or "database" means, you will. In the mean time, just practice saying the words in front of your friends and coworkers. -- CowGirl)

PresentationManager (extends Panel) --the class that presents the quiz GUI interface to the user. It manages the radio buttons, the question text, and the done button.

(notice that I use the word "Manager" in some of my class names. A lot of Big Time Programmers like to use that word, so it makes my classes sound like they do Really Important Things. -- CowGirl)

CowPanel (extends Panel) --responsible for the animation that relates to the quiz. It is completely decoupled from the game so that any animation can be plugged into any quiz. Holds the run() method used by the Thread that keeps up the cow animation. Also manages the double-buffering of the cow animation by calling each cow's paint() method but giving the cow an offscreen Graphics object for composing an entire scene before painting it to the CowPanel.

(double-buffering is another one of those terms you might not be familiar with. It really means "paint the whole picture in the back room and when it's finally all ready, THEN bring it out and show it off". Unfortunately, if you don't use double-buffering on your animations, they may really suck. "Suck" is a technical term for "flicker and look bad"- CowGirl)

Cow -- for the unique cow object. Each cow has instance variables for Image, location, velocity, currentLook (left, right, legs out or in, etc.), inFence, onTheMove, etc. The animation is run by a Thread in the CowPanel.

ScoreKeeper --responsible for keeping track of rounds, scores, game status, point values (for games with questions of different point values).

RewardDisplay (extends Panel) --the class that presents the reward screen (gets the score from Scorekeeper object, then shows the user ranking).

GraphicalButton (extends Canvas) -- a custom component used for the .gif image buttons (Done, Next, etc.)

There are a few other small classes used including a utility class for randomizing arrays, and a class for wrapping text.

A few Notes:

Reading the File from the server -- Java applets don't actually "read" from the server, even though it usually looks like that's what's happening. Instead, you connect to a URL and using a standard HTTP "Get", you get the text at the URL specified (which is your text file). You then open a stream and read in the normal way. Check out the Code Barn's "HelloServerFile" example.

(do NOT be intimidated by Internet protocols. People get PhD's in this stuff, but you don't have to understand them all just to use them. Do learn how to pronounce them, though. You won't be invited to parties if you say URL as an acronym ("yuril"). You MUST pronounce each letter "YOU ARE E L" -- CowGirl, the Martha Stewart of Java Terminology

Displaying a message while the graphics are downloading -- You have two main choices when you load images into an applet:

1) Wait for all the images to load before letting the applet run most of its code

OR

2) Don't wait -- the user will see pieces of images as they are being downloaded.

The first option -- waiting -- makes a better overall user experience, but then there's that wait... still waiting... more waiting... and yet the browser's status bar shows that the applet has already loaded. The user thinks the applet has "hung" or "froze".

A good choice: use a MediaTracker object to monitor the download of the images, and update a status message for the user. [see Code Barn's LoadAGifMsg example]

The Roundup Game uses the simplest mechanism:

• The init() method sets a boolean variable for "graphicsAreIn" to false, then calls paint().
• The paint() method (overridden) does a simple if/else test. If the graphicsAreIn variable is still false, then a "Please wait..." message is painted using drawString(), and another method is called which downloads the graphics and starts the game.

It would have been nicer to have the status message change as the graphics are loading. Oh well... Next Version.