US20090117995A1

US20090117995A1 - Method of credit input and a gaming system

Info

Publication number: US20090117995A1
Application number: US12/134,124
Authority: US
Inventors: Martin Stephen Lyons; Robert Linley Muir
Original assignee: Aristocrat Technologies Australia Pty Ltd
Current assignee: Aristocrat Technologies Australia Pty Ltd
Priority date: 2007-06-07
Filing date: 2008-06-05
Publication date: 2009-05-07
Also published as: EP2000995A2; AU2011202440B2; EP2000995A3; AU2011202440A1; AU2008202090A1

Abstract

A gaming system for multiple players using horizontal touch screen displays. A credit input/output mechanism receives currency or a trading device, and may include an input amount. A credit record is generated as well as an associated unique credit identifier. Credits specified by the credit record may be allocated relative to a player interface in accordance with input to a touch screen display.

Description

RELATED APPLICATIONS

This application claims priority to Australian Provisional Patent Application No. 2007903070, having an international filing date of Jun. 7, 2007, entitled “Method of Credit Input and a Gaming System,” which is hereby incorporated by reference herein in its entirety.

FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

[Not Applicable]

MICROFICHE/COPYRIGHT REFERENCE

[Not Applicable]

BACKGROUND OF THE INVENTION

The present invention relates to a method of credit input and a gaming system. Traditionally, electronic gaming machines have taken the form of slot machines where a player plays a game involving reels that spin and prizes are awarded based on the position at which the reels stop relative to win lines selected by the player. Originally, these machines were mechanical with physically rotating reels. In many modern slot machines, the mechanical reels have been replaced by “virtual reels displayed as spinning on a video display.
More recently, there has been a move towards implementing other types of games such as table games including poker, blackjack or roulette on electronic gaming machines including as multi-player games. Motivations for doing so include that less staff may be required and games can be played more quickly when a human dealer or croupier is replaced by a gaming machine.
As such games are developed, there is a need to provide a credit input technique which suits these game types.

BRIEF SUMMARY OF THE INVENTION

In a first aspect, the invention provides a method of credit input for a multi-player gaming system, the method comprising:

- receiving a credit input;
- generating a credit record associated with a gaming system including data indicative of the credit input; and
- associating a credit identifier with the credit record.

In an embodiment, the method further comprises receiving the credit identifier from a player interface of the gaming system; and allocating the credit specified by the credit record to the player interface.
In an embodiment, the method further comprises issuing the credit identifier.
In an embodiment, the method further comprises associating a player provided credit identifier with the credit record.
In an embodiment, the method further comprises displaying one or more tokens corresponding to the credit record on a display of the multi-player gaming system.
In an embodiment, the method comprises issuing a request for the credit identifier in response to an attempt to allocate the one or more tokens with a player interface.
In an embodiment, the method comprises monitoring for an attempt to allocate one or more tokens with a player interface by monitoring for an attempt to move the one or more tokens to within the player interface.
In an embodiment, an attempt to allocate one or more tokens with a player interface comprises an attempt to move the one or more tokens to a designated part of the player interface.
In an embodiment, the display is a touch screen display and the method comprises monitoring the output of the touch screen for an attempt to move the one or more tokens.
In an embodiment, receiving a credit input comprises receiving a ticket having a credit value.
In an embodiment, receiving a credit input comprises obtaining credit from a player account.
In an embodiment, the player account is linked to a player tracking device.
In an embodiment, receiving a credit input comprises receiving a currency input.
In a second aspect, the invention provides a multi-player gaming system comprising:

- a credit input mechanism; and
- a credit manager arranged to:
  - generate a credit record including data indicative of the credit input; and
  - associate a credit identifier with the credit record.

In an embodiment, the credit manager is further arranged to:

- receive the credit identifier from a player interface of the gaming system; and
- allocate the credit specified by the credit record to the player interface.

