US20070184897A1

US20070184897A1 - Player terminal for providing multiplayer game

Info

Publication number: US20070184897A1
Application number: US11/585,349
Authority: US
Inventors: Jun Fujimoto
Original assignee: Aruze Corp
Current assignee: Universal Entertainment Corp
Priority date: 2005-10-25
Filing date: 2006-10-24
Publication date: 2007-08-09
Also published as: JP2007117200A; AU2006233176A1

Abstract

A player terminal is configured as one of a plurality of player terminals, and provides a game in which the players participate simultaneously. The player terminal includes a processor that is operable to: (a) calculate total bet point by adding up bet points that are bet on the game by the players through the player terminals; (b) determine game results of the game being correlated with each of the players; (c) determine whether each of the game results satisfies a predetermined condition; (d) determine a winning award in accordance with the total bet point and the number of players who are correlated with game results that are determined to satisfy the predetermined condition; and (e) add the winning award to the player points of the players who are correlated with the game results that are determined to satisfy the predetermined condition.

Description

CROSS-REFERENCE TO THE RELATED APPLICATION(S)

The present application is based upon and claims priority from prior Japanese Patent Application No. 2005-310306, filed on Oct. 25, 2005, the entire contents of which are incorporated herein by reference.

TECHNICAL FIELD

The present invention relates to a gaming system having plural terminals that are connected to each other via a communication line, a game program for allowing plural players to play the same game simultaneously by manipulating respective terminals, a game control method for allowing plural players to play the same game simultaneously by manipulating respective terminals, and a terminal as one of plural terminals that are connected to each other via a communication line.

BACKGROUND

Conventionally, there are network video games, in which a plurality of players participate for playing the same game simultaneously, employed with casino games (refer to International Patent Publication No. WO/1997/026061, for example). The gaming system disclosed in the publication allows players to enjoy a casino game without the need for going to a casino.
In casino games, each of the players plays the game against a dealer. When the dealer loses, the casino pays winning awards to winning players. However, where a casino game is employed as a network video game, it is difficult to set a dealer. Hence, a proper method for paying winning awards to winning players needs to be devised. As exemplified by this matter, it is necessary to configure a new scheme in the case of employing a casino game as a network video game in which plural players play the same game simultaneously.

SUMMARY

One of objects of the present invention is to provide a gaming system, a game program, a game control method, and a terminal which enable smooth payment of winning awards and allow the game-providing side to make profits stably in a game in which plural players play the same game simultaneously.
According to a first aspect of the invention, there is provided a player terminal configured as one of a plurality of player terminals that are provided for each of a plurality of players, and connected with one another by a communication line, the player terminals providing a game in which the players participate simultaneously. The player terminal includes: a memory that stores player points owned by each of the players; and a processor that is connected to the memory. The processor is operable to: (a) calculate total bet point by adding up bet points that are bet on the game by the players through the player terminals; (b) determine game results of the game being correlated with each of the players; (c) determine whether each of the game results satisfies a predetermined condition; (d) determine a winning award in accordance with the total bet point and the number of players who are correlated with game results that are determined to satisfy the predetermined condition; and (e) add the winning award to the player points of the players who are correlated with the game results that are determined to satisfy the predetermined condition.
According to a second aspect of the invention, there is provided a game control method for providing a game in which a plurality of players participate simultaneously with a plurality of player terminals that are connected with one another by a communication line. The method includes: calculating total bet point by adding up bet points that are bet on the game by the players through the player terminals; determining game results of the game being correlated with each of the players; determining whether each of the game results satisfies a predetermined condition; determining a winning award in accordance with the total bet point and the number of players who are correlated with game results that are determined to satisfy the predetermined condition; and adding the winning award to player points of the players who are correlated with the game results that are determined to satisfy the predetermined condition.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings:
FIG. 1 is a schematic diagram of an exemplary gaming system according to the present invention;
FIG. 2 is a block diagram showing an internal configuration of each terminal of the gaming system shown in FIG. 1;
FIG. 3 is a flowchart of a game process;
FIG. 4 is a flowchart of a bet reception process which is executed after being called at step S11 of the subroutine shown in FIG. 3;
FIG. 5 is a flowchart of a game result determination process which is executed after being called at step S12 of the subroutine shown in FIG. 3;
FIG. 6 is a flowchart of a winning award determination process which is executed after being called at step S15 of the subroutine shown in FIG. 3;
FIGS. 7A-7E show examples of status data;
FIGS. 8A-8D show examples of status data;
FIG. 9 is a flowchart of another exemplary bet reception process;
FIG. 10 is a flowchart of another exemplary winning award determination process;
FIGS. 11A-11E show examples of status data;
FIGS. 12A and 12B show examples of status data;
FIG. 13 is a schematic diagram of another exemplary gaming system according to the invention;
FIG. 14 is a schematic diagram of still another exemplary gaming system according to the invention; and
FIG. 15 is a schematic diagram of a further exemplary gaming system according to the invention.

DETAILED DESCRIPTION

