WO2013124932A1 - ゲーム制御装置、ゲーム制御方法、ゲーム制御プログラム、記録媒体、ゲームシステム - Google Patents

ゲーム制御装置、ゲーム制御方法、ゲーム制御プログラム、記録媒体、ゲームシステム Download PDF

Info

Publication number
WO2013124932A1
WO2013124932A1 PCT/JP2012/007439 JP2012007439W WO2013124932A1 WO 2013124932 A1 WO2013124932 A1 WO 2013124932A1 JP 2012007439 W JP2012007439 W JP 2012007439W WO 2013124932 A1 WO2013124932 A1 WO 2013124932A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
game
battle
progress
information
Prior art date
Application number
PCT/JP2012/007439
Other languages
English (en)
French (fr)
Inventor
誉之 高原
秋津 寺嶋
Original Assignee
株式会社コナミデジタルエンタテインメント
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社コナミデジタルエンタテインメント filed Critical 株式会社コナミデジタルエンタテインメント
Publication of WO2013124932A1 publication Critical patent/WO2013124932A1/ja

Links

Images

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/80—Special adaptations for executing a specific game genre or game mode
    • A63F13/833—Hand-to-hand fighting, e.g. martial arts competition
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/45—Controlling the progress of the video game
    • A63F13/49—Saving the game status; Pausing or ending the game
    • A63F13/493—Resuming a game, e.g. after pausing, malfunction or power failure
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/40—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of platform network
    • A63F2300/406—Transmission via wireless network, e.g. pager or GSM
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/80—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game specially adapted for executing a specific type of game
    • A63F2300/8029—Fighting without shooting