In an embodiment, the gaming system comprises a player interface controller adapted to provide a plurality of player interfaces.
In an embodiment, the credit manager is adapted to issue a request for the credit identifier in response to an attempt to allocate the credit record to a player interface.
In an embodiment, the gaming system comprises a touch screen display and the player interface controller is adapted to provide at least part of each player interface on with the touch screen display.
In an embodiment, the credit manager is arranged to cause the display to initially display one or more tokens corresponding to the credit record at a position separate to each player interface.
In an embodiment, the touch screen is operable to allow a player to move the one or more tokens from the initial display position to a player interface to attempt to allocate the credit record.
In an embodiment, each player interface is operable to enter a credit identifier.
In an embodiment, the player interface controller is adapted to add and remove player interfaces.
In an embodiment, the credit input mechanism comprises a bill acceptor.
In an embodiment, the credit input mechanism comprises a coin acceptor.
In an embodiment, the credit input mechanism comprises a ticket reader.
In an embodiment, the credit input mechanism is adapted to obtain a credit amount from a player account.
In an embodiment, the display is a horizontal display.
In an embodiment, the display is 2-3 m across the diagonal.
In a third aspect, the invention provides a credit manager for a multi-player gaming system arranged to:

- process a credit input;
- generate a credit record based on the credit input; and
- associate a credit identifier with the credit record.

In an embodiment, the credit manager is further adapted to issue a request for the credit identifier in response to an attempt to allocate the credit record to a player interface of the gaming system.
In an embodiment, the credit manager is arranged to cause a display of the gaming system to initially display one or more tokens corresponding to the credit record at a position separate to the player interface.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

An embodiment incorporating all aspects of the invention will now be described in relation to the accompanying drawings in which:

FIG. 1 is a plan view of a gaming table of an embodiment;

FIG. 2 is a functional block diagram of a gaming system on an embodiment;

FIG. 3 is a further block diagram showing a credit manager in more detail;

FIG. 4 is a schematic diagram showing a networked embodiment;

FIG. 5 is a schematic diagram of a player interface;

FIG. 6 is a schematic diagram of a player interface where a player enters a code;

FIG. 7 is a schematic diagram of a player interface updated after tokens have been assigned to a player; and

FIG. 8 is a flowchart showing a method of the embodiment.

DETAILED DESCRIPTION OF THE INVENTION

