eberard@ajpo.sei.cmu.edu (Edward Berard) (10/15/89)
Folks,
Here is the specification for the Greed Game that was used for a
programming exercise at OOPSLA '89. The idea is simple:
Potential participants each received a (constantly updated)
copy of this specification. The object was to produce an
object-oriented implementation of Greed in the programming
language of your choice. The rules for the "contest" were:
1. Participants had to keep track of as many metrics
(e.g., numbers of compiles, classes, and instances,
development time, and source and object code size).
2. All deliverables (e.g., code, designs, etc.) had to
be made available to all other participants who
submitted a solution.
3. All participants who submitted a solution received
a prize -- a t-shirt, supplied by Hewlett-Packard.
About 10 solutions were presented on the evening of Tuesday, October
3, 1989. They addressed many different issues, from probabilistic
calculations of strategy, to galloping (forget creeping) featureism,
to how to best define the characteristics of the objects involved.
-- Ed Berard
(301) 353-9652
------------------------------------
Greed Specification
(Revised: September 15, 1989)
[Provided courtesy of Reed Phillips, Knowledge Systems Corporation,
114 Mackenan Drive, Suite 100, Cary, North Carolina 27511, Phone:
(919) 481-4000, and Tom Love, 30 East Woods Road, Roxbury, Connecticut
06783, Phone: (203) 350-4331.]
Greed is a dice game played between two or more players. The object
of the game is to tally points from the dice rolls and be the first
player to score 5000 points. There are five dice in the game that are
rolled from a cup.
To "enter the game" a player must score at least 300 points on the
first roll of his turn, otherwise the player is considered "bust". If
he goes "bust" he must wait his turn to roll again. If this first
roll produces 300 or more points, then the player has the option of
stopping and keeping the initial score or continuing. To continue,
the player rolls only the dice that have not yet scored in this turn.
If all the dice score, in one or multiple roles, the player may
continue by rolling all five dice. A player may continue rolling as
long as a score is made on each roll. With the exception of the entry
roll, a "bust" is when an individual roll produces no points. During
his turn the player may stop and keep his score after any roll as long
as he is not "bust". When a player is "bust" the only points lost are
those accumulated during the turn in which the "bust" occurs. In
other words he gets no points for that turn.
Each dice roll is tallied as follows:
- Threes of a kind score 100 * face value of one of the three
die. If the face value = 1, then it is scored as 1000.
- Single 1's and 5's score 100 and 50 points, respectively.
- Examples (Rolls to "enter the game"):
44446 = 400 points total
and would have the option to roll the 4 & 6 if
the player chose to role the 4&6 and they did
not score the player would be bust and would
have to try to "enter the game" on his next
turn. If the 4&6 score then the player could
continue by rolling all five dice.
11115 = 1000 +100 +50 points = 1150 points
and would have the option to roll all five
dice again
12315 = 100 + 0 + 0 + 100 + 50 points = BUST
Finally, the winner is determined after a player collects a total
score of 5000 or more and all players have had an equal number of
turns. If, for example, a player scores over 5000 points, he may
still lose if a subsequent player ends up with a final score greater
than his.
Getting Started
For design purposes, we should assume that the rules, strategies and
scoring algorithms can be changed. For this reason, the design should
be cleanly factored. Rules are not expected to change during play.
The designer is also encouraged to play the game a few times before
beginning the design. The following sections give a suggested basic
object breakdown for the design. There can easily be more objects
involved.
Game Object
The greed game itself can be considered an object. The game consists
of players, dice, a cup, and rules. The game object should also know
who started first, who's turn it is, and what the rolls are for the
current turn. It should be playable 'by itself' and independent of
the type of interface used. For example, the object should respond to
request (messages) like:
roll the dice,
go to next player,
restart game,
add a new player, etc.
The game object should be flexible enough to easily allow for
different game parameters such as:
different numbers of dice,
different minimum score to enter,
different high score,
different dice scoring rules, etc.
Die Object
Each die can be considered an object. It should know how to roll and
display itself. It needs to randomly choose and keep track of its
value. The die object would probably need an undefined state which
would represent it being shaken or sitting in the cup. A die in an
undefined state would also display itself differently (i.e. rolling
or spinning).
We will assume the die is a cube but the design should be flexible
enough to account for die with different numbers of faces (i.e. a die
with 11 sides).
Player Object
Players participate in the greed game and keep track of their score.
Their score tracking should also reflect the scoring history. A
player should at least know what his score was for each turn of the
game. Players have names. This player object expects an external
source (user) to make the decisions (i.e. when to continue rolling or
stop).
Computer Player Object
The computer player object is a subclass of player object that makes
his own decisions about whether to roll or stop. The computer player
allows a user to play greed with the computer. The intelligence about
whether or not to roll should be represented by a 'degree of risk' or
greediness factor. The computer player can also take into account
things like how far behind he is, is this his last turn, his history
of busts vs. rolls, etc. Any number and combination of players
(users) and computer players should be allowed.
Interface Model Object
This object is determined by your interface design. Its roll is to
orchestrate the game and players and to reflect player decisions and
game state. As a minimum, the interface should:
- show the dice graphically for current turn and roll
- allow players to be added and removed
- allow players to provide roll/stop decisions
- graphically display the scoring history of the players.
This could take the form of a monotonically increasing curve
for each player.
The designer is encouraged to use creativity when designing the
interface. This could be anything from animating the cup and dice to
giving the computer players or game a personality.