FIG. 1 is a schematic diagram of an exemplary gaming system according to the present invention.
The gaming system 100 is provided with a plurality of terminals 1 (denoted by symbols 1A-1D in FIG. 1) which are connected to each other via a communication line 9. Each terminal 1 is equipped with, on the front side, a display 13 on which various images relating to a game are displayed. Each terminal 1 is also equipped with a controller 16 and a coin selector 17.
Although only four terminals 1 are shown in FIG. 1, the number of terminals provided in a gaming system according to the invention may be any plural number. Although the communication line 9 of the gaming system 100 is a wire, the communication line used in the invention is not limited to a wired channel and may be a wireless channel. The communication line may be a dedicated channel, a switched channel, or the like.
In the gaming system 100, a LAN (local area network) is formed by the plural terminals 1. However, in the invention, the terminals 1 may be connected to each other via the Internet. The gaming system 100 may be configured either in a single commercial facility in which a game can be played such as what is called a game arcade, a casino, or a bar or among plural commercial facilities. Plural gaming systems 100 may be configured in a single commercial facility in such a manner that a gaming system 100 is configured on each floor or in each section of the commercial facility. In the gaming system 100, each terminal 1 is an arcade machine for a business purpose. However, in the invention, no limitations are imposed on the type of terminal. For example, as described later, each terminal 1 may be a general-purpose personal computer.
Blackjack is played in the gaming system 100. However, in the invention, no limitations are imposed on the type of game played in a gaming system as long as it allows plural players to play the same game simultaneously. Examples of such games are card games such as “poker” and “seven bridge” (a kind of rummy) and table games such as roulette.
FIG. 2 is a block diagram showing the internal configuration of each terminal 1 of the gaming system 100 shown in FIG. 1.
The terminal 1 is equipped with a CPU (computer) 10, to which a ROM 11 and a RAM 12 as a player point storage unit (memory) are connected. Game programs according to the invention, various kinds of image data to be displayed on the display 13, various kinds of sound data to be output from a speaker 14, permanent data and programs, etc. are stored in the ROM 11. Status data (see FIGS. 7 and 8) including data relating to players (player data) and data relating to a game in progress (game data) are stored in the RAM 12. The status data will be described later in detail.
The display 13, the speaker 14, a communication interface 15, the controller 16, and the coin selector 17 are connected to the CPU 10. Various images are displayed on the display 13 in accordance with game situations. Various sounds (e.g., BGM, a voice, and a sound effect) are output or produced from the speaker 14 in accordance with game situations. The communication interface 16, which is to communicate with the other terminals 1, is connected to the communication line 9. The controller 16, which is to receive game-related instructions, outputs an instruction signal to the CPU 10 when manipulated by a player. The coin selector 17, which is to detect an inserted coin, outputs a detection signal to the CPU 10 when having detected a coin.
Next, processes which are executed by each terminal 1 will be described with reference to FIGS. 3-8D. FIG. 3 is a flowchart of a game process. FIG. 4 is a flowchart of a bet reception process which is executed after being called at step S11 of the subroutine of FIG. 3. FIG. 5 is a flowchart of a game result determination process which is executed after being called at step S12 of the subroutine of FIG. 3. FIG. 6 is a flowchart of a winning award determination process which is executed after being called at step S15 of the subroutine of FIG. 3. FIGS. 7A-7E and FIGS. 8A-8D show exemplary status data.
In the gaming system 100, the processes which will be described below with reference to FIGS. 3-8D are processes that are executed by one of the plural terminals 1 (e.g., a terminal to which an entry instruction is input first). The following description will be made with an assumption that these processes are executed by the terminal 1A. The terminals 1 (1B-1D) other than the terminal 1A execute processes suitable for these processes executed by the terminal 1A. In this embodiment, the terminal 1A corresponds to a terminal according to the invention.
In the following, descriptions relating to the display of images and the output of sounds will be omitted except for special cases. However, in each of the terminals 1 (1A-1D), images are displayed on the display 13 and various sounds (e.g., BGM, a voice, and a sound effect) are output or produced from the speaker 14 in accordance with game situations.
FIG. 3 is a flowchart of a game process which is executed by the terminal 1A.
The CPU 10 of the terminal 1A performs entry reception processing at step S10. A player inserts a predetermined number of coins into the terminal 1A as a game entry procedure and then inputs his or her ID data (hereinafter referred to as “player ID”) by manipulating the controller 16 of the terminal 1A. At step S10, the CPU 10 of the terminal 1A stores, in the RAM 12, as part of status data (see FIG. 7), the thus-input player ID and ID data of the terminal 1A (hereinafter referred to as “terminal ID”) in such a manner that they are correlated with each other. Further, the CPU 10 of the terminal 1A stores, in the RAM 12, as part of status data, a player point corresponding to coins detected by the coil selector 17 in such a manner that the player point is correlated with the player ID.
Furthermore, at step S10, if receiving an entry request signal from one or some of the other terminals 1 (1B-1D) within a predetermined time (e.g., one minute), the CPU 10 of the terminal 1A stores a player ID, a terminal ID, and a player point that are indicated by the entry request signal in the RAM 12 as part of status data. The entry request signal is a signal that is transmitted to the terminal 1A when another player has followed a game entry procedure with one of the other terminals 1 (1B-1D) and indicates a player ID, a terminal ID, and a player point.
The RAM 12 of the terminal 1A serves as a player point storage unit for storing player points of respective players. In the gaming system 100, a player point of each player is stored in the RAM 12 of the terminal 1A. However, the invention is not limited to such a case and a player point of each player may be stored in a storage device (e.g., RAM) of each terminal.
If at step S10 no entry request signal is received from any of the other terminals 1 within the predetermined time (e.g., one minute), one option is not to start a game and another option is that the player is caused to play a game with an NPC (non-play character) which is manipulated by the computer. The following description will be directed to a case that entry request signals are received from all of the other terminals 1B-1D.
If game entries have been made through the terminals 1A-1D at step S10, status data shown in FIG. 7A, for example, are stored in the RAM 12 of the terminal 1A.
FIG. 7A shows status data at a time point when step S10 has just been executed.
The status data consist of player data (shown on the left side in FIG. 7A) and game data (shown on the right side in FIG. 7A). The above-mentioned player IDs, terminal IDs, and player points are stored as the player data. The terminals 1A-1D correspond to terminal IDs “AA,” “AB,” “AC,” and “AD,” respectively.
A setting value of bet points that can be bet for a game, sets of bet points of the respective players for the game, total bet points for the game, card points and total card points of the respective players, and game results can be stored as the game data.
A card point corresponds to the numeral printed on each card. More specifically, the card point of card “A” is “1” or “11.” The card point of each of cards “2” to “10” is the numeral printed on the card. The card point of each of cards “J” to “K” is “10.” Symbols CP1, CP2, . . . represent card points of the first card, the second card, . . . , respectively. Each total card point is the sum of card points.
After the execution of step S10, coins are inserted into each terminal 1. When coins are detected by the coin selector 17, predetermined interrupt processing is performed, whereby points corresponding to the inserted coins are added to the player point corresponding to the terminal ID of the terminal 1. Therefore, after making entry, each player can increase his or her player point by inserting coins into the terminal 1 with desired timing.
After executing step S10, the CPU 10 of the terminal 1A executes a bet reception process at step S11.
In the bet reception process, as shown in FIG. 4, first, at step S20, the CPU 10 of the terminal 1A sets the setting value to a predetermined value (in this embodiment, “10”). The setting value is a value that each player can bet for a game, and each player can bet, for a game, bet points that are equal to the setting value. The setting value is stored in the RAM 12 as part of the status data. In the invention, the setting value need not be kept the same at all times and may be changed as appropriate in accordance with the game situation.
At step S20, the CPU 10 of the terminal 1A serves as a bet points setting unit for setting, to the same value, bet points for a game that plural players can input through the respective terminals 1.
At step S21, the CPU 10 of the terminal 1A determines whether or not a “bet” instruction has been input through or from one of the terminals 1A-1D. The “bet” instruction is an instruction to set bet points for a game and is input by manipulating the controller 16 of each terminal 1. If determined that no “bet” instructions have been input, the CPU 10 of the terminal 1A returns to step S21. On the other hand, if determined that a “bet” instruction has been input, the CPU 10 of the terminal 1A sets, at step S22, the bet points of the player who input the “bet” instruction and decreases his or her player point at step S23.
At step S24, the CPU 10 of the terminal 1A determines whether or not bet points have been set for all the players who made entries. If determined that bet points have not been set for all the players, the CPU 10 of the terminal 1A returns to step S21. On the other hand, if determined that bet points have been set for all the players, at step S25 the CPU 10 of the terminal 1A adds up the sets of bet points to obtain total bet points.
At step S25, the CPU 10 of the terminal 1A serves as a bet points adding-up unit for adding up sets of bet points for a game that have been input by plural players through the respective terminals 1. Step S25 corresponds to a bet points adding-up step of adding up sets of bet points for a game that have been input by plural p layers through the respective terminals 1.
When step S25 has been executed, status data shown in FIG. 7B, for example, are stored in the RAM 12 of the terminal 1A. FIG. 7B shows status data at a time point when step S25 has just been executed. The bet points of each player is set to “10” and the player point of each player has been decreased to “90” (100−10). Total bet points “40” are also stored.
After the execution of step S25, the CPU 10 of the terminal 1A returns to the process of FIG. 3.
At step S12, the CPU 10 of the terminal 1A executes a game result determination process. In the game result determination process, as shown in FIG. 5, first, at step S30, the CPU 10 of the terminal 1A runs a predetermined lottery program which is included in the game programs stored in the ROM 11 and thereby sets two card points for each player and the dealer (NPC). This processing corresponds to “deal” in blackjack.
When step S30 has been executed, status data shown in FIG. 7C, for example, are stored in the RAM 12 of the terminal 1A. FIG. 7C shows status data at a time point when step S30 has just been executed. The card points of the terminal 1A are “11” (CP1) and “10” (CP2) and hence the total card point is “21.” The card points of the terminal 1B are “10” (CP1) and “10” (CP2) and hence the total card point is “20.” The card points of the terminal 1C are “10” (CP1) and “4” (CP2) and hence the total card point is “14.” The card points of the terminal 1D are “6” (CP1) and “2” (CP2) and hence the total card point is “8.” The card points of the dealer are “10” (CP1) and “6” (CP2) and hence the total card point is “16.”
After the execution of step S30, at step S31 the CPU 10 of the terminal 1A refers to the status data (see FIG. 7C) stored in the RAM 12 and determines whether or not the total card point of one or some of the players is equal to “21.” If the total card point of one or some of the players is equal to “21,” at step S32 the CPU 10 of the terminal 1A fixes the game result of that player or those players at “21.”
At step S32, the CPU 10 of the terminal 1A serves as a game result determining unit for determining a game result in such a manner that it is correlated with a player. Step S32 corresponds to a game result determining step of determining a game result in such a manner that it is correlated with a player.
In the status data shown in FIG. 7C, since the total card point of the terminal 1A is “21,” the CPU 10 of the terminal 1A makes the game status of the terminal 1A “stand” and fixes its game result at “21” (see FIG. 7D). The player of a terminal 1 whose game result has been determined is not allowed to input a “stand” or “hit” instruction (described later).
At step S33, the CPU 10 of the terminal 1A determines whether or not a “stand” instruction has been input through or from one of the terminals 1A-1D. The “stand” instruction is an instruction to determine a game result and is input by manipulating the controller 16 of each terminal 1. If determined that a “stand” instruction has been input, at step S34 the CPU 10 of the terminal 1A fixes the game result of that player at the total card point.
At step S34, the CPU 10 of the terminal 1A serves as a game result determining unit for determining a game result in such a manner that it is correlated with a player. Step S34 corresponds to a game result determining step of determining a game result in such a manner that it is correlated with a player.
If a “stand” instruction is input through the controller 16 of the terminal 1B in the state that the status data are as shown in FIG. 7D, since the total card point of the terminal 1B is “20,” the CPU 10 of the terminal 1A makes the game status of the terminal 1B “stand” and fixes its game result at “20” (see FIG. 7E).
If determined, at step S33, that no “stand” instructions have been input or step S34 has been executed, the CPU 10 of the terminal 1A determines at step S35 whether or not a “hit” instruction has been input through or from one of the terminals 1A-1D.
If determined that a “hit” instruction has been input, at step S36 the CPU 10 of the terminal 1A runs the predetermined lottery program which is included in the game programs stored in the ROM 11 and adds one card point as a lottery result to the total card point of the player.
After the execution of step S36, the CPU 10 of the terminal 1A determines at step S37 whether or not the total card point of the player is smaller than “21.” If determined that the total card point of the player is smaller than “21,” the CPU 10 of the terminal 1A moves to step S41.
On the other hand, if determined that the total card point of the player is not smaller than “21,” the CPU 10 of the terminal 1A determines at step S38 whether or not the total card point of the player is equal to “21.” If determined that the total card point of the player is equal to “21,” at step S39 the CPU 10 of the terminal 1A fixes the game result of the player at “21.” On the other hand, if determined that the total card point of the player is not equal to “21,” at step S40 the CPU 10 of the terminal 1A determines that the game result of the player should be “bust.”
At step S39 or S40, the CPU 10 of the terminal 1A serves as a game result determining unit for determining a game result in such a manner that it is correlated with a player. Step S34 corresponds to a game result determining step of determining a game result in such a manner that it is correlated with a player.
If “hit” instructions are input through the controllers 16 of the terminals 1C and 1D (step S35: yes) in the state that the status data are as shown in FIG. 7E and single card points “10” and “9” are added to the total card points of the respective players at step S36, the total card point of the terminal 1C becomes “24” and the total card point of the terminal 1D becomes “17.” Since the total card point of the terminal 1C is larger than “21” (step S38: no), at step S40 the CPU 10 of the terminal 1A determines that the game result of the player should be “bust” (see FIG. 8A).
If determined at step S35 that no “hit” instructions have been input, determined at step S37 that the total card point is smaller than “21,” or having executed step S39 or S40, at step S41 the CPU 10 of the terminal 1A refers to the status data stored in the RAM 12 and determines whether or not game results have been determined for all the players. If determined that game results have not been determined for all the players, the CPU 10 of the terminal 1A returns to step S33 to execute steps S33-S40 again.
If steps S33-S40 are executed again in the state that the status data are as shown in FIG. 8A and a “stand” instruction is input through the controller 16 of the terminal 1D at step S33, the CPU 10 of the terminal 1A fixes the game result of the terminal 1D at the total card point “17” of the terminal 1D (see FIG. 8B). In this manner, the game results of all the players are determined by repeated execution of steps S33-S40.
If determined, at step S41, that game results have been determined for all the players, at step S42 the CPU 10 of the terminal 1A determines the total card point of the dealer (NPC). In this processing, the CPU 10 of the terminal 1A determines, on the basis of the total card point of the dealer (NPC), which of “stand” and “hit” should be effected. If determined that “hit” should be effected, the CPU 10 of the terminal 1A runs the predetermined lottery program which is included in the game programs stored in the ROM 11 and adds one card point as a lottery result to the total card point of the dealer (NPC). This processing is performed repeatedly until the total card point becomes larger than or equal to “21” or “stand” is effected.
FIG. 8C shows exemplary status data at a time point when step S42 has just been executed. In this state, the total card points of all the players and the dealer are determined. On the basis of these data, the CPU 10 of the terminal 1A determines at the following step whether or not the game result of each player satisfies a predetermined condition.
After the execution of step S42, the CPU 10 of the terminal 1A returns to the process of FIG. 3.
At step S13, the CPU 10 of the terminal 1A determines whether or not the game result of each player satisfies a predetermined condition.
The predetermined condition is (A) the game result of the player is not “bust” if the total card point of the dealer is larger than “21” or (B) the game result of the player is not “bust” and larger than the total card point of the dealer if the total card point of the dealer is smaller than or equal to “21.” The predetermined condition is included in the game programs stored in the ROM 12.
If the CPU 10 of the terminal 1A executes step S13 in the state that the status data are as shown in FIG. 8C, results are as follows. Since the total card point of the dealer is “19,” the CPU 10 of the terminal 1A determines whether or not the game result of each player satisfies the condition (B).
The game result of the terminal 1A is “21,” which is not “bust” and is larger than the dealer's total card point “19.” Therefore, the CPU 10 of the terminal 1A determines that the game result of the terminal 1A satisfies the predetermined condition.
The game result of the terminal 1B is “20,” which is not “bust” and is larger than the dealer's total card point “19.” Therefore, the CPU 10 of the terminal 1A determines that the game result of the terminal 1B satisfies the predetermined condition.
The game result of the terminal 1C is “bust.” Therefore, the CPU 10 of the terminal 1A determines that the game result of the terminal 1C does not satisfy the predetermined condition.
The game result of the terminal 1D is “17,” which is not “bust” but is not larger than the dealer's total card point “19.” Therefore, the CPU 10 of the terminal 1A determines that the game result of the terminal 1C does not satisfy the predetermined condition.
At step S13, the CPU 10 of the terminal 1A serves as a determination unit for determining whether or not game results that are correlated with respective players satisfy the predetermined condition. Step S13 corresponds to a determining step of determining whether or not game results that are correlated with respective players satisfy the predetermined condition.
At step S14, the CPU 10 of the terminal 1A determines, on the basis of the judgment results of step S13, whether or not there exists a player whose game result satisfies the predetermined condition. If determined that there is no player whose game result satisfies the predetermined condition, the CPU 10 of the terminal 1A moves to step S17. On the other hand, if determined that there exists a player whose game result satisfies the predetermined condition, at step S15 the CPU 10 of the terminal 1A executes a winning award determination process.
In the winning award determination process, as shown in FIG. 6, at step S50 the CPU 10 of the terminal 1A determines a winning award for winning players by dividing the total bet points by the number of players whose game results satisfy the predetermined condition. After the execution of step S50, the CPU 10 of the terminal 1A returns to the process of FIG. 3.
In executing step S15 (process of FIG. 6), the CPU 10 of the terminal 1A serves as a winning award determination unit for determining a winning award for winning players in accordance with total bet points and the number of players who are correlated with game results that are determined in satisfaction with the predetermined condition. Step S15 (process of FIG. 6) corresponds to a winning award determining step of determining a winning award for winning players in accordance with total bet points and the number of players who are correlated with game results that are determined in satisfaction with the predetermined condition.
At step S16, the CPU 10 of the terminal 1A adds the winning award determined at step S15 to the player points of the players whose game results satisfy the predetermined condition among the player points of the players that are stored in the RAM 12 as part of the status data.
If the CPU 10 of the terminal 1A executes steps S14-S16 in the state that the status data are as shown in FIG. 8C, results are as follows.
Since there are two players whose game results satisfy the predetermined condition (step S14: yes), in the winning award determining process (step S15) the CPU 10 of the terminal 1A divides the total bet points “40” by the number of players (in this example, “2”) whose game results satisfy the predetermined condition and thereby determines that the winning award for winning players should be “20.” At step S16, the CPU 10 of the terminal 1A adds the winning award “20” to the player points of the players whose game results satisfy the predetermined condition (i.e., the player points of the terminals 1A and 1B) The status data are changed to data shown in FIG. 8D.
At step S16, the CPU 10 of the terminal 1A serves as a winning award adding unit for adding a winning award to the player points of players who are correlated with game results that are determined in satisfaction with the predetermined condition. Step S16 corresponds to a winning award adding step of adding a winning award to the player points of players who are correlated with game results that are determined in satisfaction with the predetermined condition.
Steps S11-S16 shows a process for providing one game. When step S16 has been executed, the CPU 10 of the terminal 1A determines at step S17 whether or not a game ending condition is satisfied. The game ending condition is that a predetermined number of games have been played or the player point of one of the players has become smaller than a setting value.
If determined, at step S17, that the game ending condition is not satisfied, the CPU 10 of the terminal 1A returns to step S11. On the other hand, if determined, at step S17, that the game ending condition is satisfied, the CPU 10 of the terminal 1A finishes this subroutine after performing various kinds of processing that relate to ending of the game.
In the above-described gaming system 100, total bet points that are the sum of sets of bet points of plural players are distributed, as winning awards, to players whose game results satisfy the predetermined condition. Therefore, smooth payment of winning awards to winning players is enabled and the game-providing side can make profits stably irrespective of game results.
In the above-described gaming system 100, the bet points of the players are set identical, which prevents the players from feeling that the game is unfair or untrustworthy because of the manner of distribution of total bet points as winning awards. This enables smoother payment of winning awards to winning players and allows the game-providing side to make profits more stably.
The exemplary processes that are executed by the gaming system 100 have been described above with reference to FIGS. 3-8D. However, the invention is not limited to such a case and the following processes can also be employed.
Other exemplary processes that are executed by the terminal 1A will be described with reference to FIGS. 9-12B. FIG. 9 is a flowchart of another exemplary bet reception process. FIG. 10 is a flowchart of another exemplary winning award determination process. FIGS. 11A-11E and FIGS. 12A-12B show exemplary status data.
The game process (see FIG. 3) and the game result determination process (see FIG. 5) remain the same as described above and hence will not be described.
First, the bet reception process will be described.
When the bet reception process is started after being called at step S11 of the subroutine shown in FIG. 3, first, at step S120 shown in FIG. 9, the CPU 10 of the terminal 1A sets a lower limit (in this embodiment, “10”) and an upper limit (in this embodiment, “50”) of bet points.
The lower limit of bet points is a minimum value (minimum bet) that each player can bet for a game. That is, each player is required to bet the bet points that are larger than or equal to the lower limit. The upper limit of bet points is a maximum value (maximum bet) that each player can bet for a game. That is, each player cannot bet the bet points that are larger than the upper limit. The lower limit and the upper limit of bet points are stored in the RAM 12 as part of status data.
At step S120, the CPU 10 of the terminal 1A serves as a lower limit setting unit for setting a lower limit of bet points that each of plural players can input through a terminal 1.
At step S121, the CPU 10 of the terminal 1A determines whether or not a “bet” instruction has been input through or from one of the terminals 1A-1D. The “bet” instruction is an instruction to set bet points for a game and is input by manipulating the controller 16 of each terminal 1. If determined that no “bet” instructions have been input, the CPU 10 of the terminal 1A returns to step S121. On the other hand, if determined that a “bet” instruction has been input, the CPU 10 of the terminal 1A sets, at step S122, the bet points of the player who input the “bet” instruction and decreases his or her player point at step S123.
At step S124, the CPU 10 of the terminal 1A determines whether or not the bet points of the player who input the “bet” instruction is a largest number among the current sets of bet points of all the players. If determined that the bet points of the player who input the “bet” instruction is not a largest number among the sets of bet points of all the players, the CPU 10 of the terminal 1A moves to step S132.
On the other hand, if determined, at step S124, that the bet points of the player who input the “bet” instruction is a largest number among the sets of bet points of all the players, at step S125 the CPU 10 of the terminal 1A changes the lower limit of bet points in accordance with the bet points of the player who input the “bet” instruction.
In this embodiment, the CPU 10 of the terminal 1A updates the lower limit of bet points according to the following Equation (1).
(New lower limit)=(old lower limit)+{(maximum bet points)−(old lower limit)}/2 (1)
For example, if the old lower limit is “10” and the maximum bet points are “30,” at step S125 the CPU 10 of the terminal 1A changes the lower limit to 10+(30−10)/2=20.
At step S125, the CPU 10 of the terminal 1A serves as a lower limit setting unit and sets a lower limit of bet points for a game on the basis of a maximum value of sets of bet points for the game that have been input by players through the terminals 1.
At step S126, the CPU 10 of the terminal 1A determines, on the basis of the status data stored in the RAM 12, whether or not there exists a player who bet the bet points that are smaller than the lower limit. If determined that there is no player who bet the bet points that are smaller than the lower limit, the CPU 10 of the terminal 1A moves to step S132. On the other hand, is determining, at step S126, that there exists a player who bet the bet points that are smaller than the lower limit, the CPU 10 of the terminal 1A sends, to the terminal 1 to be manipulated by the player, a request signal which requests increase of the bet points. The CPU 10 of the terminal 1 that has received the request signal displays, on the display 13, an image showing options that allow the player to choose between increase and non-increase of the bet points. By manipulating the controller 16, the player can input an instruction to increase or not to increase the bet points. On the basis of an instruction, the CPU 10 of the terminal 1A sends a response signal to the terminal 1A.
If the terminal 1 to be manipulated by the player who bet bet points that are smaller than the lower limit is the terminal 1A, the CPU 10 of the terminal 1A displays, on the display 13, an image showing options that allow the player to choose between increase and non-increase of the bet points. By manipulating the controller 16, the player can input an instruction to increase or not to increase the bet points.
After the execution of step S127, the CPU 10 of the terminal 1A determines at step S128 whether or not a response that requests increase of the bet points has been received. If determined that a response that requests increase of the bet points has been received, the CPU 10 of the terminal 1A increases the bet points of the player at step S129 and decreases the player point of the player accordingly at step S130.
On the other hand, if determined that no response that requests increase of the bet points has been received, at step S131 the CPU 10 of the terminal 1A performs processing of canceling the entry of the player to the current game. In this processing, the CPU 10 of the terminal 1A sets the bet points of the player to “0” and adds the bet points so far bet to the player point of the player.
If determined, at step S124, that the bet points of the player who input the “bet” instruction is not a maximum value among the sets of bet points of all the players, if determined, at step S126, that there is no player who bet the bet points that are smaller than the lower limit, or if step S130 or S131 has been executed, at step S132 the CPU 10 of the terminal 1A refers to the status data stored in the RAM 12 and determines whether or not bet points have been set for all the players who have entered the current game. If determined that bet points have not been set for all the players who have entered the current game, the CPU 10 of the terminal 1A returns to step S121.
On the other hand, if determined that bet points have been set for all the players who have entered the current game, at step S133 the CPU 10 of the terminal 1A adds up the sets of bet points to obtain total bet points.
At step S133, the CPU 10 of the terminal 1A serves as a bet points adding-up unit for adding up sets of bet points for a game that have been input by plural players through the respective terminals 1. Step S133 corresponds to a bet points adding-up step of adding up sets of bet points for a game that have been input by plural players through the respective terminals 1.
Next, the winning award determination process will be described.
When the winning award determination process is started after being called at step S15 of the subroutine shown in FIG. 3, first, at step S150 shown in FIG. 10, the CPU 10 of the terminal 1A determines whether or not there exist plural players whose game results satisfy the predetermined condition. If determined that there do not exist plural players whose game results satisfy the predetermined condition, that is, there is only one player whose game result satisfies the predetermined condition, at step S151 the CPU 10 of the terminal 1A determines that the total bet points should be given to the player as a winning award. After the execution of step S151, this subroutine is finished.
On the other hand, if determined at step S150 that there exist plural players whose game results satisfy the predetermined condition, at step S152 the CPU 10 of the terminal 1A calculates proportions of the sets of bet points of the respective players. For example, if there are two players whose game results satisfy the predetermined condition and their sets of bet points are “35” and “40,” proportions of the sets of bet points of the respective players are calculated as 35/(35+40)=0.47 and 40/(35+40)=0.53.
After the execution of step S152, at step S153 the CPU 10 of the terminal 1A determines winning awards of the respective players by allocating the total bet points to the players according to the proportions of their sets of bet points calculated at step S152. In the above example, if the total bet points are “125,” the player whose bet points are “35” is given a winning award 125×0.47=58 and the player whose bet points are “40” is given a winning award 125×0.53=67.
After the execution of step S151 or S153, the CPU 10 of the terminal 1A finishes this subroutine and returns to the process of FIG. 3. At step S16 shown in FIG. 3, the CPU 10 of the terminal 1A adds the winning awards that were determined by the process of FIG. 10 to the player points of the respective players whose game results satisfy the predetermined condition.
In executing the winning award determination process shown in FIG. 10, the CPU 10 of the terminal 1A serves as a winning award determination unit. If there are plural players who are correlated with game results that are determined in satisfaction with the predetermined condition (step S150: yes), the CPU 10 of the terminal 1A determines winning awards of the respective players according to total bet points and sets of bet points that were input by the respective players.
Next, the processes of FIGS. 9 and 10 will be described in a specific manner with reference to status data shown in FIGS. 11 and 12.
As shown in FIG. 11A, if the sets of bet points of the terminals 1A and 1B are set to “10” in a state that the lower limit and the upper limit of bet points are “10” and “50” (steps S121-S123), the sets of bet points of these players are a maximum value among the sets of bet points currently set (step S124: yes) but they are equal to the lower limit. Therefore, even if a new lower limit that is set according to Equation (1) remains the same as the preceding one (step S125).
If a “bet” instruction is input through the terminal 1C (step S121) in the state that the status data are as shown in FIG. 11A and bet points “30” are set (steps S122 and S123), since the bet points “30” of this player is a maximum value among the sets of bet points currently set (step S124: yes), the lower limit of bet points is changed from “10” to “20” according to Equation (1) on the basis of the bet points “30” of the player (step S125; see FIG. 11B).
After the execution of step S125, the sets of bet points of the terminals 1A and 1B become smaller than the lower limit (step S126: yes). Therefore, the CPU 10 of the terminal 1A performs processing of requesting increase of the bet points (step S127).
If the player who is to manipulate the terminal 1A makes a response to the effect that he or she does not want to increase the bet points and the player who is to manipulate the terminal 1B makes a response to the effect that he or she wants to increase the bet points, the status data are changed to data shown in FIG. 11(c). The bet points of the player who made the response to the effect that he or she did not want to increase the bet points are set to “0” and the bet points so far bet are added to the player point. The bet points of the player who made the response to the effect that he or she wanted to increase the bet points are increased to “20.”
If a “bet” instruction is input through the terminal 1D (step S121) in the state that the status data are as shown in FIG. 11C and the bet points are set to “50” (steps S122 and S123), since the bet points “50” of the player is a maximum value among the sets of bet points currently set (step S124: yes), the lower limit of bet points is changed from “20” to “35” according to Equation (1) on the basis of the bet points “50” of the player (step S125; see FIG. 11D).
After the execution of step S125, the sets of bet points of the terminals 1B and 1C become smaller than the lower limit (step S126: yes). Therefore, the CPU 10 of the terminal 1A performs processing of requesting increase of the bet points (step S127).
If the players who are to manipulate the terminal 1B and 1C make responses to the effect that they want to increase the bet points, the status data are changed to data shown in FIG. 1E. In the status data of FIG. 1E, the bet points of the terminal 1C are increased so as to exceed the lower limit. As in this case, bet points may be increased so as to exceed the lower limit.
Then, if game results are determined as shown in status data shown in FIG. 12A, the players who are to manipulate the terminals 1B and 1C are players whose game results satisfy the predetermined condition. In this case, in the winning award determination process (see FIG. 10), the CPU 10 of the terminal 1A determines that there are plural players whose game results satisfy the predetermined condition (step S150: yes) and calculates proportions of the sets of bet points (step S152). Since the sets of bet points of the players who are to manipulate the terminals 1B and 1C are “35” and “40”, the proportions of the sets of bet points of the players are calculated as 35/(35+40)=0.47 and 40/(35+40)=0.53, respectively.
After the execution of step S152, the CPU 10 of the terminal 1A determines winning awards of the respective players (step S153) by allocating the total bet points to the players according to the proportions of the sets of bet points calculated at step S152. Since the total bet points are “125,” the player who is to manipulate the terminal 1B is given a winning award 125×0.47=58 and the player who is to manipulate the terminal 1C is given a winning award 125×0.53=67. After the execution of step S153, at step S16 shown in FIG. 3, the CPU 10 of the terminal 1A adds the winning awards that were determined at step S153 to the player points of the respective players whose game results satisfy the predetermined condition (i.e., the players who are to manipulate the terminals 1B and 1C).
In the gaming system 100, when the processes of FIGS. 9 and 10 have been executed, a winning award of a player is determined in accordance with his or her bet points; for example, a player who bet more bet points is given a higher winning award. Therefore, the players are prevented from feeling that the game is unfair or untrustworthy. This enables smoother payment of winning awards to winning players and allows the game-providing side to make profits more stably.
Furthermore, setting a lower limit of bet points for a game on the basis of a maximum value of sets of bet points makes it possible to cause players to bet bet points in the following manner. For example, when one player has bet many bet points, the lower limit of bet points can be set high to thereby oblige the other players to bet more bet points. This allows the players to bet many bet points while keeping the differences between the sets of bet points of the respective players small. As a result, the players are prevented from feeling that the game is unfair or untrustworthy because of the manner of distribution of total bet points as winning awards. This enables smoother payment of winning awards to winning players and allows the game-providing side to make profits more stably.
The above-described gaming system 100 is provided with the plural terminals 1 that are connected to each other via the communication line 9. However, the invention is not limited to such a case and may be implemented as gaming systems shown in FIGS. 13-15, for example.
FIG. 13 is a schematic diagram showing another exemplary gaming system according to the invention.
The gaming system 110 is provided with plural terminals 1 (denoted by symbols 1A-1D in FIG. 13) and a server 2. The plural terminals 1 are connected to the server 2 via a communication line 3. In this manner, the invention may be implemented as a gaming system having a server.
In the gaming system 110, the processes shown in FIGS. 3-6, 9, and 10 that are executed by the CPU 10 of the terminal 1A in the gaming system 100 are executed by a computer (not shown) such as a CPU that is provided in the server 2. The CPU 10 (computer) of each terminal 1 executes processes suitable for processes executed by the server 2.
FIG. 14 is a schematic diagram showing still another exemplary gaming system according to the invention.
The gaming system 120 is provided with plural personal computers 3 each of which corresponds to a terminal according to the invention. Each personal computer 3 is connected to the Internet N via a communication line 9.
In this manner, the invention may be implemented as a gaming system consisting of general-purpose personal computers.
In the gaming system 120, the processes shown in FIGS. 3-6, 9, and 10 that are executed by the CPU 10 of the terminal 1A in the gaming system 100 are executed by a CPU (not shown) provided in one of the personal computers 3. The CPU of each of the other personal computers 3 executes processes suitable for processes executed by the one personal computer 3.
FIG. 15 is a schematic diagram showing a further exemplary gaming system according to the invention.
The gaming system 130 is provided with plural personal computers 3 each of which corresponds to a terminal according to the invention and a server 4. The plural personal computers 3 and the server 4 are connected to the Internet N via a communication line 9.
In this manner, the invention may be implemented as a gaming system which is provided with a server even in the case where the gaming system employs general-purpose personal computers.
In the gaming system 130, the processes shown in FIGS. 3-6, 9, and 10 that are executed by the CPU 10 of the terminal 1A in the gaming system 100 are executed by a computer (not shown) such as a CPU that is provided in the server 4. A CPU 10 of each personal computer 3 executes processes suitable for processes executed by the server 4.
In the gaming system 100, the above-described processes shown in FIGS. 3-6, 9, and 10 are executed by the CPU 10 of the terminal 1A and status data are stored in the RAM 12 of the terminal 1A. However, in the invention, the terminal which executes the above processes and the terminal which stores status data need not always be the same terminal. For example, a configuration is possible in which each terminal stores player data of a player who is to manipulate the terminal and one of the terminals executes the above processes and stores game data. Furthermore, the terminals may store status data in a synchronized manner.
In the description herein, the statement “plural players can play the same game simultaneously by manipulating respective terminals” does not mean that pieces of processing performed in the respective terminals are synchronized with each other in a strict sense but means that the plural players can play the same game simultaneously. Therefore, as long as the configuration of the invention is satisfied, the invention encompasses a case that plural players can play the same game simultaneously though there are time errors between pieces of processing performed in terminals.
In the gaming system 100, each player is identified by a player ID and a terminal ID. However, in the invention, each player may be identified by either a player ID or a terminal ID.
The foregoing description of the embodiment has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. The embodiment was chosen and described in order to explain the principles of the invention and its practical application to enable those skilled in the art to utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto, and their equivalents.