Referring to the drawings, there is shown a gaming system arranged to handle credit input in respect of a multi-player game. The gaming system is preferably implemented as a virtual gaming table, where a horizontally oriented touch screen display is used by players to participate in a game. The gaming system can take a number of different forms.
In a first form, a stand alone gaming table is provided wherein all or most components required for implementing the game are present or located next to a player operable virtual gaming table.
In a second form, a distributed architecture is provided wherein some of the components required for implementing the game are present located with the gaming table and some of the components are located remotely. For example, a “thick client” architecture may be used wherein part of the game is executed locally by the player operable gaming table and part of the game is executed remotely, such as by a gaming server; or a “thin client” architecture may be used wherein most of the game is executed remotely such as by a gaming server and a player operable gaming table is used only to display audible and/or visible gaming information to the player and receive gaming inputs from the player.
However, it will be understood that other arrangements are envisaged. For example, an architecture may be provided wherein a gaming table is networked to a gaming server and the respective functions of the gaming table and the gaming server are selectively modifiable. For example, the gaming system may operate in stand alone gaming table mode, “thick client” mode or “thin client” mode depending on the game being played, operating conditions, and so on. Other variations will be apparent to persons skilled in the art.
FIG. 1 is a plan view of a virtual gaming table 100 having a horizontally oriented display 120 and a log on terminal 140. As can been from FIG. 1, the gaming table is surrounded by seven chairs 130 indicating seven possible player positions. Two player interfaces 124 a, 124 b are active on the display 120. A central area 122 of the display is used to display information common to all players; in the example shown in FIG. 1 a display of a roulette game.
As shown in FIG. 2, from a functional perspective, a virtual table 200 comprises a game controller 220, a common display 212 and a variable number of player interfaces 210. As described in detail below, in the embodiment the number of player interfaces depends on the number of players playing the game. In some embodiments there may be a single player interface for each player so that each time a player enters the game an interface is added. In other embodiments, a minimum number of player interfaces may always be displayed even though it is possible they are not all being used and additional player interfaces added as necessary, when the minimum is exceeded. Unused interfaces may function in an attract mode. In further embodiments, a player may request an additional player interface. For example, some players may wish to play two hands of cards simultaneously where the gaming table implements a card game.
In the embodiment, a number of the functional modules of the game controller are implemented by a processor 215. However, a person skilled in the art will appreciate that other techniques such dedicated hardware could be used instead of program code running on a processor 215 to implement the required functions.
The game controller's processor 215 processes the game play instructions in accordance with game play rules and outputs game play outcomes to the display. Typically, the game play instructions are stored as program code in a memory 270. Herein the term “processor” is used to refer generically to any device that can process game play instructions in accordance with game play rules and may include: a microprocessor, microcontroller, programmable logic device or other computational device, a general purpose computer (e.g. a PC) or a server.
These functions are carried out based on data such as credit data 272 and game rule data 274 stored in a memory 270 of the game controller 220. The game controller 220 has a number of modules including a display controller 230 for controlling what is displayed both in the common display area 212 of a gaming table 212 and on each of the player interfaces 210.
The display 120 incorporates a touch screen. Herein such a display is referred to as “touch screen display”. Accordingly, it will be appreciated that the player interfaces share a common display 120. A person skilled in the art will appreciate that the “touch screen” sensor need not cover the entire display. For example central area 122 as shown in FIG. 1 need not necessarily have a touch screen capability. The touch screen is preferably a multi-touch screen capable of processing simultaneous or near simultaneous instructions from a number of different players. The display 120 itself is typically a wide screen, large format display such as a plasma or LCD display of a size in the order of 80-120 inches (2 m-3 m) across the diagonal. However, a person skilled in the art will appreciate that the display could be formed a plurality of sub-units located adjacent to one another under the control of the display controller 230 to display both the player interfaces 210 and the common display area 212.
The display controller 230 controls the display to display the individual player interfaces based on data provided by the interface controller 240 and the outcome determiner 260. The interface controller also provides data to the touch screen processor 250 to enable it to interpret touches on the touch screen display, for example, in order to associate them with individual player interfaces 210 and to provide this data to the outcome determiner 260. In this manner, individual player instructions can be correctly provided to the outcome determiner 260 so that the outcome determiner 266 can determine the result of the game based on the game rule data 274. Similarly, the outcome determiner 260 provides data to the display controller 230 regarding the game outcomes for individual players. This may be displayed in a display region of the player interface 210 on the common display or both.
A person skilled in the art will appreciate that depending on the game, the outcome determiner 260 may determine independent results for each player such as in a game like roulette or results that depend on the game play of other players such as in a competitive game like poker. Credit data 272 is maintained separately for each player interface in memory 270. The log-on terminal 280 typically includes a touch screen display allowing a player to enter their name and assign to themselves a player position number—i.e. a particular player interface. Alternatively the player position maybe assigned by the game system. In alternative embodiments, players may be assigned positions anonymously by providing them with a temporary access code, printed by the log-on terminal on a voucher. In still further embodiments, the player is given an entitlement to a player interface by the log-on process and the player interface is allocated or generated based on where the player sits relative to the table.
To participate in the game a player uses the log-on terminal 280 to request a player interface for the game either manually, or by swiping or otherwise providing a player tracking device to the log on terminal 280. That is, depending on the embodiment the log on terminal may read magnetic cards, smart cards, RFID tags or another suitable data carrier.
The player may also use the log-on terminal to log out of the game or alternatively may operate the player interface to log out of the game.
At least one credit input/output mechanism 290 is provided which can be shared by all players of the gaming system.
In one embodiment, the credit input/output mechanism includes a voucher printer 295. A player provides credit to the credit input/output 290 by inserting currency using a bill 291 or coin 292 acceptor or by providing their player trading device to the reader 294 and specifying an amount, e.g. by use of a keypad 296, to be retrieved from an account associated with the trading device which may be stored on a player account server 412 such as is shown in FIG. 4. Credit manager 300 processes data received from the credit record and the credit creates a record in credit data 272 specifying the amount of input credits and associates a credit identifier with the credit record, typically by generating a unique credit identifier. A voucher is printed by a voucher printer 295. The voucher has the credit identifier on it so that the player can enter it at a player interface 210 using a virtual key pad. The credit manager controller 220 processes the input credit identifier and verifies it against records stored as credit data 272. If the credit identifier is verified, the amount of credit is associated with the player interface used to enter the credit identifier. In this respect, a credit balance is maintained within the credit data for each player interface. Thus, the credit is transferred to the credit balance for the player interface. Once the player interface has been allocated the credit, tokens corresponding to the credit will be present within the player's player interface 210.
To this end, the credit manager 300 has a number of modules including a credit record generator 310 which generates a credit record corresponding to the amount of input credit, a credit identifier issuer 320 which issues credit identifiers in accordance with predetermined rules, for example, it may generate the identifier randomly or from a set of identifiers. Both the credit record generator 310 and the credit identifier issuer 320 are adapted to communicate data to the credit data 272 of the memory.
The credit manager 300 also includes an identifier requester 330 adapted to request that a player enter an identifier and cause the display controller to display this request on one of the player interfaces 210 in response to an attempt by a player to allocate the credit to their player interface.
A credit identifier processor and credit allocator 340 processes input requests and if the credit identifier is correct updates the credit data 272 such that a credit meter associated with the player interface includes the credit balance of the relevant credit record.
The most common, example of a gaming “token” is a chip. However, other tokens such as coins or the like may be employed.
With reference to FIG. 2, the interface controller provides to the display controller, data stored as interface data 273 which specifies which parts of the player interface are assigned to the different areas of the player interface 500, which has a chip stack area 510, a bet manipulation area 520 and a bet commitment area 530 so that these areas are displayed to a player. Token data 275 specifies the number of tokens associated with a player interface and their current locations within the player interface 500. The touch screen processor 250 determines when a player touches the screens and employs the token data to determine which token or tokens the player has touched. In an exemplary embodiment, a player moves a token by touching the touch screen in the vicinity of token and dragging their finger across the screen to a new position. When the player releases or removes their finger from the touch screen the movement is completed.
In an alternative mode of control, the touch screen processor 250 is configured to detect the speed at which a player moves their hand relative to the screen such that a player can “flick” a token by rapidly moving their finger in a direction they wish the chip to go to impart a vector velocity to the chip. The touch screen processor 250.
The touch screen processor 250, implements manipulation rules 276 in respect of a player's touching of the tokens. In the embodiment, after a new credit record is created by the credit manager, the credit manager 300 causes the display controller 230 to display in a new token display area 213 of the common display 212, tokens corresponding to the amount of credit in the credit records. A player reaches over to the new token display area 213 on the common display 212, touches the tokens in the new display area 213 and drags them towards their player interface area. When the tokens are released by the player within the player's interface area 500 or within a specific sub-area, such as the bet manipulation area 520 or the chip stack area 510, the touch screen processor advises the credit manager 300 that a player has attempted to allocate the tokens to their player interface. The identifier requester 330 causes the display controller 230 a virtual keypad 620 as shown in FIG. 6 and a request for a player to “enter code” 625 to thereby request that the player submit the credit identifier that they received previously. If the correct credit identifier is entered as described above, the credit amount, in the example shown in FIG. 7, 575 units of chips are added to the player's chip stack area 510 in this case in a pile of five 100 unit chips 712, and three 25 unit chips 714. The player's total of chips is also updated 722.
Accordingly there is implemented a method 800 where a credit input is received 810, a credit record is generated 820, a credit identifier is associated with a credit record 830. Tokens corresponding to the credit record are displayed 835. The touch screen is monitored for an attempt to allocate the tokens to a player interface 840. If a user attempts to allocate the tokens to themselves the user is prompted for a credit identifier 850. At step 860 the method involves receiving and processing the credit identifier and if the identifier is correct at step 870 the method involves allocating the credit record to the credit meter of the player interface 870.
Various further features or modifications will be apparent to persons skilled in the art. For example, the code will typically be in a string of alphanumerical characters, for example a number or word or mixture of the two. Further an alternative to issuing an identifier to a player is to allow a player to choose their own code. Where the player has a player tracking device with a code associated therewith, this may be a code previously associated with the tracking device for the player or alternatively a short password may be generated for the player that the player appends to their normal code.
Further, where the virtual table is networked, the terminal may contact the casino management system 412 and pass the transaction record to it. In this embodiment, transaction records are subsequently retrieved over the network when the player approaches the game.
Further, while FIG. 2, shows the credit manager and credit data being common functional components of the gaming system. A credit input mechanism may be provided as a money terminal and be physically separate or may be provided as part of the log-on terminal 140 shown in FIG. 1. In this case, an initial credit record may be established within the money terminal and the virtual table contacts the money terminal to obtain a transaction record stored in memory matching the entered credit identifier. If such a record exists, the associated money amount is credited to the gaming machine and the transaction record is marked as used within the terminal. It will be appreciated that in this example, the credit manager function is provided in combination by the virtual table and the money terminal.
A person skilled in the art will also appreciate that the player will wish to cash out or takes his credits elsewhere at the end of a gaming session. In an embodiment, each player interface is provided with a button or touch screen marked “End Session”. Pressing this action causes the gaming machine to create a new credit record and either generates a credit identifier, uses a credit identifier that was previously input by the player, or generates a short password such as a three digit number and appends it to the password previously input by the player or similar technique. The gaming machine associates the credit record with the credit identifier and the credits are associated with the credit record. If a new password has been generated or a short password has been generated this is displayed to the player. The player must memorise or write down the new password. The transaction record may also be transferred to the casino management system or the money terminal. The credit meter is reset to zero for the player interface and the player can leave the gaming machine. The player then approaches the credit mechanism and, depending upon implementation, the player either inserts the ticket he obtained from the money terminal originally, types in the password or types in the password followed by the short password. This is processed by the money terminal to locate the transaction records. The terminal obtains the credit records and provides a payout to the player.
In the case where multiple money terminals exist, it is desirable to have a casino management system in order to create unique credit records for each credit input or output. However this is not strictly necessarily provided each credit manager function is arranged to issue unique credit records.
Further, if a player associates their player tracking device with the original transaction, this information can be carried along with every subsequent transaction such that when a player needs to cash out, they only need to reinsert or otherwise associate their player tracking device with a payout terminal to obtain their money. Various techniques can be used to improve the security of the passwords, for example passwords can be time limited and once the time runs out the ticket would need to reinserted to the terminal 140 to generate a new ticket or password. This would cut down the number of active passwords at any one time. Further, the gaming table can be arranged to alert an operator or security staff if a large number of incorrect passwords attempts are made.
The above embodiment has been described in relation to a virtual gaming table where players share a display to provide a plurality of player interfaces. Persons skilled in the art will appreciate that the same technique can be applied in any situation whether a plurality of player interfaces such as may be provided by a plurality of stand alone electronic gaming machines, share a common credit input mechanism.
In some embodiments, tokens corresponding to new credit records may be displayed at a plurality of locations to make it convenient for a player to reach the virtual tokens. In other embodiments, a notification may be provided on each player interface that there is a new credit record. In other embodiments, a newly added player interface or a dormant interface may revert to a view such as shown in FIG. 6—i.e. default to a credit identifier entry mode.
FIG. 4 shows a gaming system 400 in accordance with an alternative embodiment. The gaming system 400 includes a network 401, which for example may be an Ethernet network. Gaming tables 403, are connected to the network 401. The gaming tables 202 provide a player operable interface for the gaming system 400.
One or more displays 404 may also be connected to the network 401. The displays 404 may, for example, be associated with one or more gaming tables 203. The displays 404 may be used to display representations associated with game play on the gaming tables 402, and/or used to display other representations, for example promotional or informational material.
In a thick client embodiment, game server 405 implements part of the game played by a players using a gaming table 403 and the gaming table 403 implements part of the game. With this embodiment, as both the game server and the gaming device implement part of the game, they collectively provide a game controller. A database management server 406 may manage storage of game programs and associated data for downloading or access by the gaming devices 402 in a database 406A. Typically, if the gaming system enables players to participate in a Jackpot game, a Jackpot server 407 will be provided to monitor and carry out the Jackpot game.
In a thin client embodiment (or networked gaming embodiment), game server 405 implements most or all of the game played by a player using a gaming table 403 and the gaming table 403 essentially provides only the player interface. With this embodiment, the game server 405 provides the game controller. The gaming table 403 will receive player instructions, pass these to the game server 405 which will process them and return game play outcomes to the gaming table 403 for display.
Player accounts may be maintained by player account server 412 which stores an account including a credit balance for player's having a player tracking device as well as other data such as loyalty data for a loyalty program. A player accesses their account by presenting their player tracking device to the credit input/output mechanism 290 of the virtual gaming table 403.
Servers are also typically provided to assist in the administration of the gaming network 400, including for example a gaming floor management server 408, and a licensing server 409 to monitor the use of licenses relating to particular games. An administrator terminal 410 is provided to allow an administrator to run the network 401 and the devices connected to the network.
The gaming network 400 may communicate with other gaming systems, other local networks, for example a corporate network, and/or a wide area network such as the Internet, for example through a firewall 411.
Persons skilled in the art will appreciate that in accordance with known techniques, functionality at the server side of the network may be distributed over a plurality of different computers. For example, elements may be run as a single “engine” on one server or a separate server may be provided. For example, the game server 405 could run a random generator engine. Alternatively, a separate random number generator server could be provided. Further, persons skilled in the art will appreciate that a plurality of games servers could be provided to run different games or a single game server may run a plurality of different games as required by the tables 403.
Further variations will be apparent to persons skilled in the art and should be understood as falling within the scope of the invention described herein. In particular, it will be apparent to persons skilled in the art that specific features of the above embodiments could be combined to form further embodiments.
In the claims which follow and in the preceding description of the invention, except where the context requires otherwise due to express language or necessary implication, the word “comprise” or variations such as “comprises” or “comprising” is used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention.
It is to be understood that the reference to prior art herein does not constitute an admission that the prior art forms a part of the common general knowledge in the art in any country.

