This simulation is still under development. There are a few missing pieces, and may be some small inconsitancies between documentation and actual code.
If you are still working on an assignment like this, you should not delve into my code, and I'd prefer that you only glance at the documentation for all but the simulation classes.
The files in this subsite illustrate the design and implementation of a few simple game simulations that are fairly closely related. The initial motivation for this system was the design of a simple simulator for Racquetball. The simplest simulator simply reads in the probability of each player winning when that player serves, and simulates a game. A more advanced simulator uses three values to simulate the game. Two simulators for ping pong (similar setting, different rules) are also included.
In attempting to develop these simulation, I have attempted to segment each core piece of functionality into a separate class. I've also subclassed where appropriate to permit better or different simulations.
Various design decisions led to the following classes. In this document, their purpose is summarized. More information can be found in the documentation for the individual classes.
Score, which keeps track of the score and service in a two player game.
ScoreBoard, which keeps track of not only score and service, but also the rules of the game. The ScoreBoard can report when a game is over or when a shutout occurs. The ScoreBoard also alternates service when appropriate.
PlayerKeeps track of basic information on players. Also used to determine the winner of a volley (a player is told to serve, and returns a boolean that indicates whether or not the server won the volley).
GameTies together the
ScoreBoardand the two
Players and runs a game.
RecordTableRecords the scores for each game, and presents summary statistics.
+--------------+ +---------+ | ScoreBoard | <---> | Score | +--------------+ +---------+ ^ | | +-----------+ v +> | PlayerA | <--+ +--------+ / +-----------+ | | Game | <--+ | +--------+ \ +-----------+ | ^ +> | PlayerB | <--+ | +-----------+ | v +-------+ +-------------+ | Sim | <----> | RecordTable | +-------+ +-------------+
Sim) is the heart of the simulation. It
There are a number of simulations (all of which fit under the Sim in the diagram). Here is basic information about their purpose. You can determine calling strategy by looking at their documentation.
RBsim1Simulates one game of racquetball when all we know is each player's likelihood of winning a volley when (s)he serves.
RBsim2Simulates racquetball when we know three things about each player: likelihood serves are in, likelihood serve returns are in, and likelihood that other shots are in.
RBstats1Computes statistics over some number of games.
PPsim1Simulates ping pong when all we know is each player's likelihood of winning a volley when (s)he serves.
PPsim2Simulates ping pong when we know three things about each player: likelihood serves are in, likelihood serve returns are in, and likelihood that other shots are in.
For each new simulation, I generally
I was able to provide the alternative simulation (with three
values, rather than one) by subclassing the
class. The choice to have the game tell players to serve and
ask them what happened meant that I did not have to change the
Game class at all. However, I will admit that my
current simulation is somewhat inefficient, since the computation
of the winner of a volley is done with a series of function calls.
My greatest hurdle in building this extension was ensuring that the overridden methods in the subclass were, in fact, called instead of those in the superclass.
My original design accomodated the change in rules by encapsulating
them in a generic
ScoreBoard superclass that I had
already had to subclass for the rules to racquetball. The
PingPongSB subclass was slightly more complicated to
design, because (1) I needed to add another field to keep track
of how many consecutive serves each player had made, so that I could
switch service after every five serves; and (2) an earlier assumption
that "the last server is the winner" no longer held.
Most modifications were reasonably quick. Compound modifications that
could draw upon earlier work were astoundingly quick. For example, I
was able to create
PPsim2 in less than five minutes, since
it required only five small modifications from
RBsim2 and no
new classes (the simulation extensions were done as part of the development
RBsim2, the rules extensions as part of
For both debugging and to keep it interested, I included an option for
players and games to report on what was happening as it happened. The
serve() routines take
an optional boolean parameter that, when true, asks them to be verbose
about what is happening. There are certainly other output-based debugging
strategies, but this seemed to give a good balance of simplicity and
usefulness. It is, however, somewhat computationally expensive, as it
adds a number of tests on the value of that variable.
As generated by javadoc.
Disclaimer Often, these pages were created "on the fly" with little, if any, proofreading. Any or all of the information on the pages may be incorrect. Please contact me if you notice errors.
Source text written by Samuel A. Rebelsky.
Source text last modified Fri Sep 12 11:20:18 1997.
This page generated on Fri Sep 12 11:23:26 1997 by SamR's Site Suite.
Contact our webmaster at email@example.com