WO2013180242A1 - ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム、コミュニケーション装置 - Google Patents

ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム、コミュニケーション装置 Download PDF

Info

Publication number
WO2013180242A1
WO2013180242A1 PCT/JP2013/065096 JP2013065096W WO2013180242A1 WO 2013180242 A1 WO2013180242 A1 WO 2013180242A1 JP 2013065096 W JP2013065096 W JP 2013065096W WO 2013180242 A1 WO2013180242 A1 WO 2013180242A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
user
requesting user
game
requesting
Prior art date
Application number
PCT/JP2013/065096
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 WO2013180242A1 publication Critical patent/WO2013180242A1/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
    • A63F13/49—Saving the game status; Pausing or ending the 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/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/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
    • 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/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/33—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections
    • A63F13/332—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections using wireless networks, e.g. cellular phone networks
    • 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/50—Controlling the output signals based on the game progress
    • A63F13/53—Controlling the output signals based on the game progress involving additional visual information provided to the game scene, e.g. by overlay to simulate a head-up display [HUD] or displaying a laser sight in a shooting game
    • A63F13/533—Controlling the output signals based on the game progress involving additional visual information provided to the game scene, e.g. by overlay to simulate a head-up display [HUD] or displaying a laser sight in a shooting game for prompting the player, e.g. by displaying a game menu
    • 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/71—Game security or game management aspects using secure communication between game devices and game servers, e.g. by encrypting game data or authenticating players
    • 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/20—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 the game platform
    • A63F2300/206—Game information storage, e.g. cartridges, CD ROM's, DVD's, smart cards
    • 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 technology for controlling the progress of a game by each user according to each operation of a plurality of users, and a technology for performing transmission / reception and sharing of data among a plurality of users.
  • Non-Patent Document 1 a digital card game (Dragon Collection (registered trademark)) described in Non-Patent Document 1 below is known.
  • a conventional social game for example, when a plurality of users cooperate to execute a battle (match), one user (requesting user) requests cooperation from the other user, and the other user (request) When the previous user accepts the request, a cooperative relationship between the two is formed.
  • the requesting user is simply notified that there is a request from the requesting user. In this case, when many similar requests arrive, the requested user may become reluctant to accept the request, and as a result, exchange between users based on the cooperative relationship between the two It was impossible.
  • the present invention has been made in view of the above-described viewpoints, and can provide a game control device, a game control method, a program, a recording medium, a game system, and communication that can be motivated to accept a request from a user by a requested user.
  • An object is to provide an apparatus.
  • a first aspect of the present invention is a game control device.
  • the game control device Accepting means for accepting a request on a game by a user who is a requesting user; Determining means for determining a request destination user who is a request destination of the request; Notification means for notifying the request destination user of the request; Accepting means for accepting acceptance of the request based on information related to the operation input of the requested user; Storage means for storing acceptance information regarding acceptance of the request in a storage device; Comprising When the requesting user accepts the request by the requesting user, the notifying unit changes the requesting user's request notifying mode to the requesting user when the requesting user accepts the request information. change, It is characterized by that.
  • the “information related to operation input” is not limited to information obtained by direct operation input to the game control device, for example, operation input to an external device accessible to the game control device. The information obtained by this may be sufficient.
  • the storage information is stored in the storage device, that is, when the requesting user has accepted the request by the requesting user, The notification mode of the request from the requesting user to the requesting user is changed.
  • the request-destination user can determine that the request is from a requesting user who has accepted his / her request by changing the notification mode of the request.
  • the requesting user can be motivated to accept the request from the requesting user because the requesting user can feel a mission to respond to the request from the requesting user. Therefore, the exchange between users based on the cooperative relationship between the two can be promoted, and the social property can be improved.
  • the acceptance information includes a number of times that the user has accepted at least one request from the request destination user
  • the notification unit is configured to respond to the request destination user according to the number of times.
  • the notification mode of the request source user's request may be changed. For example, as the requesting user accepts at least one request from the requesting user, the requesting user makes the requesting user's request more easily visually or audibly recognized.
  • the notification mode may be changed.
  • the request-destination user determines that the request-source user has received many requests from the request-destination user as the request-source user's request becomes easier to recognize visually or audibly. be able to.
  • the requesting user can increase the sense of mission to respond to the request from the requesting user in order to reward that the requesting user has accepted his request. Thereby, it can be motivated to positively accept the request from the requesting user.
  • the acceptance information includes a contribution indicating the degree of contribution of the requesting user to the request from the requesting user
  • the notifying unit determines the requesting user according to the contribution.
  • the notification mode of the request of the requesting user may be changed. For example, the request notification mode is changed so that the requesting user's request to the requesting user is more easily recognized visually or audibly as the contribution of the requesting user to the requesting user is higher. Also good.
  • the request-destination user determines that the request-source user has a higher contribution to the request from the request-destination user as the request-source user's request becomes easier to recognize visually or audibly. can do.
  • the requesting user in order to reward the contribution of the requesting user, the requesting user can increase the sense of mission to respond to the request from the requesting user. Thereby, it can be motivated to positively accept the request from the requesting user.
  • the acceptance information includes a period from an acceptance time of the request source user to a request from the request destination user to a notification time of the request source user request to the request destination user
  • the notification means May change a notification mode of the request source user's request to the request destination user according to the period. For example, as the period from the acceptance time of the requesting user to the request from the requesting user to the notification time of the requesting user's request to the requesting user is shorter, the requesting user's request to the requesting user is more visually or auditorily.
  • the notification mode of the request may be changed so that it can be easily recognized.
  • the requesting user can receive the requesting user from the requesting user within a short period from the notification time of the request from the requesting user. It can be determined that the user has accepted the request.
  • the request-destination users can request each other within a short period of time, a sense of familiarity with the request-source user can be generated, and thus a sense of mission to respond to the request from the request-source user can be enhanced. Thereby, it can be motivated to positively accept the request from the requesting user.
  • the acceptance information includes an execution state of the game by the request-destination user when the request-source user accepts a request from the request-destination user, and the notification unit is responsive to the execution state.
  • a notification mode of the request source user's request to the request destination user may be changed. For example, when the requesting user accepts the request from the requesting user, the requesting user's request to the requesting user increases as the execution state of the game by the requesting user is delayed (the game is not progressing).
  • the notification mode of the request may be changed so that it can be recognized more visually or audibly.
  • the requesting user can more easily recognize the request of the requesting user visually or audibly than the requesting user from the requesting user when the execution state of the game by the requesting user is delayed. It can be determined that the user has accepted the request. In this case, the requesting user has a sense of mission to respond to the request from the requesting user in order to reward that the requesting user has accepted his request when the game execution status has been delayed. Can be increased. Thereby, it can be motivated to positively accept the request from the requesting user.
  • the acceptance information includes a degree of contribution indicating a degree of contribution of the requesting user to a request from the requesting user
  • the notifying unit sends a request from the requesting user to the requesting destination.
  • the requesting user may be notified of the degree of contribution.
  • the request destination user can specifically recognize the contribution degree of the request source user to the request from the request destination user. Therefore, the requesting user can further increase the sense of mission to respond to the request from the requesting user in order to reward the contribution of the requesting user. Thereby, it can be motivated to accept the request from the requesting user more actively.
  • the notification unit may change a request notification mode for the request destination user based on the acceptance information when there are a plurality of request source users who request the request destination user. You may change for every user.
  • the request-destination user can determine, for example, a request having a high priority for the request-destination user among requests from a plurality of request-source users based on the request notification form of each request-source user.
  • the request may be made in order for the requesting user to obtain an advantageous effect on the game.
  • the “advantageous effect on the game” may be, for example, an increase in the parameter of the item that the user holds in the game, or an improvement in the character's ability without using the item. Alternatively, the user may be able to obtain a special item.
  • the “advantageous effect on the game” may be to adjust the setting so as to facilitate the progress of the scenario in the game, for example, points on the game that are consumed according to the user's operation, etc. It may be that the amount of consumption is reduced more than usual, or that the points can be obtained.
  • the “advantageous effect on the game” may be an adjustment of the setting on the game so that the game can be advantageously promoted indirectly.
  • the user can acquire a special item.
  • An event may be generated, or a probability that the parameter of the item is significantly increased may be increased.
  • the requesting user advances the game advantageously. I can feel that I was able to cooperate. For this reason, it is possible for the request destination user to enhance the sense of achievement obtained when the request is granted.
  • a second aspect of the present invention is a game control method.
  • the game control method is as follows: Receiving a game request by a user who is a requesting user; Determining a request-destination user who is a request destination of the request; Notifying the requesting user of the request; Accepting acceptance of the request based on information related to the operation input of the requested user; Storing acceptance information on acceptance of the request in a storage device; With In the step of notifying the request, if acceptance information when the requesting user accepts the request by the requesting user is stored in the storage device, a request of the requesting user to the requesting user is received. Change the notification mode.
  • a third aspect of the present invention relates to a computer.
  • 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, Accepting means for accepting a request on a game by a user who is a requesting user; A determination means for determining a request destination user who is a request destination of the request; A notification means for notifying the request destination user of the request; Accepting means for accepting acceptance of the request based on information related to the operation input of the request destination user; Storage means for storing acceptance information regarding acceptance of the request in a storage device; Each means is provided in either one of the communication terminal or the server, When the requesting user accepts the request by the requesting user, the notifying unit changes the requesting user's request notifying mode to the requesting user when the requesting user accepts the request information. change.
  • 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.
  • a sixth aspect of the present invention is a communication device.
  • the communication device An accepting means for accepting a request by a user who is a requesting user; Determining means for determining a request destination user who is a request destination of the request; Notification means for notifying the request destination user of the request; Accepting means for accepting acceptance of the request based on information related to the operation input of the requested user; Storage means for storing acceptance information regarding acceptance of the request in a storage device; Comprising When the requesting user accepts the request by the requesting user, the notifying unit changes the requesting user's request notifying mode to the requesting user when the requesting user accepts the request information. change, It is characterized by that.
  • 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 block diagram which shows the structure of the communication terminal of embodiment The block diagram which shows the structure of the game server of embodiment.
  • the figure which illustrates a series of web pages displayed in a user's communication terminal The figure which illustrates a series of web pages displayed in a user's communication terminal.
  • the present invention relates to a patent application of Japanese Patent Application No. 2012-124112 filed with the Japan Patent Office on May 31, 2012, the contents of which are incorporated herein by reference.
  • a gaming service which is an example of a communication service is provided to a communication terminal owned by a user
  • the communication service is not limited to the gaming service, and for example, transmission / reception and sharing of data (for example, text data such as comments and messages, image data, audio data, etc.) via a network among a plurality of users. Any service can be used.
  • 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 has a program for generating a document that can be interpreted on a web browser as a game program.
  • 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 that can display a web page provided by the game server 20, and the user executes the game application by performing an operation on 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 each 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.
  • buttons or the like are displayed on the web page
  • the user selects one hyperlink or menu that is actively displayed (for example, highlighted), for example. This is provided to instruct the CPU 11 to do so.
  • these 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 can be realized by a general-purpose storage such as a large-capacity hard disk device or a storage device such as RAID (Redundant Arrays 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. As shown in FIG. 5, 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 is used.
  • the game according to the present embodiment is configured such that a support request can be made when a user loses in a battle with a monster character.
  • the requesting user when another user (requested user) who is the request destination of the support request accepts the support request, the requesting user becomes a monster instead of the support requesting user (hereinafter referred to as the requesting user). It is configured to support the requesting user by performing a battle with the character.
  • 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, for example.
  • User name / display image A user name and a display image that are displayed to identify the user of the communication terminal 10 when the game is executed.
  • the user name is text of a predetermined length or less that is designated in advance by the user, for example, 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.
  • Lv1 level 1
  • Lv100 level 100
  • -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.
  • -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), a request acceptance list, and the like based on 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 request acceptance list is a list in which acceptance information regarding acceptance of requests is sequentially written.
  • FIG. 8 is a diagram illustrating a data configuration example of the request acceptance list.
  • the request acceptance list illustrated in FIG. 8 for each user ID of the requesting user who requested the support, the battle opponent (monster character) of the battle when the support request is made, the remaining HP of the battle opponent, and the request source The user ID of the request-destination user who accepted the request from the user, and the acceptance date and time when the request-destination user accepted the request are written.
  • the remaining HP indicates the latest HP value of the corresponding monster character. For example, when HP is reduced in one or more battles, the reduced HP is written in the request acceptance list.
  • the support request for the battle can be made to another user. 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 a user in a battle and an attack power of a battle opponent's monster character. For example, a condition that a difference in attack power between a warrior card and a monster character has a certain value may be used.
  • 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 14 are diagrams showing examples of web pages displayed on the communication terminal 10 when the battle process is executed.
  • a support request from a user “ABC” hereinafter referred to as user: ABC
  • XYZ hereinafter referred to as user: XYZ
  • 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.
  • step S1 of FIG. 9 the web page is updated as shown in step S1 of FIG.
  • a menu m11 labeled “battle start” is displayed on the web page in step S1.
  • step S1 when the menu m11 is selected by the user: ABC, 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 menu m12 is selected and operated, 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 MC1 decreases due to 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 MC1 sequentially attacks the ten warrior cards.
  • the card is 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 MC1 does not become zero and all ten warrior cards of the user: ABC are defeated (defeated)
  • the web page is updated as shown in step S5 of FIG. If the battle is defeated, the monster character MC1 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 becomes a support requesting user.
  • menu m13 is selected, a battle with another monster character may be performed. In this case, it is updated to the web page of step S1 on which an image of another monster character (for example, monster character MC2) is displayed.
  • another monster character for example, monster character MC2
  • step S5 When the user: ABC selects and operates the menu m13 on the web page in step S5, the request destination user as the request destination of the support request is determined, and the request source user (here) is displayed on the communication terminal 10 of the determined request destination user. Then, a message for confirming whether or not to accept the support request from the user (ABC) is displayed.
  • An example of the web page for the user: XYZ determined as the request destination user is shown in step S6 of FIG. On the web page in step S6, a menu m14 labeled “Accept” and a menu m15 labeled “Do Not Accept” are displayed to prompt selection of whether to accept the support request. .
  • step S6 When the menu m14 (“Accept”) is selected on the web page in step S6, the web page is updated as shown in step S7 in FIG. 13, and the user: XYZ owns a predetermined number (in the figure) Using the 10 warrior cards 202 in the example, a transition is made to a screen for performing a battle with the monster character MC1 who is a 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).
  • Monster character MC's HP) value When the menu m14 (“Accept”) is selected on the web page in step S6, the web page is updated as shown in step S7 in FIG. 13, and the user: XYZ owns a predetermined number (in the figure)
  • the web page of step S7 has the same format as the web page of step S2 of
  • the number of wins of each of user: ABC and user: XYZ may be increased by one.
  • the HP of the monster character MC1 does not become zero and all ten warrior cards of the user: XYZ are defeated (defeated)
  • the user XYZ who is the requested user loses the battle requested for support, the user XYZ who is the requested user battles the opponent of the battle for which the support is requested (in this case, the monster character MC1). You may be able to make a support request for the target. In this case, since the processing may be complicated, it is preferable that the request-destination user not be able to make a support request for the battle opponent as a target of the battle when defeated in the support-requested battle. . In this case, the request source user does not change as the user: ABC, and the new request destination user accepts the support request from the user: ABC and performs a battle.
  • step S8 of FIG. 14 is displayed on the communication terminal 10 of the user: XYZ.
  • the example of the web page in step S8 has the same format as the web page in step S5 in FIG. 12, and indicates that the user: XYZ has been defeated in the battle with the monster character (monster character MC2 in the example in the figure). Yes.
  • the menu m13 is selected and operated, the user: XYZ becomes a support request source user.
  • a request destination user is determined, and the request source user (here, user: XYZ) is displayed on the communication terminal 10 of the determined request destination user.
  • a message for confirming whether or not to accept the support request is displayed.
  • a web page for the user: ABC when the user: ABC is determined as the requested user is shown in step S9 of FIG.
  • the web page in step S9 is configured so that the format is different from the web page in step S6 in FIG. 13 (the request notification mode is different).
  • a message notifying that the user: XYZ is a user who has accepted a request from the user: ABC in the past is displayed larger than other texts.
  • the requesting user: ABC determines that the request is from the requesting user (user: XYZ) who has accepted the request by changing the request notification mode. be able to.
  • the user: ABC can be motivated to accept the request from the user: XYZ because it can generate a sense of mission to respond to the request from the user: XYZ.
  • the game control device is an example of the “communication device” in the present invention.
  • the game server 20 and the database server 30 constitute a game control device.
  • functions implemented by the game control device of the present embodiment will be described with reference to FIG. 15, taking as an example the case where the above-described competitive digital card game is applied.
  • FIG. 15 is a functional block diagram for explaining functions that play a major role in the game control apparatus of the present embodiment.
  • the accepting means 53, the determining means 54, the notifying means 55, the accepting means 56, and the storage means 57 correspond to the main configuration of the present invention.
  • menus, marks, and the like displayed on the web page displayed on the communication terminal 10 are arranged at desired positions on the web page, and are menus visually recognized on the communication terminal 10. The position on the display screen of the mark and the like can be changed by scrolling the web page by the user's direction instruction button or touch panel operation.
  • the registration unit 51 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 registration means 51 may be provided with the function which relates users. Specifically, the registration unit 51 may register the user ID in association with another user ID triggered by an application based on the user ID. That is, the registration unit 51 registers another user ID as a “mate” with an application based on the user ID as a trigger.
  • the function of the registration means 51 in this case is realized as follows, for example.
  • the CPU 21 of the game server 20 sends an application message (application) specifying a user ID (or a corresponding display name) that the user wants to become a friend from the communication terminal 10 of the user corresponding to a certain user ID via the communication interface unit 25. Accept. Transmission of this application message is preset as a function of a web page provided to the user's communication terminal 10.
  • the CPU 21 approves an application based on another user ID to the communication terminal 10 corresponding to the user ID at the timing when the access is based on the user ID included in the application message. HTML data for displaying a web page for requesting the reply is transmitted. If it is replied that the application is approved, the CPU 21 registers both as friends. Specifically, the CPU 21 accesses the user data of the corresponding two user IDs in the user database 31 and writes the data in the location of “friend user” (see FIG. 6). Note that the conditions for relating users are not limited to the forms that require application and approval as described above, and the user who performs the stage on the same game or the user who performed the battle is related to the user in the game.
  • 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). For example, when 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 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 battle execution means 52 is not an essential component of the present invention, but is a component for making the present invention more preferable.
  • the battle execution means 52 may execute a battle on the game by sequentially updating the 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 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.
  • the CPU 21 recognizes the selection operation of the menu m14 (“Accept”) from the request destination user, the CPU 21 executes a battle process between the request destination user and the monster character in the battle to be requested. Specifically, the CPU 21 generates HTML data so that the requested user can perform an attack operation on the monster character in the requested battle, and transmits the HTML data to the communication terminal 10 of the requested user (for example, , See the web page of step S7 in FIG. 13).
  • 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 acceptance list.
  • the CPU 21 writes the remaining HP value written in the request acceptance list into the RAM 23.
  • 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”.
  • attack operation For example, if 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.
  • HP before attack is denoted as HPb
  • HP after attack is denoted as HPa.
  • HPa HPb ⁇ 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 uses only one warrior card in battle, the user loses when the warrior card is defeated. When a plurality of warrior cards participate in the battle, 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 may be determined that the monster character has not been defeated (defeated).
  • 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 receiving means 53 has a function of receiving a request on the game by the requesting user.
  • the “request on the game” may be anything as long as it is made for the necessity in the game, such as a support request in battle processing (match) or an item exchange between users. However, for example, it may be performed for the user who makes the request to obtain an advantageous effect on the game.
  • the requesting user can obtain an advantageous effect on the game that when the requesting user wins the battle in the support request, the number of victory of the requesting user increases by one. For example, when the requesting user accepts the request so that the requesting user can obtain an advantageous effect on the game, the requesting user advances the game advantageously. I can feel that I was able to cooperate.
  • the advantageous effect on the game may be, for example, increasing the parameter of the item held by the user on the game, or improving the ability of the character (for example, a warrior card) without using the item. It may be that the user can obtain a special item. Furthermore, the advantageous effect on the game may be that the setting is adjusted so that the scenario progresses easily in the game, for example, consumption of points on the game to be consumed according to the user's operation or the like. The amount may be reduced more than usual, or the point may be available.
  • the advantageous effect on the game may be that the setting on the game is adjusted so that the game can be advantageously promoted indirectly, for example, an event that allows the user to acquire a special item. It may be generated, or may be to increase the probability that the parameter of the item will increase significantly.
  • the function of the accepting means 53 is realized as follows, for example.
  • the CPU 21 of the game server 20 recognizes the user who performed the selection operation (here, user: ABC) as the user who requested the support request.
  • the user ID of the user (user: ABC) is stored in the RAM 23.
  • the CPU 21 recognizes the user who performed the selection operation (here, user: XYZ) as the requesting user of the support request, and
  • the user ID of the user (user: XYZ) is stored in the RAM 23.
  • the determination unit 54 has a function of determining a request destination user that is a request destination of the request.
  • the function of the determination means 54 is implement
  • the CPU 21 of the game server 20 accesses the user database 31 when the user ID of the requesting user of the support request is stored in the RAM 23, and at least one user ID from among the plurality of user IDs in the user database 31. To extract. Then, the CPU 21 determines a user corresponding to the extracted user ID as a request destination user. The extracted user ID is stored in the RAM 23.
  • the user ID extraction method may be random or based on a predetermined rule, for example.
  • the request destination user may be, for example, a friend of the request source user.
  • the notification means 55 has a function of notifying the request destination user of the request.
  • the function of the notification means 55 is implement
  • the CPU 21 of the game server 20 determines the request destination user
  • the CPU 21 refers to the request acceptance list and determines whether the request source user has accepted the request by the request destination user. More specifically, when the user: XYZ is determined as the requesting user of the support request from the user: ABC, the CPU 21 records the user ID of the user: XYZ in the user ID of the requesting user, and the user : It is determined whether or not the acceptance information recorded in the user ID of the request destination user whose ABC user ID has accepted the request is stored in the request acceptance list.
  • the CPU 21 determines that the requesting user (user: ABC) has not accepted the request by the request destination user (user: XYZ). On the other hand, when the acceptance information is stored in the request acceptance list, the CPU 21 determines that the requesting user (user: ABC) has accepted the request by the request destination user (user: XYZ).
  • the acceptance information is not stored in the request acceptance list, that is, the request source user (user: ABC) has not accepted the request by the request destination user (user: XYZ). This will be explained as a premise.
  • the CPU 21 determines that the requesting user (user: ABC) has not accepted the request by the requesting user (user: XYZ)
  • the CPU 21 displays HTML data for displaying the web page exemplified in step S6 of FIG. Generated and transmitted to the communication terminal 10 of the requested user (user: XYZ).
  • the timing when the web page shown in step S6 is displayed on the communication terminal 10 of the user: XYZ is, for example, from the requesting user (user: ABC) when the user: XYZ is playing a game. It may be almost the same as the timing at which the request is received, or when the user: XYZ is not playing the game, it may be the timing at which the user: XYZ has started playing the game.
  • the notification means 55 is a function for changing the notification mode of the request source user's request to the request destination user when acceptance information when the request source user accepts the request by the request destination user is stored in the storage device. Is provided.
  • the CPU 21 of the game server 20 determines the request destination user
  • the CPU 21 accesses the storage device in which the game database 32 is configured, and the request acceptance list in the game database 32.
  • the user: ABC is determined as the request destination user of the support request from the user: XYZ
  • the request source user (user: XYZ) has accepted the request by the request destination user (user: ABC).
  • the user: ABC is determined as the request destination user of the support request from the user: XYZ
  • the user ID of the user: ABC is recorded in the user ID of the requesting user
  • the user: The acceptance information recorded in the user ID of the requested user whose XYZ user ID has accepted the request is stored in the request acceptance list.
  • the CPU 21 determines that the requesting user (user: XYZ) has accepted the request by the requesting user (user: ABC)
  • the CPU 21 displays HTML data for displaying the web page exemplified in step S9 of FIG. Generated and transmitted to the communication terminal 10 of the request destination user (user: ABC).
  • the point of notification of the request on the web page shown in step S9 is different from the web page shown in step S6 as described above.
  • the timing at which the web page shown in step S9 is displayed on the communication terminal 10 of the user: ABC may be the same as the timing at which the web page shown in step S6 described above is displayed.
  • the requesting user (user: XYZ) includes a message notifying that the requesting user (user: ABC) has accepted the request from the requesting user (user: ABC) in the web page, thereby notifying the support request.
  • the mode of changing the notification of the support request is not limited to this.
  • the font type, size, or color of the text that constitutes the web page is different from that of a web page for notifying a normal support request (for example, the web page in step S6). It may be changed.
  • a web page for notifying a normal support request when a web page for notifying a normal support request includes a still image, when the notification mode of the support request is changed, the image is a moving image (for example, the color of the still image is changed). ).
  • the audio data may be changed when the notification mode of the support request is changed.
  • the display name of the requesting user is displayed in text, but when changing the notification mode of the support request, the display name of the requesting user is displayed, for example, with an icon or the like. Also good.
  • the web page for notifying a normal support request is configured with a predetermined background color, the background color may be changed when the support request notification mode is changed.
  • the accepting unit 56 has a function of accepting acceptance of a request based on information related to the operation input of the request destination user.
  • the “information related to operation input” is not limited to information obtained by direct operation input to the game control device, for example, operation input to an external device accessible to the game control device. The information obtained by this may be sufficient.
  • the function of the acceptance means 56 is implement
  • the CPU 21 recognizes the user who performed the selection operation (here, user: ABC) as the request-destination user who accepted the support request. Then, the user ID of the request destination user (user: ABC) is stored in the RAM 23.
  • the storage unit 57 has a function of storing acceptance information regarding acceptance of a request in a storage device.
  • storage means 57 is implement
  • the CPU 21 of the game server 20 stores the user ID of the request-source user stored in the RAM 23, the monster character of the battle opponent, and the remaining HP of the monster character.
  • acceptance information including the user ID of the request-destination user who accepted the support request and the date and time of acceptance of the request is generated.
  • the request acceptance date and time may be, for example, the date and time when the request destination user selects and operates the menu m14.
  • the CPU 21 accesses the storage device in which the game database 32 is configured, and records the acceptance information in a request acceptance list in the game database 32.
  • FIG. 16 shows battle processing with a monster character performed by the game control device of the present embodiment.
  • the user: ABC executes the battle process will be described as an example.
  • step S100 YES
  • CPU21 produces
  • step S106 When it is recognized that the selection operation of the menu m12, that is, the attack instruction operation is performed on the web page in step S2 (step S104: YES), the CPU 21 performs a battle process with the monster character (step S106).
  • This battle process is executed based on user: ABC user data and monster character data.
  • an attack is performed on the monster character from the user: ABC's own warrior card (user's warrior card and fellow warrior card), thereby reducing the monster character's HP.
  • the scale of the HP gauge 201 on the web page is reduced.
  • the monster character attacks the warrior card held by the user: ABC in response to an attack instruction operation or at random timing, thereby defeating one or more warrior cards. May be.
  • the scale of the HP gauge 201 is changed or the warrior card is defeated, for example, as shown in step S3 of FIG. 11, web pages are sequentially updated.
  • step S108 determines whether or not the battle with the monster character has ended. This determination can be made as appropriate. For example, it may be determined that the battle has ended when a certain number of attack instruction operations have been performed, or when a certain amount of time has elapsed since the first attack instruction operation, or the HP of the monster character becomes zero. Or when the user: ABC's own warrior card is all defeated (defeated), it may be determined that the battle has ended. If it is determined that the battle with the monster character has ended (step S108: YES), the process proceeds to step S110. If it is determined that the battle with the monster character has not ended (step S108: NO), the process returns to step S104, and the next attack instruction operation can be accepted.
  • step S112 the CPU 21 accesses the user database 31 and increments the number of wins corresponding to the user ID of the user: ABC by one (step S114).
  • step S110: NO the CPU 21 generates HTML data for displaying the web page shown in step S5 of FIG. To the communication terminal 10 (step S116).
  • step S118: YES the CPU21 performs the request process mentioned later (step S120).
  • FIG. 17A is a sequence chart illustrating an example of a request process when a support request is made by a user: ABC.
  • the CPU 21 of the game server 20 receives the user who performed the selection operation (here, user: (ABC) is recognized as the requesting user of the support request, and the user ID of the user (user: ABC) is stored in the RAM 23.
  • the CPU 21 accesses the user database 31 and extracts at least one user ID from a plurality of user IDs in the user database 31.
  • the CPU 21 determines a user corresponding to the extracted user ID as a request destination user (step S202).
  • the user: XYZ is determined as the requested user.
  • the CPU 21 refers to the request acceptance list to determine whether or not the request source user has accepted the request by the request destination user (step S204). More specifically, the CPU 21 accepts the user: XYZ user ID recorded in the user ID of the requesting user and the user: ABC user ID recorded in the user ID of the requested user who accepted the request. It is determined whether the information is stored in the request acceptance list.
  • the description will be made on the assumption that the request source user (user: ABC) has not accepted the request by the request destination user (user: XYZ).
  • the CPU 21 determines that the requesting user (user: ABC) has not accepted the request by the requesting user (user: XYZ)
  • the CPU 21 displays HTML data for displaying the web page exemplified in step S6 of FIG. It is generated and transmitted to the communication terminal 10 of the requested user (user: XYZ) (step S206).
  • the CPU 21 When the menu m14 (“accept”) is selected and operated by the user: XYZ on the web page in step S6 and the support request is accepted (step S208), the CPU 21 performs the selection operation of the menu m14.
  • the user (user: XYZ) is recognized as the request destination user who accepted the support request, and the user ID of the request destination user (user: XYZ) is stored in the RAM 23.
  • the CPU 21 accepts information including the user ID of the requesting user stored in the RAM 23, the monster character of the battle partner, the remaining HP of the monster character, the user ID of the requesting user who accepted the support request, and the request acceptance date and time. Is generated.
  • CPU21 accesses the memory
  • requested user user: XYZ
  • the flow of the battle process performed by the user: XYZ may be the same as the flow of FIG.
  • FIG. 17B is a sequence chart illustrating an example of a request process when a support request is made by a user: XYZ.
  • the user: XYZ is defeated in the battle with the monster character (step S110: NO in the flow of FIG. 16), so that the web page shown in step S8 of FIG. 14 is displayed on the communication terminal 10 of the user: XYZ. It is assumed that
  • the CPU 21 of the game server 20 receives the user who performed the selection operation (here, user: XYZ) is recognized as the requesting user of the support request, and the user ID of the user (user: XYZ) is stored in the RAM 23.
  • the CPU 21 accesses the user database 31 and extracts at least one user ID from a plurality of user IDs in the user database 31.
  • the CPU 21 determines a user corresponding to the extracted user ID as a request destination user (step S222).
  • the user: ABC is determined as the request destination user.
  • the request source user here, user: XYZ
  • the request destination user here, user: ABC
  • the request acceptance list Whether or not (step S224).
  • the user ID of the user: ABC is recorded in the user ID of the requesting user
  • the user ID of the request destination user that the user ID of the user: XYZ has accepted the request.
  • the acceptance information recorded in the request acceptance list is stored in the request acceptance list. Therefore, the CPU 21 determines that the requesting user has accepted the request from the requesting user.
  • step S226 If the CPU 21 determines that the requesting user has accepted the request from the requesting user, the CPU 21 generates HTML data for displaying the web page exemplified in step S9 in FIG. 14 (step S226). Note that the web page shown in step S9 is generated so that the notification mode of the request is different from the web page shown in step S6. Then, the CPU 21 transmits the generated HTML data to the communication terminal 10 of the request destination user (user: ABC) (step S228).
  • the acceptance information is stored in the storage device. That is, when the user: XYZ has accepted the request by the user: ABC, the notification mode of the request from the user: XYZ to the user: ABC is changed.
  • the user: ABC can determine that the request is from the user XYZ who has accepted the request by changing the notification mode of the request.
  • the user: ABC can be motivated to accept the request from the user: XYZ because it may cause a desire to respond to the request from the user: XYZ. Therefore, the exchange between users based on the cooperative relationship between the two can be promoted, and the social property can be improved.
  • the acceptance information includes the number of times the requesting user has accepted at least one request from the requesting user, and the notifying unit 55 determines the requesting user for the requesting user according to the number of times.
  • the notification mode of the request may be changed. For example, as the requesting user accepts at least one request from the requesting user, the requesting user makes the requesting user's request more easily visually or audibly recognized.
  • the notification mode may be changed.
  • the request-destination user determines that the request-source user has received many requests from the request-destination user as the request-source user's request becomes easier to recognize visually or audibly. be able to.
  • the requesting user can increase the sense of mission to respond to the request from the requesting user in order to reward that the requesting user has accepted his request. Thereby, it can be motivated to positively accept the request from the requesting user.
  • the function of the notification means 55 is implement
  • a case where the user: ABC is the request destination user and the user: XYZ is the request source user will be described as an example.
  • the CPU 21 of the game server 20 determines that the user: ABC is the requested user, the CPU 21 refers to the request acceptance list in the game database 32 and counts the number of times the user: XYZ is accepted for at least one request from the user: ABC. .
  • the number of times of accepting the user: XYZ is obtained, for example, by counting the number of acceptance information in which the user: XYZ is recorded as the requested user among the acceptance information recorded as the requesting user: the user: ABC. May be.
  • the CPU 21 when the CPU 21 generates HTML data for displaying a web page for notifying the request from the user: XYZ to the user: ABC, for example, as the number of times of acceptance of the user: XYZ increases, the user: XYZ
  • the web page is structured so that the request is easily recognized visually or audibly. For example, the larger the number of times of accepting the user: XYZ, the larger the font of the text displayed on the web page, or the larger the size of the menu m14.
  • the acceptance information includes a contribution indicating the degree of contribution of the requesting user to the request from the requested user
  • the notifying unit 55 requests the user for the requested user according to the contribution.
  • the notification mode may be changed.
  • the request notification mode is changed so that the requesting user's request to the requesting user is more easily recognized visually or audibly as the contribution of the requesting user to the requesting user is higher. Also good.
  • the request-destination user determines that the request-source user has a higher contribution to the request from the request-destination user as the request-source user's request becomes easier to recognize visually or audibly. can do.
  • the requesting user in order to reward the contribution of the requesting user, the requesting user can increase the sense of mission to respond to the request from the requesting user. Thereby, it can be motivated to positively accept the request from the requesting user.
  • a request acceptance list shown in FIG. 18 may be stored in the game database 32.
  • the request acceptance list shown in FIG. 18 is different from the request acceptance list of FIG. 8 in that a contribution is included for each piece of acceptance information.
  • the contribution may be the number of attacks on the monster character in one battle process (that is, the number of selections of the menu m12) or one battle. It may be the total damage given to the monster character in the process. Note that the number of attacks on the monster character, the total damage given to the monster character, and the like may be stored in the RAM 23 by the function of the battle execution means 52.
  • the CPU 21 of the game server 20 stores the user ID of the requesting user stored in the RAM 23, the monster character of the battle opponent, and the monster character's Acceptance information including the remaining HP, the user ID of the request destination user, the request acceptance date and time, and the contribution level is generated. Then, the CPU 21 records the generated acceptance information in the request acceptance list.
  • the function of the notification means 55 in this modification is realizable as follows, for example. Here, a case where the user: ABC is the request destination user and the user: XYZ is the request source user will be described as an example.
  • the CPU 21 of the game server 20 determines that the user: ABC is the requested user, the CPU 21 refers to the request acceptance list in the game database 32 and extracts the contribution of the user: XYZ to the request from the user: ABC. Then, when the CPU 21 generates HTML data for displaying a web page for notifying the request from the user: XYZ to the user: ABC, the higher the contribution degree of the user: XYZ, the higher the contribution from the user: XYZ.
  • the web page may be configured to make the request easier to recognize visually or audibly.
  • the menu m14 may be configured to have a large size.
  • the acceptance information includes a period from the acceptance time of the requesting user to the request from the requesting user to the notification time of the requesting user's request to the requesting user, and the notifying unit corresponds to the period.
  • the notification mode of the request of the request source user to the request destination user may be changed. For example, as the period from the acceptance time of the requesting user to the request from the requesting user to the notification time of the requesting user's request to the requesting user is shorter, the requesting user's request to the requesting user is more visually or auditorily.
  • the notification mode of the request may be changed so that it can be easily recognized.
  • the requesting user can receive the requesting user from the requesting user within a short period from the notification time of the request from the requesting user. It can be determined that the user has accepted the request.
  • the request-destination users can request each other within a short period of time, a sense of familiarity with the request-source user can be generated, and thus a sense of mission to respond to the request from the request-source user can be enhanced. Thereby, it can be motivated to positively accept the request from the requesting user.
  • the function of the notification means 55 in this modification is realizable as follows, for example.
  • a case where the user: ABC is the request destination user and the user: XYZ is the request source user will be described as an example.
  • the CPU 21 of the game server 20 refers to the request acceptance list in the game database 32, and there is acceptance information indicating that the user: XYZ has accepted the request from the user: ABC. If so, the user: XYZ acceptance time is extracted from the acceptance information. Then, when the CPU 21 generates HTML data for displaying a web page for notifying the request from the user: XYZ to the user: ABC, for example, until the generation of HTML data from the acceptance time of the user: XYZ.
  • the web page may be configured so that the request from the user: XYZ becomes easier to recognize visually or audibly as the elapsed time of is shorter.
  • it may be configured such that the shorter the elapsed time from the acceptance time of the user: XYZ to the generation of HTML data, the larger the font of the text displayed on the web page, or the larger the size of the menu m14 You may be comprised so that it may become.
  • the acceptance information includes a game execution status by the request-destination user when the request-source user accepts the request from the request-destination user, and the notification unit 55 determines the request-destination user according to the execution status.
  • the notification mode of the request of the requesting user may be changed. For example, when the requesting user accepts the request from the requesting user, the requesting user's request to the requesting user increases as the execution state of the game by the requesting user is delayed (the game is not progressing). The notification mode of the request may be changed so that it can be recognized more visually or audibly.
  • the requesting user can more easily recognize the request of the requesting user visually or audibly than the requesting user from the requesting user when the execution state of the game by the requesting user is delayed. It can be determined that the user has accepted the request. In this case, the requesting user has a sense of mission to respond to the request from the requesting user in order to reward that the requesting user has accepted his request when the game execution status has been delayed. Can be increased. Thereby, it can be motivated to positively accept the request from the requesting user.
  • a request acceptance list shown in FIG. 19 may be stored in the game database 32.
  • the request acceptance list shown in FIG. 19 is different from the request acceptance list in FIG. 8 in that for each of a plurality of pieces of acceptance information, the execution state of the game by the requesting user when the requesting user accepts the request is included.
  • the execution status of the game by the requesting user may be a progress status until the requesting user gains victory in the battle with the monster character, taking the game of this embodiment as an example. It may be the number of battles won by the user.
  • the game execution status may be set based on, for example, execution status data illustrated in FIG.
  • the condition corresponding to the situation is data set in advance.
  • the execution status of “I am struggling” indicates that the execution status of the game is delayed compared to the execution status of “I am marginal”.
  • the conditions corresponding to each execution situation can be set arbitrarily. For example, when a predetermined amount of points is consumed from the points held by the requesting user in order to perform one battle with the monster character, the requesting user has more points than the predetermined amount.
  • the execution status data may be stored in the game database 32.
  • the CPU 21 of the game server 20 accepts the requesting user's user ID, the battle partner's monster character, the remaining HP of the monster character, and the support request in step S210 of the sequence of FIG. 17A, for example.
  • the acceptance information including the user ID of the requested user, the acceptance date and time of the request, and the game execution status by the requesting user when the requesting user accepts the request is generated.
  • the CPU 21 may set the game execution status by the requesting user with reference to, for example, the execution status data shown in FIG.
  • the attack power of the warrior card participating in the battle may be a value recorded in the data of the possessed card in the user data of the requesting user, for example.
  • FIG. 20 the example of FIG.
  • the monster character's HP may be, for example, the remaining HP stored in the RAM 23.
  • the CPU 21 records the generated acceptance information in the request acceptance list in the game database 32.
  • the function of the notification means 55 in this modification is realizable as follows, for example.
  • a case where the user: ABC is the request destination user and the user: XYZ is the request source user will be described as an example.
  • the CPU 21 of the game server 20 refers to the request acceptance list in the game database 32, and there is acceptance information indicating that the user: XYZ has accepted the request from the user: ABC.
  • the game execution status by the user: ABC is extracted from the acceptance information.
  • the CPU 21 when the CPU 21 generates HTML data for displaying a web page for notifying the request from the user: XYZ to the user: ABC, for example, the execution status of the game by the user: ABC has been delayed.
  • User: The web page may be configured so that a request from XYZ can be recognized more visually or audibly. For example, as the game execution state by the user: ABC is delayed, the font of the text displayed on the web page may be increased, or the size of the menu m14 may be increased. Also good.
  • FIG. 21 an example of a web page displayed on the communication terminal 10 of the user: ABC is shown in FIG. In the web page illustrated in FIG. 21, for example, when the user: XYZ who is the requesting user has an execution state that the execution state of the game by the user: ABC is “striking”, the user: ABC A message notifying that the user has accepted the support application may be included.
  • the acceptance information includes a contribution indicating the degree of contribution of the requesting user to the request from the requesting user
  • the notifying unit 55 notifies the requesting user of the request from the requesting user.
  • the requesting user may be notified of the degree of contribution.
  • the request destination user can specifically recognize the contribution degree of the request source user to the request from the request destination user. Therefore, the requesting user can further increase the sense of mission to respond to the request from the requesting user in order to reward the contribution of the requesting user. Thereby, it can be motivated to accept the request from the requesting user more actively.
  • a request acceptance list shown in FIG. 18 may be stored in the game database 32.
  • the function of the notification means 55 in this modification is realizable as follows, for example.
  • a case where the user: ABC is the request destination user and the user: XYZ is the request source user will be described as an example.
  • the CPU 21 of the game server 20 determines that the user: ABC is the requested user, the CPU 21 refers to the request acceptance list in the game database 32 and extracts the contribution of the user: XYZ to the request from the user: ABC.
  • the CPU 21 configures the web page to include the contribution degree of the user: XYZ when generating HTML data for displaying the web page for notifying the user: ABC of the request from the user: XYZ. May be.
  • a display example of the web page is shown in FIG.
  • the web page illustrated in FIG. 22 includes, for example, a message for notifying the user: XYZ's contribution to the request from the user: ABC (in the illustrated example, the total amount of damage given to the monster character).
  • the contribution portion may be a larger display change than the other portions (for example, only the contribution portion is further enlarged and displayed).
  • the notification unit 55 changes the notification mode of the request to the request destination user for each of the plurality of users based on the acceptance information when there are a plurality of request source users who request the request destination user. May be.
  • the request-destination user can determine, for example, a request having a high priority for the request-destination user among requests from a plurality of request-source users based on the request notification form of each request-source user.
  • the function of the notification means 55 in this modification is realizable as follows, for example.
  • a case where the user: ABC is a request destination user will be described as an example.
  • the CPU 21 of the game server 20 refers to the request acceptance list in the game database 32 when the user: ABC is determined as a request destination user of requests from a plurality of requesting users, for example, and responds to requests from the user: ABC. It is determined for each of a plurality of requesting users whether there is acceptance information indicating that the requesting user has accepted. And CPU21 produces
  • the web page may be configured such that the request from the requesting user becomes easier to recognize visually or audibly as the requesting user accepts the request from ABC.
  • FIG. 23 an example of the web page displayed on the communication terminal 10 of user: ABC is shown in FIG.
  • a message including the display name of the requesting user is displayed larger as the requesting user accepts the request from the user: ABC more frequently.
  • the larger the number of times the request source user accepts the request from the user: ABC the larger the size of the menu m14 labeled “accept” corresponding to the request source user may be formed.
  • a game control device which is an example of a communication device, executes a game
  • the present invention is not limited to this and can be applied to any communication device.
  • data for example, text data such as comments and messages, image data, audio data, etc.
  • the configuration of the present invention is preferably applied. Can do.
  • the request from the requesting user is notified to the requesting user according to the number of times the requesting user has accepted the request made by the requesting user in the past, The notification mode of the request may be changed.
  • 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.
  • games such as role playing games, table games, puzzle games, sports games, racing games, shooting games, action games, adventure games, simulation games, etc.
  • requests from users to other users In the case where it is configured to notify and accept that the request destination user accepts the request, the present invention can be suitably 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 reception unit 53, the determination unit 54, the notification unit 55, the acceptance unit 56, and the storage unit 57. Not limited to. 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. For example, FIGS. 24A and 24B 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 stores various data (for example, monster character data and request acceptance list).
  • the data is stored in a storage device in the communication terminal 10. You may let them.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

　本発明のゲーム制御装置は、要請元ユーザであるユーザによるゲーム上の要請を受け付ける受付手段と、前記要請の要請先である要請先ユーザを決定する決定手段と、前記要請先ユーザに前記要請を通知する通知手段と、前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付ける受諾手段と、前記要請の受諾に関する受諾情報を記憶装置に記憶させる記憶手段と、を具備し、前記通知手段は、前記要請先ユーザによる要請を前記要請元ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記要請元ユーザの要請の通知態様を変更する。

Description

ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム、コミュニケーション装置
　本発明は、複数のユーザの各々の操作に応じて各ユーザによるゲームの進行を制御する技術、及び複数のユーザ間でデータの送受信や共有などを行う技術に関する。
　従来、複数のユーザ間でネットワークを介したデータ（例えば、コメントやメッセージなどのテキストデータ、画像データ、音声データなど）の送受信や共有などを行うことが可能なコミュニケーションサービスが知られている。また、近年では、上述したコミュニケーションサービスの一例として、ソーシャルネットワーキングサービス（ＳＮＳ）において実行されるアプリケーションとして、いわゆるソーシャルゲーム（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 (13)

  1. 　要請元ユーザであるユーザによるゲーム上の要請を受け付ける受付手段と、
    　前記要請の要請先である要請先ユーザを決定する決定手段と、
    　前記要請先ユーザに前記要請を通知する通知手段と、
    　前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付ける受諾手段と、
    　前記要請の受諾に関する受諾情報を記憶装置に記憶させる記憶手段と、
    　を具備し、
    　前記通知手段は、前記要請先ユーザによる要請を前記要請元ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記要請元ユーザの要請の通知態様を変更する、
    　ことを特徴とする、ゲーム制御装置。
  2. 　前記受諾情報は、前記要請先ユーザからの少なくとも１回の要請に対して前記要請元ユーザが受諾した回数を含み、
    　前記通知手段は、前記回数に応じて、前記要請先ユーザに対する前記要請元ユーザの要請の通知態様を変更する、ことを特徴とする、
    　請求項１に記載されたゲーム制御装置。
  3. 　前記受諾情報は、前記要請先ユーザからの要請に対する前記要請元ユーザの貢献の程度を示す貢献度を含み、
    　前記通知手段は、前記貢献度に応じて、前記要請先ユーザに対する前記要請元ユーザの要請の通知態様を変更する、ことを特徴とする、
    　請求項１または２に記載されたゲーム制御装置。
  4. 　前記受諾情報は、前記要請先ユーザからの要請に対する前記要請元ユーザの受諾時期から前記要請先ユーザに対する前記要請元ユーザの要請の通知時期までの期間を含み、
    　前記通知手段は、前記期間に応じて、前記要請先ユーザに対する前記要請元ユーザの要請の通知態様を変更する、ことを特徴とする、
    　請求項１～３のいずれかに記載されたゲーム制御装置。
  5. 　前記受諾情報は、前記要請先ユーザからの要請を前記要請元ユーザが受諾したときの前記要請先ユーザによるゲームの実行状況を含み、
    　前記通知手段は、前記実行状況に応じて、前記要請先ユーザに対する前記要請元ユーザの要請の通知態様を変更する、ことを特徴とする、
    　請求項１～４のいずれかに記載されたゲーム制御装置。
  6. 　前記受諾情報は、前記要請先ユーザからの要請に対する前記要請元ユーザの貢献の程度を示す貢献度を含み、
    　前記通知手段は、前記要請元ユーザからの要請を前記要請先ユーザに通知する際に、前記貢献度を前記要請先ユーザに通知する、ことを特徴とする、
    　請求項１～５のいずれかに記載されたゲーム制御装置。
  7. 　前記通知手段は、前記要請先ユーザに対して要請を行う要請元ユーザが複数存在する場合に、前記受諾情報に基づいて、前記要請先ユーザに対する要請の通知態様を複数の要請元ユーザ毎に変更する、ことを特徴とする、
    　請求項１～６のいずれかに記載されたゲーム制御装置。
  8. 　前記要請は、前記要請元ユーザがゲーム上の有利な効果を得るために行われることを特徴とする、
    　請求項１～７のいずれかに記載されたゲーム制御装置。
  9. 　要請元ユーザであるユーザによるゲーム上の要請を受け付けるステップと、
    　前記要請の要請先である要請先ユーザを決定するステップと、
    　前記要請先ユーザに前記要請を通知するステップと、
    　前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付けるステップと、
    　前記要請の受諾に関する受諾情報を記憶装置に記憶させるステップと、
    　を備え、
    　前記要請を通知するステップでは、前記要請先ユーザによる要請を前記要請元ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記要請元ユーザの要請の通知態様を変更する、
    　ゲーム制御方法。
  10. 　コンピュータに、
    　要請元ユーザであるユーザによるゲーム上の要請を受け付ける機能、
    　前記要請の要請先である要請先ユーザを決定する機能、
    　前記要請先ユーザに前記要請を通知する機能、
    　前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付ける機能、及び
    　前記要請の受諾に関する受諾情報を記憶装置に記憶させる機能、
    　を実現させ、
    　前記要請を通知する機能では、前記要請先ユーザによる要請を前記要請元ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記要請元ユーザの要請の通知態様を変更する、
    　ことを実現させるためのプログラム。
  11. 　請求項１０に記載されたプログラムを記録したことを特徴とする、コンピュータ読み取り可能な記録媒体。
  12. 　通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
    　要請元ユーザであるユーザによるゲーム上の要請を受け付ける受付手段、
    　前記要請の要請先である要請先ユーザを決定する決定手段、
    　前記要請先ユーザに前記要請を通知する通知手段、
    　前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付ける受諾手段、
    　前記要請の受諾に関する受諾情報を記憶装置に記憶させる記憶手段、
    　の各手段を、前記通信端末又は前記サーバのいずれか一方が備え、
    　前記通知手段は、前記要請先ユーザによる要請を前記要請元ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記要請元ユーザの要請の通知態様を変更する、
    　ゲームシステム。
  13. 　要請元ユーザであるユーザによる要請を受け付ける受付手段と、
    　前記要請の要請先である要請先ユーザを決定する決定手段と、
    　前記要請先ユーザに前記要請を通知する通知手段と、
    　前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付ける受諾手段と、
    　前記要請の受諾に関する受諾情報を記憶装置に記憶させる記憶手段と、
    　を具備し、
    　前記通知手段は、前記要請先ユーザによる要請を前記要請元ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記要請元ユーザの要請の通知態様を変更する、
    　ことを特徴とする、コミュニケーション装置。
PCT/JP2013/065096 2012-05-31 2013-05-30 ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム、コミュニケーション装置 WO2013180242A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2012124112A JP5395210B2 (ja) 2012-05-31 2012-05-31 ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、コミュニケーション装置
JP2012-124112 2012-05-31

Publications (1)

Publication Number Publication Date
WO2013180242A1 true WO2013180242A1 (ja) 2013-12-05

Family

ID=49673429

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/065096 WO2013180242A1 (ja) 2012-05-31 2013-05-30 ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム、コミュニケーション装置

Country Status (2)

Country Link
JP (1) JP5395210B2 (ja)
WO (1) WO2013180242A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6678866B2 (ja) * 2013-12-13 2020-04-08 株式会社コナミデジタルエンタテインメント 情報処理装置、プログラム、情報処理システム
KR102281439B1 (ko) * 2014-04-04 2021-07-27 엔에이치엔 주식회사 카드 게임 진행 방법 및 이를 이용한 카드 게임 서비스 시스템
JP2018153695A (ja) * 2018-06-08 2018-10-04 株式会社コナミデジタルエンタテインメント 情報処理装置、プログラム、情報処理システム
JP2019010595A (ja) * 2018-10-30 2019-01-24 株式会社 ディー・エヌ・エー 電子ゲーム提供装置及び電子ゲームプログラム

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001293254A (ja) * 2000-04-14 2001-10-23 Konami Co Ltd ゲームシステム、ゲーム装置、ゲーム装置の制御方法及び情報記憶媒体
JP2011206442A (ja) * 2010-03-30 2011-10-20 Namco Bandai Games Inc ゲームシステム、プログラム及び情報記憶媒体

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3437841B2 (ja) * 2001-06-15 2003-08-18 コナミ株式会社 ゲームシステム及びゲーム用プログラム
JP5249675B2 (ja) * 2008-08-11 2013-07-31 株式会社タイトー 救援要請プログラム及びゲームシステム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001293254A (ja) * 2000-04-14 2001-10-23 Konami Co Ltd ゲームシステム、ゲーム装置、ゲーム装置の制御方法及び情報記憶媒体
JP2011206442A (ja) * 2010-03-30 2011-10-20 Namco Bandai Games Inc ゲームシステム、プログラム及び情報記憶媒体

Also Published As

Publication number Publication date
JP5395210B2 (ja) 2014-01-22
JP2013248085A (ja) 2013-12-12

Similar Documents

Publication Publication Date Title
JP5882188B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5646537B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5436612B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
WO2013191124A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム
JP5838149B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
WO2013157396A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム
JP6195093B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
WO2013176285A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム
JP5290460B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
WO2013176002A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム
JP5941386B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5789233B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5318987B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5395210B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、コミュニケーション装置
JP5731710B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5847037B2 (ja) ゲーム制御装置、ゲーム制御方法、ゲームシステム
JP6678867B2 (ja) サーバ、制御プログラム
JP5222418B1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP6206764B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5827271B2 (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: 13797822

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

Country of ref document: EP

Kind code of ref document: A1