Claims

1. A method of credit input for a multi-player gaming system, the method comprising:

receiving a credit input;

generating a credit record associated with a gaming system including data indicative of the credit input; and

associating a credit identifier with the credit record.

2. A method as claimed in claim 1, further comprising receiving the credit identifier from a player interface of the gaming system; and

allocating the credit specified by the credit record to the player interface.

3. A method as claimed in claim 1, and further comprising issuing the credit identifier.

4. A method as claimed in claim 1, and further comprising associating a player provided credit identifier with the credit record.

5. A method as claimed in claim 2, and further comprising displaying one or more tokens corresponding to the credit record on a display of the multi-player gaming system.

6. A method as claimed in claim 5 comprising issuing a request for the credit identifier in response to an attempt to allocate the one or more tokens with a player interface.

7. A method as claimed in claim 6 comprising monitoring for an attempt to allocate one or more tokens with a player interface by monitoring for an attempt to move the one or more tokens to within the player interface.

8. A method as claimed in claim 7, wherein an attempt to allocate one or more tokens with a player interface comprises an attempt to move the one or more tokens to a designated part of the player interface.

9. A method as claimed in claim 6, wherein the display is a touch screen display and the method comprises monitoring the output of the touch screen for an attempt to move the one or more tokens.

10. A method as claimed in claim 1, wherein receiving a credit input comprises receiving a ticket having a credit value.

