Game Conversion Method
A method is disclosed for enabling play of legacy games on a previously-incompatible enhanced gaming platform that provides enhanced functionality using a game conversion system. The method includes: providing a game cabinet for a gaming machine; operatively associating an enhanced gaming platform with the gaming machine, wherein the enhanced gaming platform includes an enhanced gaming operating system and an enhanced gaming processor board; loading one or more legacy games onto the enhanced gaming platform, wherein the one or more legacy games are configured to operate on a legacy gaming platform, and wherein the one or more legacy games are not natively configured to operate on an enhanced gaming platform; converting legacy data from legacy game EPROMS into files usable by the enhanced gaming platform via a configuration file generator system; and enabling game play of the one or more legacy games using the converted legacy data on the enhanced gaming platform, wherein the enhanced gaming platform provides increased functionality associated with the platform. The game conversion system increases the number of game titles that are available to be played on the newer game platforms by enabling operability of legacy games. Additionally, the game conversion system decreases the amount of certification processing required by utilizing previously-certified legacy games.
This application is a continuation-in-part of U.S. patent application Ser. No. 10/224,026 filed Aug. 19,2002, entitled GAMING BOARD SET AND GAMING KERNEL FOR GAME CABINETS, which is hereby incorporated herein by reference, and which in turn claims the benefit of the filing date of provisional application 60/313,743 which was filed on Aug. 20, 2001, entitled “Form Fitting Upgrade Board Set For Existing Game Cabinets,” all of which are hereby incorporated herein by reference. This application is related to co-pending U.S. patent application Ser. No. 11/559,401 filed Nov. 13, 2006, entitled GAME CONVERSION SYSTEM.
COPYRIGHT NOTICEA portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
FIELD OF THE INVENTIONThis invention relates generally to a gaming system and, more particularly, to a system and methodology for providing high performance, incremental and large upgrades, and a consistent game development API for gaming cabinets, both existing and new.
BACKGROUNDGaming industry cabinets are fairly standardized as to general configuration. This is partly due to the needs of the casinos, who want to fit the maximum number of gaming devices into a given amount of floor space. It is also due to the physical needs of players, who need a certain minimum amount of cabinet area in front of them to play the game while not crowding their fellow players on the next gaming machine. It is also due to the requirements of the game components, encompassing both regulated and non-regulated aspects. Game components include a video monitor or reels, input and output devices (buttons, network interface, voucher or ticket printers, and magnetic strip card readers are typical) together with a main processor board. The main processor board has interfaces to the various input and output devices, and has at least a processor and memory which enables gaming software to be installed and run on the processor board. In most gaming machines the processor board, power supply and other related mechanical and electrical elements are typically co-located near the base of the gaming machine. Disposed thereabove at approximately chest level of the player is the gaming display, such as the rotatable reel displays in a slot machine or a video monitor for video-based games.
The processor board, in addition to have physical mounts such as guides, rails, standoff mounts, board slots, board slides, or board tray, will further have cabinet electronic interfaces, typically at the back of the board (towards the front of the cabinet, from a player's perspective). Processor boards will typically have a set of multi-pin plugs or bus connectors that slide into mating plugs or bus connectors when the processor board is correctly seated in its mounts.
If the board needs work, the entire processor board is replaced. In addition to a replacement board from the manufacturer (in this case IGT®), there are commercially available replacement boards having the same or nearly the same features, speed, memory capacity, etc., from after market manufacturers. No matter where the board originates from, they follow the same configuration, that is, they consist of a single board that replaces the processor board supplied with the game having similar functionality and the same form. In addition to their physical similarity, they employ a monolithic software architecture; that is, the game cabinet-specific operating system and specific game software are not a modular, layered design using modem software engineering practices. An example of an aftermarket replacement processor board for the IGT® Game King® gaming cabinet is, or was sold by, Happ Controls™, 106 Garlisch Drive, Elk Grove, Ill. 60007. It has the same basic physical, electronic, and software architecture as the original.
Upgrade processor boards are also available for some games. The reason for considering upgrade boards is that it may be possible to run newer games in a cabinet already owned by a casino if improvements are made to processor speed, memory, graphic support chips, and other components. Game upgrades interface to some degree with the internal busses of the game cabinet, but require cabinet modifications. Currently available upgraded boards do not fit in the slot used by the original processor board; rather, they must be mounted elsewhere in the cabinet. In addition to requiring the accompanying mechanical fabrication and electrical work, the upgrade boards are a fixed upgrade. That is, if the configuration of the upgraded game itself needs to be upgraded a few years later, you have to purchase and install a completely new upgrade kit which requires going through the same installation problems that were encountered with the original upgrade. This is a significant deterrent to upgrading activity.
In addition, each proprietary processor board as well as upgraded game boards typically uses its own interface to the game software, requiring game rewrites each time a hardware upgrade occurs. This makes gradual or incremental game enhancement prohibitively expensive.
SUMMARYA method is disclosed for enabling play of legacy games on a previously-incompatible enhanced gaming platform that provides enhanced functionality using a game conversion system. The method includes: providing a game cabinet for a gaming machine; operatively associating an enhanced gaming platform with the gaming machine, wherein the enhanced gaming platform includes an enhanced gaming operating system and an enhanced gaming processor board; loading one or more legacy games onto the enhanced gaming platform, wherein the one or more legacy games are configured to operate on a legacy gaming platform, and wherein the one or more legacy games are not natively configured to operate on an enhanced gaming platform; converting legacy data from legacy game EPROMS into files usable by the enhanced gaming platform via a configuration file generator system; and enabling game play of the one or more legacy games using the converted legacy data on the enhanced gaming platform, wherein the enhanced gaming platform provides increased functionality associated with the platform. The game conversion system increases the number of game titles that are available to be played on the newer game platforms by enabling operability of legacy games. Additionally, the game conversion system decreases the amount of certification processing required by utilizing previously-certified legacy games.
In one aspect of a preferred method, the legacy data is from legacy game EPROMS that have been previously submitted and approved by game regulators. In one embodiment, the legacy data is S6000 gaming data. In another aspect of the game conversion system, the enhanced gaming platform comprises an Alpha platform. Continuing, in another aspect of a preferred embodiment, the configuration file generator system reads a binary file created from data contained in the legacy game EPROMS and generates a set of configuration files necessary for proper operation of game personalities on an enhanced gaming platform. In this regard, the configuration file generator system acts as a translator, and does not alter any original mathematical modeling of a game program processed by the system. Notably, in some embodiments, the game conversion system enables pre-approved legacy game personalities to be used on enhanced gaming platform-based systems without requiring new development, testing, and submission costs.
In another aspect of a preferred method, the legacy game titles available to an enhanced gaming platform include, by way of example only, and not by way of limitation: jumpin′ joker, flaming sevens; fireball, fireball frenzy; wacky winners, bonus frenzy; hat trick, nudge; bonus game, diamonds and devils; monte carlo, hit and run; and s5500 legacy game programs. In one embodiment, the enhanced gaming platform runs a legacy game using the game conversion system supports up to three game denominations. In another aspect, the enhanced gaming platform runs a legacy game using the game conversion system supports up game denominations do not exceed a value ratio of 10:1. In another aspect, a video display of an enhanced gaming platform enabled gaming machine uses the game conversion system supports utilities include, by way of example only, and not by way of limitation: game setup/configuration; diagnostics/accounting/game recall; tilt messages; door statuses; ticket in messages; hand pay messages; denomination selection; denomination help screen; credit meter continuously displayed in dollar and cents; and paid meter displayed in dollar and cents upon cashout.
Another game conversion method is directed towards enabling play of single display screen games on a enhanced gaming platform while providing related content on a second display screen using a game conversion system. The method including: providing a game cabinet for a gaming machine, wherein the gaming includes at least a first display screen and a second display screen; operatively associating an enhanced gaming platform with the gaming machine, wherein the enhanced gaming platform includes an enhanced gaming operating system and an enhanced gaming processor board, and wherein the enhance gaming operating system supports the first and second display screens; loading one or more legacy games onto the enhanced gaming platform, wherein the one or more legacy games are configured to operate on only a single display screen, and presenting game theme content on the second display screen when a single display screen game operates on the single display screen using a dynamic glass system, wherein the dynamic glass system presents game theme content on the second display screen that is related to the single display screen game if related game theme content is available.
In another aspect of a preferred method, the second display screen is located in the upper panel of the gaming machine. In one presently preferred embodiment, game theme related content that was previously printed on an upper panel of a legacy gaming machine that supported single display screen game is virtually mimicked on the second display screen of enhanced gaming platform based gaming machine using the dynamic glass system. In another aspect, the dynamic glass system changes content presented on the second display screen to correspond to a currently selected single display screen game presented on the first display screen. In this manner, the single display screen game is selectable by the patron, thereby enabling multiple enhance legacy games to be played consecutively on a gaming cabinet without requiring printed theme content on an upper panel to be replaced or otherwise changed.
In another aspect of a preferred method, the dynamic glass system enables second display surrogate content capability into an enhanced gaming operating system release. In this regard, wherein the dynamic glass system supports both games having single display screen configurations and games containing intrinsic content for second display screen. In another embodiment, the dynamic glass system only activates, and presents game theme content on the second display screen, when the system detects a single display screen game in operation. Preferably, the game theme content for the second display screen is stored on the operating system compact flash. More preferably, the game theme content for the second display screen is stored on the operating system compact flash in a dedicated partition of the operating system program. Moreover, in one embodiment, the dedicated partition of the operating system program in which the game theme content for the second display screen is stored, is a read only partition, and the game theme content for the second display screen is non-alterable media.
In one preferred method, the game theme content for the second display screen is a static image, while in another preferred embodiment, the game theme content for the second display screen is multi-media. In another aspect, (1) the dynamic glass system first checks a game compact flash for second display screen content, and if second display screen content is not present on the game content flash, (2) the dynamic glass system checks for second display screen content on the operating system compact flash, and if second display screen content is not present on the operating system compact flash, then (3) the dynamic glass system uses default second display screen content from the operating system compact flash. In one embodiment, second display screen content that is stored on a partition of the operating system compact flash is authenticated before use by the dynamic glass system. In such an embodiment, the operating system disables game play and displays an error message if authentication of the second display screen content fails. Preferably, the operating system of the game conversion system includes a configuration option for enabling or disabling the dynamic glass system. In still another aspect of a preferred embodiment, the game theme content for the second display screen includes a plurality of language components that enable games to be quickly converted from a first displayed game in a first language to the first displayed game in a second language using the dynamic glass system.
Yet another embodiment of a game conversion method is directed towards enabling play of single display screen games on a enhanced gaming platform while providing related content on a second display screen using a game conversion system. The method includes: providing a game cabinet for a gaming machine, wherein the gaming includes at least a first display screen and a second display screen; operatively associating an enhanced gaming platform with the gaming machine, wherein the enhanced gaming platform includes an enhanced gaming operating system and an enhanced gaming processor board, and wherein the enhance gaming operating system supports the first and second display screens, wherein the enhanced gaming platform includes a universal serial bus dongle connection, and wherein a universal serial bus flash memory device is attachable to the dongle connection; and presenting game theme content on the second display screen when a single display screen game operates on the single display screen using a dynamic glass system, wherein the dynamic glass system presents game theme content on the second display screen that is related to the single display screen game from the universal serial bus flash memory device is attached to the dongle connection.
BRIEF DESCRIPTION OF THE DRAWINGS
Referring to the drawings, for illustrative purposes a disclosed embodiment is shown embodied in
A disclosed embodiment provides a new and dramatically more cost effective way for owners of aging games (hardware and software) to upgrade their existing cabinets to incorporate new hardware features and capabilities, as well manufacturers of new game cabinets to insure a new, novel, and easy to access upgrade paths to help stave off obsolescence in an industry where games often have lives of 6 months or even less.
A disclosed embodiment provides for easy hardware and game-level software upgrades (user-level or application level software, from the operating system's viewpoint and when in a modular and layered software environment such as that provided by a disclosed embodiment), not previously available. This includes being able to easily and economically upgrade hardware that incorporates faster CPUs, busses, etc., as well as incorporating new features such as Ethernet connectivity, stereo sound, and high speed/high resolution graphics. In addition to the ease of upgrading hardware capabilities, a disclosed embodiment further provides a game kernel which, by providing a callable, consistent user-interface API to the new hardware, makes game programming changes for the game-level programmers minimal after a hardware upgrade. It also provides for backward compatibility, enabling gaming machine owners to upgrade hardware, install the game kernel supporting the new hardware (described in more detail below, but fundamentally installing the libraries that support the added or new hardware capabilities), but wait to upgrade the game software until any later time.
In addition, the game kernel and two-piece processor board introduced in a disclosed embodiment allows game-level programmers to design and build games using the same game application interface across multiple manufacturers' cabinets, resulting in a huge development savings when compared to the prior art.
FIG.2 shows two game processor boards. Board 200 is a prior art processor board from an IGT® game cabinet. Board 204 is a processor board according to a disclosed embodiment, called a two-board processor board set. Note that it is designed to be a swap-fit with the original, prior art board. It will use the same physical board mounts (slides, guides, rails, etc.) inside the cabinet, and will connect to the cabinet wiring using compatibly placed connectors 206. Note that in any particular replacement board set, there may be some individual connectors, pins, or pin positions not used, because player I/O devices were changed, added, and/or other considerations. However, the supplied connectors will make the game machine (cabinet) functional for game play. For added functionality, there will typically be additional connectors supplied over and above those on the processor board being replaced. This allows the two-board set of a disclosed embodiment to be a simple swap replacement for the old processor board. This is a huge improvement over other upgrade boards, which require casino personnel to install the prior art replacement processor board in a new physical location within the game cabinet, including figuring out where to mount the new board mounting hardware as well as the attendant problems of fitting new connectors.
For the purposes of this disclosure, the processor board that came with the game cabinet as first delivered from the manufacturer to a customer will be called the OEM (Original Equipment Manufacturer) processor board. Further, the mounting system for the OEM processor board, in whatever form the game cabinet was delivered, is called the OEM mount, mounts, or mounting system. It is to be understood that the OEM mounts may be any implementation, including but not limited to slides, rack-mount, stand-offs, guides, blocks, rails, trays, etc. Whatever mounting system or mounts were used when the game was first manufactured is included in the definition of OEM mount(s).
FIG.3 shows more details of an example two board set to replace the traditional processor board. A very important feature is that the replacement processor board is made up of two boards, a first board 300 and a second board 306. The two boards are plugged together, using the three visible multi-connector plugs between the two boards (no pointer provided to help keep visual clutter to a minimum).
Board 300 is an industry standard processor board, such as a Netra AX2200 from Sun Microsystems of California, or the SE440BX-2 or CA180 from Intel Corporation of California. Both can be purchased in an industry standard form factors, and are configured to support at least one operating system (including embedded operating systems). By “industry standard form factors”, this disclosure means any board form factor that has been agreed to by more than one board manufacturer. Such form factors typically have publicly available specifications, often using an industry funded organization to keep the specifications.
One such organization is the Desktop Form Factors Organization, which may be found at www.formfactors.org. Examples of form factors whose specifications may be found there include the ATX, MicroATX, NLX, and FlexATX. There are other industry standard form factors as well. In addition, there are other specifications that are understood to be a consideration in the industry and in the selection of an industry standard form factor for use in the current invention, but are not explicitly discussed in this disclosure. One such consideration is height. Older rack mounted systems might have been based on 4U or 6U racks, with boards having a larger perimeter measurement than desktop form factors.
Now, manufacturers are targeting 2U or even 1U racks. Because it is generally the case that height is not an issue in pre-existing game cabinets, height considerations (as well as some other form factors) are not explicitly discussed herein. However, it is to be understood that should such considerations become necessary, all such considerations are included in the description of “form factors” as used herein. Any board having at least a CPU or a CPU socket, having any industry standard form factor, and being designed to be a system in the sense of enabling at least one operating system (including an embedded operating system) to run on it, will be referred to as processor boards for the purposes of the disclosure.
Board 306 is a unique board created by Sierra Design Group® (SDG) for the purposes of creating a form fitting and functionally compatible replacement processor board (when coupled with board 300) for the OEM processor board found in game cabinets currently in use. The board set is also intended to be used in new gaming cabinets when new game cabinets are designed from the ground up with the board set of a disclosed embodiment, with an I/O adapter board designed specifically for the new cabinet. Existing game cabinets used with a disclosed embodiment might be from IGT®, Bally®, WMS®, or other preeminent game manufacturers. Further, each of these game manufacturers is typically selling several game cabinets, each with their own processor board, at any given time.
Board 306 is specially designed and manufactured for each targeted game cabinet, with board 300 and board 306 configured to form a plug-compatible, functionally compatible and functionally enhanced, and form-fit-compatible replacement processor board. As part of this plug-in compatibility, game cabinet interface connectors 304 mate directly with the plugs in the game cabinet for which the processor board is designed. Note that it may be the case that a subset of the pre-existing game cabinet's plugs (or pins in a plug) are used, where the unused plugs (or pins) do not mate to a compatible plug on the processor board set of a disclosed embodiment. The processor board set is still plug compatible, however, because the remaining plugs (or pins) are designed to be functionally compatible with the subset they do interface with, with the unused plugs (or pins) being taken into consideration during the design of the processor board set such that there will be no interference with the other plugs (or pins), fully enabling a swap-fit.
Thus, it is to be understood that swap-fit does not imply identical connector mappings or identical connector configurations; rather, swap-fit means that the processor board set of a disclosed embodiment replaces the OEM processor board in such a manner that it uses the OEM mounts and interfaces to such existing plugs/pins/opto-isolators/connectors/connector-blocks/ blocks/bus-connectors (collectively: connectors) that enables all player devices to be used in the existing game cabinet to be functionally connected to the processor board set of a disclosed embodiment.
“Player device” and “player devices” are defined to mean any and all devices that a player may see, hear, touch, or feel. Some are passive (in the sense that a player only receives information from them, such as a video screen and speakers), while others are active (buttons, handles, levers, touchscreens, etc.). Both types are included when using the words “player devices” in general.
Boards such as 306 are called game cabinet adapter and functional enhancement boards, or I/O adapter boards, for the purposes of this disclosure. A processor board coupled with an I/O adapter board is called a two-board processor board set. Note that for certain applications, it may be the case that the applicable I/O adapter board could be made that is an adapter board without additional functional enhancements, to fit an existing game cabinet. This is not expected to be a preferred embodiment, as the cost to provide enhancements (like addition communications ports) is small enough relative to the cost of the overall two-board set as to make the additional functionality well worth the incremental costs.
The creation of a replacement processor board made up of board 300 and board 306, or two-board processor board set, opens many optional upgrading and game enhancement paths for game box manufacturers, game developers, and casino owners. For example, 302 points to a portion of board 306 which incorporates stereo sound capabilities, including an amplifier to drive higher wattage speakers than found in a standard game cabinet. This allows the game software that is running on the two-board processor board set of a disclosed embodiment (coupled with the gaming kernel), without any changes, to make use of stereo audio output. For best results, the standard mono speakers in the game cabinet should then be upgraded to stereo audio speakers; this can be easily done with a disclosed embodiment by merely replacing the speakers with new ones. Now the game will suddenly have full stereo sound, able to drive speakers having significantly higher wattage ratings.
If the speakers are not upgraded, both signals will be sent to the standard plug into the existing game cabinet wiring and speakers, allowing the game to function exactly as before. This enables, at a later date as investment capital becomes available (or if a new game requires stereo audio capabilities, especially helpful for use with sight-impaired game players), the cabinet can be upgraded with new speakers and the stereo output is already available—no further changes will be required. This one example shows how the two-board processor board set allows both hardware and software upgrades in a gradual manner, as investment capital becomes available. This incremental upgrading capability, including the use of both hardware and software incremental upgrades, has heretofore been unavailable.
Returning now to board 300, a few of its major components are indicated such as processor chip 310 (a socketted Pentium® 266 in one preferred embodiment), memory slot 312, and compact flash program storage 310. Board 306, the I/O adapter board, includes the functionality described below. Further, to see how board 306 looks in more detail and separated from board 300, FIG.4 shows an illustration of the I/O adapter board 400 in its unpopulated state. The I/O adapter board shown in FIG.4 is designed for use with an industry standard CPU board having an ATX type form factor, and for use in a popular IGT® game cabinet, forming thereby a swap-fit replacement for the IGT® processor board that came with the game originally. The I/O adapter and processor board provide significantly enhanced functional capabilities.
The functionality of the I/O adapter board may be grouped into two categories. The first category of functionality is that needed to provide, for each particular preexisting game cabinet, the unique optical or electronic interfaces between the game cabinet's existing apparatus and the new processor board.
These interfaces will include both basic electronic or optical interfaces, accounting for differences in everything from voltage levels to power needs to basic signal propagation, up to any needed communications protocol translations or interfaces (all this will be very depending on each particular game cabinet and CPU board). In addition to supporting the needed base functionality, in one preferred embodiment each I/O adapter board provides additional functionality and support not previously found in the game cabinet. A primary example of this added support would be an Ethernet connection, which may be used to provide supplemental network support to the game machines, or may be used to replace the older serial communications ports found in existing gaming cabinets. In addition to all this, of course, is simply the increased processing power available from the new processor board. In the case of the I/O adapter board for the IGT® game cabinet illustrated in
Power to the processor board is supplied using voltage and power regulators adapted to use the +13V and +25V power supplies in the game cabinet, to supply regulated power. Four more corn ports are supplied (in addition to the four supplied by the industry standard processor board) for a total of eight corn ports. One corn port is brought to the front of the processor board or tray where it may be used with an optional touchscreen controller.
A VGA port and a keyboard port are supplied in the I/O adapter board to allow a game independent monitor and input/output device to be hooked up to the game cabinet for development, troubleshooting, and monitoring purposes. For this application, the VGA port is also used to drive the game cabinet's standard video monitor.
An Ethernet connection is provided that may be used in addition to, and eventually in place of, the standard game cabinet's serial port connection to RGCs or other gaming equipment, or the rest of the casino's networked infrastructure. The Ethernet may be used to provide two-level authentication, which further enables age verification and other capabilities as described in co-pending application Ser. No. 09/908,878 entitled “Enhanced Player Authentication Using Biometric Identification”, incorporated herein by explicit reference. Further, the Ethernet connection may be used to enable the use of web-based interfaces between machines, both locally and remotely.
The IGT® game cabinet currently under discussion uses a proprietary serial multi-drop RS485-based communications channel for several devices on the same wire. The I/O adapter board has been designed to have only the bill validator connected using this particular RS485 channel. Other devices are connected using other serial connectors built into the I/O adapter board. Since other devices, such as touch-screen controllers, are controlled by other interface means provided by the replacement board, resulting in one device coupled to the original single serial line, there is no need for any type of multi-device communications protocol on the RS485 channel. With only a single device on the channel, any issues surrounding the use of a proprietary serial interface for multiple devices are avoided. The I/O adapter board further provides an interface for the game cabinet's SENET circuitry (a readily available protocol), which interfaces to the display lights, player buttons, etc.
Further, the I/O adapter board includes NVRAM with power management and a battery backup to save any needed game device state in the event of a power loss. Additionally, the I/O adapter board may be reconfigured in the future, and replaced as an individual item separately from the processor board, to incorporate any additional functionality that is needed by newer games, new markets, or newer player input/output devices. Examples include but are not limited to better graphics, better sound, interactive web capabilities using a high speed network connection such as 100 MB Ethernet, multiple game support, audio support for players with limited eyesight capabilities, and newer, more interactive player I/O devices. The same concept holds true of the processor (or CPU) board. The CPU board may be replaced separately from the I/O adapter board. This allows very economical upgrades of the game cabinet to be carried out in those situations where a new CPU board may be all that is needed to support, for example, games requiring a higher performance CPU but nothing else.
Additionally, if the CPU board ever fails, the replacement is significantly less expensive than the older proprietary boards. Not only that, this avoids the problem of finding replacements for aging electronics. Because the two-board processor board set of a disclosed embodiment uses an industry standard form and function, if existing CPUs, busses, etc., become unavailable (which can happen quickly, given that many designs have a total life span of less than two years now) the game may be kept in operation by replacing the CPU board, or both the I/O adapter board and CPU board. This circumvents the problem of finding replacement electronic components of an older board that are no longer being manufactured.
This further addresses the very significant issue of obsolescing OEM boards. In the high tech industry, after a board product has been out a few years, it becomes increasingly likely that at least some, if not most, of the boards components (chips) will gradually become unavailable. When this happens, it sometimes becomes impossible to continue manufacturing the same OEM boards as replacements for failed boards, even if the original game cabinet manufacturer wanted to continue to supply parts (and many do not, after a certain point in time). The OEM is now faced with re-engineering a new replacement CPU board for an older, low-demand game cabinet. That will rarely ever be done. The two-board processor board set addresses this problem by allowing the I/O adapter board to be produced relatively inexpensively, providing continuing life of older game cabinets through the use of standard form-factor CPU boards with the I/O adapter board.
FIG.5 is an functional block diagram of the gaming kernel 500 of a disclosed embodiment. Game software uses the gaming kernel and two-board processor board set by calling into application programming interface (API) 502, which is part of the game manager.
There are three layers: the two-board processor board set (hardware); the Linux operating system; and, the game kernel layer (having the game manager therein). The third layer executes at the user level, and itself contains a major component called the I/O Board Server. Note the unique architecture of the gaming kernel: ordinarily, the software identified as the I/O Board Server would be inside the Linux kernel as drivers and controllers. It was decided that as many functions normally found in a UNIX (in this case, Linux) kernel would be brought to the user level as possible. In a multi-user or non-dedicated environment, this would cause performance problems and possibly security problems. It has been discovered that in a gaming machine, those risks are manageable. Performance is maintained due to the control of overall system resource drains in a dedicated environment, coupled with ability to choose a suitably fast processor as part of the two-board processor board set. Additionally, gaming software is highly regulated so the ordinary security concerns one would find in an open user environment (or where uncontrolled applications may be run) does not exist in gaming machines. Game application software is well-behaved, creating a benign environment as far as attacks from installed software are concerned. To properly set the bounds of game application software (making integrity checking easier), all game applications interact with the gaming kernel using a single API in the game manager. This enables game applications to make use of a well-defined, consistent interface as well as making access points to the gaming kernel controlled, where overall access is controlled using separate processes.
The game manager parses the incoming command stream and, when a command dealing with I/O comes in, it is sent to the applicable library routine (the actual mechanisms used are the UNIX or Linux IPC capabilities). The library routine decides what it needs from a device, and sends commands to the I/O Board Server (arrow 508). Note that a few specific drivers are still in the UNIX/Linux kernel, shown as those below line 506. These are built-in, primitive, or privileged drivers that were (i) general, (ii) kept to a minimum, and (iii) easier to leave than extract. In such cases, the low-level communications is handled within UNIX or Linux and the contents passed to the library routines.
Thus, in a few cases library routines will interact with drivers inside the operating system which is why arrow 508 is shown as having three directions (between library utilities and the I/O Board Server, or between library utilities and certain drivers in the operating system). No matter which path is taken, the “smarts” needed to work with each device is coded into modules in the user layer of the diagram. The operating system is kept simple, stripped down, and common across as many platforms as possible. It is the library utilities and user-level drivers that change for each two-board processor board set, as dictated by the game cabinet or game machine in which it will run. Thus, each game cabinet or game machine will have an industry standard processor board connected to a unique, relatively dumb, and as inexpensive as possible I/O adapter board, plus a gaming kernel which will have the game-machine-unique library routines and I/O Board Server components needed to enable game applications to interact with the game machine (game cabinet). Note that these differences will be invisible to the game application software with the exception of certain functional differences (i.e., if a box or cabinet has stereo sound, the game application will be able make use of the API to use the capability over that of a cabinet having traditional monaural sound).
Examples of the “smarts” built into user-level code of a disclosed embodiment includes the following. One example is using the I/O library to write data to the gaming machine EEPROM, which is located in the gaming machine cabinet and holds meter storage that must be kept even in the event of power failure. The game manager calls the I/O library function to write data to the EEPROM. The I/O Board Server receives the request and starts a low priority thread within the server to write the data. This thread uses a sequence of 8 bit command and data writes to the EEPROM device to write the appropriate data in the proper location within the device. Any errors detected will be sent as IPC messages to the game manager. All of this processing is asynchronous.
Another example is the button module within the I/O Board Server, which pools (or is sent) the state of buttons every 2 milliseconds. These inputs are debounced by keeping a history of input samples. Certain sequences of samples are required to detect the button was pressed, in which case the I/O Board Server sends an IPC event to the game manager that a button was pressed or released. For some machines with intelligent distributed I/O to which debounces the buttons, the button module may be able to communicate with the remote intelligent button processor to get the button events and relay them to the game manager via IPC messages.
Another example is the use of the I/O to library for pay out requests from the game application. The I/O to Board Server must start the hopper motor, constantly monitor the coin sensing lines of the hopper, debounce them, and send an IPC message to the game manager when each coin is paid.
The I/O library interface has been designed so that the I/O to Board Server does not require novram data storage. All novram state flow is programmed in the game manager level (using library utilities) so that it is consistent across all platforms. The I/O to Board Server also contains intelligence and a lot of state information. The intelligence needed to interface with each device is found in the combination of I/O library routines and the I/O Board Server.
The use of a UNIX-based operating system allows the game developers interfacing to the gaming kernel to use any of a number of standard development tools and environments available for the UNIX or Linux OS. This is a huge win over the prior art in casino game development, which required game developers to use low level, proprietary interfaces for their games. The use of proprietary, low-level interfaces in turn requires significant time and engineering investments for each game upgrade, hardware upgrade, or feature upgrade. A disclosed embodiment is a very significant step in reducing both development costs and enhancement costs as viewed by game developers. In particular, this will enable smaller game developers to reasonably compete with the larger, more established game developers by significantly reducing engineering time using a UNIX or Linux environment. Savings include but are not limited to reduced development time, reduced development costs, and the ability to use the gaming kernel and its two-board processor board set to market a single game for many game cabinets, spanning multiple game machine vendors. This is a remarkable and significant breakthrough for the gaming industry, being an additional breakthrough beyond simply providing a standard UNIX-like interface to a game developer.
Some gaming kernel components are next described. The gaming kernel of a disclosed embodiment is also called the Alpha Game Kit kernel or Alpha Game Kit game kernel, abbreviated AGK game kernel or AGK kernel.
The Game Manager provides the interface into the AGK game kernel, providing consistent, predictable, and backwards compatible calling methods, syntax, and capabilities (game application API). This enables the game developer to be free of dealing directly with the hardware, including the freedom to not have to deal with low-level drivers as well as the freedom to not have to program lower level managers (although lower level managers may be accessible through the Game Manager's interface if a programmer has the need). In addition, the freedom derived from not having to deal with the hardware level drivers and the freedom of having consistent, callable, object oriented interfaces to software managers of those components (drivers), the game manager provides access to a set of upper level managers also having the advantages of consistent callable, object-oriented interfaces, and further providing the types and kinds of base functionality required in all casino-type games. The game manager, providing all the advantages of its consistent and richly functional interface as support by the rest of the AGK kernel, thus provides the game developer with a multitude of advantages.
The Game Manager has several objects within itself, including an Initialization object. The Initialization object performs the initialization of the entire game machine, including other objects, after the game manager has started its internal objects and servers in appropriated order. In order to carry out this function, the Configuration Manager is amongst the first objects to be started; the Configuration manager has data needed to initialize (correctly configure) other objects or servers.
After the game is brought up (initialized) into a known state, the Game Manager checks the configuration and then brings either a game or a menu object. The game or menu object completes the setup required for the application to function, including but not limited to setting up needed callbacks for events that are handled by the event manager, after which control is passed back to the Game Manager. The Game Manager now calls the game application to start running; the game machine is made available for player use.
While the game application is running (during game play, typically), the application continues to make use of the Game Manager. In addition to making function calls to invoke functionality found in the AGK kernel, the application will receive, using the callbacks set up during initialization and configuration, event notification and related data. Callback functionality is suspending if an internal error occurs (“Tilt event”) or if a call attendant mode is entered. When this state is cleared, event flow continues.
In a multi-game or menu-driven environment, the event callbacks set by a game application during its initialization are typically cleared between applications. The next application, as part of its initialization sequence, sets any needed callbacks. This would occur, for example, when a player ends one game, invokes a menu (callbacks cleared and reset), then invokes a different game (callbacks cleared and reset).
The Game Event Log Manager is to provide, at the least, a logging or logger base class, enabling other logging objects to be derived from this base object. The logger (logger object) is a generic logger; that is, it is not aware of the contents of logged messages and events. The Log Manager's job is to log events in NVRAM event log space. The size of the space if fixed, although the size of the logged event is not. When the event space or log space fills up, a preferred embodiment will delete the oldest logged event (each logged event will have a time/date stamp, as well as other needed information such as length), providing space to record the new event. In this embodiment the latest events will be found in NVRAM log space, regardless of their relative importance. Further provided is the capability to read the stored logs for event review.
The Meter Manager manages the various meters embodied in the AGK kernel. This includes the accounting information for the game machine and game play. There are hard meters (counters) and soft meters; the soft meters are stored in NVRAM to prevent loss. Further, a backup copy of the soft meters is stored in EEPROM. In one preferred embodiment, the Meter Manager receives its initialization data for the meters, during startup, from the Configuration (Config) Manager. While running, the Cash In and Cash Out Managers call the Meter Manager's update functions to update the meters, and the Meter Manager will, on occasion, create backup copies of the soft meters by storing the soft meters readings in EEPROM; this is accomplished by calling and using the EEPROM Manager.
The Progressive Manager manages progressive games playable from the game machine. It receives a list of progressive links and options from the Config Manager on startup; the Progressive Manager further registers progressive event codes (“events”) and associated callback functions with the Event Manager to enable the proper handling of progressive events during game play, further involving other components such as Coin Manager, perhaps the Meters Manager, and any other associated or needed modules, or upper or lower level managers. This enables the game application to make use of a progressives known to the game machine via the network in the casino; the progressives may be local to the casino or may extend beyond the casino (this will be up to the casino and its policies).
The Event Manager object is generic, like the Log Manager. The Event Manager does not have any knowledge of the meaning of events; rather, its purpose is to handle events. The Event Manager is driven by its users; that is, it records events as being passed onto it by other processes, and then uses its callback lists so that any process known to the Event Manager and having registered a callback event number that matches the event number given to the Event Manager by the event origination process, will be signalled (“called”). Each event contains fields as needed for event management, including as needed and designed, a date/time stamp, length field, an event code, and event contents.
The Focus Manager object correlates which process has control of which focus items. During game play, objects can request a focus event, providing a callback function with the call. This includes the ability to specify lost focus and regained focus events. In one embodiment, the Focus Manager uses a FIFO list when prioritizing which calling process gets their callback functions handled relating to a specific focus item.
The Tilt Manager is an object that receives a list of errors (if any) from the Configuration Manager at initialization, and during play from processes, managers, drivers, etc., that generate errors. The Tilt Manager watches the overall state of the game, and if a condition or set of conditions occur that warrant it, a tilt message is sent to the game application. The game application then suspends play, resumes play, or otherwise responds to the tilt message as needed.
The Random Number Generator Manager is provided to allow easy programming access to a random number generator (RNG), as a RNG is required in virtually all casino-style (gambling) games. The RNG Manager includes the capability of using multiple seeds by reading RNG seeds from NVRAM; this can be updated/changed as required in those jurisdictions that require periodic seed updates.
The Credit Manager object manages the current state of credits (cash value or cash equivalent) in the game machine. The Cash In and Cash Out objects are the only objects that have read privileges into the Credit Manager; all other objects only have read capability into the public fields of the Credit Manager. The Credit Manager keeps the current state of the credits available, including any available winnings, and further provides denomination conversion services.
The Cash Out Manager has the responsibility of configuring and managing monetary output devices. During initialization the Cash Out Manager, using data from the Configuration Manager, sets the cash out devices correctly and selects any selectable cash out denominations. During play, a game application may post a cash out event through the Event Manager (the same way all events are handled), and using the callback posted by the Cash Out Manager, the Cash Out Manager is informed of the event. The Cash Out Manager updates the Credit Object, updates its state in NVRAM, and sends an appropriate control message to the device manager that corresponds to the dispensing device. As the device dispenses dispensable media, there will typically be event messages being sent back and forth between the device and the Cash Out Manager until the dispensing finishes, after which the Cash Out Manager, having updated the Credit Manager and any other game state (such as some associated with the Meter Manager) that needs to be updated for this set of actions, sends a cash out completion event to the Event Manager and to the game application thereby.
The Cash In Manager functions similarly to the Cash Out Manager, only controlling, interfacing with, and taking care of actions associated with cashing in events, cash in devices, and associated meters and crediting. Further details, including disclosure of the lower level fault handling and/or processing, are included in the provisional from which this utility application receives date precedence, entitled “Form Fitting Upgrade Board Set For Existing Game Cabinets” and having Ser. No. 60/313,743, said provisional being fully incorporated herein by explicit reference.
Referring now to
In one non-limiting example the game conversion system 600, a legacy MPU board (e.g., an S6000 MPU board) is replaced with a board capable of running enhanced platform code (e.g., Alpha code), thus, enabling conversion of S6000 game cabinets to Alpha-based software (e.g., A6000). In another non-limiting example the game conversion system 600, an EPROM board is added to an existing Alpha MPU board (e.g., S9000C). In both non-limiting embodiments, the game conversion system 600 includes a configuration file generator system 640 which converts legacy data (e.g., S6000 data) from previously submitted and approved EPROMS into files that are usable by an enhanced gaming platform-based (e.g., Alpha-based) gaming machine 630.
In one presently preferred embodiment, the configuration file generator system 640 (e.g., A6000/S9000C A/S-CFG) of the game conversion system 600 reads a binary file that is created from the data contained in the S6000 personality EPROMs and generates a set of A6000/S9000C configuration files necessary for proper operation on the A6000 game personalities on the S9000C game platforms. Notably, the configuration file generator system 640 acts as a translator, and does not alter the original mathematical modelling of any SMI (game programs) processed by the system. In a non-limiting example of one embodiment, the configuration file generator system 640 of the game conversion system 600 enables pre-approved S6000 personalities to be used on Alpha-based stepper-based systems without requiring new development, testing, and submission costs.
In one presently preferred embodiment of the game conversion system 600, a hardware and software of older legacy game 610 personalities (e.g., the S6000 game personalities) are upgrade and/or otherwise enhanced. By replacing an old MPU (e.g., the legacy S6000 MPU) with a hardware version of a newer game platform 620 (e.g., the Alpha platform), the modified game cabinet 630 is able to execute a newer operating system 650 (e.g., the Alpha OS). In such an embodiment, the new hardware is capable of reading most presently approved S6000 game personalities. Thus, the game conversion system 600 enables an enhanced gaming platform 620 (e.g., the Alpha platform) to capitalize on large amounts of previously-certified game products. Accordingly, a legacy game cabinet is generated (e.g., the S6000 cabinet) that has the benefits of an enhanced game platform 620 (e.g., the Alpha platform). Improvement produced by this configuration include, by way of example only, and not be way of limitation: dual SAS (Slot Accounting System), multi-percentage, and multi-denomination.
In one presently preferred embodiment, the game conversion system 600 enhances development and implementation of multi-denomination games (such as on a 3.5″ iView-game type VIDEO display). In another aspect of one embodiment, the game conversion system 600 drives a legacy set of reels (e.g., the S6000 ) reels and the existing LED display. Continuing, in a presently preferred embodiment of the game conversion system 600, the game titles available to an enhanced gaming cabinet/platform 620 (e.g., the A6000) include: by way of example only, and not by way of limitation: (1) Jumpin'Joker (Flaming Sevens); (2) FireBall (FireBall Frenzy); (3) Wacky Winners (Bonus Frenzy); (4) Hat Trick (Nudge); (5) Bonus game (Diamonds and Devils); (6) Monte Carlo (Hit and Run); and (7) S5500 legacy SMIs (game programs).
Additionally, with respect to another aspect of a game conversion system 600, the enhanced gaming cabinet/platform 620 (e.g., the A6000) supports up to three game denominations (due to available EPROM sockets). In other system configurations, still larger amounts of game denominations are possible. Moreover, in still another aspect of a game conversion system 600, the game denominations do not exceed a value ratio of 10:1 (due to the limitation of the four-digit display). However, in other system configurations, larger value ratio are possible. In one embodiment, the presentation of the denominations is to match the one previously developed for an iView-type device. In one embodiment, the cabinet reels in an enhanced gaming cabinet/platform 620 are driven by an internal Reel Control Unit located on the MPU of the new game platform (e.g., A6000). As such, an enhanced gaming cabinet/platform 620 (e.g., A6000) does not require the existing reels to be replaced.
In another aspect of a game conversion system 600, the enhanced gaming cabinet/platform 620 (e.g., A6000) video display is used for the following: (1) game setup/configuration; (2) diagnostics/accounting/game recall; (3) tilt messages; (4) door statuses; (5) ticket in messages; (6) hand pay messages; (7) denomination selection; (8) denomination help screen; (9) credit meter continuously displayed in dollar and cents; and (10) paid meter displayed in dollar and cents upon cashout.
In one presently preferred embodiment, during normal game operations, the video display presents the denominations available to the player. Typically, the selected denomination are highlighted. As described above, in one presently preferred embodiment, the maximum number of selectable denominations is three, although it will be appreciated that in other embodiments, larger or smaller numbers of denominations may be made available to patrons. In another aspect of one embodiment, the video display also presents a help button that, when selected, launches a text screen describing how to use the denomination selection screen to the player.
In one presently preferred embodiment of the game conversion system 600, the components that are addressed during game conversion (from older legacy (e.g., S6000 ) games to newer enhanced game platform-enabled games) include, by way of example only, and not by way of limitation: legacy game personalities, reels, the LED dashboard, button deck, and the IOP board. Regarding the legacy (e.g., S6000 ) personalities, in one embodiment, up to three game personalities (with different payback percentages) are mapped to format enhanced game platform 620 (e.g., Alpha platform). Regarding the reels, in one embodiment, an enhanced game platform 620 (e.g., A6000) supports the number of reels dictated by game, provides a mechanism to calibrate the reels, and modifies the acceleration tables for the reels, if needed.
Referring now to the LED dashboard, in one embodiment, a game conversion system 600 supports an existing legacy dashboard (e.g., S6000 LED dashboard) with 4 digit “win,” 4 digit “credit,” and 2 “coin-in” meters. Regarding the button deck, in one embodiment, an enhanced game platform 620 (e.g., A6000) support five deck buttons, namely a “Cash-out” button, a “Bet One” button, a “Bet Max” button, a “Spin” button, and a “Change” button. In other embodiments, an enhanced game platform 620 supports a 14 button deck. Regarding the IOP (Input/Output Processor) board, in one embodiment, the game conversion system 600 provides replacements for a legacy IOP board (e.g., an S6000 IOP board) with an enhanced game platform board (e.g., Alpha base board) and the capability to store three game personalities. Preferably, the enhanced game platform board provides the application-specific components (e.g., back plane connectors, memory, serial ports, I/O subsections, and the like) for a gaming machine 630. Additionally, all I/O and peripherals supported in the legacy (e.g.,S6000 ) product are supported in the enhanced game platform 620 (e.g., Alpha) as well.
In a presently preferred embodiment, the game conversion system 600 ensures that older legacy games 610 (e.g., S6000 game personalities) played on a newer game platform 620 (e.g., an Alpha game platform): (1) display appropriate games and features, (2) play appropriate sounds for the games and features, (3) implement and verify the translated pay tables, (4) implement and verify that the newer game platform 620 plays and pays appropriate feature, (5) display appropriate game recall information, (6) display appropriate game related tilt information (as well as communicated it to the host if configured for host communication), and (7) verify game related meters.
Referring now to another aspect of the game conversion system 600, an enhanced gaming- platform 620 may utilize a dynamic glass system 700 as a virtual second display. Otherwise stated, an enhanced gaming- platform 620 (e.g., an Alpha platform) includes software support in the operating system 650 that enables a game to utilize a second display screen 670, typically located in the top-box area of a game cabinet 630. This second display screen 670 can be used to enhance a game presentation by showing rich content on the top display screen 670, without altering the flow of the base game that is presented on the first (or bottom) display screen 660. Content is defined herein as subject matter of a visual presentation on an game display. In this regard, the second display screen 670 can by utilized as “dynamic top glass” that presents “game theme content 710” related to the base game. Since many legacy games 610 traditionally included only a single display screen and printed theme content on an upper panel, the game conversion system 600 may utilize the dynamic glass system 700 to present theme content 710 on the second display screen 670 that would previously have been printed “game theme content” on an upper panel in a legacy gaming cabinet. In this manner, the dynamic glass system 700 of the game conversion system 600 may be utilized to: (1) support and enhance legacy games 610 (which are typically single screen) on an enhanced gaming- platform 620 (which often support multiple screens), and (2) enable multiple enhance legacy games 610 to be played consecutively on a gaming cabinet 630 without requiring printed theme content on an upper panel to be replaced or otherwise changed.
Referring to one example, in a multi-game configuration, the dynamic glass system 700 of the game conversion system 600 may change the second display screen 670 to match the selected base game, as chosen by the patron. Similarly, in an environment where games may be downloaded (or otherwise reconfigured) and changed in a moment's notice, the ability to coordinate the second display screen 670 with new base game content is a desirable feature, and is enabled by the dynamic glass system 700 of the game conversion system 600. In the past, changing game theme content on an upper panel required the replacement of the static top glass with a second piece of top glass with corresponding game theme content printed thereon.
Notably, the physical presence of a second display screen 670 provides support for the previously-described features in an enhanced gaming platform 620. However, the second display is of no value (or may even by viewed as a detriment) if the installed game themes (e.g., legacy games 610) do not include any content to display on the second display screen 670. An example of such a situation is presented when a casino (or other establishment having gaming machines 630) purchases gaming machines 630 equipped with a second display in anticipation of using the machines for download applications, but before there is a satisfactory library of approved games that support content 710 for a second display. In such a situation, the dynamic glass system 700 of the game conversion system 600 provides a means to supply surrogate content 710 for the second display screen 670. Accordingly, an enhanced gaming platform 620 (e.g., an Alpha platform) that physically contains a second display screen 670 and uses single display legacy games 610 may have relevant content 710 provided to the second display screen 670 via the dynamic glass system 700. In a preferred embodiment, the dynamic glass system 700 enables operators (e.g., casino operators) to purchase second display hardware for future capabilities and features, yet continue to use a current set of approved game content that does not support a second display screen 670.
As described above, a preferred embodiment of the dynamic glass system 700 affords second display surrogate content capability into an enhanced gaming operating system 650 (e.g., Alpha OS) release that continues to operate in single display screen configurations, as well as support games that contain intrinsic content for second display screen 670. In one embodiment, the dynamic glass system 700 only activates in conditions where applicable. Such a situation includes, by way of example only, and not by way of limitation, where a second display screen hardware is present and single display games are used. While the dynamic glass system 700 is a component of the game conversion system 600, second display screen content 710 that is relevant to the base game content must either previously exist or be created for the second display screen 670. Typically, legacy games 610 were not built with second display screen content 710 for the dynamic glass system 700. Therefore, second display screen content 710 for the dynamic glass system 700 usually must be provided for legacy games 610.
In one presently preferred embodiment, the dynamic glass system content 710 for the second display screen 670 is stored on the operating system 650 (OS) compact flash, in a dedicated partition separate from the OS program. Preferably, the dynamic glass system 700 content partition contains the second display content 710 for a selected set of legacy base games, as described above. In one embodiment, the dynamic glass system 700 content partition is expected to contain a fixed set of content that does not need to be extended. In this regard, future games that are developed from this point forward will either contain their own dynamic glass system content 710 for use by the game conversion system 600, or explicitly drive their own content on the second display screen 670.
In one aspect of a presently preferred embodiment, the dynamic glass system 700 identifies and uses second display screen content 710 that properly corresponds to the base game. In another aspect of one embodiment, in a situation where the correct second display screen content is not present on the game content flash, the dynamic glass system 700 checks for the presence of the correct second display screen content on the dynamic glass system 700 content partition of the OS compact flash. In the event that no properly corresponding second display screen content is available, the dynamic glass system 700 uses default second display screen content from the dynamic glass system 700 content partition of the OS flash memory.
Typically, second display content 710 for the dynamic glass system 700 is limited to a static image (e.g., a PNG file). In this regard, second display screen content 710 for legacy base games that support multiple games, such as multi-poker, must be designed as a generic second display image. In another aspect of a presently preferred embodiment, the dynamic glass system content 710 on the partition of the OS compact flash is authenticated before use by the dynamic glass system 700. In one embodiment, if the authentication fails, the operating system 650 disables play and displays an error message. In still another aspect of a preferred embodiment, the operating system 650 of the game conversion system 600 includes a configuration option for either enabling or disabling the function of the dynamic glass system 700. As such, a single operating system 650 release can support both dynamic glass system 700 and non-dynamic glass system configurations.
In one presently preferred embodiment, the dynamic glass system 700 partition of the operating system 650 compact flash is created as a read-only partition, and is considered non-alterable media. In another aspect of the dynamic glass system 700, base games that control the secondary display screen 670 contain an indicator that the dynamic glass system may use for detection of native support of the secondary display screen 670. In this regard, a presently preferred embodiment of the dynamic glass system 700 detects this condition and mutes itself, so as not to interfere with the second display screen content 710 that is provided by the base game. Accordingly, the dynamic glass system 700 generally (1) does not operate in conjunction with single display screen gaming configurations, (2) does not operate in conjunction with second display screen gaming configurations that are used with second display capable games, but (3) does operate in conjunction with second display screen gaming configurations that are used for single display screen capable games.
Thus, as described above, the dynamic glass system 700 does not interfere with second display screen content 710 provided by a base game. In this manner, base games that intrinsically support second display screens 670 have full control of the second display screen as if the dynamic glass system 700 was not enabled. Additionally, the dynamic glass system 700 detects if the themed content 710 is available for the currently active game theme. Themed content is defined as content that corresponds to the theme of the game. The theme of a game is determined by reading a configuration file on the game compact flash. Thus, the dynamic glass system 700 themed content corresponding to a new single display screen game (that is capable of dynamic glass system 700 capable) is searched for on the game compact flash. If no dynamic glass system 700 themed content is available on the game compact flash, the dynamic glass system 700 themed content corresponding to legacy single display games is searched for on the dynamic glass system 700 content partition of the OS compact flash. If the themed content is not available, the dynamic glass system 700 displays a default (non-themed) image from the dynamic glass system 700 content partition of the OS compact flash.
As described above, the dynamic glass system 700 content partition of the operating system 650 is treated as non-alterable media for regulatory purposes. In this regard, the operating system 650 of an enhanced gaming platform 620 (e.g., the Alpha OS) authenticates the dynamic glass system content 710 on the dynamic glass system partition of the OS compact flash using the same security (regulatory approved) techniques employ by the Alpha platform 620 to authenticate the OS and game flash. Authentication failures tilt the machines 630 and display appropriate error messages. In another aspect of one embodiment, the operating system 650 of an enhanced gaming platform 620 (e.g., the Alpha OS) validate the dynamic glass system content 710 on the dynamic glass system partition of the OS compact flash as a background task. This is consistent with current validation procedures for the operating system 650. Validation failures tilt the machines 630 and display an appropriate error messages.
In another aspect of one embodiment, internationalization and localization requirements may be addressed using the dynamic glass system 700. Specifically, foreign language versions of game themes require dynamic glass system content 710 in the appropriate corresponding language. In this regard, the dynamic glass system 700 considers the exact content needed based upon both the selected game theme, and which language is active. With respect to manufacturing and hardware, the dynamic glass system 700 lends itself primarily to the next generation of Alpha ETX modules, specifically the 1 GHz CPU ETX modules (or better) that have been specified as required for multi-game and multi-screen configurations. With respect to configuration management, dynamic glass system content 710 utilizes digital signing to address security concerns that are regulated by in many markets.
In another preferred embodiment of the dynamic glass system 700, a USB dongle (connected to a flash memory device) is used to store glass folder displays (e.g., virtual themed content displays that mimic printed display panels) for the second display screen 670 of a dual screen video platform. One specific non-limiting example in which this embodiment of the dynamic glass system 700 is useful, relates to international games (which require foreign language text). Prior to the advent of the dynamic glass system 700 (the USB dongle/flash memory embodiment or otherwise), each different game flash (for each country and/or language) required its own individual game theme and language. Thus, a single game theme potentially had 12 or more game flashes that had to be developed, approved, and certified by gaming regulators. This procedure produced a large impediment on game development, certification, and delivery. As such, obtaining completed international graphics has traditionally been a major impact on game delivery schedule.
Through the implementation of the dynamic glass system 700 (using a USB dongle connected to a flash memory device) this obstacle can be overcome. In this regard, by using an existing USB dongle, and loading the needed movie and/or graphics files (that contain the language pack) onto a USB flash memory key, the dynamic glass system 700 enables language files to be updated by simply swapping USB flash memory keys in the USB dongle. Accordingly, when the game looks for movies and/or graphics, the game is sent to check the flash memory key for any additional selections that may be available to the player. Without a USB flash memory key inserts into the USB device, the game still functions, but simply with fewer movie and/or graphic files available from which a player may choose. Typically, games are released as English-only on standard compact flash. In a presently preferred embodiment of the dynamic glass system 700 (using a USB dongle connected to a flash memory device), when booting up the system, the games respond to instruction to: (1) query whether a USB drive is attached (with a language pack in a flash memory key), (2) verify the USB drive, if identified, with some lock/key encryption method (thereby preventing incorrect game theme packs, nefarious data, and the like), and (3) mount the USB drive over the directory where the game normally finds its graphics and language strings.
This embodiment of the dynamic glass system 700 (using a USB dongle connected to a flash memory device) enables game manufactures to develop, approve, and certify only the English version of a game (which contains the binary game code). Meanwhile, as the graphics department creates different international versions of a game theme, the game manufacture simply releases a new language pack for that theme. Preferably, the new language pack has a separate part number that is simply ordered when a game is needed that operates in a different language. In this manner, by using such an embodiment of the dynamic glass system 700 (using a USB dongle connected to a flash memory device), a whole floor of gaming machines 630 may be converted from English to French simply by opening the cabinet 630, plugging in a new USP flash memory into the USB drive, and rebooting the gaming machine 630. Although utilizing an embodiment of the dynamic glass system 700 that stores the necessary content 710 in flash memory with the operating system 650 does not require swapping a flash memory device in the USB dongle, utilizing the USB dongle flash memory may overcome memory limitation associated with the operating system flash memory, as well as enable later developed content to be easily connected to the system.
In a presently preferred embodiment of the dynamic glass system 700 (using a USB dongle connected to a flash memory device), only minimal modification to the OS (operating system 650) are required. In this regard, simply add USB_STORAGE driver (which is a driver that is already present in the kernel). Changes to the game code are also minimal. The new code simply mounts a present external drive over the current game flash “pictures” directory. Typically, all pathnames and references to graphic files are transparent.
A disclosed embodiment has been partially described using flow charts. As will be understood by a person of ordinary skill in the art and with the benefit of the present disclosure, steps described in the flow charts can vary as to order, content, allocation of resources between steps, times repeated, and similar variations while staying fully within the inventive concepts disclosed herein.
Persons of ordinary skill in the art will realize that the following description of a disclosed embodiment is illustrative only and not in any way limiting. Other embodiments of the invention will readily suggest themselves to such skilled persons having the benefit of this disclosure. Although the description above contains much specificity, the description should not be construed as limiting in scope; the descriptions given are merely providing an illustration of disclosed embodiments. The scope of the disclosed embodiments is determined by the appended claims and their legal equivalents.
Claims
1. A method for enabling play of legacy games on a previously-incompatible enhanced gaming platform that provides enhanced functionality using a game conversion system, the method comprising:
- providing a game cabinet for a gaming machine;
- operatively associating an enhanced gaming platform with the gaming machine, wherein the enhanced gaming platform includes an enhanced gaming operating system and an enhanced gaming processor board;
- loading one or more legacy games onto the enhanced gaming platform, wherein the one or more legacy games are configured to operate on a legacy gaming platform, and wherein the one or more legacy games are not natively configured to operate on an enhanced gaming platform;
- converting legacy data from legacy game EPROMS into files usable by the enhanced gaming platform via a configuration file generator system; and
- enabling game play of the one or more legacy games using the converted legacy data on the enhanced gaming platform, wherein the enhanced gaming platform provides increased functionality associated with the platform;
- whereby the game conversion system increases the number of game titles that are available to be played on the newer game platforms by enabling operability of legacy games, and whereby the game conversion system decreases the amount of certification processing required by utilizing previously-certified legacy games.
2. The method of claim 1, wherein the enhanced gaming platform enables increased functionality while playing a legacy game includes, dual slot accounting system functionality, multi-percentage gaming, and multi-denomination gaming, and combinations thereof.
3. The method of claim 1, wherein legacy data is from legacy game EPROMS that have been previously submitted and approved by game regulators.
4. The method of claim 1, wherein the legacy data comprises S6000 gaming data.
5. The method of claim 1, wherein the enhanced gaming platform comprises an Alpha platform.
6. The method of claim 1, wherein the configuration file generator system reads a binary file created from data contained in the legacy game EPROMS and generates a set of configuration files necessary for proper operation of game personalities on an enhanced gaming platform.
7. The method of claim 1, wherein the configuration file generator system acts as a translator, and wherein the configuration file generator system does not alter any original mathematical modeling of a game program processed by the system.
8. The method of claim 1, wherein the game conversion system enables pre-approved legacy game personalities to be used on enhanced gaming platform-based systems without requiring new development, testing, and submission costs.
9. The method of claim 1, wherein the legacy game titles available to an enhanced gaming platform are selected from the group consisting of: jumpin'joker, flaming sevens; fireball, fireball frenzy; wacky winners, bonus frenzy; hat trick, nudge; bonus game, diamonds and devils; monte carlo, hit and run; and S5500 legacy game programs.
10. The method of claim 1, wherein the enhanced gaming platform running a legacy game using the game conversion system supports up to three game denominations.
11. The method of claim 1, wherein the enhanced gaming platform running a legacy game using the game conversion system supports up game denominations do not exceed a value ratio of 10:1.
12. The method of claim 1, wherein a video display of enhanced gaming platform enabled gaming machine using the game conversion system supports utilities selected from the group consisting of: game setup/configuration; diagnostics/accounting/game recall; tilt messages; door statuses; ticket in messages; hand pay messages; denomination selection; denomination help screen; credit meter continuously displayed in dollar and cents; and paid meter displayed in dollar and cents upon cashout.
13. A method for enabling play of single display screen games on a enhanced gaming platform while providing related content on a second display screen using a game conversion system, the method comprising:
- providing a game cabinet for a gaming machine, wherein the gaming includes at least a first display screen and a second display screen;
- operatively associating an enhanced gaming platform with the gaming machine, wherein the enhanced gaming platform includes an enhanced gaming operating system and an enhanced gaming processor board, and wherein the enhance gaming operating system supports the first and second display screens;
- loading one or more legacy games onto the enhanced gaming platform, wherein the one or more legacy games are configured to operate on only a single display screen, and
- presenting game theme content on the second display screen when a single display screen game operates on the single display screen using a dynamic glass system, wherein the dynamic glass system presents game theme content on the second display screen that is related to the single display screen game if related game theme content is available.
14. The method of claim 13, wherein the second display screen is located in the upper panel of a gaming machine.
15. The method of claim 13, wherein game theme related content that was previously printed on an upper panel of a legacy gaming machine that supported single display screen game is virtually mimicked on the second display screen of enhanced gaming platform based gaming machine using the dynamic glass system.
16. The method of claim 13, wherein dynamic glass system changes content presented on the second display screen to correspond to a currently selected single display screen game presented on the first display screen.
17. The method of claim 13, wherein the single display screen game is selectable by the patron, thereby enabling multiple enhance legacy games to be played consecutively on a gaming cabinet without requiring printed theme content on an upper panel to be replaced or otherwise changed.
18. The method of claim 13, wherein dynamic glass system enables second display surrogate content capability into an enhanced gaming operating system release, wherein the dynamic glass system supports both games having single display screen configurations and games containing intrinsic content for second display screen.
19. The method of claim 18, wherein the dynamic glass system only activates, and presents game theme content on the second display screen, when the system detects a single display screen game in operation.
20. The method of claim 13, wherein the game theme content for the second display screen is stored on the operating system compact flash.
21. The method of claim 13, wherein the game theme content for the second display screen is stored on the operating system compact flash in a dedicated partition of the operating system program.
22. The method of claim 21, wherein the dedicated partition of the operating system program in which the game theme content for the second display screen is stored, is a read-only partition, wherein the game theme content for the second display screen is non-alterable media.
23. The method of claim 13, wherein the game theme content for the second display screen is a static image.
24. The method of claim 13, wherein the game theme content for the second display screen is multi-media.
25. The method of claim 13, wherein the dynamic glass system first checks a game compact flash for second display screen content, and if second display screen content is not present on the game content flash, the dynamic glass system checks for second display screen content on the operating system compact flash, and if second display screen content is not present on the operating system compact flash, the dynamic glass system uses default second display screen content from the operating system compact flash.
26. The method of claim 13, wherein second display screen content that is stored on a partition of the operating system compact flash is authenticated before use by the dynamic glass system.
27. The method of claim 26, wherein the operating system disables game play and displays an error message if authentication of the second display screen content fails.
28. The method of claim 13, wherein the operating system of the game conversion system includes a configuration option for enabling or disabling the dynamic glass system.
29. The method of claim 13, wherein game theme content for the second display screen includes a plurality of language components that enable games to be quickly converted from a first displayed game in a first language to the first displayed game in a second language using the dynamic glass system.
30. A method for enabling play of single display screen games on a enhanced gaming platform while providing related content on a second display screen using a game conversion system, the method comprising:
- providing a game cabinet for a gaming machine, wherein the gaming includes at least a first display screen and a second display screen;
- operatively associating an enhanced gaming platform with the gaming machine, wherein the enhanced gaming platform includes an enhanced gaming operating system and an enhanced gaming processor board, and wherein the enhance gaming operating system supports the first and second display screens, wherein the enhanced gaming platform includes a universal serial bus dongle connection, and wherein a universal serial bus flash memory device is attachable to the dongle connection; and
- presenting game theme content on the second display screen when a single display screen game operates on the single display screen using a dynamic glass system, wherein the dynamic glass system presents game theme content on the second display screen that is related to the single display screen game from the universal serial bus flash memory device is attached to the dongle connection.
31. The method of claim 30, wherein the second display screen related to the single display screen game stored in the universal serial bus flash memory device is language data for corresponding foreign games.
Type: Application
Filed: Nov 13, 2006
Publication Date: Jun 7, 2007
Inventors: Robert Crowder (Las Vegas, NV), Sreekanthan Iyer (Las Vegas, NV), Anandkumar Singh (Las Vegas, NV), Patrick Spiller (Las Vegas, NV), Warren Mitchell (Las Vegas, NV), Alexandra Kinsella (Las Vegas, NV), Jose Rosario (Henderson, NV), Rodney Hill (Sparks, NV), Shawn Quick (Sparks, NV)
Application Number: 11/559,403
International Classification: A63F 9/24 (20060101);
