Note: Descriptions are shown in the official language in which they were submitted.
CA 02319600 2000-09-14
METHOD AND APPARATUS FOR PROVIDING A COMPARTMENTALIZED GAME
INSTRUCTION ARCHITECTURE WITHIN A GAMING MACHINE
FIELD OF THE INVENTION
S This invention relates in general to a method and apparatus for organizing
the
game instruction architecture in a video gaming device. More particularly,
this invention
relates to a method and apparatus for compartmentalizing various game
instruction
modules within an overall architecture of a video gaming machine to provide re-
usable
software modules common to all games implemented on a platform which are
separable
from game-specific modules common to a specific video game.
BACKGROUND OF THE INVENTION
Computer-based, video gaming machines are becoming increasingly
commonplace to construct gaming devices such as slot machines, video poker
games, and
video roulette wheels. These automated video games utilize computing systems
containing software modules to implement gaming logic. These computing systems
also
utilize computer video display devices to present gaming players with images
of the
various gaming apparatus being implemented.
These computer-based gaming systems replace mechanical systems such as slot ;
'
machines comprising a plurality of rotating wheels and associated mechanical
logic. The
computing systems utilize a random number generator to determine a game
outcome that
statistically appears to be random in nature. The random numbers obtained from
a
random number-generating module are used to determine which symbols on the
wheels of
a slot machine axe to be displayed when the game concludes a play. Similarly,
these
random numbers are used to shuffle standard decks of playing cards used in
other games
of chance.
These computer-based gaming machines also comprise software modules which
when working together implement the rules of a particular game of chance. For
a slot
machine, these rules include the pay-out tables used to determine any winnings
paid to a
player for a particular combination of symbols shown on the rotating game
wheels.
Finally, the computer gaming machines comprise software modules which when
working
CA 02319600 2000-09-14
together display a series of images on the display device to simulate the
appearance and
operation of a gaming machine. These display modules typically comprise both
video
and audio output modules to provide a game player with a sensory experience
comparable
to the mechanical gaming machines.
Gaming machines that accept wagers and provide winning payouts are under a
wide variety of regulatory oversight procedures and provisions from
authorities of the
various jurisdictions that permit the use of these devices. These oversight
procedures and
provisions are concerned in part with providing a level of assurance that the
games
operate in the manner advertised. The behavior of the random number generator,
its
relationship to the outcome of the game implemented, and the winning pay-out
tables are
part of the functions of these gaming devices which are inspected. The
procedures for
obtaining regulatory approval for each gaming device may be a long,
complicated, and
expensive undertaking on the part of the gaming machine manufacturer and its
customers,
gaming establishment operators.
1 S At the same time, the gaming establishment operators desire a wide variety
of
different games to entice game players to play the gaming machines within
their
establishments. Part of this desire for a variety of different games includes
a desire to
periodically change the mix of different games present within the
establishment.
Establishment operators desire to increase the number of gaming devices of a
particular
type which induce players to wager larger amounts of funds and/or induce
players to play
these games for a longer period of time. At the same time, the operators
desire to remove
gaming devices which to not induce players to wager at profitable rates.
Computer-based gaming machines appear to address the establishment operators'
desires as computing systems are capable of generating a nearly infinite
number of
display images and audio combinations. As such, the computer-based gaming
machines
are capable of being reconfigured from a first gaming device to a second
gaming device
while utilizing many of the same components in a single configuration. One
issue which
may prevent the simple reconfiguration of a computer-based gaming machine from
one
game implementation to a second gaming implementation is the regulatory
oversight
approval for each gaming implementation.
CA 02319600 2000-09-14
The process of obtaining approval for a complete software implementation of a
gaming device that operates on a common computer-based gaming platform having
a
standard set of hardware components may be simplified with a software
architecture that
structures its software modules into an organization which re-uses a large
amount of its
software modules to implement functions common to all gaming devices. With
such a
software architecture, the common software modules would seek approval the
first time
the modules are used in a gaming machine. For subsequent game machine
implementation, the prior approval for the common module would be provided
along with
any changes implemented to the modules. Additionally, new modules used to
implement
game specific functions would be identified. As such, the previously approved
common
modules that may not change in a significant way may obtain approval more
quickly and
less expensively. The process of obtaining the approval for new gaming
implementations
may likely focus on the new game-specific modules. Since these modules
represent a
subset of an entire system, the approval may be obtained more quickly and less
expensively.
With the ability to more easily obtain approval for new gaming
implementations,
gaming establishments are provided with an improved ability to more readily
change the
gaming devices present in their establishments to satisfy the interests of
their gaming
players. The present invention provides a software architecture for
implementing
computer-based gaming machines to address the above problems in prior systems.
SUMMARY OF THE INVENTION
To overcome the limitations in the prior art described above, and to overcome
other limitations that will become apparent upon reading and understanding the
present
specification, the present invention discloses an apparatus for
compartmentalizing various
game instruction modules within an overall architecture of a video gaming
machine.
The video gaming machine comprises a video display, an audio output module,
and a plurality of user input buttons to provide re-usable instruction modules
common to
all games implemented on a video gaming platform. The apparatus comprises an
open-
source operating system, a plurality of platform support and utility modules
common to
all games run on the video gaming machine, and a plurality of game specific
modules and
associated data files, the plurality of game specific modules and associated
data files
CA 02319600 2000-09-14
comprise a game specific engine module for executing the instructions
implementing the
specific game on the video gaming machine.
The plurality of platform support and utility modules comprise a wagering
funds
module for accepting and paying out funds associated with wagers played on the
outcome
of the games run on the video gaming machine, a user interaction module for
generating
output display information and accepting user input instructions, a multimedia
output
module for generating output signals on the video display and audio output
module, and a
random number generator module for creating the random numbers used to
generate the
outcome of the games run on the video gaming machine.
The plurality of game specific modules and associated data files, the
plurality of
game specific modules and associated data files comprise a game specific
engine module
for executing the instructions implementing the specific game on the video
gaming
machine, a plurality of video image data files combined by the game specific
modules to
create a sequence of image displayed on the video display; and a plurality of
audio sound
data files played by the game specific modules to create a series of sounds
generated on
the audio output module in conjunction with the sequence of image displayed on
the
video display. These and various other advantages and features of novelty that
characterize
the invention are pointed out with particularity in the claims annexed hereto
and form a part
hereof. However, for a better understanding of the invention, its advantages,
and the objects
obtained by its use, reference should be made to the drawings which form a
further part
hereof, and to accompanying descriptive matter, in which there are illustrated
and described
specific examples of an apparatus in accordance with the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
In the following description of the exemplary embodiment, reference is made to
the accompanying drawings that form a part hereof, and in which is shown by
way of
illustration the specific embodiment in which the invention may be practiced.
It is to be
understood that other embodiments may be utilized as structural changes may be
made
without departing from the scope of the present invention.
Fig. 1 illustrates a video-based gaming machine according to one embodiment of
the present invention;
4
CA 02319600 2000-09-14
Fig. 2 illustrates a logical block diagram for a computer-based gaming system
used to implement gaming device according to a second embodiment of the
present
invention;
Fig. 3 illustrates an expanded logical block diagram of the processing system
202
used to implement the gaming device according to an embodiment of the present
invention;
Fig. 4 illustrates a system module block diagram of the software utilized to
construct the gaming machine according to one embodiment of the present
invention;
Fig. 5 illustrates a detailed system module block diagram of the software
utilized
to construct the gaming machine according to another embodiment of the present
invention;
Fig 6a illustrates the relationships between the Java classes associated with
a
Game Application Context;
Fig 6b illustrates the relationships between the Java classes associated with
a
Game Applet Context;
Fig 6c illustrates the relationships between the Java classes associated with
a
Station Context;
Fig 6d illustrates the relationships between the Java classes associated with
a
Device Layer Context;
Fig 7 illustrates the relationships between the Java classes associated with
Multi-
Player Classes;
Fig 8 illustrates the relationships between the Java classes associated with
Message Classes;
Fig 9 illustrates the relationships between the Java classes associated with
Local
Message Passing; and
Fig 10 illustrates the relationships between the Java classes associated with
Network Message Passing.
CA 02319600 2000-09-14
DETAILED DESCRIPTION OF THE INVENTION
In the following description of the exemplary embodiment, reference is made to
the accompanying drawings, which form a part hereof, and in which is shown by
way of
illustration the specific embodiment in which the invention may be practiced.
It is to be
understood that other embodiments may be utilized as structural changes may be
made
without departing from the scope of the present invention.
In general terms, the present invention relates to a method and apparatus for
compartmentalizing various software modules within an overall architecture of
a video
gaming machine to provide re-usable software modules common to all games
implemented on a platform which are separable from game-specific modules
common to
a specific video game. The embodiments of the invention described herein are
implemented as logical operations in a mass storage subsystem attached to a
host
computer system having connections to a distributed network such as the
Internet. The
logical operations are implemented (1) as a sequence of computer implemented
steps
running on a computer system and (2) as interconnected machine modules running
within
the computing system. This implementation is a matter of choice dependent on
the
performance requirements of the computing system implementing the invention.
Accordingly, the logical operations making up the embodiments of the invention
described herein are referred to as operations, steps, or modules. It will be
recognized by
one of ordinary skill in the art that these operations, steps, and modules may
be
implemented in software, in firmware, in special purpose digital logic, and
any
combination thereof without deviating from the spirit and scope of the present
invention
as recited within the claims attached hereto.
Fig. 1 illustrates a video-based slot machine according to one embodiment of
the
present invention. A gaming device 100 is used to implement the video-based
slot
machine and comprises a video display device 101, game-related artwork 102,
user
controls 103, a hopper 104, and wager input modules 105. Within the gaming
device 100,
a computing system is utilized to operate the gaming device 100 and generate
the video
images displayed upon the video display device 101.
Now refernng to Fig. 2, a logical block diagram for a computer-based gaming
system used to implement gaming device 100 is illustrated. The computer-based
gaming
6
CA 02319600 2000-09-14
system 200 comprises a plurality of mass storage devices 211-212, a video
connection
201 to video display device 102, and a plurality of user interface units 220.
The user
interface units 220 comprise a hopper 221, a coin acceptor 222, a set of
meters 223, a
button panel 224, and a bill validator 225.
The hopper 221 provides a game player with tokens or coins representing
something of value returned when the game player places a wager on an outcome
of a
play of the game resulting in a successful outcome for the game player. The
hopper 221
may be configured to return these winnings from the outcome of each play of
the game.
The hopper 221 may also be configured to return a current balance of funds
maintained
within the gaming device 100 upon receiving a command from the game player. In
the
latter embodiment, the winnings from any given outcome from a play of the game
are
added to a current balance maintained within the processing system 202. This
current
balance may be displayed upon one of the set of meters 223. The game player
may also
place wagers on the outcome of the play of the game from the current balance.
The coin acceptor 222 and the bill validator 225 provide the game player with
ability to input coins, tokens, or paper bills representing currency into the
gaming device
100 for use in making wagers on the outcome of a play of the game. The game
player
may input coins or tokens into the coin acceptor 222, and may input bills into
the bill
validator 225 before each play of the game is initiated. The player may also
input these
coins or other forms of money into the gaming device 100 to create the current
balance,
which is used to wager on a series of outcomes from the game.
The button panel 224 comprises a plurality of user input buttons used to
control
the operation of the game. These buttons may comprise a button to start a
game, a button
to return the current balance to the hopper 221, and one or more buttons to
determine the
amount of funds to be wagered on the outcome of the next play of the game. The
game
player depresses these buttons to provide a command to the processing system
202 how to
proceed with the operation of the gaming device 100.
Fig. 3 illustrates an expanded logical block diagram of the processing system
202
used to implement the gaming device 100. The processing system 202 comprises a
main
processing module 301, a video control module 302, a storage control module
303, and an
I/O control module 305. Each of these modules are coupled together using a
system
CA 02319600 2000-09-14
communications bus 304. The video display device 102 is coupled to the video
control
module 302 to display images generated by the processing system 202 to the
game player.
The mass storage devices 211-212 are coupled to the storage control module 303
to
provide the processing system with mass memory storage for the data and
program files
needed to implement the gaming device 101.
According to the preferred embodiment, the processing system 202 is
implemented using a computing system typically referred to as a personal
computer. The
computing system typically uses a PCI and ASI or PC-104 type system bosses to
implement the system communications bus 304. This choice to implement the
preferred
embodiment permits the main processing module 301, the video control module
302, and
the storage control module 303 to be implemented with a wide variety of
commonly
available system components. This choice also permits the periodic improvement
of the
processing system 202 with the upgrade of one of these modules as new and
faster
computing modules become available. The preferred embodiment utilizes a main
processing module 301 based upon a Pentium II processor manufactured by the
Intel
Corp. One of ordinary skill in the art will recognize that this processing
unit may be
based upon any number of alternate processing units manufactured by Advanced
Micro
Devices and other manufacturers as well as a PowerPC processor manufactured by
IBM
Corporation and Motorola.
Additionally, the preferred embodiment of the processing system 202 utilizes a
commercially available operating system, such as the Linux operating system
available
from Walnut Creek CD-ROM, as the 'Slackware' distribution. The operating
system is
stored upon mass storage disk 212 for execution with the main processing
module to
provide device driver support for the peripheral devices used to implement the
system.
The I/O control module 305 is a custom logic interface module for providing
connections between the user interface units 220 and the processing system
202. Each of
the various user interface units 220 comprise one or more electro-mechanical
device that
interacts with the game player. These units 220 accept electrical signals
generated by the
I/O control module 305 instructing the units to perform an operation. These
units 220
also generate electrical signals accepted by the I/O control module 305 for
use by the
software modules executing within the main processing module 301.
CA 02319600 2000-09-14
Now referring to Fig. 4, a system module block diagram of the software
utilized to
construct the gaming machine is illustrated. The software 401 of the gaming
device
comprises a plurality of software modules including operating system modules
402,
platform support and utility modules 41 l, and game specific modules 412. As
stated
above, the operating system modules 402 comprises a version of the Linux open
source
operating system. One skilled in the art will recognize that these modules may
alternatively be implemented using other operating systems such as Windows 98
and NT
from the Microsoft Corporation, other versions of Unix, and the MacOS
operating system
from the Apple Corporation without deviating from the spirit and scope of the
present
invention.
The platform support and utility modules 411 comprise a set of modules to
provide the gaming device 100 with interaction with the user interface modules
220 as
well as providing any audio and video output support not provided within the
operating
system modules 402. These modules are common to all of the different games
that are
implemented upon the gaming device 100.
The game specific modules 412 comprise a set of modules needed to implement a
particular version of a video-based gaming machine. The modules will include
gaming
instruction modules, audio files, and video files utilized to present the game-
related and
other images and audio information to the game player upon the display device
102.
These modules may also comprise modules to present advertising and
announcement data
in both audio and video formats to game players when a particular play of the
game is not
being conducted.
Fig. 5 illustrates a detailed system module block diagram of the software
utilized
to construct the gaming machine. Once again, the software modules 400 of the
gaming
device 100 comprise operating system modules 402, platform support and utility
modules
411, and game specific modules 412. The platform support and utility modules
41 lcomprise a hopper module 511, a bill and coin acceptance module 512, a
meter
display and register module 513, a buttons module 514, an audio output module
515, a
video output module 516, and random number generator 517. The game specific
modules
412 comprise a game specific engine module 501, video image data files 502,
and audio
sound data files 503.
CA 02319600 2000-09-14
The hopper module 511 controls the operation of the hopper user interface unit
221 to return winnings to game players from wagers made on various plays of
the game.
The hopper 221 returns coins, tokens, and other forms of currency upon
receiving
appropriate commands from the hopper module 511. The hopper module S 11
interacts
with other modules to determine the proper amount of winnings to be provided
by the
hopper 221 and instructs the hopper 221 to return the proper number of coins
in
appropriate denominations to provide the winnings.
The bill and coin acceptance module 512 interacts with the coin acceptor 222
and
bill validator 225 user interface units to accept currency for use in making
wagers on the
outcome of a particular play of the game. The bill and coin acceptance module
S 12
determines the proper numerical value for the bills and coins inserted into
the user
interface units. The module 512 will interact with the meter display and
register module
513 to add the value of each coin and bill inserted into an accumulator
register that holds
the amount of funds available for use by the game player for making wagers on
the
outcome of particular plays of the game.
The meter display and register module 513 maintains the accumulator register
that
holds the amount of funds available for use by the game player for making
wagers on the
outcome of particular plays of the game. This module 513 generates the signals
needed to
display this value upon one or more meters 223 and displays 102 on the gaming
device
100 for viewing by the game player. The module 513 will also maintain and
display other
values such as the number of plays completed by the game player, an amount of
a jackpot
award available to be won, and the amount of winnings awarded by the gaming
device
over a specified period of time.
The buttons module 514 interacts with the buttons user interface unit 224 to
accept
inputs to the gaming device 100 from the game player. The module S 14 detects
when one
of the buttons are depressed. The module 514 decodes the button and generates
the
corresponding command to an appropriate module responsible for implementing
the
desired instruction. The buttons module 224 is also responsible for generating
any signals
necessary to illuminate and flash lights that may be part of the buttons
module. In one
possible embodiment, lights associated with the buttons which are encoded to
generate
valid commands to the game at a given time may be illuminated. The other
buttons
to
CA 02319600 2000-09-14
would not be illuminated to provide an indication to the game player which
buttons may
be depressed to initiate action. The se lights associated with the various
buttons on the
buttons panel 224 may be flashed when the game in not being played as to call
attention
to game to game players present in the gaming establishment.
The audio output module 515 and the video output module 516 generate the
appropriate output signals to generate signals necessary to display a sequence
of images
upon video display unit 102 along with corresponding audio signals to provide
the game
player with a desired experience while playing the gaming device 100. These
data output
modules perform general output functions necessary to output game images and
audio,
advertising images and audio, and general announcement images and audio. Other
modules within the software system 401 generate and format the audio and video
data
into the proper format necessary for output by these routines.
The random number generator 517 generates a pseudo-random number for use by
the specific game engine module 501 to generate the outcome of the gaming
device. The
random number generator module 517 is based on a method described by Knuth in
volume 2 of the Art of Computer Programming. In this method, random numbers
are
drawn from an initial random number generator module S 17 implementation to
populate a
table of sufficient size (1000 by default) and these numbers are used as
indices back into
the table to draw and replace the numbers in the table. This can be shown to
remove
banding.
In addition, a background process draws numbers from the table at frequent but
imprecise 100 ms intervals and discards them, making them unavailable to the
game. The
startup second of random number generator module 517 class loading is used as
the seed.
These 2 elements render number selection by the game truly random. The random
number generator module 517 is invoked at least once during each polling cycle
to insure
compliance with the Nevada regulation requiring at least 100 background draws
per
second.
In the preferred embodiment, two implementations of this method are included:
a
pure Java implementation where the random number generator used as the basis
is the one
included with Java and a native implementation employing a Linear Shift
Register to
generate the underlying random sequence. This implementation saves it's seed
11
CA 02319600 2000-09-14
periodically in non-volatile RAM and restores it at startup. This random
number generator
module 517 is currently implemented in a preferred embodiment as a Linear
Shift
Register Random Number Generation, with coefficients a = 16807, c = 0, m =
Ox7fffffff,
where R9(n+1) _ ((a * R(n)) + c) mod m.
Further information on Linear Shift Registers is available in Applied
Cryptography, Second Edition by Bruce Schneier; John Wiley and Sons: 1996.
The game specific module 412 comprises video image data modules 502 and
audio sound data modules 503 for output by the above two output modules during
the
playing of the game. These data modules comprise audio and video data files
which may
be simply played for viewing and listening by the game player. These data
modules
further comprise audio and video files which may be combined together to
synthesize the
output audio data streams.
For example, the video data modules may comprise a series of images that
represent the reels of a slot machine in all of the possible positions. The
video data files
may fixrther comprise a set of background images and a set of slot machine
images that
are combined with the images of the reels to create a composite image that is
presented to
the game player. At the same time, audio files relating to the rotation of the
wheels may
be played while the images illustrate rotating wheels. Similarly, audio files
for
celebrations and disappointment may be played at the conclusion of the play
once the
reels stop rotating to provide the game player with an enhanced game
experience.
Other examples of this process comprise a set of images of playing cards, a
set of
card table arrangements, a set of dealer's hand images in various positions, a
set of audio
files of shuffling cards, a set of audio files of cards being dealt, and audio
files for
celebrations and disappointment being combined to create a video-based card
gaming
machine. One skilled in the art would recognize how other games of chance such
as
craps, roulette, and like games may be constructed from the synthesis of many
smaller
images and audio files.
The game specific engine module 501 comprises a set of modules to implement
the specific game desired to be run on the gaming device 100. These modules
would
define the game, the relationship between the elements such as cards and
reels, and the
12
CA 02319600 2000-09-14
inputs from the game player to initiate and complete a play of the game. These
modules
are the only instruction modules needed to be changed when the gaming device
is
reconfigured from one game to another.
In the preferred embodiment, the game specific modules 412 and the platform
support and utility modules 411 are implemented in an object oriented language
such as
Java from Sun Microsystems.
Software consists of a bootstrap ROM-DOS system and Linux kernel in EPROMs
or boot record of a CD-ROM 211, with Linux system libraries, Java interpreter,
game
code and sound and image files on the CD-ROM 211. ROM-DOS is booted initially;
ROM-DOS loads Linux along with a stripped-down root file system, using a GNU
Public
License utility LOADL1N.EXE. Linux mounts the CD-ROM either directly, or via
NFS
(Network File System) over Ethernet in the case of mufti-player games. System
libraries,
X (if the system supports graphics) and the Java interpreter are loaded from
the CD-ROM
211. The Java interpreter loads and initializes the game code and any
additional libraries
that may be required, including the Random Number Generator module 517. The
game
code loads meter values, events and play history from NVRAM and initializes an
Online
Accounting System,if appropriate.
The game then loops until it is shut down, either by a power down, or some non-
recoverable error. While looping, the game monitors the required security
switches,
credit input devices and game-control devices.
When a switch is open or there is a severe error on any device, the condition
is
displayed and may only be cleared by opening at least one door and
subsequently closing
all open doors. Jackpot alarms or hand-pay requests may be cleared with the
attendant
key. When an attendant key is in the "on" position, audit mode is entered,
where meters,
events, the bill-log and play history may be viewed.
In the case of a required hand-pay, an alarm is set that may only be cleared
by
pushing a cash-out button, with the attendant key in the "on" position. A hand-
pay is
required whenever some statutory cash amount must be paid or a hopper pay-out
limit is
exceeded.
13
CA 02319600 2000-09-14
Included in the root file system is a utility, whichplayer. If the station is
a remote
player (as in multi-player blackjack), the user is given an opportunity to use
this utility to
set the player >D to a number from 1 through 5, using whichplayer. Once the
player ID
has been set, whichplayeronly runs if the attendant key has been turned to its
"on"
position.
Within whichplayer, the clear switch must be set to its "on" position inorder
to set
the player ID. The player ID is then set by means of the trouble switch; each
time the
trouble switch is pressed, the player IDtoggles to the next value. The utility
exits when
the clear switch is set to its "off' position, or the attendant key is turned
to the "off'
position and a player ID has been selected.
Next, an attempt is made to initialize the network connections. In the case of
a
remote player, this can only be done after successfully setting the player ID.
If more than
one player has the same ID, one or both will hang at this point; neither will
have a reliable
network connection. In the case of the dealer or a single-player game, network
initialization failure is not fatal, but if the dealer fails to initialize, no
communication
takes place with the remote players and they will utimately fail to mount the
CD-ROM,
and exit. In the case of a remote player, excution will halt immediately if a
networkconnection cannot be initialized.
In the boot image and game-specific executables on the CD-ROM are verified at
this time. When the CD-ROM is created, a file named "medium.verification" is
placed on
the CD-ROM. This file contains the 16-bit CCITT CRC values and sizes of the
files.
Before the game can be started, this file is re-created in memory and compared
to the CD-
ROM. If any discrepancy is found, the game will not be loaded.
The current implementation of the software requires the use of X as the
presentation layer for graphical games. This is required by Java AWT (Abstract
Windowing Toolkit). If X fails to load correctly, execution halts with
appropriate error
messages on the video display. Once X has loaded, error messages may be hidden
by the
X display. To view them, a standard PC keyboard may be attached to the
motherboard.
By typing CTRL-ALT-F1, the text console appears. The user may then type SHIFT-
PageUp and SHIFT-PageDown to view the text. Immediately after X is loaded, the
JVM
14
CA 02319600 2000-09-14
(Java Virtual Machine) starts and begins to load either a graphical shell for
the game code
(if there is a video display) or a non-graphical application for controlling
the game loop.
The game-specific code is derived either from a non-graphic class,
powerpit.mains.BaseGame or a graphical class derived from
powerpit.mains.GameApplet
(a sublass of java.applet.Applet). The class BaseGame implements basic station
loading,
message and event handling, common to all games. It also processes some
parameters
such as hopper limits (HAND-PAY), game denomination (DENOMINATION) or
maximum bet allowed (MAX_BET). The class GameApplet uses an instance of
BaseGame to provide
this functionality for graphical game stations.
In addition, GameApplet adds generalized graphical functionality for
implementation of displays for game-play, audit screens and alarm conditions.
In any
form, the game portion of the software reads the required parameters, attempts
to load a
station and log files (if defined), then loops until stopped by some error
condition,
responding to inputs from the player devices or network messages (if mufti-
player).
If a graphical display is used, as on a dealer station for mufti-playergames,
the
game applet must be launched indirectly through the graphics shell (similar to
a WWW
browser), implemented by powerpit.mains.ShellFrame and
powerpit.mains.MainFrame.
An otherwise empty main() routine in ShellFrame is used to read the command-
line
arguments and pass them to a instance of MainFrame, whichimplements the
required
context for a game applet.
Configuration is by means of a configuration file in the following format:
1. Comments are either totally blank or begin with "//" (2 slashes as with a
Java or
C++ comment);
2. Keywords (parameter names) begin in column 1;
3. Parameter values are seperated from a keyword by at least 1 blank or tab;
the
values continue until a new keyword (non-comment) or end-of file;
CA 02319600 2000-09-14
4. Parameter values may contain non-nested, quoted strings. E.g: PARMl a "b c"
d is valid, but PARM2 a "b c "d a"" is not; and
5. If parameter names are duplicated, only the first set of values is used.
The name of the configuration file is passed on the command line as either a
relative or absolute path. The configuration file resides, with the game code
on the CD-
ROM locked in the logic cage. Note that many of the parameters (e.g: GAME
APPLET,
STATION, HOPPER) take fully qualified Java class names as their arguments.
This
simplifies manufacturing, testing and regulatory submission by indicating the
actual code
specific to each configuration. Fig. 6a-6d contain Unified Modeling Language
(UML)
diagrams of the relationships between the main Java classes used in all games.
Fig 6a illustrates the relationships between the Java classes associated with
a
Game Application Context. The Game Application Context comprises a Non-
Graphical
Game class 620 which interacts with liob Device 625, JaudioCip 623,
OtherUtility class
622, ConfigurationFile 621, and BaseGame 610. BaseGame 610 interacts with
classes
GameState 615, JLog 614, Station 613, Queue 612, JRandom 611, and
BaseGameInterface 601. BaseGameInterface 601 interacts with GameInterface 602,
which in turn interacts with MessageInterface 603 and ParameterInterface 605.
MessageInterface 603 interacts with Message 604. JAudioClip 623 interacts with
AudioClip 624 from java.applet.
Interface powerpit.mains.BaseGameInterface 601 is an interface required for
all
game classes. The class includes:
attendantKey() Return attendant key value (on/off)
destroy() Halt game execution
getDenomination() Get game denomination
getMaxBet() Return maximum bet allowed
getMinBet() Return minimum bet allowed
getName() Get unique class name of game
getNumberOfPlayers() Return number of players (required for GameData)
getRNG() Return reference to random number generator for game (may be null).
getSequence() Get game sequence identifier
getState() Get game state from GameData or subclass
lastAlarm() Return most recent alarm condition
Interface powerpit.mains.GameInterface 602 is a public interface.
Gamelnterface
extends MessageInterface and ParameterInterface.
16
CA 02319600 2000-09-14
Interface powerpit.mains.MessageInterface 603 is a public interface.
MessageInterface includes:
processMessage(Message) process a message sent to this class
Class powerpit.messages.Message 604 implements abstract base class for system
messages and provides the standard methods to allow queuing, logging, display
and
network transmission of all internal data representing events within the game
system
along with the resulting overall game state. The class includes:
copyOf(Message) make a copy of an arbitrary message
date(long) return formatted date string
display() display message data in ASCII
expand(byte[]) expand packed message data into actual message
getClassName(byte[]) Find class name in packed data, so we can instantiate the
message
loadMessage() test routine for incorporation in derived class tests
pack() return packed data for network transmission
testMessage(byte[])test routine for incorporation in derived class tests
unpack(byte[]) decode packed data after network transmission
Interface powerpit.mains.ParameterInterface 605 is a public interface for
ParameterInterface. It included getParameter(String) return ASCII string value
of
specified parameter.
Class powerpit.mains.BaseGame 610 is a non-graphical game base class. It is
used
as an adapter by GameApplet; extended by any non-graphical game; e.g. spinning
reel
slot driven by stepper motors. The class includes:
adjustStatus() set game state to idle if there are no players available, ready
to play
the game.
alarmMessage(AlarmMessage) handle various game tilts
attendantKey() return attendant key value
audit() toggle audit flag
auditCheck() audit check performed in player game loop before each game cycle
autoplay() return true if game is in autoplay mode
canPlay() Return an array of references to those Player Stations with credit
available for play.
clearSwitch() Return clear switch value
debugPrint(String)
debugPrintln(String)
destroy() end game and clean up any loose threads
17
CA 02319600 2000-09-14
emptyQueue() Reset game event queue and force garbage collection
emptyQueue(int) re-call emptyQueue repeatedly for ms milliseconds
getAlarmList() return ASCII descriptions of alarms since the game was last
playable
getDealer() Get the dealer station
getDenomination() Get the game denomination
getLog() Get the state log
getMaxBet() Get the maximum bet
getMinBet() Get the minimum bet
getName() Get unique class name of game
getNumberOfPlayers() Return number of players (required for GameData)
getParameter(String) return configured parameter as an ASCII string
getPlayer() Get the player station
getPlayers() Get the player station stubs for a multiplayer game
getRNG()
Return reference to random number generator for game (may be null).
getSequence()
Get game sequence identifier
getState()
Get game state from GameState or subclass
getStateData() Get the whole state data block
getStation() Get the station (may be player or dealer)
init() Do minimum game initialization: get STATION, DENOMINATION
MIN_BET, MAX_BET, HAND_PAY, GENERATOR and STATE LOG
parameters.
isAlarmed() test for current tilt of any kind, other than jackpot
j ackpot() test for current j ackpot tilt
killGenerator() Terminate with extreme prejudice; should be used only in games
and by Stopper class.
lastAlarm() return most recent alarm condition
nextMessage() This is the individual Game's only window into the message
queue.
poll() perform periodic polling of Staion/device interfaces
processMessage(Message)
resetTournamentCredits(long)
3 5 resetTournamentTimeout(long)
setStateData(GameData)
Replace state data
setTimeout(int)
implement timeout handling in a standard way; this helps insure that timeouts
will
not expire because of asynch garbage collection.
start()
Recover saved state from log if possible; finish generic setup.
startStation()
Start the station
startTournament() called by player station on the first valid bet, to start
timer
timeToStop() Used by individual Game to read m_fStopNow flag.
tournament() Is the game in tournament mode?
tournamentCredits() set tournament credits
18
CA 02319600 2000-09-14
tournamentIsOver() tournament play ends when credit goes to 0, or when timer
expires
tournamentSecondsLeft() how many seconds are left in tournament mode
tournamentStarted() has the tournament round started? called by game (or
anybody else that needs to know)
tournamentTimeout() has the tournament round timed out?
troubleSwitch() return trouble switch value
waitingForHandpay() are we waiting for a handpay?
Interface powerpit.chance.JRandom 611 is a public interface. JRandom 611
Provide a standard interface for random number generation. Allows distribution
of a
default generator for development, then use of approved generator on gaming
machines.
The class includes:
display() Toggle display of random numbers as they are drawn.
getModulus() Retrieve modulus for random numbers.
nextInt() Draw the next random number.
Public class powerpit.mains.Queue 612 provides storage for game events from
the
machine, such as button presses or play step information in multi-player
games. The class
includes:
get() Retrieve messagefrom queue.
getLeft() Get space remaining in queue.
getSize() Return total capacity of queue.
put(Object) Put message in queue
reset() Empty queue
Class powerpit.devices.Station 613 is a public abstract class. Station
implements
GameInterface and StateInterface Base class for player and dealer stations.
The class
includes:
candleOff() manual control of error candle by game
candleOn() manual control of error candle by game
disable() disable station, as for alarm; stop generation of game-related
events,
other than tilts
disableHardMeters() temporarily stop rolling hard meters to prevent glitching
displayLog(int) provide ASCII text of specified log contents
enable() enable station to generate all game-related events, such as button-
presses
enableHardMeters() enable hard meter pulses
getParameter(String) as above
getState() Return integer representing station state
isClient() let the game know if it's a serial client for test
isConsole() let the game know if it's a serial console for testing
offline() Take station offline in multi-player game
poll() poll attached peripheral devices and insert events in game queue if
required,
19
CA 02319600 2000-09-14
by invoking game's processMessage() method.
powerDown() process power-down signal from io board
print(String) print something if ticket-printer is attached
processMessage(Message) see above
S register(IiobDevice) used by game to register specialized devices with the
iiob;
can only be invoked while station is offline, before first call to enable ().
resetLogs() for polymorphism; should be overloaded by any subclass with logs
in
addition to meters and events - overloaded by player station for play
history and bill logs; invoked by powerpit.mains.Audit to display all logs
in audit mode.
resetMeters() reset any logs that need it
shutdown() Shut station down at game exit.
Class powerpit.mains.audit.JLog 614 is a class that includes:
display() provide stored data in ASCII format for display
NMI() set flag to indicate write to logs is forbidden during power-down
sequence
clean-up
NMIReceived() used by any class that needs to know power-down sequence has
been initiated
recover() Recover operation for specific object type to be logged.
save(Obj ect) Abstract method must be implemented by each subclass - save
message to log.
Class powerpit.mains.GameState 61 S is a base class containing integer values,
indicating game state. Used by GameData subclasses to indicate last saved
state for
recovery after power-down or other catastrophic failure.
Class powerpit.mains.ConfigurationFile 621 read values from configuration file
on CD-ROM and store them so getParameter() calls from other game classes can
be
serviced.
checkVersion() check current configuration against value stored in non-
volatile RAM
getParameter(String). The class includes the following:
isNewVersion() return true if version has changed; called by AuditCheck() in
main game loop
resetVersion() reset version information
Other Utility classes 622 are game specific utilities required for individual
implementation of game "personality". E.g. card decks, roulette wheels,
combination
tables for slots.
CA 02319600 2000-09-14
Class powerpit.mains.JAudioClip 623 implements abstract base class
java.applet.AudioClip from Sun Microsystems Java 1.1 specification. The class
adds
capability to play Microsoft WAV files. The class is used by game software, in
conjunction with separate C-language sound server to play sound files.
Public Class java.applet.AudioClip 624 is a Sun Microsystems abstraction of a
sound file.
Interface powerpit.devices.IiobDevice 625 is an abstract base class for
devices that
need to register with the IIOB. First it is created in an OFFLINE state by a
station. Next,
the station causes the device to register with the IIOB. The IIOB enables the
device when
it is ready to accept data. The IIOB then disables the device when a power-
down
notification is received or the physical device is otherwise disabled.
Finally, getData() is
invoked whenever there is data ready for the registered object. The class
contains the
following applets:
disable() Invoked by IIOB to stop device.
enable() Invoked by IIOB to bring device online.
getData() Invoked by IIOB when data has been received on a line registered to
the
obj ect.
register(IIOBBase) Invoked by Station or other device "owner" to cause device
to
register with IIOB game software for configuration on the physical iiob.
Fig 6b illustrates the relationships between the Java classes associated with
a
Game Applet Context. The Game Applet Context comprises a GameApplet class 640
that
interacts with classes Applet 642 from java.applet, GraphicalGame 645,
BaseGame 641,
MainFrame 630, and BaseGameInterface 635. MainFrame 630 interacts with classes
AppletContext 631 from java,applet, AppletStubt 632 from java,applet, Window
633
from java,applet, and ParameterInterface 634. GraphicalGame 645 interacts with
classes
liobDevice 651, JAudioClip 652 from java.applet, and Other Utility Classes
653.
JAudioClip 652 ineracts with class AudioClip 654 from java.applet.
BaseGameInterface
interacts with class GameInterface 644, which in turn interacts with
ParameterInterface
646 and MessageInterface 647. MessageInterface 647 itself interacts with class
648.
Public Class powerpit.mains.MainFrame 630 extends Window implements
AppletContext, AppletStub, ParameterInterface. Usage is: MainFrame.main
(<configuration>), where configuration: configuration file name. An object of
class
MainFrame is created by JShellFrame, which retrieves the configuration file
name from
21
CA 02319600 2000-09-14
its command line. Information to launch the Game applet comes from the
configuration
file. Note that the members other than main() and the appletContext and
appletStub
methods are private; the class is final and can have no subclasses. It
implements the
graphical environment normally supplied by a "browser" so a GameApplet can
execute.
Public Interface java.applet.AppletContext 631 is a Sun Microsystems
abstraction
of the basic context required for graphical applet execution.
Public Interface java.applet.AppletStub 632 is a Sun Microsystems abstraction
of
stub functions required for graphical applet execution.
Public Class java.awt.Window 633 is a Sun Microsystems abstraction of an
execution window in any GUI.
Public abstract class GameApplet extends Applet 640 implements Runnable,
Gamelnterface and BaseGameInterface. This is the abstract base class for all
games with
graphics. Note that specific game subclasses of this class are configured by
the main (or
browser) from the configuration file. The class includes:
adjustStatus() This routine checks whether any players are available for a
game
and sets the game state to idle if there are not.
alarm() display alert with last alarm
alert(String) Display alert text over existing background.
attendantKey() return attendant key value
audit() instantiate powerpit.mains.audit.Audit () to handle player audit
screens
auditCheck() audit check for meter consistency performed in player game loop
before each game cycle
canPlay() Return an array of references to those Player Stations with credit
available for play.
clear() Redraw default background, foreground, cursor, alert.
clearAlert() Clear alert message for specific screen segment.
clearSwitch() return clear switch value
clipImage(Image, int, int) Clip image frames for complete tiling, as for
animation,
card decks, etc.
clipImage(Image, int, int, int, int) Clip image to specified rectangle.
cursor(Image, int) Add cursor image. E.g. hand to place bets or rake in dice
or
roulette game.
destroy() exit game
draw(Image, Point) Add an image, without clearing the screen at the specified
location.
drawAlert(Graphics) draw alert in lower right corner for "door-closed" type
messages; otherwise, draw normal alert box.
emptyQueue() empty the game event queue
22
CA 02319600 2000-09-14
emptyQueue(int) empty the queue repeatedly for ms milliseconds
foreground(Image, Point) Add foreground image with upper left corner at the
specified point; foreground will not be revealed until after the next time
clear() is invoked.
getDenomination() Return game denomination
getMaxBet() return maximum bet allowed; note that this should never be called
unless at least one player was previously enabled.
getMinBet() return minimum bet allowed; note that this should never be called
unless the player was previously enabled.
getNumberOfPlayers() Return number of players (required for GameData)
getRNG() Return reference to random number generator for game (may be null).
getSequence() Return game sequence (from m state game data) for player win
data.
getState() Return integer game state value.
hideCursor(int) Stop displaying the cursor.
increment() Increment game sequence.
init() Recover previous state information; connect to dealer and player
stations and
required devices.
isAlarmed() return true if game has unresolved tilts.
isAlive() Is the game able to function normally? Used by MainFrame to
determine
whether to exit completely or not.
isJackpot() has the current game ended in a jackpot award?
jackpot() if the current game ends with a jackpot award, handle the clear
procedure
lastAlarm() return most recent alarm condition
loadImage(String) Encapsulate robust, synchronous image loading.
moveCursor(Point, int) Move cursor to a new position.
nextMessage() This is the indvidual Game's only window into the message queue.
paint(Graphics) overload paint() method from
poll() cause local and network inputs and outputs to be serviced
processMessage(Message) The method that gets called to distribute button and
play messages into the messageQueue so the game loop can examine them;
processes commands and alarms locally; ignores others.
refresh() redraw screen with current background, foreground, alert and cursor.
repaint() Update the screen (send it or repaint it, as appropriate).
run() Abstract method; implements game event loop; i.e. poll() and game-
specific
methods are called here; alarm (tilt) methods and auditCheck() method for
meter auditing are calledd in this loop to run game as a finite state
machine.
setStateData(GameData)
Replace state data
setTimeout(int)
implement timeout handling in a standard way
showCursor(int)
Show cursor (if cursor image and position are set).
start() Let the game begin! Invokes the specific game's startGame() method.
startGame() Game-specific initialization and recovery routines.
stop() Pause the runner thread.
timeToStop() Used by individual Game to read m fStopNow flag; signals receipt
23
CA 02319600 2000-09-14
of shutdown or power-down notice
tournament() is the game in tournament mode
troubleSwitch() return trouble switch value
update(Graphics) overload Applet method to stop flicker
Java.applet.Applet 642 is a Sun Microsystems generalized implementation of a
limited, secure application framework for execution within a well-defined
"browser"
environment.
Fig 6c illustrates the relationships between the Java classes associated with
a
Station Context. The Station Context comprises a Station class 660 that
interacts with
classes SwitchHarness 661, MeterModel 662, Candelabra 663, DealerStation 670,
Player
Station 669, JLog 668, Device 680 (which in turn interacts with GameInterface
682),
liobDevice 667, IIOBase 666, and StateInterface 665. Gamelnterface 664
interacts with
MessageInterface 686 and ParameterInterface 684. MessageInterface 686
interacts with
Message 685. IIOBBase 666 interacts with classes liobDevice 667 and message
683.
LiobDevice 667 interacts with classes IIOBBase 666 and Device 680, which in
turn
interacts with GameInterface 682. DealerStation 670 interacts with classes
PlayerStub
671 (which in turn interacts with PlayerInterface 672), ServerSocket 673,
ClientSocket
674, and Connection 678. PlayerStation 669 interacts with classes ButtonPanel
675,
OnlineSystem 676, NetworkPlayer 677, and PlayerInterface 679, which in turn
interacts
with Statelnterface. Finally, ServerSocket 673, NetworkPlayerStation 677, and
Connection 678 all interact with ClientSocket 674.
Class powerpit.devices.SwitchHarness 661 is a public abstract class.
SwitchHarness extends Object Describes the station switch harness for a game.
It is
subclassed by differing machine types to handle system events associated with
the portion
of the wiring harness devoted to security switches; e.g.:
powerpit.slots.NVSMSwitchHarness is used to specify the video slot switch
operations.The class includes:
addSwitch(int, Boolean, int, int) add another switch; should be used only in
constructor
poll() poll the switches when re-enabled after alarm
register(IIOBBase) register all the switches with iiob
Class powerpit.devices.MeterModel 662 is a public abstract class. MeterModel
extends Object implements ParameterInterface, an abstract meter model for a
Station. It
24
CA 02319600 2000-09-14
Instantiates soft meters for coin-in, coin-out, drop, credit, bet, paid, games
played and
games won. Hard meters and soft meters both incorporate the functionality
required for
any meter. It is subclassed by differing machine types to handle meter updates
and system
events associated with the portion of the wiring harness devoted to meters;
e.g.:
powerpit.slots.NVSMMeterModel and powerpit.slots.COSMMeterModel are used to
specify the video slot meter operations for Nevada and GLI/Colora.do
jurisdictions,
respectively. The class includes:
addCoinOut(int) add special meter for physical coin-out to interact with
hopper;
called only by constructor.
addHard(int, int) Add hard meter to model; called only by constructor
addSoft(int) Add soft meter to model; called only by constructor
addToUpdate(Meter) Add meter to updated list for logging (once per polling
cycle)
adjustCredit(CreditMessage) Adjust meters for credit.
adjustMeter(MeterMessage) Process meter data.
cancelGame() Cancel current game.
cashing() tell the station whether we're cashing out or not
cashout() Update meters for cashout.
disable() disable hard meters for alarm
disableHardMeters()disable hard meters in game loop
displayMeters() provide ASCII text display for meter values
enable() enable hard meters after alarm
enableHardMeters() re-enable hard meters in game loop
endGame(long) Adjust meters for end of game.
findMeter(int) find an arbitrary meter object, based on type as defined in
abstract
class Meter; used internally and by Station.
getBet() Return value of bet meter.
getCashIn() Returns total value of cash in from all sources.
getCashOut() Returns total value of cash out from all sources.
getCoinIn() Return value of (nevada) "coin in" (cumulative bet) meter.
getCoinOut() Return value of (nevada) "coin out" (cumulative win) meter.
getCredit() Returns value of credit meter.
getCreditSince() Returns credits since last game
getEscrow() Return value of escrow meter.
getPaid() Returns value of paid meter.
getParameter(String)
getUpdated() Used by Station to retrieve updated meters, when sending to
dealer
in multiplayer game , or by any Station for logging at end of polling cycle.
handpay() clear handpay-required tilt by transfernng credits from credit
meter.
increaseBet(long) Adjust meters for bet.
increment(int, long) Increment an arbitrary meter by type
ramClear() clear meters in NVRAM
recover(MeterMessage[]) Recover the meters from saved data; shows a message
on the console if there is a missing meter.
CA 02319600 2000-09-14
register(IIOBBase) Register the hard meters with the iiob
reset(int, long) Reset a meter
resetMeters() reset all meters to 0 after a ram-clear
resetTilts() reset hopper tilts
startGame() Updates games played.
stopRolling() clear m (Rolling flag for i/o board reset
undoBet(long) Cancel bet.
Class powerpit.devices.Candelabra 663 is a public abstract class. Candelabra
extends Object and describes the station candles for a game. It is subclassed
by differing
machine types to handle system events associated with the portion of the
wiring harness
devoted to candles; e.g.: powerpit.slots.NVSMCandles and
powerpit.blackjack.NVBJDCandles are used to specify the candle operations for
video
slot candles and blackjack dealer candles, respectively. The class includes:
1 S addCandle(int, Boolean, Boolean) add another candle; should be used only
in
constructor
attendantOff() dim attendant/service/change candle
attendantOn() light attendant/service/change candle
deselect() dim ready-to-play candle in multi-player games
errorOff() dim error candle
errorOn() light error candle
register(IIOBBase) register all the candles with iiob
select() light ready-to-play candle in multi-player games
winOff() dim win candle
winOn() light win candle
Interface powerpit.devices.StateInterface 665 provides a state interface
required
for DealerStation, PlayerStation, PlayerStub, NetworkPlayerStation - defines
consistent
integer values for state interfaces in various station types. The interface
includes:
disable() Disable station, as for tilt.
enable() Enable station; called by game after tilt is cleared.
getState() Return station state
offline() Take station offline, possibly temporary
shutdown() Shutdown station and all devices associated with it, at game exit.
Class powerpit.iiob.IIOBBase 666 extends Object. It is a main Java interface
for
access to the physical IIOB or IIOB simulator software, in test. poll() method
scans the
IIOB for new data or state changes and informs the other devices; translates
and
synchronizes access to the IIOB. Subclassed by IIOB (for physical i/o) or
IIOBSimulator
(for test exercise of code modules). The class includes:
commitWrite() Commit write buffer to iiob.
26
CA 02319600 2000-09-14
configure() Send configuration command to iiob; should return 0.
getState() Retrieve iiob state: 0 = iiob is not responding.
poll() scan i/o board for new inputs; deliver writes for current cycle of game
loop
readCoinOut() return the accurate coin-out value
readLine(boolean, int) Read the integer value of a line for input or output.
readPort(int) read current data from serial port
readStatus() Return the iiob status (0=okay; 1=really bad).
readTrackball() Return trackball deltas in byte[2] array.
registerCoinValidator(IiobDeviceInterface, int, int, int, int, int, int)
Register
cc40/cc46 coin validator
registerHopper(int, int, IiobDeviceInterface)
register hopper lines for motor and sensor
registerLED(byte) Register LED for configuration (write-only).
registerLine(IOLineConfiguration, boolean, int) Register an input or output
line
for call-back, via IiobDevice::getData()
registerPort(PortConfiguration, int) Register a serial port for use.
registerTrackball(byte, IiobDeviceInterface) Register trackball by providing
update interval in 10 ms units, and owner for notification.
reset() Hardware reset for iiob; should return s iWasReset.
resetHopper() reset hopper error values
resetPort(int) reset port data after error
signature() iiob signature routine - just a shell here; implemented only in
IIOB
start() Send start command to iiob; should return 0.
statusHasChanged() allow hopper to check status byte change bit
stop() Send shutdown command to iiob; should return 0.
writeCoinOut(int) write coins to dispense
writeLED(int, byte[], byte[J) Send data to seven-segment display.
writeLine(int, int) Write a value to an output line.
writePort(Port, int) Write data packet to a serial port (e.g.: bill validator
or printer)
Class powerpit.devices.PlayerStation 669 is a public class. PlayerStation
extends
Station implements PlayerInterfac. PlayerStation implements the methods for
communication with a game and dependent devices for a single-player game such
as a
video slot. The class includes:
allowValidators() allow coin and bill acceptance
attendantKey() is the attendant key on?
attendantLit() is the service lamp lit?
blinkButtons(int[]) blink player buttons of the specified types
blinkButtonsEQvalue(int, int) blink player buttons of the specified type only
if
they are equal to the specified value (e.g. blink only the bet 5 button
instead of all bet buttons)
clearHistory() reset history log only
dimButtons(int[J) Dim player buttons of the specified types
disable() Disable player station, as for alarm.
disableCashout() explicitly lock out the cashout button
displayLog(int) display a log of the specified type as ASCII text
27
CA 02319600 2000-09-14
enable() Enable player station; called by game after meter audit.
enableCashout() enable normal cashout function
getBet() Return value of bet meter.
getCashIn() interface for total cash in from all sources (audit check)
getCashOut() interface for total cash out from all sources (audit check)
getCoinIn() interface for coin-in meter (audit check)
getCoinOut() interface for coin-out meter (audit check)
getCredit() Returns value of credit meter.
getIndex() Return player index
getPaid() Returns value of paid meter.
handpay() clear handpay-required tilt
increaseBet(long) Increment bet meter; debit credit meter.
inhibitValidators() game loop interface to inhibit credit acceptance
lightButtons(int[]) Light player buttons of the specified types
lightButtonsEQvalue(int, int) light player buttons only if they are equal to
the
specified value and type; if they are the specified type but not the right
value, then turn them off.
lightButtonsLEvalue(int, int) light player buttons only if they are less than
or
equal to the specified value
offline() Take player station offline.
playMessage(PlayMessage) Process play message from game; causes game, bet
win meters to increment; logs game outcomes.
poll() poll the devices associated with this station
processMessage(Message) process messages for this station
resetLogsQ reset any logs that need it
shutdown() Shut player station down at game exit.
shutdownOnline() shut down the online system in case of severe error
undoBet(long) Subtracts amount from bet meter; adds credits to credit meter.
Class powerpit.devices.DealerStation 670 is a public class. DealerStation
extends
Station implements NetworkInterface. is provides a dealer station for game
server in
multiplayer games. The class includes:
connect(Connection) add connection for remote player
disable() Disable station, as for alarm.
disconnect(Connection) remove connection for remote player
enable() Called from GameApplet: atart() or BaseGame: atart() in
powerpit.mains.
poll() poll the devices associated with this station
processMessage(Message) process messages for this station
shutdown() shut down dealer and all connected player stations at game exit
Class powerpit.devices.PlayerStub 671 is a public class. PlayerStub extends
Obj ect
implements PlayerInterface PlayerStub. It is used by the game server for
multiplayer
28
CA 02319600 2000-09-14
games. It stores the data locally for a remote player station. The class
includes:
disable() Disable player station, as for alarm.
enable() Enable player station; called by dealer when connected.
getBet() Return value of bet meter.
getCredit() Returns value of credit meter.
getIndex() Return player index
getPaid() Returns value of paid meter.
getState() Return player state
increaseBet(long) Increment bet meter.
offline() Take player station offline.
playMessage(PlayMessage) Process play message from game.
shutdown() Shut player station down at game exit.
Interface powerpit.devices.PlayerInterface 672 is a public interface.
PlayerInterface extends Statelnterface. PlayerInterface defines the methods
for
communication between players and a game. Implemented by PlayerStation,
NetworkPlayerStation and PlayerStub getBet() Return value of bet meter. The
class
includes:
getCredit() Returns value of credit meter.
getIndex() Return player index
getPaid() Returns value of paid meter.
increaseBet(long) Increment bet meter.
Class powerpit.jni.ServerSocket 673 is a public class. ServerSocket extends
Socket and implement Berkeley sockets interface with non-blocking sockets. The
class
includes:
accept() accept new connection; used by DealerStation on game server.
Class powerpit.jni.ClientSocket 674 is a public class. ClientSocket extends
Socket
Implement Berkeley sockets interface with non-blocking sockets. It does NOT
transmit
raw data, only subclasses of Message. Used by Connection, ServerSocket; used
indirectly
by DealerStation and NetworkPlayerStation. The class includes:
recvQ return Message to caller.
send(byte[], int) write Message to network.
Class powerpit.devices.ButtonPanel 675 is a public abstract class. ButtonPanel
extends Object. It describes the player button panel for a game. Similar to
SwitchHarnee,
Candelabra and MeterModel, it is subclassed for the machine type. E.g:
NVSMButtonPanel describes the buttons for a video slot, while NVBJPButtonPanel
29
CA 02319600 2000-09-14
describes the buttons available for a player station in mufti-player
blackjack. The class
includes:
addBetButton(int, int, long) used by constructor of subclass to add a bet
button
addButton(int, int, int) add a button; should only be used by the constructor.
addPaylineButton(int, int, long) used by constructor of subclass to add a
playline
selection button
blinkButtons(int[]) blink (and enable) all buttons of the specified types
blinkButtonsEQvalue(int, int) blink (and enable) all buttons of the specified
type
only if their value is equal to the specified value.
dimButtons(int[]) dim (disable) all buttons of the specified types
disable() disable all buttons for alarm; attendant, cashout and show are never
disabled
enable() re-enable buttons after alarm
isLit(int) get state of all buttons of a particular type; currently, this is
most useful
for the attendant button.
lightButtons(int[]) light (enable) all buttons of the specified types
lightButtonsEQvalue(int, int) light (and enable) all buttons of the specified
type
only if their value is equal to the specified value.
lightButtonsLEvalue(int, int) light (and enable) all buttons of the specified
type
only if their value is less than or equal to the specified value.
register(IIOBBase) register all the buttons with iiob
Class powerpit.online.OnlineSystem 676 is a public class. OnlineSystem extends
Object. This class contains the Java part of the common online accounting
system
methods. These methods call the C part of the common interface which in turn
communicate with the protocol translator, which runs asynchronously as a
separate
process. This enables all game software to use a common interface to a family
of protocol
translators which need not be resident on the machine's main motherboard at
all. NOTE:
the term "slave" is used to indicate the protocol translation task itself.
check() Native method to check to see if the slave task is still running.
doStart() check that slave is running; stores pid of "slave" if everything's
okay;
throws exception otherwise.
nativepollRx(byte[]) Native method used to check the message queue to see if
the
slave task has sent a message to the game.
poll() process incoming messages.
pollRx() This method is used to poll the "slave" for any action or data that
it may
be sending to the game.
qDenom(int, byte) This method calls the native method qTx to put an event that
requires a denomination code into the queue for the slave.
qEvent(int) This method calls the native method qTx to put an event (with no
data) into the queue for the slave.
qHandpayWin(long, long, byte) This method calls the native method qTx to put a
"handpay won" or "handpay collected" event into the queue for the slave.
CA 02319600 2000-09-14
qID(byte[]) This method calls the native method qTx to put a "set machine id"
event into the queue for the slave.
qMeter(int, long) This method calls the native method qTx to put an event that
requires an amount for a meter value into the queue for the slave.
S qOptions(short) This method calls the native method qTx to put a "set
options"
event into the queue for the slave.
qPayBackPercent(String) This method calls the native method qTx to put a "set
payback percent" event into the queue for the slave.
qProgressiveGroup(byte) This method calls the native method qTx to put a "set
progressive group" event into the queue for the slave.
qProgressiveMeter(byte, long) This method calls the native method qTx to put a
"adjust progressive meter" event into the queue for the slave.
qReadMeter(char, int) This method calls the native method qTx to put a "read
meter" event into the queue for the slave.
qReelID(byte[]) This method calls the native method qTx to put a "set reel
strip
id" event into the queue for the slave.
qTx(int, byte[]) Native method that actually put a message from the game to
the
slave into the named pipe.
quit() Native method to shut down the slave task.
qWriteMeter(char, int, long) This method calls the native method qTx to put a
"write meter" event into the queue for the slave.
resume() Native method used to try to resume a slave task that has been
suspended.
shutdown() tell slave to clean up and exit
sizepollRx() Native method which simply returns the size of the message buffer
needed by the nativepollRx method.
start(Meter[], String, String, String, int, int) This method checks that the
slave has
started; sends alarm to owner if something's wrong.
suspend() Native method used to send a message to the slave task requesting it
to
suspend itself.
translate(Message) This subroutine is supposed to be called by
PlayerStation.processMessage() to translate messages that the player
station gets into stuff that the online accounting system understands.
trigger() Call this native method after you have queued all desired events (or
commands) to the slave task. Wakes up slave to process a group of data
messages atomically.
Class powerpit.devices.NetworkPlayerStation 677 is a public class in which
NetworkPlayerStation extends PlayerStation. The class implements
NetworkInterface
NetworkPlayerStation implements the methods for communication with a remote
game
server, in addition to basic player functionality. The class includes:
connect(Connection) connect to game server
disable() Disable player station, as for alarm.
disconnect(Connection)
enable() Enable player station; called by game after meter audit.
offline() Take player station offline.
31
CA 02319600 2000-09-14
poll() poll for inputs and process output to devices
processMessage(Message) process messages from devices, game server or local
game loop
sendDelta(int, long) send meter deltas to the dealer
shutdown() Shut player station down at game exit.
Class powerpit.devices.Connection 678 is a public class. Connection extends
Device Service player station connection. Same class is used by client and
server.
Messages are sent using the send() method. Messages are received by the poll()
method.
If no messages are received for 15 seconds the connection will be dropped. The
class
includes:
getPlayerIndex() Retrieve index of player.
nextMessage() Receive network message.
poll() poll is called each time through the game loop to scan for input
send(Message) Send network message.
shutdown() terminate network connection
Class powerpit.devices.Device 680 is a public abstract class Device extends
Object implements GameInterface which is an abstract base class for all
devices. Devices
are strictly event driven, using the poll() method invoked by the game loop;
there is no
monitoring Thread in any device.
getParameter(String) Get parameters from the configuration file.
getType() Return device subtype; -1 indicates that no subtypes are defined.
processMessage(Message) The method that gets called to distribute messages.
Fig 6d illustrates the relationships between the Java classes associated with
a
Device Layer Context. The Device Layer Context comprises a Device 690 that
interacts
with GameInterface 691, IiobDevice 692, and Meter 694. LiobDevice 692
interacts with
class liobDeviceInterface 693 which in turn interacts with HardMeter 695.
HardMeter
695 interacts with classes CoinOutMeter 697 and Meter 694. CoinOutMeter 697
interacts
with classes Hopper 698 and MessageInterface 697, which also interacts with
Hopper
698. Hopper 698 also interacts with class liobDevice 699. ButtonPanel 6011
interacts
with class PlayerButton 6012. Candleabra 6021 interacts with class Candle
6022.
SwitchHarness 6031 interacts with class Switch 6032. MeterModel 6041 interacts
with
class Meter 6042. LiobDevice 6001 ineracts with classes PlayerButton 6008,
Candle
6007, Switch 6006, Printer 6005, LED 6004, Trackball 6003, and CreditDevice
6002.
CreditDevice 6002 interacts with classes CoinValidator 6010 and BillValidator
6009.
32
CA 02319600 2000-09-14
Class powerpit.devices.Meter 694 is a public class. Meter extends Device Base
class for all meters. Implements functions for soft meter. All defined types
are included
in the MeterModel for all juridisctions. The class includes:
decrement(long) Decrement by specfied amount.
getUnrolled() Return unrolled value of meter - always 0 unless it's a hard
meter
getValue() Return value of meter.
increment(long) Increment by specified amount.
reset(long) Basic reset method.
typeString(int) translator for known meter types - integer values are defined
for all
meter types required in Nevada and GLI U.S. juridictions, including door
types and individual bill denominations from 1 to 1 million.
Class powerpit.devices.HardMeter 695 is a public class. HaxdMeter extends
Meter
implements IiobDeviceInterface and is derived from base class Meter. It
encapsulates
player station elector-mechanical meter. Note presence of attribute lUnrolled;
the amount
not yet sent to the physical meter. Note that all the functionality from
IiobDevice must be
implemented here, since HardMeter is not a subclass of IiobDevice decrement
(long)
Overndes base class. The class incudes:
disable() Disable the meter - stops sending pulses to the iiob.
enable() Invoked by the IIOB when data transfer is ok.
getData() Retrieve changed data for this meter (meter has rolled 1 count)
increment(long) Overndes base class - causes meter to start rolling if
enabled.
register(IIOBBase) Cause the hard meter to register with the IIOB.
reset(long) Overndes base class - resets unrolled amount to 0.
Class powerpit.devices.CoinOutMeter 697 is a public class. CoinOutMeter
extends HardMeter implements MessageInterface and is derived from base class
HardMeter. It encapsulates physical coin-out meter relationship with hopper.
The class
includes:
cashing() let meter model return cashing flag based on hopper and meter
disable() Disable the meter
enable() Invoked by the IIOB when data transfer is ok.
increment(long) Overrides base class; send coin-out to hopper
processMessage(Message) The method that gets called to distribute messages.
register(IIOBBase) Cause the hard meter to register with the IIOB.
resetTilts() reset hopper tilt flags so messages will be sent once more for
hopper-
related tilts
rollCoinOut() hopper calls this routine to roll meter
33
CA 02319600 2000-09-14
Class powerpit.devices.Hopper 698 is a public class. Hopper extends IiobDevice
Hopper Device controlled by coin-out meter to physically dispense coins. The
class
includes:
coinOut(int) called by coin-out meter to indicate number of coins to dispense
disable() Invoked by IIOB when data transfer is not ok, or by coin-out meter
enable() Invoked by the IIOB when data transfer is ok, or by coin-out meter.
getData() Retrieve changed coin-out data for hopper
processMessage(Message) The method that gets called to interpret iiob hopper
status.
register(IIOBBase) Cause the hard meter to register with the IIOB. - called by
coin-out meter.
resetTilts() allow tilt message to generate.
throttle(AlarmMessage) inhibit duplicate tilt messages until resetTilts() is
called.
Class powerpit.devices.CreditDevice 6002 is a public abstract class.
CreditDevice
extends IiobDevice and is an abstract base class for monetary input devices.
It is derived
from base class IiobDevice; encapsulates player station credit device; e.g.:
eft, coin
acceptor or bill acceptor. Note that BillValidator, CoinValidator and their
subclasses
implement the allow/inhibit interfaces to preserve state through iiob resets
so a vlidator
that was off because a limit was reached does not come on, or vice versa.The
class
includes:
allow() player station calls this to allow acceptance of credit inputs by this
device
inhibit() player station calls this to inhibit acceptance
resetInCount() player station calls this at cashout or handle-pull to reset
amount in
since last game or cashout.
Class powerpit.devices.Trackball 6003 is a public class. Trackball extends
IiobDevice. Trackball device. Note that other pointing devices would be
similar, but
might not be subclasses of IiobDevice, since touchscreens or mice could be
handled by
the mouse port on the motherboard. The class includes:
getData() Retrieve changed data for this device
register(IIOBBase) Cause the trackball to register with the IIOB.
Class powerpit.devices.LED 6004 is a public class. LED extends IiobDevice and
controls the output to seven-segment display with 8 characters. The class
includes:
getData() empty method to satisfy abstraction in IiobDevice.
register(IIOBBase) Cause the LED to register with the IIOB.
34
CA 02319600 2000-09-14
Class powerpit.devices.Printer 6005 is a public class. Printer extends
IiobDevice
Printer device. It is controlled by player station. Note: this is the
interface for a serial
printer connected via the i/o board. A parallel printer connected to the
motherboard
would be functionally equivalent, but would act through the parallel port
driver rather
than the iiob interfaces. The class includes:
getData() Retrieve changed data for this device; e.g. ack, device not ready,
etc.
print(String) Print something
register(IIOBBase) Cause the printer to register with the IIOB.
Class powerpit.devices.Switch 6006 is a public class. Switch extends
IiobDevice
and monitors a single security switch to send alarm for state change. There
are many of
these, organized within a SwitchHarness. Note: all switches are iiob inputs;
they cannot
be turned on and off by the station. The class includes:
alarmOff() return value of alarm off
alarmOn() return value of alarm on
enable() Invoked by the IIOB when data transfer is ok.
getData() Retrieve changed data for this switch
isOn() Returns value of flOn.
isReversed() return true if switch is "reversed" polarity; i.e. if switch is
active
high.
register(IIOBBase) Cause the switch to register with the IIOB.
Class powerpit.devices.Candle 6007 is a public class. Candle extends
IiobDevice.
A single candle on a station; may have 2, 3 or more of these, contained by a
subclass of
Candelabra. The class includes:
blink() blink the candle
getData() Retrieve changed data for this device - required in case of reset
isBlinking() is it blinking?
isOn() is it on steady?
off() turn candle off
on() turn candle on steady
register(IIOBBase) register candle line with iiob
Class powerpit.devices.PlayerButton 6008 is a public class. PlayerButton
extends
IiobDevice and is a single layer button attached to iiob. There are many of
these,
contained in a subclass of ButtonPanel. The class includes:
blinkButton() Blink (and enable) this button
dimButton() Dim (disable) this button
getDataQ Retrieve changed data for this device
getValue() Return fixed numerical value of (bet or playline) button.
CA 02319600 2000-09-14
isLit() Return true if button is lit (or blinking), false if dim.
lightButton() Light (enable) this button
register(IIOBBase) Cause the hard meter to register with the IIOB.
sendMessage() Send message - used by multiplayer games for attendant button
typeString() This instance method returns a string containing a button's type
as
well as its value (for bet and payline buttons).
typeString(int) This static method returns a string describing what a button
type is.
Class powerpit.devices.BillValidator 6009 is a public abstract class.
BillValidator
extends CreditDevice implements MessageInterface which is a serial bill
validator
abstract base class. It uses serial.c in .../libLinux . The class includes:
allow() allow acceptance, if enabled.
disable() Invoked by IIOB when data transfer is not ok; should be called by
subclass after device-specific messages.
1 S enable() Invoked by the IIOB when data transfer is ok.
inhibit() inhibit acceptance without disabling.
init() handle initialization sequence
poll() troll for responses; check timeouts.
processMessage(Message) The method that gets called to distribute messages.
register(IIOBBase) Cause the bill validator to register with the IIOB.
resetInCount() reset bill count after handle-pull or cashout
sendAlarm(int) send tilt; specific to derived type.
Class powerpit.devices.CoinValidator 6010 is a public abstract class.
CoinValidator extends CreditDevice CC-40 coin validator. Notify coin-in meter
via
CreditMessage to station. Note: there are numerout subclasses implemented
depending
on diverter and hopper types. The class includes:
allow() same as enable for cc-40 and cc-46
disable() invoked by IIOB when data transfer is not ok.
enable() invoked by the IIOB when data transfer is ok.
getData() check coin-validator on tilt or coin-in
inhibit() same as disable for cc-40 and cc-46
poll() poll for severe errors even when disabled
register(IIOBBase) Cause the device to register with the IIOB.
resetInCount() reset coin-in count after cashout or handle-pull
setoff() turn validator off and clear flag
setOn() turn validator on and set flag
Below are all the parameters understood by the basic game software. Most games
would require various additional parameters for control of game-specific
features such as
sound, video or special device options.
36
CA 02319600 2000-09-14
The name of applet to run for game (required for graphical display)
GAME APPLET powerpit.docs.SlotMachine.
The dimensions for applet display (required for graphical display)
WIDTH = 640 and HEIGHT = 480.
The game denomination: cents per credit (required) is DENOMINATION
= 100.
The station type (required) is STATION powerpit.devices.PlayerStation,
STATION CLASSES powerpit.mains.BaseGameInterface, and
STATION VALUES owner.
The image to display in background (required for graphical display) is
PLAYER BACKGROUND blackjack/images/Bjdback.gif.
The pure Java random number generator to use (required for dealer or
single player) GENERATOR powerpit.chance.JKnuthV2Random. LSR with
saved seed (seed is not actually saved without PROMDisk installed)
GENERATOR powerpit.chance.KnuthWithRNG. GENERATOR CLASSES
java.lang.Integer GENERATOR VALUES =200.
The candles (optional) is CANDLE powerpit.docs.NVSMCandles,
CANDLE CLASSES powerpit.devices.PlayerStation, CANDLE VALUES
owner.
The online system (comment this out to test bill validator on PC)
(optional) is ONLINE powerpit.online.OnlineSystem, ONLINE-CLASSES
powerpit.devices.PlayerStation, ONLINE VALUES owner, COMPANY "IGCA
", PAYBACK 96.84, and GAME ID "NVSSF ".
The I/O board (required) is IIOB powerpit.iiob.IIOBSimulator, IIOB
powerpit.devices.IIOBDummy, IIOB powerpit.iiob.IIOB, IIOB CLASSES
powerpit.devices.Station, and IIOB VALUES owner.
The meters (required) is METER MODEL
powerpit.docs.NVSMMeterModel having METER MODEL CLASSES
powerpit.devices.Station, and METER MODEL VALUES owner.
The Logs: optional, but only one of each type and are disk-based meter log
for recovery: METER LOG powerpit.mains.audit.JMeterLog,
37
CA 02319600 2000-09-14
METER LOG CLASSES java.lang.String, and METER LOG VALUES
/tmp/test dmeter log.
The disk-based event log for alarms are EVENT LOG
powerpit.mains.audit.JEventLog EVENT LOG CLASSES java.lang.String
java.lang.Integer, and EVENT LOG VALUES /tmp/test devent log 100.
The disk-based state log for recovery is STATE LOG
powerpit.mains.audit.JStateLog, STATE LOG CLASSES java.lang.String, and
STATE LOG VALUES /tmp/test state log.
The disk-based history log for play steps is PLAY LOG
powerpit.mains.audit.JPlayLog, PLAY LOG CLASSES java.lang.String, and
PLAY LOG VALUES /tmp/test~lay_log.
The NVRAM meter log for recovery (optional) is METER LOG
powerpit.mains.nvram.MeterLog, METER LOG CLASSES java.lang.Integer,
and METER LOG VALUES = 5.
The NVRAM event log for alarms (optional) is EVENT LOG
powerpit.mains.nvram.EventLog, EVENT LOG CLASSES java.lang.Integer
java.lang.Integer, EVENT LOG VALUES = 5 100. The NVRAM state log for
recovery (optional) is STATE LOG powerpit.mains.nvram.StateLog
STATE LOG CLASSES powerpit.mains.BaseGameInterface java.lang.Integer,
and STATE LOG VALUES owner = 5.
The NVRAM history log for play steps (optional) is PLAY LOG
powetpit.mains.nvram.PlayLog PLAY LOG CLASSES java.lang.Integer
java.lang.Integer, and PLAY LOG VALUES = 5 25.
The switches (optional) is SWITCH HARNESS
powerpit.docs.NVSMSwitchHarness, SWITCH HARNESS CLASSES
powerpit.devices.Station, and SWITCH HARNESS VALUES = owner.
The is button panel (optional) BUTTONS
powerpit.docs.NVSMButtonPanel, BUTTONS CLASSES
powerpit.devices.PlayerStation java.lang.Boolean, and BUTTONS VALUES
owner true.
The bill validator (optional) is BILL VALIDATOR
powerpit.devices.CBWalidator, BILL VALIDATOR
38
CA 02319600 2000-09-14
powerpit.devices.JCMValidator, and BILL VALIDATOR CLASSES
powerpit.devices.PlayerStation java.lang.Integer.
The bill validator uses serial port 0 on the iiob is
BILL VALIDATOR VALUES owner 0.
The test values for direct PC serial port hookup with the bill validator is
BILL VALIDATOR CLASSES powerpit.devices.PlayerStation java.lang.String,
and BILL VALIDATOR VALUES owner "/dev/cua0".
The coin validator (optional)is COIN VALIDATOR
powerpit.devices.BJCoinValidator, COIN VALIDATOR
powerpit.devices.ColeCoinValidator, and COIN VALIDATOR CLASSES
powerpit.devices.PlayerStation.
The ColeCoinValidator with 1 diverter is java.lang.Integer
java.lang.Integer java.lang.Integer, BJCoinValidator with 2 diverters
j ava.lang.Integer j ava.lang.Integer j ava.lang.Integer, j ava.lang.Integer
java.lang.Integer, BJCoinValidator with 2 diverters, coin-in, tilt, drop gate,
hopper
gate, hopper full, power, COIN VALIDATOR VALUES owner = 5 24 0 6 9 4,
ColeCoinValidator with 1 diverter, coin-in, tilt, drop gate, hopper full,
power, and
COIN VALIDATOR VALUES owner = 5 24 6 9 4.
The hopper (optional) is HOPPER powerpit.devices.Hopper,
HOPPER CLASSES powerpit.devices.CoinOutMeter, java.lang.Integer and
j ava.lang.Integer.
The motor line, sensor line is HOPPER VALUES owner = 7 8.
The printer (optional) is PRINTER powerpit.devices.Printer,
PRINTER CLASSES powerpit.devices.PlayerStation java.lang.Integer, 1 is
assigned serial port on I/O board, PRINTER VALUES owner = 1.
Optional parameters for which defaults are supplied tilt when player wins
this many dollars in credits (clear with key), defaults to 10000, and
JACKPOT LIMIT =1000.
Turn off coin validator when this many dollars are accepted between
games and defaults to unlimited, COIN LIMIT = 1500; turn off bill validator
when this many dollars are accepted between games and defaults to unlimited,
BILL LIMIT = 1500; turn off eft transfers in when this many dollars are
accepted
39
CA 02319600 2000-09-14
between games and defaults to unlimited, EFT LIMIT = 3000; hopper limit (in
dollars) and defaults to 1200 (clear with key), HANDPAY =1200; minimum bet
(in credits) and defaults to 1, MIN BET = 1; maximum bet (in credits), may not
exceed 100 times minimum, MAX BET =100; stop accepting credits (in dollars),
defaults to 3000, VALIDATORS_OFF = 3000; game controls when the error
candle goes off - any value for this parameter allows game-control of the
error
candle, MANUAL_CANDLE = true; unreasonable win amount strictly greater
than any possible jackpot (credits) defaults to 999,999,999, WIN LIMIT =
1000000; short-circuit version test (optional for test of RNG without NVRAM
only) (any (non-blank) value at all), NO VERSION = true; tournament mode;
implies NO VERSION (any (non-blank) value at all), TOURNAMENT = true;
tournament round in minutes - can be reset manually and defaults to 15,
TOURNAMENT MINUTES =15; and tournament credits per round - can be
reset manually and defaults to 1000, TOURNAMENT CREDITS =1000.
A set of game-specific parameters are discussed below. For mufti-player games,
the only additional parameters required are for the dealer station. In most
cases however,
the dealer would not require any devices other than meters, the I/O board and
possibly
candles.
Fig. 7 illustrates the additional classes and relationships for mufti-player
games.
Fig. 7 also illustrates the relationships between the Java classes associated
with Multi-
Player Classes. The Mufti-Player classes comprise a DealerGame 701 that
interacts with
classes JRandom 702, PlayerStub 703 and DealerStation 704. DealerStation 704
interacts
with classes P-layerStub 703, Connection 711, and ServerSocket 710, which in
turn
interacts with classes Connection 711 and ClientSocket 712. Connection 711
also
interacts with class ClientSocket 712 as well as ClientSocket 723 and
NetworkPlayerStation 720. NetworkPlayerStation 720 itself interacts with
ClientSocket
723 OnlineSystem 722, and PlayerGame 721.
Dealer Game701 is an abstraction to indicate the portion of a mufti-player
game
which contains a game loop based on either BaseGame (610) or GameApplet (640)
and
references a DealerStation (670) with PlayerStubs (671).
CA 02319600 2000-09-14
Player Game 721 is an abstraction to indicate a single, remote player in a
multiplayer game.
Parameters listed below that differ from the list above that are required for
any
dealer.
The station type (required) STATION powerpit.devices.DealerStation,
STATION CLASSES powerpit.mains.BaseGameInterface, and
STATION VALUES owner.
The player stations to load (required for dealer) uses PLAYERS = 5.
The dealer image to display in background (required for graphical display)
DEALER BACKGROUND blackjack/imageslBjdback.gif.
The only change in configuration for a remote player in a multi-player game is
the
station type. A remote player would have all the devices a single player is
likely
to have.
The station type (required) is STATION
powerpit.devices.NetworkPlayerStation, STATION CLASSES
powerpit.mains.BaseGameInterface, and STATION VALUES owner.
Each station is responsible for starting attached peripheral devices in the
correct
sequence both at startup and when re-enabled after an alarm condition (tilt)
is cleared.
This is handled by low-level software that is not game-specific. In addition,
a dealer
station starts the server network connection, when the game loop becomes
active. A
remote player station attempts to connect to the remote server and loads, but
does not start
its attached devices until the network connection is made.
The online accounting system may be of any industry supported type of online
system; e.g.: SDS, SAS, CDS, Daycom, etc. The online system is started when a
station
is first enabled and remains active until shutdown in order to report alarms.
The OAS
runs as a seperate process at a high priority, so it can respond to host
messages in real-
time. The I/O board is configured as the supported peripheral software is
loaded. It is
started only when all other items are loaded and in the case of a player in a
mufti-player
game, only after the player is connected on the network. The I/O board remains
active
during alarm conditions, except at shutdown or when the alarm is caused by a
failure of
41
CA 02319600 2000-09-14
the I/O board. If the I/O board fails to respond correctly to regular system
polls at any
time, a reset operation is performed and an alarm declared. If the I/O board
fails to
respond to the reset, the alarm may only be cleared by re-booting; such a
failure most
likely indicates a hardware defect. The technical details of the I/O board
design and
related functionality may be found within co-pending U.S. Patent Application
entitled
SYSTEM AND METHOD FOR PROVIDING A REAL-TIME PROGRAMMABLE
INTERFACE TO A GENERAL-PURPOSE NON-REAL-TIME COMPUTING
SYSTEM, Serial No. 09/395,647 which is concurrently filed with the patent
application
and incorporated by reference herein in its entirety.
The primary duty common to all game loops is to continually call a poll()
routine,
implemented in both BaseGame and GameApplet base classes, which polls the
station
software for device messages including alarms and in the case of a mufti-
player game for
network messages from the remote partners. Whenever poll() is called, it
should be
followed by a call to nextMessage(), which retrieves the polled data in a
standard system
message packet, derived from powerpit.messages.Message.
In the case of an audit check event, the meters must be cleared by entering
audit
mode, and opening the logic cage; this causes a RAM_CLEAR event to be logged.
An
audit check event occurs whenever credit is not equal to the sum of cash-in
plus
cumulative win minus cash-out, minus cumulative bet, minus current bet.
Current bet is
added to cumulative bet at the end of each game; the audit check is performed
at the
beginning of the game and each time a bet is placed.
RAM corruption or any change in the configuration causes a RAM/Version check
event to occur. In the case of a single player game (e.g.: Storybook Fantasy),
or player
station for a mufti-player game (e.g.: BJ Blitz Blackjack) the event is
cleared as with the
audit check event above. For the dealer station in a mufti-player game, the
alarm is
cleared by opening the logic door.
An audit-check tilt may only be cleared by turning the attendant key to its
"on"
position and opening the logic door to clear the meters; a ram-clear event is
logged at this
time. On mufti-player dealer stations, the attendant key is not required;
opening the logic
cage clears RAM and restores game function.
42
CA 02319600 2000-09-14
A hopper, bill validator or IO board tilt of any kind stops the game as with
an
open door. These tilts may only be cleared by opening at least one door and
then closing
all doors.
Any door open results in a tilt as well as hand-pay-required or a failed audit
check.
In mufti-player games, a dealer tilt will disable all player stations as well.
A power-down
alarm results in the shutdown of the station that declared it. In mufti-player
games, a
dealer power-down will result in a shutdown by the player stations as well.
On graphical player stations, if no hand-pay alarm is in force, turning the
attendant
key to the "on" position causes the station to be disabled as for an alarm.
Pressing the
cashout key cycles from one data set to the next; pressing the attendant key
pages through
the current data. Opening the logic door clears the current log and in the
case of clearing
the meters enters a "Ram cleared" alarm in the event log. Clearing the meters
in audit
mode is the only way for game play to proceedafter an audit check alarm is
raised. Data
is displayed or cleared by powerpit.mains.audit.Audit; an instance of this
class is owned
by the game applet on player stations (only). Audit is invoked by
GameApplet::audit().
RAM based meters are updated immediately as credits are transferred, and the
resulting values are logged. Electromechanical meters are updated
asynchronously, until
all deltas have been added; the "unrolled" amount is logged each time the
meter is
incremented for power-fail recovery.
In the case of game-play, credits are transferred to an interim bet meter
rather than
directly to the cumulative bet (Nevada coin-in) meter. At the end of the game
cycle, these
credits are returned to the credit meter in the event of a tilt, or then added
to the
cumulative bet meter. At this time, credits paid by the game are also added to
the
cumulative won meter.
Specific message classes are provided for:
1. Remote player connection; initializes credit and bet values on the dealer
station
and marks the player as enabled.
2. Play step messages; these are sent from the game to the player for logging
and
in the case of mufti-player games, to control the game loop on the remote
station.
43
CA 02319600 2000-09-14
3. Meter messages; these generally contain full meter values for logging or
synchronization of remote values in multi-player games. In multi-player games,
deltas
are also sent by players to the dealer to update cumulative dealer meters.
4. Credit messages are sent by credit devices such as coin validators, bill
validators or eft systems to the player station software. They contain fields
indicating
source of the credits, denomination in the case of bills, and whether the
credits should be
added to the drop meter or not.
5. Button messages are sent to the player station by the button devices; in
single-
player games, they are made available to the local game loop; in multi-player
games they
are sent to the dealer to relay to the remote game server.
6. Alarm messages are sent only to the local game loop. Based on the outcome,
at
the game level, enable or disable commands may be sent by the player to the
dealer
(which only affect the status in that player's database), or by the dealer to
the player.
Alarms for hand-pays and cash-outs contain the amount of credits involved and
the basic
alarm identifier.
7. Trackball messages are sent (via the player station software) to the local
game
loop to affect the position of a pointer.
8. Command messages are sent to enable or disable players or shut down the
system in an orderly fashion when an error occurs.
9. An ACK message type is provided to indicate completion of some lengthy
action (e.g.: animation) by a remote player in multi-player games.
10. A Keep-alive message type is provided to verify communication links
between the dealer and remote players in mufti-player games.
All messages are subclasses of powerpit.messages.Message. They include
certain required methods (functions, subroutines, whatever):
public static final byte[] getClassName (byte[] data)
This method is used to recover the class name of a message in packed binary
form, for reconstruction by the methods of Class, Object and the classes in
package
java.lang.reflect.
.../powerpit/devices/Connection.java in the source tree has a good example of
this in its
nextMessage() method.
44
CA 02319600 2000-09-14
Public byte[) pack () - This method stores the data from the message in a
packed
binary format suitable for network transmission or logging.
.../powerpit/devices/Connection.java in the source tree has a good example of
this in its
nextMessage() method.
Public int unpack (byte[] data)- This method decodes the packed data returned
from a log or network transmission. .../powerpit/devices/Connection.java in
the source
tree has a good example of this in its send() method.
Public static final String date (long ldate) - This method returns a string of
the
form mm/dd/yy hh:mmas from the long integer stored in each message.
Public String[] display () - This method is required to display the data
stored by
the message; used by audit - particularly important and tedious to implement
in the play
step messages.
Fig. 8 illustrates the relationships among the various classes employed in
messaging. The Message Classes comprise a Message 801 that interacts with
classes
CommandMessage 802, AlarmMessage 803, PlayMessage 804 (which in turn interacts
with classes InitialStep 816, IntermediateStep 815, and FinalStep 814),
CreditMessage
805, MeterMessage 806, ConnectMessage 807, TrackBallMessage 808, ButtonMessage
809, KeepAlive 810, Ack 811, and RandomDraw 813. PlayMessage 804 interacts
with
classes InitialStep 816, IntermediateStep 815, and FinalStep 814. AlarmMessage
803
interacts with class AlarmWithValue 812.
Class powerpit.messages.PlayMessage 804 is a public abstract class PlayMessage
extends Message and is sent by the game to the player for logging. It is used
by remote
player station game loop for changing state, redrawing screen, playing sounds,
etc.
Class powerpit.messages.CreditMessage 805 is a public class. CreditMessage
extends Message and is sent by bill-validator, coin validator or online system
to add
credit.
Class powerpit.messages.MeterMessage is a public class. MeterMessage extends
Message Sent by the game to the player for meter updates during the betting
phase, or to
reflect cancelled play. Sent by a remote player to update the credit values
for the game
when credit is added or subtracted by coin-in, bill-in, online system or
cashout. It is used
by meter logging to store meter values for recovery.
CA 02319600 2000-09-14
Class powerpit.messages.ConnectMessage 807 is a public class ConnectMessage
extends Message . It is sent by remote player to update game meters and notify
dealer of
new connection.
Class powerpit.messages.TrackballMessage 808 is a public class.
TrackballMessage extends Message to notify game of new trackball position.
Class powerpit.messages.ButtonMessage 809 is a public class. ButtonMessage
extends Message and is sent by player to indicate a press of a button on the
player button
panel.
Class powerpit.messages.KeepAlive 810 is a public class. KeepAlive extends
Message and is a network watchdog message - no content; just keeps connection
active.
Class powerpit.messages.Ack 811 is a public class. Ack extends Message and is
sent by a remote player to let the dealer know when a lengthy process is done.
Class powerpit.messages.AlarmWithValue 812 is a public class.
AlarmWithValue extends AlarmMessage and is sent by player or dealer to
indicate credit
value involved in alarm for handpay, cashout, jackpot or invalid win. Decode
specific log
type for RAM corruption.
Class powerpit.messages.RandomDraw 813 is a public class. RandomDraw
extends Message and is sent by test console to game machine running serial
test software,
to indicate random numbers drawn on console.
Class powerpit.messages.FinalStep 814 is a public class. FinalStep extends
PlayMessage and is an end of game notification sent by game to player for
logging,
recalculation of credits, various game meters. Subclassed by individual game.
Class powerpit.messages.IntermediateStep 815 is a public class.
IntermediateStep
extends PlayMessage and Intermediate play steps sent between dealer and remote
player
in multiplayer games (e.g. blackjack).
Class powerpit.messages.InitialStep 816 is a public class InitialStep extends
PlayMessage. Initial play steps such as start of game, etc. primarily sent
from
46
CA 02319600 2000-09-14
game/dealer to a player. No final bets have been placed when these messages
are sent,
and generally a game be cancelled, or resumed without penalty at this point.
In the single player game, all player messages are sent only to the game. The
base class method processMessage() strains out everything except player button
presses
S and trackball messages, which are available to the game loop through its
nextMessage()
method. Alarms (e.g. attendant key on/offj are examined via the lastAlarm()
and
isAlarmed() methods in BaseGame and GameApplet. The player station does not
echo
play step messages to the game after processing them.
Fig 9 illustrates the relationships between the Java classes associated with
Local
Message Passing.
In the multi-player game, player messages are relayed to the dealer. The
dealer
station game loop initiates all play step messages which are then relayed back
to the game
loop on the relevant player station. Button presses are generally available
only to the
dealer station game; except for auditing or tounament modes when the cashout,
attendant
and posibly other buttons are made active in a special way.
Fig 10 illustrates the relationships between the Java classes associated with
Network Message Passing.
Logs are available in two flavors. Logs using file-based I/O, primarily for
test and
development, may be found in package powerpit.mains.audit. Logs using binary
I/O to
NVRAM are in package powerpit.mains.nvram.
All logs contain the following interfaces:
/** When NMI() is invoked, all logs know it. */
public static final synchronized void NMI()
/** used by online system in particular */
public static final synchronized Boolean NMIReceived()
/** Abstract method must be implemeted by each subclass. Should be implemented
as synchronized, so save operations complete before NMI() can be invoked. */
public abstract void save(Object object)throws IOException;
/** Recover operation for specific object type to be logged. Should be
implemented
as synchronized so save() operation cannot change data while it is being
recovered. */
public abstract Object recover()throws IOException;
47
CA 02319600 2000-09-14
/** * Display stored data. Data should be recovered with the * recover()
method,
internally, to avoid displaying corrupt data. */
public abstract String[][] display() throws Exception;
Each player must log events and play history for auditing. Meters are likewise
required for auditing and also for player station recovery after power-down or
other
serious error conditions requiring reboot.
Audits are always an instance of powerpit.mains.audit.JEventLog or
powerpit.mains.nvram.EventLog. A configurable number (default 100) of events
are
displayed. All system events are logged by the player, whether they cause an
alarm
condition or not.
Meters is an instance of powerpit.mains.audit.JMeterLog or
powerpit.mains.nvram.MeterLog. All meters are logged by the player, each time
they
change value and recovered at power-up.
Play History is an instance of powerpit.mains.audit.JPlayLog or
powerpit.mains.nvram.PlayLog. Initial (handle-pull) and final (game-over) play
steps are
logged by the player. A configurable number (default 25) of play steps are
displayed.
Bills is an instance of powerpit.mains.audit.JBillLog or
powerpit.mains.nvram.BillLog. All bills accepted by a player station are
logged. A
configurable number (default 100) of bills are displayed.
Game Logs are configured into most games although they may not be required.
Currently, there is no audit mode available for viewing logs on a dealer
station.
State Log are an instance of a subclass of powerpit.mains.audit.JStateLog or
powerpit.mains.nvram.StateLog. If configured, it is used to recover game state
after a
power-down or other serious error condition requiring reboot.
The Online Accounting System runs as a seperate, real-time process. It is
initiated
by a player station, using an instance of powerpit.online.OnlineSystem. The
method
powerpit.online.OnlineSystem: aranslate() is used to transform system messages
into
online system packets and transfer them. The method
powerpit.online.OnlineSystem::pol1() is used by the system to acquire online
commands
and credit transfers.
When tournament mode is activated, via the TOURNAMENT parameter in the
configuration file, several changes occur in the execution of the normal game
loop. Play
48
CA 02319600 2000-09-14
stops whenever the player's credits go to 0 or the tournament round timer
expires. Play
resumes when an attendant uses his key to reset the tournament counters and
timer
(instructions appear onscreen). Hard meters, the hopper and coin and bill
validators are
all de-activated, whether configured or not, during tournament mode. Meter
values are
saved in a different area of NVRAM from the normal meters and the RAM version
check
is disabled. This allows the casino to use the same machines for tournament
play as those
which run the "real" game, without having to clear the RAM, as when a game
version
changes for normal play. The online system, if present, will continue to
monitor the
tournament machines normally.
At shutdown, the game invokes the destroy() method. This causes a flag to be
set,
indicating that shutdown is in progress, and launches a Thread that is an
instance of
powerpit.mains.Stopper to complete shutdown processing. This Thread stops the
running
game loop and issues a shutdown command to the local station. If this is a
dealer station,
the shutdown command is relayed to the remote player stations.
The I/O board sets a status when it senses that power is failing. This is
relayed to
the station software, which initiates the shutdown sequence, above, by passing
the power-
down alarm to the game. Once status bit is set, the online system (if any) is
aborted and
all logs are closed for fiu-ther new write operations. Any Java Exception
caught in the
game loop may cause the system to exit; except in the most severe cases of
hardware
errors, the meters and other logs in non-volatile RAM will still be preserved
in a
consistent state.
Except in the case of communications errors between the dealer and individual
player stations in multi-player games, it is best to design the game loop to
exit upon
receiving the first exception before NVRAM may be corrupted or an
unrecoverable
condition obscures the original error.
Various embodiments of individual game personalities associated with
individual
games that have been constructed using the gaming device 100. These game
personalities
comprise a storybook fantasy game, a monster money game, and a blackjack game.
Storybook Fantasy Personality
All files required to give the Storybook Fantasy Video Slot "personality" to
the
basic system described previously, reside in .../powerpit/slotsand its
subdirectories,
49
CA 02319600 2000-09-14
princess/, audio/ and princess/images/. Sounds are stored in audio/ and
graphics for the
reels and backgroundsare in princess/images/.
Several configuration files are available for the game in .../powerpit/slots:
1. test.txt, standard test configuration
2. slot.txt, standard game machine configuration; this is copied by bldslot.sh
(see
IIL6.Building the CD-ROM) to .../slots/slot.txt on the target system.
The text of slot.txt follows:
// name of applet to run for game (required)
GAME APPLET powerpit.slots.SlotMachine
// dimensions for applet display (required)
WIDTH 640
HEIGHT 480
// game denomination: cents per credit (required)
DENOMINATION 5
// unreasonable win amount strictly greater than any possible jackpot
(credits)
// defaults to 999,999,999
W1N LIMIT 1000000
// game controls when the error candle goes off and on - any value for this
// parameter allows game-control of the error candle!
MANUAL_CANDLE true
// tilt when player wins this many dollars in credits (clear with key)
JACKPOT_LIMIT 10000
// turn the validators off when we have this many dollars in credits
VALIDATORS_OFF 3000
// handpay when credits are greater than this much in dollars
HAND_PAY 1200
// turn off coin validator when this many dollars are accepted between
games
COIN_LIMIT 1500
// turn off bill validator when this many dollars are accepted between
games
BILL_LIMIT 1500
// turn off eft transfers in when this many dollars are accepted between
games
EFT_LIMIT 3000
// turn the validators off when we have this many dollars in credits
VALIDATORS_OFF 3000
// handpay when credits are greater than this much in dollars
HAND_PAY 50
// turn off coin validator when this many dollars are accepted between
games
CA 02319600 2000-09-14
COIN_LIMIT 1500
// turn off bill validator when this many dollars are accepted between
games
BILL_LIMIT 1500
// turn off eft transfers in when this many dollars are accepted between
games
EFT_LIMIT 3000
// station type (required)
STATION powerpit.devices.PlayerStation
STATION_CLASSES powerpit.mains.BaseGameInterface
STATION_VALUES owner
// dealer image to display in background (required for graphics)
PLAYER_BACKGROUND slots/princess/images/background.gif
// random number generator to use (required for dealer or standalone)
1 S GENERATOR powerpit.chance.KnuthWithRNG
GENERATOR_CLASSES java.lang.Integer
GENERATOR_VALUES 200
// dealer candle
CANDLE powerpit.slots.NVSMCandles
CANDLE CLASSES powerpit.devices.PlayerStation
CANDLE_VALUES owner
// online system (comment this out to test bill validator)
ONLINE powerpit.online.OnlineSystem
ONLINE_CLASSES powerpit.devices.PlayerStation
ONLINE_VALUES owner
COMPANY "IGCA "
PAYBACK 96.84
GAME_ID "NVSSF "
// iiob
IIOB powerpit.iiob.IIOB
IIOB CLASSES powerpit.devices.Station
IIOB_VALUES owner
// meters
METER_MODEL powerpit.slots.NVSMMeterModel
METER_MODEL_CLASSES powerpit.devices.Station
METER_MODEL_VALUES owner
// meter log for recovery
METER_LOG powerpit.mains.nvram.MeterLog
METER_LOG_CLASSES java.lang.Integer
METER_LOG_VALUES 5
// event log for alarms (last 100)
EVENT LOG powerpit.mains.nvram.EventLog
EVENT LOG_CLASSES java.lang.Integer java.lang.Integer
EVENT_LOG_VALUES 5100
// state log for recovery
STATE LOG powerpit.mains.nvram.StateLog
STATE LOG CLASSES powerpit.mains.BaseGameInterface
j ava.lang.Integer
51
CA 02319600 2000-09-14
STATE_LOG_VALUES owner 5
// history log for play steps (last 50 = last 25 games)
PLAY LOG powerpit.mains.nvram.PlayLog
PLAY LOG_CLASSES java.lang.Integer java.lang.Integer
PLAY_LOG_VALUES 5 50
// bill log
BILL_LOG powerpit.mains.nvram.BillLog
BILL_LOG_CLASSES java.lang.Integer java.lang.Integer
BILL_LOG_VALUES 5 25
// switches
SWITCH_HARNESS powerpit.slots.NVSMSwitchHarness
SWITCH HARNESS CLASSES powerpit.devices.Station
SWITCH_HARNESS_VALUES owner
// button panel
BUTTONS powerpit.slots.NVSMButtonPanel
BUTTONS CLASSES powerpit.devices.PlayerStation
java.lang.Boolean
BUTTONS_VALUES owner false
// bill validator
BILL_VALIDATOR powerpit.devices.JCMValidator
BILL_VALIDATOR_CLASSES powerpit.devices.PlayerStation
j ava.lang.Integer
BILL_VALIDATOR_VALUES owner 0
NOTE: the JCM bill validator may also be tested by connecting it directly
to the serial port of your PC. This is done by replacing the last 2 lines
above with:
BILL VALIDATOR_CLASSES powerpit.devices.PlayerStation
j ava.lang. String
BILL_VALIDATOR_VALUES owner "/dev/cua0"
NOTE: use cua0 for MS COM1, cual for MS COM2
// coin validator
COIN_VALIDATOR powerpit.devices.ColeCoinValidator
COIN_VALIDATOR_CLASSES powerpit.devices.PlayerStation
j ava.lang.Integer j ava.lang.Integer j ava.lang.Integer
java.lang.Integer java.lang.Integer
// coin-in, tilt, drop gate, hopper full, power
COIN_VALIDATOR_VALUES owner 5 24 6 9 4
// hopper
HOPPER powerpit.devices.Hopper
HOPPER_CLASSES powerpit.devices.CoinOutMeter
j ava.lang.Integer j ava.lang.Integer
// motor line, sensor line
HOPPER_VALUES owner 7 8
// printer
//PRINTER powerpit.devices.Printer
//PRINTER CLASSES powerpit.devices.PlayerStation
java.lang.Integer
//PRINTER VALUES owner 1
52
CA 02319600 2000-09-14
// reel symbols parameter order is: (enclose in quotes if they contain
spaces)
// owner
// reel symbol name as it appears in the reel strips (all upper case)
// reel symbol display names (singular form)
// reel symbol display names (plural form)
// reel symbol image filename
// reel strip symbol name of alternate symbol for win flashing
REEL SYMBOLS powerpit.slots.ReelSymbol
REEL SYMBOLS CLASSES powerpit.slots.ReelSymbols
j ava.lang. String
java.lang.String
java.lang.String java.lang.String java.lang.String
REEL_SYMBOLS_VALUES owner CASTLE Castle Castles
slots/princess/images/castle.gif BLANK
owner PRINCESS Princess Princesses
slots/princess/images/princess.gif BLANK
owner WITCH Wizard Wizards
slots/princess/images/wizardl.gif BLANK
owner FAIRY Fairy Fairies
slots/princess/images/fairy.gif BLANK
owner KING King Kings
slots/princess/images/king.gif BLANK
owner QUEEN Queen Queens
slots/princess/images/queen.gif BLANK
owner JACK Jack Jacks
slots/princess/images/jack.gif BLANK
owner TEN 10 lOs
slots/princess/images/l0.gif BLANK
owner FROGPRC Frog Frogs
slots/princess/images/frog.gif BLANK
owner SPELLBK "Spell Book" "Spell Books"
slots/princess/imageslbooks.gif BLANK
owner BLANK Blank Blanks
slots/princess/images/blank.gif BLANK
//reel strips
REEL STRIPS powerpit.slots.princess.ReelStrips96
REEL STRIPS CLASSES powerpit.slots.SlotMachine
REEL_STRIPS_VALUES owner
//combination table
COMBINATION_TABLE powerpit.slots.princess.PrincessCombo
COMBINATION_TABLE CLASSES powerpit.slots.SlotMachine
COMBINATION_TABLE_VALUES owner
// upper left corner of first reel
REEL_X 70
REEL_Y 138
// pixels between reels
53
CA 02319600 2000-09-14
REEL SPACE 12
//meter digits (and space character)
ONSCREEN_METER DIGITS slots/princess/images/Dig 11
//onscreen meter coordinates
ONSCREEN_METER_CREDIT_X 60
ONSCREEN_METER_CREDIT_Y 24
ONSCREEN_METER_BET_X 177
ONSCREEN_METER_BET_Y 24
ONSCREEN_METER_WIN_X 274
ONSCREEN_METER_WIN_Y 24
ONSCREEN_METER_PAID_X 383
ONSCREEN_METER_PAID_Y 24
PAID_PATCH_X 342
PAID PATCHY 0
PAID PATCH slots/princess/images/paid.gif
//paylines in their "turned on" state
PAYLINES slots/princess/images/Line 9
//paylines in their "extra bright" state
//PAYLINES BRIGHT slots/princess/images/Gloline 9
//// sound to play for big payoff
//WIN SOUND slots/audio/irealshort8.wav
// sounds to play for wins
WIN_TUNES powerpit.slots.WinTune
WIN_TUNES CLASSES powerpit.slots.WinTunes java.lang.Integer
j ava.lang. String
WIN TUNES VALUES owner 30 slots/audio/irealshort8.wav
owner 60 slots/audio/irealshortl8.wav
owner 200 slots/audio/Ishort8.wav
owner 750 slots/audio/imedium8.wav
// sound to play while reels are spinning
INDEX SOUND slots/audio/our_reel stop.wav
The game specific module comprising specific game engine may be
located in .../powerpit/slots and .../powerpit/slots/princess.
slots/SlotMachine.java: main video slot machine engine
slots/NVSMButtonPanel.java: container for assigning buttons.
slots/NVSMCandles.java: container for assigning candles.
slots/NVSMMeterModel Java: container for assigning meters.
slots/NVSMSwitchHarness.java: container for assigning switches.
Utility classes for organizing reel symbols and virtual reel-strips:
slots/ReelPositions.java
slots/ReelStrips.java
slots/ReelSymbol.java
slots/ReelSymbols.java
slots/princess/ReelStrips90.java
slots/princess/ReelStrips92.java
slots/princess/ReelStrips94.java
slots/princess/ReelStrips96.java
54
CA 02319600 2000-09-14
Utility classes for computing combinations:
slots/SlotCombo.java
slots/SlotComboLine.java
slots/SubstitutionLine.java
State data and play history:
slots/SlotFinal.java
slots/SlotInitial.java
slots/SlotState.java
slots/SlotStateData.java
Analyzer:
slots/SlotTest.java
Utility classes for computing wins:
slots/SlotWin.java
slots/SlotWinLine Java
slots/SubstitutionLine Java
Utility classes for displaying wins:
slots/WinFlash.java
slots/WinFlashThread.j ava
slots/WinTune.java
slots/WinTunes.java
All files required to give the Monster Money Video Slot "personality" to the
basic
system described previously, reside in .../powerpit/slots/monster and
directories,
./powerpit/slots/princess/ and .../powerpit/slots/audio/. Sounds data modules
are stored
in .../powerpit/slots/audio/ and graphics for the reels and backgrounds are in
./powerpit/slots/monster/images/. NOTE: the only difference between Monster
Money
and Storybook Fantasy (for identical percentage pay tables) is the graphics
and
configuration file - all executable code is identical.
Several configuration files are available for the game in
.../powerpit/slots/monster:
1. test.txt, standard test configuration
2. slot.txt, standard game machine configuration; this is copied by bldslot.sh
to
../slots/slot.txt on the target system.
3. testtest.txt, test configuration with analyzer
The text of slot.txt follows:
// name of applet to run for game (required)
GAME_APPLET powerpit.slots.SlotMachine
// dimensions for applet display (required)
WIDTH 640
CA 02319600 2000-09-14
HEIGHT 480
// game denomination: cents per credit (required)
DENOMINATION 5
// unreasonable win amount strictly greater than any possible jackpot
(credits)
// defaults to 999,999,999
WIN_LIMIT 1000000
// game controls when the error candle goes off and on - any value for this
// parameter allows game-control of the error candle!
MANLJAL_CANDLE true
// tilt when player wins this many dollars in credits (clear with key)
JACKPOT_LIMIT 10000
// turn the validators off when we have this many dollars in credits
VALIDATORS_OFF 3000
// handpay when credits are greater than this much in dollars
HAND_PAY 1200
// turn off coin validator when this many dollars are accepted between games
COIN_LIMIT 1500
// turn off bill validator when this many dollars are accepted between games
BILL_LIMIT 1500
// turn off eft transfers in when this many dollars are accepted between games
EFT_LIMIT 3000
// turn the validators off when we have this many dollars in credits
VALIDATORS_OFF 3000
// handpay when credits are greater than this much in dollars
HAND_PAY 50
// turn off coin validator when this many dollaxs are accepted between games
COIN_LIMIT 1500
// turn off bill validator when this many dollars axe accepted between games
BILL_LIMIT 1500
// turn off eft transfers in when this many dollars are accepted between games
EFT_LIMIT 3000
// station type (required)
STATION powerpit.devices.PlayerStation
STATION_CLASSES powerpit.mains.BaseGameInterface
STATION_VALUES owner
// dealer image to display in background (required for graphics)
PLAYER_BACKGROUND slots/princess/images/background.gif
// random number generator to use (required for dealer or standalone)
GENERATOR powerpit.chance.KnuthWithRNG
GENERATOR_CLASSES java.lang.Integer
GENERATOR_VALUES 200
// dealer candle
CANDLE powerpit.slots.NVSMCandles
CANDLE_CLASSES powerpit.devices.PlayerStation
CANDLE_VALUES owner
// online system (comment this out to test bill validator)
ONLINE powerpit.online.OnlineSystem
56
CA 02319600 2000-09-14
ONLINE-CLASSES powerpit.devices.PlayerStation
ONLINE_VALUES owner
COMPANY "IGCA "
PAYBACK 96.84
GAME_ID "NVSSF "
// iiob
IIOB powerpit.iiob.IIOB
IIOB CLASSES powerpit.devices.Station
IIOB_VALUES owner
// meters
METER_MODEL powerpit.slots.NVSMMeterModel
METER_MODEL CLASSES powerpit.devices.Station
METER_MODEL_VALUES owner
// meter log for recovery
METER_LOG powerpit.mains.nvram.MeterLog
METER_LOG_CLASSES java.lang.Integer
METER_LOG_VALUES 5
// event log for alarms (last 100)
EVENT LOG powerpit.mains.nvram.EventLog
EVENT LOG_CLASSES java.lang.Integer java.lang.Integer
EVENT LOG VALUES 5 100
// state log for recovery
STATE LOG powerpit.mains.nvram.StateLog
STATE LOG_CLASSES powerpit.mains.BaseGameInterface
j ava.lang.Integer
STATE_LOG_VALUES owner 5
// history log for play steps (last 50 = last 25 games)
PLAY_LOG powerpit.mains.nvram.PlayLog
PLAY_LOG_CLASSES java.lang.Integer java.lang.Integer
PLAY_LOG_VALUES 5 50
// bill log
BILL LOG powerpit.mains.nvram.BillLog
BILL_LOG_CLASSES java.lang.Integer java.lang.Integer
BILL_LOG_VALUES 5 25
// switches
SWITCH_HARNESS powerpit.slots.NVSMSwitchHarness
SWITCH_HARNESS CLASSES powerpit.devices.Station
SWITCH_HARNESS_VALUES owner
// button panel
BUTTONS powerpit.slots.NVSMButtonPanel
BUTTONS CLASSES powerpit.devices.PlayerStation java.lang.Boolean
BUTTONS_VALUES owner false
// bill validator
BILL_VALIDATOR powerpit.devices.JCMValidator
BILL_VALIDATOR_CLASSES powerpit.devices.PlayerStation
j ava.lang.Integer
BILL VALIDATOR VALUES owner 0
57
CA 02319600 2000-09-14
NOTE: the JCM bill validator may also be tested by connecting it directly
to the serial port of your PC. This is done by replacing the last 2 lines
above with:
BILL_VALIDATOR_CLASSES powerpit.devices.PlayerStation java.lang.String
BILL_VALIDATOR_VALUES owner "/dev/cua0"
NOTE: use cua0 for MS COM1, cual for MS COM2
// coin validator
COIN_VALIDATOR powerpit.devices.ColeCoinValidator
COIN_VALIDATOR_CLASSES powerpit.devices.PlayerStation
java.lang.Integer java.lang.Integer java.lang.Integer
j ava.lang.Integer j ava.lang.Integer
// coin-in, tilt, drop gate, hopper full, power
COIN_VALIDATOR_VALUES owner 5 24 6 9 4
// hopper
HOPPER powerpit.devices.Hopper
HOPPER CLASSES powerpit.devices.CoinOutMeter
j ava.lang.Integer j ava.lang.Integer
// motor line, sensor line
HOPPER VALUES owner 7 8
// printer
//PRINTER powerpit.devices.Printer
//PRINTER CLASSES powerpit.devices.PlayerStation java.lang.Integer
//PRINTER VALUES owner 1
// reel symbols parameter order is: (enclose in quotes if they contain spaces)
// owner
// reel symbol name as it appears in the reel strips (all upper case)
// reel symbol display names (singular form)
// reel symbol display names (plural form)
// reel symbol image filename
// reel strip symbol name of alternate symbol for win flashing
REEL SYMBOLS powerpit.slots.ReelSymbol
REEL SYMBOLS CLASSES powerpit.slots.ReelSymbols java.lang.String
j ava.lang. String
java.lang.String java.lang.String java.lang.String
REEL SYMBOLS VALUES owner CASTLE "Monster money"
"Monster monies"
slots/monster/images/M_M3.gif BLANK
owner PRINCESS Dragon Dragons
slots/monster/images/Dragon3.gif BLANK
owner WITCH Crown Crowns
slots/monster/images/Crown2.gif BLANK
owner FAIRY Castle Castles
slots/monster/images/Castle3.gif BLANK
owner KING Coin Coins
slots/monster/images/Coins3.gif BLANK
owner QUEEN Flame Flames
slots/monster/images/flames3.gif BLANK
owner JACK Knight Knights
58
CA 02319600 2000-09-14
slots/monster/images/Knight3.gif BLANK
owner TEN Shield Shields
slots/monster/images/Shield3.gif BLANK
owner FROGPRC Eyes Eyes
slots/monster/images/eyesl.gif BLANK
owner SPELLBK Jewels Jewels
slots/monster/images/Jewals3.gif BLANK
owner BLANK Blank Blanks
slots/monster/images/blank.gif BLANK
//reel strips
REEL STRIPS powerpit.slots.princess.ReelStrips96
REEL STRIPS CLASSES powerpit.slots.SlotMachine
REEL_STRIPS_VALITES owner
//combination table
COMBINATION_TABLE powerpit.slots.princess.PrincessCombo
COMBINATION_TABLE CLASSES powerpit.slots.SlotMachine
COMBINATION TABLE VALUES owner
// upper left corner of first reel
REEL_X 70
REEL_Y 13 8
// pixels between reels
REEL_SPACE 12
//meter digits (and space character)
ONSCREEN_METER_DIGITS slots/monster/images/O.gif
slots/monster/images/ 1. gif
slots/monster/images/2.gif
slots/monster/images/3.gif
slots/monster/images/4.gif
slots/monster/images/S.gif
slots/monster/images/6.gif
slots/monster/images/7.gif
slots/monster/images/8.gif
slots/monster/images/9.gif
slots/monster/images/l0.gif
//onscreen meter coordinates
ONSCREEN_METER_CREDIT_X 60
ONSCREEN_METER_CREDIT_Y 26
ONSCREEN_METER_BET_X 200
ONSCREEN_METER_BET_Y 26
ONSCREEN_METER_WIN_X 312
ONSCREEN_METER_WIN_Y 26
ONSCREEN_METER_PAID_X 434
ONSCREEN_METER_PAID_Y 26
PAID_PATCH_X 385
PAID_PATCH_Y 0
PAID PATCH slots/monster/images/PAID.gif
//paylines in their "turned on" state
59
CA 02319600 2000-09-14
PAYLINES slots/monster/images/newLine 9
//// sound to play for big payoff
//WIN SOUND slots/audio/irealshort8.wav
// sounds to play for wins
WIN TUNES powerpit.slots.WinTune
WIN TUNES CLASSES powerpit.slots.WinTunes java.lang.Integer
j ava.lang. String
WIN_TUNES_VALUES owner 30 slots/audio/irealshort8.wav
owner 60 slots/audio/irealshortl8.wav
owner 200 slots/audio/Ishort8.wav
owner 750 slots/audio/imedium8.wav
// sound to play while reels are spinning
INDEX_SOUND slots/audio/our_reel stop.wav
The game specific module comprising specific game engine may be located
in.../powerpit/slots and .../powerpit/slots/princess.
slots/SlotMachine.java: main video slot machine engine
slots/NVSMButtonPanel.java: container for assigning buttons.
slots/NVSMCandles.java: container for assigning candles.
slots/NVSMMeterModel.java: container for assigning meters.
slots/NVSMSwitchHarness.java: container for assigning switches.
Utility classes for organizing reel symbols and virtual reel-strips:
slots/ReelPositions.java
slots/ReelStrips.java
slots/ReelSymbol.java
slots/ReelSymbols.java
slots/princess/ReelStrips90.java
slots/princess/ReelStrips92.java
slots/princesslReelStrips94.java
slots/princess/ReelStrips96 Java
Utility classes for computing combinations:
slots/SlotCombo.java
slots/SlotComboLine.java
slots/SubstitutionLine.java
State data and play history:
slots/SlotFinal.java
slots/SlotInitial Java
slots/SlotState.java
slots/SlotStateData.java
Analyzer:
slots/SlotTest.java
Utility classes for computing wins:
slots/SlotWin.java
slots/SlotWinL,ine.java
slots/SubstitutionLine.java
Utility classes for displaying wins:
slots/WillFlash.java
slots/WinFlashThread.java
CA 02319600 2000-09-14
slots/WinTune.j ava
slots/WinTunes.java
All files required to give the mufti-player, Nevada-style Blackjack
"personality" to
the basic system described previously, reside in .../powerpit/blackjack and
its
subdirectories, audio/ and images/. Sounds data modules are stored in audio/
and
graphics for the cards and backgrounds are in images/.
The class powerpit.blackjack.BJDealer is a subclass of
powerpit.blackjack.BJBase, which defines data structures and a few methods
common to
the player and dealer. BJBase is a subclass of GameApplet.
Several configuration files are available for the dealer:
1. lvdl.txt, standard test configuration
2. gamedl.txt, standard game machine configuration; this is copied by
nvbj copy.sh to .../blackjack/lvdl.txt on the target system.
gamedl.txt follows:
// lvdl.txt: run player station with remote dealer
// name of applet to run for game (required)
GAME_APPLET powerpit.blackjack.BJDealer
// dimensions for applet display (required)(adjust for size error)
WIDTH 660
HEIGHT 520
// game denomination: cents per credit (required)
DENOMINATION 100
// station type (required)
STATION powerpit.devices.DealerStation
STATION_CLASSES powerpit.mains.BaseGameInterface
STATION_VALUES owner
// player stations to load (required for dealer)
PLAYERS 5
// dealer image to display in background (required for graphics)
DEALER_BACKGROUND blackjack/imagesBjdback.gif
// random number generator to use (required for dealer or standalone)
GENERATOR powerpit.chance.JKnuthV2Random
GENERATOR_CLASSES java.lang.Integer
GENERATOR_VALUES 200
// dealer candle
CANDLE powerpit.blackjack.NVBJDCandles
CANDLE CLASSES powerpit.devices.DealerStation
CANDLE_VALUES owner
// iiob
IIOB powerpit.iiob.IIOB
IIOB CLASSES powerpit.devices.Station
61
CA 02319600 2000-09-14
IIOB VALUES owner
// meters
METER_MODEL powerpit.blackjack.NVBJDMeterModel
METER_MODEL CLASSES powerpit.devices.Station
METER_MODEL_VALUES owner
// meter log for recovery
METER_LOG powerpit.mains.nvram.MeterLog
METER_LOG_CLASSES java.lang.Integer
METER_LOG_VALUES 5
// event log for alarms
EVENT LOG powerpit.mains.nvram.EventLog
EVENT LOG_CLASSES java.lang.Integer java.lang.Integer
EVENT_LOG_VALUES S 100
1 S // state log for recovery
STATE LOG powerpit.mains.nvram.StateLog
STATE_LOG_CLASSES powerpit.mains.BaseGameInterface java.lang.Integer
STATE_LOG_VALUES owner 5
// switches
SWITCH HARNESS powerpit.blackjack.NVBJDSwitchHarness
SWITCH HARNESS CLASSES powerpit.devices.Station
SWITCH_HARNESS_VALUES owner
// card image location
DECK black] ack/images/
// maximum bet allowed
MAX_BET 50
// sound to play if the dealer busts out
BUST SOUND blackjack/audio/dbust.au
// sounds to play for hand values
NUM_SOUNDS blackjack/audio/
// sound to play at end of hand
END_SOUND blackjack/audio/spacemusic.au
// sound to play for accepting bets
PLACEBETS SOUND blackjack/audio/dpls.au
// sound to play for no more bets
NOMOREBETS SOUND blackjack/audio/dnmb.au
// sound to play just before dealing
LUCK_SOUND blackjack/audio/dglk.au
// sound to play when idling
LETSPLAY_SOUND blackjack/audio/dlpbj.au
// sound to play for insurance opportunity
INSURE_SOUND blackjack/audio/dins.au
The game specific module comprising specific game engine may be located
in.../powerpit/blackj ack/BJDealer. j ava.
The class powerpit.blackjack.BJPlayer is a subclass of
powerpit.blackjack.BJBase,
which defines data structures and a few methods common to the player and
dealer. BJBase is a subclass of GameApplet.
62
CA 02319600 2000-09-14
Several configuration files are available for the players:
1. lvpl.txt, standard test configuration
2. gamepl.txt, standard game machine configuration; this is copied by
nvbj copy.sh to .../blackjack/lvpl.txt on the target system.
gamepl.txt follows:
// lvpl.txt: run player station with remote dealer
// name of applet to run for game
GAME APPLET powerpit.blackjack.BJPlayer
// maximum bet
MAX_BET 50
// dimensions for applet display (required)(adjust for size error)
WIDTH 660
HEIGHT 520
// game denomination: cents per credit (required)
DENOMINATION 100
// station type (required)
STATION powerpit.devices.NetworkPlayerStation
STATION_CLASSES powerpit.mains.BaseGameInterface
STATION_VALUES owner
// player image to display in background
PLAYER_BACKGROUND blackjack/imagesBjpback.gif
// player lamp for attendant
CANDLE powerpit.blackjack.NVBJPCandles
CANDLE CLASSES powerpit.devices.PlayerStation
CANDLE_VALUES owner
// iiob
IIOB powerpit. iiob.IIOB
IIOB CLASSES powerpit.devices.Station
IIOB_VALUES owner
// meters
METER_MODEL powerpit.blackjack.NVBJPMeterModel
METER_MODEL CLASSES powerpit.devices.Station
METER_MODEL_VALUES owner
// meter log for recovery
METER_LOG powerpit.mains.nvram.MeterLog
METER_LOG_CLASSES java.lang.Integer
METER_LOG_VALUES 5
// event log for alarms
EVENT LOG powerpit.mains.nvram.EventLog
EVENT LOG_CLASSES java.lang.Integer java.lang.Integer
EVENT_LOG_VALUES 5100
// history log for play steps
PLAY_LOG powerpit.mains.nvram.PlayLog
PLAY_LOG_CLASSES java.lang.Integer java.lang.Integer
PLAY_LOG_VALUES S 25
// switches
SWITCH_HARNESS powerpit.blackjack.NVBJPSwitchHarness
SWITCH HARNESS CLASSES powerpit.devices.Station
63
CA 02319600 2000-09-14
SWITCH_HARNESS_VALUES owner
// button panel
BUTTONS powerpit.blackjack.NVBJPButtonPanel
BUTTONS CLASSES powerpit.devices.PlayerStation
BUTTONS_VALUES owner
// bill validator
BILL VALIDATOR powerpit.devices.CBVBiIIValidator
BILL_VALIDATOR_CLASSES powerpit.devices.PlayerStation java.lang.Integer
BILL_VALIDATOR_VALUES owner 0
// coin validator
COIN_VALIDATOR powerpit.devices.BJCoinValidator
COIN_VALIDATOR_CLASSES powerpit.devices.PlayerStation
j ava.lang.Integer j ava.lang.Integer j ava.lang.Integer
j ava.lang.Integer j ava.lang.Integer j ava.lang.Integer
// coin-in, tilt, hopper gate, drop gate, hopper full, power
COIN_VALIDATOR_VALUES owner 5 24 0 6 9 4
// hopper
HOPPER powerpit.devices.Hopper
HOPPER_CLASSES powerpit.devices.CoinOutMeter
j ava.lang.Integer j ava.lang.Integer
// motor line, sensor line
HOPPER VALUES owner 7 8
// card image location
DECK blackjack/images/
// sound to play if the player busts out
BUST SOUND blackjack/audio/dbust.au
// sounds to play for hand values
NUM_SOLTNDS blackjack/audio/
// sound to play at end of hand
END_SOUND blackjack/audio/spacemusic.au
// sound to play for winning hand
WIN_SOUND blackjack/audio/bfan.au
// sound to play for player blackjack
BJ_SOUND blackjack/audio/dbj.au
// sound to play for losing hand
//LOSE SOUND blackjack/audio/hammer.au
// sound to play for push
PUSH SOUND blackjack/audio/gong.au
The game specific module comprising specific game engine may be located
in.../powerpit/blackjack/BJPlayer.java.
In addition to BJDealer, BJPlayer, the configuration files and sound and video
files, the Nevada Blackjack game requires some specialized classes. This will
provide a
64
CA 02319600 2000-09-14
good estimate of the total new code required for most games. Single player
games (a
simple slot example may be found in.../powerpit/docs) will require less
additional code.
BJStateData: subclasses powerpit.mains.GameData to provide specialized state
data for blackjack; uses BJHand and BJPlayerHand.
NVBJDCandles: subclasses powerpit.devices.Candelabra to provide specific
functionality for the dealer candles on the blackjack machine.
BJFinal: subclasses powerpit.messages.FinalStep to provide final game outcome
information specific to blackjack; uses BJHand and BJPlayerHand.
NVBJDMeterModel: subclasses powerpit.devices.MeterModel to provide
specialized dealer meters.
BJHand: subclasses powerpit.chance.CardHand to provide specialized blackjack
functionality.
NVBJDSwitchHarness: subclasses powerpit.devices.SwitchHarness to provide
specific functionality for the dealer switches on the blackjack machine.
BJInitial: subclasses powerpit.messages.InitialStep to provide game start
information specific to blackjack; uses BJHand.
NVBJPButtonPanel: subclasses powerpit.devices.ButtonPanel to provide normal
player button functionality for the blackjack player station.
BJIntermediate: subclasses powerpit.messages.IntermediateStep to provide
intemediate information specific to blackjack; uses BJHand and BJPlayerHand.
NVBJPCandles: subclasses powerpit.devices.Candelabra to provide specific
functionality for the player lamps on the blackjack machine.
NVBJPMeterModel: subclasses powerpit.devices.MeterModel to provide
specialized player meters.
BJPlayerHand: provides a container for up to 4 instances of BJHand and
provides
methods to determine whether a specific hand is splittable, etc.
NVBJPShowButtonPanel: subclasses powerpit.devices.ButtonPanel to provide
show player button functionality for the blackjack player station.
BJState: subclasses powerpit.mains.GameState to provide values for additional
states, e.g. INSURANCE, unique to blackjack.
NVBJPSwitchHarness: subclasses powerpit.devices.SwitchHarness to provide
specific functionality for the player switches on the blackjack machine.
CA 02319600 2000-09-14
The foregoing description of the exemplary embodiment of the invention has
been
presented for the purposes of illustration and description. It is not intended
to be
exhaustive or to limit the invention to the precise form disclosed. Many
modifications
and variations are possible in light of the above teaching. It is intended
that the scope of
the invention be limited not with this detailed description, but rather by the
claims
appended hereto.
66
