text:
|Publication number
|Publication type
|Application number
|Publication date
|27 Mar 2012
|Filing date
|18 Jul 2008
|Priority date
|11 Mar 1998
|Fee status
|Also published as
|Publication number
|Michael J Kuhn, Donald Evans, David A Krise
|Original Assignee
|Digideal Corporation
|Export Citation
|BiBTeX, EndNote, RefMan
|Patent Citations (91), Non-Patent Citations (19), Referenced by (16), Classifications (13), Legal Events (7)
|External Links: USPTO, USPTO Assignment, Espacenet
This continuation application claims priority to co-pending U.S. patent application Ser. No. 11/404,955 to Sines et al., entitled, "Multi-player electronic display gaming apparatuses," filed Apr. 14, 2006 and incorporated herein by reference, which in turn was a continuation of application Ser. No. 10/722,355 filed Nov. 25, 2003, now U.S. Pat. No. 7,255,642, which was a continuation of application Ser. No. 09/730,705 filed Dec. 5, 2000, now U.S. Pat. No. 6,651,985, which was a continuation of U.S. patent application Ser. No. 09/159,813 filed Sep. 23, 1998 (abandoned), which was a continuation-in-part of application Ser. No. 09/041,373 U.S. Pat. No. 6,165,069, filed Mar. 11, 1998.
In the gaming industry there is a significant volume of gambling that occurs at live table games that use playing cards. Example live table games include Blackjack, poker, Baccarat, and others. There are also proprietary or specialty live card games that have developed, such as Pai Gow poker, LET-IT-RIDE, CARIBBEAN STUD, and others. These and many other games use playing cards.
The use of real playing cards has a number of associated limitations and disadvantages which are of general concern to most card games, while other problems are associated with the use of playing cards in particular games. Several card manipulation operations are time-consuming, such as collecting, shuffling and dealing the cards. In many card games there is also the step of cutting the deck after it has been shuffled.
In the gaming industry, moreover, there is a significant amount of effort devoted to security issues that relate to play of the casino games, especially those that use playing cards. Part of the security concerns stem from frequent attempts to cheat during play. Attempts to cheat are made by players, dealers, and by both dealers and players acting in collusion. This cheating seeks to affect the outcome of the game in a way that favors the dealer or players who are working together. The amount of cheating in card games is significant to the gaming industry and constitutes a major security problem which has large associated losses. Thus, costs to prevent cheating are significant. Many of the attempts to cheat in the play of live table card games involve some aspect of card manipulation by the dealer during collecting, shuffling, cutting, or dealing the cards. Introducing one or more extra cards into the deck or into the cards in play is a common manner of cheating.
One approach to reducing security problems associated with the use of playing cards utilizes card readers, such as card dispensing shoes that have card detection capability. Card shoes hold a stack of cards containing typically from one to ten or even twenty decks of the playing cards. The cards are held in the card shoe in preparation for dealing and to secure the deck within a device that restricts access and helps to prevent card manipulations. Card shoes can be fit with optical or magnetic sensors which detect the cards as they are being dealt. Some of the difficulties introduced in security analysis by using above-the-table cameras is reduced when the sequence of cards dealt can be directly determined at the card shoe using optical or magnetic sensors. One advantage of such card shoes is that the card sequence information can be collected in a machine-readable format by sensing the specific nature (suit and count) of each card as the card is dealt out of the card shoe.
Conventional card shoes that sense the character of each playing card can convert the card identities and the dealt sequences into digital information or machine readable code. For example, U.S. Pat. No. 6,582,301 to Hill (the "Hill reference") describes a card dispensing shoe with barrier and scanner. In the card shoe described by Hill, an optical scanner, CPU system, and software associated with the shoe immediately know the card value, card rank, card suit, the sequence in which each of the cards was removed from the shoe; the hand or participant to which it was designated for delivery, as well as the scores of the various hands comprising the game round. Many other technologies exist or can be adapted for sensing specially made playing cards, or can be applied for optically scanning standard conventional playing cards as they are dealt or as each arrives "on deck" at the dealing position within the shoe. The scanned card information can be converted to digital or electronic information and fed to a memory or processor within a larger gaming system.
Because of the above-described vulnerability to cheating, there is a need for improved systems and methods that allow real playing cards to be used in some electronic gaming systems in order to provide the look, feel, and action of real cards while providing elements of security, automation, and virtual display of the cards. There is also a need for the real cards, having been converted to processor readable information during play, to be accompanied by corresponding wagering information, wherein the betting information is also virtually displayable. Thus, there is also a need for systems in which real cards are accompanied by real or virtual wagering chips or other betting techniques, and both cards and wagers are converted to digital information for processing, security tracking, and display of their images. There is a need for improved gaming systems that can sense both the cards and the bets in order to add a live feel to the game, add entertaining graphics, automate tedious parts of double-checking card and chip movement and whereabouts, and provide confidence and security to those at the gaming table that the cards and chips are being digitally tracked for all to see and verify.
Electronic gaming system with real playing cards and multiple player displays for virtual card and betting images. In one implementation, the exemplary system allows real playing cards to be used in electronic gaming systems that provide multiple video displays for multiple live participants at a gaming table. The system can post virtual images of the cards in play on the participant displays and can also display virtual bets, e.g., virtual wagering chips, on the same displays. The real playing cards provide the look, feel, and action of playing a card game while the electronic gaming system provides elements of automation, security, and virtual display of the cards and bets. By converting the identities of the cards in play into processor-usable information, the exemplary system can add entertaining graphics, automate tedious and costly aspects of double-checking card and chip movement and whereabouts, and provide confidence and security to those at the gaming table that the cards and chips are being digitally tracked for each participant to see and verify.
This summary section is not intended to give a full description of the electronic gaming system, or to provide a list of features and elements. A detailed description of example embodiments of the electronic gaming system follows.
Embodiments of the exemplary system are described below with reference to the accompanying drawings, which are briefly described below.
This disclosure describes an electronic gaming system that is capable of using real playing cards 61—or not—and multiple player displays for virtual card and betting images, e.g., virtual wagering chips. In one implementation, an exemplary system allows multiple participants to play a live casino-type table game with the option of using real playing cards 61, and includes multiple video displays, controllable by a processor to provide changeable display images for each participant. The game processor may perform various functions, including administering game rules that guide execution of the table game; defining virtual display images for the game in play; and assigning the virtual display images to the participants according to the game rules. Exemplary systems have the capability of using real playing cards 61, that is cards typically composed of paper or plastic, while posting virtual images of the cards in play on the various displays accompanied by virtual bets ("virtual wagering information") on the same displays.
The multiple displays may include at least one separate display for each participant (e.g., one to ten participants) and at least one display for a live dealer, if the particular game being played uses a dealer. There may also be a common display included that is viewable by all participating players (and dealer, if present). In another or the same implementation, the exemplary system possesses selectable modes, such that various combinations of real cards/virtual cards and real wagering chips/virtual wagering chips are user-selectable or at least reconfigurable. For example, a dealer, if used, or even a participant may toggle selections on a user interface presented on the display screen to select whether to use both real playing cards 61 and virtual playing cards, with virtual bets (i.e., with no real chips) or instead to use only virtual playing cards generated by the exemplary system. In some implementations, the use of real playing cards 61 and the type of wagering (real chips, virtual chips, or no chips) is factory set and cannot be changed.
When real cards are used, a "smart shoe" or "live shoe" (hereinafter "dealing shoe") identifies and tracks the cards in play on behalf of the exemplary gaming system, usually by passing card identities to a processor or a computer memory as digital data. In one implementation, the live shoe is both portable, so that the live shoe may be passed around the table, and wireless, communicating with the other components of the exemplary gaming system via conventional Bluetooth, Zigbee, WiMax, etc., wireless protocols.
Likewise, when real chips are used in a given game, some implementations of the exemplary system can sense the presence of real chips, including denomination or value. This can be accomplished by using special chips, such as those containing magnetic, barcode, or RFID identifiers, or by using conventional chips and optically sensing chip color, weight, and/or shape to obtain their value.
The exemplary system allows real playing cards 61 to be used in electronic gaming systems that provide multiple live participant displays in order to provide the look, feel, and action of real cards while providing elements of automation, security, and virtual display of the cards. By converting the identities of the cards in play into digital data, the exemplary system can add entertaining graphics, automate tedious and costly aspects of double-checking card and chip movement and whereabouts, and provide confidence and security to those at the gaming table that the cards and chips are being digitally tracked for all to see and verify.
Gaming Table and System General Layout
A playing surface 55 is provided upon the upwardly facing surface of table top 53 upon which participants of the card game play. A plurality of players (not shown) sit or stand along the semicircular portion and play a desired card game, such as the popular casino card game of blackjack. Other card games are alternatively possible, although the system herein is specifically described in terms of blackjack, as a representative example of a card game.
In one implementation, the gaming table 50 also advantageously includes a betting chip rack 59 which allows the dealer to conveniently store real betting chips used by the dealer in playing the game, when real wagering chips are used. Virtual wagering chips 70 may also be used in place of or in addition to the real wagering chips. A money drop slot 57 is further included to allow the dealer to easily deposit paper money bills thereinto when players purchase betting chips.
Table 50 supports an exemplary electronic gaming system 60 for live card games that can use real playing cards 61 or virtual playing cards. The exemplary system 60 offers wagering that uses real betting chips, virtual betting chips 70, or both simultaneously. In one scenario, the card game system 60 described herein is a retrofit system which has been added to table 50. Such retrofit systems includes a presentation unit 100 which displays images which depict the cards and card hands being played along with additional information used in the play of the card game. The presentation unit will be explained more fully below.
The system may or may not also include a dealer control which is preferably provided in the form of a dealing shoe 80 upon which a live dealer 56 can rest his hand and, for example, use control keys to provide control commands as will be detailed below. Dealing shoe 80 may also advantageously include other dealer controls or dealing shoe displays. In one implementation, the dealing shoe 80′ includes one or more optical scanning components to read the value, suit, rank, etc., of playing cards being dealt. The shoe 80′ or other components in the system 60 convert the optically scanned card information into card identity information used by a processor of the system 60.
The game processor or processors 90 are connected with the dealing shoe 80 or 80′ and presentation unit 100 using suitable connection cables 93. In one implementation, there are fourteen data cables running between the module 92 and the presentation unit 100 to control operation of the seven displays used in the presentation unit. There are also two data cables running between the dealing shoe module 80 and main controller module 92.
Presentation Unit—Generally
Example gaming table 50 is fitted with a presentation unit 100 which is supported thereon. The presentation units are preferably supported upon the upper or playing surface 55 of the gaming table. This allows the system to be easily installed upon a variety of differing gaming tables without extensive modifications being performed. Alternatively, the presentation unit can otherwise be mounted upon the gaming table in a manner which allows participants to view one or more of the displays which form a part of the presentation unit.
In the example construction shown, there is one presentation unit 100 which is adapted for use by a single live dealer 56 and six live players (not shown) who are in live attendance and positioned about the gaming table. Some other implementations are not hosted by a dealer.
Presentation Unit Participant Displays
Presentation unit 100 includes a number of visual displays, herein termed participant video displays, which are capable of displaying changeable display images. The participant display images are intended to display virtual playing cards and other information, such as virtual chip images 70 or other betting information, used in the play of the particular card game in play.
The dealer display 102, when a particular implementation hosts a dealer, is advantageously centered along a central centerline 110 to allow easy viewing by both dealer and players. The area of the presentation unit including and adjacent to dealer display 102 is the dealer section of the presentation unit.
Player displays 103 are preferably arranged in an arcuate array or around an entire perimeter of a circular or elliptically shaped table, forming a segment of an annular band across the upper face of the presentation unit. Each display can be centered upon a radial display centerline 111. In one implementation, this arrangement complements the semicircular player side of the presentation unit and the adjacent semicircular player side of the gaming table. In this arrangement the player displays are adjacent and opposite to each player seating position. In the construction shown that has six player positions, the displays are centered upon the player display centerlines at angularly spaced positions of about 20-30 degrees of angular arc, or more preferably approximately 25 degrees of arc. Varying the number of player positions and table configuration allows varying angular spacings to be used. This angular spacing arrangement facilitates easy viewing by the player who is viewing the real or virtual cards from his or her display. It also allows the dealer, if any, to have easy view from across the gaming table.
In one implementation, the player displays 103 are also advantageously presented in an upwardly facing orientation and contained in a single plane or approximately a single plane, to facilitate easy viewing by other players from around the table. Although this arrangement and capability are not essential, they increase viewing and interest of the nonparticipating players as a particular player's hand is being played out between the active player and dealer. This helps to maintain the ambiance of a live table game, enables skilled players to keep track of cards played, and overcomes some of the deficiencies of most video card games. Such games in particular lack significant interest to other people when the hand is being played out between a computer and a single player.
Presentation Unit Virtual Chip Production and Real Chip Detectors
In one implementation, the exemplary system 60 does not use physical betting chips, but administers wagering via virtual chip images 70 or other icons representing value, such as gold bars, etc. Consequently such betting is carried out via the participant video displays which may include touch-screen capability thereby providing interactive user interfaces between the participants and the example system 60. These user interface capabilities of the system 60 enable system variations. In one implementation, the example system 60 offers a menu whereby participants and/or dealer, if any, can select between real and virtual modalities. Real and virtual modalities can also be mixed and executed simultaneously. For example, the example system 60 may be configured to manage both real betting chips and virtual betting chips 70, both of which are optionally displayable on the multiple participant video displays. That is, some players may use real betting chips in the same game with other players who prefer only virtual betting chips 70 displayed only as images on the video display, although the example system 60 is capable of showing virtual images of the real betting chips too. A player typically buys virtual betting chips 70 on the spot via a dealer, money reader, or casino ticket or card reader, which are then posted to the player's balance at the table 50.
When real betting chips are used,
One implementation of the presentation unit includes betting chip sensors 121 which are immediately below or otherwise adjacent to zones 120. Sensors 121 can be selected from several different types of sensors. One suitable type is a weigh cell which senses the presence of a betting chip thereon so that the game processor knows at the start of a hand, that a player is participating in the next hand being played. A variety of weigh cells can be used.
Another suitable type of sensor 121 includes optical sensors. Such optical sensors can be photosensitive detectors which use changes in the sensed level of light striking the detectors. In an exemplary system, sensor 121 uses ambient light which beams from area lighting of the casino or other room in which it is placed. When a typical betting chip 160 is placed in detection zone 120, the amount of light striking the detector 121 located beneath the zone is measurably diminished by the opaque betting chip. The detector conveys a suitable electrical signal which indicates that a betting chip has been placed within the detection zone 120. A variety of other alternative detectors can also be used.
A further type of betting chip sensor is one which can detect coding included on or in the betting chips to ascertain the value of the betting chip or chips being placed by the players into detection zones 120. A form of this type of sensor or detector 121 is used to detect an integrated circuit based radio frequency identification unit which is included in or on the betting chips. Related sensors are sometimes referred to as radio frequency identification detection or read-write stations. Other variations of chip value readers include readers that scan a small barcode on each chip, or readers that merely detect the color of each chip, each color representing a denomination.
For example, one type of integrated circuit radio frequency identification transponder is available from Texas Instruments and is sold under the trademarks TIRIS TAG-IT. This transponder is available in a very thin wafer shape, and can be laminated between paper and plastic to form the transponding betting chip 164.
When betting chips 164 are used, the betting chip detection sensor 121 can be a radio frequency interrogator detection unit which sends out a query signal and receives a detectable response from the betting chip transponder 161. The transponder can be either powered or unpowered, depending upon the specific vendor chosen and the associated sensor technology and detection device used with that type of sensor. In the case of one suitable type of transponder, explained above from Texas Instruments, this same vendor has associated detection systems which can read data from the transponders. Also available are detection systems which can both read data from the transponder and write data onto the transponders. This vendor or other vendors may provide suitable detection and sensing subsystems which can be employed to not only read and write data thereto, but also provide confirmatory identification codes which deter counterfeiting of the gaming chips or provide additional data processing capabilities.
It is still further possible for other alternative sensors to be used instead of the sensors 121 described above. Such alternative sensors may work with typical betting chips or other types of betting chips. Such sensor can provide identification circuits or other identification or value-coding inserts or appliqu�s which can be included in or on the betting chips to provide value information, serial number information, and any other desired information.
Dealer Controls and Dealing Shoe
When a live dealer is used for a particular implementation, the card game system 60 also preferably includes a plurality of dealer controls which are advantageously provided near the dealer, e.g., near the dealing shoe 80′. However, the dealing shoe 80′ may also be wireless and/or portable for movement around the table 50. The dealer controls can alternatively be provided in the presentation unit or in other different forms which do not necessarily require the dealing shoe 80′ and other features.
In a given system 60, the real playing card reader can be a dealing shoe 80′, but does not have to be a shoe. Example dealing shoes 80 and 80′ are shown in greater detail in
In one implementation, the system 60 may have a dealing shoe 80 that does not deal real cards, for when virtual play without real playing cards 61 is desired. In this implementation, case 84 has a first display opening or window which allows a first dealing shoe display 81 to be presented for viewing. The dealing shoe also advantageously includes a second display opening or window which allows a second dealing shoe display 82 to be presented for viewing. In the construction the first and second displays 81 and 82 are provided by a single liquid crystal panel display. The display has two different portions or sections which are changeable and operated to provide different images through the display windows. The first display image typically shows a simulated stack of cards similar to what appears in viewing a traditional card stock contained in a manual dealing shoe long used in dealing blackjack. The first display image can also be varied to allow presentation of programming options which are available in setting up the system and customizing operational parameters to the desired settings for a particular casino or card room in which the system is being used.
The second shoe display 82 has a second display image which is advantageously used to provide a depiction of the back decorative side of a traditional playing card. This can be used along with some attractive presentation of the casino's name or other desirable image. The second shoe display image can also be moved or otherwise varied during the period of dealing to give the impression of movement and thus simulate cards being dealt from the shoe to add a touch of additional realism. Other display images are also clearly possible and can vary from casino to casino as management desires.
A card reader, or dealing shoe 80′ that reads the playing cards, typically includes optical scanning components for reading each card's suit and rank in real time. A person skilled in the art of engineering scanning devices can readily create a satisfactory card reader by arranging off-the-shelf light emitting diodes (LEDs) and fiber optic sensing components, coupled with the appropriate electronic control and image interpretation circuitry. Alternatively, the Hill reference introduced above describes a shoe that senses cards being played. Such a dealing shoe 80′ typically deals real cards for play at a user-selectable rate, sending card identity information to a computer memory or system processor. A software application program can be utilized to track which participants the dealt cards are intended for. A virtual card image, such as a synthesized or stylized image of each suit and rank of card can be associated with the card identity information generated at the dealing shoe 80′, and then displayed on the participants' video displays.
In one implementation, dealer controls on the dealing shoe 80′ also preferably include a key operated switch 83 which may be used to control basic operation of the system and for placing the unit into a programming mode. The key operated switch can provide two levels of access authorization which restricts access by dealers to programming, or additional security requirements can be provided in the software which restricts programming changes to management personnel.
Programming may be input in several different modes. In one form the programming can be provided using a touch screen display used as display 81 with varying options presented thereon and the programming personnel can set various operational and rules parameters, such as: the shuffle mode, number of decks of cards used in the virtual card stack, options with regard to the portion of the stack which is used before the stack is cut, limits on the amounts which can be bet at a particular table, whether splits are accepted for play and to what degree, options concerning doubling down plays, whether the dealer hits or stands on soft 17, and other rules can be made variable dependent upon the particular form of the system programming used in the system. It is alternatively, and more preferable to simply use the control keys 85-89 instead of a touch screen display in some forms of the exemplary system 60 to allow various menu options to be displayed and programming options to be selected using the control keys. Still further it is possible to attach an auxiliary keyboard (not shown) to the dealing shoe through a keyboard connection port 186 (see
The dealing shoe also includes a plurality of dealer operational controls provided in the form of dealer control sensors 85-89. Dealer control sensors 85-89 are advantageously electrical touch keys. The dealer control sensors are used by the dealer to indicate that desired control functions should take place or further proceed. For example, sensor 85 can be used to implement a player's decision to split his two similar cards and play them as two separate or split hands. Sensor 86 can be used to implement o player's decision to double down. Sensor 87 can be used to implement a player's decision to stand on the cards already dealt or assigned to that player. Sensor 88 can be used to "hit" a player by dealing him another card. Sensor 89 can be used to command shuffling and dealing of a new hand to the participants. In addition to or lieu of the above assignments, other functions can be attributed to other keys or input sensors of various types. In particular, it is planned that the above touch keys can be assigned to additional functions, such as in changeable soft key assignments during the programming or setup of the system.
Dealer control touch keys 85-89 can be selected from a wide variety of commercially available touch keys used to provide electrical control signals. Alternatively, the dealer control sensors can be provided in another form which are touch sensors, or other types of sensors which allow the dealer to indicate control commands being made or implemented by the dealer. The use of dealer control keys is designed with the object of minimizing most or all direct player input to the system. Instead, the players are required to provide the dealer with traditional hand gesture signals and/or oral instructions and then the dealer implements these instructions using the touch keys or other dealer control sensors.
Electronics and Control Processor
The card game system 60 also includes suitable data and control processing subsystem 90. Control and data processor 90 is largely contained within a main control module 92 supported beneath the table top 53 in casing 91 (
Power control circuit 184 is connected to a first mode control switch 182 and a second mode control switch 183. The first and second mode control switches are operated by the key control 83 (
The mother board 185 also includes a serial port 187 which allows stored data to be downloaded from the mother board to a central casino computer or other additional storage device. This allows card game action data to be analyzed in various ways using added detail, or by providing integration with data from multiple tables so that cheating schemes can be identified and eliminated. It also allows monitoring of dealer performance and accuracy on a routine basis. Player performance and/or skill can be tracked at one table or as a compilation from gaming at multiple tables. Additionally, player hand analysis can be performed.
Optional Player Identification
Although the system shown does not have features illustrated for receiving automated player identification information, such can alternatively be provided. Card readers such as used with credit cards, or other identification code reading devices (not shown) can be added in the presentation unit to allow or require player identification in connection with play of the card game and associated recording of game action by the controller 90. Such a user identification interface can be implemented in the form of a variety of magnetic card readers commercially available for reading a user-specific identification information. The user-specific information can be provided on specially constructed magnetic cards issued by a casino, or in some jurisdictions, magnetically coded credit cards or debit cards frequently used with national credit organizations such as VISA, MASTERCARD, AMERICAN EXPRESS, or banks and other institutions.
Alternatively, it is possible to use smart cards to provide added processing or data storage functions in addition to mere identification data. For example, the user identification could include coding for available credit amounts purchased from a casino. As further example, the identification card or other user-specific instrument may include specially coded data indicating security information such as would allow accessing or identifying stored security information which must be confirmed by the user after scanning the user identification card through a card reader. Such security information might include such things as file access numbers which allow the central processor 90 to access a stored security clearance code which the user must indicate using input options provided on displays 103 using touch screen displays.
Another alternative with regard to player identification having particular attraction is employed with regard to use of coded betting chips 164 described above. Each player can carry a transponder card which can be read and written to by the sensor 121. Upon arrival at the table, the player presents the transponder card to sensor 121 and the player is logged in. Thereafter bets can be charged from and winnings can be applied to the transponder according to the wishes of a casino customer. Alternatively, the player identification card could be used merely to identify the player and all betting could be accomplished using betting chips 164.
A still further possibility is to have participant identification using a fingerprint image, eye blood vessel image reader, or other suitable biological information to confirm identity of the user. Still further it is possible to provide such participant identification information by having the dealer manually code in the information in response to the player indicating his or her code name or real name. Such additional identification could also be used to confirm credit use of a smart card or transponder.
Alternative Presentation Unit Features
It should also be understood that presentation unit 100 can alternatively be provided with suitable display cowlings or covers (not shown) which can be used to shield display of card images from viewing by anyone other than the player. Such an alternative construction may be desired in systems designed for card games different from blackjack, where some or all of the player or dealer cards are not presented for viewing by other participants or onlookers. Such display covers or cowlings can be in various shapes and configurations as needed to prevent viewing access. It may alternatively be acceptable to use a player controlled switch which allows the display to be momentarily viewed and then turned off. The display can be shielded using a cover or merely by using the player's hands. Still further it is possible to use a touch screen display that would be controlled by touch to turn on and turn off. Similar shielding can be used to prevent others from viewing the display.
Alternative Embodiment Table Game System with Integrated Video Playing Card Displays
It should still further be understood that although a retrofit game system is possible, many implementations use displays which are mounted in an integrated fashion to the gaming table. Such displays may be provided adjacent to the betting sensors 121 and 131 in a configuration similar to that described above. Alternatively, the systems can have either touch screen display for added player or dealer input convenience, or other sensors which allow input of player decisions, betting, preferences, and options.
Various Display Images
When a dealer is used in a particular game,
During play of the dealer's hand, the dealer will typically hit on his hand if the hand count is 16 or less and stand if it is 17 or more. A option in setup of the system is to select according to casino procedures whether to hit or stand when the dealer has a soft 17 (ace and one or more cards which together total 17 when the ace is counted as 11).
Additional information can also be displayed on the dealer display 102 as may be desired by the casino or as provided by the manufacturer of the system. At the current time the dealer display is planned to display the card hand of the dealer and other information is presented on the player displays 103 as will be explained below in greater detail.
Example Player Display Images
The player station also includes a player station display 103 which includes a display border zone 105 which is part of the changeable display face and can vary from one display image to the next. The border zone lies within an outer display perimeter line 113 and an inner border zone boundary 114. The inner border zone boundary 114 is shown in dashed line to indicate its position but it is not highlighted in this view and other views except when the border zone is turned on as an indication of whether the player's hand has won or lost. This is preferably done by two different mechanisms to clearly indicate to the live participants at the table the outcome of that player's hand. The outcome indicating zone is also used to indicate with certainty whether the hand has been won or lost in a manner which can be recorded by any monitoring camera used above or near the gaming table. When the player has won, the border zone 105 is highlighted in green or other suitable color. The border zone is also flushed on and off so that a black and white camera can also clearly identify the outcome as a win.
When the player has lost, the border zone 105 is highlighted in red or other suitable color. The border zone is maintained red and is not flashed on and off in distinction to the flashing used to indicate a winning hand. The constantly highlighted border zone is identifiable by a black and white camera because of this constant highlighting.
When the hand results in a push (tie) neither the dealer nor the player win, and the border zone 105 is not highlighted or can be dashed or otherwise distinguished. This too can be easily discerned from a black and white or color camera monitoring the table from above. The absence of the border zone from being either flashing or being on constantly provides certain indication that a tie outcome has occurred.
At the time the player receives the ace shown in
Description of Control Software Flow Charts
The game processor controller 90 includes software which is used in the operation of the card game system 60. It should initially be understood that the particular software used will vary dependent upon the card game being played. The system described herein is being used for playing blackjack and so specific description in that context is provided. However, other games can be played and there will necessarily be modifications to the software and program routines to accomplish these changed games, or such may be required in connection with playing the wide variety of blackjack games played in casinos and card rooms everywhere.
The game processor includes operational modules for performing a number of data processing functions in connection with the currently implemented game, such as for example, blackjack card games. One significant function is managing modes between real playing cards 61, virtual playing cards, real wagering chips, and virtual wagering chips 70. Another significant function, when real playing card mode is selected, is processing card identity information transferred from the dealing shoe 80′. Whether the system 60 receives card identity information from the dealing shoe 80′ or generates the card identity information "from scratch" when in virtual playing card mode, another significant function is tallying the card array which forms the stack of virtual cards in memory, whether the virtual cards in memory are generated by the system 60 or scanned from real cards by the dealing shoe 80′. In one implementation, the system 60 tracks real playing cards 61 as dealt and handled by live participants and a dealer, if any, but in another implementation, the system 60 only uses real playing cards 61 at the dealing shoe 80′ to generate a virtual card array in memory, instead of using the real playing cards 61 during the remainder of the game.
Other important functions include: tallying the player hand counts; generating random number selections or listings; selecting virtual cards within a stack or selecting virtual cards which are to be distributed from the stack; monitoring a set of house rules or options to apply the correct rules during play of the game; monitoring player hand counts and cards dealt; providing basic strategy suggestions for use by the player in response to various different hands; and, communicating the various data processing sets and files between system components to achieve successful operation. Other functions and variations of the above are also indicated elsewhere in this document.
After any desired editing of the game rules in step 208, in one implementation a dealer initiates a new game by control command S, such as by pushing the deal control key switch 89 (
Step 215 involves dealing the two initial cards played in a blackjack implementation of the system 60 to the participating players and to the dealer. Such dealing involves generating random numbers which are used in selecting from the available cards contained in the set of cards defined to be the card stock. It further involves displaying the cards which have been dealt upon the displays in the manner and with the appearance described above, or some other suitable manner and appearance. Additional description of the two card dealing operation will be described below in connection with
The next step illustrated in
If surrender occurs then step 233 occurs which involves deactivating the surrendering player. The process can then be continued with regard to additional players who would either opt for surrendering or not surrendering.
If a player does not elect to double down, but instead proceeds to either stand or be hit, then step 260 is performed and such an election is made and the player performs by communicating such to the dealer. The dealer follows through by depressing either the stand or hit control keys 87 and 88, respectively. If another or hit card is dealt, then step 266 is performed and the game processor performs by analyzing the player's hand to determine whether the player has busted. If not, then the player is given another opportunity to obtain a hit card and the process repeats until the player elects to stand. In the last case the processor performs in step 263 by evaluating the final hand count and hand composition and then proceeds to address the additional participating players. If the player busts, then step 269 is performed in which case the dealer proceeds to the next available participating player or proceeds to step 271.
In step 271 the process continues by playing out the dealer's hand. This may involve hitting or standing in a manner similar to play by the players as explained above.
Step 274 is performed by determining which players have won or lost, and then such information is displayed on the displays 103, or 102, such as described hereinabove.
Step 295 involves displaying any casino names or logos or otherwise displaying an attraction display image, such as upon the player displays 102, dealer display 103, or shoe displays 81 or 82. Thereafter, the game processor performs in step 298 by looking for any wagers as indicated by sensors 121. Step 301 represents initiating the active player stations and querying for a response that the player display has been activated.
The sequence shown in
Prior to the dealing step, the processes according to this invention can also include a cutting step which can be performed either by the dealer or by a player. In one form of the exemplary system 60 the cutting is performed by displaying a simulated card stack on the first shoe display 81 and then having the player perform a touching of display. In this process the display 81 is a touch screen display and the touching step causes a location in the stack to be selected as the cut position. The cut card can then be specially displayed, such as by using a highlighting color. Such a process can also involve progressively moving the cut card as virtual cards are dealt.
An alternative cutting operation can be performed similar to the cutting just described but it is instead performed by the dealer touching display 81 rather than the player. This can be done in response to the dealer's judgment, or more preferably, the dealer can undertake such action in response to instructions from one of the players.
A still further alternative approach in performing a stack cutting operation is to have a selected player perform by instructing the dealer. The dealer in this alternative would be empowered to move a virtual cut card as it appears on the display. For example, during the cutting operation the stack image display 81 would function by displaying and highlighting a cut card. The dealer could then perform by moving or repositioning the cut card position within the stack by using one or more of the dealer control keys 85-89 which would become soft keys assigned to this repositioning function. The player performing the cutting judgment would then act by instructing the dealer as to the desired position of the cut card and the dealer would perform this repositioning as displayed on the display. The repositioning could be affected by adjusting the cut card position as needed in response to the instructions given by the player who is empowered with the cutting operation. After the cutting position is resolved, then the stock order is changed to reverse the two sections of the stock which are divided by the cutting position.
In various exemplary methods there is also a house or dealer cut card placing action which is advantageously made. This is made after the stack cutting operation discussed above. In this operation the dealer or other representative of the casino moves the cut card indicator to a position which is set by casino policy to be within a defined range. For example the cut card position might be midway in the stack. In such situation cards would be played until the cut card position is achieved and then the stack would be reshuffled.
After the above steps are performed, then the two initial card dealing sequence is performed. This processing if further illustrated in
In virtual playing card mode, Step 322 is followed by adjusting the simulated stack display in the first shoe display 81 by shifting the position of the cut card and moving it closer to the second display.
In virtual playing card mode,
Another form of shuffling is made available using system 60 which is usually not available when using real paper or plastic physical playing cards. This shuffling process is herein termed continuous random shuffle. In this shuffling process the order of distribution of cards from the stock is not predetermined before the hand is played. Instead the random number generator operates on the fly as needed when the game requires a card to be taken from the stack. The position from the stack is varied to produce the random distribution of potentially any card at any time. The entire set of virtual cards which make up the stack is maintained at all times, without removing cards which may already have been dealt in the same playing hand. This maintaining a set of all available cards in the stack achieves truer randomness than by reducing the stack set for removed cards. In any particular card assignment, the player can receive any of the possible cards. This procedure may be desirable in play of certain games or may be more attractive to the casino or players for objective or subjective reasons which become important.
Another shuffling or card assignment process which is contemplated by this invention is herein termed random balance shuffling. In random balance shuffling the set of available cards in the virtual stack is reduced by the assignment of prior cards dealt in the hand. For example, where the first card dealt is an ace of spades, and the stack is defined by the casino to be only one deck, then no other player in that hand can receive the ace of spades. In most casinos blackjack is played using stacks where there are multiple decks, for example six decks. In such situations, then there clearly would be additional aces of spades which might be dealt. However, the frequency of selecting the ace of spades after one or more other aces of spades have been already dealt in that hand does diminish. This should be contrasted to the continuous random shuffle wherein the expected statistical frequency does not change as cards are dealt.
Step 328 schematically represents the selection of the next card whether this is done on the fly using continuous random shuffle, or random balance shuffle. Alternatively, the selection process can be done with pre-ordering using the traditional shuffle.
The traditional shuffle does have a significant disadvantage which blackjack players may have noticed or experienced. This disadvantage is demonstrated by the situation where one player either stands or hits in a nonconventional manner, either by mistake or intent. Other players at the table often notice this apparent error, and as a result the next player or dealer would receive a different card than if the prior player had played his hand in a conventional manner. In some cases, the difference in cards can affect some or all who receive cards thereafter. In some cases, players become irate because of the realization that this mistaken choice by another player has cost the other players their bets and the wins which they otherwise would have enjoyed. This type of situation can be very upsetting and sometimes even leads to fights among the players. By utilizing the continuous random shuffle or the random balance shuffle procedures which can be accomplished with the system 60 in virtual playing card mode, there is no pre-ordering of the stack and no particular card can be said to have switched from one player to the next. In each of these procedures the random number generator goes through a selection process immediately prior to distribution of each card and thus the decisions of one player are not fairly attributable to some derogatory effect on other players.
The card selected by the above-described processes is then assigned to the next dealt card required and to the participant, whether player or dealer. Once assigned, then step 334 effects the displaying of the card on the player's display if it is a card assigned to a player. The game system also effects displaying a copy of the player's card on all screens when appropriate as explained above in connection with the player display images. The game then involves assessing whether the next action is with a player or dealer in step 340. This process repeats until all players have received their first card. Then a virtual card is assigned to the dealer in step 343. The first card to the dealer is dealt as a face-down card and is often referred to as the hole card. Step 350 indicates that the hole card of the dealer is dealt and displayed facedown. The process explained above repeats again for the active players and dealer until step 347 indicates that a second card has been received by the dealer.
After both initial cards are received by all participants, then the cards are assured in faceup condition in step 353 except for the dealer's hole card and copies of the cards are placed on other player's displays as previously indicated. Alternatively, initial cards may be dealt in a face-up condition. Thereafter process 221 proceeds to determine the players with blackjack hands.
If there is no dealer ace as upcard, then the game processor performs by assessing whether the player's hand has a pair in steps 432 and 435. If no pair exists, then the process continues by proceeding on with the consideration of whether the player wants to double down as shown in step 254 of
An insurance sequence shown in
If there are no additional active players, then step 561 proceeds on to a finish sequence shown in
Alternative Embodiment Gaming System
The presentation unit 100 advantageously includes ambient light sensors 132 (
Description of Alternative Control Software Flow Charts
1. Main Loop
1.1 System Initializes
1.1.1 Initialize Sound Card, init_sound( ) (Not Illustrated)
Call init_sound( ) to load *.wav sound files into the sound resources buffer. The sound card hardware is also initialized for volume and tonal adjustments. System further reads condition of switches (not illustrated) which sense and checks for secured conditions of access doors forming part of the processing module enclosure, similar to enclosure 91. As implemented, the enclosure includes a main door 95 (
1.1.2 Rules Editor, pit_boss_ed( ).
Step 715 entails checking to see if the key switch 83 is activated to enter the rules editor and whether the password required by the system has been provided for security reasons.
The house rules are recalled or modified with a call to file pit_boss_ed( ). The following parameters may be adjusted:
The rules editor is discussed in greater detail in following outline section on the RULES EDITOR. If the dealer or pit boss has not elected to enter the rules editor, then the system starts a new game at step 717.
1.1.3 Random Number Generator (RNG) Seed Data, get_seed.sub.—data( )
This initialization step is illustrated at step 718 of
1.1.4 Game Process Tables, clear_the_deck( ), hand_in( ), make_card_tray( )
Information about the players and the cards that are dealt are contained in memory tables which are first cleared out before a new game. A call to clear_the_deck( ), to hand_in( ), and make_card_tray( ) achieve this function of the initialization. The casino or other house rules and settings are represented in steps 719 which can also be approached through the rules editor.
1.1.5 Graphics Files, transfer( )
The initialization process also advantageously includes loading many graphics images that are displayed during game-play are facilitated by a graphics engine which is initialized with a call to transfer( ).
1.2 Display House Logo, send( )
The house logo graphics is sent to the respective LCD displays.
1.3 Wait for Dealer to Press Deal Key, shoe( )
Step 298 determines the presence of a wager over the bet sensors 121 and indicates an interested player. When the dealer presses the deal key on the shoe, all wager sensors which detect a wager will communicate the information back to the rules program. Player positions 1-6 which have wagers over the sensor will be counted as active players. The system reads the keypad on control 80 in step 209.1 and makes a decision in steps 209.2 and 209.3 indicating when the dealer presses the deal keypad cards will then be dealt according to the deal sequence selected in the rules editor. In step 708.1 the system again checks the security of the controller doors and chooses between a service mode condition 720 or continued operation carrying onto the top of
The top of
1.4 Deal Two Cards, two_card_deal( )
In virtual card mode, step 215 represents the operation of dealing or assigning the initial two cards of blackjack to each participant: Beginning with the first active player to the dealer's left hand, cards will be dealt one at a time until all players have received a card. The dealer then receives his first card, which may be face up or face down, depending on the house rules selection. The sequence is reported until all active players hold two cards. One of the dealer's cards will be face down. A call to two_card_deal( ) accomplished this. In the implementation of this action the speed of dealing is subject to adjustment of a speed parameter implemented when the rules are loaded. Thus the action can be relatively fast or slower as may be appreciated by different groups of participants.
1.5 Find BlackJack Hands, find_bj_hands( )
After the initial two cards are dealt, a search can be made for all hands that may hold blackjack. A status table can be updated with this information. The find blackjack hands sequence is illustrated in
1.6 Insurance Sequence, insure_seq( )
If the dealer's face card is an ACE, insurance is offered at this time. This is represented in
1.7 Dealer Holds BlackJack find_bj_hands( )
If the dealer does hold BJ as determined by step 738, the finish sequence 739 is entered wherein all active hands are compared to the dealer's. Any hand which also holds blackjack (BJ) is determined to be a PUSH. All others are NO WIN,
1.8 Play Hands Sequence, two_card_play_seq( )
A call to two_card_play_seq( ) begins the cycle through which all active hands are played out as assessed by step 747. This has a beginning with the first active hand to the dealer's left. Additional hands are recognized in step 748. Through this cycle split hands are created from pairs of like cards, depending upon house rules. Double down is a choice a player may have, depending on house rules. A player may hit or stand as they like. These options are generally shown at step 746 of
Splits are permitted or not permitted as the rules define. If permitted, then step 779 determines whether the hand is eligible for splitting by have a pair. The player is presented with the decision in step 780 and the input response is represented by step 781. If split then the system creates the second hand in step 782 and deals a first card to the first of the split hands in step 783. Reconsideration and revised strategy information is made and then displayed as illustrated by step 784.
1.9 Play Dealer Sequence, play_dlr_seq( )
When all active player hands are played out, a call to play_dlr_seq( ) will begin the cycle through which the dealer draws cards until a hard count of 17 is reached. Whether he hits on a soft-17 is set in the rules table.
1.10 Finish Sequence, finish_seq( )
The final win/lose determination is made here against the hard/soft counts of each active hand at shown at step 739 with respect to the dealer's. A call to finish_seq( ) performs this process.
1.11 Cut Card Reached, shuffle_tray( ).
In virtual card mode, there are always enough cards in the deck to complete a game after the cut-card is located. When a game has completed and the cut card was located during play, a reshuffling will be done with a call to shuffle_tray. This is illustrated at steps 730-732.
1.12 Update Game Records, write_game_data( ), up_deck_rec( )
When the game is finished, vital information about the game will be written to a disk file and stored. A call to up_deck_rec( ) writes the data. The state of the RNG is written to a separate file for future recall within the function write_game_data( ).
This is represented by step 751 of
2. Random Number Generator
2.1 RNG Engines
In virtual card mode, step 718 can be performed by two RNG's which are employed in the production of random numbers. The first generator is an ANSII standard function that is resident with the compiler. It is a pseudorandom generator which yields 32-bit integers. The second generator comes from George Marsaglia at Florida State University moth department, and is known as The Mother of All Random Number Generators, or "Mother" for short. It returns 64-bit random numbers.
The 32-bit generator is provided a chaotically produced seed in order to return a randomly generated seed for "Mother." The second seed is fed once to "Mother" and from that time onward the generator is always running on a set of numbers saved from game to game.
2.2 Seeding
A primary seed is obtained with a call to init_seed( ) when the software is initially powered up. Here, a 32-bit unsigned number is allowed to increment through a modulo-32-bit cycle until a key is pressed. The state of this variable, a_seed, is sent to the 32-bit RNG as a seed, and a random number is produced, b_seed The variable, b_seed, is sent to "Mother," from which a dual ten element array is constructed. The array contains state data for which new random numbers are generated. The array contents are different with each new number.
2.3 Saving the State of the RNG
Following each game, the dual ten-element arrays are saved in a file write_game_data along with the initial seed value. When a new game is initializing, the file is read and the array values are reinstated into Mother. The RNG then proceeds as if it had never been shut down.
3. Card Tray
A serial card tray is built at the start of each new game series as illustrated by step 723. The tray size is determined by the number of decks specified in the house rules settings. To fill the tray, a call is first made to make_card_tray( ). Within this function the RNG is queried for new cards, the conditions being that acceptable card numbers cannot be 0 or any number greater than 52. Also, a card number (1-52) may be used only up to the number of decks that are allowed. For example, if 12 decks are used, the card number 13 may be used only 12 times while filling the array.
4. Shuffle Mechanism shuffle_tray( )
4.1 Deal Sequences
In virtual card mode, three schemes are available for shuffling cards, depending on house rules setting variable RULE_deal.
4.2 Traditional
This scheme is illustrated by step 724 and emulates a randomly filled card tray which is continually shuffled until the deal/cut key is pressed by the dealer. After the key is pressed, cards are drawn sequentially through the tray. The tray is not shuffled again until the cut card is located. The mechanism for shuffling swaps randomly selected pairs of cards from the tray. The process continues until the deal/cut key is pressed. A recorded sound file of shuffling cards is played through the speakers while the cards are shuffled.
4.3 Random Balance
This scheme is shown by step 725. The card tray is filled once, as with the traditional scheme, but with a random balance shuffling scheme all cards following the drawn card are shuffled every time a card is drawn. Cards are drawn sequentially through the tray, however with each drawing the balance of cards is shuffled by swapping randomly selected cards. While a player waits to decide his next move, the deck is shuffled. A shuffle sound file is played while he decides.
4.4 Full Random Balance
This scheme is shown by step 726. The card tray is filled once, as with the traditional scheme, but with a full random balance shuffling scheme the entire tray is shuffled every time a card is drawn. Cards are drawn randomly from the tray. While a player waits to decide his next move, the deck is shuffled. A shuffle sound file is played while he decides. This scheme precludes the need for a cut card.
5. Deal Sequences card_select( )
5.1 Traditional
Cards are drawn from the card tray sequentially through the deck as illustrated by steps 731. An index, card_tray_indx, is incremented for each card drawn from the tray, card_tray[card_tray_indx]. When the cut card is encountered the tray will be shuffled at the close of the current game.
5.2 Random Balance
Cards are drawn from the card tray sequentially through the deck. An index, card tray indx, is incremented for each card drawn from the tray, card_tray[card_tray_indx]. When the cut card is encountered the tray will be shuffled at the close of the current game. The balance of cards following the currently selected card is shuffled while a player waits to decide his next move.
5.3 Full Random Balance
Cards are drawn randomly from the domain of cards in the card tray. With each card that is drawn, the entire tray of cards is shuffled.
6. Play Hands Sequence two_card_play_seq( )
6.1 Overview
The two card play out sequence is shown starting at step 771 of
6.2 Data Structures
Status information about the players and their hands can be contained in a data structure:
The record of cards dealt to each hand is contained in:
Both hard and soft count is held for each hand in:
See section 12.0 for a detailed description of the data structure.
6.3 Sequence
For each active hand, the sequence begins with two cards having been dealt to the base hand as indicated by steps 774 and 775. The hand is evaluated at step 776 and the most appropriate strategy is returned following a call to strategy( ). The strategy is calculated against the dealer's face-up card and the player's soft and hard count. The rules table is consulted before a strategy is finally returned. Thus, if a hand holds a pair and a split would otherwise be recommended, a maximum allowed split count of zero would preclude the recommended strategy of splitting. Hit or stand might be recommended instead. The strategy is sent to the player's screen and displayed graphically. Through the course of play, the player may choose to split his hand, double-down, hit, or stand. If the hand holds only one card, the result of a split, a second card is automatically dealt.
6.4 Split Hands split_seq( )
If the hand holds a pair of like cards and the player has not exceeded the allowable limit of splits, then a split sequence is entered at step 778 with a call to split_seq( ). In this sequence the player may choose to split his hand step, double-down at step 787, hit or stand at step 792. This general decision is also represented at steps 747 and 746 of
6.5 Double Down double_down( )
If the hand satisfies the restrictions for a double-down and the player chooses to double-down, a call to double_down( ) will enter that sequence. A third card is automatically dealt the hand at step 788, the hand is evaluated at step 789, and the sequence terminates at step 790. The next active hand is then played out starting back at step 772.
6.6 Hit/Stand Loop Within two_card_play( )
Provided the hand is active, it has not busted as determined at step 795, and double-down was not chosen, a loop is entered at step 791 that allows the player to accept hits or to stand at step 792. The loop is terminated when the hand either busts or the player chooses to stand. Following each hit, a call is made to deal_card_seq( ) wherein a card is drawn from the tray. Next, a call to evaluate( ) computes both hard and soft count for the hand. The count and card type are sent to the active player's display. For every decision, a new strategy is formulated and displayed until the hand terminates.
6.7 Exit from Loop
The sequence of playing out active hands terminates when the last active hand has been played out at step 796. A message signaling the terminus is sent to the graphics module with a call to send( ). Control returns to the main( ) function.
7. Split Sequence split_seq( )
7.1 Entry Test
When the split sequence is entered at step 778 with a call to split_seq( ), a test determines whether a hand may be split. A pair of like cards must first be acknowledged. House rules govern the pairing of face cards. If all face cards are equal to 10, (RULE_face=0) then any pair of face cards is considered a pair. Conversely, if only like face cards are a pair (RULE_face=1), then, for example, only two Jacks or two Queens can enable a split. A second test 779 examines the number of splits already active. If the count does not exceed house limits, as set in RULE_splits, then the player may choose to split his hand. A final test is that variable repeat is 1; a choice not to split resets it. His choices at this point are split, double-down, hit, or stand. If split is chosen, then the sequence is entered according to the following test for splits.
The Boolean test for splits is:
like face cards only
Card One Value=Card Two Value;
the pair has equal face value
first card is an ACE
Card One Type=Card Two Type;
the pair has equal type
the hand may split again
pairs of 10's may NOT split
Card One is not b 10;
hand holds two cards
hand can not have split
split only one pair of ACES
7.2 Sequence
The split count for the player is first incremented, p_info[player].num_splits. The top card is moved to the dealer's left. A new card is dealt to the card on the left. This pair remains hand 0, while the single card on the right becomes hand 1. A new strategy for hand 0 is formulated and returned to the calling function, two_card_play_seq( ). The hand is played out in two_card_play_seq( ), and when the next hand becomes active, hand 1, a second card is dealt. If this hand also holds a pair, the split sequence is entered again.
Hand 1 is dealt a second card at step 783 and the hand is thereafter played out. This process continues until further splits are prevented and all hands are played out.
7.3 Algorithm
S=split_num, N=hand_num (of the hand that is splitting), X=S−N−1
The algorithm for creating new hand is:
[hand_num][card_pas]: for (i=0; i<x; i++){[s−i][0]=[s−(i+1)][0]}
Always: [N+1][0]=[N][1]; new hand, card 0 receives old hand card 1
Level H0,S0: In the example above, hand 0 holds a pair, A1,A2. No splits have formed yet, so S=0. N (hand #)=0, and the variable X=S−N−1; X=−1. Card 0 of the pair is A1, card 1 is A2. Level H0,H1,S1: The pair A1,A2 is split, A1 receiving new card A3, and A2 moving to the right to form H1. Split becomes S1, N=0 (hand0 is splitting), and X=1−0−1=0. The algorithm loop:
The process continues in this fashion.
8. Double Down Action
8.1 Overview
With a call to double_down( ) from two_card_play( ), is represented by step 785 which determines whether such a play is permitted under the rules of play. A player decision to double down is first qualified by step 786 and then implemented in step 787. The option to double-down is granted by permission where house rules govern the qualifying hand. The common qualifier is that the hand hold only two cards. When permission is granted, the player's motion to double-down is received by the dealer and step 788 results in issuing a third card. The hand is evaluated at step 789 and flow proceeds to the next active hand at step 790. If the hand was previously split, house rules may prevent a double-down. The governing rules are summarized below.
8.2 Any Two-Card Hand
If the card count for the current active hand is two, permission is granted.
8.3 Hard Two-Card Hand Without Aces
If the hand holds two cards, and neither card is an ace, permission is granted.
8.4 9, 10, 11 Hands
If the hand holds two cards and the hard/soft count is 9, 10, or 11, permission is granted.
8.5 10, 11 Hands
If the hand holds two cards and the hard/soft count is 10 or 11, permission is granted.
8.6 11 Hand Only
If the hand holds two cards and the hard/soft count is 11, permission is granted.
8.7 Return from Function
The function is passed not only player/hand data, but previous decision codes made in two_card_play( ) as well. For example, if the hand had previously split and the new hand wished to double-down, that decision is passed from split_seq( ) back to two_card_play( ), and on into double_down( ) at step 785. If permission is granted in double_down( ), then a third card is dealt. After action is taken in double_down( ), the decision code is passed back to the calling function, two_card_play( ). If a double-down was taken, the hand terminates in two_card_play( ). Otherwise, the hand is played out.
9. Play Dealer Sequence play_dlr_seq( )
This sequence is illustrated by
9.1 Dealer has Blackjack
If the dealer has a blackjack as checked by step 803, then there is no need to continue and step 804 branches action to 805 and the game is returned to scan winner's step 750 of
9.2 Evaluate Dealer Hand
A call to evaluate( ) the dealer hand at step 806 determines both hard and soft count for the dealer's two-card hand. Further decisions are based upon this evaluation which is accomplished as illustrated by steps 807, 808, 809, 810, and 811.
9.3 Hard Count Greater Than 16
If the dealer's hard count exceeds 16 he must stand. If the hard count is less than 16, a play loop is entered.
9.4 Play Out Loop
The loop exits when the hard count exceeds 16. If the dealer's hand holds a soft 17, house rules stored in variable RULE_soft determine whether he hits or stands. If he stands on a soft 17, the loop exits and the sequence terminates. If he hits on a soft 17, a card is dealt at step 812 and the hand is re-evaluated by step 806.
If the hand is not soft, cards will be dealt until the hard count exceeds 16, at which point the loop exits at step 809. Play proceeds to the finish sequence 749 et seq.
10. Find Blackjack Hands find_bj_hands( )
Following the two-card-deal sequence, a call to find_bj_hands( ) examines each active hand for the presence of an ace and a 10 or a face card. Any player that holds a BJ receives a status code "BJ" for that hand. This status is different than an ACTIVE status which is necessary for processing through the two-card-deal sequence. Is
11. Finish Sequence finish_seq( )
11.1 Hole Card hole_card( )
The first step in this sequence is to reveal the dealer's hole card with a call to hole_card( ) at step 802. If RULE_hole is either first or second settings, then the hole card will be turned over. If, however, both cards are placed face up (HOLE_card=2), then no action is taken.
11.2 Scan Players scan_players( )
A call to scan_players( ) starts the process of translating active hands into final score determinations at step 739. If the hand status is BUSTED, the final score is BUSTED. If the hand did not bust, the hand's best count is compared to the dealer's best hand. If the dealer's is better, the hand is NO WIN. If the hand beats the dealer's, it is WIN. If the hand ties the dealer's, the score is a PUSH. If the hand is a BJ and the dealer's is not, the player receives BJ; if the dealer also has BJ, the hand is a PUSH.
11.3 Display Score
The final determination is sent to the graphics engine which displays the appropriate border and WIN/LOSE graphic for the hand.
12. Strategy Table
12.1 Considerations
Before an appropriate strategy can be formulated, several factors must be considered. They are listed below, and each pertains to the player and his current hand information:
12.2 Table 1: Ordinary Hands that are not Pairs nor Hold an ACE
In order to locate a strategy here, several conditions must be true:
a. Card One must not equal Card Two, unless no more splits are permitted or if card count is >2
b. Neither Card One nor Card Two may be an ACE unless the card count is more than two. First, the better count of the hard/soft hands is computed. The column is found by subtracting 4 from the hand count: COL=COUNT−4. Second, the row is found by subtracting one from the dealer's face card: ROW=dIrFACE−1. Then, table 1 is indexed and the proper code is retrieved. See the tables below
12.3 Table 2: Two Card Hands that Hold an ACE
Go here if the card count is two, and one of the cards is an ACE but not both. The column index is taken from the card that is not an ACE. The index=COL=card val−2. If the request for a strategy originates within the HIT/STAND loop of two_card_play_seq( ), and the strategy is found to be 2 (double-down), the strategy will be modified to HIT. The row index is found by subtracting one from the dealer's face card: ROW=dIrFACE−1.
12.4 Table 3: Two Card Hands that Qualify as a Pair
For this table to be used, the card count must equal two, the two cards must be like values (determined by house rule RULE_face_cards), and additional splits must be permitted. The column index is calculated by subtracting 1 from the value of one of the cards: COL=val−1. The row is found by subtracting one from the dealer's face card: ROW=dIrFACE−1.
12.5 Strategy Table Codes
2, 2
3, 3
4, 4
5, 5
6, 6
7, 7
8, 8
9, 9
10, 10
The cells of the tables hold codes that indicate decision moves. The codes are: H=hit, S=stand, D=double, P=split
13. Player Hand Information
Information about each player position and each active hand is maintained in a structure p_info[player].
13.1 Structure: p_info[player]
The typedef below shows the structure of p_info:
typedef struct
int card[RULE_splits][MAX_HAND]; // sequence of played cards
int num_splits; // # times hand split < RULE_splits
int num_cards[RULE_splits]; // # cards in each split
int count[3][MAX_HAND]; // hand count[0] hard,[1] soft, [3]best
int status[RULE_splits]; // 0=no player, 1=active, 2=bust
3= card dealt face down 4=two cards face down, 5=blackjack
} hand_info;
13.2 Sub-Level: card[RULE_splits][MAX_HAND]
The two fields are indexed by variables: card[hand_num][card_hold]. This sub-level contains a record of all the cards dealt to a [player]'s hands. The number of hands is limited by RULE_splits, as set in the house rules. A particular hand is pointed to by hand_num. For each hand, a maximum of MAX_HAND cards may be dealt to that hand, currently set at 11. A discrete card is indexed by card_num. For example, p_info[3].card[0][5]=4 says that player 3's base hand(0) holds an ACE(4) in card position 5.
13.3 Sub-Level: num_splits
This is a simple integer that indicates how many times [player]'s hand has split.
13.4 Sub-Level: num_cards[RULE_splits]
This array holds the quantity of cards that has been dealt to each hand of an active player. The number of hands is limited by RULE_split, and indexed by num_cards[hand_num]. For example,
Indicates that player 2's hand #2 holds no cards.
13.5 Sub-Level: count[COUNT_TYPE][RULE_splits]
A [player]'s hand can have a soft count and a hard count if ACEs are present. The indices into [COUNT_TYPE] are: 0=HARD, 1=SOFT, 2=BEST (the better of HARD or SOFT). The field [RULE_splits] is indexed by [hand_num] which points to a specific hand. For example:
This indicates that player 5's base hand (0) holds a soft 17.
13.6 Sub-Level: status[RULE_splits]
Every player position 1-6 (where 0 is the dealer) has at least one hand assigned by default, hand 0 (the base hand.) As a game progresses every hand is assigned a status which is used to identify decisions for which choices may be possible. Discrete hands are indexed by status[hand_num]. The status codes are listed:
13.7 Score Card
Final WIN/LOSE determination is registered in the array: score_card [MAX_PLAYERS] [MAX_SPLITS+1]
The first field [MAX_PLAYERS] is indexed by player, and points to a discrete player. The second field, [MAX_SPLITS+1], is indexed by hand_num, and points to a discrete hand. For each active hand, a score code is ultimately assigned, listed below:
14. Card Calculation Card_calc( )
14.1 Hard Count
Any card may have an absolute face value from 1 to 10. Aces count as 1, and face cards are 10. Since there are four of every type in a deck, the range of card types progress in groups of four, beginning with ACES, which are 1-4. All ACES return a value of 1 when the argument ace_num>1. This yields a hard count.
14.2 Soft Count
When a soft count is desired, the first ACE counts as 11. The argument ace_num must be 1 in order for the function to return a value of 11 when the card type is 1-4. After a second ACE is encountered in card[hand_num][card_hold] the ACE count increments and subsequent calls to card_calc( ) will return a value of 1 for an ACE.
14.3 Card Type card_type( )
When house rules (RULE_face=1) require that pairs of face cards be of similar type, a call to curd_type( ) will return a character that corresponds with the card type. For example, a queen is 'Q' and a 10 is 'T'.
15. Record of Game Data
15.1 Game State Data write_game_data( ), get_seed_data( ), get_rules_data( )
State information about the last played game is written/read from/to a ram-disk file, GAME_SET.DAT. The function that reads the file is get_seed_data( ) and get_rules_data( ). When a game session concludes, the file is written by a call to write_game_data( ). Three categories of data is written to this file:
1. Initial seed value; once obtained, it should never change unless the file is corrupted
2. RNG (Mother) state tables; two ten-element arrays of unsigned 32-bit numbers hold the terminal state of the RNG from the last access of a number
3. House Rules; the last revision or update to the house rules are kept on file.
15.1.1 Write Game Data write_game_data( )
Writes all the data to the file GAME_SET.DAT.
15.1.2 Get Seed Data get_seed_data( )
This function is called while initializing a new game. If the file GAME_SET.DAT cannot be opened or located, the user is prompted to provide a new start-up seed by pressing a keyboard key. After the seed is obtained it will be subsequently written back to this file. When present, a new seed is unnecessary, and the function proceeds to retrieve the internal state data for the dual ten-element arrays used within the RNG "Mother." The arrays mother1[10] and mother2[10] are filled with the same numbers they held before the machine was shut down the last time.
15.1.3 Get House Rules get_rules_data( )
All of the house rules settings are stored in the file GAME_SET.DAT at the conclusion of a game session. To facilitate the pit-boss in reinstating these rules, they are read from file into the game settings and become the default rules. They may be altered in the rules editor (see pit_boss_ed( )). The parameter TABLE=0 from the above listing refers to which of the five tables were used as the basis for setting the current rules.
15.2 Game Hand History game_his( )
At the conclusion of every game, information pertaining to the hands that were actively played is updated in the file GAME_OVER.DAT. An example is printed below:
15.2.1 Version
The version of source code rules-21.c is found at the beginning. A short list of house rules governing the game are listed after GAME CHAR:. The number of games used to compile the data is given as well as the RNG used to select cards. The date upon which the game was played is printed.
15.2.2 Player/Card Data
Under GAME LOG, some total values are listed. Cards Dealt refers to the quantity of cards dealt to active hands, including the dealer's. Cards Rejected is a count of all the cards that did not qualify for the initial filling of the card tray. Cards Accessed is the sum of the two quantities above.
15.2.3 Card Histogram
The four arrays under CARD DEAL LOG: DISPLAY BY QTY DEALT indicate the distribution frequency of cards by card type, where type is a number from 1 to 52. This is repeated again, by percent usage.
15.2.4 Card Tray Data
The card tray from which cards are selected is built into an array whose is length is the number of decks times 52 cards The first 52 cards of this initial tray are printed as "Card Tray Init." Throughout game play the card tray is shuffled, and the final state of this tray is printed for comparison as "Card Tray Final."
15.2.5 Card Tray Index
If either Traditional or Random Balance access to the card tray is used, an index is incremented with each access. The final state of the index is printed.
15.2.6 Player Hand Data
The sequence of cards dealt to each player is printed by card type.
16. Rules Editor pit_boss_ed( )
16.1 Pit Boss Ed
16.1.1 Initialize Rule Tables init_house_rules( )
This is the entry function into the module PIT_BOSS.C. Its first task is to initialize the house rules with a call to init_house_rules( ). House rules are either read from disk or they are generated from default table A.
16.1.2 Make the Exec Screen
The executive screen is built with a call to mak_exec_scrn( ). This becomes the pit-boss's graphical entry point to the game session. The list of items presented allows him to inspect the current default rules settings or make changes to any of five pre-set tables. This choice will vector to the functions set_table( ) and edit_table( ) where changes to any of the tables is possible. He may also to choose to dump data files to an I/O port or make adjustments to physical settings, such as speed or light sensor readings. If a brief review of instructions and overview of the software is necessary, he may call up an on-line document from item Read More About The Instructions. When he is ready to commence with the game session he selects EXIT Screen Now. This restores the default graphics mode and frees up any allocated memory. The editor exits and the rules portion of the game is entered.
16.2 Init House Rules
If the file GAME_SET.DAT can be found and read, all of the house rules will be read into the structure rule_save (below.) The table pointer, tab_indx, is set to point at the last table used to set the rules. If the file cannot be found the default settings are taken from Table A with the equate of variable: tab_indx=TAB_A.
int num_splits; // this sets MAX_SPLITS, must be <= 3
int dbl_splt; // permission to split on double-down
int splt_10 // permission to split pairs of 10's
int splt_ACES // 0 = no play out on split ACES; 1=play out hands
int face_cards; // 0 = loose, 1 = strict
int num_decks; // up to 12 allowed
int deal_seq; // TRAD = 0; RAN_BAL = 1; FULL_RAN_BAL = 2
int soft_17; // STAND_17 = 0; HIT_17 = 1
int double_down; // 2_CARD = 0; HARD = 1; 9_10_11 = 2;
int surrender; // YES_SURR = 0; NO_SURR = 1
int hole_card; // HOLE_FIRST =0; HOLE_SECOND = 1;
int game_table; // points to table last used to define rules
} r_table;
When the source of the rules has been identified the next task is to build a screen with graphics tools and then plug in the rule settings. A call to set_table( ) builds all but the settings portion of the screen. Before they are filled in, a working image of the screen is saved in buf_all_B[tab_indx] where tab_indx points to one of five tables that will be used to complete the settings column. In a field that is 640.thrfore.480 pixels square, the buff_all_X images are advantageous arrayed from 50,50 to 590,425.
Next, an image of the complete screen is desired. This will be saved in the buffer buf_all_C[tab_indx]. At this time both of the above images is identical. The whole screen image is defined in an array from 0,0 to 640,480.
When the current house rules are to be inspected a specialized screen will be built from current settings.
The image is saved in a buffer buf_save_rules and when recalled will always display the current settings. A call to make_save_screen( ) will achieve this. Since there are five rules tables plus another current default table, a six-element array holds information regarding the initialization of these tables. A '1' indicates the table is done; '0' means it has not been built. Here, table_done[5=1 completes the current rules table, and the program returns to pit_boss_ed( ).
16.3 Set Table Set_table( )
Use this function to construct a specific table A-E. The working interior is a space defined by an array between 50,50 and 590,425. The screen title is RULES TABLE X, where 'X' is a letter A-E. Three columns are headed with labels:
The RULE TYPE column is filled in with the set of parameters for the house rules. For the DEFAULT settings that correspond with the indicated table A-E, a pair of tables, rule_table_opt[ ], rule_table_opt[ ] in pit_tab.h are indexed to fill text buffer buf_opt[0-7] with the correct default value. The option buffers are then written respectively beside each RULE TYPE parameter beneath DEFAULT.
For each RULE TYPE parameter an image box is created for the purpose of scrolling the list with a reverse-video box enclosing each item. These image buffers are buf_rule_A-G.
When the screen is built with two completed columns and three column headers, the screen image is saved in an image buffer, buf_all_A, which has no selected options under SELECTED. It is defined by an array between 50,50 and 590,425.
The two images, buf_all_A and buf_all_B hold identical information now. As the table's selected option column begins to fill up, buf_all_B will hold a running memory of the changes, whereas buf_all_A will remain empty beneath that column.
16.4 Edit Table edit_table( )
The purpose of this function is to complete the building of a table[tab_indx] by filling in the SELECTED column with either default values, or values saved in game_set.dat for this particular table. If default values are to be used, the function set def_rules (i.e. def_splits( ) will find the default values in tables rule_table_opt[ ], rule_table opt[ ] and write them beneath the header SELECTED. When done, the working image is saved to image buffer buf_all_B[tab_indx]. Several hot keys are listed below the screen in order to save/revise the working screen. Key F1 allows the table to be edited. F2 accepts the current settings, and F3 restores any default settings that were changed. The screen exits upon the pressing of F2, after which the entire screen image is saved in buffer buf_all_C[tab_indx]. If the table requires editing, F1 will effect a call to edit_item( ) where items in the parameter list can now be changed.
16.5 Edit Item edit_item( )
A new set of hot keys are listed below the working screen in order to edit the screen. The up/down arrows will scroll the RULES column items by highlighting the selected item. A right-arrow key or a CR will cause that item to be opened for editing. If at any time the operator is satisfied with the settings, F2 will accept the screen and permit further choices. Following any change, the updated screen will be written to image buffer buf_all_B[tab_indx]. Prior to exiting the screen, the entire screen is saved to image buffer buf_all_C[tab_indx].
When a rule parameter in the RULES column is highlighted and waiting for action, control is passed to function go_edit( ) which serves key recognition and follow-through action upon edit_item( ). When the up/down arrow keys are pressed, an array which holds the eight items is either advanced or decremented in order to comply with the arrow. The counter up_it is always incrementing, and modulo-8 division provides a remainder which is used by the switch to index into the correct item. When the up-key is pressed, a small array up_it_next[which_ed] revalues the pointer, up_it to the prior element.
If the ESC key or the right arrow key are pressed, the highlighted item is to be edited. A return from go_edit( ) will enable the calling of the editing function for that discrete item. For example, to edit item NUMBER OF DECKS a call is made to ed_decks( ).
16.6 Edit Splits ed_splits( )
The number of splits allowed is set here. A dialogue box is first displayed in the SELECT column. Text "Type the number of splits:" is displayed. A conio.h function getch( ) is used to retrieve the typed character, which is done as soon as a character is typed (not entered.) A limit of 3 is imposed, and if the character '4' is typed, '3' will be displayed. The choice above is stored into the rules structure rule_table[tab_indx].num_splits, where tab_indx points to one of the five tables A-E. The function returns to ed_item( ) where the rest of the column is redisplayed and the image buffer buf_all B is updated for this table.
16.7 Edit Face Cards ed_face( )
Next, "Type face Split Options: (0) Loose, All Equal to 10 (1) Strict, Pairs of Like Face Only" is display. See Splits, sec.7, for details about these options. When the user types a character '0' or '1' it is read and the full text selection is displayed. If an out-of-bounds character is typed, the default value for this table is used. This choice is stored into the rules structure rule_table[tab_indx].face_cards, where tab_indx points to one of the five tables A-E. The function returns to ed_item( ) where the rest of the column is redisplayed and the image buffer buf_all_B is updated for this table.
16.8 Edit Double-Down on Split ed_dbl_splt( )
This rule pertains to a split hand and the option of accepting "double-down" upon that hand. Where "(0) No" is select, a d-down may not be played on a hand that has split. Text "Double-Down On Split Hand? (0)No (1)Yes" is displayed in the box. A single typed character completes the selection. If an out-of-bounds character is typed, the default value for this table is used. The choice is saved in rule_table[tab_indx.dbl_splt, where tab_indx points to one of the five tables A-E. The function returns to ed_item( ) where the rest of the column is redisplayed and the image buffer buf_all_B is updated for this table.
16.9 Edit Split 10 Pairs ed_splt.sub.—10( )
This rule pertains to a split hand and the option of splitting a pair of 10's. Here, house rule RULE_face applies (see sec. 16.7, above). A dialogue box is written with the text "Split '10' Value Hands? (0)No (1)Yes" A single typed character completes the selection. If an out-of-bounds character is typed, the default value for this table is used. The choice is saved in rule_table[tab_indx].splt.sub.—10, where tab_indx points to one of the five tables A-E. The function returns to ed_item( ) where the rest of the column is redisplayed and the image buffer buf_all_B is updated for this table.
16.10 Edit Split Aces ed_splt_ACES( )
This rule pertains to a split hand and the option of splitting a pair of ACEs. A dialogue box is written with the text "Play Out Split ACES? (0)No (1)Yes". If "(1) Yes" is selected, a pair of ACEs may be split and each new hand played out as normal. However, if "(0) No" is selected, then each ACE automatically becomes the first card of new hand H0 and H1, respectively, and a second card is dealt to each hand. Both hands are required to stand, and play proceeds to the next active player. A dialogue box is written with the text "Play Out Split ACES? (0)No (1)Yes", and a single typed character completes the selection. If an out-of-bounds character is typed, the default value for this table is used. The choice is saved in rule_table[tab_indx].splt_ACES, where tab_indx points to one of the five tables A-E. The function returns to ed_item( ) where the rest of the column is redisplayed and the image buffer buf_all_B is updated for this table.
16.11 Edit Decks ed_decks( )
Here the parameter that sets the number of decks in use is offered for edit. First, a dialogue box is displayed. Text "Number of Decks: (12 MAX) (TYPE 2 digits, or ENTER 1 digit)" is displayed. If a single digit quantity is used, the character must be entered. If a two-digit number is used, the entry is accepted upon typing the second digit. If an out-of-bounds character is typed, the default value for this table is used. Next, the full text selection is displayed. The choice is saved in rule_table[tab_indx].num_decks, where tab_indx points to one of the five tables A-E. The function returns to ed_item( ) where the rest of the column is redisplayed and the image buffer buf_all_B is updated for this table.
16.12 Edit Deal Sequence ed_deal( )
Three options are offered for dealing cards: traditional, random balance, full random balance. First, the dialogue box is displayed. Text "Type Deal Sequence: (0) Traditional (1) Random Balance (2) Full Random Balance" is display in the box. A single typed character completes the selection. If an out-of-bounds character is typed, the default value for this table is used. The choice is saved in rule_table[tab[indx].deal_seq, where tab_indx points to one of the five tables A-E. The function returns to ed_item( ) where the rest of the column is redisplayed and the image buffer buf_all_B is updated for this table.
16.13 Edit Soft 17 ed_soft( )
When the dealer's hand is played out, his soft count may equal 17 if an ACE is present. House rules may permit a hit, or they may enforce a stand. The two choices are offered here. First, the dialogue box is built.
The text is displayed: "Type Dealer Soft 17: (0) Stand (1) Hit". A single typed character completes the selection. If an out-of-bounds character is typed, the default value for this table is used. Next, the full text selection is displayed. The choice is saved in rule_table[tab_indx].soft.sub.—17, where tab_indx points to one of the five tables A-E. The function returns to ed_item( ) where the rest of the column is redisplayed and the image buffer buf_all_B is updated for this table.
16.14 Edit Double Down Options ed_doub( )
This selection determines what restrictions apply to hands that wish to double-down.
Text is displayed: "Type Double Down Option: (0) 2 Card Hands (1) Hard 2-Card Hands (2) 9, 10, 11 hands (3)10, 11 Hands (4)11 Hands Only". A single typed character completes the selection. If an out-of-bounds character is typed, the default value for this table is used. Next, the full text selection is displayed. The choice is saved in rule_table[tab_indx].double_down where tab_indx points to one of the five tables A-E. The function returns to ed_item( ) where the rest of the column is redisplayed and the image buffer buf_all_B is updated for this table.
16.15 Edit Surrender Options ed_surr( )
The choices here are binary. The house either permits or does not permit a surrender. The dialogue box is built. Text is displayed in the box: "Type Surrender Option: (0) None (1) Allowed". A single typed character completes the selection. If an out-of-bounds character is typed, the default value for this table is used. Next, the full text selection is displayed. The choice is saved in rule_table[tab_indx].surrender, where tab_indx points to one of the five tables A-E. The function returns to ed_item( ) where the rest of the column is redisplayed and the image buffer buf_all_B is updated for this table.
16.16 Edit Hole Card ed_hole( )
The dealer's hole card may appear first, second, or not at all. These choices are offered in this selection. First, the dialogue box is created. The text is displayed: "Type Hole Card Option: (0) Hole Card First (1) Hole Card Second (2) Both Cards Up." A single typed character completes the selection. If an out-of-bounds character is typed, the default value for this table is used. Next, the full text selection is displayed. The choice is saved in rule_table[tab_indx].hole_card, where tab_indx points to one of the five tables A-E. The function returns to ed_item( ) where the rest of the column is redisplayed and the image buffer buf_all_B is updated for this table.
16.17 Default Options def_splits . . . def_hole( )
These functions serve to initialize the rules structure rule_table[tab_indx].xxx_yyy with selections that originate either from a saved list of values located in file game_set.dat, or from tables located in file pit_tab.h. The variable source indicates which file is to be accessed. When source=1 and the table has not been initialized, consult file game_set.dat. If the table is initialized, use the recently entered values from rule_table[tab_indx]. When source=0 and the table is uninitialized, the default tables are used.
Table: rule_table_dat (from pit_tab.h)
rule_table[tab_indx].xxxx (edited values)
File: saved values (from game_set.dat)
16.18 Make the Save Screen make_save_scrn( )
The purpose of this function is to prepare an edited table's image for presentation when the user wishes to view all current house rules settings. For example, if table E was last edited and accepted with keystroke F2, and the pit boss wished to see the rules currently in effect, he would choose "View Current Rules Table" from the executive menu. The screen heading "CURRENT HOUSE RULES" is displayed with all of the selections he made in table E. Until he edits another table, this will be the default list of house rules every time a new game session is commenced.
First, two portions of the table image are saved, as shown above. The full screen area is cleared and a new screen is created with the two image above placed within. After text headings and command lines are added, the entire image is saved to image buffer buf_save_rules.
16.19 Show Current Rules show_current_rules( )
When current rules settings that are in effect are to be viewed, this function which is called only from pit_boss_ed( ) will display the image that has been saved in buf_save_rules. See sec. 15.14 for more information.
16.20 Free Memory free_mem( )
When graphics image are saved, large blocks of memory must be allocated. After the rules editor has been accessed and the game begins, the allocated is no longer needed. This function frees it up for other resources.
17. Compilation and Files
The following indicates compilation and files
17.1 Compiler
Watcom C/C++, Version 11
17.2 Source Files
17.3 Include Files
17.4 Libraries
17.5 Files Used to Operate Game
17.5.1 game_his.dat
This file holds records of the ten most recent games, including player win/lose status and card usage data.
17.5.2 game_set.dat
Start-up settings for the next game session are stored in this file, including the original seed for the RNG.
17.5.4 dos4GW.exe
An executable file that serves to access protected mode memory.
17.5.5 cardlib.snd
Several recorded sounds are stored in this file for use by the sound blaster card. Specifically, the sounds of shuffled cards and cards being dealt are saved here.
17.5.6 21 play.exe
An executable file that runs the game.
18. Communications Module game_comm( )
18.1 General Description
This module performs a polled retrieval of serial data from a specified port, and transmits serial data via the same port. The port is connected to the game hardware interface PCB where the following information is collected and assembled into a ten-field data string:
Shoe switches (hit, stand, d-down, deal/cut, split)
Lock status
System status
Sensor data, up to 14 optical bet sensors
The port is operated at 19.2K baud without flow control. If the host returns an ACK the bet sensor will remain idle.
If the host returns a NAK, the bet sensor will retransmit the data.
18.2 Received Data String
18.2.1 Field One: Keypad Data
The first white-space delineated field contains keypad data from the shoe. Valid keys are 1-16, where an active key sends a '1'. A string will be sent every time a valid key is pushed.
18.2.2 Field Two through Eight: Bet Sensor Data for Players 1 to 7, respectively. Each of the seven fields is coded as follows:
0=no insurance bet, no game bet
1=no insurance bet, game bet in place
2=insurance bet in place, no game bet
3=insurance bet in place, game bet in place
A new record will be sent every time a bet has changed.
18.2.3 Field Nine: System Status and Lock Data
Bit assignment for field 9.
tx_dat.a.switches = 0;
if (!RA4) // Pit Boss game modify switch active
tx_dat.a.switches += 1;
if (!RD0) // Pit Boss power off switch active
tx_dat.a.switches += 2;
if (RD1) // Door interlock 2 - True - Inner door is open
tx_dat.a.switches += 4;
if (RD2) // Door interlock 1 - True - Outer door is open
tx_dat.a.switches += 8;
if (RC5) // Spare
tx_dat.a.switches += 0x10;
if (Hz60) // 1=60Hz 0=50Hz
tx_dat.a.switches += 0x20;
if (sense_0_ok) // True sensor 3,2 is above minimum value
tx_dat.a.switches += 0x40;
if (sense_1_ok) // True sensor 3,3 is above minimum value
tx_dat.a.switches += 0x80;
Sensors 132 (above coded as 3,2 and 3,3) are ambient light sensors. Sense.sub.—0_ok and sense.sub.—1_ok will be set if minimum light levels were measured on these respective sensors during the bet light detection process. It is the responsibility of the host as to accept the reliability of the individual player bet sensors if there is a problem with either the ambient light sensors.
18.2.4 Field Ten: Check Sum
A simple 8-bit checksum over the first nine fields with no carry is computed and transmitted.
18.3 Received Data Structure
Incoming data is organized within game_com( ) into the following structure:
Struct bim{
Byte keypad;
Byte bet_status[7];
Byte switches;
Byte check_sum };
Struct bim a;
Byte packet[10];
}; tx_dat;
For example, when shoe data is inspected the location tx_dat.a.keypad is examined.
18.4 Game_Comm game_com( )
When needed, calls to game_comm( ) are made from the rules module rules.sub.—21.c. Before the function is called, the port is initialized in a call to a Greenleaf CommLib function:
The function game_comm( ) first looks to see if new data is in the received buffer of the serial port. If the buffer is not empty, the volume of data must exceed 20 bytes before the buffer is read. Next, a NAK is sent to the PCB for a retransmit of data. Then, a "c" is sent in order to calibrate the bet sensor. Finally, a function serial_parse( ) is called.
18.5 Serial Parse Serial_parse( )
The purpose of this function is to fill the data structure tx_dat.a.xxx with the received string. The string is first read into buffer rx_data. The data fields are parsed into tx_dat.a.xxx. The checksum is computed against the nine fields and is compared against the received checksum in field ten. If the two don't match, a NAK is sent requesting a retransmission of the data. If the transmission is valid, a ACK is sent instead.
18.6 Receive Data Rcv_data( )
This function works to retrieve each character in the transmission by calling a Greenleaf CommLib function ReadChar(port) Until a carriage return is found, the data is read into array rx_data[ ].
18.7 Send Data Send_data( )
This function serves to assemble a message string for transmission to the UART on the communications PCB. A Greenleaf CommLib function WriteString(port) handles the physical layer task of transmitting the data.
On power up (or any time the bet system is not responding) the Host will send a "c" to the bet sensor to calibrate the bet optics. The bet sensor will respond with an "ACK" if minimum light levels are present on all sensors. A "NAK" will be sent if those levels have not been attained. The following is the diagnostic output from the bet sensor when the following single character is sent from the host.
Ascii Character "d"
This display shows the raw analog data the 16 possible bet light sensors for one AC line cycle.
Values can range from 0 to 255.
aval00=141 // bet player 1
aval01=0 // insurance player 1
aval02=0 ″
aval03=0 ″
aval10=0 ″
aval11=0 ″
aval12=0 ″
aval13=0 ″
aval20=0 ″
aval21=0 ″
aval22=0 ″
aval23=0 ″
aval30=0 // bet player 7
aval31=0 // insurance player 7
aval32=0 // ambient light sensor 0
aval33=152 // ambient light sensor 1
Ascii Character "f"
This display shows the raw analog data the 16 possible bet light sensors for one to six AC line cycles. Values can range from 0 to 255 and 1 to 6 line cycles. The format is a-d val/line cycles.
The brighter the light:
Power Failure Recovery
Any interruption to the computer/hardware power supply that is sufficient in causing the computer to reset automatically result in the game rebooting into a replay mode. No user intervention is required to assist the replay mechanism. The game will immediately enter the replay mode and all data from the previous game that was interrupted will be recalled from non-volatile CMOS memory and fed into the (1) decision making engine, and the (2) card selection engine. The game will play automatically up to the player and card at which the power was lost.
When a new game is played vital data about the game is entered into holding buffers. With every state change in the game the buffers are written to NV-RAM, thus preserving the recent history of game state changes. A few of the important state changes that are necessary to replay the game are:
a) Active Players; when a game is replayed, only the active positions from the last game are again active
b) Shoe Decisions; all decisions that result in stand, double-down, hit, split actions originate in shoe switches, and are recorded serially as the game advances
c) Card Selection; every card that is dealt to either a player or the dealer is drawn from an electronic card tray that is randomly filled during the shuffle/cut sequence. When a card is drawn, its number is recorded serially in a buffer
d) Insurance Players; when a dealer shows an ACE, an insurance sequence is entered and any player who places an insurance bet is recorded in a buffer which is later saved to NV-RAM. This information is used during replay to accurately replay the insurance bet.
The active window during which the above data is recorded begins when the first card is dealt and ends after the dealer has played out his hand. If the power drops during the dealer's playout sequence, his cards will be restored to the point at which power went down. In any replay, after the last decision which was saved from the previous game is executed, all new cards will be drawn from a new card tray.
Further Alternative Embodiment Using Slot Symbols
The system of
The slot symbols considered from the first three player cards are depicted as three of the same "double BAR" slot symbols. This is typically a symbol group for which a jackpot would be awarded, as suggested in the payoff schedule at windows 908 and 918 wherein it is indicated that such a combination of slot symbols would result in a payoff of 500 times the ante bet.
The player display shown in
Additional Operation and Methods
Additional aspects of the novel methods and operation of system 60 are now further described. The methods are for playing a live card game involving a plurality of live participants. The live participants including at least one player and at least one dealer. The live participants attend the card game personally about a gaming table.
In one aspect the methods include providing at least one presentation unit which is supported by the gaming table and has a viewing face which is available for viewing by the participants attending the game about the gaming table. The providing step occurs by constructing or having constructed a gaming table with system, such as system 60, retrofit or otherwise installed thereon.
In another aspect the methods include displaying a plurality of changeable participant display images from at least one participant video display which forms a part of the at least one presentation unit. The plurality of participant video displays can be provided in the form of discreet displays are shown herein, or part of a large display if practical in terms of positioning about the gaming table. The displaying step involves providing participant display images which include playing card images indicating virtual playing cards dealt or otherwise assigned to the live participants.
The methods further advantageously include processing data using at least one game processor. The processing of data is advantageously used to perform a number of data processing functions as have been described herein. Of particular interest are the data processing steps which provide the following steps or functions. In one aspect such involves providing game rules which at least partially administer play of the card game. In another aspect such involves defining a stack of virtual playing cards having one or more decks of virtual playing cards included therein for use in playing the card game. Such decks can be conventional decks, abbreviated decks, or decks of unusual composition depending upon the card game being played.
The data processing function further includes shuffling the stack of virtual playing cards to produce a stack sequence which determines the order of virtual playing cards dealt or otherwise assigned to the participants. The stack sequence referred to can be done in a single time frame, such as by using the traditional shuffle discussed above. Alternatively, such shuffling can be done on an intermittent basis to perform the continuous random shuffle, random balance shuffle or other shuffling routines on the fly as cards need to be dealt or otherwise assigned in play of the card game.
The data processing functions can further include dealing virtual playing cards to participants from the stack according to the game rules.
The data processing functions further advantageously include instructing the participant video displays to display at least playing card images indicating virtual playing cards assigned to the participants, said virtual playing cards assigned to the participant forming the participant's card hand. The instructing step relative to participant video displays can also include presentation of additional information as detailed above.
The methods of this invention further involve controlling play of the card game using at least one dealer control, such as dealer control keys 85-89. The dealer control keys act as dealer control sensors which are controllably activated by the dealer control action of the card game. This control action includes at least dealing of virtual playing cards to the participants. The description given above further details other control actions of the dealer's operation of the system.
The novel methods can further include recording game action for the card game being played to enable subsequent analysis or replay. This can be done using the mother board memory described above or by recording the data on a remote memory device (not shown), such as connected through serial port 187. The analysis will likely be performed at some other location on a different data processing unit so that operation of the gaming table is not impeded.
Additional exemplary methods can include reversing the action of a game to remove or back-up one or more steps performed in playing the game. This is indicated at step 743 of
The novel methods can also include replaying one or more sequence steps of the game to show a participant the action which has transpired.
Methods may further include displaying a simulated stack image, such as at first dealing shoe display 81. This displaying can be further enhanced by display of a cut card image, and moving or adjusting the cut card image to simulate playing of the stack.
Methods can further include sensing placement of betting chips by a player, such as at betting chip detection zones 120 using sensors 121. This is advantageously done for purposes of indicating participation in the card game.
Another exemplary method can include sensing placement of betting chips by a player for purposes of indicating an insurance bet being placed in the card game, such as at insurance bet detection zones 130 using sensors 131.
The methods involving sensing the betting chips can be enhanced by using betting chips which are encoded to allow determination of the value of the betting chips. Such methods can further include sensing the value of chips placed by the players.
As explain above in the methods the decisions of the players are effected by communicating instructions from the players to the dealer. These indicate playing decisions being made by the player in carrying out play of the card game. The dealer then implements the player's decision using dealer controls which perform by controlling the data processing and other functions of the card game system.
The methods according to this invention can use shuffling processes which are performed in a manner which reorders the stack after each card is dealt from the deck. The continuous random shuffling and random balance shuffling described above perform this function. The shuffling function can also be effected using a shuffling process which reorders the stack after each card is dealt from the deck, the reordering being performed after excluding any cards which have been dealt and are currently in the hand of a participant. This latter shuffling is performed by the random balance shuffling.
The gaming system of
The association of slot symbols is preferably a separate process in the game software apart from the random number assignment of virtual cards in the stack of virtual cards. This preferably independent process causes the variable association possibilities to be very large. This is important in providing a large number of possible odds. Since the slot symbol set can be defined to include multiple copies of the same symbols the different probabilities of symbols or groups of symbols can essentially be tailored to achieve large frequencies of winning slot symbols or combinations of symbols, or very low frequencies of winning symbols or combinations of symbols. These can be held constant or varied over time or with different machines or different versions of games played on each machine.
The novel methods involving the system of
The methods for using the system of
The slot jackpot aspect of the system of
The numerous methods according to this invention preferably involve digital data processing functions and processes. This allows high speed, accuracy and clarity of display images.
Alternative Embodiment Slot Machine Game System and Methods
Presentation unit 1100, shown best in
The player displays 1103 have associated player display images 1133 and 1134.
The player displays 1103 form part of associated player stations which also include a betting zone 1120 having associated betting sensors 1121 for detecting betting chips placed thereon to indicate participation by a player in the game. The player stations further include additional wager zones 1136 which detect additional wager chips placed therein using additional wager sensors 1137. The manner in which additional wager zones 1136 and sensor 1137 are used is further detailed below.
The player stations also preferably include bonus symbol betting zones 1130 which have associated bonus symbol betting sensors 1131. The bonus symbol betting sensors detect presence of a gaming chip placed therein to assure and allow recording that a player has elected to have a bonus symbol assigned to that player in response to placement of a bonus symbol ante bet by the players electing to do so.
The dealer display also preferably includes card symbol display areas 1144-1147. In typical operation, these display areas are used to display dealer symbol display images such as 1345 shown in
The gaming system also preferably includes a dealer control module 1300 illustrated in
The player display participation images 1134 have slot card display areas 1161-1164 for display first, second, third and fourth symbol display images according to varying possible rules of play. In one manner of play, the three display areas 1161-1163 form a pay line display of three symbols which form the equivalent of a traditional slot machine. In such embodiment, the fourth symbol display area and associated image are used to display an optional fourth symbol card or symbol purchased by a player for an additional bonus symbol ante. The bonus symbol ante is preferably detected by the bonus bet sensor 1131 when a typical betting chip is placed within bonus chip detection zone 1130 (see
The player display image shown in
The stage of play illustrate by
According to one method of playing the game system the first virtual symbol assigned to the dealer is displayed as image 1345 of
Block 1229 indicates that the dealer collects the bets at this stage of play. The common card is then displayed at block 1231. Any appropriate message is displayed at block 1233. The non-winning subsets are processed at block 1235 and these player positions are rendered inactive. Players can then continue optionally by placing the bonus symbol wagers as represented by the dealer's call in block 1237 and placement of the bonus bets in block 1239. The dealer checks to see if all bets are placed. If not, then the process proceeds by path 1242 to allow completion of betting. If completed, then path 1243 is pursued and the dealer depresses the deal key to resume play of the game.
Path 1246 continues the process to
Block 1257 indicates the game processor check to see if the dealer subset contains two wild cards. If not then path 1258 is followed and a new game round is initiated. If there are two dealer wild cards, then path 1259 is pursued and the dealer is assigned another symbol card at block 1261. A similar analysis concerning the dealer's possible assignment of a third wild card is represented at block 1263 with associate process paths 1264 for a no answer and 1265 for a yes answer. If the answer is yes then the dealer draws a fourth symbol card at block 1267. Block 1269 represents a comparison to see if the dealer subset has been assigned four wild cards. Blocks 1277, 1273 and 1275 illustrate payoffs to all participating players if the dealer has received the indicated number of wild cards. Path 1280 proceeds from these dealer winning group situations to the start of another round of play.
Exemplary methods include a processor-executable method that comprises:
receiving card identity information from a card reader that identifies each real playing card used in playing an electronic table game;
receiving wagering information from participants in the electronic table game, wherein each participant uses a separate video display of the electronic table game, each video display controllable to provide changeable display images assigned to the participants;
accessing game rules which at least partially administer play of the electronic table game;
defining virtual display images for playing the electronic table game, wherein at least some of the virtual display images are based on the card identity information and on the wagering information;
assigning the virtual display images to the participants according to the game rules; and
instructing the video display being used by an individual participant to display the virtual display images assigned to the participant according to the game rules.
In one implementation, the card reader is a card shoe for holding one or more decks of the real playing cards 61. At least some of the virtual display images can represent the real playing cards 61 for display on the multiple video displays. The processor-executable method can further include receiving card identity information from the card reader that includes a card value, a card rank, a card suit, a sequence in which each card was placed in play from a card shoe, an intended participant for an individual card, or a score of each card hand in a game round.
The exemplary processor-executable method can further include receiving wagering information from a visual user interface displayable on at least some of the video displays, or from chip sensors, or from both—the visual user interface and the chip sensors enable each participant to designate the wagering information. The chip sensors can detect a presence of betting chips placed by the participants using optical sensors or weigh cells, and can even include reading a value of each betting chip.
Other exemplary methods can include playing a live game involving wagering by a plurality of live participants, said live participants including at least one player and at least one dealer, said participants being live persons who personally attend the game at a live game location, comprising:
Exemplary methods can further include recording game action to enable subsequent analysis or replay.
Methods can further include reversing game action to delete the effects of one or more actions taken in playing the game.
Methods can additionally include sensing betting chips.
Methods can include displaying at least two virtual symbols assigned to said at least one player in the participant symbol subset;
providing said at least one player an opportunity to view said at least two virtual symbols;
determining whether said at least one player has placed an additional wager;
after said determining, displaying at least one additional virtual symbol assigned to said at least one player.
Additional methods according to the invention can include displaying images of the participant symbol subset assigned to said at least one player;
providing said at least one player an opportunity to view said images of the participant symbol subset assigned to said at least one player;
determining whether said at least one player has placed a bonus symbol ante;
providing a bonus symbol to the participant symbol subset for a player who has placed a bonus symbol ante;
redefining the participant symbol subset for a player who has placed a bonus symbol ante if said bonus symbol provides an improved payoff.
Still further methods can include comparing the participant symbol subset of both said at least one player and said at least one dealer.
Additional slot machine methods can include methods for playing a slot machine game involving wagering by at least one participant, comprising:
displaying a plurality of changeable participant display images from at least one participant display;
defining a set of virtual symbols for use in playing the game;
assigning virtual symbols from the set of virtual symbols to the at least one participant to define an assigned participant symbol subset;
instructing the participant display to display symbol images indicating the virtual symbols assigned to the participant symbol subsets;
displaying images of the participant symbol subset assigned to said at least one participant;
providing said at least one player an opportunity to view said images of the participant symbol subset assigned to said at least one participant;
determining whether said at least one participant has placed a bonus symbol ante;
providing a bonus symbol to the participant symbol subset for a player who has placed a bonus symbol ante;
comparing the participant symbol subsets to a pre-defined payoff list which indicates whether an assigned participant symbol subset is a winning group;
redefining the participant symbol subset for a participant who has placed a bonus symbol ante if said bonus symbol provides on improved payoff;
awarding payoffs to participants who receive a winning symbol group.
Further methods include, a method for playing a slot machine game involving wagering by at least one participant, comprising:
displaying a plurality of changeable participant display images from at least one participant display;
defining a set of virtual symbols for use in playing the game;
assigning virtual symbols from the set of virtual symbols to the at least one participant to define an assigned participant symbol subset;
instructing the participant display to display symbol images indicating the virtual symbols assigned to the participant symbol subsets;
displaying at least two virtual symbols assigned to said at least one participant in the participant symbol subset;
providing said at least one participant with an opportunity to view said at least two virtual symbols;
determining whether said at least one participant has placed an additional wager;
after said determining, displaying at least one additional virtual symbol assigned to said at least one participant;
comparing the participant symbol subsets to a pre-defined payoff list which indicates whether an assigned participant symbol subset is a winning group;
awarding payoffs to participants who receive a winning symbol group.
Additional aspects of the novel methods for playing a live game involve wagering by a plurality of live participants, said live participants including at least one player and at least one dealer, said participants being live persons who personally attend the game at a live game location, comprising:
displaying a plurality of changeable participant display images from at least one participant display;
defining a set of virtual symbols for use in playing the game;
assigning virtual symbols from the set of virtual symbols to the dealer and at least one player to provide assigned participant symbol subsets thereto, at least one of the virtual symbols assigned being shared between at least one dealer and at least one player;
instructing the participant displays to display symbol images indicating the virtual symbols assigned to the participant symbol subsets;
comparing the participant symbol subsets to a pre-defined payoff list which indicates whether an assigned participant symbol subset is a winning group;
displaying participant symbols assigned to the participants using the at least one participant display;
controlling play of the game using at least one dealer control operated by the at least one dealer;
awarding payoffs to players who receive a winning symbol group.
Although exemplary systems have been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed systems, methods, and structures.
|Cited Patent
|Filing date
|Publication date
|14 Jun 1971
|12 Mar 1974
|Hydro Search Inc
|Electronic gaming device simulating the game of blackjack
|15 Jan 1976
|7 Feb 1978
|Beam Dale R
|Control apparatus for a card game simulator
|27 Aug 1979
|13 Oct 1981
|Wollner Robert A
|Slot machine card game
|24 Mar 1980
|19 Apr 1983
|Mattel, Inc.
|Electronic card game simulator
|21 Oct 1982
|23 Jul 1985
|Uhland Joseph C
|Game monitoring apparatus
|7 Nov 1984
|30 Sep 1986
|Doyle Davis
|Electronic game machine suitable for chance and gambling card games
|30 Apr 1984
|13 Jan 1987
|Ainsworth Nominees Pty. Ltd.
|Poker machine communication system
|13 Sep 1982
|21 Apr 1987
|Harold Lorber
|Monte verde playing card dispenser
|5 Jun 1986
|26 Jul 1988
|Sidley Joseph D H
|System for interactively playing poker with a plurality of players
|7 Mar 1988
|21 Mar 1989
|Bally Manufacturing Corporation
|Reconfigurable casino table game and gaming machine table
|18 Apr 1986
|21 Mar 1989
|Leonard Storch
|Information transfer and use, particularly with respect to objects such as gambling chips
|29 Mar 1988
|15 May 1990
|Sidley Joseph D H
|Computerized gaming system
|13 Jul 1988
|11 Jun 1991
|Caribbean Stud Enterprises, Inc.
|Electronic poker game
|9 Feb 1990
|23 Jul 1991
|Bridgeman James L
|Card playing apparatus with single card discard feature
|11 Oct 1988
|10 Sep 1991
|Bridgeman James L
|Imitative-opponent gambling games
|11 Mar 1991
|24 Mar 1992
|Bet Technology Inc.
|Method and apparatus for playing a wagering game
|23 Sep 1991
|25 Aug 1992
|Bet Technology, Inc.
|Method of playing a wagering game
|16 Apr 1987
|27 Oct 1992
|Poker Pot, Inc.
|Multiple player game data processing system with wager accounting
|23 Sep 1991
|6 Jul 1993
|Bridgeman James L
|Gambling game and apparatus with uneven passive banker
|27 Aug 1992
|7 Sep 1993
|D.D. Stud Inc.
|Casino game system
|23 Oct 1991
|26 Oct 1993
|United Gaming, Inc.
|Six-card draw-poker-like video game
|8 Oct 1992
|26 Jul 1994
|Rio Properties, Inc.
|Apparatus and method for playing an electronic poker game
|14 Feb 1994
|3 Jan 1995
|D&D Gaming Patents, Inc.
|Methods and apparatus for playing casino card games including a progressive jackpot
|4 Mar 1994
|3 Jan 1995
|Josephs; Ronald H.
|Wagering game
|7 Feb 1992
|28 Feb 1995
|Marnell, Ii; Anthony A.
|Electronic gaming apparatus and method
|28 May 1993
|18 Apr 1995
|Vegas Pull Tabs, Inc.
|Interactive games and method of playing
|29 Sep 1994
|13 Jun 1995
|Stavinsky; Emil G.
|Card game
|3 May 1994
|19 Sep 1995
|Toy Builders
|Poker tournament
|3 Feb 1994
|5 Mar 1996
|Universal Sales Co., Ltd.
|Management method for gaming hall
|17 Feb 1993
|30 Apr 1996
|United Games, Inc.
|Stop play award wagering system
|29 Sep 1994
|2 Jul 1996
|Sevens Unlimited, Inc.
|Double poker
|28 Jun 1995
|2 Jul 1996
|Moody Ernest W
|Poker-style card game
|12 May 1995
|24 Dec 1996
|Casinovations, Inc.
|Blackjack game system and methods
|22 Sep 1994
|24 Dec 1996
|Mikohn Gaming Corporation
|Automated gaming table tracking system and method therefor
|5 Apr 1995
|25 Mar 1997
|Harrah's Club
|Bet tracking system for gaming tables
|16 Apr 1996
|20 May 1997
|Lowden; David
|Combined slot machine and table game apparatus and method of play
|25 Mar 1994
|10 Jun 1997
|Roberts; Carl
|Methods for prop bets for blackjack and other games
|19 May 1995
|29 Jul 1997
|Chip Track International
|Gaming chips with electronic circuits scanned by antennas in gaming chip placement areas for tracking the movement of gaming chips within a casino apparatus and method
|7 Aug 1995
|12 Aug 1997
|Method and apparatus for cashless bartop gaming system operation
|25 Jul 1996
|23 Sep 1997
|Peripheral Dynamics, Inc.
|Blackjack scanner apparatus and method
|25 Jan 1996
|23 Sep 1997
|Tarantino; Elia R.
|Casino card table with video display
|25 Sep 1996
|7 Oct 1997
|Oneida Indian Nation
|Cashless computerized video game system and method
|22 Nov 1995
|18 Nov 1997
|Game Data, Inc.
|Wagering system
|20 Sep 1995
|7 Apr 1998
|Chip Track International
|Gaming table tracking system and method
|16 Aug 1996
|28 Apr 1998
|B.C.D. Mecanique Ltee.
|Auxiliary game with random prize generation
|13 Feb 1996
|16 Jun 1998
|International Game Technology
|Progressive gaming system and method for wide applicability
|2 May 1994
|23 Jun 1998
|Franchi; John Franco
|Open architecture casino operating system
|27 Jan 1997
|14 Jul 1998
|Fm Gaming Electronics L.P.
|Automated gaming system and method of automated gaming
|17 May 1996
|4 Aug 1998
|Inven Corporation
|Drop slot game machine
|22 Sep 1995
|4 Aug 1998
|Mao, Inc.
|Method and apparatus for playing a betting game including incorporating side betting which may be selected by a game player
|18 Aug 1995
|8 Sep 1998
|John M. Strisower
|Card game hand counter/decision counter device
|11 Dec 1996
|3 Nov 1998
|Jones, Ii; Griffith
|Casino table sensor alarms and method of using
|14 Aug 1996
|24 Nov 1998
|Parra; Anthony C.
|Table for playing a game of chance
|29 Sep 1997
|8 Dec 1998
|Wells; Jeffrey M.
|Method of playing a poker game
|24 Nov 1997
|9 Feb 1999
|Kraft Gaming & Golf Inc.
|Method and apparatus for playing a poker game with a unique betting format
|29 Mar 1996
|9 Mar 1999
|Stupero; John R.
|Duplicate card game
|30 Mar 1998
|8 Jun 1999
|Steven R. Pyykkonen
|Game machine wager sensor
|19 Sep 1997
|15 Jun 1999
|Mccrea, Jr.; Charles H.
|Jackpot system for live card games based upon game play wagering and method therefore
|15 Dec 1995
|6 Jul 1999
|Grips Electronic Gmbh
|Apparatus and method for data gathering in games of chance
|20 Feb 1996
|10 Aug 1999
|Digideal Corporation
|Slot machine and methods of operation
|13 Oct 1995
|10 Aug 1999
|Forte; Steven L.
|Blackjack game system and methods
|2 Mar 1998
|31 Aug 1999
|Mostashari; Moe
|Poker game with designatable jokers
|19 Jun 1998
|31 Aug 1999
|Hernandez; Conrad B.
|1-2-3 card game
|24 Jul 1992
|14 Sep 1999
|International Game Technology
|Gaming machine and method using touch screen
|11 Sep 1995
|2 Nov 1999
|De Keller; David Guy
|Casino poker game
|3 Apr 1997
|4 Jan 2000
|Walker Asset Management Limited Partnership
|Method and apparatus for using a player input code to affect a gambling outcome
|5 Feb 1998
|25 Jul 2000
|Mourad; Raphael
|Gaming apparatus including slot machine
|31 Dec 1996
|8 Aug 2000
|Walker Digital, Llc
|Method and apparatus for securing electronic games
|18 Dec 1998
|12 Dec 2000
|Digideal Corporation
|Method of playing blackjack with a side wager
|11 Mar 1998
|26 Dec 2000
|Digideal Corporation
|Automated system for playing live casino table games having tabletop changeable playing card displays and monitoring security features
|7 Oct 1998
|13 Feb 2001
|Mikohn Gaming Corporation
|Intelligent casino chip system and method or use thereof
|20 Jan 1998
|13 Mar 2001
|John Huxley Limited
|Gaming chip system
|3 Aug 1998
|20 Mar 2001
|Digideal Corporation
|Drop slot game machine
|4 Aug 1998
|20 Mar 2001
|Digideal Corporation
|Slot-type gaming machine with variable drop zone symbols
|31 Jan 1997
|17 Apr 2001
|Dp Stud, Inc.
|Method and system for generating displays in relation to the play of baccarat
|26 Dec 2000
|7 Aug 2001
|Digideal Corporation
|Automated system for playing live casino table games having tabletop changeable playing card displays and play monitoring security features
|20 Mar 2001
|16 Jul 2002
|Digideal Corporation
|Slot-type gaming machine with variable drop zone symbols
|20 Mar 2001
|16 Jul 2002
|Digideal Corporation
|Drop slot game machine
|11 Dec 2000
|19 Nov 2002
|Digideal Corporation
|Method of playing blackjack with a side wager
|13 Jul 2001
|24 Jun 2003
|Smart Shoes, Inc.
|System including card game dispensing shoe with barrier and scanner, and enhanced card gaming table, enabling waging by remote bettors
|16 Jul 2002
|16 Sep 2003
|Digideal Corporation
|Drop slot game machine
|16 Jul 2002
|4 Nov 2003
|Digideal Corporation
|Slot-type gaming machine with variable drop zone symbols
|5 Dec 2000
|25 Nov 2003
|Digideal Corporation
|Automated system for playing live casino table games having tabletop changeable playing card displays and play monitoring security features
|7 Aug 2001
|20 Apr 2004
|Digideal Corporation
|Automated system for playing live casino table games having tabletop changeable playing card displays and play monitoring security features
|4 Nov 2003
|24 May 2005
|Digideal Corporation
|Slot-type gaming machine with variable drop zone symbols
|6 May 2002
|23 May 2006
|Digideal Corporation
|Automated system for playing casino games having changeable displays and play monitoring security features
|25 Nov 2003
|14 Aug 2007
|Sines Randy D
|Automated system for playing live casino table games having tabletop changeable playing card displays and play monitoring security features
|22 Jan 2001
|23 Aug 2001
|Oliver Terrance W.
|Intelligent casino chip system and method for use thereof
|25 Jun 2002
|2 Jan 2003
|Vt Tech Corp.
|Intelligent casino management system and method for managing real-time networked interactive gaming systems
|13 Oct 1995
|14 Feb 2006
|Digideal Corporation
|Gambling game system and methods
|Title not available
|U.S. Appl. No. 10/858,160, filed 2005, Sines et al.
|U.S. Appl. No. 11/055,589, filed 2005, Sines et al.
|U.S. Appl. No. 11/100,795, filed 2006, Sines et al.
|U.S. Appl. No. 11/396,005, filed 2006, Sines et al.
|U.S. Appl. No. 11/397,155, filed 2006, Sines et al.
|U.S. Appl. No. 11/404,952, filed 2007, Kuhn et al.
|U.S. Appl. No. 11/404,955, filed 2006, Sines et al.
|U.S. Appl. No. 11/505,748, filed 2008, Kuhn et al.
|U.S. Appl. No. 11/590,954, filed 2007, Kuhn et al.
|U.S. Appl. No. 11/591,072, filed 2006, Kuhn et al.
|U.S. Appl. No. 11/591,144, filed 2007, Kuhn et al.
|U.S. Appl. No. 11/591,145, filed 2007, Kuhn et al.
|U.S. Appl. No. 11/642,404, filed 2006, Kuhn et al.
|U.S. Appl. No. 11/642,580, filed 2006, Kuhn et al.
|U.S. Appl. No. 12/072,020, filed 2008, Kuhn et al.
|U.S. Appl. No. 12/072,028, filed 2008, Sines et al.
|U.S. Appl. No. 12/077,074, filed 2008, Sines et al.
|U.S. Appl. No. 12/077,078, filed 2008, Sines et al.
|U.S. Appl. No. 12/077,080, filed 2008, Sines et al.
|Citing Patent
|Filing date
|Publication date
|30 Jan 2012
|7 Aug 2012
|Microsoft Corporation
|Providing alternative content in a windowed environment
|20 Apr 2012
|29 Oct 2013
|Tech Art, Inc.
|Integrated blackjack hole card readers and chip racks, and improved covers for chip racks
|30 Nov 2012
|15 Jul 2014
|Mark H. Jones
|Turbo card table game with RFID card identifier
|9 Mar 2012
|9 Sep 2014
|Timothy M. Frazin
|Poker table accommodating multiple dealers to facilitate play of multiple poker games simultaneously
|9 Mar 2012
|20 Jan 2015
|Pac Gaming Llc
|Multi-action poker game and method of conducting multiple hands substantially simultaneously
|23 Apr 2012
|14 Apr 2015
|Pac Gaming Llc
|Multi-action poker game and method of conducting same via networked systems
|4 Apr 2012
|15 Sep 2015
|Kenneth J. Huebner
|Connecting video objects and physical objects for handheld projectors
|17 Jul 2014
|29 Sep 2015
|Royal Suite Blackjack, Llc
|Blackjack games
|8 Jul 2015
|5 Sep 2017
|Royal Suite Blackjack, Llc
|Games and gaming machines having bonus features
|30 Jan 2012
|24 May 2012
|Microsoft Corporation
|Providing alternative content in a windowed environment
|20 Apr 2012
|25 Apr 2013
|Arthur C. Miller
|Integrated blackjack hole card readers and chip racks, and improved covers for chip racks
|30 Nov 2012
|30 May 2013
|Mark H. Jones
|Turbo card table game with rfid card identifier
|9 Mar 2012
|12 Sep 2013
|Timothy M. Frazin
|Poker table accommodating multiple dealers to facilitate play of multiple poker games simultaneously
|8 Mar 2013
|12 Sep 2013
|Pac Gaming Llc
|Poker table accommodating multiple dealers to facilitate play of multiple poker games simultaneously
|7 Oct 2013
|26 Jun 2014
|Tech Art, Inc.
|Integrated blackjack hole card readers and chip racks, and improved covers for chip racks
|20 Dec 2012
|27 Nov 2014
|Sociedad De Jogos De Macau, S.A.
|Playing cards and system
|U.S. Classification
|463/13, 463/10, 463/11
|International Classification
|Cooperative Classification
|European Classification
|4 Dec 2008
Owner name: DIGIDEAL CORPORATION, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KUHN, MICHAEL;EVANS, DONALD;KRISE, DAVID;REEL/FRAME:021928/0142;SIGNING DATES FROM 20081111 TO 20081126
Owner name: DIGIDEAL CORPORATION, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KUHN, MICHAEL;EVANS, DONALD;KRISE, DAVID;SIGNING DATES FROM 20081111 TO 20081126;REEL/FRAME:021928/0142
|4 Aug 2010
Owner name: IGT, NEVADA
Free format text: SECURITY AGREEMENT;ASSIGNOR:DIGIDEAL CORPORATION;REEL/FRAME:024785/0583
Effective date: 20100716
|24 May 2011
Owner name: DIGIDEAL CORPORATION, WASHINGTON
Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:IGT;REEL/FRAME:026331/0965
Effective date: 20110524
|10 Jun 2011
Owner name: SEAPORT V LLC, NEW YORK
Free format text: SECURITY AGREEMENT;ASSIGNOR:DIGIDEAL CORPORATION;REEL/FRAME:026426/0565
Effective date: 20110523
|6 Nov 2015
|Maintenance fee reminder mailed
|27 Mar 2016
|Surcharge for late payment
|27 Mar 2016
|Fee payment
Year of fee payment: 4