11. A method as claimed in claim 1, wherein receiving a credit input comprises obtaining credit from a player account.

12. A method as claimed in claim 11, wherein the player account is linked to a player tracking device.

13. A method as claimed in claim 1, wherein receiving a credit input comprises receiving a currency input.

14. A multi-player gaming system comprising:

a credit input mechanism; and

a credit manager arranged to:

generate a credit record including data indicative of the credit input; and

associate a credit identifier with the credit record.

15. A multi-player gaming system as claimed in claim 14, wherein the credit manager is further arranged to:

receive the credit identifier from a player interface of the gaming system; and

allocate the credit specified by the credit record to the player interface.

16. A gaming system as claimed in claim 15, comprising a player interface controller adapted to provide a plurality of player interfaces.

17. A gaming system as claimed in claim 15, wherein the credit manager is adapted to issue a request for the credit identifier in response to an attempt to allocate the credit record to a player interface.

18. A gaming system as claimed in claim 14, comprising a touch screen display and the player interface controller is adapted to provide at least part of each player interface on with the touch screen display.

19. A gaming system as claimed in claim 18, wherein the credit manager is arranged to cause the display to initially display one or more tokens corresponding to the credit record at a position separate to each player interface.

20. A gaming system as claimed in claim 19 wherein the touch screen is operable to allow a player to move the one or more tokens from the initial display position to a player interface to attempt to allocate the credit record.

21. A gaming system as claimed in claim 15, wherein each player interface is operable to enter a credit identifier.

22. A gaming system as claimed in claim 15, wherein the player interface controller is adapted to add and remove player interfaces.

23. A gaming system as claimed in claim 14, wherein the credit input mechanism comprises a bill acceptor.

24. A gaming system as claimed in claim 14, wherein the credit input mechanism comprises a coin acceptor.

25. A gaming system as claimed in claim 14, wherein the credit input mechanism comprises a ticket reader.

26. A gaming system as claimed in claim 14, wherein the credit input mechanism is adapted to obtain a credit amount from a player account.

27. A gaming system as claimed in claim 18, wherein the display is a horizontal display.

28. A gaming system as claimed in claim 27, wherein the display is 2-3 m across the diagonal.

29. A credit manager for a multi-player gaming system arranged to:

process a credit input;

generate a credit record based on the credit input; and

associate a credit identifier with the credit record.

30. A credit manager as claimed in claim 29, further adapted to issue a request for the credit identifier in response to an attempt to allocate the credit record to a player interface of the gaming system.

31. A credit manager as claimed in claim 30, wherein the credit manager is arranged to cause a display of the gaming system to initially display one or more tokens corresponding to the credit record at a position separate to the player interface.