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

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

Info

Publication number
WO2013161732A1
WO2013161732A1 PCT/JP2013/061724 JP2013061724W WO2013161732A1 WO 2013161732 A1 WO2013161732 A1 WO 2013161732A1 JP 2013061724 W JP2013061724 W JP 2013061724W WO 2013161732 A1 WO2013161732 A1 WO 2013161732A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
battle
game
information
communication terminal
Prior art date
Application number
PCT/JP2013/061724
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 WO2013161732A1 publication Critical patent/WO2013161732A1/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/45—Controlling the progress of the video game
    • 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/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • 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/48—Starting a game, e.g. activating a game device or waiting for other players to join a multiplayer session
    • 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/55—Controlling game characters or game objects based on the game progress
    • A63F13/58—Controlling game characters or game objects based on the game progress by computing conditions of game characters, e.g. stamina, strength, motivation or energy level
    • 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/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A63F13/795—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for finding other players; for building a team; for providing a buddy list
    • 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/847—Cooperative playing, e.g. requiring coordinated actions from several players to achieve a common goal
    • 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/46—Computing the game score
    • 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/90—Constructional details or arrangements of video game devices not provided for in groups A63F13/20 or A63F13/25, e.g. housing, wiring, connections or cabinets
    • A63F13/92—Video game devices specially adapted to be hand-held while playing
    • 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/50—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 characterized by details of game servers
    • A63F2300/55—Details of game data or player data management
    • A63F2300/5546—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
    • A63F2300/5566—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history by matching opponents or finding partners to build a team, e.g. by skill level, geographical area, background, play style

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.
  • Non-Patent Document 1 a digital card game (Dragon Collection (registered trademark)) disclosed in Non-Patent Document 1 is known.
  • this known digital card game a menu for performing a quest process in which a user searches various areas and acquires a new card or item is provided.
  • One of the features of such a social game is that it has a richer communication function for interacting with users than a 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.
  • An object of the present invention is to provide a game control device, a game control method, a program, a recording medium, and a game system.
  • a first aspect of the present invention is a game control device.
  • the game control device A battle execution means for performing a battle on the game by the user; Storage means for storing information about the first user in a storage device when the first user does not satisfy the victory condition in the first battle by the first user; Information about the first user during a second battle, which is a battle by the second user and a battle with the opponent of the first user in the first battle, when a predetermined condition is satisfied Information providing means for obtaining the information from the storage device and providing it to the second user; Adjusting means for adjusting settings on the game so that the second user is advantageous in the second battle when information about the first user is provided; Is provided.
  • the “information about the first user” may be anything as long as it is information that can identify the first user, for example, a user name or an avatar image on the game of the first user, for example. It may be a character, an item, etc. which a 1st user holds on a game. Further, the “information about the first user” may be, for example, text data, image data, audio data, or the like.
  • the “predetermined condition” may be, for example, that the second user has conquered (cleared) a predetermined number of areas, or the second user has a predetermined number of other users or characters. You may have won the match. Further, for example, the second user may have acquired a predetermined number of items, or the progress of the second user's game may have reached a predetermined value or more.
  • the second user can obtain information on the first user during the second battle when a predetermined condition is satisfied. Moreover, when the information regarding the first user is provided, the settings on the game are adjusted so that the second user is advantageous in the second battle. For this reason, the 2nd user cooperates with the 1st user who had already faced the same opponent by the time of carrying out his own battle (that is, did not get a victory from the opponent), and played a battle. You can get a sense of being.
  • the predetermined condition may be that the second user plays the second battle in response to the application of the first user based on the result of the first battle. Good.
  • the first user Information about the user is provided to the second user.
  • the second user can not only realize that he / she is fighting in cooperation with the first user, but also can play a battle while obtaining a sense of mission to respond to an application from the first user. it can. For this reason, for the second user, it is possible to enhance the sense of accomplishment obtained when a victory is obtained from the opponent.
  • the game control apparatus may further include an association unit that associates users, and the predetermined condition may be that the second user is associated with the first user.
  • the second user is provided with information about the first user (companion) associated with himself / herself during the second battle, so that he / she feels that he / she is fighting in cooperation with the fellow. Obtainable. For this reason, the relationship with a friend can be improved and the social property of a game can be improved by extension.
  • the predetermined condition may be that the second battle is performed within a predetermined period after the first battle.
  • the first user plays the second battle at substantially the same time after the first battle by the first user, the first user during the second battle Information about the user is provided to the second user. For this reason, the 2nd user can actually feel that he is fighting in cooperation with the 1st user.
  • the first battle was performed almost at the same time as the second battle (that is, for the same opponent) By playing at almost the same time, it is possible to create a sense of familiarity with the first user. Thereby, the exchange between users can be accelerated
  • the information providing means is configured such that when there are a plurality of the first users, the time when the first battle is performed among the plurality of first users is the time of the second battle.
  • Information about a predetermined number of users may be provided to the second user in the order from the first to the second.
  • the second user can obtain information regarding the predetermined number of first users who have played the first battle at a time close to the time of the second battle during the second battle.
  • the 2nd user is the 1st user because the 1st battle was performed at the same time as the 2nd battle (that is, the same opponent was played at the same time). You can feel that you are fighting in cooperation with.
  • the second user may be familiar with the predetermined number of first users, when the first user and the second user are related as friends, the second user and the predetermined number Exchange with the first user can be promoted, and the social nature of the game can be further enhanced.
  • the game control apparatus includes an association unit that associates users with each other, and the information providing unit includes the second user among the plurality of first users when there are a plurality of the first users.
  • Information related to a predetermined number of users may be provided to the second user in descending order of the closeness indicating the degree of relation with the second user.
  • a 2nd user is a user (companion) related with the 2nd user among a plurality of 1st users, Comprising: It is related with the predetermined number of associates with high intimacy with the 2nd user. Information can be obtained during the second match. For this reason, since the 2nd user can acquire the actual feeling that he is fighting in cooperation with a close friend, he can motivate to raise the degree of relation with the close friend. . Thereby, a close relationship between users can be established.
  • a second aspect of the present invention is a game control method.
  • the game control method is as follows: Performing a game battle by a user; Storing the information about the first user in a storage device when the first user does not satisfy the victory condition in the first battle by the first user; Information about the first user during a second battle, which is a battle by the second user and a battle with the opponent of the first user in the first battle, when a predetermined condition is satisfied Obtaining from the storage device and providing to the second user; Adjusting the settings on the game so that the second user has an advantage in the second battle when information about the first user is provided; Is provided.
  • a third aspect of the present invention relates to a computer.
  • a function for performing a game battle by a user A function of storing information about the first user in a storage device when the first user does not satisfy the victory condition in the first battle by the first user; Information about the first user during a second battle, which is a battle by the second user and a battle with the opponent of the first user in the first battle, when a predetermined condition is satisfied
  • the second user is advantageous in the second battle.
  • 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 accessed from the communication terminal, A battle execution means for performing a battle on the game by the user; Storage means for storing information about the first user in a storage device when the first user does not satisfy the victory condition in the first battle by the first user; Information about the first user during a second battle, which is a battle by the second user and a battle with the opponent of the first user in the first battle, when a predetermined condition is satisfied Providing information from the storage device and providing it to the second user, Adjusting means for adjusting settings on the game so that the second user is advantageous in the second battle when information about the first user is provided; Any one of the communication terminal and the server is provided with each means.
  • the communication terminal may be, for example, a mobile terminal, a smartphone, a PDA (Personal Digital Assistant), a personal computer, a television receiver having a bidirectional communication function, a game device with a communication function, or the like.
  • a mobile terminal a smartphone, a PDA (Personal Digital Assistant), a personal computer, a television receiver having a bidirectional communication function, a game device with a communication function, or the like.
  • the figure which shows the basic composition of the game system of embodiment The figure which shows an example of the external appearance of the communication terminal of embodiment.
  • the figure which shows the other 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 block diagram which shows the structure of the database server of embodiment The figure which shows the structural example of the user database contained in a database server.
  • the figure which shows the data structural example of an application list The figure which shows an example of the display screen of the communication terminal which displays a top page.
  • 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 sequence chart which shows an example of the main processes of the game control apparatus of embodiment.
  • the figure which shows the data structural example of familiarity data The figure which shows the example of 1 structure of each function in each of a communication terminal and a game server. The figure which shows the other structural example of each function in each of a communication terminal and a
  • the present invention relates to a patent application of Japanese Patent Application No. 2012-099714 filed with the Japan Patent Office on April 25, 2012, the contents of which are incorporated herein 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 in a wired or wireless manner for reading and writing the information. Note that the game server 20 and the database server 30 may be connected via a communication network NW.
  • the communication terminal 10 includes a web browser capable of displaying a web page provided by the game server 20, and the user executes a game by operating the web page on the communication terminal 10.
  • 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 illustrating an example of the appearance of the communication terminal 10.
  • FIG. 2A illustrates a button input type communication terminal such as a foldable mobile terminal (mobile phone).
  • FIG. 2B illustrates a communication terminal of a touch panel input method 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 is provided, and a bus 18 for transmitting control signals or data signals 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
  • 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 plurality of instruction input buttons such as a direction instruction button and a decision button for accepting a user operation input.
  • a button group 15b including a group 15a and a plurality of instruction input buttons such as a numeric keypad is provided, and an interface circuit for recognizing a pressing (operation) input of each button and outputting it to the CPU 11 is included.
  • 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.
  • the CPU 21 performs processing according to the hyperlink or menu selected by the user on the web page displayed on the communication terminal 10.
  • 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 system according to the present embodiment is not particularly limited, but in the following, as an example of the game according to the present embodiment, the user performs a game on the game in accordance with the user's operation on the communication terminal 10.
  • the battle-type digital card game (hereinafter referred to as “game of the present embodiment” as appropriate) that battles with a monster character, which is a monster on the game, is used.
  • game of the present embodiment As will be described later, in the game of the present embodiment, if a user loses a battle with a monster character (does not satisfy the victory condition), a support request can be made, and other users who have accepted the support request It is configured to be able to support the battle of the support requesting user.
  • FIG. 6 shows an example of a user database 31 applied in the game of the present embodiment.
  • the user database 31 stores, for each user ID (user identification information), information on each item of user name / display image, skill level, number of warriors, number of wins, fellow user ID, and possessed card data. Including. 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.
  • 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.
  • -Number of warriors This is the number of warrior cards held by the user. The maximum number of warriors (for example, 60) is defined in advance.
  • -Number of wins The number of wins in battles with monster characters.
  • ⁇ Friend's user ID This is user ID data of another user associated with the target user ID. The fellow user ID is related to Modification 1 described later.
  • -Data of possession card The possession card data is data of the warrior card possessed by the user, and includes parameters such as an image and attack power for each warrior card as shown in FIG. When a warrior card battles with a monster character, damage according to the value of the attack power can be given to the monster character.
  • the game database 32 stores information on the progress of the game executed by the game server 20, monster character data (monster character data), an application list, and the like 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 related to the progress of the game may include detailed results of battles with the monster characters of each user.
  • the monster character data includes data of a monster character that is the opponent of the battle.
  • the monster character data is data that is loaded from the game database 32 to, for example, the RAM 23 and stored together with the execution of the battle process.
  • the image displayed on the web page is associated with the HP (HitHPoint) value indicating the physical strength of the monster character.
  • the HP of each monster character is in the range of 1500 to 2000, but the HP value may be set randomly when performing a battle from this range.
  • the condition for requesting support for the battle is not limited to the condition that the user has lost the battle with the monster character. It may be possible to request support unconditionally at the start of the battle, or to request support only when a predetermined condition in the battle is satisfied.
  • the “predetermined condition in the battle” may be, for example, a predetermined condition for a parameter (or an ability level) such as a warrior card used by the user in battle and an attack power of a battle opponent's monster character. For example, it may be a condition that a difference in attack power between a warrior card and a monster character has a certain value.
  • the application list is a list in which support requests made by users are sequentially written. The application list is not essential data for the present invention, but is data for making the present invention more preferable. Of the support requests in the application list, those that have defeated the monster character due to the execution of the support are deleted from the list.
  • FIG. 8 is a diagram illustrating a data configuration example of the application list. In the application list illustrated in FIG.
  • the remaining HP of the monster character is not set to zero (that is, if the monster character cannot be destroyed) before the predetermined time elapses from the application user's battle date, it is determined that the monster character could not be defeated, and the application The support request corresponding to the user's battle date may be deleted from the list.
  • FIG. 9 is a diagram illustrating an example of a top page displayed on the communication terminal 10 in the game of the present embodiment.
  • 10 to 15 are diagrams illustrating examples of web pages displayed on the communication terminal 10 when the battle process is executed.
  • a case where the user who first executes the battle process is “ABC” (hereinafter referred to as user: ABC) will be described as an example.
  • 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 top page of the game of this embodiment illustrated in FIG. 9 is configured by a web page corresponding to each user ID.
  • the example of FIG. 9 includes a user data display area, a warrior image display area, and a menu display area.
  • the user data display area is an area in which data of each item of skill level, the number of warriors, and the number of wins included in the user data of the target user ID (see FIG. 6) is displayed.
  • “40/60” is described as an example of the number of warriors, but this is 40 warrior cards held by the user, and the maximum number of warrior cards that can be held is 60.
  • 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 an area where a plurality of menus (not shown except for the menu m1) including a menu m1 for starting execution of the battle process in the game of the present embodiment are displayed.
  • the web page is updated as shown in step S1 of FIG.
  • a menu m11 labeled “battle start” and the like are displayed on the web page in step S1.
  • the web page is updated as shown in step S2 in FIG.
  • a predetermined number (10 in the example shown) of warrior cards 202 held by the user: ABC is displayed.
  • a menu m12 labeled “attack” is displayed.
  • the warrior card 202 may be determined at random from among warrior cards held by the user: ABC or in advance by selection of the user: ABC.
  • the web page is updated as shown in step S3 of FIG. 11, and the user: ABC performs a battle on the game with the monster character MC.
  • 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 m12.
  • the amount of HP that decreases each time the menu m12 is selected and operated may be determined according to the attack power of the warrior card.
  • the monster character MC attacks the 10 warrior cards in order.
  • the cards are displayed in a collapsed form. Is done.
  • the web page is updated as shown in step S4 of FIG.
  • the HP of the monster character MC is not zero and all 10 warrior cards of the user: ABC are defeated (defeated)
  • the user: ABC is defeated in the battle (Victory condition)
  • the web page is updated as shown in step S5 of FIG. If the battle is defeated, the monster character MC does not disappear, and the HP remaining after the battle is maintained.
  • a menu m13 written as “request support” for requesting support from another user is displayed on the web page in step S5.
  • the user: ABC is registered in the application list as an application user.
  • menu m13 is selected, a battle with another monster character may be performed. In this case, it is updated to the web page in step S1 on which images of other monster characters are displayed.
  • step S5 when the user: ABC selects and operates the menu m13 on the web page in step S5, a message for confirming whether or not to receive a support request from another user is displayed.
  • a web page for other user XYZ is shown in step S6 of FIG.
  • a menu m14 described as “participating in war” and a menu m15 described as “not participating in war” are displayed.
  • the menu m14 (“participate") is selected on the web page in step S6
  • the web page is updated as shown in step S7 in FIG.
  • the screen transitions to a screen for performing a battle with the monster character MC that is the battle opponent of the user: ABC.
  • the web page of step S7 has the same format as the web page of step S2 of FIG. 10, for example, but the HP value of the monster character MC is the HP at the time when the user: ABC is defeated (that is, the web page of step S5).
  • the image of the warrior card specified by the user: ABC in advance (for example, the warrior card displayed in the warrior image display area on the top page of the user: ABC).
  • the image) SC moves across the game screen instantaneously, and then updated to the web page shown in step S9 of FIG.
  • the web page in step S9 has the same format as the web page in step S3 in FIG. 11, for example, but includes a message indicating that user: ABC has entered the battle of user: XYZ.
  • the attack power of the warrior card 203 used by the user: XYZ in the battle increases.
  • user: XYZ can acquire the real feeling that it is performing a battle in cooperation with user: ABC who is an application user.
  • the web page is updated as shown in step S10 of FIG.
  • the HP of the monster character MC is not zero and all 10 warrior cards of the user: XYZ are defeated (defeated)
  • the web page is updated as shown in step S5 of FIG. If the battle is defeated, the monster character MC does not disappear, and the HP remaining after the battle is maintained.
  • the user XYZ who is a support user loses the battle, the user XYZ cannot make a support request targeting the monster character MC that was the opponent of the battle for the battle. Also good.
  • the support user may be able to make a support request, but in this case, the game balance may be biased and the processing may be complicated. For this reason, it is preferable that a support user cannot make a support request.
  • the application user does not change as the user: ABC, and the new support user accepts the support request from the user: ABC and performs a battle.
  • FIG. 16 is a functional block diagram for explaining functions that play a main role in the game control apparatus of the present embodiment.
  • the battle execution means 52, the storage means 53, the information providing means 54, and the adjustment means 55 correspond to the main configuration of the present invention.
  • Other means are not necessarily indispensable structures, but they are structures for making the present invention more preferable.
  • the registration unit 51 has a function of recognizing 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 performing a registration process (user registration). This registration process is executed when the user performs user registration for the game of the present embodiment.
  • the registration means 51 is not an essential component of the present invention, but is a component for making the present invention more preferable.
  • the function of the registration means 51 is implement
  • 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 on the communication terminal 10 on the web page provided from the game server 20 (for example, a predetermined menu selection operation or a text input such as a user ID or password specified by the user). Web pages may be configured to be generated automatically.
  • the registration request message may include information for identifying the communication terminal 10 as the transmission source (for example, individual identification information of a terminal such as a UID (Unique Identifier), an IP address, a mail address, etc.), or If the user has already used another game by the same service provider, the user ID may be included.
  • UID Unique Identifier
  • the CPU 21 When 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 user can execute the game of the present embodiment.
  • the battle execution means 52 has a function of executing a battle (match) on the game by the user.
  • the battle opponent the opponent
  • the opponent may be another user, for example, A team consisting of a plurality or a single warrior card possessed by the user may be used, or a team consisting of a plurality or a single warrior card arbitrarily extracted by the CPU 21 may be used.
  • the function of the battle execution means 52 may execute a battle on the game by, for example, sequentially updating a web page displayed on the communication terminal 10 in response to a request from the communication terminal 10.
  • the CPU 21 of the game server 20 receives an HTTP request from the communication terminal 10, performs a predetermined process on the game in accordance with the HTTP request, and executes the game.
  • An HTTP response including the resulting HTML data is returned to the communication terminal 10.
  • the CPU 21 of the game server 20 responds to the HTTP request. Then, an HTTP response including HTML data for displaying the web page shown in step S1 of FIG. 10 is transmitted to the communication terminal 10.
  • the CPU 21 reads out the monster character that is the battle opponent of the user who is executing the game from the monster character data and stores it in the RAM 23, and generates HTML data based on the read data. .
  • the CPU 21 receives the number of wins from that user. If there is a user whose number of wins is smaller than that of the user who transmitted the HTTP request by searching the request list to determine whether there is a request for assistance, the communication of the user who transmitted the HTTP request is requested. You may transmit to the terminal 10. Note that the condition “whether there is a support request from a user who has fewer wins than that user” is not an essential condition, and the determination process for this condition may not be performed. In this case, for example, the web page shown in step S6 is displayed on the communication terminal 10 of the user who has transmitted the HTTP request.
  • the CPU 21 of the game server 20 acquires a selection result of a predetermined number of warrior cards used in the battle among warrior cards held by the user in accordance with an appropriate operation by the user.
  • the number of warrior cards participating in the battle is one.
  • the CPU 21 causes one of the monster characters in the monster character data stored in the game database 32 to appear for battle at the timing of defeating the monster character or at random timing.
  • the CPU 21 reads out the data of the monster character that is the user's battle opponent and newly writes it in the RAM 23. At this time, the initial HP value of the monster character data is randomly determined.
  • the HP of the monster character MC1 is set as a range of 1500 to 2000, but as an initial value of HP used when performing an actual battle process, a random value is selected from the range of 1500 to 2000. One value is determined.
  • CPU21 recognizes selection operation of menu m14 ("participate") from a support user, it will perform a battle process between the said support user and the monster character in the battle of assistance object. Specifically, the CPU 21 generates HTML data so that the support user can perform an attack operation on the monster character in the support target battle, and transmits the HTML data to the support user's communication terminal 10 (for example, FIG. 13 (see the web page in step S7).
  • the HP of the monster character to be a battle opponent starts a battle based on the value of the remaining HP written in the request list.
  • the CPU 21 writes the remaining HP value written in the request list into the RAM 23.
  • the CPU 21 recognizes the selection operation of the menu m14 from the support user, the CPU 21 sets the user ID of the support user corresponding to the user ID of the support user corresponding to the user ID of the support target application user in the application list ( (See FIG. 8).
  • the CPU21 reads the data of the warrior card used by a battle from user data, makes it memorize
  • the CPU 21 is used, for example, when the user attacks a monster character using a warrior card (for example, when the menu m12 (“attack”) is selected on the web page in step S2 of FIG. 10). Processing to reduce the HP of the monster character is performed according to the attack power value of the warrior card.
  • the operation on the menu m12 (“attack”) is referred to as “attack operation”.
  • the attack power of a warrior card is Pa and the coefficient determined at random is k
  • the calculation performed on the HP of the monster character by one attack operation is performed, for example, according to the following equation (1): You may be made to be.
  • the updated HP value is sequentially overwritten in the RAM 23 during the execution of the battle.
  • HP HP ⁇ Pa ⁇ k (1)
  • an attack is applied to the warrior card from the battle opponent's monster character with a constant or random attack power according to the attack operation.
  • the attack power of the monster character may be a value that is approximately proportional to HP, or may be a constant or random value.
  • the attack power applied from a monster character or the integrated value of the attack power exceeds the defense power of the warrior card. Become. When the user has only one warrior card used in the battle, when the warrior card is defeated, the user loses (does not satisfy the victory condition).
  • the warrior cards to be attacked by the monster character may be determined in a certain order or randomly.
  • the update of the monster character's HP by the attack operation is not limited to the above-described formula (1).
  • Pa in the above formula (1) may be a numerical value determined randomly according to the attack operation from a predetermined range, not the attack power of the warrior card.
  • the determination method of a battle win / loss can be set suitably. For example, if the HP of a monster character cannot be reduced to zero by a predetermined number of attack operations or by a predetermined time, it is determined that the monster character could not be defeated (the victory condition was not satisfied).
  • the CPU 21 determines that the monster character has been defeated (has won the monster character), and increases the number of wins in the user data by one.
  • the storage unit 53 stores information regarding the user in the game database 32 (storage device).
  • the function to memorize is provided.
  • the information related to the user may be any information as long as it can be identified as the user, for example, may be a user name or an avatar image on the user's game, or the user. May be characters or items held in the game.
  • the information regarding the user may be, for example, text data, image data, audio data, or the like.
  • storage means 53 is implement
  • the CPU 21 of the game server 20 recognizes that the user who is executing the game has performed an operation of selecting the menu m13 (“request for assistance”)
  • the CPU 21 writes the required data in the application list in the game database 32.
  • the data written in the application list includes, for example, the user ID of the user (applying user) who has selected and operated the menu m13, the image of the warrior card, the battle opponent (the monster character when the user is defeated in the battle) ), And the remaining HP of the monster character.
  • the selection operation of the menu m13 is not performed, when the user who is executing the game loses the battle, information regarding the user may be stored in the application list.
  • the information providing means 54 is a battle by the support user (second user) when the predetermined condition is satisfied, and the battle (first battle) of the user (first user) who did not satisfy the victory condition in the battle. ) Is provided with a function of acquiring information about the user from the game database 32 (storage device) and providing it to the support user during a battle (second battle) that is a battle with the user's opponent.
  • the “predetermined condition” may be, for example, that the supporting user has won (cleared) a predetermined number of areas, or the supporting user has won a battle against a predetermined number of other users or characters. It may be that.
  • the support user may have acquired a predetermined number of items, or the support user's game progress may have reached a predetermined value or more.
  • the user who did not satisfy the victory condition in the battle includes not only the application user but also the support user who did not win after performing the battle in response to the support request from the application user.
  • the predetermined condition is determined according to the support request (application) of the user based on the result of the battle (first battle) of the user (first user) who did not satisfy the victory condition in the battle (first user).
  • 2 users may perform a battle (second battle).
  • a support user performs a battle according to an application user's application based on the result of an application user's battle
  • information about an application user is provided to a support user during a support user's battle.
  • the support user can not only realize that he / she is fighting in cooperation with the application user, but also can perform a battle while obtaining a sense of mission to respond to the application from the application user. For this reason, it is possible for the support user to enhance the sense of achievement obtained when winning from the opponent.
  • the function of the information provision means 54 is implement
  • the CPU 21 of the game server 20 recognizes the selection operation of the menu m12 (“attack”) on the web page in step S7
  • the CPU 21 of the game server 20 acquires the image of the application user's warrior card corresponding to the support user from the application list, and then executes step S8.
  • HTML data is generated so as to be included in the web page, and transmitted to the communication terminal 10 of the support user.
  • the web page in step S8 is configured so that the warrior card image SC is displayed so as to cross the game screen instantaneously, but the warrior card image SC is always displayed on the game screen.
  • a web page may be configured.
  • the information regarding an application user may be a user name of an application user, for example, It may be a display image of the user.
  • the CPU 21 obtains the information from the storage area and provides the information. Also good.
  • the adjustment means 55 is advantageous to the support user (second user) in the battle (second battle) by the support user when information on the user (first user) who did not satisfy the victory condition in the battle is provided. It has a function to adjust the settings on the game to become.
  • the function of the adjustment means 55 is realizable as follows.
  • the CPU 21 of the game server 20 recognizes the selection operation of the menu m12 (“attack”) on the web page in step S7, the attack power of the warrior card used by the support user in the battle (second battle) by the support user
  • the setting on the game is adjusted so that the support user is advantageous by performing a process of increasing the attack power of the monster character of the battle opponent.
  • the increase in the attack power of the warrior card or the decrease in the attack power of the monster character may be an increase or decrease in a predetermined ratio, or an increase or decrease in a predetermined amount.
  • the setting on the game may be adjusted so that the support user is advantageous by reducing the HP of the monster character of the battle opponent by a predetermined ratio or a predetermined amount.
  • the support user may be adjusted based on the information on the application user so as to be advantageous.
  • the battle may be performed in a state where the attack power of the warrior card held by the application user is added to the attack power of the warrior card used by the support user.
  • the warrior card of the application user used in this case may be a warrior card used by the application user in a battle, or may be a warrior card displayed on the web page in step S8.
  • FIG. 17 shows a game battle process of the present embodiment, which is performed by the game control apparatus of the present embodiment.
  • the timing at which each web page described in FIGS. 13 to 15 is displayed is indicated by reference numerals.
  • user: ABC is an example of the first user
  • user: XYZ is an example of the second user.
  • step S5 of FIG. 12 a web page in step S5 of FIG. 12 is displayed.
  • the menu m13 (“request for support”) is selected and an HTTP request including a support request is received (step S100)
  • the CPU 21 of the game server 20 stores necessary data in the application list in the game database 32.
  • Write step S102.
  • the data to be written includes, for example, the user ID of the application user (here, user: ABC), the image of the warrior card, the battle opponent (monster character when the user is defeated in the battle), battle The remaining HP of the other party.
  • the CPU 21 recognizes the user who transmits the HTTP request for the top page of the game or the HTTP request based on the selection operation of the menu m1 (step S104). It is determined whether or not the user has more wins than user: ABC, and if so, a user: ABC support request may be transmitted to the user (step S106). That is, a support request may be made for a user who has a greater number of wins than the application user.
  • a user: ABC support request is transmitted to the communication terminal 10 of the user: XYZ.
  • the web page of step S6 in FIG. 13 is displayed on the communication terminal 10 of the user ABC that has received the support request.
  • step S108 When the menu m14 ("participate") is selected on the web page in step S6 and it is recognized that the support request has been accepted (step S108), the CPU 21 defeats the user ABC and the user KNM in the battle. HTML data for a battle screen with the character MC is generated and transmitted (step S110). As a result, for example, the web page in step S7 of FIG. 13 is displayed on the communication terminal 10 of the user: XYZ. At this time, the HP of the monster character MC in the battle of the user: XYZ is read and displayed by the data of the user: ABC in the application list.
  • step S112 the attack operation of the user ABC is performed (step S112), the CPU 21 determines whether or not a predetermined condition is satisfied (step S114).
  • the CPU 21 generates HTML data for displaying the web page shown in step S8 of FIG. 14, and the communication terminal 10 of the user: XYZ. It transmits to address (step S116).
  • the CPU 21 advantageously performs the process of increasing the attack power of the warrior card used by the support user or reducing the attack power of the monster character of the battle opponent in the battle by the support user.
  • the settings on the game are adjusted so as to be (step S118).
  • step S120 performs a battle process (step S120), produces
  • step S122 the processing in steps S114 to S122 may be repeated each time the attack operation in step S112 is performed.
  • step S124 in response to the transmission of the HTML data from the CPU 21 (step S124), for example, the web page of step S10 in FIG. 15 is sent to the communication terminal 10 of the user: XYZ. Is displayed.
  • step S124 when the user: XYZ is defeated by the monster character MC, in response to the transmission of the HTML data from the CPU 21 (step S124), for example, the web page of step S11 in FIG. 15 is displayed on the communication terminal 10 of the user: XYZ. Is done.
  • the CPU 21 updates the application list and user data (step S12). For example, when the user: XYZ defeats the monster character MC, the corresponding data (the user: the monster character MC as an ABC opponent) is deleted from the application list, and the user data of the user: ABC and the user: XYZ is accessed. Then, increase the number of wins by 1, respectively.
  • the support user can obtain information on the user who did not satisfy the victory condition in the battle when the predetermined condition is satisfied. Moreover, if the information regarding the user who did not satisfy the victory condition in the battle is provided, the setting on the game is adjusted so that the support user is advantageous in the battle by the support user. For this reason, the feeling that the supporting user is performing a battle in cooperation with another user who has already played against the same opponent by the time of his / her battle (that is, has not been able to obtain victory from the opponent). Can be obtained.
  • FIG. 18 is a functional block diagram for explaining functions that play a major role in the game control device of the present modification.
  • the functional block diagram of FIG. 18 differs from that of FIG. 16 in that an association means 56 is added.
  • the associating means 56 has a function of associating users with each other.
  • the associating unit 56 has a function of associating the user ID with another user ID when triggered by an application based on the user ID.
  • the function of the correlation means 56 is implement
  • 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.
  • the CPU 21 writes the data in the location (see FIG. 6) of “friend user ID” 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 requiring application and approval as described above, and users who execute stages on the same game may be registered as friends.
  • users who transmit a predetermined number of greeting messages may be automatically registered as friends, and if there is a mode on the game in which a battle is performed between users, the user who has performed the battle a predetermined number of times or more You may automatically register each other as a friend.
  • the users in the group may be associated with each other by associating each user with the same group (guild or the like).
  • the user A can apply for the specific user B in the user associated with the predetermined group and obtain the approval of the specific user B, the predetermined group and Associate user A.
  • the users may be related to each other.
  • achieves by registering data in the user database 31 by registering the friendship relationship between users was shown, it is not restricted to this example.
  • the data regarding the friendship may be written in an external storage device on the network accessible from the game server 20.
  • the predetermined condition may be that the support user (second user) is associated with a user (first user) who does not satisfy the victory condition in the battle.
  • the support user can obtain an actual feeling that a battle is being performed in cooperation with a fellow by providing information regarding the fellow application user associated with the support user during the battle. For this reason, the relationship with a friend can be improved and the social property of a game can be improved by extension.
  • the function of the information providing means 54 in this modification is realized as follows.
  • CPU21 of the game server 20 discriminate
  • it is necessary is just to discriminate
  • the predetermined condition is that the battle (second battle) by the support user (second user) is the battle (first battle) by the user (first user) who did not satisfy the victory condition in the battle. ) It may be performed within a predetermined period thereafter. For example, when the support user conducts a battle at approximately the same time after the battle by the application user, information regarding the application user is provided to the support user during the battle by the support user. For this reason, the support user can realize more that he is fighting in cooperation with the application user.
  • the function of the information provision means 54 in this modification is implement
  • the battle date and time match date and time
  • the battle date may be, for example, the time when the menu m11 is selected and operated, or the time when the menu m12 is selected and operated.
  • the time when the menu m12 is selected and operated is the battle date and time
  • information on the application user is obtained based on the latest selection operation time when the menu m12 is selected and operated multiple times in one battle. It is possible to determine whether or not to provide.
  • the CPU 21 of the game server 20 determines whether or not the date and time of the battle by the support user (for example, the time when the menu m14 is selected and operated) is within the predetermined period of the battle date and time in step S114 of the sequence of FIG. If it is within the predetermined period, the processing of step S116 and step S118 is performed. On the other hand, when the battle execution start time by the support user is not within the predetermined period of the battle date, the CPU 21 performs the process of step S120. Note that the predetermined condition in the first modification and the predetermined condition in this modification may be combined.
  • the predetermined condition is that the battle (second battle) by the support user (second user) is the battle (first battle) by the user (first user) who did not satisfy the victory condition in the battle. ) It may be performed within a predetermined period thereafter, and the user (first user) and the support user (second user) may be associated (being friends).
  • the information providing means 54 when there are a plurality of users (first users) who did not satisfy the victory condition in the battle, among the plurality of first users,
  • the information regarding a predetermined number of users may be provided to the support user in order from the time when the battle (second battle) was performed from the time of the battle (second battle) by the support user.
  • the support user can obtain information related to a predetermined number of first users who performed the battle at a time close to the time of his / her battle during his / her battle. For this reason, the support user performs the battle by the first user almost at the same time as his / her own battle (that is, the battle against the same opponent at the same time). You can feel that you are fighting in cooperation. Since the support user can be intimate with the predetermined number of first users, when the first user and the support user are related as friends, the support user and the predetermined number of first users The social nature of the game can be further enhanced.
  • the function of the information providing means 54 in this modification is realized as follows.
  • a plurality of support user IDs corresponding to the user ID are recorded in the application list.
  • the date and time of battle (for example, the time when the menu m14 or the menu m14 is selected and operated) is recorded in the application list for each user ID and support user of the application user.
  • an image of a warrior card preliminarily designated by each support user is recorded in the application list for each user ID of a plurality of support users.
  • step S116 the CPU 21 of the game server 20 has a predetermined number in the order in which the battle date / time is closer to the battle user's battle date / time among the application user corresponding to the same support request and the plurality of support users. (For example, two users) are extracted. And CPU21 produces
  • the information providing means 54 is a support user (second user) among the plurality of first users.
  • Information regarding a predetermined number of users may be provided to the support user in descending order of closeness indicating the degree of relationship with the support user.
  • the support user is a user (companion) associated with the support user among the plurality of first users, and information on a predetermined number of close friends with the support user is obtained from his / her battle. Can get inside.
  • the support user can get a real feeling that he / she is performing a battle in cooperation with a close friend, he can be motivated to further increase the degree of relationship with the close friend.
  • a close relationship between users can be established.
  • 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 that can be used on the game, etc.
  • the number of times the present is sent or received (the number of presents) is recorded, and the familiarity value is set based on a certain standard based on the frequency and the number of times.
  • weighting may be taken into consideration for each item (in FIG. 20, support frequency, number of presents, etc.) that is the basis for setting 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 information providing means 55 in this modification is realized as follows.
  • a plurality of support user IDs corresponding to the user ID are recorded in the application list.
  • an image of a warrior card preliminarily designated by each support user is recorded in the application list for each user ID of a plurality of support users.
  • the CPU 21 of the game server 20 has a predetermined number (for example, two people) in descending order of closeness with the support user who is executing the battle among the application user corresponding to the same support request and the plurality of support users. Extract users. And CPU21 produces
  • the present invention is not limited thereto.
  • various objects such as a user's avatar image may be used instead of the card.
  • curd and object in a battle may not be plural, and a single card
  • the game of the present invention is not limited to this and can be applied to any game.
  • a battle is performed by a user in various types of games such as a role playing game, a table game, a puzzle game, a sports game, a racing game, a shooting game, an action game, an adventure game, and a simulation game.
  • the present invention can be preferably applied.
  • 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 server 20 and the database server 30 on the network are configured to realize the functions of the battle execution unit 52, the storage unit 53, the information providing unit 54, and the adjustment unit 55. Not limited. All these means may be realized by the communication terminal 10, or at least a part of the means may be realized by the communication terminal 10. Since the communication terminal 10 and the game server 20 can have substantially the same hardware configuration, each function can be realized by the communication terminal 10 as described in the above embodiment.
  • FIG. 21A and FIG. 21B each show an example of function sharing between the communication terminal 10, the game server 20, and the database server 30 for each function in the functional block diagram shown in FIG.
  • the database server 30 (game database 32) stores various data (for example, monster character data and application data).
  • the data is stored in the storage device in the communication terminal 10. May be.
  • the storage device may be a RAM 13 in the communication terminal 10, a mass storage device such as an HDD (Hard Disk Drive) (not shown), a flash memory, or the like.
  • HDD Hard Disk Drive