Definitions

  • the present invention relates to a technique for controlling the progress of a game by each user according to each operation of a plurality of users.
  • social game executed by a game application created based on an operating environment such as an API (Application Programming Interface) operating on a web browser in a social networking service (SNS) by a specific service provider.
  • API Application Programming Interface
  • SNS social networking service
  • Game is popular. It can be said that the social game is a kind of online game that is played while communicating among an unspecified number of users. If a user can connect to the Internet and has a communication terminal equipped with a web browser, the user can enjoy a social game regardless of time and place.
  • One of the features of the above-described social game is that it has a richer communication function for interaction between users than the conventional online game.
  • social games for example, in addition to cooperative play with other users (friends), information exchange by communicating with friends such as greetings and contacts with friends, gifts of items on the game with friends or items An exchange has been made.
  • a digital card game (Dragon Collection (registered trademark)) described in Non-Patent Document 1 below is known.
  • the present invention has been made in view of the above-described viewpoints, and provides a game control device, a game control method, a game control program, a recording medium, and a game system that allow a user to feel the benefits of the existence of a friend more clearly.
  • the purpose is to provide.
  • a first aspect of the present invention is a game control device, Each information is acquired from a storage device that stores user information of the first user, user information of the second user associated with the first user, and game character information of the game character, and the first A battle execution means for executing a battle between the user and the game character based on the user information of the first user, the user information of the second user, and the game character information; Progress stopping means for stopping the progress of the game by the first user when the battle result of the battle does not satisfy a predetermined criterion; Progress resumption means for resuming the progress of the game by the first user stopped by the progress stop means when a predetermined condition on the game is satisfied; Is provided.
  • the “game character” is, for example, a virtual person, creature, or monster on the game, and includes those displayed on a card.
  • the “user information” and “character information” may be constant or variable data related to the progress or result of the battle, respectively, associated with the user and the game character. For example, it may be an index value such as a parameter for attack or defense in a battle, or an index value such as HP indicating resistance to attack.
  • the first user may not be able to proceed with the game without satisfying a predetermined standard with respect to the battle result of the battle involving the second user associated with the first user.
  • the first user is discouraged from the battle result, but after that, if the predetermined condition on the game is satisfied, the progress of the game can be resumed.
  • the predetermined conditions on the game include, for example, conditions related to the user's friends who are playing. In this case, the user can more clearly feel the benefit of the existence of the friend. Thereby, a game with high sociality and high interest can be realized.
  • the selection means may select a user who has already logged out at the time if the elapsed time from the time of the battle between the first user and the game character is within a predetermined time.
  • “Login” is for logging in to access the game itself (for example, logging in to access the game top page, etc.), as well as for progressing or executing a specific part or a specific stage in the game. May be included.
  • the user since the user is selected based on the login status of the second user (the user associated with the first user), the user cooperates with the second user who is playing the game in almost the same time zone. Thus, it is possible to give the first user a feeling of performing a battle.
  • a setting means for setting a closeness indicating a degree of relationship between the first user and a user related to the first user, and the first user Selection means may be provided that selects, from among users, a user whose closeness with the first user is higher than a predetermined threshold as the second user.
  • the second user who is involved in the battle of the first user is selected from the users who have a high degree of relationship with the first user, so that the users who have a high degree of relationship feel further mutual benefits.
  • the degree of relationship can be further increased.
  • the user information includes a first index value indicating an attack power against the game character in the battle, and the character information is an index value indicating a resistance to an attack, and the user information corresponds to the attack power.
  • a second index value that decreases when the progress of the game is stopped by the progress stop means as to whether or not the predetermined condition is satisfied. You may determine based on whether it is below a predetermined value. In this configuration, if the second index value of the game character is not zero but less than a predetermined value, the progress of the game can be resumed, and the difficulty level of the game is substantially reduced. The user can clearly feel the benefits of the existence of his / her peers.
  • the user information includes a first index value indicating an attack power against the game character in the battle, and the character information is an index value indicating a resistance to an attack, and the user information corresponds to the attack power.
  • a second index value that decreases when the progress of the game is stopped by the progress stop means as to whether or not the predetermined condition is satisfied. The determination may be made based on a comparison result with the sum of the first index values of the first user and the second user.
  • the predetermined condition may be, for example, a condition that the second index value of the game character is smaller than the sum of the first index values of the first user and the second user.
  • whether the progress resuming means is related to the first user and whether the number of users participating in the game is greater than or equal to a predetermined number as to whether or not the predetermined condition is satisfied. You may decide based on whether or not.
  • the user participating in the game may be a user who has logged in to the game and has not logged out, or a user who is performing a battle with a game character from among the users. In this configuration, the progress of the game can be resumed when there are many fellow users participating in the game, so that the user can more clearly feel the benefits of the existence of the fellows.
  • the progress resuming unit may resume the progress of the game by the first user so that the first user wins a battle with the game character.
  • the user since the user can unconditionally win after the game has been resumed, the user can more clearly feel the benefits of the existence of the friends.
  • the user information includes a first index value indicating an attack power against the game character in the battle, and the character information is an index value indicating a resistance to an attack, and the user information corresponds to the attack power.
  • the progress resumption means includes a first index value of the game character based on a second index value of the game character at the time when the progress resumption means is stopped. A match may be performed.
  • the battle between the first user and the game character is executed based on the second index value of the game character when the progress of the game is stopped.
  • the second index value of the game character is already equal to or less than the predetermined value, the user can advantageously advance the battle.
  • the user can clearly feel the benefits of the existence of his / her friends.
  • a second aspect of the present invention is a game control method.
  • This game control method Each information is acquired from a storage device that stores user information of the first user, user information of the second user associated with the first user, and game character information of the game character, and the first Executing a battle between the user and the game character based on the user information of the first user, the user information of the second user, and the game character information; Stopping the progress of the game by the first user when the battle result of the battle does not satisfy a predetermined criterion; Resuming the progress of the game by the first user stopped by the stopping step when a predetermined condition on the game is satisfied; Is provided.
  • a third aspect of the present invention is a game control program.
  • This game control program is Each information is acquired from a storage device that stores user information of the first user, user information of the second user associated with the first user, and game character information of the game character, and the first A function for executing a battle between the user and the game character based on the user information of the first user, the user information of the second user, and the game character information,
  • the first function stopped by the function of stopping the progress of the game by the first user when the battle result of the battle does not satisfy a predetermined standard and the function of stopping when the predetermined condition on the game is satisfied
  • the ability to resume game progress by users It is a program for realizing.
  • the computer may be, for example, a network server or a large computer. Further, this program may be stored in a computer-readable information storage medium such as a DVD-ROM or a CD-ROM. That is, a fourth aspect of the present invention is a computer-readable recording medium in which the program is recorded.
  • a fifth aspect of the present invention is a game system including a communication terminal and a server that is connected to the communication terminal via a network and controls the progress of the game by the communication terminal.
  • This game system Each information is acquired from a storage device that stores user information of the first user, user information of the second user associated with the first user, and game character information of the game character, and the first
  • a battle execution means for executing a battle between the user and the game character based on the user information of the first user, the user information of the second user, and the game character information
  • a progress stopping means for stopping the progress of the game by the first user when the battle result of the battle does not satisfy a predetermined criterion
  • a progress resumption means for resuming the progress of the game by the first user stopped by the progress stop means when a predetermined condition on the game is satisfied; Any one of the communication terminal and the server is provided with each means.
  • the figure which shows the basic composition of the game system of embodiment The figure which shows the example of the external appearance of the communication terminal of embodiment.
  • the figure which shows the example of the external appearance of the communication terminal of embodiment The block diagram which shows the structure of the communication terminal of embodiment.
  • the figure which illustrates a series of web pages displayed in a user's communication terminal The figure which illustrates a series of web pages displayed in a user's communication terminal.
  • the figure which illustrates a series of web pages displayed in a user's communication terminal The figure which illustrates a series of web pages displayed in a user's communication terminal.
  • the figure which illustrates a series of web pages displayed in a user's communication terminal The figure which illustrates a series of web pages displayed in a user's communication terminal.
  • the functional block diagram for demonstrating the function to play main roles with the game control apparatus of embodiment The flowchart which shows an example of the main processes of the game server of embodiment.
  • the present invention relates to a patent application of Japanese Patent Application No. 2012-036767 filed with the Japan Patent Office on February 22, 2012, and the entire contents of the application are incorporated in this specification by reference.
  • FIG. 1 shows a system configuration example of a game system according to the embodiment.
  • the game system includes communication terminals 10a, 10b, 10c,... That can be connected to a communication network NW (network) such as the Internet, a game server 20 connected to the communication network NW,
  • NW network
  • the database server 30 is configured.
  • Each of the communication terminals 10a, 10b, 10c,... Is a terminal operated by an individual user, for example, a mobile terminal, a smartphone, a PDA (Personal Digital Assistant), a personal computer, a television having a bidirectional communication function.
  • a communication terminal such as a John receiver (including a so-called multi-function smart TV).
  • the game server 20 is configured to be able to communicate with the communication terminal 10 that is a client, and provides a gaming service to the communication terminal 10.
  • the game server 20 is mounted with an application operable on a web browser as a game application.
  • the database server 30 stores various information to be described later in executing the game, and is connected to the game server 20 by, for example, a wire for reading and writing the information.
  • the communication terminal 10 includes a web browser capable of displaying a web page provided by the game server 20, and the user operates the communication terminal 10 on the web page to execute a game.
  • an authentication server for authenticating the user of each communication terminal 10 may be provided separately from the game server 20. Further, when a plurality of game servers 20 are provided in order to accept access from many communication terminals 10, a load balancer for adjusting a load between the plurality of game servers 20 may be provided.
  • the game server 20 may be configured as a single server device, but may be configured as a plurality of server devices having distributed functions.
  • FIGS. 2A and 2B are diagrams each showing an example of the appearance of the communication terminal 10, and FIG. 2A exemplifies a button input type communication terminal such as a foldable mobile terminal (mobile phone), for example.
  • FIG. 2B illustrates a touch panel input type communication terminal such as a smartphone.
  • FIG. 3 is a block diagram showing an internal configuration of the communication terminal 10. As shown in FIG.
  • the communication terminal 10 includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, an image processing unit 14, an instruction input unit 15, a display unit 16, A communication interface unit 17 as a signal transmission / reception unit is provided, and a bus 18 for transmitting a control signal or a data signal between the units is provided.
  • a CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • the CPU 11 loads the web browser in the ROM 12 into the RAM 13 and executes it. And CPU11 is based on the appropriate designation
  • HTML data HyperText Markup Language
  • the communication terminal 10 may be mounted with various plug-ins for extending the browser function of the web browser. In acquiring the HTML data, the CPU 11 sends an access request message including a user ID (user identification information) registered in advance or a user ID input via the instruction input unit 15 via the communication interface unit 17. The game server 20 is notified.
  • the web browser displays the web page provided from the game server 20 on the display unit 16 based on the acquired HTML data via the image processing unit 14.
  • the web browser transmits new HTML data for displaying the web page according to the selection. (That is, update of the web page) is requested to the game server 20.
  • the image processing unit 14 displays a web page on the display unit 16 based on the display image data given from the CPU 11 as the analysis result of the HTML data.
  • the display unit 16 is, for example, an LCD (Liquid-Cristal-Display) monitor including thin film transistors arranged in units of pixels in a matrix, and displays an image of a web page by driving the thin film transistors based on display image data. To display.
  • LCD Liquid-Cristal-Display
  • the instruction input unit 15 includes a button group 15a including a plurality of instruction input buttons such as a direction instruction button and a decision button for accepting a user operation input. And a button group 15b including a plurality of instruction input buttons such as a numeric keypad, and includes an interface circuit for recognizing a pressing (operation) input of each button and outputting it to the CPU 11.
  • the direction instruction button is provided to instruct the CPU 11 to scroll and display the web page displayed on the display unit 16.
  • the determination button instructs the CPU 11 that the user selects one hyperlink or menu that is actively displayed (for example, highlighted) when, for example, a plurality of hyperlinks or menus are displayed on a web page.
  • buttons are provided on the front surface of the communication terminal 10 so that the user can easily operate (click) with the thumb while holding the communication terminal 10 with one hand. It is preferable to arrange
  • the button group 15b is arranged below the button group 15a and includes a plurality of instruction input buttons on which “0” to “9”, “*”, and “#” (ten keys) are written. .
  • the instruction input unit 15 mainly accepts touch panel type input by touching the display screen 16a with a fingertip or a pen.
  • the touch panel input method may be a known method such as a capacitance method.
  • the button group 15a may be provided even when the communication terminal 10 is a touch panel input method.
  • the menu selection operation on the web page displayed on the communication terminal 10 is selected by pressing the direction instruction button and selecting by pressing the enter button. This is done by confirming the selected menu.
  • the selection operation is performed by instructing (touch operation) a menu position on the display screen 16a on which the web page is displayed with a finger or a pen.
  • the configuration of the game server 20 will be described with reference to FIG.
  • the game server 20 manages a game website including a plurality of hierarchical web pages, for example, and provides a game web service to the communication terminal 10.
  • the game server 20 includes a CPU 21, a ROM 22, a RAM 23, a database (DB) access unit 24, and a communication interface unit 25, for transmitting control signals or data signals between the units.
  • a bus 26 is provided.
  • the game server 20 can take the same structure as a general-purpose web server regarding hardware.
  • the ROM 22 stores an application program that provides a service for displaying an object such as an HTML document or an image (displaying a web page) to the web browser of the communication terminal 10 that is a client.
  • the ROM 22 stores various data referred to by the CPU 21 in addition to the application program.
  • the CPU 21 loads the game program in the ROM 22 to the RAM 23 and executes it, and performs various processes via the communication interface unit 25.
  • the CPU 21 transmits HTML data to the communication terminal 10 via the communication interface unit 25.
  • the CPU 21 performs the authentication process.
  • CPU21 performs the process according to the hyperlink or menu selected by the user on the web page displayed on the communication terminal 10 via a communication interface part.
  • the processing includes, for example, transmission of new HTML data, arithmetic processing in the game server 20 or data processing.
  • the database access unit 24 is an interface when the CPU 21 reads / writes data from / to the database server 30.
  • the database server 30 (storage device) can be realized by a general-purpose storage such as a large-capacity hard disk device or a device such as a RAID (Redundant Array of Inexpensive Disks).
  • Each database in the database server 30 is configured to be able to read and write data from the CPU 21 via the database access unit 24 of the game server 20.
  • FIG. 5 shows an example of the configuration of the database server 30.
  • the database server 30 includes a user database 31 and a game database 32.
  • the type of game realized by the game server 20 of the present embodiment is not particularly limited, but in the following, as an example of a game realized by the game server 20 for convenience of description of the embodiment, a user communication terminal
  • a battle-type digital card game in which a user battles with a monster character that is a monster on the game using a warrior card virtually held on the game (monster battle processing) is taken up.
  • This digital card game is a game in which a user collects a warrior card to create his or her own team (army), for example, a battle with another user's team (army) or a monster character. .
  • FIG. 6 shows an example of a user database 31 applied in the above-described competitive digital card game (hereinafter simply referred to as “game” or “game of the present embodiment” as appropriate).
  • the user database 31 has, for each user ID (user identification information), a login status, a user name / display image, a skill level, a physical strength point, an attack point, a strengthening point, a friendship point, the number of warriors, a possessed coin, a friend Information about each item of the user ID, possessed card image data, and retained card parameters.
  • Information included in the user database 31 can be updated sequentially by the game server 20.
  • the user ID included in the user database 31 or data for each user name (to be described later) specifying the user is generically referred to as user data.
  • the data of each item constituting the user data is as follows.
  • Login status Data indicating the login status based on the target user ID.
  • the data includes login time data as shown in FIG.
  • User name / display image A user name and a display image that are displayed to identify the user on the communication terminal 10 when the game is executed.
  • the user name is text of a predetermined length or less that is specified in advance by the user, and the display image is an avatar image that is selected in advance by the user, for example.
  • the user name is a name that identifies the user on the network environment (or game community) provided by the game server 20.
  • Skill level This is data indicating the skill level of the user on the game. For example, it is a level value in a range from Lv1 (level 1) to Lv100 (level 100).
  • -Physical strength point It is a point required when performing the quest on a game by a user in the game of this embodiment.
  • the health point is a value that decreases by performing a quest, and recovers (increases) every time a predetermined time elapses.
  • -Attack point In the game of this embodiment, it is a point required when performing the battle on a game by a user.
  • the attack point is a value that is reduced by a battle with another user or a monster character and is recovered (increased) every time a predetermined time elapses.
  • -Strengthening point In the game of this embodiment, it is a point required when strengthening a warrior card by a user.
  • the strengthening point is a value that is reduced by strengthening the warrior card and is recovered (increased) every time a battle with another user is won or a predetermined time elapses.
  • -Friendship point In the game of this embodiment, it is a point which a user acquires by transmitting a support message to a friend.
  • -Number of warriors This is the number of warrior cards held by the user. The number of warriors increases or decreases with the execution of quest processing and reinforcement processing.
  • the maximum value (for example, 60) of the number of warriors may be defined in advance.
  • -Owned coin This is the possessed amount of virtual currency (coin) on the game that is required when the user corresponding to the user ID uses the pay function on the game.
  • the possessed coins are consumed (reduced) when the user uses a paid function on the game, and the user pays actual money to the service provider or the like by a predetermined method, and increases according to the amount paid.
  • ⁇ Friend's user ID This is data of another user ID associated with the target user ID.
  • -Image data of possession card In the case of the game of this embodiment, the image data of possession card is data including the image about the warrior card which a user possesses.
  • the held card parameter is data indicating the ability value of the warrior card.
  • each capability value of “attack power” and “defense power” and “necessary points” may be included as parameter items.
  • “Necessary points” are points required when using a warrior card in battle. In this game, the total required points of warrior cards used in battles may be limited to be equal to or less than attack points.
  • the value of the attack power parameter is an example of a first index value.
  • the game database 32 stores and updates information related to the progress of the game executed by the database server 30 based on the access from the game server 20.
  • Information relating to the progress of the game may include various information depending on the nature of the game. Taking the case of the game of the present embodiment as an example, the information regarding the progress of the game includes battle results between different users, monster character data (monster character data), processing results of a monster battle execution process described later, and the like. including.
  • FIG. 7 An example of monster character data is shown in FIG.
  • the monster character data is data that is loaded into the RAM 23 and stored together with the execution of the monster battle process.
  • the level (Lv), the attack power value, and the HP value of the monster character value indicating resistance to attack; second index) Value. It may be set so that the value of the attack power and HP of the monster character increase as the level of the monster character increases.
  • FIG. 7 shows a plurality of types of monster characters, it is sufficient that at least one monster character is provided.
  • FIG. 8 is a diagram illustrating an example of a top page displayed on the communication terminal 10 in the game of the present embodiment.
  • 9 to 13 are diagrams showing examples of web pages displayed on the communication terminal 10 when the monster battle process is executed.
  • the top page of the game of this embodiment illustrated in FIG. 8 is configured by a web page corresponding to each user ID.
  • the example of FIG. 8 includes a user data display area, a warrior image display area, and a menu display area.
  • the skill level, physical strength point, attack point, strengthening point, friendship point, number of warriors, and data of each item included in the user data of the target user ID are displayed. Area.
  • the number of warriors is written as “40/60”
  • the number of warrior cards held by the user is 40
  • the maximum number of warrior cards that can be held is 60 Indicates that there is.
  • the warrior image display area is an area in which an image of a warrior card specified in advance by the user among a plurality of warrior cards included in the user data of the target user ID is displayed.
  • the menu display area is a basic menu corresponding to a plurality of functions provided in the game of this embodiment (quest processing, reinforcement processing, battle processing, lottery processing, monster battle processing), “quest”, “enhancement”, “battle” This is an area in which the menus m1 to m5 in which the texts “”, “Lottery”, and “Monster Battle” are displayed are displayed. That is, a plurality of menus to which a plurality of processes executed in the game are respectively assigned are arranged at predetermined positions on the web page displayed on the communication terminal 10.
  • the web page in step S1 includes an image of a plurality of little monster characters mc (10 in the example of FIG. 9), a menu m10 labeled “attacking”, and physical strength points of the target user. Is displayed.
  • the number of the little monster characters mc decreases by a random number, for example, from 1 to 4, and the value of the user's physical strength point decreases, for example, by a certain amount. .
  • step S2 each time the menu m10 is continuously selected, the web page is displayed so that the number of little monster characters mc displayed on the web page and the value of the user's physical strength point decrease. Updated.
  • the physical strength point becomes zero, the little monster character mc cannot be attacked. In that case, it is necessary to wait until the health points are recovered.
  • the web page is updated as shown in step S3 of FIG. 10, the monster character MC appears, and the process proceeds to battle processing with the monster character MC.
  • a menu m11 described as “Battle start” and a menu m12 expressed as “Request support from friends” are displayed on the web page in step S3.
  • the web page is updated as shown in step S4, for example.
  • the game server 20 has a game setting in which, for example, a user randomly selected from among logged-in fellow users rushes to support the battle of the user who is playing.
  • step S4 the names of fellow users who provide support (in the example of FIG. 10, user names of “GIP”, “NGY”, “HKT”, “JKT”, “RIM”) and an avatar image are displayed.
  • An HP gauge 201 indicating the HP of the monster character MC is displayed.
  • step S5 of FIG. the web page is updated as shown in step S5 of FIG.
  • a total of five warrior cards (companies) including five warrior cards of the user who is playing (user warrior card 202) and one warrior card of five fellow users who provide support. Warrior card 203) is displayed.
  • a menu m13 labeled “attack” is displayed.
  • the user's warrior card 202 may be determined randomly from warrior cards held by the user who is playing, or may be determined in advance by the selection of the user who is playing.
  • Each of the fellow warrior cards 203 may be a card determined in advance as a representative (eg, leader) warrior card of each fellow.
  • the HP of the monster character MC is lowered by the attack of 10 warrior cards performed according to the selection operation of the menu m13. Further, in response to the selection operation of the menu m13 or at random timing, the monster character MC attacks the 10 warrior cards in order. Of the 10 warrior cards 202 and 203 on the web page in step S6, the warrior card that has been defeated by the monster character MC (three warrior cards 202 in the example of step S6) is in a collapsed form. Is displayed.
  • the web page is updated as shown in step S7. For example, if the HP of the monster character MC is zero and at least one warrior card held by the user being played is not defeated, it is determined that the user has satisfied a predetermined criterion in the battle, The web page is updated as shown in S9.
  • the web page of step S7 illustrates a case where the user's warrior card 202 and the fellow warrior card 203 are all defeated (that is, annihilated).
  • the menu m13 is not displayed, and the progress of the battle (that is, the progress of the game) is stopped.
  • the web page is updated as shown in step S8, and the user's warrior card 202 and the fellow warrior card 203 are all revived.
  • the resurrection condition is, for example, a condition that the user who is playing is supported by a friend (that is, the fellow warrior card 203 is involved in the battle) and the HP of the monster character MC is equal to or less than a predetermined value. is there.
  • the game progress is basically stopped unless the predetermined criteria in the battle are satisfied, but the game progress is resumed only when the predetermined revival condition is satisfied.
  • the web page is updated, for example, as shown in step S9 in FIG.
  • the HP of the monster character MC becomes zero by the selection operation of the menu m13, and it is displayed that the monster character MC has been defeated.
  • FIG. 14 is a functional block diagram for explaining functions that play a main role in the game control apparatus of the present embodiment.
  • menus, marks and the like displayed on the web page displayed on the communication terminal 10 are arranged at desired positions on the web page, and are menus visually recognized on the communication terminal 10. The position on the display screen of the mark and the like can be changed by scrolling the web page by the user's direction instruction button or touch panel operation.
  • the registration unit 51 recognizes a user request based on an appropriate operation input to the communication terminal 10 on a web page provided to the communication terminal 10, for example, and performs a registration process.
  • the registration means 51 in this case is executed as follows, for example.
  • the CPU 21 of the game server 20 receives a registration request message from the communication terminal 10 via the communication interface unit 25.
  • the registration request message is automatically generated by a predetermined operation (for example, a predetermined menu selection operation, text input, etc.) on the communication terminal 10 on the web page provided from the game server 20. May be configured.
  • the registration request message may include information (for example, IP address, e-mail address, etc.) for specifying the communication terminal 10 as the transmission source, or the user has already played another game by the same service provider.
  • the user ID may be included.
  • the CPU 21 receives the registration request message and the registration request message does not include the user ID, the CPU 21 issues a new user ID and performs registration processing of the user ID, and then the registration processing is completed. Is sent to the communication terminal 10.
  • the CPU 21 receives the registration request message and the registration request message includes a user ID, the CPU 21 performs registration processing of the user ID, and then transmits a registration completion message indicating that the registration processing is completed to the communication terminal. 10 to send.
  • the CPU 21 When the registration is completed, the CPU 21 generates user data corresponding to the user ID and stores it in the user database 31.
  • the registration unit 51 may also include a function for relating different users.
  • the registration unit 51 may register the user ID in association with another user ID, for example, triggered by an application based on the user ID. That is, the registration unit 51 registers another user ID (that is, another user) as a “friend” with an application based on the user ID as a trigger.
  • the registration means 51 in this case is executed as follows, for example.
  • the CPU 21 of the game server 20 sends an application message (application) specifying a user ID (or a corresponding user name) to be a friend from the communication terminal 10 of the user corresponding to a certain user ID via the communication interface unit 25. Accept. Transmission of this application message is preset as a function of a web page provided to the user's communication terminal 10.
  • the CPU 21 approves an application based on another user ID to the communication terminal 10 corresponding to the user ID at the timing when the access is based on the user ID included in the application message. HTML data for displaying a web page for requesting the reply is transmitted. If it is replied that the application is approved, the CPU 21 registers both as friends. Specifically, the CPU 21 writes the data in the “mate” part (see FIG. 6) of the user data of the corresponding two user IDs in the user database 31.
  • the conditions which relate users are not limited to the format that requires application and approval as described above, but a game user who executes a stage on the same game or a user who has performed a battle within the game. You may register as a related user, that is, a friend.
  • the game progress means 52 has a function of managing authentication at the time of login of each user and managing login time and logout time.
  • This function of the game progression means 52 is realized as follows.
  • the CPU 21 of the game server 20 receives the HTTP request from the communication terminal 10 of each user, it collates with the individual identification number, the user ID and the password included in the HTTP request, for example, the data recorded in the user database 31 Then, the authentication process is performed, and the user data is accessed to update the information about the login status. Further, even when the user logs out, the CPU 21 accesses the user data and updates information about the login status.
  • the game progress means 52 performs a specific process in the game in addition to the time of login (for example, login for accessing the top page of the game) when accessing the game itself of the present embodiment as the login time. (Monster battle process etc.) and the time of access for proceeding or executing the process of a specific stage in the process may be managed.
  • the game progression means 52 further has a function of advancing the game by transmitting HTML data for sequentially updating web pages displayed on the communication terminal 10 in accordance with a user operation on the communication terminal 10 after authentication.
  • the following processing can be performed when the game is advanced.
  • Quest processing This is a process for obtaining warrior cards by searching an area set in the game in order to build up his own team. In this game, a certain amount of action points is required to execute the quest process.
  • ⁇ Strengthening process It is a process that increases the ability of a specific warrior by integrating two or more warrior cards. In this game, a certain amount of strengthening points is required for the user to execute the strengthening process.
  • ⁇ Battle processing This is a process of performing a battle with another user's team.
  • Lottery processing This is a process in which a user performs a lottery for obtaining a warrior card.
  • Monster battle processing As illustrated in steps S1 to S9 of FIGS. 9 to 13, this is a process in which the user performs a battle with a monster character using his / her warrior card and further a fellow warrior card.
  • the game progress means 52 has a function of causing the communication terminal 10 to display a plurality of menus to which the plurality of processes executed in the game are assigned. Specifically, the CPU 21 generates HTML data for displaying a web page including a plurality of menus, and transmits the HTML data to the communication terminal 10. In the game, points on the game are consumed with the execution of the quest process, the reinforcement process, the battle process, the lottery process, and the monster battle process.
  • the game progress means 52 is realized as follows.
  • the CPU 21 of the game server 20 accesses the user database 31 via the database access unit 24, and reads the data of each item included in the user data display area and the image data of the warrior card to be displayed in the warrior image display area.
  • the CPU 21 generates HTML data so that the top page shown in FIG. 8 is configured, and transmits it to the communication terminal 10.
  • the generated HTML data is different for each user (that is, for each user ID).
  • the communication terminal 10 interprets the received HTML data and displays the top page image on the display unit 16 (display screen 16a).
  • the CPU 21 executes a quest process, a strengthening process, a battle process, a lottery process, and a monster battle process in accordance with the user's selection operation for any of the menus m1 to m5 displayed on the communication terminal 10.
  • each process is executed hierarchically so that a new web page including a plurality of subdivided menus is displayed.
  • the storage means 53 stores user data (user information; see FIG. 6), which is information on the user's game, in the user database 31 (storage device), and monster character data (character information; FIG. 7) indicating monster character information. For example) is stored in the game database 32 (storage device).
  • the CPU 21 of the game server 20 accesses the user database 31 or the game database 32 via the database access unit 24 and writes data.
  • Writing data includes writing new user data, updating existing user data, writing new monster character data, updating existing monster character data, and the like.
  • the selection means 54 is provided with the function to select the user who assists in a battle with a monster character among the friends of the user (1st user) who is playing in the monster battle process in the game of this embodiment.
  • the selection method of the user from among the friends of the user who is playing can be arbitrarily set. For example, a predetermined number of users (five people in the example of FIG. 10) may be selected at random from among users who are playing. Further, the user selection method may be performed according to a predetermined selection condition. As a selection condition, a user who is not logged out at the timing when the selection operation of the menu m12 of FIG. 10 is performed by a user who is playing, or a user whose elapsed time from the login to the timing is within a predetermined time.
  • the user who has already logged out may be selected at the timing when the selection operation of the menu m12 is performed.
  • the login status it is possible to give a user who is playing a battle in cooperation with friends who are playing the game at almost the same time zone to the user who is playing.
  • a login for accessing the game itself of the present embodiment for example, a login for accessing the top page of the game
  • a monster battle process in the game and a specific in the monster battle process It is also possible to include access for proceeding or executing the process of the stage.
  • the CPU 21 of the game server 20 refers to the user data of the user who is playing, reads the user ID of the fellow, and selects the user randomly from the read user ID or according to a preset selection condition. A process of selecting an ID is performed. At this time, for example, data on the login status is read for determination on the selection condition.
  • the battle execution means 55 performs a battle between the user who is playing (first user) and the monster character (game character), the user data of the user who is playing, and the user A function to be executed based on the user data of the friend (second user) and the monster character data.
  • the monster battle process may be composed of a plurality of stages, and the level (Lv) may differ from the monster character that the user battles at each stage.
  • the number of warrior cards that can participate in a battle with a monster character from among the warrior cards held by the user, and the number of fellow warrior cards that support the user who is playing May be defined in advance (for example, 5 sheets each).
  • the function of the battle execution means 55 is realized as follows, for example.
  • the CPU 21 of the game server 20 reads out the parameters of the user's warrior card and the fellow warrior card from the user database 31 and stores them in the RAM 23. Further, the CPU 21 accesses the game database 32 to determine the attack power and HP (initial value) of the monster character corresponding to the stage to be played by the user who is playing, and stores it in the RAM 23.
  • the values of the attack power and HP (initial value) may be determined at random from the range of the attack power and HP shown in FIG. 7, for example, or determined so as to increase as the stage progresses. You can do it.
  • the CPU 21 performs the subsequent processing based on the data stored in the RAM 23 during the execution of the battle.
  • the monster character When the CPU 21 recognizes the selection operation (hereinafter referred to as “attack instruction operation”) for the menu m13 (refer to FIG. 11), the monster character performs one attack with a random number of warrior cards held by the user who is playing. Against.
  • One attack power by each warrior card may be determined by the sum of attack power values (see FIG. 6; first index value) of the warrior card parameters.
  • the CPU 21 reduces the HP (second index value) value of the monster character in the RAM 23 according to the sum of the attack power values of the one or more warrior cards that have made the attack. That is, the CPU 21 rewrites the HP value of the monster character in the RAM 23 and determines the scale amount of the HP gauge 201 according to the rewritten value.
  • the CPU 21 generates an attack with the attack power stored in the RAM 23 at the timing when the attack instruction operation is performed on the warrior card from the monster character or at random timing. For example, the CPU 21 accesses the RAM 23 and reads the monster character's attack power value.
  • CPU21 gives the attack by a monster character, for example with respect to the 1 or several random warrior card which is participating in a battle, and defense power is smaller than the attack power of a monster character among the warrior cards to which the attack was given. It is determined that the warrior card was defeated by the attack.
  • the progress stop unit 56 and the monster character by the playing user (first user) and the first A function of stopping the progress of the battle game with the user is provided.
  • the battle game stopped by the progress stopping unit 56 is limited to a battle with a monster character being executed by the first user, and execution of games other than battle, such as quest processing and reinforcement processing, is not stopped.
  • the function of the progress stop means 56 is realizable as follows.
  • the CPU 21 of the game server 20 for example, when the HP of the monster character is not zero and all the warrior cards held by the user being played are defeated (defeated) Is determined that the user does not satisfy the predetermined criteria in the battle, the HP of the monster character is zero, and if at least one warrior card held by the user being played is not defeated, It is determined that a predetermined standard in the battle is satisfied.
  • the CPU 21 determines that the user does not satisfy a predetermined criterion in the battle, the CPU 21 stops the progress of the battle game by preventing the user from performing an attack instruction operation, for example.
  • the criterion for determining whether or not a battle with a monster character satisfies a predetermined criterion is not limited to the example described above. After a certain number of attack instruction operations, or after a certain period of time has elapsed since the first attack instruction operation, if all of the user's warrior cards have been defeated (or annihilated), or the monster character's HP is zero If not, it may be determined that the predetermined standard is not satisfied.
  • the progress resuming means 57 is a match between the monster character and the first user by the playing user (first user) stopped by the progress stopping means 56 when the resurrection condition (predetermined condition on the game) is satisfied.
  • a function to resume the progress of the game is provided.
  • the battle game restarted by the progress restarting means 57 is limited to the battle with the monster character being executed by the first user, and is irrelevant to the execution of games other than battle, such as quest processing and reinforcement processing. .
  • the function of the progress resuming means 57 is realized as follows. Even when the CPU 21 of the game server 20 determines that the monster character could not be defeated at the stage to be played, when it determines that the predetermined resurrection condition is satisfied, it resumes the progress of the game.
  • the predetermined revival condition is, for example, a condition that a user who is playing is supported by a friend (that is, a fellow warrior card is participating in a battle) and the HP of the monster character is equal to or less than a predetermined value. It may be.
  • the progress resuming unit 57 may change the battle result when the battle is stopped by the single progress stop unit 56 to determine a new second battle result.
  • the progress resuming unit 57 may use the second battle result as the user's victory when the battle result by the progress stopping unit 56 is the user's defeat. Further, the progress resuming unit 57 presents the result of the battle when the battle is stopped by the progress stopping unit 56 when the resumption condition is not satisfied, and changes the result of restarting the game progress when the resumption condition is satisfied.
  • the second match result may be presented.
  • FIG. 15 is a flowchart showing the monster battle process of the game of the present embodiment by the game control device of the present embodiment.
  • the flowchart of FIG. 15 is processing corresponding to the web page in steps S3 to S9 of FIGS.
  • HTML data for displaying each web page in steps S3 to S9 is transmitted from the game server 20 to the communication terminal 10 as appropriate. Only the reference numerals of steps S3 to S9 are shown in the flowchart.
  • step S110 when it is recognized that the menu m12 is selected on the web page on which the monster character MC appears (step S100: m12), the selection means 54 is playing A user who assists in a battle with a monster character among the user's friends is selected according to, for example, a predetermined selection condition (step S110).
  • the selection condition may be, for example, a condition that the user is not logged out at the timing when the selection operation of the menu m12 is recognized, or is a user whose elapsed time from the login to the timing is within a predetermined time. .
  • the maximum number of friends who provide support may be determined in advance, and is five in the example of FIG.
  • HTML data is transmitted from the game server 20 to the communication terminal 10 of the user who is playing, thereby updating the web page as shown in step S4 of FIG.
  • step S100: m11 it is determined that the user who is playing alone battles with the monster character MC, No friends are selected.
  • step S5 of FIG. 11 is a web page when a friend is selected, the friend's warrior card 203 is not displayed when a friend is not selected.
  • step S120 YES
  • step S130 the battle execution means 55 performs a battle process with the monster character MC (step) S130). This battle process is executed based on the user data of the user who is playing, the user data of the friend selected in step S110, and the monster character data.
  • the monster character MC is attacked from the warrior card (the user's warrior card and the fellow warrior card) held by the user who is playing, and thereby the monster character MC HP decreases, and the scale of the HP gauge 201 on the web page decreases.
  • an attack is performed from the monster character MC to the warrior card held by the user who is playing, according to the attack instruction operation or at random timing, thereby one or more warrior cards. May be defeated.
  • the scale of the HP gauge 201 or defeating the warrior card for example, as shown in step S6 of FIG. 11, the web page is sequentially updated.
  • step S140 The determination as to whether or not the battle with the monster character MC has ended (step S140) can be made as appropriate. For example, it may be determined that the battle has ended when a certain number of attack instruction operations have been performed, or when a certain time has elapsed since the first attack instruction operation was performed, and the HP of the monster character MC is zero. It may be determined that the battle has ended when all the warrior cards held by the user who is playing have been defeated (completely annihilated). If it is determined that the battle with the monster character MC has ended (step S140: YES), the process proceeds to step S150. If it is determined that the battle with the monster character MC has not ended (step S140: NO), the process returns to step S120, and the next attack instruction operation can be accepted.
  • step S150: NO the progress stopping means 56 updates the web page as shown in step S7 of FIG. Stop the progress of the game. That is, the user cannot perform an attack instruction operation.
  • the progress stop means 56 for example, the HP of the monster character MC is not zero, and all the warrior cards held by the user being played are defeated (annihilation) If it is determined that the user does not satisfy the predetermined criteria in the battle (step S150: NO), the HP of the monster character MC becomes zero, and at least one warrior card held by the user being played is present. If the user is not defeated, it may be determined that the user satisfies a predetermined criterion in the battle (step S150: YES).
  • Step S150 YES
  • the progress resuming unit 57 determines whether or not the predetermined resumption condition is satisfied (step S160). If it is determined in step S150 that the predetermined standard is not satisfied and it is determined that the predetermined restoration condition is not satisfied (step S160: NO), the user cannot proceed to the next stage.
  • step S150 determines whether the predetermined standard is not satisfied.
  • step S160 determines whether the predetermined restoration condition is satisfied.
  • the process stops at the web page in step S7 in FIG. Resume battle with the monster character MC. That is, the progress resuming means 57 restores the user's warrior card and the fellow warrior card that have been defeated by the battle with the monster character, and updates the web page as shown in step S8. As a result, an attack instruction operation by the user can be accepted.
  • the resurrection condition is, for example, a condition that the user who is playing is supported by a friend (that is, the fellow warrior card 203 is involved in the battle) and the HP of the monster character MC is equal to or less than a predetermined value. is there.
  • the progress restarting means 57 may update the web page from step S8 to step S9 as shown in the flowchart of FIG. 15 in response to one attack instruction operation. . That is, when a hand-held warrior card is revived, the user who is playing unconditionally may win a battle with the monster character MC. As a result, the user who is playing can get a refreshing feeling that the warrior card on hand wins immediately after the resurrection. And the game progress means 52 permits a user to advance to the next stage.
  • the battle is not performed when the battle result does not satisfy a predetermined criterion.
  • the battle is resumed only when the revival condition including at least the user who is playing is supported by the friend is satisfied. Therefore, the user who is playing is discouraged once the warrior card on hand is annihilated and can not proceed with the battle, but then the warrior card on hand is revived and the battle can be resumed, Users can feel the benefits of the existence of their friends more clearly.
  • the revival condition includes an additional condition in addition to that the user who is playing is supported by a friend. If the revival condition is only that the user who is playing is supported by a friend, the user who is playing is always revived if the user is supported by the friend. May decrease.
  • the HP of the monster character MC is equal to or less than a predetermined value. Thereby, if the HP of the monster character MC is not zero and is equal to or less than a predetermined value, the progress of the game can be resumed, which has the effect of reducing the difficulty of the game.
  • the user since the user can visually recognize the HP of the monster character MC with the HP gauge 201, the user is motivated to set the HP of the monster character MC to a predetermined value or less (that is, to satisfy the resurrection condition). Easy to put on.
  • the selection condition of the fellow users in the selection unit 54 may include the degree of relationship between the fellow users.
  • FIG. 17 shows a functional block diagram for explaining functions that play a main role in the game control device of this modification.
  • the functional block diagram shown in FIG. 17 is different from that shown in FIG. 14 in that setting means 58 is added.
  • the setting means 58 has a function of setting a closeness indicating the degree of relationship between fellow users.
  • the intimacy is a numerical value of the degree of relationship between fellow users based on a certain standard.
  • An example of intimacy data (intimacy data) is shown in FIG.
  • the frequency of sending or receiving a support message between users (support frequency) in association with each user's fellow user (user ID), items usable on the game, etc.
  • the number of times the present was sent or received (the number of presents), the number of battles between fellow users, and the like are recorded, and the familiarity value is set based on a certain standard based on these frequencies and times.
  • weighting may be considered for each item (in FIG. 18, the support frequency, the number of presents, etc.) that is the basis for setting the familiarity. For example, the intimacy may be set high when the number of presents is large even if the support frequency is low.
  • Such familiarity data is recorded in the user database 31, for example.
  • the function of the setting means 58 is realized as follows.
  • the CPU 21 of the game server 20 manages user data and closeness data in the user database 31 in association with each user ID. For example, the CPU 21 performs transmission / reception of a support message and transmission / reception among present friends based on a request of a transmission destination user via the communication interface unit 25. When such transmission / reception occurs, the CPU 21 sequentially updates the target closeness data.
  • the selection means 54 selects the user whose closeness with the user who is playing is higher than a predetermined threshold among the users of the user who is playing (the first user). May be.
  • the CPU 21 accesses the intimacy data of the user who is playing, searches for a user whose intimacy is higher than a predetermined threshold, and supports the battle of the user who is playing. Select a number of users. When there are more users whose familiarity is higher than a predetermined threshold than the predetermined number of users that can support the battle, the CPU 21 may select at random.
  • the friend who supports the battle of the user who is playing is selected from among the friends who have a high degree of relationship with the user who is playing, users who have a high degree of relationship can feel mutual benefits. And the degree of relationship can be further increased.
  • the progress resuming unit 57 determines whether the progress of the game is stopped by the progress stopping unit 56 as to whether or not the resumption condition is satisfied, and the monster character's HP (second index value). You may determine based on the comparison result with the sum total of the attack value (1st index value) of the warrior card of the user (1st user) in play and the friend (2nd user) who supports.
  • the predetermined reference when the progress stop means 56 stops the progress of the battle with the monster character is a fixed time after a predetermined number of attack instruction operations or after the first attack instruction operation. The case where it carries out based on a later battle result is assumed.
  • the monster character's HP does not become zero (second index value), and the predetermined standard is satisfied.
  • the HP of the monster character is smaller than the sum of the attack values (first index values) of the user's hand-held warrior card, the hand-held warrior card May be revived.
  • the HP of the monster character MC is already smaller than the sum of the attack values of the user's warrior card when the battle process is executed again, the user uses the revived warrior card.
  • a battle can be advanced advantageously. Therefore, even with such a configuration, the user can clearly feel the benefit of the existence of the friend.
  • the progress resuming means 57 determines whether or not the resurrection condition is satisfied by a user who is playing (first user) and a fellow user and who is participating in the game. You may determine based on whether a number is more than predetermined number.
  • the user participating in the game may be a user who has logged in to the game of the present embodiment and has not logged out, or a user who is executing a monster battle process from among the users. In this way, when there are many fellow users participating in the game, the warrior card on hand can be revived and the battle can be resumed, and the user can feel the benefits of the existence of the fellows more clearly.
  • the progress resuming means 57 assists before restarting when the battle with the monster character is resumed.
  • Only some of the plurality of friends who have been involved may be involved in the battle after resumption. That is, the fellow users involved in the battle may be different before and after the battle with the monster character is resumed.
  • warrior cards that are revived when the resurrection conditions are satisfied may be limited to fellow warrior cards that satisfy the selection conditions.
  • the attack of the user's warrior card is stopped in the battle game (that is, the attack by the monster character is not stopped)
  • the attack of the warrior card by the user's operation stops that is, when the attack by the monster character or the attack of the warrior card not by the user's operation does not stop).
  • the present invention is not limited thereto.
  • the resumption of the battle game may be set in various modes or degrees. For example, when the battle game itself is executed as before, when the attack of the user's warrior card is stopped and the attack is resumed, the attack of the warrior card by the user's operation was stopped When the attack of the warrior card by the user operation is resumed, it may be either. Note that the battle game processing, parameter settings, and the like may be different before the battle game is stopped and after the battle game is resumed.
  • the resumption condition of the progress resuming means 57 exemplified in the embodiment is a condition that the user who is playing is supported by a friend and the HP of the monster character is equal to or less than a predetermined value.
  • the restoration conditions may be set by individually combining Example 3 and Modification 4. A case where the battle process is actually resumed when the restoration conditions described in the above-described embodiments and modifications are satisfied may be realized based on a predetermined probability.
  • the game settings can be adjusted so that the game is not easily restarted.
  • the resumption conditions described in the above-described embodiment and each modification may be added with additional conditions so that the user who is playing is more likely to win after the battle process is resumed.
  • the values of the parameters of the attack power and the defense power of the user's handheld warrior card are set by a certain ratio than before the restart. It may be increased.
  • the present invention is not limited to this.
  • the game server 20 and the database server 30 on the network use the game progress means 52, the storage means 53, the selection means 54, the battle execution means 55, the progress stop means 56, the progress resume means 57, and the setting means 58.
  • it is configured to realize each function, it is not limited to this configuration.
  • the communication terminal 10 can have substantially the same hardware configuration, each function can be realized by the communication terminal 10 as described in the above embodiment.
  • the user data (user information) and the monster character data (character information) are stored in the database server 30 (game database 32) as a storage device. You may provide in the terminal 10.
  • the storage device may be a mass storage device such as the RAM 13 in the communication terminal 10 or an HDD (Hard Disk Drive) (not shown).
  • the communication terminal 10 receives the user of the communication terminal 10 from the game server 20 or the database server 30 prior to battle processing.
  • User data first user information
  • user data of the user's associate second user information
  • monster character data character information
  • the communication terminal 10 transmits game result data such as a battle result to the game server 20, and the game server 20 records the received game result data in the game database 32 in association with the user. You may make it do.
  • 19A and 19B show a case where the functions between the communication terminal 10, the game server 20, and the database server 30 are shared for each function (each function shown in FIG. 13) of the game control device of the present embodiment. An example is shown.
  • the predetermined operation input by the user to the communication terminal is an input of a pressing operation of a predetermined operation button on the user's communication terminal or an input of a touch operation on the display screen to the communication terminal having a touch panel function.
  • the operation input may be an operation input by shaking a communication terminal provided with an acceleration sensor, or an operation input by gesture (gesture input).
  • gesture input by performing a predetermined gesture on a communication terminal having an imaging function, the communication terminal recognizes an image of the gesture and recognizes an operation input previously associated with the gesture.
  • the operation input may be performed by inputting voice.
  • the game of the embodiment may be realized using a communication method directly performed between user terminals without using a server, for example, communication using P2P (Peer to Peer) or a wireless ad hoc network.
  • P2P Peer to Peer

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