Claims

1. A player terminal configured as one of a plurality of player terminals that are provided for each of a plurality of players, and connected with one another by a communication line, the player terminals providing a game in which the players participate simultaneously, the player terminal comprising:

a memory that stores player points owned by each of the players; and

a processor that is connected to the memory, the processor being operable to:

(a) calculate total bet point by adding up bet points that are bet on the game by the players through the player terminals;

(b) determine game results of the game being correlated with each of the players;

(c) determine whether each of the game results satisfies a predetermined condition;

(d) determine a winning award in accordance with the total bet point and the number of players who are correlated with game results that are determined to satisfy the predetermined condition; and

(e) add the winning award to the player points of the players who are correlated with the game results that are determined to satisfy the predetermined condition.

2. The player terminal according to claim 1, wherein the processor is further operable to set the bet points, which are allowed to input by the players through the player terminals, to be identical with one another.

3. The player terminal according to claim 1, wherein the processor is further operable to, when a plurality of players are determined to be correlated with the game results that satisfies the predetermined condition, determine winning awards for each of the players in accordance with the total bet point and the bet points bet by the players that are determined to be correlated with the game results that satisfies the predetermined condition.

4. The player terminal according to claim 1, wherein the processor is further operable to set a lower limit of bet point that is allowed to bet on the game, in accordance with a maximum bet point that is bet on the game.

5. A game control method for providing a game in which a plurality of players participate simultaneously with a plurality of player terminals that are connected with one another by a communication line, the method comprising:

calculating total bet point by adding up bet points that are bet on the game by the players through the player terminals;

determining game results of the game being correlated with each of the players;

determining whether each of the game results satisfies a predetermined condition;

determining a winning award in accordance with the total bet point and the number of players who are correlated with game results that are determined to satisfy the predetermined condition; and

adding the winning award to player points of the players who are correlated with the game results that are determined to satisfy the predetermined condition.

6. The method according to claim 5, further comprising setting the bet points, which are allowed to input by the players through the player terminals, to be identical with one another.

7. The method according to claim 5, further comprising, when a plurality of players are determined to be correlated with the game results that satisfies the predetermined condition, determining winning awards for each of the players in accordance with the total bet point and the bet points bet by the players that are determined to be correlated with the game results that satisfies the predetermined condition.

8. The method according to claim 5, further comprising setting a lower limit of bet point that is allowed to bet on the game, in accordance with a maximum bet point that is bet on the game.