Abstract

　本発明のゲーム制御装置は、ユーザによるゲーム上の対戦を実行する対戦実行手段と、第１のユーザによる第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を記憶装置に記憶する記憶手段と、所定の条件を満たす場合に、第２のユーザによる対戦であって前記第１の対戦における前記第１のユーザの対戦相手との対戦である第２の対戦中に、前記第１のユーザに関する情報を前記記憶装置から取得して前記第２のユーザに提供する情報提供手段と、前記第１のユーザに関する情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるようにゲーム上の設定を調整する調整手段と、を備える。

Description

ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム
　本発明は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御する技術に関する。
　近年、特定のサービス提供者によるソーシャルネットワーキングサービス（ＳＮＳ）においてウェブブラウザ上で動作するＡＰＩ(Application Programming Interface)などの動作環境を基に作成されるゲーム用アプリケーションによって実行される、いわゆるソーシャルゲーム（Social Game）が普及している。ソーシャルゲームは、不特定多数のユーザ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言える。ユーザは、インターネットに接続可能であり、かつウェブブラウザが搭載された通信端末を備えていれば、時間と場所を問わずソーシャルゲームを楽しむことができる。
　上述したソーシャルゲームの一例として、非特許文献１に開示されているデジタルカードゲーム（ドラゴンコレクション（登録商標））が知られている。この公知のデジタルカードゲームは、ユーザが様々なエリアを探索して新たなカードやアイテムを取得するクエスト処理を行うメニューが設けられている。このようなソーシャルゲームは、従来のオンラインゲームよりも、ユーザ間の交流を図るためのコミュニケーション機能が充実している点が特徴の１つとなっている。ソーシャルゲームでは、例えば、他のユーザ（仲間）との協力プレイのほか、仲間との挨拶や連絡など仲間とコミュニケーションを取ることによる情報交換、仲間との間のゲーム上のアイテムのプレゼントあるいはアイテムの交換が行なわれている。
アプリＳＴＹＬＥ　Vol.5（株式会社イースト・プレス）、7-8頁
　従来のソーシャルゲームにおいて、同一の対戦相手に対して複数のユーザがそれぞれ対戦を行い、各ユーザが対戦において与えたダメージを累積させることによって、当該対戦相手を撃破（当該対戦相手に勝利）するものが知られている。このようなゲームでは、結果として、複数のユーザが協力して対戦相手から勝利を得るようになっているが、各ユーザそれぞれの対戦においては、各ユーザが個々に対戦相手と対戦を行うように構成されている。このため、ユーザが対戦相手を撃破したとしても、当該ユーザは、自らの対戦を行うまでに既に当該対戦相手と対戦した（つまり、当該対戦相手から勝利を得るに至らなかった）他のユーザと協力して対戦を行ったという実感が得られないものとなっていた。
　本発明は上述した観点に鑑みてなされたもので、ユーザによるゲーム上の対戦が行われる場合に、当該ユーザが、当該対戦における対戦相手と既に対戦した他のユーザと協力して対戦を行う実感が得られるようにしたゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステムを提供することを目的とする。
　本発明の第１の観点は、ゲーム制御装置である。
　当該ゲーム制御装置は、
　ユーザによるゲーム上の対戦を実行する対戦実行手段と、
　第１のユーザによる第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を記憶装置に記憶する記憶手段と、
　所定の条件を満たす場合に、第２のユーザによる対戦であって前記第１の対戦における前記第１のユーザの対戦相手との対戦である第２の対戦中に、前記第１のユーザに関する情報を前記記憶装置から取得して前記第２のユーザに提供する情報提供手段と、
　前記第１のユーザに関する情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるようにゲーム上の設定を調整する調整手段と、
　を備える。
　ここで、「第１のユーザに関する情報」とは、例えば、第１のユーザであることを識別できる情報であれば何でもよいが、例えば、第１のユーザのゲーム上のユーザ名やアバタ画像等であってもよいし、第１のユーザがゲーム上保有するキャラクタやアイテムなどであってもよい。また、「第１のユーザに関する情報」は、例えば、テキストデータであってもよいし、画像データあるいは音声データなどであってもよい。
　また、「所定の条件」とは、例えば、第２のユーザが所定数のエリアを制覇（クリア）したことであってもよいし、第２のユーザが所定数の他のユーザあるいはキャラクタとの対戦に勝利したことであってもよい。また、例えば、第２のユーザが所定数のアイテムを獲得したことであってもよいし、第２のユーザのゲームの進行度が所定値以上に達したことであってもよい。
　このゲーム制御装置では、第２のユーザは、所定の条件を満たす場合に、第２の対戦中に、第１のユーザに関する情報を得ることができる。また、第１のユーザに関する情報が提供されると、第２の対戦において第２のユーザが有利になるようにゲーム上の設定が調整される。このため、第２のユーザは、自らの対戦を行うまでに既に同じ対戦相手と対戦した（つまり、当該対戦相手から勝利を得るに至らなかった）第１のユーザと協力して対戦を行っているという実感を得ることができる。
　上記ゲーム制御装置において、前記所定の条件は、前記第１の対戦の結果に基づく前記第１のユーザの申請に応じて、前記第２のユーザが前記第２の対戦を行うことであってもよい。
　このゲーム制御装置によれば、第２のユーザが、第１の対戦の結果に基づく第１のユーザの申請に応じて第２の対戦を行った場合、第２の対戦中に、第１のユーザに関する情報が第２のユーザに提供される。この場合、第２のユーザは、第１のユーザと協力して対戦していることをより実感できるだけでなく、第１のユーザからの申請に応えようという使命感を得ながら対戦を行うことができる。このため、第２のユーザにとっては、対戦相手から勝利を得た場合に得られる達成感を高めることができる。
　上記ゲーム制御装置において、ユーザ同士を関係付ける関係付け手段を備え、前記所定の条件は、前記第２のユーザが前記第１のユーザと関係付けられていることであってもよい。
　この場合、第２のユーザは、自らと関係付けられた第１のユーザ（仲間）に関する情報が第２の対戦中に提供されることにより、仲間と協力して対戦を行っているという実感を得ることができる。このため、仲間との関係性を高めることができ、ひいてはゲームのソーシャル性を高めることができる。
　上記ゲーム制御装置において、前記所定の条件は、前記第２の対戦が、前記第１の対戦以降の所定期間内に行われることであってもよい。
　このゲーム制御装置によれば、例えば、第２のユーザが、第１のユーザによる第１の対戦以降のほぼ同じ時期に第２の対戦を行った場合、第２の対戦中に、第１のユーザに関する情報が第２のユーザに提供される。このため、第２のユーザは、第１のユーザと協力して対戦していることをより実感できる。また、第１のユーザと第２のユーザが仲間として関係付けられている場合には、第１の対戦が第２の対戦とほぼ同時期に行われた（つまり、同一の対戦相手に対してほぼ同時期に対戦した）ことにより、第１のユーザに対して親近感を生じ得る。これにより、ユーザ間の交流を促進することができ、ひいてはユーザ間のさらなる密接な関係を構築することができる。
　上記ゲーム制御装置において、前記情報提供手段は、前記第１のユーザが複数存在する場合に、複数の第１のユーザのうち、前記第１の対戦を行った時期が前記第２の対戦の時期から近い順に所定数のユーザに関する情報を、前記第２のユーザに提供してもよい。
　この場合、第２のユーザは、第２の対戦の時期と近い時期に第１の対戦を行った所定数の第１のユーザに関する情報を、第２の対戦中に得ることができる。このため、第２のユーザは、第１の対戦が第２の対戦とほぼ同時期に行われた（つまり、同一の対戦相手に対してほぼ同時期に対戦した）ことにより、第１のユーザと協力して対戦していることをより実感できる。第２のユーザは所定数の第１のユーザに対して親近感を生じ得るため、第１のユーザと第２のユーザが仲間として関係付けられている場合には、第２のユーザと所定数の第１のユーザとの交流を促進することができ、ゲームのソーシャル性をさらに高めることができる。
　上記ゲーム制御装置において、ユーザ同士を関係付ける関係付け手段を備え、前記情報提供手段は、前記第１のユーザが複数存在する場合に、複数の第１のユーザのうち、前記第２のユーザと関係付けられ、且つ、前記第２のユーザとの関係度合いを示す親密度が高い順に所定数のユーザに関する情報を、前記第２のユーザに提供してもよい。
　この場合、第２のユーザは、複数の第１のユーザのうち、第２のユーザと関係付けられたユーザ（仲間）であって、第２のユーザとの親密度の高い所定数の仲間に関する情報を、第２の対戦中に得ることができる。このため、第２のユーザは、親密度の高い仲間と協力して対戦を行っているという実感を得ることができるので、親密度の高い仲間との関係度をさらに高めるように動機付けることができる。これにより、ユーザ間の密接な関係を構築することができる。
　本発明の第２の観点は、ゲーム制御方法である。
　当該ゲーム制御方法は、
　ユーザによるゲーム上の対戦を実行するステップと、
　第１のユーザによる第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を記憶装置に記憶するステップと、
　所定の条件を満たす場合に、第２のユーザによる対戦であって前記第１の対戦における前記第１のユーザの対戦相手との対戦である第２の対戦中に、前記第１のユーザに関する情報を前記記憶装置から取得して前記第２のユーザに提供するステップと、
　前記第１のユーザに関する情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるようにゲーム上の設定を調整するステップと、
　を備える。
　本発明の第３の観点は、コンピュータに、
　ユーザによるゲーム上の対戦を実行する機能、
　第１のユーザによる第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を記憶装置に記憶する機能、
　所定の条件を満たす場合に、第２のユーザによる対戦であって前記第１の対戦における前記第１のユーザの対戦相手との対戦である第２の対戦中に、前記第１のユーザに関する情報を前記記憶装置から取得して前記第２のユーザに提供する機能、及び
　前記第１のユーザに関する情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるようにゲーム上の設定を調整する機能、
　を実現させるためのプログラムである。
　コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、ＤＶＤ－ＲＯＭやＣＤ－ＲＯＭ等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。すなわち、本発明の第４の観点は、前記プログラムを記録したことを特徴とする、コンピュータ読み取り可能な記録媒体である。
　本発明の第５の観点は、通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
　ユーザによるゲーム上の対戦を実行する対戦実行手段、
　第１のユーザによる第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を記憶装置に記憶する記憶手段、
　所定の条件を満たす場合に、第２のユーザによる対戦であって前記第１の対戦における前記第１のユーザの対戦相手との対戦である第２の対戦中に、前記第１のユーザに関する情報を前記記憶装置から取得して前記第２のユーザに提供する情報提供手段、
　前記第１のユーザに関する情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるようにゲーム上の設定を調整する調整手段、
　の各手段を、前記通信端末又は前記サーバのいずれか一方が備える。
　通信端末は、例えば携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機、通信機能付きゲーム装置等であってよい。
実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の一例を示す図。 実施形態の通信端末の外観の他の例を示す図。 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 データベースサーバに含まれるユーザデータベースの構成例を示す図。 モンスターキャラクタデータの内容を例示する図。 申請リストのデータ構成例を示す図。 トップページを表示する通信端末の表示画面の一例を示す図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 実施形態のゲーム制御装置の主要な処理の一例を示すシーケンスチャート。 変形例のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 親密度データのデータ構成例を示す図。 通信端末及びゲームサーバの各々における各機能の一構成例を示す図。 通信端末及びゲームサーバの各々における各機能の他の構成例を示す図。
　本発明は、２０１２年４月２５日に日本国特許庁に出願された特願２０１２－０９９７１４の特許出願に関連しており、この出願の内容がこの明細書に参照によって組み込まれる。
　以下、本発明の実施形態について説明する。
　（１）ゲームシステムの構成
　図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(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）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
　図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、ユーザデータベース３１と、ゲームデータベース３２とを備える。
　本実施形態のゲームシステムによって実現されるゲームのタイプは特に限定されるものではないが、以下では、本実施形態のゲームの一例として、ユーザの通信端末１０に対する操作に応じて、ユーザがゲーム上で仮想的に保有する戦士カードを使い、ゲーム上のモンスターであるモンスターキャラクタとバトルを行う対戦型デジタルカードゲーム（以下、適宜「本実施形態のゲーム」という。）を採り上げる。後述するように、本実施形態のゲームでは、ユーザがモンスターキャラクタとのバトル（対戦）で敗北する（勝利条件を満たさない）と支援要請を行うことができ、支援要請を受諾した他のユーザは、支援要請元のユーザのバトルを支援することができるように構成されている。
　図６に、本実施形態のゲームにおいて適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名／表示画像、技能レベル、戦士数、勝利数、仲間のユーザＩＤ及び保有カードのデータの各項目についての情報を含む。ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。
　以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
　ゲームの実行時に通信端末１０にユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・技能レベル
　ゲーム上のユーザの技能レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。
・戦士数
　ユーザが保有する戦士カードの数である。戦士数の最大値（例えば、６０）は予め規定されている。
・勝利数
　モンスターキャラクタとのバトルにおいて勝利した数である。
・仲間のユーザＩＤ
　対象となるユーザＩＤと関係付けられた他のユーザのユーザＩＤのデータである。なお、仲間のユーザＩＤは、後述する変形例１に関連する。
・保有カードのデータ
　保有カードのデータは、ユーザが保有している戦士カードのデータであり、例えば、図６に示すように、戦士カード毎の画像、攻撃力などのパラメータを含む。戦士カードがモンスターキャラクタとバトルを行うときに、モンスターキャラクタに対して攻撃力の値に応じたダメージを与えることができる。
　図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報、モンスターキャラクタのデータ（モンスターキャラクタデータ）、申請リストなどを記憶する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、各ユーザのモンスターキャラクタとのバトルの詳細結果などを含んでもよい。
　モンスターキャラクタデータの一例を図７に示す。モンスターキャラクタデータは、バトルの相手となるモンスターキャラクタのデータを含む。モンスターキャラクタデータは、バトル処理の実行とともにゲームデータベース３２から例えばＲＡＭ２３にロードされ、記憶されるデータである。図７では、バトルに出現するモンスターキャラクタＭＣ１，ＭＣ２，ＭＣ３，…の各々について、ウェブページに表示される画像と、モンスターキャラクタの体力を示すＨＰ(Hit Point)の値とが対応付けられている。例えば、図７に示す例では、各モンスターキャラクタのＨＰは１５００～２０００の範囲内であるが、この範囲の中からバトルを行うときにランダムにＨＰの値が設定されてもよい。
　本実施形態のゲームでは、例えばユーザがモンスターキャラクタとのバトルにおいて敗北した場合に、他のユーザに対してそのバトルに対する支援要請を行うことができることとしているが、他のユーザに対して支援要請を行うこと及びその支援要請に対して他のユーザが受諾することは本発明における必須の要件ではない。なお、バトルの支援要請を行う条件は、ユーザがモンスターキャラクタとのバトルにおいて敗北したという条件に限られない。バトル開始時に無条件で支援要請できることとしてもよいし、バトルにおける所定の条件が満たされた場合にのみ支援要請ができることとしてもよい。「バトルにおける所定の条件」とは、例えば、ユーザがバトルで使用する戦士カード、及びバトル相手のモンスターキャラクタの攻撃力などのパラメータ（又は能力レベル）についての所定の条件でよく、より具体的には、例えば、戦士カードとモンスターキャラクタの攻撃力の差が一定値あることという条件としてもよい。
　申請リストは、ユーザから行われた支援要請が順に書き込まれたリストである。
　なお、申請リストは、本発明に必須のデータではないが、本発明をさらに好ましくするためのデータである。
　申請リスト内の支援要請のうち支援が実行されたことによりモンスターキャラクタを撃破したものについては、リストから削除される。図８は、申請リストのデータ構成例を示す図である。図８に例示する申請リストでは、支援を要請した申請ユーザのユーザＩＤごとに、当該ユーザＩＤのユーザデータに含まれる複数の戦士カードのうちユーザによって予め指定された戦士カードの画像と、支援要請が行われたときのバトルのバトル相手（モンスターキャラクタ）と、バトル相手の残りＨＰと、支援要請に応じて支援する支援ユーザのユーザＩＤとが書き込まれる。残りＨＰは、対応するモンスターキャラクタの最新のＨＰの値を示している。例えば、１又は複数回のバトルにおいてＨＰが低減した場合に、低減後のＨＰが申請リストに書き込まれる。
　また、図示を省略したが、申請ユーザのユーザＩＤごとに、支援要請が行われたときのバトルの日時（対戦日時）が記録されてもよい。この場合、申請ユーザの対戦日時から所定時間が経過するまでにモンスターキャラクタの残りＨＰをゼロにしなければ（つまり、モンスターキャラクタを撃破できなければ）、そのモンスターキャラクタは倒せなかったと判断され、当該申請ユーザの対戦日時に対応する支援要請がリストから削除されてもよい。
　（５）本実施形態のゲーム
　以下、本実施形態のゲームのモンスターキャラクタとのバトル処理について、図９～１５を参照しながら説明する。図９は、本実施形態のゲームにおいて通信端末１０上に表示されるトップページの一例を示す図である。図１０～１５は、バトル処理が実行されるときの通信端末１０上に表示されるウェブページの例を示す図である。また、ここでは、最初にバトル処理を実行するユーザが「ＡＢＣ」（以下、ユーザ：ＡＢＣと表記する。）である場合を一例として説明する。
　また、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネルの操作によるウェブページのスクロール操作によって変化しうる。
　図９に例示する本実施形態のゲームのトップページは、個々のユーザＩＤに応じたウェブページで構成される。図９の例では、ユーザデータ表示領域、戦士画像表示領域及びメニュー表示領域を含む。
　ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル、戦士数、勝利数の各項目のデータ（図６参照）が表示される領域である。なお、図９において、戦士数の一例として「４０／６０」と表記されているが、これは、ユーザが保有する戦士カードが４０枚であり、最大で保有可能な戦士カードの枚数が６０枚であることを示す。
　戦士画像表示領域は、対象となるユーザＩＤのユーザデータに含まれる複数の戦士カードのうちユーザによって予め指定された戦士カードの画像が表示される領域である。
　メニュー表示領域は、本実施形態のゲームにおいてバトル処理の実行を開始するためのメニューｍ１を含む複数のメニュー（メニューｍ１以外は図示せず）が表示される領域である。
　図９のトップページ上で、メニューｍ１が選択操作されると、図１０のステップＳ１に示すようにウェブページが更新される。ステップＳ１のウェブページには、モンスターキャラクタＭＣの画像のほか、「バトル開始」と表記されたメニューｍ１１などが表示される。
　ステップＳ１のウェブページにおいてメニューｍ１１が選択されると、図１０のステップＳ２に示すようにウェブページが更新される。ステップＳ２のウェブページでは、ユーザ：ＡＢＣが保有する所定数（図の例では１０枚）の戦士カード２０２が表示される。また、ステップＳ２のウェブページでは、「攻撃する」と表記されたメニューｍ１２が表示される。戦士カード２０２は、ユーザ：ＡＢＣが保有する戦士カードの中からランダムに、あるいは予めユーザ：ＡＢＣの選択によって決定されてよい。
　ここで、メニューｍ１２が選択操作されると、図１１のステップＳ３に示すようにウェブページが更新されて、ユーザ：ＡＢＣがモンスターキャラクタＭＣとの間でゲーム上のバトルを行うことになる。
　モンスターキャラクタＭＣとのバトルでは、メニューｍ１２の選択操作に応じて行われる１０枚の戦士カードの攻撃によって、モンスターキャラクタＭＣのＨＰが低下する。メニューｍ１２が選択操作される毎に低下するＨＰの量は、戦士カードの攻撃力に応じて決定されてもよい。また、メニューｍ１２の選択操作に応じて、あるいはランダムなタイミングで、モンスターキャラクタＭＣから１０枚の戦士カードに対して順に攻撃が行われる。ステップＳ３のウェブページの１０枚の戦士カード２０２のうち、モンスターキャラクタＭＣに倒された戦士カード（ステップＳ３の例では、３枚のユーザの戦士カード２０２）については、倒れた形態でカードが表示される。バトルの結果、例えば、モンスターキャラクタＭＣのＨＰがゼロになり、且つ、ユーザ：ＡＢＣの１０枚の戦士カードのうち少なくとも１枚の戦士カードが倒されずにいる場合には、ユーザ：ＡＢＣがバトルに勝利し、モンスターキャラクタＭＣが撃破されたことになる。この場合、図１１のステップＳ４に示すようにウェブページが更新される。一方、例えば、モンスターキャラクタＭＣのＨＰがゼロにならず、且つ、ユーザ：ＡＢＣの１０枚の戦士カードがすべて倒された（全滅した）場合には、ユーザ：ＡＢＣがバトルに敗北した（勝利条件を満たさなかった）と判断されて、図１２のステップＳ５に示すようにウェブページが更新される。バトルに敗北した場合、モンスターキャラクタＭＣは消失せずに、バトル後に残存するＨＰが維持された状態となる。
　なお、ステップＳ５のウェブページには、他のユーザに支援要請を行うための「支援要請する」と表記されたメニューｍ１３が表示される。
　ここで、メニューｍ１３が選択操作されると、ユーザ：ＡＢＣは、申請ユーザとして申請リストに登録される。なお、メニューｍ１３が選択操作された場合、他のモンスターキャラクタとのバトルが行われるようにしてもよい。この場合、他のモンスターキャラクタの画像が表示されたステップＳ１のウェブページに更新される。
　次に、ユーザ：ＡＢＣが支援要請を行ったときに、他のユーザがその支援要請を受諾してユーザ：ＡＢＣを支援する場合の一例について説明する。ここでは、支援要請を受諾してユーザ：ＡＢＣを支援する他のユーザ（支援ユーザ）が「ＸＹＺ」（以下、ユーザ：ＸＹＺと表記する。）である場合を一例として説明する。
　先ず、ステップＳ５のウェブページにおいてユーザ：ＡＢＣがメニューｍ１３を選択操作すると、他のユーザに対して支援要請を受けるか否かを確認するためのメッセージが表示される。ここでは、他のユーザであるユーザ：ＸＹＺ向けのウェブページの一例を図１３のステップＳ６に示す。ステップＳ６のウェブページには、支援するか否かの選択を促すために、「参戦する」と表記されたメニューｍ１４と、「参戦しない」と表記されたメニューｍ１５とが表示される。ステップＳ６のウェブページにおいてメニューｍ１４（「参戦する」）が選択操作されると、図１３のステップＳ７に示すようにウェブページが更新されて、ユーザ：ＸＹＺが、自ら保有する所定数（図の例では１０枚）の戦士カード２０３を使用して、ユーザ：ＡＢＣのバトル相手であるモンスターキャラクタＭＣとバトルを行う画面に遷移する。ステップＳ７のウェブページは、例えば図１０のステップＳ２のウェブページと同形式であるが、モンスターキャラクタＭＣのＨＰの値は、ユーザ：ＡＢＣが敗北した時点のＨＰ（つまり、ステップＳ５のウェブページのモンスターキャラクタＭＣのＨＰ）の値となっている。
　そして、ステップＳ７のウェブページにおいて、「攻撃する」と表記されたメニューｍ１６が選択操作されると、図１４のステップＳ８に示すようにウェブページが更新されて、ユーザ：ＸＹＺがモンスターキャラクタＭＣとの間でゲーム上のバトルを行うことになる。
　ここで、図１４のステップＳ８に示すウェブページに更新されると、ユーザ：ＡＢＣが予め指定した戦士カードの画像（例えば、ユーザ：ＡＢＣのトップページの戦士画像表示領域に表示される戦士カードの画像）ＳＣが、ゲーム画面を瞬時に横切るように移動し、その後、図１４のステップＳ９に示すウェブページに更新される。ステップＳ９のウェブページは、例えば図１１のステップＳ３のウェブページと同形式であるが、ユーザ：ＡＢＣがユーザ：ＸＹＺのバトルに参戦したことを示すメッセージが含まれる。この場合、例えば、ユーザ：ＸＹＺがバトルで使用する戦士カード２０３の攻撃力が増加する。
　これにより、ユーザ：ＸＹＺは、申請ユーザであるユーザ：ＡＢＣと協力してバトルを行っているという実感を得ることができる。
　ユーザ：ＸＹＺによるバトルの結果、例えば、モンスターキャラクタＭＣのＨＰがゼロになり、且つ、ユーザ：ＸＹＺの１０枚の戦士カードのうち少なくとも１枚の戦士カードが倒されずにいる場合には、ユーザ：ＸＹＺがバトルに勝利し、モンスターキャラクタＭＣが撃破されたことになる。この場合、図１５のステップＳ１０に示すようにウェブページが更新される。一方、例えば、モンスターキャラクタＭＣのＨＰがゼロにならず、且つ、ユーザ：ＸＹＺの１０枚の戦士カードがすべて倒された（全滅した）場合には、ユーザ：ＸＹＺがバトルに敗北したと判断されて、図１５のステップＳ５に示すようにウェブページが更新される。バトルに敗北した場合、モンスターキャラクタＭＣは消失せずに、バトル後に残存するＨＰが維持された状態となる。
　また、支援ユーザであるユーザ：ＸＹＺがバトルに敗北した場合には、ユーザ：ＸＹＺは、当該バトルの対戦相手であったモンスターキャラクタＭＣをバトルの対象とした支援要請を行うことができないようにしてもよい。なお、支援ユーザが支援要請を行えるようにしてもよいが、この場合には、ゲームバランスが偏るおそれがあるとともに、処理が煩雑になるおそれがある。このため、支援ユーザは、支援要請を行えないようにすることが好ましい。この場合、申請ユーザはユーザ：ＡＢＣのまま変わることなく、新たな支援ユーザがユーザ：ＡＢＣからの支援要請を受諾してバトルを行うことになる。
　（６）ゲーム制御装置における各機能の概要
　次に、上述した本実施形態のゲームを実現するゲーム制御装置における各処理について説明する。
　本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述した対戦型デジタルカードゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図１６を参照して説明する。図１６は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
　なお、図１６の機能ブロック図において、対戦実行手段５２、記憶手段５３、情報提供手段５４及び調整手段５５が本発明の主要な構成に対応している。その他の手段は必ずしも必須の構成ではないが、本発明をさらに好ましくするための構成である。
　登録手段５１は、例えば通信端末１０に提供するウェブページ上での通信端末１０への適切な操作入力に基づいてユーザの要求を認識し、登録処理（ユーザ登録）を行う機能を備える。この登録処理は、ユーザが本実施形態のゲームにユーザ登録を行うときに実行される。
　なお、登録手段５１は、本発明に必須の構成要素ではないが、本発明をさらに好ましくするための構成要素である。
　登録手段５１の機能は、例えば以下のとおり実現される。ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して通信端末１０から登録要求メッセージを受信する。登録要求メッセージは、ゲームサーバ２０から提供されるウェブページ上での通信端末１０に対する所定の操作（例えば、所定のメニューの選択操作やユーザが指定するユーザＩＤやパスワード等のテキスト入力等）によって自動的に生成されるように、ウェブページが構成されていてもよい。登録要求メッセージには、送信元の通信端末１０を特定するための情報（例えば、ＵＩＤ（Unique Identifier）などの端末の個体識別情報、ＩＰアドレス、メールアドレス等）が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザＩＤが含まれていてもよい。
　ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれていない場合には、ユーザＩＤを新規に発行してそのユーザＩＤの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末１０へ送信する。ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれている場合には、そのユーザＩＤの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末１０へ送信する。
　登録が完了すると、ＣＰＵ２１は、ユーザＩＤに対応するユーザデータを生成し、ユーザデータベース３１に格納する。登録が完了すると、ユーザは、本実施形態のゲームを実行することが可能となる。
　対戦実行手段５２は、ユーザによるゲーム上のバトル（対戦）を実行する機能を備える。
　ここで、本実施形態のゲームでは、バトルの相手（対戦相手）がモンスターキャラクタである場合を一例として説明しているが、対戦相手は、例えば、他のユーザであってもよいし、他のユーザの保有する複数あるいは単一の戦士カードからなるチームであってもよいし、ＣＰＵ２１が任意に抽出した複数あるいは単一の戦士カードからなるチームであってもよい。
　対戦実行手段５２の機能は、例えば、通信端末１０に表示するウェブページを、通信端末１０からの要求に応じて逐次更新させることによって、ゲーム上のバトルを実行するようにしてもよい。この場合、対戦実行手段５２の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、通信端末１０からＨＴＴＰリクエストを受信し、そのＨＴＴＰリクエストに応じてゲーム上の所定の処理を行い、ゲームの実行結果としてのＨＴＭＬデータを含むＨＴＴＰレスポンスを通信端末１０宛に返信する。
　例えば、図９に示すゲームのトップページ上でメニューｍ１が選択操作されたことによってＨＴＴＰリクエストが通信端末１０からゲームサーバ２０宛に送信されると、ゲームサーバ２０のＣＰＵ２１は、そのＨＴＴＰリクエストに応じて、図１０のステップＳ１に示すウェブページを表示するためのＨＴＭＬデータを含むＨＴＴＰレスポンスを通信端末１０宛に送信する。このとき、ＨＴＭＬデータを作成するに当たって、ＣＰＵ２１は、モンスターキャラクタデータからゲームを実行中のユーザのバトル相手となるモンスターキャラクタを読み出してＲＡＭ２３に記憶させるとともに、読み出したデータに基づいてＨＴＭＬデータを生成する。
　また、ＣＰＵ２１は、例えば、ユーザの通信端末１０から、ゲームのトップページに対するＨＴＴＰリクエスト、あるいはメニューｍ１の選択操作に基づくＨＴＴＰリクエストが送信された場合には、そのユーザよりも勝利数が少ないユーザからの支援要請があるか否か、要請リストを検索し、ＨＴＴＰリクエストを送信したユーザよりも勝利数が少ないユーザが存在する場合には、当該ユーザの支援要請を、ＨＴＴＰリクエストを送信したユーザの通信端末１０宛に送信してもよい。なお、「そのユーザよりも勝利数が少ないユーザからの支援要請があるか否か」という条件は必須の条件ではなく、この条件についての判別処理を行わなくてもよい。この場合、ＨＴＴＰリクエストを送信したユーザの通信端末１０には、例えば、ステップＳ６に示したウェブページが表示される。
　モンスターキャラクタとのバトル処理では、ゲームサーバ２０のＣＰＵ２１は、ユーザによる適切な操作に応じて、ユーザが保有する戦士カードのうちバトルで使用される所定数の戦士カードの選択結果を取得する。なお、以下では、理解の容易のために、バトルに参加する戦士カードの数を１枚とする。ＣＰＵ２１は、各ユーザについて、モンスターキャラクタを倒したタイミングで、あるいはランダムなタイミングで、ゲームデータベース３２が記憶するモンスターキャラクタデータのうちいずれかのモンスターキャラクタをバトルのために出現させる。具体的には、ＣＰＵ２１は、ユーザのバトル相手となるモンスターキャラクタのデータを読み出し、ＲＡＭ２３に新たに書き込む。このとき、モンスターキャラクタのデータのＨＰの初期値がランダムに決定される。例えば、モンスターキャラクタデータにおいてモンスターキャラクタＭＣ１のＨＰが１５００～２０００の範囲として設定されているが、実際のバトル処理を行うときに使用されるＨＰの初期値として、１５００～２０００の範囲の中からランダムに１つの値が決定される。
　なお、ＣＰＵ２１は、支援ユーザからのメニューｍ１４（「参戦する」）の選択操作を認識すると、当該支援ユーザと、支援対象のバトルにおけるモンスターキャラクタとの間で、バトルの処理を実行する。具体的には、ＣＰＵ２１は、支援ユーザが支援対象のバトルにおけるモンスターキャラクタに対して攻撃操作が可能となるようにＨＴＭＬデータを生成して、支援ユーザの通信端末１０宛に送信する（例えば、図１３のステップＳ７のウェブページ参照）。このとき、バトル相手となるモンスターキャラクタのＨＰは、要請リストに書き込まれている残りＨＰの値を元にバトルが開始される。このとき、ＣＰＵ２１は、要請リストに書き込まれている残りＨＰの値をＲＡＭ２３に書き込む。なお、ＣＰＵ２１は、支援ユーザからのメニューｍ１４の選択操作を認識すると、当該支援ユーザのユーザＩＤを、申請リストのうち、支援対象の申請ユーザのユーザＩＤに対応する支援ユーザのユーザＩＤの箇所（図８参照）に記録する。
　ＣＰＵ２１は、バトルで使用される戦士カードのデータをユーザデータから読み出して、ＲＡＭ２３に記憶させ、以下のバトル処理を実行する。
　ＣＰＵ２１は、例えば、ユーザが戦士カードを使ってモンスターキャラクタを攻撃するとき（例えば図１０のステップＳ２のウェブページでメニューｍ１２（「攻撃する」）が選択操作されたとき）には、使用される戦士カードの攻撃力の値に応じてモンスターキャラクタのＨＰを低減させる処理を行う。以下、メニューｍ１２（「攻撃する」）に対する操作を「攻撃操作」という。
　例えば、戦士カードの攻撃力をＰａとし、ランダムに決定される係数をｋとすると、１回の攻撃操作によって、モンスターキャラクタのＨＰに対して行われる演算は、例えば以下の式（１）に従って行われるようにしてもよい。更新されたＨＰの値は、バトル実行中に逐次ＲＡＭ２３に上書きされる。
 
　ＨＰ＝ＨＰ－Ｐａ×ｋ　…（１）
 
　また、攻撃操作に応じてバトル相手のモンスターキャラクタから戦士カードに対して、一定の、あるいはランダムな値の攻撃力にて攻撃が加えられる。モンスターキャラクタの攻撃力は、ＨＰに概ね比例した値としてもよいし、一定の、あるいはランダムな値であってもよい。モンスターキャラクタから加えられる攻撃力、あるいはその攻撃力の積算値（複数回の攻撃操作に伴う攻撃力の積算値）が戦士カードの防御力を上回った場合に、その戦士カードが倒されたことになる。ユーザがバトルで使用される戦士カードが１枚のみの場合、その戦士カードが倒されたときにはユーザの敗北（勝利条件を満たさない）となる。なお、戦士カードが複数枚バトルに参加する場合、モンスターキャラクタから加えられる攻撃の対象となる戦士カードは一定の順に、あるいはランダムに決定されてよい。
　攻撃操作によるモンスターキャラクタのＨＰの更新は、上述した式（１）に限られない。例えば、上記式（１）におけるＰａは戦士カードの攻撃力ではなく、所定の範囲の中から攻撃操作に応じてランダムに決定される数値としても良い。
　また、バトルの勝敗の決定方法は適宜設定することができる。例えば、所定回数の攻撃操作によって、あるいは所定時刻までにモンスターキャラクタのＨＰをゼロにすることができなければ、そのモンスターキャラクタは倒せなかった（勝利条件を満たさなかった）と判断される。
　ＣＰＵ２１は、更新後のモンスターキャラクタのＨＰの値がゼロになった場合には、モンスターキャラクタを撃破した（モンスターキャラクタに勝利した）と判断し、ユーザデータの勝利数を１だけ増加させる。
　記憶手段５３は、ゲームを実行中のユーザ（第１のユーザ）によるバトル（第１の対戦）において当該ユーザが勝利条件を満たしていない場合に、当該ユーザに関する情報をゲームデータベース３２（記憶装置）に記憶する機能を備える。
　ここで、ユーザに関する情報とは、例えば、当該ユーザであることを識別できる情報であれば何でもよいが、例えば、当該ユーザのゲーム上のユーザ名やアバタ画像等であってもよいし、当該ユーザがゲーム上保有するキャラクタやアイテムなどであってもよい。また、ユーザに関する情報は、例えば、テキストデータであってもよいし、画像データあるいは音声データなどであってもよい。
　記憶手段５３の機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、ゲームを実行中のユーザによってメニューｍ１３（「支援要請する」）の選択操作が行われたことを認識すると、ゲームデータベース３２内の申請リストに所要のデータを書き込むことによって、当該ユーザに関する情報を記憶する。申請リストに書き込まれるデータは、図８に示したように、例えばメニューｍ１３を選択操作したユーザ（申請ユーザ）のユーザＩＤ、戦士カードの画像、バトル相手（バトルでユーザが敗北したときのモンスターキャラクタ）、モンスターキャラクタの残りＨＰ等である。なお、メニューｍ１３の選択操作が行われなくても、ゲームを実行中のユーザがバトルに敗北した場合には、当該ユーザに関する情報が申請リストに記憶されてもよい。
　なお、本実施形態では、ゲームを実行中のユーザによってメニューｍ１３（「支援要請する」）の選択操作が行われたことによって、当該ユーザに関する情報がゲームデータベース３２に記憶される場合を一例として説明しているが、例えば、当該ユーザがバトルにおいて勝利条件を満たしていないと判別されたときには、当該ユーザに関する情報がゲームデータベース３２内の所定の記憶領域に自動的に記憶されてもよい。
　情報提供手段５４は、所定の条件を満たす場合に、支援ユーザ（第２のユーザ）による対戦であって、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）のバトル（第１の対戦）における当該ユーザの対戦相手との対戦であるバトル（第２の対戦）中に、当該ユーザに関する情報をゲームデータベース３２（記憶装置）から取得して支援ユーザに提供する機能を備える。
　ここで、「所定の条件」とは、例えば、支援ユーザが所定数のエリアを制覇（クリア）したことであってもよいし、支援ユーザが所定数の他のユーザあるいはキャラクタとの対戦に勝利したことであってもよい。また、例えば、支援ユーザが所定数のアイテムを獲得したことであってもよいし、支援ユーザのゲームの進行度が所定値以上に達したことであってもよい。
　また、バトルにおいて勝利条件を満たさなかったユーザは、申請ユーザだけでなく、申請ユーザからの支援要請に応じてバトルを行ったものの勝利することができなかった支援ユーザも含む。
　また、所定の条件は、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）のバトル（第１の対戦）の結果に基づく当該ユーザの支援要請（申請）に応じて、支援ユーザ（第２のユーザ）がバトル（第２の対戦）を行うことであってもよい。
　例えば、支援ユーザが、申請ユーザのバトルの結果に基づく申請ユーザの申請に応じてバトルを行った場合、支援ユーザのバトル中に、申請ユーザに関する情報が支援ユーザに提供される。この場合、支援ユーザは、申請ユーザと協力して対戦していることをより実感できるだけでなく、申請ユーザからの申請に応えようという使命感を得ながらバトルを行うことができる。このため、支援ユーザにとっては、対戦相手から勝利を得た場合に得られる達成感を高めることができる。
　情報提供手段５４の機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ステップＳ７のウェブページにおいてメニューｍ１２（「攻撃する」）の選択操作を認識すると、支援ユーザに対応する申請ユーザの戦士カードの画像を申請リストから取得して、ステップＳ８のウェブページに含めるようにＨＴＭＬデータを生成して、支援ユーザの通信端末１０宛に送信する。なお、ステップＳ８のウェブページは、戦士カードの画像ＳＣがゲーム画面を瞬時に横切るように表示されるように構成されているが、戦士カードの画像ＳＣがゲーム画面上に常に表示されるようにウェブページが構成されてもよい。
　なお、本実施形態では、申請ユーザの戦士カードの画像を、申請ユーザに関する情報として提供する場合について説明したが、申請ユーザに関する情報は、例えば、申請ユーザのユーザ名であってもよいし、申請ユーザの表示画像などであってもよい。
　また、バトルにおいて勝利条件を満たさなかったユーザに関する情報がゲームデータベース３２内の所定の記憶領域に記憶されている場合には、ＣＰＵ２１は、当該情報を当該記憶領域から取得して提供するようにしてもよい。
　調整手段５５は、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）に関する情報が提供された場合に、支援ユーザによるバトル（第２の対戦）において支援ユーザ（第２のユーザ）が有利になるようにゲーム上の設定を調整する機能を備える。
　調整手段５５の機能は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、ステップＳ７のウェブページにおいてメニューｍ１２（「攻撃する」）の選択操作を認識すると、支援ユーザによるバトル（第２の対戦）において、支援ユーザが使用する戦士カードの攻撃力を増加させる、あるいはバトル相手のモンスターキャラクタの攻撃力を低下させる処理を行うことにより、支援ユーザが有利になるようにゲーム上の設定を調整する。なお、戦士カードの攻撃力の増加、あるいはモンスターキャラクタの攻撃力の低下は、所定比率の増加あるいは低下でもよいし、所定量の増加あるいは低下でもよい。また、例えば、バトル相手のモンスターキャラクタのＨＰを所定比率、あるいは所定量低下させることにより、支援ユーザが有利になるようにゲーム上の設定を調整してもよい。
　さらに、申請ユーザに関する情報に基づいて、支援ユーザが有利になるように調整されてもよい。例えば、支援ユーザがバトルで使用する戦士カードの攻撃力に、申請ユーザの保有する戦士カードの攻撃力が加わった状態でバトルが行われるようにしてもよい。この場合に用いられる申請ユーザの戦士カードは、申請ユーザがバトルで使用した戦士カードであってもよいし、ステップＳ８のウェブページで表示される戦士カードであってもよい。
　（７）本実施形態のゲーム制御装置の主要な処理のフロー
　次に、本実施形態のゲーム制御装置により行われる主要な処理のシーケンスの一例について、図１７のシーケンスチャートを参照して説明する。図１７は、本実施形態のゲーム制御装置によって行われる、本実施形態のゲームのバトル処理を示している。なお、図１７には、図１３～図１５に記載された各ウェブページが表示されるタイミングを符号により示している。
　また、図１７では、ユーザ：ＡＢＣが第１のユーザの例であり、ユーザ：ＸＹＺが第２のユーザの例である。
　先ず、ゲームを実行中のユーザ：ＡＢＣ（第１のユーザ）が、例えばモンスターキャラクタＭＣとのバトルに敗北すると、例えば図１２のステップＳ５のウェブページが表示される。ここで、メニューｍ１３（「支援要請する」）が選択操作され、支援要請を含むＨＴＴＰリクエストを受信すると（ステップＳ１００）、ゲームサーバ２０のＣＰＵ２１は、ゲームデータベース３２内の申請リストに所要のデータを書き込む（ステップＳ１０２）。書き込まれるデータは、図８に示したように、例えば、申請ユーザ（ここでは、ユーザ：ＡＢＣ）のユーザＩＤ、戦士カードの画像、バトル相手（バトルでユーザが敗北したときのモンスターキャラクタ）、バトル相手の残りＨＰ等である。ユーザ：ＡＢＣの支援要請が申請リストに書き込まれた後、ＣＰＵ２１は、ゲームのトップページに対するＨＴＴＰリクエスト、あるいはメニューｍ１の選択操作に基づくＨＴＴＰリクエストを送信するユーザを認識する度に（ステップＳ１０４）、そのユーザがユーザ：ＡＢＣよりも勝利数が多いか否かを判定し、多い場合には、そのユーザに対してユーザ：ＡＢＣの支援要請を送信してもよい（ステップＳ１０６）。つまり、申請ユーザよりも勝利数が多いユーザを対象として支援要請が行われてもよい。ここでは、ユーザ：ＸＹＺの通信端末１０宛にユーザ：ＡＢＣの支援要請が送信された場合を想定する。支援要請を受信したユーザＡＢＣの通信端末１０には、例えば図１３のステップＳ６のウェブページが表示される。
　ステップＳ６のウェブページ上でメニューｍ１４（「参戦する」）が選択操作され、支援要請が受諾されたことを認識すると（ステップＳ１０８）、ＣＰＵ２１は、ユーザＡＢＣと、ユーザＫＮＭがバトルで敗北したモンスターキャラクタＭＣとの間のバトル画面用のＨＴＭＬデータを生成して送信する（ステップＳ１１０）。その結果、例えば図１３のステップＳ７のウェブページがユーザ：ＸＹＺの通信端末１０に表示される。このとき、ユーザ：ＸＹＺのバトルにおけるモンスターキャラクタＭＣのＨＰは、申請リストのユーザ：ＡＢＣのデータが読み出されて表示される。そして、ユーザＡＢＣの攻撃操作が行われると（ステップＳ１１２）、ＣＰＵ２１は、所定の条件を満たすか否かを判別する（ステップＳ１１４）。例えば、所定の条件は、支援ユーザ（ユーザ：ＸＹＺ）が申請ユーザ（ユーザ：ＡＢＣ）のバトルの結果に基づく申請ユーザの申請に応じて、支援ユーザがバトルを行うことである場合であってもよい。ここでは、所定の条件を満たす場合を想定すると（ステップＳ１１４：ＹＥＳ）、ＣＰＵ２１は、図１４のステップＳ８に示すウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＸＹＺの通信端末１０宛に送信する（ステップＳ１１６）。また、ＣＰＵ２１は、支援ユーザによるバトルにおいて、支援ユーザが使用する戦士カードの攻撃力を増加させる、あるいはバトル相手のモンスターキャラクタの攻撃力を低下させるなどの処理を行うことにより、支援ユーザが有利になるようにゲーム上の設定を調整する（ステップＳ１１８）。そして、ＣＰＵ２１は、バトル処理を行い（ステップＳ１２０）、図１４のステップＳ９に示すウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＸＹＺの通信端末１０宛に送信する（ステップＳ１２２）。なお、ステップＳ１１４～Ｓ１２２の処理は、ステップＳ１１２の攻撃操作が行われるごとに繰り返し行われてもよい。ここで、ユーザ：ＸＹＺがモンスターキャラクタＭＣを撃破した場合には、ＣＰＵ２１からのＨＴＭＬデータの送信（ステップＳ１２４）に応じて、例えば図１５のステップＳ１０のウェブページがユーザ：ＸＹＺの通信端末１０に表示される。一方、ユーザ：ＸＹＺがモンスターキャラクタＭＣに敗北した場合には、ＣＰＵ２１からのＨＴＭＬデータの送信（ステップＳ１２４）に応じて、例えば図１５のステップＳ１１のウェブページがユーザ：ＸＹＺの通信端末１０に表示される。
　ＣＰＵ２１は、ユーザＡＢＣとモンスターキャラクタＭＣ１のバトルの後、申請リスト及びユーザデータを更新する（ステップＳ１２）。例えば、ユーザ：ＸＹＺがモンスターキャラクタＭＣを撃破した場合、申請リストから、該当データ（ユーザ：ＡＢＣの対戦相手としてのモンスターキャラクタＭＣ）を削除するとともに、ユーザ：ＡＢＣとユーザ：ＸＹＺのユーザデータにアクセスして、それぞれ勝利数を１だけ増加させる。
　上述したように、実施形態のゲーム制御装置によれば、支援ユーザは、所定の条件を満たす場合に、自らのバトル中に、バトルにおいて勝利条件を満たさなかったユーザに関する情報を得ることができる。また、バトルにおいて勝利条件を満たさなかったユーザに関する情報が提供されると、支援ユーザによるバトルにおいて支援ユーザが有利になるようにゲーム上の設定が調整される。このため、支援ユーザは、自らのバトルを行うまでに既に同じ対戦相手と対戦した（つまり、当該対戦相手から勝利を得るに至らなかった）他のユーザと協力してバトルを行っているという実感を得ることができる。
　（８）変形例
　以下、上述した実施形態の変形例について説明する。
　（８－１）変形例１
　図１８は、本変形例のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。図１８の機能ブロック図は、図１６と比較すると、関係付け手段５６が追加された点で異なる。関係付け手段５６は、ユーザ同士を関係付ける機能を備える。例えば、関係付け手段５６は、ユーザＩＤに基づく申請を契機として、当該ユーザＩＤと他のユーザＩＤとを仲間として関係付ける機能を備える。
　関係付け手段５６の機能は例えば、以下のとおり実現される。ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して、あるユーザＩＤに対応するユーザの通信端末１０から、仲間になりたいユーザＩＤ（あるいは、対応するユーザ名）を指定した申請メッセージ（申請）を受け付ける。この申請メッセージの送信は、ユーザの通信端末１０に提供されるウェブページの機能として予め設定されている。ＣＰＵ２１は、申請メッセージを受け付けると、申請メッセージに含まれるユーザＩＤに基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０宛に、他のユーザＩＤに基づく申請を承認するか否かを返信することを要求するためのウェブページを表示させるＨＴＭＬデータを送信する。その申請を承認することが返信されれば、ＣＰＵ２１は、両者を仲間として登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータの「仲間のユーザＩＤ」の箇所（図６参照）にデータを書き込む。
　なお、ユーザ同士を関係付ける条件は、上記のような申請と承認を必要とする形式に限らず、同一のゲーム上のステージを実行するユーザ同士を仲間として登録してもよい。あるいは、所定回数の挨拶メッセージを送信するユーザ同士を自動的に仲間として登録してもよいし、ユーザ間でバトルを行うゲーム上のモードが存在する場合には、所定回数以上バトルを行ったユーザ同士を自動的に仲間として登録してもよい。
　また、ユーザ同士を直接的に対応付けるのではなく、各ユーザを同一のグループ（ギルド等）と対応付けることで、そのグループ内のユーザ同士を関連関係付けても良い。例えば、ユーザＡが所定のグループと対応付けられたユーザ内の特定のユーザＢに対して上記のような申請を行い、当該特定のユーザＢの承認を得ることができると、当該所定のグループとユーザＡとを対応付ける。このようにすることによって、所定のグループ内の特定のユーザに対して申請と承認を行うことで、所定のグループに所属する直接的に申請と承認を行っているかいないかに関わらず同一グループ内のユーザ同士を関連関係付けるようにしても良い。
　本実施形態では、ユーザ同士の仲間関係の登録をユーザデータベース３１にデータを書き込むことによって実現する例を示したが、この例に限られない。仲間関係に関するデータは、ゲームサーバ２０からアクセス可能なネットワーク上の外部の記憶装置に書き込まれるようにしてもよい。
　本変形例では、所定の条件は、支援ユーザ（第２のユーザ）が、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）と関係付けられていることであってもよい。
　この場合、支援ユーザは、自らと関係付けられた仲間の申請ユーザに関する情報がバトル中に提供されることにより、仲間と協力して対戦を行っているという実感を得ることができる。このため、仲間との関係性を高めることができ、ひいてはゲームのソーシャル性を高めることができる。
　本変形例における情報提供手段５４の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、図１７のシーケンスのステップＳ１１４において、申請ユーザが支援ユーザの仲間であるか否かを判別し、仲間である場合には、ステップＳ１１６及びステップＳ１１８の処理を行う。一方、申請ユーザが支援ユーザの仲間でない場合には、ＣＰＵ２１は、ステップＳ１２０の処理を行う。なお、申請ユーザが支援ユーザの仲間であるか否かは、申請ユーザのユーザデータを参照して判別すればよい。
　（８－２）変形例２
　上記実施形態において、所定の条件は、支援ユーザ（第２のユーザ）によるバトル（第２の対戦）が、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）によるバトル（第１の対戦）以降の所定期間内に行われることであってもよい。
　例えば、支援ユーザが、申請ユーザによるバトル以降のほぼ同じ時期にバトルを行った場合、支援ユーザによるバトル中に、申請ユーザに関する情報が支援ユーザに提供される。このため、支援ユーザは、申請ユーザと協力して対戦していることをより実感できる。また、申請ユーザと支援ユーザが仲間として関係付けられている場合には、申請ユーザによるバトルが支援ユーザによるバトルとほぼ同時期に行われた（つまり、同一の対戦相手に対してほぼ同時期に対戦した）ことにより、申請ユーザに対して親近感を生じ得る。これにより、ユーザ間の交流を促進することができ、ひいてはユーザ間のさらなる密接な関係を構築することができる。
　本変形例における情報提供手段５４の機能は、以下のようにして実現される。なお、ここでは、申請ユーザのユーザＩＤごとに、支援要請が行われたときのバトルの日時（対戦日時）が申請リストに記録されていることを想定する。なお、対戦日時は、例えば、メニューｍ１１が選択操作された時期であってもよいし、メニューｍ１２が選択操作された時期であってもよい。ここで、メニューｍ１２が選択操作された時期を対戦日時とする場合には、１回のバトルにおいてメニューｍ１２が複数回選択操作されたときの最新の選択操作時期に基づいて、申請ユーザに関する情報を提供するか否かを判別することが可能となる。ゲームサーバ２０のＣＰＵ２１は、図１７のシーケンスのステップＳ１１４において、支援ユーザによるバトルの日時（例えば、メニューｍ１４が選択操作された時期）が、対戦日時の所定期間内であるか否かを判別し、所定期間内である場合には、ステップＳ１１６及びステップＳ１１８の処理を行う。一方、支援ユーザによるバトルの実行開始時期が対戦日時の所定期間内でない場合には、ＣＰＵ２１は、ステップＳ１２０の処理を行う。
　なお、変形例１における所定の条件と本変形例における所定の条件とを組合せてもよい。具体的には、所定の条件は、支援ユーザ（第２のユーザ）によるバトル（第２の対戦）が、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）によるバトル（第１の対戦）以降の所定期間内に行われ、且つ、当該ユーザ（第１のユーザ）と支援ユーザ（第２のユーザ）が関係付けられている（仲間である）ことであってもよい。
　（８－３）変形例３
　上記実施形態において、情報提供手段５４は、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）が複数存在する場合に、複数の第１のユーザのうち、第１のユーザによるバトル（第１の対戦）を行った時期が支援ユーザによるバトル（第２の対戦）の時期から近い順に所定数のユーザに関する情報を、支援ユーザに提供してもよい。
　この場合、支援ユーザは、自らのバトルの時期と近い時期にバトルを行った所定数の第１のユーザに関する情報を、自らのバトル中に得ることができる。このため、支援ユーザは、第１のユーザによるバトルが自らのバトルとほぼ同時期に行われた（つまり、同一の対戦相手に対してほぼ同時期に対戦した）ことにより、第１のユーザと協力して対戦していることをより実感できる。支援ユーザは所定数の第１のユーザに対して親近感を生じ得るため、第１のユーザと支援ユーザが仲間として関係付けられている場合には、支援ユーザと所定数の第１のユーザとの交流を促進することができ、ゲームのソーシャル性をさらに高めることができる。
　本変形例における情報提供手段５４の機能は、以下のようにして実現される。なお、ここでは、申請ユーザのユーザＩＤごとに、当該ユーザＩＤに対応する複数の支援ユーザのＩＤが申請リストに記録されていることを想定する。また、申請ユーザのユーザＩＤ及び支援ユーザごとに、バトルの日時（例えば、メニューｍ１４又はメニューｍ１４が選択操作された時期）が申請リストに記録されていることを想定する。また、申請リストには、複数の支援ユーザのユーザＩＤごとに、各支援ユーザが予め指定した戦士カードの画像が記録されていることを想定する。ゲームサーバ２０のＣＰＵ２１は、ステップＳ１１６の処理において、同じ支援要請に対応する申請ユーザ及び複数の支援ユーザのうち、バトルの日時が、バトルを実行中の支援ユーザのバトルの日時から近い順に所定数（例えば２人）のユーザを抽出する。そして、ＣＰＵ２１は、抽出したユーザのユーザＩＤに対応する戦士カードの画像を含むように、ステップＳ８のウェブページを表示するためのＨＴＭＬデータを生成して、バトルを実行中の支援ユーザの通信端末１０宛に送信する。
　（８－４）変形例４
　上記実施形態において、情報提供手段５４は、バトルにおいて勝利条件を満たさなかったユーザ（第１のユーザ）が複数存在する場合に、複数の第１のユーザのうち、支援ユーザ（第２のユーザ）との関係度合いを示す親密度が高い順に所定数のユーザに関する情報を、支援ユーザに提供してもよい。
　この場合、支援ユーザは、複数の第１のユーザのうち、支援ユーザと関係付けられたユーザ（仲間）であって、支援ユーザとの親密度の高い所定数の仲間に関する情報を、自らのバトル中に得ることができる。このため、支援ユーザは、親密度の高い仲間と協力してバトルを行っているという実感を得ることができるので、親密度の高い仲間との関係度をさらに高めるように動機付けることができる。これにより、ユーザ間の密接な関係を構築することができる。
　ここで、親密度とは、仲間のユーザ間の関係性の高さを一定の基準で数値化したものである。親密度のデータ（親密度データ）の一例を図２０に示す。図２０に示す親密度データの例では、各ユーザの仲間のユーザ（ユーザＩＤ）と対応付けて、ユーザ間の応援メッセージの送信あるいは受信の頻度（応援頻度）、ゲーム上で使用可能なアイテムなどのプレゼントを送信あるいは受信した回数（プレゼント回数）などが記録され、これらの頻度や回数に基づいて一定の基準で親密度の値が設定される。応援頻度やプレゼント回数が多いほど親密度が高く設定される。また、一定の基準では、親密度の設定の基礎となる項目（図２０では、応援頻度やプレゼント回数など）ごとに、重み付けを考慮したものであってもよい。例えば、応援頻度が少なくてもプレゼント回数が多い場合に親密度を高く設定してもよい。このような親密度データは、例えば、ユーザデータベース３１内に記録される。
　本変形例における情報提供手段５５の機能は、以下のようにして実現される。なお、ここでは、申請ユーザのユーザＩＤごとに、当該ユーザＩＤに対応する複数の支援ユーザのＩＤが申請リストに記録されていることを想定する。また、申請リストには、複数の支援ユーザのユーザＩＤごとに、各支援ユーザが予め指定した戦士カードの画像が記録されていることを想定する。ゲームサーバ２０のＣＰＵ２１は、ステップＳ１１６の処理において、同じ支援要請に対応する申請ユーザ及び複数の支援ユーザのうち、バトルを実行中の支援ユーザとの親密度の高い順に所定数（例えば２人）のユーザを抽出する。そして、ＣＰＵ２１は、抽出したユーザのユーザＩＤに対応する戦士カードの画像を含むように、ステップＳ８のウェブページを表示するためのＨＴＭＬデータを生成して、バトルを実行中の支援ユーザの通信端末１０宛に送信する。
　以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。上記実施形態及び各変形例に記載された技術的事項は適宜組合せて適用してもよい。
　上述した実施形態では、複数のカードを用いたバトルを行う場合を例として説明したが、これに限られない。カードでなく、例えば、ユーザのアバタ画像等の各種オブジェクトであってもよい。また、バトルにおけるカードやオブジェクトは複数でなくてもよく、単一のカードやオブジェクトで構わない。あるいは、カード等のオブジェクトを使用せずにバトル処理を行ってもよい。
　上述した実施形態では、実行対象のゲームがカードを用いたバトルゲームである場合の例について説明したが、本発明のゲームはこれに限られず、任意のゲームに適用することができる。例えば、ロールプレイングゲーム、テーブルゲーム、パズルゲーム、スポーツゲーム、レースゲーム、シューティングゲーム、アクションゲーム、アドベンチャーゲーム、シミュレーションゲームなどの各種ジャンルのゲームにおいて、ユーザによる対戦が行われる場合には、当該ユーザの対戦相手と既に対戦し、且つ、当該対戦相手との対戦において勝利条件を満たしていない他のユーザに関する情報を当該ユーザに提供することによって、当該ユーザが対戦において有利になるようにすることができ、本発明を好適に適用することができる。
　上述した実施形態では、ユーザによる通信端末に対する所定の操作入力は、ユーザの通信端末に対する所定の操作釦の押下操作の入力や、タッチパネル機能を備えた通信端末に対する表示画面上のタッチ操作の入力であるとしたが、操作入力はこれに限られない。操作入力は、加速度センサを備えた通信端末を振ることによる操作入力、あるいはジェスチャによる操作入力（ジェスチャ入力）であってもよい。ジェスチャ入力では、撮像機能を備えた通信端末に対する所定のジェスチャを行うことで通信端末がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラムを実行可能な通信端末の場合には、操作入力は、音声を入力することにより行われてもよい。
　上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、各ユーザによるゲームの進行を制御できることは言うまでもない。
　上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、対戦実行手段５２、記憶手段５３、情報提供手段５４、及び調整手段５５の各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。例えば、図２１Ａ，図２１Ｂにはそれぞれ、図１５に示した機能ブロック図の各機能について、通信端末１０と、ゲームサーバ２０及びデータベースサーバ３０との機能分担の例を示す。なお、上述した実施形態では、各種データ（例えば、モンスターキャラクタデータや申請データなど）をデータベースサーバ３０（ゲームデータベース３２）が記憶している構成としたが、通信端末１０内の記憶装置に記憶させてもよい。その場合には、記憶装置は、通信端末１０内のＲＡＭ１３や図示しないＨＤＤ(Hard Disk Drive)などの大容量記憶装置やフラッシュメモリ等であってよい。

Claims (10)

  1. 　ユーザによるゲーム上の対戦を実行する対戦実行手段と、
    　第１のユーザによる第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を記憶装置に記憶する記憶手段と、
    　所定の条件を満たす場合に、第２のユーザによる対戦であって前記第１の対戦における前記第１のユーザの対戦相手との対戦である第２の対戦中に、前記第１のユーザに関する情報を前記記憶装置から取得して前記第２のユーザに提供する情報提供手段と、
    　前記第１のユーザに関する情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるようにゲーム上の設定を調整する調整手段と、
    　を備えた、ゲーム制御装置。
  2. 　前記所定の条件は、前記第１の対戦の結果に基づく前記第１のユーザの申請に応じて、前記第２のユーザが前記第２の対戦を行うことであることを特徴とする、
    　請求項１に記載されたゲーム制御装置。
  3. 　ユーザ同士を関係付ける関係付け手段を備え、
    　前記所定の条件は、前記第２のユーザが前記第１のユーザと関係付けられていることであることを特徴とする、
    　請求項１または２に記載されたゲーム制御装置。
  4. 　前記所定の条件は、前記第２の対戦が、前記第１の対戦以降の所定期間内に行われることであることを特徴とする、
    　請求項１～３のいずれかに記載されたゲーム制御装置。
  5. 　前記情報提供手段は、前記第１のユーザが複数存在する場合に、複数の第１のユーザのうち、前記第１の対戦を行った時期が前記第２の対戦の時期から近い順に所定数のユーザに関する情報を、前記第２のユーザに提供することを特徴とする、
    　請求項１～４のいずれかに記載されたゲーム制御装置。
  6. 　ユーザ同士を関係付ける関係付け手段を備え、
    　前記情報提供手段は、前記第１のユーザが複数存在する場合に、複数の第１のユーザのうち、前記第２のユーザと関係付けられ、且つ、前記第２のユーザとの関係度合いを示す親密度が高い順に所定数のユーザに関する情報を、前記第２のユーザに提供することを特徴とする、
    　請求項１～４のいずれかに記載されたゲーム制御装置。
  7. 　ユーザによるゲーム上の対戦を実行するステップと、
    　第１のユーザによる第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を記憶装置に記憶するステップと、
    　所定の条件を満たす場合に、第２のユーザによる対戦であって前記第１の対戦における前記第１のユーザの対戦相手との対戦である第２の対戦中に、前記第１のユーザに関する情報を前記記憶装置から取得して前記第２のユーザに提供するステップと、
    　前記第１のユーザに関する情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるようにゲーム上の設定を調整するステップと、
    　を備えた、ゲーム制御方法。
  8. 　コンピュータに、
    　ユーザによるゲーム上の対戦を実行する機能、
    　第１のユーザによる第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を記憶装置に記憶する機能、
    　所定の条件を満たす場合に、第２のユーザによる対戦であって前記第１の対戦における前記第１のユーザの対戦相手との対戦である第２の対戦中に、前記第１のユーザに関する情報を前記記憶装置から取得して前記第２のユーザに提供する機能、及び
    　前記第１のユーザに関する情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるようにゲーム上の設定を調整する機能、
    　を実現させるためのプログラム。
  9. 　請求項８に記載されたプログラムを記録したことを特徴とする、コンピュータ読み取り可能な記録媒体。
  10. 　通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
    　ユーザによるゲーム上の対戦を実行する対戦実行手段、
    　第１のユーザによる第１の対戦において前記第１のユーザが勝利条件を満たしていない場合に、前記第１のユーザに関する情報を記憶装置に記憶する記憶手段、
    　所定の条件を満たす場合に、第２のユーザによる対戦であって前記第１の対戦における前記第１のユーザの対戦相手との対戦である第２の対戦中に、前記第１のユーザに関する情報を前記記憶装置から取得して前記第２のユーザに提供する情報提供手段、
    　前記第１のユーザに関する情報が提供された場合に、前記第２の対戦において前記第２のユーザが有利になるようにゲーム上の設定を調整する調整手段、
    　の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
    　ゲームシステム。
PCT/JP2013/061724 2012-04-25 2013-04-22 ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム WO2013161732A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2012099714A JP5646537B2 (ja) 2012-04-25 2012-04-25 ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP2012-099714 2012-04-25

Publications (1)

Publication Number Publication Date
WO2013161732A1 true WO2013161732A1 (ja) 2013-10-31

Family

ID=49483049

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/061724 WO2013161732A1 (ja) 2012-04-25 2013-04-22 ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム

Country Status (2)

Country Link
JP (1) JP5646537B2 (ja)
WO (1) WO2013161732A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015075847A1 (ja) * 2013-11-21 2015-05-28 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 情報通信方法

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013116926A1 (en) 2012-02-06 2013-08-15 Hothead Games, Inc. Virtual opening of boxes and packs of cards
JP5800932B2 (ja) * 2014-02-26 2015-10-28 グリー株式会社 ゲームプログラム、制御方法、及び情報処理装置
US20150335999A1 (en) * 2014-05-21 2015-11-26 DeNA Co., Ltd. Facilitating the collaboration of players in an online game
JP5827386B1 (ja) * 2014-08-13 2015-12-02 グリー株式会社 プログラム、サーバの制御方法、及びサーバ
KR101596160B1 (ko) * 2014-08-25 2016-02-22 주식회사 엔씨소프트 카드 게임 프로그램 및 이를 실행하는 컴퓨팅 디바이스
JP6195592B2 (ja) * 2015-06-29 2017-09-13 グリー株式会社 プログラム、サーバの制御方法、及びサーバ
US20170036119A1 (en) * 2015-08-04 2017-02-09 Hothead Games, Inc. Virtual card play based interactive gaming experiences
US9919213B2 (en) 2016-05-03 2018-03-20 Hothead Games Inc. Zoom controls for virtual environment user interfaces
US10004991B2 (en) 2016-06-28 2018-06-26 Hothead Games Inc. Systems and methods for customized camera views in virtualized environments
US10010791B2 (en) 2016-06-28 2018-07-03 Hothead Games Inc. Systems and methods for customized camera views and customizable objects in virtualized environments
JP6872458B2 (ja) * 2017-08-15 2021-05-19 グリー株式会社 プログラム、サーバの制御方法、及びサーバ
JP6896026B2 (ja) * 2017-10-11 2021-06-30 グリー株式会社 ゲームプログラム、制御方法、及び情報処理装置
JP7164649B2 (ja) 2021-03-11 2022-11-01 グリー株式会社 ゲーム制御方法、コンピュータ及び制御プログラム

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011188887A (ja) * 2010-03-11 2011-09-29 Konami Digital Entertainment Co Ltd ゲームシステム、ゲームシステムの制御方法及びプログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011188887A (ja) * 2010-03-11 2011-09-29 Konami Digital Entertainment Co Ltd ゲームシステム、ゲームシステムの制御方法及びプログラム

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CROWS, X WORST SAIKYO DENSETSU, APURI FAN, vol. 2, 15 April 2012 (2012-04-15), pages 12 - 13 *
DRAGON COLLECTION, APURI STYLE, vol. 3, 1 July 2011 (2011-07-01), pages 22 - 23 *
NINJA ROYAL, APURI STYLE, vol. 6, 15 January 2012 (2012-01-15), pages 154 - 155 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015075847A1 (ja) * 2013-11-21 2015-05-28 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 情報通信方法
US9294188B2 (en) 2013-11-21 2016-03-22 Panasonic Intellectual Property Corporation Of America Information communication device
CN105723632A (zh) * 2013-11-21 2016-06-29 松下电器（美国）知识产权公司 信息通信方法
JPWO2015075847A1 (ja) * 2013-11-21 2017-03-16 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 情報通信方法
US9680572B2 (en) 2013-11-21 2017-06-13 Panasonic Intellectual Property Corporation Of America Information communication device
JP2018078655A (ja) * 2013-11-21 2018-05-17 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 情報通信方法、情報通信装置、およびプログラム
US10177847B2 (en) 2013-11-21 2019-01-08 Panasonic Intellectual Property Corporation Of America Information communication device
CN105723632B (zh) * 2013-11-21 2019-03-22 松下电器（美国）知识产权公司 信息通信方法、装置及计算机可读存储介质

Also Published As

Publication number Publication date
JP5646537B2 (ja) 2014-12-24
JP2013226232A (ja) 2013-11-07

Similar Documents

Publication Publication Date Title
JP5646537B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5436612B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5923411B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5889777B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5551210B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5715615B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP6195093B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
WO2013157396A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム
JP5789233B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
WO2013176002A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム
JP5290460B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5941386B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
WO2013191043A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム
WO2013154020A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲーム制御システム
WO2013094160A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム
JP5395210B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、コミュニケーション装置
JP5731710B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP6206764B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
WO2013111226A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム
JP2015128668A (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
WO2013124932A1 (ja) ゲーム制御装置、ゲーム制御方法、ゲーム制御プログラム、記録媒体、ゲームシステム
JP5839711B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP2014208168A (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP2014147832A (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: 13782373

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: 13782373

Country of ref document: EP

Kind code of ref document: A1