　仲間の存在による恩恵をユーザがより明確に感じることができるようにしたゲーム制御装置、ゲーム制御方法、ゲーム制御プログラム、記録媒体、ゲームシステムが提供される。このゲーム制御装置は、第１のユーザのユーザ情報と、第１のユーザと関係付けられた第２のユーザのユーザ情報と、ゲームキャラクタのゲームキャラクタ情報とを記憶する記憶装置から、各情報を取得し、第１のユーザとゲームキャラクタとの対戦を、第１のユーザのユーザ情報と、第２のユーザのユーザ情報と、前記ゲームキャラクタ情報とに基づいて実行する。その対戦の対戦結果が所定の基準を満たない場合には、第１のユーザによるゲームの進行が停止させられるが、ゲーム上の所定条件を満たす場合には、停止させられた第１のユーザによるゲームの進行が再開させられる。

Description

ゲーム制御装置、ゲーム制御方法、ゲーム制御プログラム、記録媒体、ゲームシステム
　本発明は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御する技術に関する。
　近年、特定のサービス提供者によるソーシャルネットワーキングサービス（ＳＮＳ）においてウェブブラウザ上で動作するＡＰＩ(Application Programming Interface)などの動作環境を基に作成されるゲーム用アプリケーションによって実行される、いわゆるソーシャルゲーム（Social Game）が普及している。ソーシャルゲームは、不特定多数のユーザ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言える。ユーザは、インターネットに接続可能であって、かつウェブブラウザが搭載された通信端末を備えていれば、時間と場所を問わずソーシャルゲームを楽しむことができる。
　上述したソーシャルゲームでは、従来のオンラインゲームよりも、ユーザ間の交流を図るためのコミュニケーション機能が充実している点が特徴の１つとなっている。ソーシャルゲームでは、例えば、他のユーザ（仲間）との協力プレイのほか、仲間との挨拶や連絡など仲間とコミュニケーションを取ることによる情報交換、仲間との間のゲーム上のアイテムのプレゼントあるいはアイテムの交換が行なわれている。このようなソーシャルゲームの一例として、下記の非特許文献１に記載されたデジタルカードゲーム（ドラゴンコレクション（登録商標））が知られている。
アプリＳＴＹＬＥ　Vol.2（株式会社イースト・プレス）、26-27頁
　従来のソーシャルゲームにおいて、ゲームキャラクタとの間でユーザがバトルを行うときに、ユーザによる選択操作、あるいはランダムに仲間からの救済（手助け）を得ることができるようにしたものがある。仲間からの救済が得られた場合、ユーザとその仲間に設定されているゲーム上のパラメータを用いてゲームキャラクタとの間のバトルが行われる。しかし、仲間からの救済が得られた場合でもゲームキャラクタとのバトルで負けてしまうと、ユーザは自らの仲間による恩恵あるいは利益を感じ難くなってしまい、積極的に仲間を作らなくなってしまう。このような状況は、ゲームのソーシャル性を低下させ、ソーシャルゲームならではの興趣性を削ぐことになる。
　本発明は上述した観点に鑑みてなされたもので、仲間の存在による恩恵をユーザがより明確に感じることができるようにしたゲーム制御装置、ゲーム制御方法、ゲーム制御プログラム、記録媒体、ゲームシステムを提供することを目的とする。
　本発明の第１の観点は、ゲーム制御装置であって、
　第１のユーザのユーザ情報と、第１のユーザと関係付けられた第２のユーザのユーザ情報と、ゲームキャラクタのゲームキャラクタ情報とを記憶する記憶装置から、各情報を取得し、前記第１のユーザと前記ゲームキャラクタとの対戦を、前記第１のユーザのユーザ情報と、前記第２のユーザのユーザ情報と、前記ゲームキャラクタ情報とに基づいて実行する対戦実行手段と、
　前記対戦の対戦結果が所定の基準を満たない場合に、第１のユーザによるゲームの進行を停止させる進行停止手段と、
　ゲーム上の所定条件を満たす場合に、前記進行停止手段によって停止させられた第１のユーザによるゲームの進行を再開させる進行再開手段と、
　を備える。
　このゲーム制御装置において「ゲームキャラクタ」とは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。
　このゲーム制御装置において、「ユーザ情報」、「キャラクタ情報」とはそれぞれ、ユーザ及びゲームキャラクタに関連付けられた、対戦の進行あるいは結果に関係しうる定数あるいは変数のデータであってよい。例えば、対戦における攻撃又は防御についてのパラメータなどの指標値、攻撃に対する耐力を示すＨＰなどの指標値であってもよい。
　このゲーム制御装置では、第１のユーザは、自らと関係付けられた第２のユーザが関与した対戦の対戦結果について、所定の基準を満たさずゲームの進行ができない場合がある。その場合には第１のユーザは対戦結果に対して落胆するが、その後、ゲーム上の所定条件を満たす場合にはゲームの進行を再開できるようになる。ゲーム上の所定条件は、例えばプレイ中のユーザの仲間に関連する条件を含むことが好ましい。この場合、仲間の存在による恩恵をユーザがより明確に感じることができる。それによって、ソーシャル性が高く、かつ興趣性が高いゲームを実現することができる。
　上記ゲーム制御装置において、前記第１のユーザと関係付けられたユーザの中から、第１のユーザと前記ゲームキャラクタとの対戦の時点でログインしているユーザ、あるいはログインしてから前記時点までの経過時間が所定時間以内であるユーザを、前記第２のユーザとして選択する選択手段を備えてもよい。なお、選択手段は、第１のユーザと前記ゲームキャラクタとの対戦の時点からの経過時間が所定時間以内であれば、当該時点において既にログアウトしているユーザを選択してもよい。また、「ログイン」には、ゲーム自体にアクセスする際のログイン（例えば、ゲームのトップページなどにアクセスするためのログイン）のほか、ゲーム内の特定のパートや特定のステージを進行あるいは実行させるためのアクセスを含むようにしてもよい。
　この構成では、第２のユーザ（第１のユーザと関係付けられたユーザ）のログイン状況に基づいてユーザが選択されるため、ほぼ同じ時間帯にゲームを行っている第２のユーザと協力してバトルを行っている実感を第１のユーザに与えることができる。
　上記ゲーム制御装置において、前記第１のユーザと、第１のユーザと関係付けられたユーザとの間の関係度合いを示す親密度を設定する設定手段と、前記第１のユーザと関係付けられたユーザの中から、第１のユーザとの間の親密度が所定の閾値よりも高いユーザを、前記第２のユーザとして選択する選択手段と、を備えてもよい。この構成では、第１のユーザの対戦に関与する第２のユーザが、第１のユーザと関係度合いが高いユーザの中から選択されるため、関係度合いが高いユーザ間でさらに互いの恩恵を感じられるものとなり、関係度合いをさらに高めることができるようになる。
　上記ゲーム制御装置において、前記ユーザ情報は、前記対戦において前記ゲームキャラクタに対する攻撃力を示す第１指標値を含み、前記キャラクタ情報は、攻撃に対する耐力を示す指標値であって、前記攻撃力に応じて低下する第２指標値を含み、前記進行再開手段は、前記所定条件を満たすか否かについて、前記進行停止手段によってゲームの進行が停止させられたときの前記ゲームキャラクタの第２指標値が所定値以下であるか否かに基づいて決定してもよい。
　この構成においては、これによって、ゲームキャラクタの第２指標値がゼロでなく所定値以下であればゲームの進行を再開させることができ、ゲームの難易度が実質的に低下することになるため、ユーザは、仲間の存在による恩恵を明確に感じることができる。
　上記ゲーム制御装置において、前記ユーザ情報は、前記対戦において前記ゲームキャラクタに対する攻撃力を示す第１指標値を含み、前記キャラクタ情報は、攻撃に対する耐力を示す指標値であって、前記攻撃力に応じて低下する第２指標値を含み、前記進行再開手段は、前記所定条件を満たすか否かについて、前記進行停止手段によってゲームの進行が停止させられたときの前記ゲームキャラクタの第２指標値と、前記第１のユーザ及び前記第２のユーザの第１指標値の総和との比較結果に基づいて決定してもよい。
　この構成において、上記所定条件として、例えば、ゲームキャラクタの第２指標値が、第１のユーザ及び第２のユーザの第１指標値の総和よりも小さいことを条件としてもよい。このような設定であれば、ユーザは、ゲームの進行が再開された後の対戦を有利に進めることができる。そのため、ユーザは、仲間の存在による恩恵を明確に感じることができる。
　上記ゲーム制御装置において、前記進行再開手段は、前記所定条件を満たすか否かについて、前記第１のユーザと関係付けられ、かつ前記ゲームに参加しているユーザの数が所定数以上であるか否かに基づいて決定してもよい。なお、ゲームに参加しているユーザとは、ゲームにログイン済みでログアウトしていないユーザ、又は、当該ユーザの中からゲームキャラクタとの対戦を実行中のユーザであってよい。この構成では、ゲームに参加している仲間のユーザが多い場合にゲームの進行を再開できるようになるため、仲間の存在による恩恵をユーザがより明確に感じることができる。
　上記ゲーム制御装置において、前記進行再開手段は、第１のユーザが前記ゲームキャラクタとの対戦に勝利するように、前記第１のユーザによるゲームの進行を再開させてもよい。この構成では、ユーザは、ゲームの進行の再開後に無条件で勝利することができるため、仲間の存在による恩恵をユーザがさらに明確に感じることができる。
　上記ゲーム制御装置において、前記ユーザ情報は、前記対戦において前記ゲームキャラクタに対する攻撃力を示す第１指標値を含み、前記キャラクタ情報は、攻撃に対する耐力を示す指標値であって、前記攻撃力に応じて低下する第２指標値を含み、前記進行再開手段は、前記進行停止手段によって停止させられた時点の前記ゲームキャラクタの第２指標値に基づいて、前記第１のユーザと前記ゲームキャラクタとの対戦を実行してもよい。
　この構成では、ゲームの進行が停止させられた時点のゲームキャラクタの第２指標値に基づいて、第１のユーザとゲームキャラクタとの対戦が実行される。この対戦では既にゲームキャラクタの第２指標値が所定値以下となっているため、ユーザは、対戦を有利に進めることができる。よって、ユーザは、仲間の存在による恩恵を明確に感じることができる。
　本発明の第２の観点は、ゲーム制御方法である。
　このゲーム制御方法は、
　第１のユーザのユーザ情報と、第１のユーザと関係付けられた第２のユーザのユーザ情報と、ゲームキャラクタのゲームキャラクタ情報とを記憶する記憶装置から、各情報を取得し、前記第１のユーザと前記ゲームキャラクタとの対戦を、前記第１のユーザのユーザ情報と、前記第２のユーザのユーザ情報と、前記ゲームキャラクタ情報とに基づいて実行するステップと、
　前記対戦の対戦結果が所定の基準を満たない場合に、第１のユーザによるゲームの進行を停止させるステップと、
　ゲーム上の所定条件を満たす場合に、前記停止させるステップによって停止させられた第１のユーザによるゲームの進行を再開させるステップと、
　を備える。
　本発明の第３の観点は、ゲーム制御プログラムである。このゲーム制御プログラムは、コンピュータに、
　第１のユーザのユーザ情報と、第１のユーザと関係付けられた第２のユーザのユーザ情報と、ゲームキャラクタのゲームキャラクタ情報とを記憶する記憶装置から、各情報を取得し、前記第１のユーザと前記ゲームキャラクタとの対戦を、前記第１のユーザのユーザ情報と、前記第２のユーザのユーザ情報と、前記ゲームキャラクタ情報とに基づいて実行する機能、
　前記対戦の対戦結果が所定の基準を満たない場合に、第１のユーザによるゲームの進行を停止させる機能、及び
　ゲーム上の所定条件を満たす場合に、前記停止させる機能によって停止させられた第１のユーザによるゲームの進行を再開させる機能、
　を実現させるためのプログラムである。
　コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、ＤＶＤ－ＲＯＭやＣＤ－ＲＯＭ等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。すなわち、本発明の第４の観点は、前記プログラムを記録したことを特徴とする、コンピュータ読み取り可能な記録媒体である。
　本発明の第５の観点は、通信端末と、当該通信端末とネットワークを介して接続され、前記通信端末によるゲームの進行を制御するサーバと、を備えたゲームシステムである。
　このゲームシステムは、
　第１のユーザのユーザ情報と、第１のユーザと関係付けられた第２のユーザのユーザ情報と、ゲームキャラクタのゲームキャラクタ情報とを記憶する記憶装置から、各情報を取得し、前記第１のユーザと前記ゲームキャラクタとの対戦を、前記第１のユーザのユーザ情報と、前記第２のユーザのユーザ情報と、前記ゲームキャラクタ情報とに基づいて実行する対戦実行手段、
　前記対戦の対戦結果が所定の基準を満たない場合に、第１のユーザによるゲームの進行を停止させる進行停止手段、及び、
　ゲーム上の所定条件を満たす場合に、前記進行停止手段によって停止させられた第１のユーザによるゲームの進行を再開させる進行再開手段、
　の各手段を、前記通信端末又は前記サーバのいずれか一方が備える。
実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図。 実施形態の通信端末の外観の例を示す図。 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 データベースサーバに含まれるユーザデータベースの構成例を示す図。 モンスターキャラクタデータの内容を例示する図。 トップページを表示する通信端末の表示画面の一例を示す図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 実施形態のゲームサーバの主要な処理の一例を示すフローチャート。 実施形態のゲームサーバの主要な処理の変形例を示すフローチャート。 変形例に係るゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 親密度データの内容を例示する図。 実施形態のゲーム制御装置の各機能について、通信端末と、ゲームサーバ及びデータベースサーバとの間の分担例を示す図。 実施形態のゲーム制御装置の各機能について、通信端末と、ゲームサーバ及びデータベースサーバとの間の別の分担例を示す図。
　本発明は、２０１２年２月２２日に日本国特許庁に出願された特願２０１２－０３６７６７の特許出願に関連しており、当該出願の内容のすべてが参照によってこの明細書に組み込まれる。
　以下、本発明の実施形態について説明する。
　（１）ゲームシステムの構成
　図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型のスマートテレビも含む。）などの通信端末である。なお、以下の説明において、各通信端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、通信端末１０と表記する。
　このゲームシステムにおいて、ゲームサーバ２０は、クライアントである通信端末１０と通信可能に構成されており、通信端末１０に対してゲーミングサービスを提供する。ゲームサーバ２０には、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ３０は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ２０と例えば有線で接続される。
　通信端末１０は、ゲームサーバ２０によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末１０をウェブページ上で操作してゲームを実行する。
　また、図１には図示していないが、ゲームサーバ２０とは別に各通信端末１０のユーザを認証するための認証サーバを設けてもよい。また、多くの通信端末１０からのアクセスを受け入れるために複数のゲームサーバ２０を設ける場合は、その複数のゲームサーバ２０間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ２０は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。
　（２）通信端末の構成
　図２Ａ、図２Ｂ及び図３を参照して通信端末１０について説明する。
　図２Ａ、図２Ｂはそれぞれ、通信端末１０の外観の例を示す図であって、図２Ａは、例えば折り畳み式の携帯端末（携帯電話機）などの釦入力方式の通信端末を例示したものであり、図２Ｂは、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図３は、通信端末１０の内部構成を示すブロック図である。
　図３に示すように、通信端末１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、画像処理部１４、指示入力部１５、表示部１６、及び、信号送受信部としての通信インタフェース部１７を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス１８が設けられている。
　ＣＰＵ１１は、ＲＯＭ１２内のウェブブラウザをＲＡＭ１３にロードして実行する。そして、ＣＰＵ１１は、指示入力部１５等によってユーザに入力されるＵＲＬ(Uniform Resource Locator)の適切な指定に基づき、通信インタフェース部１７を介して、ゲームサーバ２０からウェブページを表示するためのデータ、すなわち、ＨＴＭＬ(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ（以下、総称して適宜「ＨＴＭＬデータ」と表記する。）を通信インタフェース部１７を介して取得し、そのＨＴＭＬデータを解釈する。なお、通信端末１０には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてよい。
　なお、ＨＴＭＬデータの取得に当たって、ＣＰＵ１１は、予め登録されたユーザＩＤ（ユーザ識別情報）、あるいは指示入力部１５を介して入力されるユーザＩＤを含むアクセス要求メッセージを、通信インタフェース部１７を介してゲームサーバ２０へ通知する。
　ウェブブラウザは、画像処理部１４を介して、取得したＨＴＭＬデータに基づき、ゲームサーバ２０から提供されるウェブページを表示部１６に表示する。また、ウェブブラウザは、ユーザが指示入力部１５の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、その選択に応じたウェブページを表示するための新たなＨＴＭＬデータの送信（つまり、ウェブページの更新）をゲームサーバ２０へ要求する。
　画像処理部１４は、ＨＴＭＬデータの解析結果としてＣＰＵ１１から与えられる表示用画像データに基づいて、表示部１６にウェブページを表示する。表示部１６は、例えば、マトリクス状に画素単位で配置された薄膜トランジスタを含むＬＣＤ(Liquid Cristal Display)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面１６ａに表示する。
　通信端末１０が釦入力方式の通信端末（図２Ａ）である場合、指示入力部１５は、ユーザの操作入力を受け入れるための方向指示釦と決定釦などの複数の指示入力釦を含む釦群１５ａ、及び、テンキーなどの複数の指示入力釦を含む釦群１５ｂを備え、各釦の押下（操作）入力を認識してＣＰＵ１１へ出力するためのインタフェース回路を含む。例えば、方向指示釦は、表示部１６に表示されているウェブページをスクロールして表示することをＣＰＵ１１へ指示するために設けられる。また、決定釦は、例えばウェブページ上で複数のハイパーリンクまたはメニューが表示されるときに、アクティブ表示（例えば強調表示）されている１つのハイパーリンクまたはメニューをユーザが選択することをＣＰＵ１１へ指示するために設けられる。なお、通信端末１０を小型の携帯端末によって構成する場合には、これらの釦は、ユーザが通信端末１０を片手で保持したままその親指で操作（クリック）しやすいように、通信端末１０の前面に配置されていることが好ましい。図２Ａに示す例では、釦群１５ｂは、釦群１５ａの下方に配置され、「０」～「９」、「＊」、「＃」（テンキー）が表記された複数の指示入力釦を含む。
　通信端末１０がタッチパネル入力方式の通信端末（図２Ｂ）である場合、指示入力部１５は、主として表示画面１６ａに指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよい。なお、図２Ｂに示すように、通信端末１０がタッチパネル入力方式の場合であっても釦群１５ａが設けられる場合もある。
　通信端末１０に表示されるウェブページ上のメニューの選択操作は、例えば通信端末１０が携帯端末である場合には、方向指示釦の押下操作によってメニューを選択し、決定釦の押下操作によって、選択したメニューを確定することによって行われる。また、選択操作は、例えば通信端末１０がタッチパネル入力方式の場合には、ウェブページが表示されている表示画面１６ａ上のメニューの位置を指あるいはペンで指示（タッチ操作）することによって行われる。
　（３）ゲームサーバの構成
　図４を参照してゲームサーバ２０の構成について説明する。
　ゲームサーバ２０は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末１０に対してゲームのウェブサービスを提供する。図３に示すように、ゲームサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、データベース（ＤＢ）アクセス部２４、及び、通信インタフェース部２５を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス２６が設けられている。なお、ゲームサーバ２０は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。
　ＲＯＭ２２には、クライアントである通信端末１０のウェブブラウザに対してＨＴＭＬ文書や画像などのオブジェクトの表示（ウェブページの表示）のサービスを提供するアプリケーションプログラムが格納されている。ＲＯＭ２２には、アプリケーションプログラム以外にもＣＰＵ２１によって参照される各種データが格納されている。
　ＣＰＵ２１は、ＲＯＭ２２内のゲームプログラムをＲＡＭ２３にロードして実行し、通信インタフェース部２５を介して、各種の処理を行う。
　例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、ＨＴＭＬデータを通信端末１０宛に送信する。なお、ゲームサーバ２０が通信端末１０のユーザの認証処理を行う場合には、ＣＰＵ２１はその認証処理を行う。
　ＣＰＵ２１は、通信インタフェース部を介して、通信端末１０で表示されるウェブページ上でユーザにより選択されたハイパーリンクまたはメニューに応じた処理を行う。その処理は、例えば、新たなＨＴＭＬデータの送信、または、ゲームサーバ２０内の演算処理あるいはデータ処理などを含む。
　データベースアクセス部２４は、ＣＰＵ２１がデータベースサーバ３０に対してデータの読み書きを行うときのインタフェースである。
　（４）データベースサーバの構成
　データベースサーバ３０（記憶装置）は、大容量のハードディスク装置やＲＡＩＤ（Redundant Arrays of Inexpensive Disks）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
　図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、ユーザデータベース３１と、ゲームデータベース３２とを備える。
　本実施形態のゲームサーバ２０によって実現されるゲームのタイプは特に限定されるものではないが、以下では、実施形態の説明の便宜上、ゲームサーバ２０によって実現されるゲームの一例として、ユーザの通信端末１０に対する操作に応じて、ユーザがゲーム上で仮想的に保有する戦士カードを使い、ゲーム上のモンスターであるモンスターキャラクタとバトル（モンスターバトル処理）を行う対戦型デジタルカードゲームを採り上げる。
　このデジタルカードゲームは、ユーザが戦士カードを収集することによって自らのチーム（軍隊）を作り上げ、例えば、他のユーザのチーム（軍隊）やモンスターキャラクタとバトルを行うように構成されているゲームである。このデジタルカードゲームには、自らのチームに組み込む戦士カードを得るためにゲーム上で設定されているエリアを探索するクエスト処理、抽選によって戦士カードを入手することを可能とする抽選処理、さらには、２枚以上の戦士カードを一体化して戦士カードの能力を上昇させる強化処理等が設けられている。
　図６に、上述した対戦型デジタルカードゲーム（以下適宜、単に「ゲーム」あるいは「本実施形態のゲーム」という。）において適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ログイン状況、ユーザ名／表示画像、技能レベル、体力ポイント、攻撃ポイント、強化ポイント、友情ポイント、戦士数、所持コイン、仲間のユーザＩＤ、保有カードの画像データ、及び保有カードのパラメータの各項目についての情報を含む。ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。
　以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ログイン状況
　対象となるユーザＩＤに基づいてログインの状況を示すデータである。ログイン中かログアウト済みかを示すデータのほか、図６に示すようにログイン時刻のデータを含む。
・ユーザ名／表示画像
　ゲームの実行時に通信端末１０にユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・技能レベル
　ゲーム上のユーザの技能レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。
・体力ポイント
　本実施形態のゲームにおいて、ユーザによるゲーム上のクエストを行う上で必要となるポイントである。体力ポイントは、クエストを行うことで低減し、所定の時間が経過する毎に回復（増加）する値である。
・攻撃ポイント
　本実施形態のゲームにおいて、ユーザによるゲーム上のバトルを行う上で必要となるポイントである。攻撃ポイントは、他のユーザ、あるいはモンスターキャラクタとのバトルによって低減し、所定の時間が経過する毎に回復（増加）する値である。
・強化ポイント
　本実施形態のゲームにおいて、ユーザによる戦士カードの強化を行う上で必要となるポイントである。強化ポイントは、戦士カードの強化を行うことで低減し、他のユーザとのバトルで勝利するか、あるいは所定の時間が経過する毎に回復（増加）する値である。
・友情ポイント
　本実施形態のゲームにおいて、仲間へ応援メッセージを送信することでユーザが取得するポイントである。
・戦士数
　ユーザが保有する戦士カードの数である。戦士数は、クエスト処理や強化処理の実行によって増減する。戦士数の最大値（例えば、６０）は予め規定されてもよい。
・所持コイン
　ユーザＩＤに対応するユーザがゲーム上で有料機能を利用するときに必要となるゲーム上の仮想通貨（コイン）の所持額である。所持コインは、ユーザがゲーム上で有料機能を利用したときに消費（低減）し、ユーザが、サービス提供者等に所定の方法で実際の金銭を支払うことでその支払額に応じて増加する。
・仲間のユーザＩＤ
　対象となるユーザＩＤと関係付けられた他のユーザＩＤのデータである。
・保有カードの画像データ
　本実施形態のゲームの場合、保有カードの画像データは、ユーザが保有する戦士カードについての画像を含むデータである。
・保有カードのパラメータ
　保有カードのパラメータは、戦士カードの能力値を示すデータである。例えば、図６に示すように、パラメータの項目として「攻撃力」，「防御力」の各々の各能力値、及び「必要ポイント」が含まれてもよい。「必要ポイント」は、戦士カードをバトルで使用するときに必要となるポイントである。このゲームでは、バトルで使用する戦士カードの必要ポイントの総計が攻撃ポイント以下となるように制限されてもよい。なお、攻撃力のパラメータの値は、第１指標値の一例である。
　図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、データベースサーバ３０によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、異なるユーザ同士のバトルの結果や、モンスターキャラクタのデータ（モンスターキャラクタデータ）、後述するモンスターバトルの実行処理の処理結果などを含む。
　モンスターキャラクタデータの一例を図７に示す。モンスターキャラクタデータは、モンスターバトル処理の実行とともに例えばＲＡＭ２３にロードされ、記憶されるデータである。図７では、３種類のモンスターキャラクタＭＣ１～ＭＣ３の各々について、モンスターキャラクタのパラメータとしてレベル（Ｌｖ）、攻撃力の値、及び、モンスターキャラクタのＨＰの値（攻撃に対する耐力を示す値；第２指標値）が示されている。モンスターキャラクタのレベルが大きくなるほど、そのモンスターキャラクタの攻撃力の値、及びＨＰの値が大きくなるように設定されてもよい。図７では、複数の種類のモンスターキャラクタを示しているが、モンスターキャラクタは少なくとも１種類設けられていればよい。
　（５）本実施形態のゲーム
　以下、本実施形態のゲーム（対戦型デジタルカードゲーム）のモンスターバトル処理について、図８～１３を参照しながら説明する。図８は、本実施形態のゲームにおいて通信端末１０上に表示されるトップページの一例を示す図である。図９～１３は、モンスターバトル処理が実行されるときの通信端末１０上に表示されるウェブページの例を示す図である。
　図８に例示する本実施形態のゲームのトップページは、個々のユーザＩＤに応じたウェブページで構成される。図８の例では、ユーザデータ表示領域、戦士画像表示領域及びメニュー表示領域を含む。
　ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル、体力ポイント、攻撃ポイント、強化ポイント、友情ポイント、戦士数、仲間の各項目のデータ（図６参照）が表示される領域である。なお、図８に例示するように、戦士数が「４０／６０」と表記されている場合、ユーザが保有する戦士カードが４０枚であり、最大で保有可能な戦士カードの枚数が６０枚であることを示す。
　戦士画像表示領域は、対象となるユーザＩＤのユーザデータに含まれる複数の戦士カードのうちユーザによって予め指定された戦士カードの画像が表示される領域である。
　メニュー表示領域は、本実施形態のゲームに設けられる複数の機能（クエスト処理、強化処理、バトル処理、抽選処理、モンスターバトル処理）に対応した基本メニューとして、「クエスト」、「強化」、「バトル」、「抽選」、「モンスターバトル」のテキストが表記された各メニューｍ１～ｍ５が表示される領域である。つまり、ゲームで実行される複数の処理が各々割り当てられた複数のメニューが、通信端末１０に表示されるウェブページの所定の位置にそれぞれ配置されている。
　図８のトップページ上でメニューｍ５が選択操作されると、図９のステップＳ１に示すようにウェブページが更新され、ユーザが体力ポイントを消費してリトルモンスターを倒すためのプレイを実行するための画面に切り替わる。ステップＳ１のウェブページには、複数体のリトルモンスターキャラクタｍｃ（図９の例では、１０体）の画像と、「攻撃する」と表記されたメニューｍ１０と、対象となるユーザの体力ポイントとが表示される。ここで、ユーザによりメニューｍ１０の選択操作が行われると、リトルモンスターキャラクタｍｃの数が例えば１～４体の中のランダムな数だけ減少するとともに、ユーザの体力ポイントの値が例えば一定量減少する。例えば、ステップＳ２に示すように、メニューｍ１０を連続して選択操作する度に、ウェブページに表示されるリトルモンスターキャラクタｍｃの数と、ユーザの体力ポイントの値とが減少するようにウェブページが更新される。
　なお、体力ポイントがゼロになった場合にはリトルモンスターキャラクタｍｃを攻撃することはできない。その場合には、体力ポイントが回復するまで待機する必要がある。
　リトルモンスターキャラクタｍｃが全滅すると、図１０のステップＳ３に示すようにウェブページが更新されて、モンスターキャラクタＭＣが出現し、モンスターキャラクタＭＣとのバトルの処理に移行する。ステップＳ３のウェブページには、モンスターキャラクタＭＣの画像のほか、「バトル開始」と表記されたメニューｍ１１と、「仲間に支援要請する」と表記されたメニューｍ１２とが表示される。ここで、メニューｍ１２が選択操作された場合には、例えばステップＳ４に示すようにウェブページが更新される。つまり、ゲームサーバ２０によって、例えばログインしている仲間のユーザの中からランダムに選択されたユーザが、プレイ中のユーザのバトルを支援するために駆け付けるゲーム設定となっている。なお、支援を行う他のユーザは、支援要請があったこと、及び支援要請を受諾したことを認識せずに、ゲームサーバ２０内で、あたかもバトルを支援するために駆け付けたようにプレイ中のユーザに見せるように設定してよい。また、支援を行う仲間のユーザの数の上限値（ステップＳ４の例では、５名）を予め設定してもよい。
　ステップＳ４では、支援を行う仲間のユーザ名（図１０の例では、「ＧＩＰ」，「ＮＧＹ」，「ＨＫＴ」，「ＪＫＴ」，「ＲＩＭ」というユーザ名）とアバタ画像が表示されるとともに、モンスターキャラクタＭＣのＨＰを示すＨＰゲージ２０１が表示されている。
　ステップＳ４の後、図１１のステップＳ５に示すようにウェブページが更新される。ステップＳ５のウェブページでは、プレイ中のユーザの５枚の戦士カード（ユーザの戦士カード２０２）と、支援を行う５名の仲間のユーザの戦士カード１枚ずつの計５枚の戦士カード（仲間の戦士カード２０３）とが表示される。また、ステップＳ５のウェブページでは、「攻撃する」と表記されたメニューｍ１３が表示される。ユーザの戦士カード２０２は、プレイ中のユーザが保有する戦士カードの中からランダムに、あるいは予めプレイ中のユーザの選択によって決定されてよい。仲間の戦士カード２０３の各々は、各仲間の代表的な（例えばリーダーの）戦士カードとして予め決定されているカードであってよい。
　ここで、メニューｍ１３が選択操作されると、ステップＳ６に示すようにウェブページが更新されて、ユーザが仲間の支援を受けて、モンスターキャラクタＭＣとの間でゲーム上のバトルを行うことになる。
　モンスターキャラクタＭＣとのバトルでは、メニューｍ１３の選択操作に応じて行われる１０枚の戦士カードの攻撃によって、モンスターキャラクタＭＣのＨＰが低下する。また、メニューｍ１３の選択操作に応じて、あるいはランダムなタイミングで、モンスターキャラクタＭＣから１０枚の戦士カードに対して順に攻撃が行われる。ステップＳ６のウェブページの１０枚の戦士カード２０２，２０３のうち、モンスターキャラクタＭＣに倒された戦士カード（ステップＳ６の例では、３枚のユーザの戦士カード２０２）については、倒れた形態でカードが表示される。バトルの結果、例えば、モンスターキャラクタＭＣのＨＰがゼロにならず、かつプレイ中のユーザの手持ちの戦士カードがすべて倒された（全滅した）場合には、ユーザがバトルにおける所定の基準を満たさないと判断されて、ステップＳ７に示すようにウェブページが更新される。例えば、モンスターキャラクタＭＣのＨＰがゼロになり、かつプレイ中のユーザの手持ちの戦士カードが少なくとも１枚倒されずにいる場合には、ユーザがバトルにおける所定の基準を満たしたと判断されて、ステップＳ９に示すようにウェブページが更新される。
　ステップＳ７のウェブページは、ユーザの戦士カード２０２、及び仲間の戦士カード２０３がすべて倒された（つまり、全滅した）場合が例示されている。このウェブページ上では、メニューｍ１３は表示されず、バトルの進行（つまり、ゲームの進行）が停止した状態となる。
　ここで、本実施形態のゲームでは、所定の復活条件を満たす場合には、ステップＳ８に示すようにウェブページが更新され、ユーザの戦士カード２０２、及び仲間の戦士カード２０３がすべて復活する。復活条件は、例えば、プレイ中のユーザが仲間の支援を受けており（すなわち、仲間の戦士カード２０３がバトルに関与しており）、かつモンスターキャラクタＭＣのＨＰが所定値以下であるという条件である。つまり、このゲームでは、基本的には、バトルにおける所定の基準を満たさなければゲームの進行が停止されてしまうが、所定の復活条件を満たす場合に限り、ゲームの進行が再開されることになる。
　ゲームの進行が再開され、ステップＳ８のウェブページ上でメニューｍ１３が選択操作されると、例えば図１３のステップＳ９に示すようにウェブページが更新される。この例では、メニューｍ１３の選択操作によってモンスターキャラクタＭＣのＨＰがゼロとなり、モンスターキャラクタＭＣが倒されたことが表示される。
　（６）ゲーム制御装置における各処理の概要
　次に、上述した本実施形態のゲームを実現するためゲーム制御装置における各処理について説明する。
　本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述した対戦型デジタルカードゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図１４を参照して説明する。図１４は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
　なお、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネル操作によるウェブページのスクロール操作によって変化しうる。
　登録手段５１は、例えば通信端末１０に提供するウェブページ上での通信端末１０への適切な操作入力に基づいてユーザの要求を認識し、登録処理を行う。この場合の登録手段５１は、例えば以下のとおり実行される。ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して通信端末１０から登録要求メッセージを受信する。登録要求メッセージは、ゲームサーバ２０から提供されるウェブページ上での通信端末１０に対する所定の操作（例えば、所定のメニューの選択操作、テキスト入力等）によって自動的に生成されるように、ウェブページが構成されていてもよい。登録要求メッセージには、送信元の通信端末１０を特定するための情報（例えばＩＰアドレス、メールアドレス等）が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザＩＤが含まれていてもよい。
　ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれていない場合には、ユーザＩＤを新規に発行してそのユーザＩＤの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末１０へ送信する。ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれている場合には、そのユーザＩＤの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末１０へ送信する。
　登録が完了すると、ＣＰＵ２１は、ユーザＩＤに対応するユーザデータを生成し、ユーザデータベース３１に格納する。
　登録手段５１はまた、異なるユーザ間を関係付ける機能を含んでいてもよい。つまり、登録手段５１は、例えばユーザＩＤに基づく申請を契機として、当該ユーザＩＤを他のユーザＩＤとを関係付けて登録してもよい。すなわち、登録手段５１は、ユーザＩＤに基づく申請を契機として、他のユーザＩＤ（つまり、他のユーザ）を「仲間」として登録する。
　この場合の登録手段５１は例えば、以下のとおり実行される。ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して、あるユーザＩＤに対応するユーザの通信端末１０から、仲間になりたいユーザＩＤ（あるいは、対応するユーザ名）を指定した申請メッセージ（申請）を受け付ける。この申請メッセージの送信は、ユーザの通信端末１０に提供されるウェブページの機能として予め設定されている。ＣＰＵ２１は、申請メッセージを受け付けると、申請メッセージに含まれるユーザＩＤに基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０宛に、他のユーザＩＤに基づく申請を承認するか否かを返信することを要求するためのウェブページを表示させるＨＴＭＬデータを送信する。その申請を承認することが返信されれば、ＣＰＵ２１は、両者を仲間として登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータの「仲間」の箇所（図６参照）にデータを書き込む。
　なお、ユーザ同士を関係付ける条件は、上記のような申請と承認を必要とする形式に限らず、同一のゲーム上のステージを実行するゲームユーザやバトルを行ったユーザを、ユーザとゲーム内で関係付けられたユーザ、つまり仲間として登録しても良い。
　ゲーム進行手段５２は、各ユーザのログイン時の認証や、ログイン時刻及びログアウト時刻を管理する機能を備える。ゲーム進行手段５２のこの機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、各ユーザの通信端末１０からのＨＴＴＰリクエストを受信すると、当該ＨＴＴＰリクエストに含まれる個体識別番号や、ユーザＩＤ及びパスワードと、例えばユーザデータベース３１に記録しているデータと照合して認証処理を行うとともに、ユーザデータにアクセスしてログイン状況についての情報を更新する。また、ＣＰＵ２１は、ユーザがログアウトした場合も、ユーザデータにアクセスしてログイン状況についての情報を更新する。
　なお、ゲーム進行手段５２は、ログイン時刻として、本実施形態のゲーム自体にアクセスする際のログイン（例えば、ゲームのトップページなどにアクセスするためのログイン）の時刻のほか、ゲーム内の特定の処理（モンスターバトル処理等）や当該処理における特定のステージの処理を進行あるいは実行させるためのアクセスの時刻を管理してもよい。
　ゲーム進行手段５２はさらに、認証後に、通信端末１０に対するユーザの操作に応じて、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータを送信することで、ゲームを進行させる機能を備える。本実施形態のゲームの例では、ゲームを進行させる上で以下の処理が行われうる。
・クエスト処理：
　自らのチームを作り上げていくためにゲーム上で設定されているエリアを探索して戦士カードを得る処理である。このゲームでは、クエスト処理を実行するには、一定量の行動ポイントが必要となる。
・強化処理：
　２人以上の戦士カードを一体化して特定の戦士の能力を上昇させる処理である。このゲームでは、ユーザが強化処理を実行するには一定量の強化ポイントが必要となる。
・バトル処理：
　他のユーザのチームとバトルを行う処理である。
・抽選処理： 
　ユーザが戦士カードを入手するための抽選を行う処理である。
・モンスターバトル処理：
　図９～１３のステップＳ１～Ｓ９に例示したように、ユーザが自らの戦士カード、さらには仲間の戦士カードを用いて、モンスターキャラクタとバトルを行う処理である。
　ゲーム進行手段５２は、図８に示したように、ゲームで実行される上記複数の処理が各々割り当てられた複数のメニューを通信端末１０に表示させる機能を備える。具体的には、ＣＰＵ２１は、複数のメニューを含むウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。ゲームでは、クエスト処理、強化処理、バトル処理、抽選処理、モンスターバトル処理の各処理の実行に伴ってゲーム上のポイントが消費される。
　例えば図８に示すトップページをユーザの通信端末１０に表示する場合、ゲーム進行手段５２は以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、データベースアクセス部２４を介してユーザデータベース３１にアクセスし、ユーザデータ表示領域に含まれる各項目のデータと、戦士画像表示領域に表示すべき戦士カードの画像データを読み出す。次にＣＰＵ２１は、図８に示したトップページが構成されるようにＨＴＭＬデータを生成し、通信端末１０宛に送信する。生成されるＨＴＭＬデータは、ユーザごと（つまり、ユーザＩＤごと）に異なるものとなる。通信端末１０は、受信したＨＴＭＬデータを解釈してトップページの画像を表示部１６（表示画面１６ａ）に表示する。
　ＣＰＵ２１は、通信端末１０に表示されたメニューｍ１～ｍ５のいずれかに対するユーザの選択操作に応じて、それぞれクエスト処理、強化処理、バトル処理、抽選処理、及び、モンスターバトル処理を実行する。好ましくは、各処理が実行された場合、さらに細分化された複数のメニューを含む新たなウェブページが表示されるように、階層的に各処理が実行される。
　記憶手段５３は、ユーザのゲーム上の情報であるユーザデータ（ユーザ情報；図６参照）をユーザデータベース３１（記憶装置）に記憶させ、モンスターキャラクタの情報を示すモンスターキャラクタデータ（キャラクタ情報；図７参照）をゲームデータベース３２（記憶装置）に記憶させる機能を備える。記憶手段５３では、ゲームサーバ２０のＣＰＵ２１が、データベースアクセス部２４を介してユーザデータベース３１又はゲームデータベース３２にアクセスし、データの書き込みを行う。データの書き込みは、新たなユーザデータの書き込み、既存のユーザデータの更新、新たなモンスターキャラクタデータの書き込み、既存のモンスターキャラクタデータの更新等を含む。
　選択手段５４は、本実施形態のゲームにおけるモンスターバトル処理において、プレイ中のユーザ（第１のユーザ）の仲間のうち、モンスターキャラクタとのバトルにおいて支援を行うユーザを選択する機能を備える。プレイ中のユーザの仲間の中からのユーザの選択方法は、任意に設定することができる。例えば、プレイ中のユーザの仲間の中からランダムに所定数（図１０の例では、５人）のユーザを選択してもよい。また、ユーザの選択方法は、所定の選択条件に従って行われてもよい。
　選択条件として、プレイ中のユーザによって図１０のメニューｍ１２の選択操作が行われたタイミングで、ログアウトしていないユーザ、あるいはログインしてから当該タイミングまでの経過時間が所定時間以内であるユーザであることを条件としてもよい。この場合、メニューｍ１２の選択操作が行われたタイミングでは、既にログアウトしたユーザが選択されてもよい。このようにログイン状況に基づいてユーザを選択することで、ほぼ同じ時間帯にゲームを行っている仲間と協力してバトルを行っている実感をプレイ中のユーザに与えることができる。また、「ログイン」には、本実施形態のゲーム自体にアクセスする際のログイン（例えば、ゲームのトップページなどにアクセスするためのログイン）のほか、ゲーム内のモンスターバトル処理やモンスターバトル処理における特定のステージの処理を進行あるいは実行させるためのアクセスを含むようにしてもよい。
　選択手段５４において、ゲームサーバ２０のＣＰＵ２１は、プレイ中のユーザのユーザデータを参照して、仲間のユーザＩＤを読み出し、読み出したユーザＩＤの中からランダムに、あるいは予め設定された選択条件に従ってユーザＩＤを選択する処理を行う。このとき、例えば、ログイン状況についてのデータが選択条件についての判定のために読み出される。
　対戦実行手段５５は、本実施形態のゲームにおけるモンスターバトル処理において、プレイ中のユーザ（第１のユーザ）とモンスターキャラクタ（ゲームキャラクタ）との対戦を、プレイ中のユーザのユーザデータと、当該ユーザの仲間（第２のユーザ）のユーザデータと、モンスターキャラクタデータとに基づいて実行する機能を備える。本実施形態のゲームにおいて、モンスターバトル処理は複数のステージから構成されてもよく、各ステージでユーザがバトルを行うモンスターキャラクタとそのレベル（Ｌｖ）が異なるようにしてもよい。また、モンスターバトル処理において、例えば、ユーザが保有する戦士カードの中からモンスターキャラクタとのバトルに参加可能な戦士カードの数と、プレイ中のユーザに対して支援を行う仲間の戦士カードの数とが予め規定されていてもよい（例えば、各５枚）。
　対戦実行手段５５の機能は、例えば以下のようにして実現される。
　ゲームサーバ２０のＣＰＵ２１は先ず、ユーザの戦士カードと仲間の戦士カードのパラメータをユーザデータベース３１から読み出し、ＲＡＭ２３に記憶させる。また、ＣＰＵ２１は、ゲームデータベース３２にアクセスして、プレイ中のユーザのプレイ対象となるステージに対応するモンスターキャラクタの攻撃力とＨＰ（初期値）を決定し、ＲＡＭ２３に記憶させる。攻撃力とＨＰ（初期値）の値は、例えば図７に示した攻撃力とＨＰの値の範囲の中からランダムに決定してよく、あるいはステージの進行に応じて値が大きくなるように決定してよい。ＣＰＵ２１は、バトル実行中はＲＡＭ２３に記憶されたデータに基づいて、以降の処理を行う。
　ＣＰＵ２１は、メニューｍ１３（図１１参照）に対する選択操作（以下、「攻撃指示操作」という。）を認識すると、プレイ中のユーザのランダムな数の手持ちの戦士カードによる１回の攻撃をモンスターキャラクタに対して行う。各戦士カードによる１回の攻撃力は、戦士カードのパラメータの攻撃力の値（図６参照；第１指標値）の総和によって決定されてよい。ＣＰＵ２１は、攻撃に行った１又は複数の戦士カードの攻撃力の値の総和に応じて、ＲＡＭ２３内のモンスターキャラクタのＨＰ（第２指標値）の値を低下させる。つまり、ＣＰＵ２１は、ＲＡＭ２３内のモンスターキャラクタのＨＰの値を書き換えるとともに、書き換え後の値に応じてＨＰゲージ２０１の目盛りの量を決定する。
　ＣＰＵ２１は、モンスターキャラクタからも戦士カードに対し、攻撃指示操作が行われたタイミングで、あるいはランダムなタイミングで、ＲＡＭ２３に記憶させた攻撃力で攻撃を発生させる。例えば、ＣＰＵ２１は、ＲＡＭ２３にアクセスして、モンスターキャラクタの攻撃力の値を読み出す。ＣＰＵ２１は、モンスターキャラクタによる攻撃を、例えば、バトルに参加中の１又は複数のランダムな戦士カードに対して与え、攻撃が与えられた戦士カードのうち、防御力がモンスターキャラクタの攻撃力よりも小さい戦士カードについては、攻撃によって倒されたと判断する。
　進行停止手段５６は、対戦実行手段５５によるモンスターキャラクタとのバトル結果（対戦の対戦結果）が所定の基準を満たない場合に、プレイ中のユーザ（第１のユーザ）によるモンスターキャラクタと第１のユーザとの対戦ゲームの進行を停止させる機能を備える。なお、進行停止手段５６によって停止させられる対戦ゲームは、第１のユーザが実行中のモンスターキャラクタとのバトルに限られ、例えばクエスト処理や強化処理等、バトル以外のゲームの実行は停止しない。
　進行停止手段５６の機能は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、ユーザとモンスターキャラクタとのバトルの結果、例えば、モンスターキャラクタのＨＰがゼロにならず、かつプレイ中のユーザの手持ちの戦士カードがすべて倒された（全滅した）場合には、ユーザがバトルにおける所定の基準を満たさないと判断し、モンスターキャラクタのＨＰがゼロになり、かつプレイ中のユーザの手持ちの戦士カードが少なくとも１枚倒されずにいる場合には、ユーザがバトルにおける所定の基準を満たしたと判断する。ＣＰＵ２１は、ユーザがバトルにおける所定の基準を満たさないと判断した場合には、例えばユーザによる攻撃指示操作ができないようにすることで、ユーザによる対戦ゲームの進行を停止させる。
　なお、モンスターキャラクタとのバトルが所定の基準を満たすか否かの判断基準は、上述した例に限られない。一定回数の攻撃指示操作の後、あるいは最初に攻撃指示操作を行ってから一定時間経過した後に、ユーザの手持ちの戦士カードがすべて倒された（全滅した）場合、あるいは、モンスターキャラクタのＨＰがゼロにならない場合に、所定の基準を満たさないと判断してもよい。
　進行再開手段５７は、復活条件（ゲーム上の所定条件）を満たす場合に、進行停止手段５６によって停止させられたプレイ中のユーザ（第１のユーザ）によるモンスターキャラクタと第１のユーザとの対戦ゲームの進行を再開させる機能を備える。なお、進行再開手段５７によって再開させられるバトルゲームは、第１のユーザが実行中のモンスターキャラクタとのバトルに限られ、例えばクエスト処理や強化処理等、バトル以外のゲームの実行とは無関係である。
　進行再開手段５７の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、プレイ対象となるステージにおいてモンスターキャラクタを倒すことができなかったと判断した場合でも、所定の復活条件を満たすと判断したときには、ゲームの進行を再開させる。具体的には、ＣＰＵ２１は、所定の復活条件を満たすと判断したときには、それまでのモンスターキャラクタとのバトルによって倒されたユーザの戦士カード、及び仲間の戦士カードを復活させ、ユーザによる攻撃指示操作を受け入れ可能とする。それによって、プレイ中のユーザによる対戦ゲームの進行の再開が可能となる。所定の復活条件は、例えば、プレイ中のユーザが仲間の支援を受けており（すなわち、仲間の戦士カードがバトルに参加しており）、かつモンスターキャラクタのＨＰが所定値以下であるという条件であってよい。
　なお、進行再開手段５７は、一度の進行停止手段５６によって対戦が停止した際の対戦結果を変更して新たな第２の対戦結果を決定してもよい。例えば、進行再開手段５７は、進行停止手段５６による対戦結果がユーザの敗北であった場合、第２の対戦結果をユーザの勝利としてもよい。
　また、進行再開手段５７は、復活条件を満たさない場合は、進行停止手段５６によって対戦が停止した際の対戦結果がユーザに提示され、復活条件を満たす場合は、ゲーム進行が再開された結果変更された第２の対戦結果を提示するようにしても良い。
　（７）本実施形態のゲーム制御装置の主要な処理のフロー
　次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１５のフローチャートを参照して説明する。図１５は、本実施形態のゲーム制御装置によって、本実施形態のゲームのモンスターバトル処理を示すフローチャートである。なお、図１５のフローチャートは、図１０～１３のステップＳ３～Ｓ９のウェブページに対応した処理である。図１５のフローチャートにおける各処理の実行に伴って適宜、ステップＳ３～Ｓ９の各ウェブページを表示するためのＨＴＭＬデータがゲームサーバ２０から通信端末１０宛に送信されるが、ＨＴＭＬデータの送信処理はフローチャートには記載せず、ステップＳ３～Ｓ９の符号のみを記載してある。
　先ず、図１０のステップＳ３に示したようにモンスターキャラクタＭＣが出現するウェブページ上で、メニューｍ１２が選択されたことが認識されると（ステップＳ１００：ｍ１２）、選択手段５４は、プレイ中のユーザの仲間のうち、モンスターキャラクタとのバトルにおいて支援を行うユーザを、例えば所定の選択条件に従って選択する（ステップＳ１１０）。選択条件は、例えば、メニューｍ１２の選択操作を認識したタイミングで、ログアウトしていないユーザ、あるいはログインしてから当該タイミングまでの経過時間が所定時間以内であるユーザであることを条件であってよい。支援を行う仲間の最大数は予め定めておいてもよく、図１０の例では、５人である。支援を行う仲間が決定されると、ゲームサーバ２０からプレイ中のユーザの通信端末１０宛にＨＴＭＬデータが送信され、それによって図１０のステップＳ４に示すように、ウェブページが更新される。一方、図１０のステップＳ３のウェブページ上で、メニューｍ１１が選択されたことが認識されると（ステップＳ１００：ｍ１１）、プレイ中のユーザが単独でモンスターキャラクタＭＣとバトルを行うと判断され、仲間の選択は行われない。
　次に、図１１のステップＳ５に示すようにウェブページが更新される。なお、図１１のステップＳ５のウェブページでは、仲間が選択されたときの場合のウェブページであるが、仲間が選択されなかったときには仲間の戦士カード２０３は表示されない。
　以下では、選択手段５４によって仲間が選択された場合を想定して説明する。
　ステップＳ５のウェブページ上でメニューｍ１３の選択操作、すなわち攻撃指示操作がなされたことが認識されると（ステップＳ１２０：ＹＥＳ）、対戦実行手段５５は、モンスターキャラクタＭＣとのバトル処理を行う（ステップＳ１３０）。このバトル処理は、プレイ中のユーザのユーザデータと、ステップＳ１１０で選択された仲間のユーザデータと、モンスターキャラクタデータとに基づいて実行される。バトル処理においては、攻撃指示操作に応じて、プレイ中のユーザの手持ちの戦士カード（ユーザの戦士カードと仲間の戦士カード）からモンスターキャラクタＭＣに対して攻撃が行われ、それによってモンスターキャラクタＭＣのＨＰが低下し、ウェブページ上のＨＰゲージ２０１の目盛りの量が低下する。また、バトル処理においては、攻撃指示操作に応じて、あるいはランダムなタイミングで、モンスターキャラクタＭＣからプレイ中のユーザの手持ちの戦士カードに対して攻撃が行われ、それによって１又は複数枚の戦士カードが倒される場合がある。ＨＰゲージ２０１の目盛りが変化する、あるいは戦士カードが倒されることによって、例えば図１１のステップＳ６に示すように、逐次ウェブページが更新される。
　モンスターキャラクタＭＣとのバトルが終了したか否かの判定（ステップＳ１４０）は適宜行うことができる。例えば、一定回数の攻撃指示操作がなされたこと、あるいは最初に攻撃指示操作を行ってから一定時間経過したことをもってバトルが終了したと判定を行ってもよいし、モンスターキャラクタＭＣのＨＰがゼロになった場合、又はプレイ中のユーザの手持ちの戦士カードがすべて倒された（全滅した）場合にバトルが終了したと判定してもよい。
　モンスターキャラクタＭＣとのバトルが終了したと判定された場合には（ステップＳ１４０：ＹＥＳ）、ステップＳ１５０へ進む。モンスターキャラクタＭＣとのバトルが終了していないと判定された場合には（ステップＳ１４０：ＮＯ）、ステップＳ１２０へ戻り、次の攻撃指示操作を受け入れ可能な状態となる。
　進行停止手段５６は、モンスターキャラクタＭＣとのバトル結果が所定の基準に満たない場合に（ステップＳ１５０：ＮＯ）、図１２のステップＳ７に示すようにウェブページを更新して、プレイ中のユーザによるゲームの進行を停止させる。つまり、ユーザによる攻撃指示操作ができないようにする。ここで、進行停止手段５６は、ユーザとモンスターキャラクタＭＣとのバトルの結果、例えば、モンスターキャラクタＭＣのＨＰがゼロにならず、かつプレイ中のユーザの手持ちの戦士カードがすべて倒された（全滅した）場合には、ユーザがバトルにおける所定の基準を満たさないと判断し（ステップＳ１５０：ＮＯ）、モンスターキャラクタＭＣのＨＰがゼロになり、かつプレイ中のユーザの手持ちの戦士カードが少なくとも１枚倒されずにいる場合には、ユーザがバトルにおける所定の基準を満たしたと判断してもよい(ステップＳ１５０:ＹＥＳ)。
　プレイ中のユーザが所定の基準を満たしたと判断された場合には、図１３のステップＳ９に示すようにウェブページが更新され、ゲーム進行手段５２は、ユーザが次のステージへ進むことを許可する(ステップＳ１５０：ＹＥＳ)。
　一方、進行再開手段５７は、ステップＳ１５０において所定の基準を満たさないと判断された場合には、所定の復活条件を満たすか否かについて判断される（ステップＳ１６０）。ステップＳ１５０において所定基準を満たさないと判断され、かつ所定の復活条件を満たさないと判断された場合には（ステップＳ１６０：ＮＯ）、ユーザは次のステージへ進めない。一方、ステップＳ１５０において所定基準を満たさないと判断された場合であっても、所定の復活条件を満たすと判断された場合に限り（ステップＳ１６０：ＹＥＳ）、図１２のステップＳ７のウェブページで停止したモンスターキャラクタＭＣとのバトルを再開させる。つまり、進行再開手段５７は、モンスターキャラクタとのバトルによって倒されたユーザの戦士カード、及び仲間の戦士カードを復活させて、ステップＳ８に示すようにウェブページを更新させる。これによって、ユーザによる攻撃指示操作を受け入れ可能な状態となる。復活条件は、例えば、プレイ中のユーザが仲間の支援を受けており（すなわち、仲間の戦士カード２０３がバトルに関与しており）、かつモンスターキャラクタＭＣのＨＰが所定値以下であるという条件である。ゲームの進行が再開された場合には、進行再開手段５７は、１回の攻撃指示操作に応じて、図１５のフローチャートに示すように、ステップＳ８からステップＳ９へウェブページを更新させてもよい。つまり、手持ちの戦士カードが復活した場合には、無条件にプレイ中のユーザがモンスターキャラクタＭＣとのバトルに勝利するように構成してもよい。これによって、プレイ中のユーザは、手持ちの戦士カードが復活後に直ちに勝利するという爽快感が得られる。そして、ゲーム進行手段５２は、ユーザが次のステージへ進むことを許可する。
　上述したように、本実施形態のゲーム制御装置では、手持ちの戦士カード（ユーザの戦士カード、及び仲間の戦士カード）がすべて全滅した場合等、バトル結果が所定の基準を満たさない場合にはバトルの進行を停止するが、その場合であっても、少なくともプレイ中のユーザが仲間の支援を受けていることを含む復活条件を満たす場合に限り、バトルの進行を再開させる。そのため、プレイ中のユーザは、手持ちの戦士カードが全滅してバトルを進めることができずに一旦は落胆するが、その後に、手持ちの戦士カードが復活してバトルを再開できるようになるため、仲間の存在による恩恵をユーザがより明確に感じることができる。
　なお、復活条件は、プレイ中のユーザが仲間の支援を受けていることの他に、追加の条件を含むことが好ましい。復活条件を、プレイ中のユーザが仲間の支援を受けていることのみとしてしまうと、プレイ中のユーザが仲間の支援を受けている場合には常に復活することになって、ゲームの興趣性が低下する虞がある。追加の条件としては、前述したように、例えば、モンスターキャラクタＭＣのＨＰが所定値以下であるとすることが好ましい。これによって、モンスターキャラクタＭＣのＨＰがゼロでなく所定値以下であればゲームの進行を再開させることができるため、ゲームの難易度を低下させる効果がある。また、本実施形態では、モンスターキャラクタＭＣのＨＰをＨＰゲージ２０１によってユーザが視認できるため、モンスターキャラクタＭＣのＨＰを所定値以下とする（つまり、復活条件を満たすようにする）ことをユーザに動機付けしやすい。
　図１５のフローチャートに示したように、手持ちの戦士カードが復活したときに、無条件にプレイ中のユーザがモンスターキャラクタＭＣとのバトルに勝利するように構成した場合には、復活後にユーザは必ず勝てるため、仲間の存在による恩恵をユーザがさらに明確に感じることができる。
　（８）変形例
　上述した実施形態では、複数のカードを用いたバトルを行う場合を例として説明したが、これに限られない。カードでなく、各種オブジェクトであってもよい。また、バトルにおけるカードやオブジェクトは複数でなくてもよく、単一のカードやオブジェクトで構わない。
　以下、上述した実施形態の変形例について説明する。
　（８－１）変形例１
　上述した実施形態において、図１５のフローチャートでは、手持ちの戦士カードが復活した場合には、無条件にプレイ中のユーザがモンスターキャラクタＭＣとのバトルに勝利することとしたが、このような構成に限られない。図１６のフローチャートのように構成してもよい。つまり、復活条件を満たす場合には（ステップＳ１６０：ＹＥＳ）、ステップＳ１２０に戻り、進行再開手段５７が、対戦実行手段５５と同様のバトルの処理を再度実行するようにしてもよい。これにより、進行停止手段５６によって停止させられた時点のモンスターキャラクタＭＣのＨＰ（第２指標値）に基づいて、プレイ中のユーザとモンスターキャラクタＭＣとの対戦が実行される。無条件にユーザの勝利とせずに再度バトルを継続する構成であっても、モンスターキャラクタＭＣのＨＰが所定値以下であることを復活条件が含む場合には、バトルの処理を再度実行するときに既にモンスターキャラクタＭＣのＨＰが所定値以下となっているため、ユーザは、復活した手持ちの戦士カードを用いてバトルに勝利する可能性を高めることができる。よって、かかる構成であっても、ユーザは、仲間の存在による恩恵を明確に感じることができる。
　（８－２）変形例２
　上述した実施形態において、選択手段５４における仲間のユーザの選択条件に、仲間のユーザ間の関係度合いを含むようにしてもよい。
　本変形例のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図を図１７に示す。図１７に示す機能ブロック図は、図１４に示したものと比較して設定手段５８が追加された点で異なる。
　設定手段５８は、仲間のユーザ間の関係度合いを示す親密度を設定する機能を備える。ここで、親密度とは、仲間のユーザ間の関係性の高さを一定の基準で数値化したものである。親密度のデータ（親密度データ）の一例を図１８に示す。図１８に示す親密度データの例では、各ユーザの仲間のユーザ（ユーザＩＤ）と対応付けて、ユーザ間の応援メッセージの送信あるいは受信の頻度（応援頻度）、ゲーム上で使用可能なアイテムなどのプレゼントを送信あるいは受信した回数（プレゼント回数）や、仲間のユーザ間でのバトル回数などが記録され、これらの頻度や回数に基づいて一定の基準で親密度の値が設定される。応援頻度、プレゼント回数や、バトル回数が多いほど親密度が高く設定される。また、一定の基準では、親密度の設定の基礎となる項目（図１８では、応援頻度やプレゼント回数など）ごとに、重み付けを考慮したものであってもよい。例えば、応援頻度が少なくてもプレゼント回数が多い場合に親密度を高く設定してもよい。このような親密度データは、例えば、ユーザデータベース３１内に記録される。
　設定手段５８の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ユーザデータベース３１内のユーザデータと親密度データをユーザＩＤごとに紐付けて管理している。ＣＰＵ２１は、例えば応援メッセージの送受信やプレゼントの仲間の間での送受信を、通信インタフェース部２５を介して送信先のユーザの要請に基づいて行っている。このような送受信が生ずると、ＣＰＵ２１は、対象となる親密度データを逐次更新する。
　また、本変形例では、選択手段５４は、プレイ中のユーザ（第１のユーザ）の仲間のユーザの中から、プレイ中のユーザとの間の親密度が所定の閾値よりも高いユーザを選択してもよい。この場合、ＣＰＵ２１は、プレイ中のユーザの親密度データにアクセスして、仲間の中から、親密度が所定の閾値よりも高いユーザを検索して、プレイ中のユーザのバトルの支援を行う所定数のユーザを選択する。親密度が所定の閾値よりも高いユーザが、バトルに支援可能な所定数のユーザ数よりも多く存在する場合には、ＣＰＵ２１は、ランダムに選択してよい。
　本変形例では、プレイ中のユーザのバトルの支援を行う仲間が、プレイ中のユーザと関係度合いが高い仲間の中から選択されるため、関係度合いが高いユーザ間でさらに互いの恩恵を感じられるものとなり、関係度合いをさらに高めることができるようになる。
　（８－３）変形例３
　上述した実施形態とは異なり、進行再開手段５７は、復活条件を満たすか否かについて、進行停止手段５６によってゲームの進行が停止させられたときのモンスターキャラクタのＨＰ（第２指標値）と、プレイ中のユーザ（第１のユーザ）及び支援を行う仲間（第２のユーザ）の戦士カードの攻撃値（第１指標値）の総和との比較結果に基づいて決定してもよい。ここでは、例えば、進行停止手段５６がモンスターキャラクタとのバトルの進行を停止させるときの所定の基準が、一定回数の攻撃指示操作の後、あるいは最初に攻撃指示操作を行ってから一定時間経過した後のバトル結果に基づいて行われる場合が想定される。この場合、一定回数の攻撃指示操作の後、あるいは最初に攻撃指示操作を行ってから一定時間経過した後に、モンスターキャラクタのＨＰがゼロ（第２指標値）にならない場合に、所定の基準を満たさないと判断されるが、そのような場合であっても、モンスターキャラクタのＨＰが、ユーザの手持ちの戦士カードの攻撃値（第１指標値）の総和よりも小さい場合には、手持ちの戦士カードが復活するようにしてもよい。これにより、バトルの処理を再度実行するときに既にモンスターキャラクタＭＣのＨＰがユーザの手持ちの戦士カードの攻撃値の総和よりも小さくなっているため、ユーザは、復活した手持ちの戦士カードを用いてバトルを有利に進めることができる。よって、かかる構成であっても、ユーザは、仲間の存在による恩恵を明確に感じることができる。
　（８－４）変形例４
　上述した実施形態とは異なり、進行再開手段５７は、復活条件を満たすか否かについて、プレイ中のユーザ（第１のユーザ）と仲間のユーザであって、かつゲームに参加しているユーザの数が所定数以上であるか否かに基づいて決定してもよい。なお、ゲームに参加しているユーザとは、本実施形態のゲームにログイン済みでログアウトしていないユーザ、又は、当該ユーザの中からモンスターバトル処理を実行中のユーザであってよい。このように、ゲームに参加している仲間のユーザが多い場合に、手持ちの戦士カードが復活してバトルを再開できるようになり、仲間の存在による恩恵をユーザがより明確に感じることができる。
　（８－５）変形例５
　上述した実施形態において、選択手段５４の選択条件を満たす仲間の数が所定数に満たない場合であっても、プレイ中のユーザが例えば体力ポイントなどの所定のポイントを一定量消費することで、選択条件を満たさない仲間からの支援を受けることが出来るように設定してもよい。例えば、最大で５名の仲間からの支援を受けることができる場合に、選択条件を満たす仲間が３人である場合には、残りの２人を選択条件を満たさない仲間の中から一定量の体力ポイントの消費と引き換えに選択できるように構成してもよい。
　このとき、プレイ中のユーザ（第１のユーザ）を支援する仲間（第２のユーザ）が複数存在する場合に、進行再開手段５７は、モンスターキャラクタとのバトルを再開するときには、再開前に支援していた複数の仲間のうち一部の仲間のみが再開後のバトルに関与するようにしてもよい。つまり、モンスターキャラクタとのバトルを再開する前後で、バトルに関与する仲間のユーザが異なる場合があってもよい。例えば、復活条件を満たしたときに復活する戦士カードを、選択条件を満たした仲間の戦士カードに限定してもよい。選択条件を満たした仲間の戦士カードのみがバトル再開後に関与する構成とすることで、選択条件を満たした仲間が多いほど復活する戦士カードが多くなり、バトル再開後に勝利する可能性を高くすることができる。
　（８－６）変形例６
　上述した実施形態において、進行停止手段５６に関連して、ユーザがバトルにおける所定の基準を満たさないと判断した場合に、例えばユーザによる攻撃指示操作ができないようにすることで、ユーザによる対戦ゲームの進行を停止させる場合について説明したが、この場合に限られない。対戦ゲームの進行の停止は、様々な態様があるいは程度で設定してもよい。例えば、対戦ゲーム自体を停止する（つまり、ユーザ及びモンスターキャラクタのいずれの攻撃も停止する）場合、対戦ゲームにおいてユーザの戦士カードの攻撃が停止する（つまり、モンスターキャラクタによる攻撃は停止しない）場合、対戦ゲームにおいて、ユーザの操作による戦士カードの攻撃が停止する場合（つまり、モンスターキャラクによる攻撃や、ユーザ操作によらない戦士カードの攻撃は停止しない場合）、のいずれかであってもよい。
　上述した実施形態において、進行再開手段５７に関連して、所定の復活条件を満たすと判断したときに、それまでのモンスターキャラクタとのバトルによって倒されたユーザの戦士カード、及び仲間の戦士カードを復活させ、ユーザによる攻撃指示操作を受け入れ可能とする場合について説明したが、この場合に限られない。対戦ゲームの再開は、様々な態様あるいは程度で設定してもよい。例えば、対戦ゲーム自体を停止前と同様に実行する場合、ユーザの戦士カードの攻撃が停止させられていたときにその攻撃が再開する場合、ユーザの操作による戦士カードの攻撃が停止させられていたときにユーザ操作による戦士カードの攻撃が再開する場合、のいずれかであってもよい。
　なお、対戦ゲームの停止前とその対戦ゲームの再開後とで、対戦ゲームの処理、あるいはパラメータ等の設定等が異なっていてもよい。
　以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。
　上記実施形態及び各変形例に記載された技術的事項は適宜組合せて適用してもよい。例えば、実施形態において例示した進行再開手段５７の復活条件は、プレイ中のユーザが仲間の支援を受けており、かつモンスターキャラクタのＨＰが所定値以下であるという条件であるが、この条件と変形例３と変形例４の各々を個別に組合せて復活条件を設定してもよい。
　上述した実施形態及び各変形例で述べた復活条件を満たしたときに、実際にバトル処理が再開される場合を所定の確率に基づいて実現してもよい。これによって、例えばゲームの再開が安易に行われないように、ゲーム設定を調整することができる。
　上述した実施形態及び各変形例で述べた復活条件は、バトルの処理の再開後にプレイ中のユーザがより勝利しやすいように付加的な条件を追加してもよい。例えば、図１６に示すフローチャートでは、ゲームの進行が再開してステップＳ１６０からステップＳ１２０に戻ったときには、ユーザの手持ちの戦士カードの攻撃力や守備力のパラメータの値を一定比率だけ再開前よりも増加させてもよい。
　上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、各ユーザによるゲームの進行を制御できることは言うまでもない。
　上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、ゲーム進行手段５２、記憶手段５３、選択手段５４、対戦実行手段５５、進行停止手段５６、進行再開手段５７、設定手段５８の各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。なお、上述した実施形態では、ユーザデータ（ユーザ情報）とモンスターキャラクタデータ（キャラクタ情報）を、記憶装置としてのデータベースサーバ３０（ゲームデータベース３２）が記憶している構成としたが、記憶装置を通信端末１０内に設けてもよい。その場合には、記憶装置は、通信端末１０内のＲＡＭ１３や図示しないＨＤＤ(Hard Disk Drive)などの大容量記憶装置であってよい。
　一例として、記憶装置をデータベースサーバ３０とし、実質的な処理を通信端末１０内で行う場合、通信端末１０は、バトルの処理に先立ってゲームサーバ２０あるいはデータベースサーバ３０から、通信端末１０のユーザのユーザデータ（第１のユーザ情報）と、当該ユーザの仲間のユーザデータ（第２のユーザ情報）と、モンスターキャラクタデータ（キャラクタ情報）とを受信してバトルの処理を行う。ゲーム終了時には、通信端末１０は、バトルの結果等のゲームの結果についてのデータをゲームサーバ２０へ送信し、ゲームサーバ２０は、受信したゲームの結果のデータをユーザと関連付けてゲームデータベース３２に記録するようにしてもよい。図１９Ａ，図１９Ｂには、本実施形態のゲーム制御装置の各機能（図１３に示す各機能）について、通信端末１０と、ゲームサーバ２０及びデータベースサーバ３０との間の機能を分担した場合の例を示す。
　上述した実施形態では、ユーザによる通信端末に対する所定の操作入力は、ユーザの通信端末に対する所定の操作釦の押下操作の入力や、タッチパネル機能を備えた通信端末に対する表示画面上のタッチ操作の入力であるとしたが、操作入力はこれに限られない。操作入力は、加速度センサを備えた通信端末を振ることによる操作入力、あるいはジェスチャによる操作入力（ジェスチャ入力）であってもよい。ジェスチャ入力では、撮像機能を備えた通信端末に対する所定のジェスチャを行うことで通信端末がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラムを実行可能な通信端末の場合には、操作入力は、音声を入力することにより行われてもよい。
　上述した実施形態では、ゲームがネットワーク上のサーバを介して実現される場合について説明したが、この場合に限られない。サーバを用いずに直接ユーザ端末間で行われる通信方式、例えばＰ２Ｐ(Peer to Peer)や無線アドホックネットワークによる通信を利用して、実施形態のゲームを実現してもよい。

Claims (12)

  1. 　第１のユーザのユーザ情報と、第１のユーザと関係付けられた第２のユーザのユーザ情報と、ゲームキャラクタのゲームキャラクタ情報とを記憶する記憶装置から、各情報を取得し、前記第１のユーザと前記ゲームキャラクタとの対戦を、前記第１のユーザのユーザ情報と、前記第２のユーザのユーザ情報と、前記ゲームキャラクタ情報とに基づいて実行する対戦実行手段と、
    　前記対戦の対戦結果が所定の基準を満たない場合に、第１のユーザによるゲームの進行を停止させる進行停止手段と、
    　ゲーム上の所定条件を満たす場合に、前記進行停止手段によって停止させられた第１のユーザによるゲームの進行を再開させる進行再開手段と、
    　を備えた、ゲーム制御装置。
  2. 　前記第１のユーザと関係付けられたユーザの中から、第１のユーザと前記ゲームキャラクタとの対戦の時点でログインしているユーザ、あるいはログインしてから前記時点までの経過時間が所定時間以内であるユーザを、前記第２のユーザとして選択する選択手段を備えたことを特徴とする、
    　請求項１に記載されたゲーム制御装置。
  3. 　前記第１のユーザと、第１のユーザと関係付けられたユーザとの間の関係度合いを示す親密度を設定する設定手段と、
    　前記第１のユーザと関係付けられたユーザの中から、第１のユーザとの間の親密度が所定の閾値よりも高いユーザを、前記第２のユーザとして選択する選択手段と、を備えたことを特徴とする、
    　請求項１に記載されたゲーム制御装置。
  4. 　前記ユーザ情報は、前記対戦において前記ゲームキャラクタに対する攻撃力を示す第１指標値を含み、
    　前記キャラクタ情報は、攻撃に対する耐力を示す指標値であって、前記攻撃力に応じて低下する第２指標値を含み、
    　前記進行再開手段は、前記所定条件を満たすか否かについて、前記進行停止手段によってゲームの進行が停止させられたときの前記ゲームキャラクタの第２指標値が所定値以下であるか否かに基づいて決定することを特徴とする、
    　請求項１～３のいずれかに記載されたゲーム制御装置。
  5. 　前記ユーザ情報は、前記対戦において前記ゲームキャラクタに対する攻撃力を示す第１指標値を含み、
    　前記キャラクタ情報は、攻撃に対する耐力を示す指標値であって、前記攻撃力に応じて低下する第２指標値を含み、
    　前記進行再開手段は、前記所定条件を満たすか否かについて、前記進行停止手段によってゲームの進行が停止させられたときの前記ゲームキャラクタの第２指標値と、前記第１のユーザ及び前記第２のユーザの第１指標値の総和との比較結果に基づいて決定することを特徴とする、
    　請求項１～３のいずれかに記載されたゲーム制御装置。
  6. 　前記進行再開手段は、前記所定条件を満たすか否かについて、前記第１のユーザと関係付けられ、かつ前記ゲームに参加しているユーザの数が所定数以上であるか否かに基づいて決定することを特徴とする、
    　請求項１～３のいずれかに記載されたゲーム制御装置。
  7. 　前記進行再開手段は、第１のユーザが前記ゲームキャラクタとの対戦に勝利するように、前記第１のユーザによるゲームの進行を再開させることを特徴とする、
    　請求項１～６のいずれかに記載されたゲーム制御装置。
  8. 　前記ユーザ情報は、前記対戦において前記ゲームキャラクタに対する攻撃力を示す第１指標値を含み、
    　前記キャラクタ情報は、攻撃に対する耐力を示す指標値であって、前記攻撃力に応じて低下する第２指標値を含み、
    　前記進行再開手段は、前記進行停止手段によって停止させられた時点の前記ゲームキャラクタの第２指標値に基づいて、前記第１のユーザと前記ゲームキャラクタとの対戦を実行することを特徴とする、
    　請求項１～６のいずれかに記載されたゲーム制御装置。
  9. 　第１のユーザのユーザ情報と、第１のユーザと関係付けられた第２のユーザのユーザ情報と、ゲームキャラクタのゲームキャラクタ情報とを記憶する記憶装置から、各情報を取得し、前記第１のユーザと前記ゲームキャラクタとの対戦を、前記第１のユーザのユーザ情報と、前記第２のユーザのユーザ情報と、前記ゲームキャラクタ情報とに基づいて実行するステップと、
    　前記対戦の対戦結果が所定の基準を満たない場合に、第１のユーザによるゲームの進行を停止させるステップと、
    　ゲーム上の所定条件を満たす場合に、前記停止させるステップによって停止させられた第１のユーザによるゲームの進行を再開させるステップと、
    　を備えた、ゲーム制御方法。
  10. 　コンピュータに、
    　第１のユーザのユーザ情報と、第１のユーザと関係付けられた第２のユーザのユーザ情報と、ゲームキャラクタのゲームキャラクタ情報とを記憶する記憶装置から、各情報を取得し、前記第１のユーザと前記ゲームキャラクタとの対戦を、前記第１のユーザのユーザ情報と、前記第２のユーザのユーザ情報と、前記ゲームキャラクタ情報とに基づいて実行する機能、
    　前記対戦の対戦結果が所定の基準を満たない場合に、第１のユーザによるゲームの進行を停止させる機能、及び
    　ゲーム上の所定条件を満たす場合に、前記停止させる機能によって停止させられた第１のユーザによるゲームの進行を再開させる機能、
    　を実現させるためのゲーム制御プログラム。
  11. 　請求項１０に記載されたプログラムを記録したことを特徴とする、コンピュータ読み取り可能な記録媒体。
  12. 　通信端末と、当該通信端末とネットワークを介して接続され、前記通信端末によるゲームの進行を制御するサーバと、を備えたゲームシステムであって、
    　第１のユーザのユーザ情報と、第１のユーザと関係付けられた第２のユーザのユーザ情報と、ゲームキャラクタのゲームキャラクタ情報とを記憶する記憶装置から、各情報を取得し、前記第１のユーザと前記ゲームキャラクタとの対戦を、前記第１のユーザのユーザ情報と、前記第２のユーザのユーザ情報と、前記ゲームキャラクタ情報とに基づいて実行する対戦実行手段、
    　前記対戦の対戦結果が所定の基準を満たない場合に、第１のユーザによるゲームの進行を停止させる進行停止手段、及び、
    　ゲーム上の所定条件を満たす場合に、前記進行停止手段によって停止させられた第１のユーザによるゲームの進行を再開させる進行再開手段、
    　の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
    　ゲームシステム。
PCT/JP2012/007439 2012-02-22 2012-11-20 ゲーム制御装置、ゲーム制御方法、ゲーム制御プログラム、記録媒体、ゲームシステム WO2013124932A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2012-036767 2012-02-22
JP2012036767 2012-02-22

Publications (1)

Publication Number Publication Date
WO2013124932A1 true WO2013124932A1 (ja) 2013-08-29

Family

ID=49005156

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/007439 WO2013124932A1 (ja) 2012-02-22 2012-11-20 ゲーム制御装置、ゲーム制御方法、ゲーム制御プログラム、記録媒体、ゲームシステム

Country Status (1)

Country Link
WO (1) WO2013124932A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015198857A (ja) * 2014-04-10 2015-11-12 株式会社ｇｌｏｏｐｓ ゲームサーバ、ゲーム制御方法、ゲームプログラム、ゲームプログラム記録媒体及びゲームシステム
JP2017113427A (ja) * 2015-12-25 2017-06-29 株式会社バンダイナムコエンターテインメント プログラム及びサーバ

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
"Dragon Collection", DENGEKI GAME APURI, vol. 1, 14 December 2011 (2011-12-14), pages 6, 11 *
"Final Fantasy -Zeroshiki", WEEKLY FAMITSU, vol. 26, no. 48, 10 November 2011 (2011-11-10), pages 123 *
"The Legend of Heros: Ao no Kiseki", DENGEKI PLAYSTATION, vol. 17, no. 34, 24 November 2011 (2011-11-24), pages 156 *
KAIZOKU OKOKU COLUMBUS, FAMITSU GREE, vol. 1, 15 September 2011 (2011-09-15), pages 24 - 25 *
SHIN'ICHI ANDO ET AL., DEVIL SURVIVOR 2 KOSHIKI PERFECT GUIDE, 8 September 2011 (2011-09-08), pages 292 *
YUGEN KAISHA CHOPPU, WILD ARMS THE VTH VANGUARD COMPLETE GUIDE, 30 March 2007 (2007-03-30), pages 72 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015198857A (ja) * 2014-04-10 2015-11-12 株式会社ｇｌｏｏｐｓ ゲームサーバ、ゲーム制御方法、ゲームプログラム、ゲームプログラム記録媒体及びゲームシステム
JP2017113427A (ja) * 2015-12-25 2017-06-29 株式会社バンダイナムコエンターテインメント プログラム及びサーバ

Similar Documents

Publication Publication Date Title
JP5646537B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5436612B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5265789B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲーム制御システム
JP5551210B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP6090935B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5442810B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5789233B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5715266B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5260783B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
WO2013154020A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲーム制御システム
JP2014133149A (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5562400B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5731710B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5499068B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5847037B2 (ja) ゲーム制御装置、ゲーム制御方法、ゲームシステム
JP5628851B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
WO2013124932A1 (ja) ゲーム制御装置、ゲーム制御方法、ゲーム制御プログラム、記録媒体、ゲームシステム
JP6678867B2 (ja) サーバ、制御プログラム
JP5894109B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5529924B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、情報処理装置
JP6206772B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5845208B2 (ja) ゲーム制御装置、プログラム、ゲーム制御システム
JP6206764B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP6069612B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP2014208168A (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12869573

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12869573

Country of ref document: EP

Kind code of ref document: A1