WO2013094160A1 - ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム - Google Patents
ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム Download PDFInfo
- Publication number
- WO2013094160A1 WO2013094160A1 PCT/JP2012/007982 JP2012007982W WO2013094160A1 WO 2013094160 A1 WO2013094160 A1 WO 2013094160A1 JP 2012007982 W JP2012007982 W JP 2012007982W WO 2013094160 A1 WO2013094160 A1 WO 2013094160A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- user
- character
- game
- data
- monster
- Prior art date
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/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/60—Generating or modifying game content before or while executing the game program, e.g. authoring tools specially adapted for game development or game-integrated level editor
- A63F13/63—Generating or modifying game content before or while executing the game program, e.g. authoring tools specially adapted for game development or game-integrated level editor by the player, e.g. authoring using a level editor
-
- 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/90—Constructional details or arrangements of video game devices not provided for in groups A63F13/20 or A63F13/25, e.g. housing, wiring, connections or cabinets
- A63F13/92—Video game devices specially adapted to be hand-held while playing
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
- A63F2300/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
-
- 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/57—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 details of game services offered to the player
- A63F2300/575—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 details of game services offered to the player for trading virtual items
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
- A63F2300/80—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game specially adapted for executing a specific type of game
- A63F2300/8058—Virtual breeding, e.g. tamagotchi
Definitions
- the present invention relates to a technique for controlling the progress of a game by each user according to each operation of a plurality of users.
- social game executed by a game application created based on an operating environment such as an API (Application Programming Interface) operating on a web browser in a social networking service (SNS) by a specific service provider.
- API Application Programming Interface
- SNS social networking service
- Game is popular. It can be said that the social game is a kind of online game that is played while communicating among an unspecified number of users. If a user can connect to the Internet and has a communication terminal equipped with a web browser, the user can enjoy a social game regardless of time and place.
- One of the features of the above-described social game is that it has a richer communication function for interaction between users than the conventional online game.
- social games for example, in addition to cooperative play with other users (friends), information exchange by communicating with friends such as greetings and contacts with friends, gifts of items on the game with friends or items An exchange has been made.
- Non-Patent Document 1 in a digital card game (Dragon Collection (registered trademark)), when a user battles with another game character using his game character, a fellow game character is supplementarily supported. It is stated that you can borrow.
- Non-Patent Document 1 when a user performs a battle by borrowing a game character from another user, there is no instruction in the battle from the other user, and the users cooperate with each other. You can't taste the feeling of doing a battle. That is, even if a user performs a battle by borrowing a game character from another user, it is not possible to obtain a sense of cooperation between the users in that battle.
- the present invention has been made in view of the above-described viewpoints, and provides a game control device, a game control method, a program, a recording medium, and a game system that can provide a sense that a user is advancing a game in cooperation with each other. Objective.
- a first aspect of the present invention is a game control device that controls the progress of a game by each user in accordance with each operation of a plurality of users.
- This game control device Storage means for storing a character on the game and character data as character data in association with each other; For each user, control means for changing the character data according to the user's operation; Providing means for providing information identifying a character of a first user among the plurality of users to a second user different from the first user; With When the information for specifying the first user's character is provided to the second user, the control means is configured to send the character data of the second user's character according to the operation of the second user. At the same time, the character data of the first user's character is changed.
- character data is data related to a character and can be changed in accordance with the progress of the game.
- the character data may take various types of data depending on the nature of the game.
- the character data may be a value (HP) indicating the physical strength of the enemy character.
- the “information for identifying a character” may be any information as long as it is information that can distinguish different characters on the game, or information that can identify a character on the game.
- the information specifying the character may be an image showing the appearance of the character, text showing the name of the character, or an identification code for specifying the character.
- the “character” is, for example, a virtual person, creature, or monster on the game, and includes those displayed on a card.
- a game is advanced for each user with respect to a plurality of users while the character data is changed according to the user's operation. Further, in this game control device, when the information specifying the character of the first user is provided to the second user, the character data of the character of the second user is changed according to the operation of the second user. In addition, the character data of the first user character is also changed. Thereby, since the operation of the second user can directly affect the progress of the game of the first user, the first user and the second user proceed with the game in cooperation with each other. You can get the feeling of doing it.
- the user character may be an enemy character in the case of a competitive game, but may be set as appropriate depending on the nature of the game.
- the user's character may be a plant character to be a user's growing target.
- the control means does not display the second user character on the display screen presented to the first user, and does not display the second user character on the display screen presented to the second user. May be displayed.
- the character data of each of the first user character and the second user character may be displayed on a display screen presented to the second user.
- each user's character is associated with an attribute
- the control means obtains the character data of the first user character according to the operation of the second user. It may be changed.
- the “character attribute” refers to, for example, a character's form and / or color, pattern, character itself and ability (numerical level), and a specific sound (scream) set for the character. Etc.) may include any characteristic that can visually and / or audibly distinguish character differences.
- the user's character attribute may be an enemy character attribute.
- the second user is responsive to the progress of the game of the first user among his / her characters. It is possible to proceed with the game while recognizing characters that can be affected.
- the control means can select either one based on a selection operation by the second user.
- the character data of the selected character may be changed together with the character data of the character of the second user in accordance with the operation of the second user. That is, the second user can select which character to select.
- the second user can select a character having the same attribute as that of his / her character, so that it is easy to advance the game in cooperation with other users.
- the game control apparatus includes a second storage unit that stores associations between the plurality of users, and the providing unit specifies a user associated with the first user as the second user. May be.
- the association between the users may be performed by associating the users with each other as a friend in advance.
- the game control apparatus includes a second storage unit that stores associations between the plurality of users, and the providing unit includes the first user among the plurality of users associated with the first user. Inquiries about whether or not to provide information specifying the user's character may be made, and the user who first responded that the information is desired to be provided may be specified as the second user. Thereby, the user's desire to quickly advance the game in cooperation with other users can be satisfied.
- a second aspect of the present invention is a game control apparatus that controls the progress of a game by each user in accordance with each operation of a plurality of users.
- This game control device Storage means for storing the enemy character of the user on the game and character data that is data of the enemy character in association with each other; For each user, control means for changing the character data according to the user's operation; Providing means for providing information for identifying an enemy character of the first user among the plurality of users to a second user different from the first user; With When the information for specifying the enemy character of the first user is provided to the second user, the control means, in response to the operation of the second user, the character of the enemy character of the second user Simultaneously with the data, the character data of the enemy character of the first user is changed.
- a third aspect of the present invention is a game control method for controlling the progress of a game by each user in accordance with each operation of a plurality of users.
- This game control method Storing a character on the game and character data that is character data in a storage device in association with each other; For each user, changing the character data according to the user's operation; Providing information for identifying a character of the first user among the plurality of users to a second user different from the first user; Including In the step of changing, when information specifying the first user's character is provided to the second user, the character data of the second user's character according to the operation of the second user. At the same time, the character data of the first user character is changed. When information specifying the first user's character is provided to the second user, the second user's character is not displayed on the display screen presented to the first user. A step of displaying the first user's character on the display screen presented to the user.
- the function to be changed is the second user's operation according to the operation of the second user.
- the character data of the first user character is changed simultaneously with the character data of the character.
- 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 fifth aspect of the present invention is a computer-readable recording medium in which the program is recorded.
- a communication terminal operated by a user a game control device connected to the communication terminal via a network, and controlling the progress of a game by each user according to each user's operation;
- a game system provided with This game system Storage means for storing a character on the game and character data that is character data in association with each other;
- control means for changing the character data according to the user's operation, and Providing means for providing information identifying a character of a first user among the plurality of users to a second user different from the first user;
- Each means is provided in either one of the communication terminal or the server, When the information for specifying the first user's character is provided to the second user, the control means is configured to send the character data of the second user's character according to the operation of the second user. At the same time, the character data of the first user's character is changed.
- the control means may not display the second user character on the display screen presented to the first user, but may display the first user character on the display screen presented
- the figure which shows the basic composition of the game system of embodiment The figure which shows the example of the external appearance of the communication terminal of embodiment.
- the figure which shows the example of the external appearance of the communication terminal of embodiment The block diagram which shows the structure of the communication terminal of embodiment.
- the block diagram which shows the structure of the game server of embodiment The block diagram which shows the structure of the database server of embodiment.
- the functional block diagram for demonstrating the function to play main roles with the game control apparatus of embodiment The figure which shows an example of the display screen of the communication terminal which displays a top page.
- the figure which illustrates a series of web pages displayed in a user's communication terminal The figure which illustrates the contents of battle data. The figure which illustrates the contents of battle data. The figure which illustrates a series of web pages displayed in a user's communication terminal. The figure which illustrates the web page displayed in a user's communication terminal. The figure which illustrates the web page displayed in a user's communication terminal. The figure which illustrates the web page displayed in a user's communication terminal. The flowchart which shows an example of the main processes 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 the web page displayed in a user's communication terminal. The figure which illustrates the web page displayed in a user's communication terminal. The figure which illustrates the web page displayed in a user's communication terminal. The figure which illustrates the web page displayed in a user's communication terminal. The figure which illustrates the web page displayed in a user's communication terminal.
- the present invention relates to a patent application of Japanese Patent Application No. 2011-277722 filed with the Japan Patent Office on December 19, 2011, the entire contents of which are incorporated herein by reference.
- FIG. 1 shows a system configuration example of the game system according to the embodiment.
- the game system includes communication terminals 10a, 10b, 10c,... That can be connected to a communication network NW (network) such as the Internet, a game server 20 connected to the communication network NW,
- NW network
- the database server 30 is configured.
- Each of the communication terminals 10a, 10b, 10c,... Is a terminal operated by an individual user, for example, a mobile terminal, a smartphone, a PDA (Personal Digital Assistant), a personal computer, a television having a bidirectional communication function.
- a communication terminal such as a John receiver (including a so-called multi-function smart TV).
- the game server 20 is configured to be able to communicate with the communication terminal 10 that is a client, and provides a gaming service to the communication terminal 10.
- the game server 20 is mounted with an application operable on a web browser as a game application.
- the database server 30 stores various information to be described later in executing the game, and is connected to the game server 20 by, for example, a wire for reading and writing the information.
- the communication terminal 10 includes a web browser capable of displaying a web page provided by the game server 20, and the user operates the communication terminal 10 on the web page to execute a game.
- an authentication server for authenticating the user of each communication terminal 10 may be provided separately from the game server 20. Further, when a plurality of game servers 20 are provided in order to accept access from many communication terminals 10, a load balancer for adjusting a load between the plurality of game servers 20 may be provided.
- the game server 20 may be configured as a single server device, but may be configured as a plurality of server devices having distributed functions.
- the database server 30 stores various information to be described later in executing the game, and is connected to the game server 20 by, for example, a wire for reading and writing the information.
- FIGS. 2A, 2B, and 3 are diagrams each showing an example of the appearance of the communication terminal 10, and FIG. 2A exemplifies a button input type communication terminal such as a foldable mobile terminal (mobile phone), for example.
- FIG. 2B illustrates a touch panel input type communication terminal such as a smartphone.
- FIG. 3 is a block diagram showing an internal configuration of the communication terminal 10. As shown in FIG.
- the communication terminal 10 includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, an image processing unit 14, an instruction input unit 15, a display unit 16, A wireless communication interface unit 17 serving as a signal transmission / reception unit is provided, and a bus 18 for transmitting a control signal or a data signal between the units is provided.
- a CPU Central Processing Unit
- ROM Read Only Memory
- RAM Random Access Memory
- the CPU 11 loads the web browser in the ROM 12 into the RAM 13 and executes it.
- the CPU 11 displays data for displaying a web page from the game server 20 via the wireless communication interface unit 17 based on appropriate designation of a URL (Uniform Resource Locator) input to the user by the instruction input unit 15 or the like. That is, data of an object such as an HTML (HyperText Markup Language) document and an image associated with the document (hereinafter, collectively referred to as “HTML data” as appropriate) is acquired via the wireless communication interface unit 17.
- HTML data is interpreted.
- the communication terminal 10 may be mounted with various plug-ins for extending the browser function of the web browser.
- 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 wireless communication interface unit 17. To the game server 20.
- the web browser displays the web page provided from the game server 20 on the display unit 16 based on the acquired HTML data via the image processing unit 14.
- the web browser transmits new HTML data for displaying the web page according to the selection. (That is, update of the web page) is requested to the game server 20.
- the image processing unit 14 displays a web page on the display unit 16 based on the display image data given from the CPU 11 as the analysis result of the HTML data.
- the display unit 16 is, for example, an LCD (Liquid-Cristal-Display) monitor including thin film transistors arranged in units of pixels in a matrix, and displays an image of a web page by driving the thin film transistors based on display image data. To display.
- LCD Liquid-Cristal-Display
- the instruction input unit 15 includes a button group 15a including a plurality of instruction input buttons such as a direction instruction button and a decision button for accepting a user operation input. And a button group 15b including a plurality of instruction input buttons such as a numeric keypad, and includes an interface circuit for recognizing a pressing (operation) input of each button and outputting it to the CPU 11.
- the direction instruction button is provided to instruct the CPU 11 to scroll and display the web page displayed on the display unit 16.
- the determination button instructs the CPU 11 that the user selects one hyperlink or menu that is actively displayed (for example, highlighted) when, for example, a plurality of hyperlinks or menus are displayed on a web page.
- buttons are provided on the front surface of the communication terminal 10 so that the user can easily operate (click) with the thumb while holding the communication terminal 10 with one hand. It is preferable to arrange
- the button group 15b is arranged below the button group 15a and includes a plurality of instruction input buttons on which “0” to “9”, “*”, and “#” (ten keys) are written. .
- the instruction input unit 15 mainly accepts touch panel type input by touching the display screen 16a with a fingertip or a pen.
- the touch panel input method may be a known method such as a capacitance method.
- the button group 15a may be provided even when the communication terminal 10 is a touch panel input method.
- the menu selection operation on the web page displayed on the communication terminal 10 is selected by pressing the direction instruction button and selecting by pressing the enter button. This is done by confirming the selected menu.
- the selection operation is performed by instructing (touch operation) a menu position on the display screen 16a on which the web page is displayed with a finger or a pen.
- the configuration of the game server 20 will be described with reference to FIG.
- the game server 20 manages a game website including a plurality of hierarchical web pages, for example, and provides a game web service to the communication terminal 10.
- the game server 20 includes a CPU 21, a ROM 22, a RAM 23, a database (DB) access unit 24, and a wireless communication interface unit 25, for transmitting control signals or data signals between the units.
- 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 wireless communication interface unit 25.
- the CPU 21 transmits HTML data to the communication terminal 10 via the wireless communication interface unit 25.
- the CPU 21 performs the authentication process.
- CPU21 performs the process according to the hyperlink or menu selected by the user on the web page displayed on the communication terminal 10 via a communication interface part.
- the processing includes, for example, transmission of new HTML data, arithmetic processing in the game server 20 or data processing.
- the database access unit 24 is an interface when the CPU 21 reads / writes data from / to the database server 30.
- the database server 30 can be realized by a general-purpose storage such as a large-capacity hard disk device or a device such as a RAID (Redundant Array of Inexpensive Disks). Each database in the database server 30 is configured to be able to read and write data from the CPU 21 via the database access unit 24 of the game server 20.
- FIG. 5 shows an example of the configuration of the database server 30. 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 server 20 of the present embodiment is not particularly limited, but in the following, as an example of a game realized by the game server 20 for convenience of description of the embodiment, a user communication terminal
- a battle type digital card game in which a user battles with a monster character that is a monster on the game using a warrior card virtually held in the game is taken up.
- This digital card game is a game in which a user collects a warrior card to create his or her own team (army), for example, a battle with another user's team (army) or a monster character.
- This digital card game includes a mission execution process to search for warrior cards to create your own team, a lottery process that allows you to obtain warrior cards by lottery, or two or more warrior cards. Strengthening processing to improve the ability of warrior cards is provided.
- FIG. 6 shows an example of a user database 31 applied in the above-described competitive digital card game.
- the user database 31 has a display name / display image, skill level, physical strength points, attack points, strengthening points, friendship points, number of warriors, possessed coins, and fellow user IDs for each user ID (user identification information).
- Information included in the user database 31 can be updated sequentially by the game server 20.
- user IDs included in the user database 31 or data for each display name (to be described later) that identifies a user are collectively referred to as user data.
- the data of each item constituting the user data is as follows.
- Display name / display image A display name and a display image that are displayed to identify the user of the communication terminal 10 when the game is executed.
- the display name is a text of a predetermined length or less designated in advance by the user, and the display image is an avatar image selected in advance by the user, for example.
- the display 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
- -Physical point This is a point necessary for performing the mission on the game by the user in the above-mentioned competitive digital card game.
- the health point is a value that decreases by performing the mission and recovers (increases) every time a predetermined time elapses.
- -Attack point It is a point which is needed when performing a battle on a game by a user in the above-mentioned battle type digital card game.
- the attack point is a value that is reduced by a battle with another user or a monster character and is recovered (increased) every time a predetermined time elapses.
- the strengthening point is a value that is reduced by strengthening the warrior card and is recovered (increased) every time a battle with another user is won or a predetermined time elapses.
- competition type digital card game it is a point which a user acquires by transmitting a support message to a friend.
- -Number of warriors This is the number of warrior cards held by the user. The number of warriors increases and decreases with the execution of mission execution processing and reinforcement processing. The maximum number of warriors (for example, 60) is defined in advance.
- -Owned coin This is the possessed amount of virtual currency (coin) on the game that is required when the user corresponding to the user ID uses the pay function on the game.
- the possessed coins are consumed (reduced) when the user uses a paid function on the game, and the user pays actual money to the service provider or the like by a predetermined method, and increases according to the amount paid.
- ⁇ Friend's user ID This is data of another user ID previously associated with the target user ID.
- -Image data of possession card In the case of the above-mentioned battle type digital card game, the image data of possession card is data including the image about the warrior card possessed by the user.
- -Owned card parameter The held card parameter is data indicating the ability value of the warrior card.
- each capability value of “attack power” and “defense power” and “necessary points” may be included as parameter items.
- “Necessary points” are points required when using a warrior card in battle. In this game, the total required points of warrior cards used in battles may be limited to be equal to or less than attack points.
- the game database 32 stores and updates information related to the progress of the game executed by the game server 20 based on the access from the game server 20.
- Information relating to the progress of the game may include various information depending on the nature of the game. Taking the case of a battle-type digital card game as an example, the information related to the progress of the game includes the results of battles between different users, the processing results of excavation execution processing described later, and the like.
- FIG. 7 is a functional block diagram for explaining functions that play a main role in the game control apparatus of the present embodiment.
- menus, marks and the like displayed on the web page displayed on the communication terminal 10 are arranged at desired positions on the web page, and are menus visually recognized on the communication terminal 10. The position of the mark on the display screen can be changed by scrolling the web page by the user's direction instruction button.
- the registration unit 51 recognizes a user request based on an appropriate operation input to the communication terminal 10 on a web page provided to the communication terminal 10, for example, and performs a registration process.
- the registration means 51 in this case is executed as follows, for example.
- the CPU 21 of the game server 20 receives a registration request message from the communication terminal 10 via the wireless communication interface unit 25.
- the registration request message is automatically generated by a predetermined operation (for example, a predetermined menu selection operation, text input, etc.) on the communication terminal 10 on the web page provided from the game server 20. May be configured.
- the registration request message may include information (for example, IP address, e-mail address, etc.) for specifying the communication terminal 10 as the transmission source, or the user has already played another game by the same service provider.
- the user ID may be included.
- the CPU 21 receives the registration request message and the registration request message does not include the user ID, the CPU 21 issues a new user ID and performs registration processing of the user ID, and then the registration processing is completed. Is sent to the communication terminal 10.
- the CPU 21 receives the registration request message and the registration request message includes a user ID, the CPU 21 performs registration processing of the user ID, and then transmits a registration completion message indicating that the registration processing is completed to the communication terminal. 10 to send.
- the CPU 21 When the registration is completed, the CPU 21 generates user data corresponding to the user ID and stores it in the user database 31.
- the registration unit 51 may also 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 (that is, another user) as a “friend” with an application based on the user ID as a trigger.
- the registration means 51 in this case is executed as follows, for example.
- the CPU 21 of the game server 20 applies 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 wireless communication interface unit 25. Accept. Transmission of this application message is preset as a function of a web page provided to the user's communication terminal 10.
- the CPU 21 approves an application based on another user ID to the communication terminal 10 corresponding to the user ID at the timing when the access is based on the user ID included in the application message. HTML data for displaying a web page for requesting the reply is transmitted. If it is replied that the application is approved, the CPU 21 registers both as friends. Specifically, the CPU 21 writes the data in the “mate” part (see FIG. 6) of the user data of the corresponding two user IDs in the user database 31.
- the game progress means 52 advances the game by transmitting HTML data for sequentially updating web pages displayed on the communication terminal 10 in response to a user operation on the communication terminal 10.
- game In an example of a battle-type digital card game (hereinafter simply abbreviated as “game” as appropriate), the following processing can be performed to advance the game.
- Mission execution processing This is a process to get a warrior card by completing a mission to build your own team. In this game, a certain amount of action points are required to complete the mission.
- ⁇ Strengthening process It is a process that increases the ability of a specific warrior by integrating two or more warrior cards. In this game, a certain amount of strengthening points is required for the user to execute the strengthening process.
- ⁇ Battle execution process This is a process of performing a battle with another user's team.
- Lottery processing This is a process in which a user performs a lottery for obtaining a warrior card.
- Excavation execution processing This is a process of executing a play to capture the land by excavating the land in accordance with the user's operation and defeating the monster character of the land (described later).
- the display unit 521 has a function of causing the communication terminal 10 to display a plurality of menus to which the plurality of processes executed in the game are assigned. Specifically, the CPU 21 generates HTML data for displaying a web page including a plurality of menus, and transmits the HTML data to the communication terminal 10. In the game, points on the game are consumed with the execution of the mission execution process, the reinforcement process, the battle execution process, and the lottery process.
- FIG. 8 An example of the top page of the game displayed on the communication terminal 10 by the display means 521 is shown in FIG.
- This top page is composed of web pages corresponding to individual user IDs.
- the top page illustrated in FIG. 8 includes a user data display area, a warrior image display area, and a menu display area.
- the skill level, physical strength point, attack point, strengthening point, friendship point, number of warriors, and data of each item included in the user data of the target user ID (see FIG. 6) are displayed.
- Area It should be noted that in the items displayed in the user data display area, the point or number written in the X / Y format is that X is the point or number held by the user, and Y is the maximum value of the point or number. Indicates that there is.
- the warrior image display area is an area in which an image of a warrior card specified in advance by the user among a plurality of warrior cards included in the user data of the target user ID is displayed.
- the menu display area is a basic menu corresponding to the multiple functions (mission execution process, reinforcement process, battle execution process, lottery process, excavation execution process) provided in the competitive digital card game. This is an area in which the menus m1 to m5 in which the texts “battle”, “lottery”, and “excavation” are written are displayed. That is, a plurality of menus to which a plurality of processes executed in the game are assigned are respectively arranged at predetermined positions on the web page displayed on the communication terminal 10.
- the game progress means 52 is realized as follows.
- the CPU 21 of the game server 20 accesses the user database 31 via the database access unit 24, and reads the data of each item included in the user data display area and the image data of the warrior card to be displayed in the warrior image display area.
- the CPU 21 generates HTML data so that the top page shown in FIG. 8 is configured, and transmits it to the communication terminal 10.
- the generated HTML data is different for each user (that is, for each user ID).
- the communication terminal 10 interprets the received HTML data and displays the top page image on the display unit 16 (display screen 16a).
- the game progress means 52 performs a mission execution process, a reinforcement process, a battle execution process, a lottery process, and an excavation execution process in accordance with a user's selection operation for any of the menus m1 to m5 displayed on the communication terminal 10. Execute. Preferably, when each process is executed, each process is executed hierarchically so that a new web page including a plurality of subdivided menus is displayed.
- the game progression means 52 has a function of executing excavation execution processing for each user and advancing the game using a character whose character data can be changed according to the user's operation.
- the function of the excavation execution process in the game progress means 52 and the method for realizing it will be described in detail below.
- FIG. 9 exemplifies the contents of the monster character data, and is data that is loaded and stored in, for example, the RAM 23 together with the execution of the excavation execution process. This data may be stored in the game database 32.
- the level (Lv), attack power value, defense power value, and monster character HP value A value indicating physical strength; character data
- the attack power value, the defense power value, and the HP value of the monster character may be set to increase.
- the image of the monster character is an example of the attribute of the monster character.
- the flow of the game by the excavation execution process is as follows.
- the excavation execution processing includes processing of each game in excavation mode and battle mode.
- a plurality of sections of land are dug in order (excavated) in response to a user operation, and a monster character appears when each section is dug.
- a monster character appears, it shifts to a battle mode in which a battle is performed between the warrior card held by the user and the monster character that appears, in accordance with the user's operation on the communication terminal 10.
- the HP value indicating physical strength
- the warrior card loses physical strength due to the attack of the monster character, the capture of the land in the section where the monster character appears has failed, and the monster character will not disappear from the section. In that case, after the physical strength of the warrior card is recovered, the user performs a battle with the same monster character again.
- FIG. 10 shows an example in which the user who performs the operation is “KNM” (hereinafter referred to as user: KNM).
- Steps S1 to S3 in FIG. 10 sequentially show examples of web pages displayed on the user communication terminal 10 in the excavation mode.
- step S1 in FIG. 10 is a top page in the excavation execution process.
- a display area 100 for enabling display of a maximum of three monster characters as battle opponents For example, a display area 200 for displaying a maximum of three monster characters as battle opponents of the user is included.
- the web page displayed on the user's communication terminal 10 displays the land of a predetermined number (10 in FIG. 10) of sections.
- the display image 300 representing, the display image 350 representing the excavation rate of the land of the target section, and the menu m8 of “digging” are transferred (FIG. 10, step S2).
- the display image 300 it can be visually recognized that the land of the section to be excavated by the user is the section 301.
- the value of the “digging rate” (%) displayed in the display image 350 increases by a random increase amount. Displayed.
- FIG. 11 shows an example of a web page displayed on the communication terminal 10 when the excavation rate reaches 100% and shifts to the battle mode.
- an image of an appearing monster character and its level (Lv8 in FIG. 11) are displayed, and in order to select one user to fight against the appearing monster character.
- the providing means 523 provides information on the monster character of the first user (that is, the monster character that is the battle opponent of the first user; enemy character) to the communication terminal 10 of the second user different from the first user. It has the function to provide. In other words, the providing means 523 allows the second user to simultaneously attack the monster character that is the battle opponent of the first user who is the other user, in addition to the monster character that is the battle opponent.
- the function which provides the 2nd user's communication terminal 10 with the information which specifies the monster character of a 1st user is provided.
- the user: KNM corresponds to the “first user”
- the user: ABC corresponds to the “second user”.
- the support request message for making a support request to the game server 20 is transmitted from the communication terminal 10 of the first user.
- the support request message may be automatically transmitted from the game server 20 to the communication terminal 10 of the fellow user while shifting to the battle mode.
- the function of the providing unit 523 is specifically realized as follows.
- the CPU 21 of the game server 20 recognizes that the menu m11 has been selected in the web page shown in step S4 of FIG. 11, the user: KNM user data is identified with reference to the user: KNM user data, and the identification is made. HTML data for displaying a friend in a selectable format is transmitted to the communication terminal 10 of the user: KNM.
- the web page shown in step S5 of FIG. 11 is displayed on the communication terminal 10 of the user: KNM.
- a case where user: ABC is selected as the support request destination user on the web page list in step S5 will be described as an example.
- HTML data for displaying the web page to be included is transmitted to the communication terminal 10 of the user: ABC.
- the avatar image of the user: KNM who is the support request source and the information specifying the monster character of the battle partner of the user: KNM are provided to the user: ABC.
- the information for specifying the provided monster character shows an example including the image and level of the monster character, but is not limited thereto. The text for specifying a monster character may be sufficient.
- the CPU 21 of the game server 20 recognizes that the menu m20 is selected on the web page shown in step S5 of FIG. 11, it becomes a battle partner in the battle mode for the communication terminal 10 of the user: KNM and the user: ABC. HTML data for displaying a monster character is transmitted.
- the monster character MC ⁇ b> 1 is arranged in the sub area 101 of the display area 100 on the web page displayed on the communication terminal 10 of the user: KNM.
- the monster character MC ⁇ b> 1 is arranged in the sub area 201 of the display area 200.
- FIG. 12A is an example of battle data corresponding to user: KNM
- FIG. 12B is an example of battle data corresponding to user: ABC.
- battle data are level (Lv) about the monster character used as the battle partner of one's own battle, and the monster character used as the battle partner of the other user who accepted the support request for every user.
- the attack power of the monster character and the initial HP value may be determined randomly with reference to the data of the monster character shown in FIG.
- the CPU 21 accesses the battle data each time and changes the HP value of the monster character subjected to the attack.
- CPU21 deletes the monster character from which HP became zero during battle from battle data.
- the RAM 23 that stores the HP (character data) of the monster character in the battle may be an example of the storage unit 522. Further, the CPU 21 accessing the RAM 23 for storing and updating the HP of the monster character in the battle may be an example for realizing the storage unit 522.
- gauges 101g and 201g indicating the HP of the monster character are displayed in the sub areas 101 and 201 where the monster character is arranged, respectively.
- This gauge is a scale that decreases in accordance with the degree of attack on the monster character of the warrior card by the user's operation, and is linked to the value of the monster character's HP in the battle data.
- the control means 524 has a function of changing the HP (character data) of a monster character that is a user's battle partner for each user in accordance with the user's operation. In this embodiment, more specifically, the control means 524 reduces the HP of a monster character by a warrior card held by the user attacking the monster character based on an attack instruction based on the user's operation. It has a function to make it. Further, the control means 524 provides information for identifying the monster character of the first user (support requesting user; KNM) to the second user (user who accepted the support request; ABC). A function of changing the HP value of the first user's monster character at the same time as the HP value (character data) of the second user's monster character according to the operation of the second user. Note that the control unit 524 may display the first user character on the display screen presented to the second user without displaying the second user character on the display screen presented to the first user. .
- FIG. 13 is a diagram illustrating a series of web pages displayed on the communication terminal 10 of the user: ABC who has accepted the support request from the user: KNM.
- the monster character that is the battle partner of the user: KNM is arranged and displayed in the sub-area 201 of the display area 200, and then the own battle is performed.
- the attack on the monster character of the battle opponent (monster of the sub area 101) by the warrior card possessed by the user ABC is against the monster character of the battle opponent of the user: KNM (the monster character of the sub area 201).
- KNM the monster character of the sub area 201.
- Is also configured to be effective that is, to reduce physical strength).
- the CPU 21 of the game server 20 When receiving the attack instruction message, the CPU 21 of the game server 20 generates HTML data for displaying a state in which a plurality of warrior cards (C1) possessed by the user: ABC simultaneously attack two monster characters, and the user : Transmit to the ABC communication terminal 10.
- the web page shown in step S8 of FIG. 13 is displayed on the communication terminal 10 of the user: ABC.
- the same gauge G as the gauges 101g and 102g is displayed on each of the two monster characters.
- the battle between a plurality of warrior cards on hand and a monster character may be set as follows.
- the number of warrior cards for example, 5 to 10 cards
- the user consumes a certain amount of attack points and performs one attack on the monster character with one or more warrior cards.
- the monster character's HP value decreases according to the sum of the attack power values of one or more warrior cards participating in the attack. If the attack point becomes zero, the monster character cannot be attacked.
- an attack is applied from the monster character to the warrior card at random timing with the attack power shown in the battle data.
- the CPU 21 when the CPU 21 recognizes that the menu m23 has been selected, the CPU 21 selects, for example, a warrior card that performs an attack from a predetermined number of warrior cards participating in the battle, at a certain standard or randomly.
- the total of the attack power of the warrior card may be read from the user data and subtracted from the HP value of the monster character in the battle data in the RAM 23.
- the CPU 21 writes the HP value of the monster character after subtraction into battle data, determines the scale amount of the gauge G according to the value after subtraction, and generates HTML data.
- CPU21 performs the process which subtracts from the value of HP of all the monster characters currently displayed on a user's web page.
- the CPU 21 can attack all monster characters by one attack (that is, consumption of one attack point) by the user.
- the battle data is updated so as to lower the HP.
- the web page shown in step S9 of FIG. 13 indicates that the HPs of both monster characters have decreased due to a single attack of the warrior card.
- the amount of change in HP of the two monster characters may be different. For example, even if the attack power is the same, there may be a case where the amount of HP change to be reduced varies depending on the level of the monster character.
- ⁇ ⁇ Various methods can be used to vary the amount of HP change between the two monster characters.
- the amount of change in the HP of the monster character of the second user (user who accepted the support request; ABC) to be processed is set to that of the HP of the monster character of the first user (user who requested the support; KNM). You may take the method of making it larger.
- the attack by the 2nd user the attack to the monster character of the battle opponent is mainly performed, and the attack to the monster character of the 1st user's battle partner is performed in a secondary manner.
- a monster character can be selected by selecting either the sub-region 101 or the sub-region 201, and thereby the user can designate the monster character that is the main attack target.
- the amount of change in HP of the main attack target monster character specified by the user may be larger than that of the monster character not specified. That is, in the example of FIG. 13, when the selection operation for the menu m23 (“attack a monster”) is recognized in a state where the sub area 101 is selected, the CPU 21 determines the HP of the monster character of the battle opponent of the user: ABC. The amount of change may be larger than that of the monster character of the battle partner of the user: KNM.
- the CPU 21 determines the amount of change in the HP of the monster character of the battle partner of the user: KNM. : It may be larger than that of the monster character of the ABC battle opponent.
- FIG. 13 is an example in which only one monster character is displayed in each of the display area 100 and the display area 200.
- each sub area is displayed.
- the monster character that is the main attack target may be designated (selected) by the user for each monster character.
- processing may be performed as follows.
- the CPU 21 is identical to the designated monster character among the monster characters displayed in any sub-area of the display area 200. It is determined whether or not there is a monster character with the attribute of.
- the CPU 21 changes the HP of the monster character designated as the monster character, and when there is no monster character with the same attribute, the CPU 21 Only HP is changed.
- the CPU 21 changes only the HP of the designated monster character even when another monster character having the same attribute as the monster character designated in the display area 100 exists in the display area 100.
- the CPU 21 designates the designated monster character among the monster characters displayed in any sub-area of the display area 100. It is determined whether or not there is a monster character having the same attribute.
- the CPU 21 changes the HP of the monster character designated as the monster character, and when there is no monster character with the same attribute, the CPU 21 Only HP is changed. Note that the CPU 21 changes only the HP of the designated monster character even when another monster character having the same attribute as the monster character designated in the display area 200 exists in the display area 200.
- the battle data shown in FIGS. 12A and 12B is associated with each battle opponent, and is configured so as to describe a sub-area where the battle opponent is displayed.
- the CPU 21 refers to the battle data and identifies the battle opponent corresponding to the sub-region designated by the user. For example, when the CPU 21 specifies any one of the “other users and their battle opponent” in the battle data as the designated monster character, the CPU 21 has the same monster character as the designated monster character. It is determined whether or not an attribute monster character exists. When there is a monster character having the same attribute, the HPs of both the monster character and the designated monster character are lowered according to the user's attack instruction.
- Intimacy may be a numerical value of the level of relationship between fellow users, for example, frequency of sending or receiving messages between users, items that can be used on the game It may be set on the basis of the number of times a present is sent or received. For example, the familiarity may be set higher as the frequency and the number of times are higher.
- Data describing the intimacy between users is stored in the user database 31, for example.
- the CPU 21 refers to the familiarity data and adjusts the amount of change in HP according to the familiarity between users.
- the HP change amount when the familiarity is lower than a predetermined value is set as the reference value, and the closeness is equal to or higher than the predetermined value
- the HP change amount is set to the reference value ⁇ k (k is 1). Large coefficient).
- the higher the closeness between the user: ABC and the user: KNM the more the user: ABC's selection operation of the menu m23 (“attack monster”) by the user: ABC, the support requesting user: KNM battle It is preferable to increase the amount of change in HP of the opponent monster character. Since a battle can be advanced advantageously, so that the closeness between friends is high, the exchange between users can be promoted.
- the CPU 21 generates an attack on the warrior card from the monster character at random timing. For example, CPU21 accesses the battle data of RAM23 and reads the value of the monster character's attack power.
- the CPU 21 randomly gives an attack by a monster character to, for example, one of the warrior cards participating in the battle, and when the attack power of the monster character is greater than the defense power of the warrior card to which the attack is given, Judge that the warrior card was killed by the attack. It is preferable to display such that the number of warrior cards of the user decreases on the updated web page as the monster character is defeated by the attack.
- the CPU 21 When the process corresponding to the selection operation of the menu m23 ends, the CPU 21 generates new HTML data so that the gauge indicating the monster character's HP is updated by the attack based on the operation by the user: ABC, and the user: KNM. , And user: send to the communication terminal 10 of ABC.
- the web page shown in step S10 of FIG. 14 is displayed on the communication terminal 10 of the user: KNM and the user: ABC. Comparing step S10 in FIG. 14 with step S7 in FIG. 13, it can be seen that the HP of the monster character that is the battle opponent of both user: KNM and user: ABC has decreased due to the attack by user: ABC (gauge 101g , 201g). As shown in FIG.
- the user: KNM's battle opponent monster character is displayed on the lower screen on the display screen presented to the user: KNM who requested the support, but the user: ABC battle.
- the opponent's monster character is not displayed.
- the monster character of the battle partner of the user: KNM is displayed in the upper row
- the monster character of the battle partner of the user: ABC is displayed in the lower row. That is, in this embodiment, only a common monster character (enemy character) based on the support request is displayed on each user's display screen, and other monster characters (that is, their own battle opponent monster characters) are individually Only displayed on the user's display screen.
- a display screen differs between users and a virtual space is not shared between users.
- FIG. 15A is a diagram illustrating an example of a web page displayed on the communication terminal 10 after the battle when the warrior card possessed by the user wins the monster character and succeeds in capturing the land in the target section 301. is there.
- FIG. 15B is a diagram illustrating an example of a web page displayed on the communication terminal 10 after the battle when the warrior card possessed by the user is defeated by the monster character and fails to capture the land in the target section 301. is there.
- a flag image indicating that the land has been successfully captured in the section 301 is displayed in the section 301.
- an image of a monster character that could not be defeated is displayed in the section 301.
- the attribute of the user who accepted the support request: ABC battle opponent monster character and the support request source user: KNM battle opponent monster character are the same (in this case, monster character MC1).
- Both HPs of KNM's battle opponent monster characters may be changed (decreased).
- the amount of change in the HP of the monster character of the user: KNM may be smaller than the case where the attributes match, or may be a value corresponding to the attribute of each monster character.
- the selection operation of the user: ABC menu m23 reduces only the HP of the monster character of the user: ABC battle opponent, and the user : You may make it not change HP of the monster character of KNM.
- FIG. 16 is a flowchart illustrating an example of a battle mode process in the excavation execution process.
- KNM first user
- ABC second user
- the screen display in steps S4 to S10 corresponds to the display example of the web page in steps S4 to S10 of FIGS.
- the communication terminal 10 of the user: KNM displays an image of the monster character that appears in the battle mode and a web page displaying the level, and selects the menu m11.
- a web page including a list for selecting a user as a support request destination is displayed (steps S4 and S5).
- a support request message specifying the support request destination user (user: ABC) is transmitted from the communication terminal 10 to the game server 20 (step S100).
- the game server 20 receives the support request message, the game server 20 generates HTML data including information for identifying the monster character of the user: KNM, and transmits it to the communication terminal 10 of the user: ABC who is the support request destination (step S102). ).
- the user: ABC communication terminal 10 Upon receiving the HTML data in step S102, the user: ABC communication terminal 10 has a web page including a menu as to whether or not to accept the support request along with information specifying the user who requested the support and the monster character. It is displayed (step S5). Thereby, the information which specifies a monster character is provided with respect to user: ABC.
- an acceptance message is transmitted from the communication terminal 10 to the game server 20 (step S104).
- the game server 20 sends new HTML data to the support requesting user: KNM communication terminal 10 and the user who accepted the support request: ABC communication terminal 10. Is transmitted (steps S106, S108).
- a web page including a monster character as a battle partner is displayed in a predetermined display area on the communication terminal 10 of the user: KNM, and a user is displayed in the predetermined display basin on the communication terminal 10 of the user: ABC.
- a web page including a monster character to be a battle partner of KNM is displayed (step S6).
- step S110 HTML data including information for specifying the monster character is transmitted (step S110).
- step S7 displayed on the communication terminal 10 of the user: ABC based on the HTML data transmitted in step S110, the monster character that is his / her battle opponent is displayed in a predetermined display area.
- a monster character that is a battle partner of the user: KNM is displayed.
- an attack instruction message is transmitted to the game server 20 from the communication terminal 10 of the user: ABC (step S112).
- the game server 20 updates the battle data so as to reduce the HP of the monster characters of both the user: KNM and the user: ABC (step S114), and reflects the new HP value.
- the generated HTML data is generated and transmitted to the communication terminal 10 of the user: ABC (step S116).
- the gauge which shows HP of a monster character changes on the web page displayed on the communication terminal 10 of user: ABC (step S9).
- the game server 20 updates the user data based on the attack instruction by the user: ABC so that the attack point of the user: ABC decreases by a certain amount.
- the game server 20 When the process corresponding to the operation of the attack instruction by the user: ABC is completed, the game server 20 generates new HTML data and transmits it to the communication terminal 10 of the user: ABC and the user: KNM (steps S118 and S120). ). In the web page displayed by this HTML data, it can be visually recognized that the HP of the monster character that is the battle partner of both the user: ABC and the user: KNM has decreased (step S10).
- the case where there is one type of monster character as a user's battle opponent that is, the case where the monster character is associated with a single attribute has been described as an example.
- the monster character that is the user's battle opponent may be associated with any of a plurality of attributes.
- the attributes of a monster character include, for example, a monster character's form and / or color, pattern, the character itself and a numerical value of the ability (level, etc.), and a specific sound (scream, etc.) set for the monster character. Any characteristic that can visually and / or audibly distinguish between monster characters can be included.
- FIG. 9 at least one of a plurality of monster characters (monster characters MC1 to MC3 in FIG. 9) having different attributes (appearance image in the example of FIG. 9) is a user. The case of becoming a battle opponent will be described.
- the HP of all monster characters displayed on the user's web page is reduced by an attack instruction operation (selection operation of the menu m23 in FIG. 13) by the user, but in this embodiment, The user can select and operate a monster character whose HP is reduced by an operation of an attack instruction among the monster characters displayed on the user's web page.
- control means 524 has the same attribute as the monster character of the battle partner of the support request source user (first user) and the monster character of the battle partner of the user (second user) who accepted the support request. Is different from the first embodiment in that it has a function of changing the HP (character data) of the monster character of the first user in accordance with the operation of the second user.
- FIG. 17 is a diagram exemplifying a series of web pages displayed on the communication terminal 10 of a user: ABC who has accepted support requests from a plurality of users, for example.
- step S20 of FIG. 17 the three monster characters that are their battle opponents are arranged in the sub areas 101 to 103 of the display area 100, respectively, and the two monsters that are the battle opponents of the other two users.
- An example in which characters are arranged and displayed in the sub-areas 201 and 202 of the display area 200 is shown.
- information (monster characters MC1, MC3) for specifying the monster character of another user is already provided to the communication terminal 10 of the user: ABC.
- a menu m25 in which the text “attacks most monsters” may be provided.
- This menu m25 is used to give an attack instruction to a monster character having the same attribute as that of any of the monster characters of the user: ABC battle opponent among the monster characters displayed on the web page. It is a menu.
- an attack instruction message is transmitted from the communication terminal 10 to the game server 20.
- the CPU 21 of the game server 20 has the same attribute as that of one of the monster characters of the user: ABC battle opponent among the monster characters provided to the user: ABC, and is the most.
- a monster character having the same attribute three monster characters MC1 in the example of step S21 in FIG.
- step S21 of FIG. 17 is displayed on the communication terminal 10 of user: ABC.
- a gauge G indicating HP is displayed on each of the three monster characters MC1.
- step S20 of FIG. 17 the user: ABC does not display the menu m25, and selects a monster character to be attacked by selecting one of the sub-regions. May be. According to this configuration, the user can select a monster character to be attacked while considering which monster character can support other users by attacking.
- the battle between a plurality of warrior cards and monster characters may be the same method as described in the first embodiment.
- the CPU 21 performs a process of reducing all the HP values of the three monster characters MC1 by consuming one attack point according to the attack power of the warrior card.
- the CPU 21 writes the HP value of the reduced monster character in the battle data in the RAM 23, determines the scale amount of the gauge G according to the value after the decrease, generates HTML data, and communicates with the user: ABC. Transmit to the terminal 10.
- step S22 of FIG. 17 a web page indicating that the HP of all three monster characters has decreased is displayed on the communication terminal 10 of user: ABC.
- the CPU 21 When the processing corresponding to the selection operation of the menu m25 is completed, the CPU 21 generates new HTML data for the related user so that the gauge indicating the monster character's HP is updated by the attack based on the operation by the user: ABC. Then send.
- the gauge indicating the HP of the monster character MC1 is updated.
- new HTML data is generated and transmitted to the user: ABC and the user: KNM.
- the web page shown in step S23 of FIG. 18 is displayed on the communication terminal 10 of the user: KNM and the user: ABC. Comparing step S20 in FIG.
- the HP of the monster character MC1 which is a battle opponent of both the user: ABC and the user: KNM
- the attack by the user: ABC user: (See gauge 101g displayed to KNM, user: 102g, 103g, 201g displayed to ABC).
- the user: KNM's battle opponent's monster character is displayed on the lower screen on the display screen presented to the user: KNM who requested the support, but the user: ABC's battle.
- the opponent's monster character is not displayed.
- the monster character of the user KNM's battle partner and the user: the monster character of the battle partner of the user who requested the support by a user other than KNM.
- the monster character of the battle partner of the user: ABC is displayed in the lower row. That is, in this embodiment, only a common monster character (enemy character) based on the support request is displayed on each user's display screen, and other monster characters (that is, their own battle opponent monster characters) are individually Only displayed on the user's display screen.
- a display screen differs between users and a virtual space is not shared between users.
- the monster character of the supporting user and the monster character of the requesting support user are the same according to the attack instruction from the supporting user. Attack is added to the attribute monster character. Therefore, according to the present embodiment, when a plurality of monster characters having different attributes appear on the game, the user attacks the monster character having the highest attack effect including the monster characters of other users. Will be added. Further, in the present embodiment, even when a plurality of monster characters having different attributes are set on the game, the user who has accepted the support request is the progress of the game of the support request source among his monster characters. The game can be advanced while recognizing the characters that can affect the game. That is, since it becomes a structure which makes a user judge about which monster character can support another user by attacking, the interest property of a game increases.
- the control means 524 receives the support request.
- a function of selecting any monster character based on the selection operation by may be provided. That is, when a plurality of support requests from other users are received, it is preferable that the user can select which monster character to select from among the monster characters provided by the support request. In that case, since the user who received the support request can select, for example, a monster character having the same attribute as the monster character that is his / her battle partner, it is easy to support other users.
- the function of the control means 524 described above can be realized as follows.
- the CPU 21 of the game server 20 receives a plurality of support request messages addressed to a specific user within a certain period of time, for example, the user of the support request source specified by the plurality of support request messages and the battle partner of the user HTML data for displaying information specifying the monster character in a list format is generated and transmitted to the communication terminal 10 of the user of the support request destination.
- the web page shown in FIG. 19 is displayed on the communication terminal 10 of the user of the support request destination.
- the CPU 21 selects the user to be supported based on the selection result (the user to whom the support request is accepted) ).
- Step S ⁇ b> 5 the user: KNM is configured to recognize the attribute of the monster character that is its battle opponent after selecting one of the users from the list for selecting the support request destination user.
- Step S6 Steps S5 and S6 may be reversed. That is, the configuration may be such that the user selects the user of the support request destination after confirming the attribute of the monster character that is the battle opponent of the user first. In that case, since the user already knows the monster character of his / her battle opponent, it is preferable that the user of the support request destination can be selected accordingly.
- the control means 524 provides information for identifying the monster characters of a plurality of users to the first user when a support request is made from the user (first user) who is the support request source. Then, based on the selection operation by the first user, one of the monster characters may be selected, and a user who uses the monster character as a battle partner may be determined as the support request destination user. For example, after the web page in step S6 of FIG. 11 is displayed, the web page shown in FIG. 20 is displayed on the communication terminal 10 of the user: KNM. This web page includes a list of information for identifying a plurality of users who are candidates for support requests and the monster characters of each user's battle opponent.
- KNM knows his / her battle opponent's monster character (monster character MC1 in step S6), the monster character having the same attribute as that monster character is selected from the list of FIG. Motivated to choose.
- a monster character with the same attribute it will not be a burden on the user who supports it (that is, his attack points will not be consumed only by attacking other users' monster characters) This is because the received user is highly likely to accept the support request.
- the function of the control means 524 described above can be realized as follows.
- the CPU 21 of the game server 20 updates the display so that the web page shown in step S6 is displayed.
- the CPU 21 updates the display so that the web page in step S5 of FIG. 20 is displayed.
- the user in the list displayed in FIG. 20 is a user who belongs to the user: KNM.
- the CPU 21 refers to the battle data in the RAM 23 when creating the list of fellow users, and acquires information for identifying the monster character of the fellow user's battle opponent.
- the user KNM selects the support request destination user.
- the providing unit 523 determines whether to accept the support request among a plurality of users (a plurality of users associated with the first user) of the first user (the user who requested the support) (that is, Inquiries about whether or not you wish to provide information that identifies the first user's monster character), requesting support for the user who first responded to accept (that is, to provide that information) You may specify as a previous user (2nd user). Thereby, it is possible to satisfy the desire of the user who has accepted the support request to help the fellow quickly.
- the CPU 21 of the game server 20 recognizes the selection operation of the menu m11 in the web page in step S4 in FIG. 11, the CPU 21 refers to the user data of the user: KNM without shifting to the web page in step S5.
- User: A support request message is transmitted to all the communication terminals 10 of KNM.
- a web page including menus m20 and m21 for selecting whether or not to accept the support request is displayed.
- the CPU 21 specifies the user who first performed the selection operation of the menu m20 in response to the support request message (that is, the user of the communication terminal 10 that first transmitted the acceptance message), and designates the user as the support request destination user.
- the support request message that is, the user of the communication terminal 10 that first transmitted the acceptance message
- the support request source user and the support request destination user are friends (associated users) is described. Absent.
- the user can also support other users who are not friends. However, the community between friends can be activated by limiting the support request destination to friends.
- the attribute of the monster character may be aurally different.
- a monster character displayed on the communication terminal 10 when a monster character displayed on the communication terminal 10 is selected and operated, a cry of the monster character is output. Then, an attack may be applied to the monster character that outputs the same cry between the monster character of the user who performs the support and the monster character of the user who requests the support, according to an attack instruction from the user who performs the support.
- the user's battle partner may be a warrior card of another user other than the user's friends.
- the game server 20 and the database server 30 on the network are configured to realize the functions of the respective units shown in FIG. 7, but the present invention is not limited to this configuration. 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. In that case, in the above-described embodiment, at least one of the user database, the monster character data, and the battle data is stored in the storage device (RAM 13 or HDD (Hard Disk Disk Drive) not shown) in the communication terminal 10 of each user. Large-capacity storage device) or another storage device on a network, for example.
- RAM 13 or HDD Hard Disk Disk Drive
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- General Business, Economics & Management (AREA)
- Information Transfer Between Computers (AREA)
- User Interface Of Digital Computer (AREA)
Abstract
ユーザ間で協力してゲームを進行させている感覚が得られるゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステムが提供される。このゲーム制御方法では、以下の処理が行われる。ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶装置に記憶させる。ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する。複数のユーザのうち第1のユーザのキャラクタの情報を、第1のユーザとは異なる第2のユーザに対して提供する。ここで、第2のユーザに対して第1のユーザのキャラクタの情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータと同時に、第1のユーザのキャラクタのキャラクタデータを変更する。
Description
本発明は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御する技術に関する。
近年、特定のサービス提供者によるソーシャルネットワーキングサービス(SNS)においてウェブブラウザ上で動作するAPI(Application Programming Interface)などの動作環境を基に作成されるゲーム用アプリケーションによって実行される、いわゆるソーシャルゲーム(Social Game)が普及している。ソーシャルゲームは、不特定多数のユーザ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言える。ユーザは、インターネットに接続可能であって、かつウェブブラウザが搭載された通信端末を備えていれば、時間と場所を問わずソーシャルゲームを楽しむことができる。
上述したソーシャルゲームでは、従来のオンラインゲームよりも、ユーザ間の交流を図るためのコミュニケーション機能が充実している点が特徴の1つとなっている。ソーシャルゲームでは、例えば、他のユーザ(仲間)との協力プレイのほか、仲間との挨拶や連絡など仲間とコミュニケーションを取ることによる情報交換、仲間との間のゲーム上のアイテムのプレゼントあるいはアイテムの交換が行なわれている。例えば、非特許文献1には、デジタルカードゲーム(ドラゴンコレクション(登録商標))において、ユーザが自らのゲームキャラクタを用いて他のゲームキャラクタとバトルを行うときに、仲間のゲームキャラクタを補助的に借りることが記載されている。
アプリSTYLE Vol.2(株式会社イースト・プレス)、26-27頁
上記非特許文献1に記載されているゲームでは、ユーザが他のユーザからゲームキャラクタを補助的に借りてバトルを行う場合、他のユーザからそのバトルにおける指示は存在せず、ユーザ間で協力してバトルを行っている感覚を味わうことはできない。つまり、ユーザが他のユーザからゲームキャラクタを補助的に借りてバトルを行ったとしても、そのバトルにおいてユーザ間で連携している感覚が得られないものとなっている。
本発明は上述した観点に鑑みてなされたもので、ユーザ間で協力してゲームを進行させている感覚が得られるゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステムを提供することを目的とする。
本発明の第1の観点は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御するゲーム制御装置である。
このゲーム制御装置は、
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶する記憶手段と、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する制御手段と、
前記複数のユーザのうち第1のユーザのキャラクタを特定する情報を、第1のユーザとは異なる第2のユーザに対して提供する提供手段と、
を備え、
前記制御手段は、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータと同時に、第1のユーザのキャラクタのキャラクタデータを変更する。
このゲーム制御装置は、
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶する記憶手段と、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する制御手段と、
前記複数のユーザのうち第1のユーザのキャラクタを特定する情報を、第1のユーザとは異なる第2のユーザに対して提供する提供手段と、
を備え、
前記制御手段は、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータと同時に、第1のユーザのキャラクタのキャラクタデータを変更する。
このゲーム制御装置において「キャラクタデータ」とは、キャラクタに関連するデータであって、ゲームの進行に応じて変更されうるデータである。キャラクタデータは、ゲームの性質によって様々な種別のデータを採りうるが、例えば対戦型ゲームの場合には、キャラクタデータは敵キャラクタの体力を示す値(HP)などであってよい。
このゲーム制御装置において「キャラクタを特定する情報」とは、ゲーム上の異なるキャラクタを区別できる情報、あるいはゲーム上のキャラクタを特定可能な情報であれば如何なるものでもよい。例えば、キャラクタを特定する情報は、キャラクタの外観を示す画像、キャラクタの名称を示すテキスト、または、キャラクタを特定するための識別コードなどであってよい。
このゲーム制御装置において「キャラクタ」とは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。
このゲーム制御装置において「キャラクタを特定する情報」とは、ゲーム上の異なるキャラクタを区別できる情報、あるいはゲーム上のキャラクタを特定可能な情報であれば如何なるものでもよい。例えば、キャラクタを特定する情報は、キャラクタの外観を示す画像、キャラクタの名称を示すテキスト、または、キャラクタを特定するための識別コードなどであってよい。
このゲーム制御装置において「キャラクタ」とは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。
このゲーム制御装置では、キャラクタデータがユーザの操作に応じて変更されながら、複数のユーザに対してユーザごとにゲームを進行させる。このゲーム制御装置ではさらに、第1のユーザのキャラクタを特定する情報が第2のユーザに提供された場合、第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータが変更されるのみならず、第1のユーザのキャラクタのキャラクタデータも変更される。これにより、第2のユーザの操作が第1のユーザのゲームの進行に対して直接的に影響を与えることができるため、第1のユーザと第2のユーザは、互いに協力してゲームを進行させている感覚を得ることができる。
ユーザのキャラクタは、対戦型ゲームの場合には敵キャラクタであってもよいが、ゲームの性質によって適宜設定しうる。例えば、複数のユーザの各々が植物等を育成させることを競うゲームの場合には、ユーザのキャラクタは、ユーザの育成対象となる植物のキャラクタであってもよい。
なお、このゲーム制御装置において、前記制御手段は、第1のユーザに提示する表示画面において第2のユーザのキャラクタを表示させず、第2のユーザに提示する表示画面において第1のユーザのキャラクタを表示させてもよい。
ユーザのキャラクタは、対戦型ゲームの場合には敵キャラクタであってもよいが、ゲームの性質によって適宜設定しうる。例えば、複数のユーザの各々が植物等を育成させることを競うゲームの場合には、ユーザのキャラクタは、ユーザの育成対象となる植物のキャラクタであってもよい。
なお、このゲーム制御装置において、前記制御手段は、第1のユーザに提示する表示画面において第2のユーザのキャラクタを表示させず、第2のユーザに提示する表示画面において第1のユーザのキャラクタを表示させてもよい。
上記ゲーム制御装置において、前記第2のユーザに提示する表示画面において、前記第1のユーザのキャラクタと前記第2のユーザのキャラクタの各々のキャラクタデータを表示させてもよい。これにより、第2のユーザは、自らの操作に基づく、自らのキャラクタのキャラクタデータの変更結果と、第1のユーザのキャラクタのキャラクタデータの変更結果とを視認することができるため、互いに協力してゲームを進行させている感覚を実感することができる。
上記ゲーム制御装置において、各ユーザのキャラクタは属性と対応付けられており、
前記制御手段は、前記第1のユーザのキャラクタと前記第2のユーザのキャラクタとが同じ属性である場合に、前記第2のユーザの操作に応じて前記第1のユーザのキャラクタのキャラクタデータを変更してもよい。
このゲーム制御装置において「キャラクタの属性」とは、例えばキャラクタの形態および/または色、模様、キャラクタそのものや能力を数値化したもの(レベル等)に加えて、キャラクタに設定された特定音(鳴き声等)など、キャラクタの違いを視覚的および/または聴覚的に区別可能な如何なる特性も含みうる。対戦型ゲームの場合、ユーザのキャラクタの属性は敵キャラクタの属性であってもよい。
このゲーム制御装置によれば、第2のユーザは、属性が異なる複数のキャラクタがゲーム上で設定されている場合であっても、自らのキャラクタのうち、第1のユーザのゲームの進行に対して影響を与えることができるキャラクタを認識しながらゲームを進めることができる。
前記制御手段は、前記第1のユーザのキャラクタと前記第2のユーザのキャラクタとが同じ属性である場合に、前記第2のユーザの操作に応じて前記第1のユーザのキャラクタのキャラクタデータを変更してもよい。
このゲーム制御装置において「キャラクタの属性」とは、例えばキャラクタの形態および/または色、模様、キャラクタそのものや能力を数値化したもの(レベル等)に加えて、キャラクタに設定された特定音(鳴き声等)など、キャラクタの違いを視覚的および/または聴覚的に区別可能な如何なる特性も含みうる。対戦型ゲームの場合、ユーザのキャラクタの属性は敵キャラクタの属性であってもよい。
このゲーム制御装置によれば、第2のユーザは、属性が異なる複数のキャラクタがゲーム上で設定されている場合であっても、自らのキャラクタのうち、第1のユーザのゲームの進行に対して影響を与えることができるキャラクタを認識しながらゲームを進めることができる。
上記ゲーム制御装置において、前記制御手段は、前記第2のユーザに対して複数のユーザのキャラクタを特定する情報が提供された場合には、前記第2のユーザによる選択操作に基づいて、いずれかのキャラクタを選択し、第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータとともに、選択したキャラクタのキャラクタデータを変更してもよい。つまり、いずれかのキャラクタを選択するかについては、第2のユーザが選択可能とする。それによって、第2のユーザは、例えば、自らのキャラクタと同一の属性のキャラクタを選択することができるため、他のユーザと協力してゲームを進行させやすくなる。
上記ゲーム制御装置において、前記複数のユーザの間の関連付けを記憶する第2の記憶手段、を備え、前記提供手段は、前記第1のユーザと関連付けられているユーザを前記第2のユーザとして特定してもよい。ユーザ間の関連付けは、ユーザ同士を例えば仲間として予め関係付けることによって行われてよい。このゲーム制御装置によって、協力してゲームを進行させるユーザは、予め関連付けられたユーザ同士に限定されるため、そのユーザ同士の関係をより強化することができる。これにより、例えば仲間の間のコミュニティの活性化を図ることができる。
上記ゲーム制御装置において、前記複数のユーザの間の関連付けを記憶する第2の記憶手段、を備え、前記提供手段は、前記第1のユーザと関連付けられている複数のユーザのうち、前記第1のユーザのキャラクタを特定する情報の提供を希望するか否かについて問い合わせをし、当該情報の提供を希望することを最初に回答したユーザを、前記第2のユーザとして特定してもよい。これにより、早く他のユーザと協力してゲームを進行させたい、というユーザの欲求を満たすことができる。
本発明の第2の観点は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御するゲーム制御装置である。
このゲーム制御装置は、
ゲーム上のユーザの敵キャラクタと、敵キャラクタのデータであるキャラクタデータとを対応付けて記憶する記憶手段と、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する制御手段と、
前記複数のユーザのうち第1のユーザの敵キャラクタを特定する情報を、第1のユーザとは異なる第2のユーザに対して提供する提供手段と、
を備え、
前記制御手段は、第2のユーザに対して第1のユーザの敵キャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザの敵キャラクタのキャラクタデータと同時に、第1のユーザの敵キャラクタのキャラクタデータを変更する。
このゲーム制御装置は、
ゲーム上のユーザの敵キャラクタと、敵キャラクタのデータであるキャラクタデータとを対応付けて記憶する記憶手段と、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する制御手段と、
前記複数のユーザのうち第1のユーザの敵キャラクタを特定する情報を、第1のユーザとは異なる第2のユーザに対して提供する提供手段と、
を備え、
前記制御手段は、第2のユーザに対して第1のユーザの敵キャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザの敵キャラクタのキャラクタデータと同時に、第1のユーザの敵キャラクタのキャラクタデータを変更する。
本発明の第3の観点は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御するゲーム制御方法である。
このゲーム制御方法は、
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶装置に記憶させるステップと、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更するステップと、
前記複数のユーザのうち第1のユーザのキャラクタを特定する情報を、第1のユーザとは異なる第2のユーザに対して提供するステップと、
を含み、
前記変更するステップは、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータと同時に、第1のユーザのキャラクタのキャラクタデータを変更することを特徴とする。
なお、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第1のユーザに提示する表示画面において第2のユーザのキャラクタを表示させず、第2のユーザに提示する表示画面において第1のユーザのキャラクタを表示させるステップを備えてもよい。
このゲーム制御方法は、
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶装置に記憶させるステップと、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更するステップと、
前記複数のユーザのうち第1のユーザのキャラクタを特定する情報を、第1のユーザとは異なる第2のユーザに対して提供するステップと、
を含み、
前記変更するステップは、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータと同時に、第1のユーザのキャラクタのキャラクタデータを変更することを特徴とする。
なお、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第1のユーザに提示する表示画面において第2のユーザのキャラクタを表示させず、第2のユーザに提示する表示画面において第1のユーザのキャラクタを表示させるステップを備えてもよい。
本発明の第4の観点は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御するために、コンピュータに、
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶装置に記憶させる機能と、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する機能と、
前記複数のユーザのうち第1のユーザのキャラクタを特定する情報を、第1のユーザとは異なる第2のユーザに対して提供する機能と、
を実現させるためのプログラムである。
このプログラムにおいて、前記変更する機能は、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータと同時に、第1のユーザのキャラクタのキャラクタデータを変更する。
なお、上記プログラムによって、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第1のユーザに提示する表示画面において第2のユーザのキャラクタを表示させず、第2のユーザに提示する表示画面において第1のユーザのキャラクタを表示させる機能が実現されてもよい。
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶装置に記憶させる機能と、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する機能と、
前記複数のユーザのうち第1のユーザのキャラクタを特定する情報を、第1のユーザとは異なる第2のユーザに対して提供する機能と、
を実現させるためのプログラムである。
このプログラムにおいて、前記変更する機能は、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータと同時に、第1のユーザのキャラクタのキャラクタデータを変更する。
なお、上記プログラムによって、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第1のユーザに提示する表示画面において第2のユーザのキャラクタを表示させず、第2のユーザに提示する表示画面において第1のユーザのキャラクタを表示させる機能が実現されてもよい。
コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、DVD-ROMやCD-ROM等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。すなわち、本発明の第5の観点は、前記プログラムを記録したことを特徴とする、コンピュータ読み取り可能な記録媒体である。
本発明の第6の観点は、ユーザによって操作される通信端末と、当該通信端末とネットワークを介して接続され、各ユーザの操作に応じて、各ユーザによるゲームの進行を制御するゲーム制御装置と、を備えたゲームシステムである。
このゲームシステムは、
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶する記憶手段、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する制御手段、及び、
前記複数のユーザのうち第1のユーザのキャラクタを特定する情報を、第1のユーザとは異なる第2のユーザに対して提供する提供手段、
の各手段を、前記通信端末又は前記サーバのいずれか一方が備え、
前記制御手段は、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータと同時に、第1のユーザのキャラクタのキャラクタデータを変更する。
なお、前記制御手段は、第1のユーザに提示する表示画面において第2のユーザのキャラクタを表示させず、第2のユーザに提示する表示画面において第1のユーザのキャラクタを表示させてもよい。
このゲームシステムは、
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶する記憶手段、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する制御手段、及び、
前記複数のユーザのうち第1のユーザのキャラクタを特定する情報を、第1のユーザとは異なる第2のユーザに対して提供する提供手段、
の各手段を、前記通信端末又は前記サーバのいずれか一方が備え、
前記制御手段は、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータと同時に、第1のユーザのキャラクタのキャラクタデータを変更する。
なお、前記制御手段は、第1のユーザに提示する表示画面において第2のユーザのキャラクタを表示させず、第2のユーザに提示する表示画面において第1のユーザのキャラクタを表示させてもよい。
本発明は、2011年12月19日に日本国特許庁に出願された特願2011-277722の特許出願に関連しており、当該出願の内容のすべてが参照によってこの明細書に組み込まれる。
(1)第1の実施形態
以下、第1の実施形態について説明する。
以下、第1の実施形態について説明する。
(1-1)ゲームシステムの構成
図1は、実施形態のゲームシステムのシステム構成例を示している。図1に示すように、このゲームシステムは、例えばインターネットなどの通信網NW(ネットワーク)に接続可能な通信端末10a,10b,10c,…と、通信網NWに接続されているゲームサーバ20と、データベースサーバ30とによって構成されている。各通信端末10a,10b,10c,…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、PDA(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機(いわゆる多機能型のスマートテレビも含む。)などの通信端末である。なお、以下の説明において、各通信端末10a,10b,10c,…に共通して言及するときには、通信端末10と表記する。
このゲームシステムにおいて、ゲームサーバ20は、クライアントである通信端末10と通信可能に構成されており、通信端末10に対してゲーミングサービスを提供する。ゲームサーバ20には、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ30は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ20と例えば有線で接続される。
通信端末10は、ゲームサーバ20によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末10をウェブページ上で操作してゲームを実行する。
図1は、実施形態のゲームシステムのシステム構成例を示している。図1に示すように、このゲームシステムは、例えばインターネットなどの通信網NW(ネットワーク)に接続可能な通信端末10a,10b,10c,…と、通信網NWに接続されているゲームサーバ20と、データベースサーバ30とによって構成されている。各通信端末10a,10b,10c,…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、PDA(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機(いわゆる多機能型のスマートテレビも含む。)などの通信端末である。なお、以下の説明において、各通信端末10a,10b,10c,…に共通して言及するときには、通信端末10と表記する。
このゲームシステムにおいて、ゲームサーバ20は、クライアントである通信端末10と通信可能に構成されており、通信端末10に対してゲーミングサービスを提供する。ゲームサーバ20には、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ30は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ20と例えば有線で接続される。
通信端末10は、ゲームサーバ20によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末10をウェブページ上で操作してゲームを実行する。
また、図1には図示していないが、ゲームサーバ20とは別に各通信端末10のユーザを認証するための認証サーバを設けてもよい。また、多くの通信端末10からのアクセスを受け入れるために複数のゲームサーバ20を設ける場合は、その複数のゲームサーバ20間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ20は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。
データベースサーバ30は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ20と例えば有線で接続される。
データベースサーバ30は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ20と例えば有線で接続される。
(1-2)通信端末の構成
図2A、図2B及び図3を参照して通信端末10について説明する。
図2A、図2Bはそれぞれ、通信端末10の外観の例を示す図であって、図2Aは、例えば折り畳み式の携帯端末(携帯電話機)などの釦入力方式の通信端末を例示したものであり、図2Bは、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図3は、通信端末10の内部構成を示すブロック図である。
図3に示すように、通信端末10は、CPU(Central Processing Unit)11、ROM(Read Only Memory)12、RAM(Random Access Memory)13、画像処理部14、指示入力部15、表示部16、及び、信号送受信部としての無線通信インタフェース部17を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス18が設けられている。
図2A、図2B及び図3を参照して通信端末10について説明する。
図2A、図2Bはそれぞれ、通信端末10の外観の例を示す図であって、図2Aは、例えば折り畳み式の携帯端末(携帯電話機)などの釦入力方式の通信端末を例示したものであり、図2Bは、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図3は、通信端末10の内部構成を示すブロック図である。
図3に示すように、通信端末10は、CPU(Central Processing Unit)11、ROM(Read Only Memory)12、RAM(Random Access Memory)13、画像処理部14、指示入力部15、表示部16、及び、信号送受信部としての無線通信インタフェース部17を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス18が設けられている。
CPU11は、ROM12内のウェブブラウザをRAM13にロードして実行する。そして、CPU11は、指示入力部15等によってユーザに入力されるURL(Uniform Resource Locator)の適切な指定に基づき、無線通信インタフェース部17を介して、ゲームサーバ20からウェブページを表示するためのデータ、すなわち、HTML(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ(以下、総称して適宜「HTMLデータ」と表記する。)を無線通信インタフェース部17を介して取得し、そのHTMLデータを解釈する。なお、通信端末10には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてよい。
なお、HTMLデータの取得に当たって、CPU11は、予め登録されたユーザID(ユーザ識別情報)、あるいは指示入力部15を介して入力されるユーザIDを含むアクセス要求メッセージを、無線通信インタフェース部17を介してゲームサーバ20へ通知する。
なお、HTMLデータの取得に当たって、CPU11は、予め登録されたユーザID(ユーザ識別情報)、あるいは指示入力部15を介して入力されるユーザIDを含むアクセス要求メッセージを、無線通信インタフェース部17を介してゲームサーバ20へ通知する。
ウェブブラウザは、画像処理部14を介して、取得したHTMLデータに基づき、ゲームサーバ20から提供されるウェブページを表示部16に表示する。また、ウェブブラウザは、ユーザが指示入力部15の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、その選択に応じたウェブページを表示するための新たなHTMLデータの送信(つまり、ウェブページの更新)をゲームサーバ20へ要求する。
画像処理部14は、HTMLデータの解析結果としてCPU11から与えられる表示用画像データに基づいて、表示部16にウェブページを表示する。表示部16は、例えば、マトリクス状に画素単位で配置された薄膜トランジスタを含むLCD(Liquid Cristal Display)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面16aに表示する。
通信端末10が釦入力方式の通信端末(図2A)である場合、指示入力部15は、ユーザの操作入力を受け入れるための方向指示釦と決定釦などの複数の指示入力釦を含む釦群15a、及び、テンキーなどの複数の指示入力釦を含む釦群15bを備え、各釦の押下(操作)入力を認識してCPU11へ出力するためのインタフェース回路を含む。例えば、方向指示釦は、表示部16に表示されているウェブページをスクロールして表示することをCPU11へ指示するために設けられる。また、決定釦は、例えばウェブページ上で複数のハイパーリンクまたはメニューが表示されるときに、アクティブ表示(例えば強調表示)されている1つのハイパーリンクまたはメニューをユーザが選択することをCPU11へ指示するために設けられる。なお、通信端末10を小型の携帯端末によって構成する場合には、これらの釦は、ユーザが通信端末10を片手で保持したままその親指で操作(クリック)しやすいように、通信端末10の前面に配置されていることが好ましい。図2Aに示す例では、釦群15bは、釦群15aの下方に配置され、「0」~「9」、「*」、「#」(テンキー)が表記された複数の指示入力釦を含む。
通信端末10がタッチパネル入力方式の通信端末(図2B)である場合、指示入力部15は、主として表示画面16aに指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよい。なお、図2Bに示すように、通信端末10がタッチパネル入力方式の場合であっても釦群15aが設けられる場合もある。
通信端末10に表示されるウェブページ上のメニューの選択操作は、例えば通信端末10が携帯端末である場合には、方向指示釦の押下操作によってメニューを選択し、決定釦の押下操作によって、選択したメニューを確定することによって行われる。また、選択操作は、例えば通信端末10がタッチパネル入力方式の場合には、ウェブページが表示されている表示画面16a上のメニューの位置を指あるいはペンで指示(タッチ操作)することによって行われる。
(1-3)ゲームサーバの構成
図4を参照してゲームサーバ20の構成について説明する。
ゲームサーバ20は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末10に対してゲームのウェブサービスを提供する。図3に示すように、ゲームサーバ20は、CPU21、ROM22、RAM23、データベース(DB)アクセス部24、及び、無線通信インタフェース部25を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス26が設けられている。なお、ゲームサーバ20は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。
図4を参照してゲームサーバ20の構成について説明する。
ゲームサーバ20は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末10に対してゲームのウェブサービスを提供する。図3に示すように、ゲームサーバ20は、CPU21、ROM22、RAM23、データベース(DB)アクセス部24、及び、無線通信インタフェース部25を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス26が設けられている。なお、ゲームサーバ20は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。
ROM22には、クライアントである通信端末10のウェブブラウザに対してHTML文書や画像などのオブジェクトの表示(ウェブページの表示)のサービスを提供するアプリケーションプログラムが格納されている。ROM22には、アプリケーションプログラム以外にもCPU21によって参照される各種データが格納されている。
CPU21は、ROM22内のゲームプログラムをRAM23にロードして実行し、無線通信インタフェース部25を介して、各種の処理を行う。
CPU21は、ROM22内のゲームプログラムをRAM23にロードして実行し、無線通信インタフェース部25を介して、各種の処理を行う。
例えば、CPU21は、無線通信インタフェース部25を介して、HTMLデータを通信端末10宛に送信する。なお、ゲームサーバ20が通信端末10のユーザの認証処理を行う場合には、CPU21はその認証処理を行う。
CPU21は、通信インタフェース部を介して、通信端末10で表示されるウェブページ上でユーザにより選択されたハイパーリンクまたはメニューに応じた処理を行う。その処理は、例えば、新たなHTMLデータの送信、または、ゲームサーバ20内の演算処理あるいはデータ処理などを含む。
データベースアクセス部24は、CPU21がデータベースサーバ30に対してデータの読み書きを行うときのインタフェースである。
CPU21は、通信インタフェース部を介して、通信端末10で表示されるウェブページ上でユーザにより選択されたハイパーリンクまたはメニューに応じた処理を行う。その処理は、例えば、新たなHTMLデータの送信、または、ゲームサーバ20内の演算処理あるいはデータ処理などを含む。
データベースアクセス部24は、CPU21がデータベースサーバ30に対してデータの読み書きを行うときのインタフェースである。
(1-4)データベースサーバの構成
データベースサーバ30は、大容量のハードディスク装置やRAID(Redundant Arrays of Inexpensive Disks)等の形態の装置等、汎用ストレージで実現できる。データベースサーバ30内の各データベースは、ゲームサーバ20のデータベースアクセス部24を介してCPU21からのデータの読み書きが可能となるように構成されている。
図5に、データベースサーバ30の構成の一例を示す。図5に示すように、データベースサーバ30は、ユーザデータベース31と、ゲームデータベース32とを備える。
データベースサーバ30は、大容量のハードディスク装置やRAID(Redundant Arrays of Inexpensive Disks)等の形態の装置等、汎用ストレージで実現できる。データベースサーバ30内の各データベースは、ゲームサーバ20のデータベースアクセス部24を介してCPU21からのデータの読み書きが可能となるように構成されている。
図5に、データベースサーバ30の構成の一例を示す。図5に示すように、データベースサーバ30は、ユーザデータベース31と、ゲームデータベース32とを備える。
本実施形態のゲームサーバ20によって実現されるゲームのタイプは特に限定されるものではないが、以下では、実施形態の説明の便宜上、ゲームサーバ20によって実現されるゲームの一例として、ユーザの通信端末10に対する操作に応じて、ユーザがゲーム上で仮想的に保有する戦士カードを使い、ゲーム上のモンスターであるモンスターキャラクタとバトルを行う対戦型デジタルカードゲームを採り上げる。
このデジタルカードゲームは、ユーザが戦士カードを収集することによって自らのチーム(軍隊)を作り上げ、例えば、他のユーザのチーム(軍隊)やモンスターキャラクタとバトルを行うように構成されているゲームである。このデジタルカードゲームには、自らのチームを作り上げていくために戦士カードを探索するミッション遂行処理や、抽選によって戦士カードを入手することを可能とする抽選処理、あるいは2枚以上の戦士カードを一体化して戦士カードの能力を上昇させる強化処理等が設けられている。
このデジタルカードゲームは、ユーザが戦士カードを収集することによって自らのチーム(軍隊)を作り上げ、例えば、他のユーザのチーム(軍隊)やモンスターキャラクタとバトルを行うように構成されているゲームである。このデジタルカードゲームには、自らのチームを作り上げていくために戦士カードを探索するミッション遂行処理や、抽選によって戦士カードを入手することを可能とする抽選処理、あるいは2枚以上の戦士カードを一体化して戦士カードの能力を上昇させる強化処理等が設けられている。
図6に、上述した対戦型デジタルカードゲームにおいて適用されるユーザデータベース31の一例を示す。この例では、ユーザデータベース31は、ユーザID(ユーザ識別情報)ごとに、表示名/表示画像、技能レベル、体力ポイント、攻撃ポイント、強化ポイント、友情ポイント、戦士数、所持コイン、仲間のユーザID、保有カードの画像データ、及び保有カードのパラメータの各項目についての情報を含む。ユーザデータベース31に含まれる情報は、ゲームサーバ20によって逐次更新されうる。
以下の説明では、ユーザデータベース31に含まれるユーザID、あるいはユーザを特定する表示名(後述する)ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・表示名/表示画像
ゲームの実行時に通信端末10のユーザを特定するために表示される表示名及び表示画像である。表示名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。表示名は、ゲームサーバ20によって提供されるネットワーク環境(あるいはゲームコミュニティ)上でユーザを特定する名称である。
・技能レベル
ゲーム上のユーザの技能レベル示すデータである。例えばLv1(レベル1)からLv100(レベル100)までの範囲のレベル値である。
・体力ポイント
上記対戦型デジタルカードゲームにおいて、ユーザによるゲーム上のミッション遂行を行う上で必要となるポイントである。体力ポイントは、ミッション遂行を行うことで低減し、所定の時間が経過する毎に回復(増加)する値である。
・攻撃ポイント
上記対戦型デジタルカードゲームにおいて、ユーザによるゲーム上のバトルを行う上で必要となるポイントである。攻撃ポイントは、他のユーザ、あるいはモンスターキャラクタとのバトルによって低減し、所定の時間が経過する毎に回復(増加)する値である。
・強化ポイント
上記対戦型デジタルカードゲームにおいて、ユーザによる戦士カードの強化を行う上で必要となるポイントである。強化ポイントは、戦士カードの強化を行うことで低減し、他のユーザとのバトルで勝利するか、あるいは所定の時間が経過する毎に回復(増加)する値である。
・友情ポイント
上記対戦型デジタルカードゲームにおいて、仲間へ応援メッセージを送信することでユーザが取得するポイントである。
・戦士数
ユーザが保有する戦士カードの数である。戦士数は、ミッション遂行処理や強化処理の実行によって増減する。戦士数の最大値(例えば、60)は予め規定されている。
・所持コイン
ユーザIDに対応するユーザがゲーム上で有料機能を利用するときに必要となるゲーム上の仮想通貨(コイン)の所持額である。所持コインは、ユーザがゲーム上で有料機能を利用したときに消費(低減)し、ユーザが、サービス提供者等に所定の方法で実際の金銭を支払うことでその支払額に応じて増加する。
・仲間のユーザID
対象となるユーザIDと予め関連付けられた他のユーザIDのデータである。
・保有カードの画像データ
上記対戦型デジタルカードゲームの場合、保有カードの画像データは、ユーザが保有する戦士カードについての画像を含むデータである。
・保有カードのパラメータ
保有カードのパラメータは、戦士カードの能力値を示すデータである。例えば、図6に示すように、パラメータの項目として「攻撃力」,「防御力」の各々の各能力値、及び「必要ポイント」が含まれてもよい。「必要ポイント」は、戦士カードをバトルで使用するときに必要となるポイントである。このゲームでは、バトルで使用する戦士カードの必要ポイントの総計が攻撃ポイント以下となるように制限されてもよい。
・表示名/表示画像
ゲームの実行時に通信端末10のユーザを特定するために表示される表示名及び表示画像である。表示名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。表示名は、ゲームサーバ20によって提供されるネットワーク環境(あるいはゲームコミュニティ)上でユーザを特定する名称である。
・技能レベル
ゲーム上のユーザの技能レベル示すデータである。例えばLv1(レベル1)からLv100(レベル100)までの範囲のレベル値である。
・体力ポイント
上記対戦型デジタルカードゲームにおいて、ユーザによるゲーム上のミッション遂行を行う上で必要となるポイントである。体力ポイントは、ミッション遂行を行うことで低減し、所定の時間が経過する毎に回復(増加)する値である。
・攻撃ポイント
上記対戦型デジタルカードゲームにおいて、ユーザによるゲーム上のバトルを行う上で必要となるポイントである。攻撃ポイントは、他のユーザ、あるいはモンスターキャラクタとのバトルによって低減し、所定の時間が経過する毎に回復(増加)する値である。
・強化ポイント
上記対戦型デジタルカードゲームにおいて、ユーザによる戦士カードの強化を行う上で必要となるポイントである。強化ポイントは、戦士カードの強化を行うことで低減し、他のユーザとのバトルで勝利するか、あるいは所定の時間が経過する毎に回復(増加)する値である。
・友情ポイント
上記対戦型デジタルカードゲームにおいて、仲間へ応援メッセージを送信することでユーザが取得するポイントである。
・戦士数
ユーザが保有する戦士カードの数である。戦士数は、ミッション遂行処理や強化処理の実行によって増減する。戦士数の最大値(例えば、60)は予め規定されている。
・所持コイン
ユーザIDに対応するユーザがゲーム上で有料機能を利用するときに必要となるゲーム上の仮想通貨(コイン)の所持額である。所持コインは、ユーザがゲーム上で有料機能を利用したときに消費(低減)し、ユーザが、サービス提供者等に所定の方法で実際の金銭を支払うことでその支払額に応じて増加する。
・仲間のユーザID
対象となるユーザIDと予め関連付けられた他のユーザIDのデータである。
・保有カードの画像データ
上記対戦型デジタルカードゲームの場合、保有カードの画像データは、ユーザが保有する戦士カードについての画像を含むデータである。
・保有カードのパラメータ
保有カードのパラメータは、戦士カードの能力値を示すデータである。例えば、図6に示すように、パラメータの項目として「攻撃力」,「防御力」の各々の各能力値、及び「必要ポイント」が含まれてもよい。「必要ポイント」は、戦士カードをバトルで使用するときに必要となるポイントである。このゲームでは、バトルで使用する戦士カードの必要ポイントの総計が攻撃ポイント以下となるように制限されてもよい。
図5に戻り、ゲームデータベース32は、ゲームサーバ20からのアクセスに基づき、ゲームサーバ20によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。対戦型デジタルカードゲームの場合を例に挙げれば、ゲームの進行に関する情報は、異なるユーザ同士のバトルの結果や、後述する掘削実行処理の処理結果などを含む。
(1-5)ゲーム制御装置における各処理の概要
本実施形態では、ゲームサーバ20及びデータベースサーバ30によってゲーム制御装置が構成されている。以下では、上述した対戦型デジタルカードゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図7を参照して説明する。図7は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
なお、以下の説明において、通信端末10に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末10で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦によるウェブページのスクロール操作によって変化しうる。
本実施形態では、ゲームサーバ20及びデータベースサーバ30によってゲーム制御装置が構成されている。以下では、上述した対戦型デジタルカードゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図7を参照して説明する。図7は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
なお、以下の説明において、通信端末10に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末10で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦によるウェブページのスクロール操作によって変化しうる。
登録手段51は、例えば通信端末10に提供するウェブページ上での通信端末10への適切な操作入力に基づいてユーザの要求を認識し、登録処理を行う。この場合の登録手段51は、例えば以下のとおり実行される。ゲームサーバ20のCPU21は、無線通信インタフェース部25を介して通信端末10から登録要求メッセージを受信する。登録要求メッセージは、ゲームサーバ20から提供されるウェブページ上での通信端末10に対する所定の操作(例えば、所定のメニューの選択操作、テキスト入力等)によって自動的に生成されるように、ウェブページが構成されていてもよい。登録要求メッセージには、送信元の通信端末10を特定するための情報(例えばIPアドレス、メールアドレス等)が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザIDが含まれていてもよい。
CPU21は、登録要求メッセージを受信し、登録要求メッセージにユーザIDが含まれていない場合には、ユーザIDを新規に発行してそのユーザIDの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末10へ送信する。CPU21は、登録要求メッセージを受信し、登録要求メッセージにユーザIDが含まれている場合には、そのユーザIDの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末10へ送信する。
登録が完了すると、CPU21は、ユーザIDに対応するユーザデータを生成し、ユーザデータベース31に格納する。
CPU21は、登録要求メッセージを受信し、登録要求メッセージにユーザIDが含まれていない場合には、ユーザIDを新規に発行してそのユーザIDの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末10へ送信する。CPU21は、登録要求メッセージを受信し、登録要求メッセージにユーザIDが含まれている場合には、そのユーザIDの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末10へ送信する。
登録が完了すると、CPU21は、ユーザIDに対応するユーザデータを生成し、ユーザデータベース31に格納する。
登録手段51はまた、ユーザIDに基づく申請を契機として当該ユーザIDを他のユーザIDとを関連付けて登録してもよい。すなわち、登録手段51は、ユーザIDに基づく申請を契機として、他のユーザID(つまり、他のユーザ)を「仲間」として登録する。
この場合の登録手段51は例えば、以下のとおり実行される。ゲームサーバ20のCPU21は、無線通信インタフェース部25を介して、あるユーザIDに対応するユーザの通信端末10から、仲間になりたいユーザID(あるいは、対応する表示名)を指定した申請メッセージ(申請)を受け付ける。この申請メッセージの送信は、ユーザの通信端末10に提供されるウェブページの機能として予め設定されている。CPU21は、申請メッセージを受け付けると、申請メッセージに含まれるユーザIDに基づくアクセスがあったタイミングで、そのユーザIDに対応する通信端末10宛に、他のユーザIDに基づく申請を承認するか否かを返信することを要求するためのウェブページを表示させるHTMLデータを送信する。その申請を承認することが返信されれば、CPU21は、両者を仲間として登録する。具体的には、CPU21は、ユーザデータベース31内の対応する2つのユーザIDのユーザデータの「仲間」の箇所(図6参照)にデータを書き込む。
この場合の登録手段51は例えば、以下のとおり実行される。ゲームサーバ20のCPU21は、無線通信インタフェース部25を介して、あるユーザIDに対応するユーザの通信端末10から、仲間になりたいユーザID(あるいは、対応する表示名)を指定した申請メッセージ(申請)を受け付ける。この申請メッセージの送信は、ユーザの通信端末10に提供されるウェブページの機能として予め設定されている。CPU21は、申請メッセージを受け付けると、申請メッセージに含まれるユーザIDに基づくアクセスがあったタイミングで、そのユーザIDに対応する通信端末10宛に、他のユーザIDに基づく申請を承認するか否かを返信することを要求するためのウェブページを表示させるHTMLデータを送信する。その申請を承認することが返信されれば、CPU21は、両者を仲間として登録する。具体的には、CPU21は、ユーザデータベース31内の対応する2つのユーザIDのユーザデータの「仲間」の箇所(図6参照)にデータを書き込む。
ゲーム進行手段52は、通信端末10に対するユーザの操作に応じて、通信端末10に表示されるウェブページを逐次更新するためのHTMLデータを送信することで、ゲームを進行させる。対戦型デジタルカードゲーム(以下、適宜単に「ゲーム」と略記する。)の例では、ゲームを進行させる上で以下の処理が行われうる。
・ミッション遂行処理:
自らのチームを作り上げていくためにミッションを遂行して戦士カードを得る処理である。このゲームでは、ミッションを遂行するには、一定量の行動ポイントが必要となる。
・強化処理:
2人以上の戦士カードを一体化して特定の戦士の能力を上昇させる処理である。このゲームでは、ユーザが強化処理を実行するには一定量の強化ポイントが必要となる。
・バトル実行処理:
他のユーザのチームとバトルを行う処理である。
・抽選処理:
ユーザが戦士カードを入手するための抽選を行う処理である。
・掘削実行処理:
ユーザの操作に応じて土地を掘削し、その土地のモンスターキャラクタを倒すことによって土地を攻略するプレイを実行する処理である(後述する)。
・ミッション遂行処理:
自らのチームを作り上げていくためにミッションを遂行して戦士カードを得る処理である。このゲームでは、ミッションを遂行するには、一定量の行動ポイントが必要となる。
・強化処理:
2人以上の戦士カードを一体化して特定の戦士の能力を上昇させる処理である。このゲームでは、ユーザが強化処理を実行するには一定量の強化ポイントが必要となる。
・バトル実行処理:
他のユーザのチームとバトルを行う処理である。
・抽選処理:
ユーザが戦士カードを入手するための抽選を行う処理である。
・掘削実行処理:
ユーザの操作に応じて土地を掘削し、その土地のモンスターキャラクタを倒すことによって土地を攻略するプレイを実行する処理である(後述する)。
表示手段521は、ゲームで実行される上記複数の処理が各々割り当てられた複数のメニューを通信端末10に表示させる機能を備える。具体的には、CPU21は、複数のメニューを含むウェブページを表示するためのHTMLデータを生成して通信端末10宛に送信する。ゲームでは、ミッション遂行処理、強化処理、バトル実行処理、及び抽選処理の各処理の実行に伴ってゲーム上のポイントが消費される。
表示手段521によって通信端末10に表示されるゲームのトップページの例を図8に示す。このトップページは、個々のユーザIDに応じたウェブページで構成される。図8に例示されるトップページは、ユーザデータ表示領域、戦士画像表示領域及びメニュー表示領域を含む。
ユーザデータ表示領域は、対象となるユーザIDのユーザデータに含まれる、技能レベル、体力ポイント、攻撃ポイント、強化ポイント、友情ポイント、戦士数、仲間の各項目のデータ(図6参照)が表示される領域である。なお、ユーザデータ表示領域に表示される項目で、X/Yの形式で表記されているポイントまたは数は、Xがユーザの保有するポイントまたは数であり、Yがそのポイントまたは数の最大値であることを示す。例えば、戦士数が「40/60」と表記されていれば、ユーザが保有する戦士カードが40枚であり、最大で保有可能な戦士カードの枚数が60枚であることを示す。
戦士画像表示領域は、対象となるユーザIDのユーザデータに含まれる複数の戦士カードのうちユーザによって予め指定された戦士カードの画像が表示される領域である。
メニュー表示領域は、対戦型デジタルカードゲームに設けられる複数の機能(ミッション遂行処理、強化処理、バトル実行処理、抽選処理、掘削実行処理)に対応した基本メニューとして、「ミッション」、「強化」、「バトル」、「抽選」、「掘削」のテキストが表記された各メニューm1~m5が表示される領域である。つまり、ゲームで実行される複数の処理が各々割り当てられた複数のメニューが、通信端末10に表示されるウェブページの所定の位置にそれぞれ配置される。
ユーザデータ表示領域は、対象となるユーザIDのユーザデータに含まれる、技能レベル、体力ポイント、攻撃ポイント、強化ポイント、友情ポイント、戦士数、仲間の各項目のデータ(図6参照)が表示される領域である。なお、ユーザデータ表示領域に表示される項目で、X/Yの形式で表記されているポイントまたは数は、Xがユーザの保有するポイントまたは数であり、Yがそのポイントまたは数の最大値であることを示す。例えば、戦士数が「40/60」と表記されていれば、ユーザが保有する戦士カードが40枚であり、最大で保有可能な戦士カードの枚数が60枚であることを示す。
戦士画像表示領域は、対象となるユーザIDのユーザデータに含まれる複数の戦士カードのうちユーザによって予め指定された戦士カードの画像が表示される領域である。
メニュー表示領域は、対戦型デジタルカードゲームに設けられる複数の機能(ミッション遂行処理、強化処理、バトル実行処理、抽選処理、掘削実行処理)に対応した基本メニューとして、「ミッション」、「強化」、「バトル」、「抽選」、「掘削」のテキストが表記された各メニューm1~m5が表示される領域である。つまり、ゲームで実行される複数の処理が各々割り当てられた複数のメニューが、通信端末10に表示されるウェブページの所定の位置にそれぞれ配置される。
例えば図8に示すトップページをユーザの通信端末10に表示する場合、ゲーム進行手段52は以下のようにして実現される。ゲームサーバ20のCPU21は、データベースアクセス部24を介してユーザデータベース31にアクセスし、ユーザデータ表示領域に含まれる各項目のデータと、戦士画像表示領域に表示すべき戦士カードの画像データを読み出す。次にCPU21は、図8に示したトップページが構成されるようにHTMLデータを生成し、通信端末10宛に送信する。生成されるHTMLデータは、ユーザごと(つまり、ユーザIDごと)に異なるものとなる。通信端末10は、受信したHTMLデータを解釈してトップページの画像を表示部16(表示画面16a)に表示する。
ゲーム進行手段52は、通信端末10に表示されたメニューm1~m5のいずれかに対するユーザの選択操作に応じて、それぞれミッション遂行処理、強化処理、バトル実行処理、抽選処理、及び、掘削実行処理を実行する。好ましくは、各処理が実行された場合、さらに細分化された複数のメニューを含む新たなウェブページが表示されるように、階層的に各処理が実行される。
ゲーム進行手段52は、通信端末10に表示されたメニューm1~m5のいずれかに対するユーザの選択操作に応じて、それぞれミッション遂行処理、強化処理、バトル実行処理、抽選処理、及び、掘削実行処理を実行する。好ましくは、各処理が実行された場合、さらに細分化された複数のメニューを含む新たなウェブページが表示されるように、階層的に各処理が実行される。
[掘削実行処理]
上述したように、ゲーム進行手段52は、ユーザ単位で掘削実行処理を実行し、ユーザの操作に応じてキャラクタデータが変化しうるキャラクタを用いてゲームを進行させる機能を備える。ゲーム進行手段52における掘削実行処理の機能及びその実現方法について、以下で詳しく説明する。
上述したように、ゲーム進行手段52は、ユーザ単位で掘削実行処理を実行し、ユーザの操作に応じてキャラクタデータが変化しうるキャラクタを用いてゲームを進行させる機能を備える。ゲーム進行手段52における掘削実行処理の機能及びその実現方法について、以下で詳しく説明する。
掘削実行処理時には、ゲーム上のモンスターキャラクタのデータがCPU21によって参照される。図9は、モンスターキャラクタのデータの内容を例示するものであり、掘削実行処理の実行とともに例えばRAM23にロードされ、記憶されるデータである。このデータは、ゲームデータベース32に記憶させておいてもよい。図9では、一例として属性が異なる3種類のモンスターキャラクタMC1~MC3の各々について、モンスターキャラクタのパラメータとしてレベル(Lv)、攻撃力の値、守備力の値、及び、モンスターキャラクタのHPの値(体力を示す値;キャラクタデータ)が示されている。モンスターキャラクタのレベルが大きくなるほど、そのモンスターキャラクタの攻撃力の値、守備力の値、及びHPの値が大きくなるように設定されてもよい。図9では、属性が異なる3種類のモンスターキャラクタを示しているが、本実施形態では、モンスターキャラクタは少なくとも1種類設けられていればよい。なお、図9において、モンスターキャラクタの画像は、モンスターキャラクタの属性の一例である。
掘削実行処理によるゲームの流れは、以下のとおりである。
掘削実行処理は、掘削モードとバトルモードの各ゲームの処理を含む。掘削モードでは、ユーザの操作に応じて、複数の区画の土地が順に掘り進められ(掘削され)、各区画を掘り終わると、モンスターキャラクタが出現する。モンスターキャラクタが出現した場合には、ユーザの通信端末10に対する操作に応じて、ユーザが保有する戦士カードと、出現したモンスターキャラクタとの間で、バトルを行うバトルモードに移行する。戦士カードの攻撃によってモンスターキャラクタのHP(体力を示す値)がゼロになると、モンスターキャラクタは倒されてモンスターキャラクタが出現した区画の土地が攻略されたことになり、ユーザの掘削対象の土地の区画は、次の区画に移る。逆に、モンスターキャラクタの攻撃によって戦士カードの体力が無くなると、そのモンスターキャラクタが出現した区画の土地の攻略が失敗したことになり、モンスターキャラクタはその区画から無くならない。その場合、ユーザは、戦士カードの体力が回復した後に、再度同じモンスターキャラクタとバトルを行うことになる。
掘削実行処理は、掘削モードとバトルモードの各ゲームの処理を含む。掘削モードでは、ユーザの操作に応じて、複数の区画の土地が順に掘り進められ(掘削され)、各区画を掘り終わると、モンスターキャラクタが出現する。モンスターキャラクタが出現した場合には、ユーザの通信端末10に対する操作に応じて、ユーザが保有する戦士カードと、出現したモンスターキャラクタとの間で、バトルを行うバトルモードに移行する。戦士カードの攻撃によってモンスターキャラクタのHP(体力を示す値)がゼロになると、モンスターキャラクタは倒されてモンスターキャラクタが出現した区画の土地が攻略されたことになり、ユーザの掘削対象の土地の区画は、次の区画に移る。逆に、モンスターキャラクタの攻撃によって戦士カードの体力が無くなると、そのモンスターキャラクタが出現した区画の土地の攻略が失敗したことになり、モンスターキャラクタはその区画から無くならない。その場合、ユーザは、戦士カードの体力が回復した後に、再度同じモンスターキャラクタとバトルを行うことになる。
掘削実行処理における掘削モードの流れについて、図10を参照して説明する。図10では、操作を行うユーザが「KNM」(以下、ユーザ:KNMと表記する。)である場合を一例として示している。図10のステップS1~S3は、掘削モードにおけるユーザの通信端末10に表示されるウェブページの例を順に示している。
先ず、図8のトップページにおいてユーザによってメニューm5が選択操作されると、掘削実行処理のトップページがユーザの通信端末10に表示されるように、HTMLデータを生成して通信端末10宛に送信する(図10,ステップS1)。図10のステップS1は、掘削実行処理におけるトップページであり、後述するバトルモードにおいて、自らのバトル相手となるモンスターキャラクタを例えば最大で3体、表示可能とするための表示領域100と、他のユーザのバトル相手となるモンスターキャラクタを例えば最大で3体、表示可能とするための表示領域200とを含む。
先ず、図8のトップページにおいてユーザによってメニューm5が選択操作されると、掘削実行処理のトップページがユーザの通信端末10に表示されるように、HTMLデータを生成して通信端末10宛に送信する(図10,ステップS1)。図10のステップS1は、掘削実行処理におけるトップページであり、後述するバトルモードにおいて、自らのバトル相手となるモンスターキャラクタを例えば最大で3体、表示可能とするための表示領域100と、他のユーザのバトル相手となるモンスターキャラクタを例えば最大で3体、表示可能とするための表示領域200とを含む。
このトップページ上の「開始」のメニューm7が選択操作されたことをCPU21が認識すると、ユーザの通信端末10に表示されるウェブページは、所定数(図10では10個)の区画の土地を表す表示画像300と、対象となる区画の土地の掘削率を表す表示画像350と、「掘る」のメニューm8とを含むものに移行する(図10,ステップS2)。表示画像300では、ユーザの掘削の対象となる区画の土地が区画301であることが視認可能に表される。ここで、「掘る」のメニューm8が選択操作されたことをCPU21が認識すると、その都度、表示画像350に表示されている「掘削率」(%)の値がランダムな増加量にて増加して表示される。表示画像350に表示されている「掘削率」(%)が100%になると、その区画の土地の掘削が完了したことになる(図10,ステップS3)。
なお、「掘る」のメニューm8が選択操作される度に、ユーザの体力ポイントが一定量消費され、体力ポイントがゼロになった場合には掘削を続けることはできない。その場合には、体力ポイントが回復するまで待機する必要がある。
なお、「掘る」のメニューm8が選択操作される度に、ユーザの体力ポイントが一定量消費され、体力ポイントがゼロになった場合には掘削を続けることはできない。その場合には、体力ポイントが回復するまで待機する必要がある。
掘削率が100%に達してバトルモードに移行したときに通信端末10に表示されるウェブページの一例を図11に示す。図11のステップS4に示すように、出現したモンスターキャラクタの画像及びそのレベル(図11ではLv8)が表示されるとともに、その出現したモンスターキャラクタに対して、ユーザ1人で戦うことを選択するためのメニューm10と、仲間のユーザに対してバトルの支援要請を行うためのメニューm11とが表示される。
提供手段523は、第1のユーザとは異なる第2のユーザの通信端末10に対し、第1のユーザのモンスターキャラクタ(つまり、第1のユーザのバトル相手であるモンスターキャラクタ;敵キャラクタ)の情報を提供する機能を備える。つまり、提供手段523は、第2のユーザが、自らのバトル相手であるモンスターキャラクタに加えて、他のユーザである第1のユーザのバトル相手であるモンスターキャラクタをも同時に攻撃を加えられるように、第1のユーザのモンスターキャラクタを特定する情報を第2のユーザの通信端末10に提供する機能を備える。以降の説明では、ユーザ:KNMが「第1のユーザ」に相当し、ユーザ:ABCが「第2のユーザ」に相当する。
なお、以下では、第1のユーザの通信端末10に対する操作に応じて、第1のユーザの通信端末10からゲームサーバ20宛に支援要請を行うための支援要請メッセージが送信されたことを契機として、提供手段523の機能が実現される場合について説明するが、これに限られない。支援要請メッセージは、バトルモードに移行するとともに自動的に、ゲームサーバ20から仲間のユーザの通信端末10宛に送信されるようにしてもよい。
なお、以下では、第1のユーザの通信端末10に対する操作に応じて、第1のユーザの通信端末10からゲームサーバ20宛に支援要請を行うための支援要請メッセージが送信されたことを契機として、提供手段523の機能が実現される場合について説明するが、これに限られない。支援要請メッセージは、バトルモードに移行するとともに自動的に、ゲームサーバ20から仲間のユーザの通信端末10宛に送信されるようにしてもよい。
図11を参照すると、提供手段523の機能は、具体的に以下のとおり実現される。
ゲームサーバ20のCPU21は、図11のステップS4に示すウェブページにおいてメニューm11が選択されたことを認識すると、ユーザ:KNMのユーザデータを参照してユーザ:KNMの仲間を特定し、その特定した仲間を選択可能な形式で表示するためのHTMLデータをユーザ:KNMの通信端末10宛に送信する。これにより、ユーザ:KNMの通信端末10には、図11のステップS5に示すウェブページが表示される。このウェブページにおいて、ステップS5のウェブページのリスト上で、支援要請先のユーザとして、ユーザ:ABCが選択された場合を例として、以下説明していく。
ゲームサーバ20のCPU21は、図11のステップS4に示すウェブページにおいてメニューm11が選択されたことを認識すると、ユーザ:KNMのユーザデータを参照してユーザ:KNMの仲間を特定し、その特定した仲間を選択可能な形式で表示するためのHTMLデータをユーザ:KNMの通信端末10宛に送信する。これにより、ユーザ:KNMの通信端末10には、図11のステップS5に示すウェブページが表示される。このウェブページにおいて、ステップS5のウェブページのリスト上で、支援要請先のユーザとして、ユーザ:ABCが選択された場合を例として、以下説明していく。
ユーザ:KNMの通信端末10から、支援要請先のユーザとしてユーザ:ABCを指定した支援要請メッセージを受信すると、CPU21は、その支援要請を受諾するか否かを選択するためのメニューm20,m21を含むウェブページを表示するためのHTMLデータを、ユーザ:ABCの通信端末10宛に送信する。このHTMLデータの送信では、支援要請元であるユーザ:KNMのアバタ画像、及び、ユーザ:KNMのバトル相手のモンスターキャラクタを特定する情報が、ユーザ:ABCに対して提供される。図11のステップS5では、提供されるモンスターキャラクタを特定する情報は、そのモンスターキャラクタの画像とレベルを含む例を示しているが、これに限られない。モンスターキャラクタを特定するためのテキストであってもよい。
ゲームサーバ20のCPU21は、図11のステップS5に示すウェブページにおいてメニューm20が選択されたことを認識すると、ユーザ:KNM、及びユーザ:ABCの通信端末10宛に、バトルモードにおいてバトル相手となるモンスターキャラクタを表示するためのHTMLデータを送信する。その結果、図11のステップS6に示すように、例えば、ユーザ:KNMの通信端末10に表示されるウェブページには、表示領域100のサブ領域101にモンスターキャラクタMC1が配置される。ユーザ:ABCの通信端末10に表示されるウェブページには、表示領域200のサブ領域201にモンスターキャラクタMC1が配置される。
以上が提供手段523の実現方法の例である。なお、CPU21は、ステップS6の時点で、ユーザごとにバトルデータをRAM23に生成する。バトルデータは、ユーザのバトル相手となるモンスターキャラクタのデータを管理するためのものである。図11のステップS6の時点で生成されるバトルデータの例を、図12A及び図12Bに例示する。図12Aは、ユーザ:KNMに対応するバトルデータの例であり、図12Bは、ユーザ:ABCに対応するバトルデータの例である。図12A及び図12Bに示すように、バトルデータは、ユーザごとに、自らのバトル相手となるモンスターキャラクタ、及び、支援要請を受諾した他のユーザのバトル相手となるモンスターキャラクタについて、レベル(Lv)、攻撃力、及びHP(体力を示す値;キャラクタデータ)のデータを含む。モンスターキャラクタの攻撃力、及び初期のHPの値は、図9に示したモンスターキャラクタのデータを参照してランダムに決定されてよい。後述するように、バトル中の攻撃指示に応じてモンスターキャラクタに対する攻撃が加えられると、CPU21は、その都度バトルデータにアクセスし、攻撃が加えられたモンスターキャラクタのHPの値を変更する。CPU21は、バトル中にHPがゼロになったモンスターキャラクタを、バトルデータから削除する。
なお、バトル中のモンスターキャラクタのHP(キャラクタデータ)を記憶するRAM23は、記憶手段522の一例であってよい。また、バトル中のモンスターキャラクタのHPの記憶、更新のためにRAM23にCPU21がアクセスすることは、記憶手段522を実現するための一例であってよい。
なお、バトル中のモンスターキャラクタのHP(キャラクタデータ)を記憶するRAM23は、記憶手段522の一例であってよい。また、バトル中のモンスターキャラクタのHPの記憶、更新のためにRAM23にCPU21がアクセスすることは、記憶手段522を実現するための一例であってよい。
図11のステップS6において、モンスターキャラクタが配置されるサブ領域101,201にはそれぞれ、モンスターキャラクタのHPを示すゲージ101g,201gが表示される。このゲージは、ユーザの操作による戦士カードのモンスターキャラクタに対する攻撃の程度に応じて低下する目盛りであり、バトルデータにおけるモンスターキャラクタのHPの値と連動している。
制御手段524は、ユーザごとに、ユーザの操作に応じて、ユーザのバトル相手となるモンスターキャラクタのHP(キャラクタデータ)を変更する機能を備える。本実施形態において、制御手段524は、より具体的には、ユーザの操作に基づく攻撃指示に基づき、ユーザが保有する戦士カードがモンスターキャラクタに対して攻撃することによって、そのモンスターキャラクタのHPを低下させる機能を備える。
さらに制御手段524は、第2のユーザ(支援要請を受諾したユーザ;ABC)対して第1のユーザ(支援要請元のユーザ;KNM)のモンスターキャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザのモンスターキャラクタのHPの値(キャラクタデータ)と同時に、第1のユーザのモンスターキャラクタのHPの値をも変更する機能を備える。なお、制御手段524は、第1のユーザに提示する表示画面において第2のユーザのキャラクタを表示させず、第2のユーザに提示する表示画面において第1のユーザのキャラクタを表示させてもよい。
さらに制御手段524は、第2のユーザ(支援要請を受諾したユーザ;ABC)対して第1のユーザ(支援要請元のユーザ;KNM)のモンスターキャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザのモンスターキャラクタのHPの値(キャラクタデータ)と同時に、第1のユーザのモンスターキャラクタのHPの値をも変更する機能を備える。なお、制御手段524は、第1のユーザに提示する表示画面において第2のユーザのキャラクタを表示させず、第2のユーザに提示する表示画面において第1のユーザのキャラクタを表示させてもよい。
以下の説明では、ユーザ:KNMのバトル相手であるモンスターキャラクタはユーザ:KNMの敵キャラクタであり、ユーザ:ABCのバトル相手であるモンスターキャラクタはユーザ:ABCの敵キャラクタである。
図13を参照すると、制御手段524の機能は、具体的に以下のとおり実現される。図13では、ユーザ:KNMからの支援要請を受諾したユーザ:ABCの通信端末10に表示される一連のウェブページを例示する図である。図13のステップS7では、ユーザ:KNMからの支援要請を受諾した結果、ユーザ:KNMのバトル相手であるモンスターキャラクタが表示領域200のサブ領域201に配置されて表示され、その後に、自らのバトル相手となるモンスターキャラクタが出現して表示領域100のサブ領域101に配置された場合の例を示している。図13のステップS7が表示される時点では、ユーザ:ABC(第2のユーザ)の通信端末10に対して、ユーザ:KNM(第1のユーザ)のモンスターキャラクタを特定する情報が既に提供されていることが想定されている。
図13を参照すると、制御手段524の機能は、具体的に以下のとおり実現される。図13では、ユーザ:KNMからの支援要請を受諾したユーザ:ABCの通信端末10に表示される一連のウェブページを例示する図である。図13のステップS7では、ユーザ:KNMからの支援要請を受諾した結果、ユーザ:KNMのバトル相手であるモンスターキャラクタが表示領域200のサブ領域201に配置されて表示され、その後に、自らのバトル相手となるモンスターキャラクタが出現して表示領域100のサブ領域101に配置された場合の例を示している。図13のステップS7が表示される時点では、ユーザ:ABC(第2のユーザ)の通信端末10に対して、ユーザ:KNM(第1のユーザ)のモンスターキャラクタを特定する情報が既に提供されていることが想定されている。
この場合、ユーザ:ABCが保有する戦士カードによるバトル相手のモンスターキャラクタ(サブ領域101のモンスターキャラクタ)への攻撃は、ユーザ:KNMのバトル相手のモンスターキャラクタ(サブ領域201のモンスターキャラクタ)に対しても効果を発揮する(つまり、体力を低下させる)ように構成されている。例えば、図13のステップS7に示すウェブページにおいて、「モンスターを攻撃する」というテキストが表記されたメニューm23が選択されると、攻撃指示メッセージが通信端末10からゲームサーバ20宛に送信される。ゲームサーバ20のCPU21は、攻撃指示メッセージを受信すると、ユーザ:ABCが保有する複数の戦士カード(C1)が2体のモンスターキャラクタを同時に攻撃する状態を表示するためのHTMLデータを生成し、ユーザ:ABCの通信端末10宛に送信する。その結果、図13のステップS8に示すウェブページがユーザ:ABCの通信端末10で表示される。このウェブページでは、2体のモンスターキャラクタの各々に、ゲージ101g,102gと同一のゲージGが表示される。
手持ちの複数の戦士カードとモンスターキャラクタとのバトルは、以下のように設定されてもよい。例えば、ユーザが保有する戦士カードの中からモンスターキャラクタとのバトルに参加可能な戦士カードの数(例えば5~10枚)が予め規定される。ユーザは、攻撃ポイントを一定量消費して、1又は複数の戦士カードによる1回の攻撃をモンスターキャラクタに対して行う。その攻撃に参加した1又は複数の戦士カードの攻撃力の値の総和に応じて、モンスターキャラクタのHPの値が低下する。なお、攻撃ポイントがゼロになった場合には、モンスターキャラクタに対して攻撃を加えられない。一方、モンスターキャラクタからも戦士カードに対してランダムなタイミングで、バトルデータに示す攻撃力で攻撃が加えられる。その結果、一定時間内にモンスターキャラクタのHPの値がゼロになった場合には、ユーザの戦士カードが勝利してその区画の土地の攻略に成功したと判断され、そうでない場合には、ユーザはその区画の土地の攻略に失敗したと判断される。
より具体的には、CPU21は、メニューm23が選択されたことを認識すると、例えば、バトルに参加中の所定数の戦士カードの中から一定の基準あるいはランダムに、攻撃を行う戦士カードを選択し、その戦士カードの攻撃力の総和をユーザデータから読み取り、RAM23内のバトルデータにおけるモンスターキャラクタのHPの値から減算する処理を行ってもよい。CPU21は、減算後のモンスターキャラクタのHPの値をバトルデータに書き込むとともに、減算後の値に応じてゲージGの目盛りの量を決定し、HTMLデータを生成する。このとき、CPU21は、ユーザのウェブページに表示されているすべてのモンスターキャラクタのHPの値から減算する処理を行う。つまり、CPU21は、ユーザの通信端末10に表示されているモンスターキャラクタの数とは無関係に、そのユーザによる1回の攻撃(つまり、1回分の攻撃ポイントの消費)によって、すべてのモンスターキャラクタに対してHPを低下させるように、バトルデータを更新する。例えば、図13のステップS9に示すウェブページは、戦士カードの1回の攻撃によって2体のモンスターキャラクタの双方のHPが低下したことを示している。なお、2体のモンスターキャラクタのHPの変化量は異なっていてもよい。例えば、同じ攻撃力であってもモンスターキャラクタのレベルによって、低下するHPの変化量が異なる場合が考えられる。
2体のモンスターキャラクタのHPの変化量を異ならせる方法として、様々な方法を採り得る。例えば、処理対象である第2のユーザ(支援要請を受諾したユーザ;ABC)のモンスターキャラクタのHPの変化量を、第1のユーザ(支援要請元のユーザ;KNM)のモンスターキャラクタのHPのそれよりも大きくする方法を採ってもよい。この場合、第2のユーザによる攻撃では、自身のバトル相手のモンスターキャラクタへの攻撃を主として行われ、第1のユーザのバトル相手のモンスターキャラクタへの攻撃は、言わば副次的に行われる。
図13において、サブ領域101又はサブ領域201のいずれかを選択することでモンスターキャラクタを選択可能とし、それによって主攻撃対象のモンスターキャラクタをユーザが指定できるようにしてもよい。その場合、ユーザによって指定された主攻撃対象のモンスターキャラクタのHPの変化量を、指定されていないモンスターキャラクタのそれよりも大きくしてもよい。つまり、図13の例では、サブ領域101が選択された状態でメニューm23(「モンスターを攻撃する」)に対する選択操作を認識した場合、CPU21は、ユーザ:ABCのバトル相手のモンスターキャラクタのHPの変化量を、ユーザ:KNMのバトル相手のモンスターキャラクタのそれよりも大きくしてもよい。逆に、サブ領域201が選択された状態でメニューm23(「モンスターを攻撃する」)に対する選択操作を認識した場合、CPU21は、ユーザ:KNMのバトル相手のモンスターキャラクタのHPの変化量を、ユーザ:ABCのバトル相手のモンスターキャラクタのそれよりも大きくしてもよい。
図13のステップS7では、表示領域100及び表示領域200にモンスターキャラクタがそれぞれ1つのみ表示されている例であるが、各領域に複数のモンスターキャラクタが表示されている場合には、サブ領域ごとに、つまりモンスターキャラクタごとに主攻撃対象のモンスターキャラクタをユーザが指定(選択)できるようにしてもよい。その場合、以下のように処理が行われてもよい。
CPU21は、表示領域100に表示されているいずれかのモンスターキャラクタが指定された場合には、表示領域200のいずれのサブ領域に表示されているモンスターキャラクタの中に、指定されたモンスターキャラクタと同一の属性のモンスターキャラクタが存在するか否か判定する。同一の属性のモンスターキャラクタが存在する場合には、CPU21は、そのモンスターキャラクタと指定されたモンスターキャラクタのHPを変化させ、同一の属性のモンスターキャラクタが存在しない場合には、指定されたモンスターキャラクタのHPのみを変化させる。なお、CPU21は、表示領域100内で指定されたモンスターキャラクタと同一の属性の別のモンスターキャラクタが表示領域100内に存在した場合でも、指定されたモンスターキャラクタのHPのみを変化させる。
一方、CPU21は、表示領域200に表示されているいずれかのモンスターキャラクタが指定された場合には、表示領域100のいずれのサブ領域に表示されているモンスターキャラクタの中に、指定されたモンスターキャラクタと同一の属性のモンスターキャラクタが存在するか否か判定する。同一の属性のモンスターキャラクタが存在する場合には、CPU21は、そのモンスターキャラクタと指定されたモンスターキャラクタのHPを変化させ、同一の属性のモンスターキャラクタが存在しない場合には、指定されたモンスターキャラクタのHPのみを変化させる。なお、CPU21は、表示領域200内で指定されたモンスターキャラクタと同一の属性の別のモンスターキャラクタが表示領域200内に存在した場合でも、指定されたモンスターキャラクタのHPのみを変化させる。
上述した処理を実現するためには、図12A及び図12Bに示すバトルデータを、各バトル相手に対応付けて、そのバトル相手が表示されるサブ領域を記述するように構成する。CPU21は、バトルデータを参照し、ユーザによって指定されたサブ領域に対応するバトル相手を特定する。CPU21は、例えば、バトルデータの「他のユーザとそのバトル相手」のいずれかを、指定されたモンスターキャラクタとして特定した場合、「自らのバトル相手」の中から、指定されたモンスターキャラクタと同一の属性のモンスターキャラクタが存在するか否か判定する。同一の属性のモンスターキャラクタが存在する場合には、そのモンスターキャラクタと指定されたモンスターキャラクタの双方のHPをユーザの攻撃指示に応じて低下させるようにする。
CPU21は、表示領域100に表示されているいずれかのモンスターキャラクタが指定された場合には、表示領域200のいずれのサブ領域に表示されているモンスターキャラクタの中に、指定されたモンスターキャラクタと同一の属性のモンスターキャラクタが存在するか否か判定する。同一の属性のモンスターキャラクタが存在する場合には、CPU21は、そのモンスターキャラクタと指定されたモンスターキャラクタのHPを変化させ、同一の属性のモンスターキャラクタが存在しない場合には、指定されたモンスターキャラクタのHPのみを変化させる。なお、CPU21は、表示領域100内で指定されたモンスターキャラクタと同一の属性の別のモンスターキャラクタが表示領域100内に存在した場合でも、指定されたモンスターキャラクタのHPのみを変化させる。
一方、CPU21は、表示領域200に表示されているいずれかのモンスターキャラクタが指定された場合には、表示領域100のいずれのサブ領域に表示されているモンスターキャラクタの中に、指定されたモンスターキャラクタと同一の属性のモンスターキャラクタが存在するか否か判定する。同一の属性のモンスターキャラクタが存在する場合には、CPU21は、そのモンスターキャラクタと指定されたモンスターキャラクタのHPを変化させ、同一の属性のモンスターキャラクタが存在しない場合には、指定されたモンスターキャラクタのHPのみを変化させる。なお、CPU21は、表示領域200内で指定されたモンスターキャラクタと同一の属性の別のモンスターキャラクタが表示領域200内に存在した場合でも、指定されたモンスターキャラクタのHPのみを変化させる。
上述した処理を実現するためには、図12A及び図12Bに示すバトルデータを、各バトル相手に対応付けて、そのバトル相手が表示されるサブ領域を記述するように構成する。CPU21は、バトルデータを参照し、ユーザによって指定されたサブ領域に対応するバトル相手を特定する。CPU21は、例えば、バトルデータの「他のユーザとそのバトル相手」のいずれかを、指定されたモンスターキャラクタとして特定した場合、「自らのバトル相手」の中から、指定されたモンスターキャラクタと同一の属性のモンスターキャラクタが存在するか否か判定する。同一の属性のモンスターキャラクタが存在する場合には、そのモンスターキャラクタと指定されたモンスターキャラクタの双方のHPをユーザの攻撃指示に応じて低下させるようにする。
HPの変化量は、仲間のユーザ間の親密度に応じて異なるようにしてもよい。親密度とは、仲間のユーザ間の関係性の高さを一定の基準で数値化したものであってもよく、例えば、ユーザ間のメッセージの送信あるいは受信の頻度、ゲーム上で使用可能なアイテムなどのプレゼントを送信あるいは受信した回数などに基づいて設定されてもよい。例えば、上記頻度や上記回数が多いほど、親密度が高く設定されてもよい。ユーザ間の親密度を記述したデータ(親密度データ)は、例えばユーザデータベース31に記憶される。CPU21は、HPの変化量を算出するに当たって親密度データを参照し、ユーザ間の親密度に応じてHPの変化量を調整する。例えば、親密度が所定値よりも低い場合のHP変化量を基準値とした場合に、親密度がその所定値以上である場合には、HP変化量を基準値×k(kは、1より大きい係数)とする。
図13の例では、ユーザ:ABCとユーザ:KNMの間の親密度が高いほど、ユーザ:ABCによるメニューm23(「モンスターを攻撃する」)の選択操作によって、支援要請元のユーザ:KNMのバトル相手のモンスターキャラクタのHPの変化量を大きくすることが好ましい。仲間の間の親密度が高いほど、バトルを有利に進行させることができるため、ユーザ間の交流を促進させることができる。
図13の例では、ユーザ:ABCとユーザ:KNMの間の親密度が高いほど、ユーザ:ABCによるメニューm23(「モンスターを攻撃する」)の選択操作によって、支援要請元のユーザ:KNMのバトル相手のモンスターキャラクタのHPの変化量を大きくすることが好ましい。仲間の間の親密度が高いほど、バトルを有利に進行させることができるため、ユーザ間の交流を促進させることができる。
CPU21は、モンスターキャラクタから戦士カードに対する攻撃をランダムなタイミングで発生させる。例えば、CPU21は、RAM23のバトルデータにアクセスして、モンスターキャラクタの攻撃力の値を読み出す。CPU21は、モンスターキャラクタによる攻撃を、例えば、バトルに参加中のいずれかの戦士カードにランダムに与え、攻撃が与えられた戦士カードの防御力よりもモンスターキャラクタの攻撃力が大きい場合には、その戦士カードが攻撃によって倒されたと判断する。モンスターキャラクタの攻撃で倒されるにつれて、更新されるウェブページ上で、ユーザの戦士カードの枚数が減少していくように表示することが好ましい。
CPU21は、メニューm23の選択操作に応じた処理が終了すると、ユーザ:ABCによる操作に基づく攻撃によってモンスターキャラクタのHPを示すゲージが更新されるように、新たなHTMLデータを生成してユーザ:KNM、及びユーザ:ABCの通信端末10宛に送信する。その結果、図14のステップS10に示すウェブページがユーザ:KNM、及びユーザ:ABCの通信端末10に表示される。図14のステップS10を図13のステップS7と比較すると、ユーザ:ABCによる攻撃によって、ユーザ:KNM、及びユーザ:ABCの双方のバトル相手であるモンスターキャラクタのHPが低下したことが分かる(ゲージ101g,201gを参照)。
図14に示すように、本実施形態では、支援要請を行ったユーザ:KNMに提示する表示画面には、ユーザ:KNMのバトル相手のモンスターキャラクタが下段に表示されるが、ユーザ:ABCのバトル相手のモンスターキャラクタは表示されない。一方、支援要請を受諾したユーザ:ABCに提示する表示画面には、ユーザ:KNMのバトル相手のモンスターキャラクタが上段に表示されと、ユーザ:ABCのバトル相手のモンスターキャラクタが下段に表示される。つまり、本実施形態では、支援要請に基づく共通のモンスターキャラクタ(敵キャラクタ)のみが各ユーザの表示画面に表示され、それ以外のモンスターキャラクタ(つまり、自身のバトル相手のモンスターキャラクタ)については、個々のユーザの表示画面にのみ表示される。要するに、本実施形態では、ユーザ間で協力バトルを行っているものの、ユーザ間で表示画面が異なりユーザ間で仮想空間を共有するものではない。
図14に示すように、本実施形態では、支援要請を行ったユーザ:KNMに提示する表示画面には、ユーザ:KNMのバトル相手のモンスターキャラクタが下段に表示されるが、ユーザ:ABCのバトル相手のモンスターキャラクタは表示されない。一方、支援要請を受諾したユーザ:ABCに提示する表示画面には、ユーザ:KNMのバトル相手のモンスターキャラクタが上段に表示されと、ユーザ:ABCのバトル相手のモンスターキャラクタが下段に表示される。つまり、本実施形態では、支援要請に基づく共通のモンスターキャラクタ(敵キャラクタ)のみが各ユーザの表示画面に表示され、それ以外のモンスターキャラクタ(つまり、自身のバトル相手のモンスターキャラクタ)については、個々のユーザの表示画面にのみ表示される。要するに、本実施形態では、ユーザ間で協力バトルを行っているものの、ユーザ間で表示画面が異なりユーザ間で仮想空間を共有するものではない。
図15Aは、ユーザの保有する戦士カードがモンスターキャラクタに勝利して、対象となる区画301の土地の攻略に成功した場合の、バトル後に通信端末10に表示されるウェブページの例を示す図である。図15Bは、ユーザの保有する戦士カードがモンスターキャラクタに敗北して、対象となる区画301の土地の攻略に失敗した場合の、バトル後に通信端末10に表示されるウェブページの例を示す図である。図15Aに示す例では、区画301の土地の攻略に成功したことを示す旗の画像が区画301に表示される。一方、図15Bに示す例では、倒すことができなかったモンスターキャラクタの画像が区画301に表示される。図15Bにおいて、区画301を選択操作することによって、再度モンスターキャラクタとのバトルが実行されるように設定してもよい。
なお、図13及び図14では、支援要請を受諾したユーザ:ABCのバトル相手のモンスターキャラクタと支援要請元のユーザ:KNMのバトル相手のモンスターキャラクタの属性が同じ(この場合、共にモンスターキャラクタMC1)である場合について説明したが、両者のモンスターキャラクタの属性が異なる場合であっても、ユーザ:ABCのメニューm23(「モンスターを攻撃する」)の選択操作によって、ユーザ:ABCのバトル相手のモンスターキャラクタとユーザ:KNMのバトル相手のモンスターキャラクタのHPを両方とも変化(低下)させてもよい。その場合、ユーザ:KNMのモンスターキャラクタのHPの変化量を、属性が一致する場合よりも少なくしてもよいし、それぞれのモンスターキャラクタの属性に応じた値としてもよい。
あるいは、両者のモンスターキャラクタの属性が異なる場合には、ユーザ:ABCのメニューm23(「モンスターを攻撃する」)の選択操作によって、ユーザ:ABCのバトル相手のモンスターキャラクタのHPのみが低下し、ユーザ:KNMのモンスターキャラクタのHPを変化させないようにしてもよい。
あるいは、両者のモンスターキャラクタの属性が異なる場合には、ユーザ:ABCのメニューm23(「モンスターを攻撃する」)の選択操作によって、ユーザ:ABCのバトル相手のモンスターキャラクタのHPのみが低下し、ユーザ:KNMのモンスターキャラクタのHPを変化させないようにしてもよい。
(1-6)本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図16のフローチャートを参照して説明する。図16は、掘削実行処理におけるバトルモードの処理の例を示すフローチャートである。図16では、図11~14と同様に、支援要請元のユーザがユーザ:KNM(第1のユーザ)であり、支援要請先のユーザがユーザ:ABC(第2のユーザ)である場合を例として説明する。なお、図16のフローチャートにおいて、ステップS4~S10の画面表示は、図11,図13及び図14のステップS4~S10におけるウェブページの表示例に対応している。
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図16のフローチャートを参照して説明する。図16は、掘削実行処理におけるバトルモードの処理の例を示すフローチャートである。図16では、図11~14と同様に、支援要請元のユーザがユーザ:KNM(第1のユーザ)であり、支援要請先のユーザがユーザ:ABC(第2のユーザ)である場合を例として説明する。なお、図16のフローチャートにおいて、ステップS4~S10の画面表示は、図11,図13及び図14のステップS4~S10におけるウェブページの表示例に対応している。
先ず、掘削実行処理におけるバトルモードに移行すると、ユーザ:KNMの通信端末10には、そのバトルモードで出現したモンスターキャラクタの画像及びそのレベルを表示するウェブページが表示されるとともに、メニューm11の選択操作に応じて、支援要請先のユーザを選択するためのリストを含むウェブページが表示される(ステップS4,S5)。このリストの中からいずれかのユーザが選択されると、通信端末10からゲームサーバ20宛に、支援要請先のユーザ(ユーザ:ABC)を指定した支援要請メッセージが送信される(ステップS100)。ゲームサーバ20は、支援要請メッセージを受信すると、ユーザ:KNMのモンスターキャラクタを特定する情報を含むHTMLデータを生成して、支援要請先であるユーザ:ABCの通信端末10宛に送信する(ステップS102)。
ステップS102のHTMLデータを受信すると、ユーザ:ABCの通信端末10には、支援要請元のユーザ、そのモンスターキャラクタを特定する情報とともに、支援要請を受諾するか否かについてのメニューを含むウェブページが表示される(ステップS5)。これにより、ユーザ:ABCに対して、モンスターキャラクタを特定する情報が提供されたことになる。ここで、ユーザ:ABCによって支援要請を受諾する選択操作がなされると、通信端末10からゲームサーバ20宛に受諾メッセージが送信される(ステップS104)。ユーザ:ABCからの受諾メッセージを受けて、ゲームサーバ20は、支援要請元のユーザ:KNMの通信端末10と、支援要請を受諾したユーザ:ABCの通信端末10とに対して、新たなHTMLデータを送信する(ステップS106,S108)。それによって、ユーザ:KNMの通信端末10には、所定の表示領域に自らのバトル相手となるモンスターキャラクタを含むウェブページが表示され、ユーザ:ABCの通信端末10には、所定の表示流域にユーザ:KNMのバトル相手となるモンスターキャラクタを含むウェブページが表示される(ステップS6)。
その後、例えば、ユーザ:ABCにとって自らのバトル相手となるモンスターキャラクタが出現した場合を想定すると、そのモンスターキャラクタを特定する情報を含むHTMLデータが送信される(ステップS110)。この場合、ステップS110で送信されたHTMLデータに基づき、ユーザ:ABCの通信端末10で表示されるウェブページ(ステップS7)には、所定の表示領域に自らのバトル相手となるモンスターキャラクタが表示され、他の表示領域にユーザ:KNMのバトル相手となるモンスターキャラクタが表示される。ここで、ユーザ:ABCによるモンスターキャラクタへの攻撃指示の操作(メニューm23の選択操作)がなされると、ユーザ:ABCの通信端末10からゲームサーバ20宛に攻撃指示メッセージが送信される(ステップS112)。ゲームサーバ20は、攻撃指示メッセージに応じて、ユーザ:KNM、及びユーザ:ABCの双方のモンスターキャラクタのHPを低下させるようにしてバトルデータを更新し(ステップS114)、新たなHPの値を反映させたHTMLデータを生成してユーザ:ABCの通信端末10宛に送信する(ステップS116)。これにより、ユーザ:ABCの通信端末10に表示されるウェブページ上では、モンスターキャラクタのHPを示すゲージが変化する(ステップS9)。なお、ゲームサーバ20は、ユーザ:ABCによる攻撃指示に基づき、ユーザ:ABCの攻撃ポイントが一定量低下するように、ユーザデータを更新する。
ユーザ:ABCによる攻撃指示の操作に応じた処理が終了すると、ゲームサーバ20は、新たなHTMLデータを生成してユーザ:ABC、及びユーザ:KNMの通信端末10宛に送信する(ステップS118,S120)。このHTMLデータによって表示されるウェブページでは、ユーザ:ABC、及びユーザ:KNMの双方のバトル相手であるモンスターキャラクタのHPが低下したことが視認できるようになっている(ステップS10)。
上述したように、掘削実行処理におけるバトルモードの処理では、自らのモンスターキャラクタのみを攻撃するのに必要となる一定量の攻撃ポイントを消費して、自らのモンスターキャラクタのみならず、他のユーザのモンスターキャラクタをも攻撃できるように構成されている。それによって、各ユーザは、互いに協力してゲームを進行させている感覚を得ることができる。
また、上述したバトルモードの処理では、他のユーザのモンスターキャラクタを攻撃することによって攻撃ポイントを消費したために自らのモンスターキャラクタを攻撃することができないといった状況や、逆に、自らのユーザのモンスターキャラクタを攻撃することによって攻撃ポイントを消費したために他のユーザのモンスターキャラクタを攻撃することができないといった状況が生じない。そのため、ユーザは、自らのモンスターキャラクタとともに他のユーザのモンスターキャラクタを攻撃することで、より積極的に他のユーザのバトルを手助けすることができるようになる。よって、ユーザ間で互いに協力してゲームを進行させやすくなり、ゲームにおけるユーザ間のコニュニティの活性化を図ることができる。
また、上述したバトルモードの処理では、他のユーザのモンスターキャラクタを攻撃することによって攻撃ポイントを消費したために自らのモンスターキャラクタを攻撃することができないといった状況や、逆に、自らのユーザのモンスターキャラクタを攻撃することによって攻撃ポイントを消費したために他のユーザのモンスターキャラクタを攻撃することができないといった状況が生じない。そのため、ユーザは、自らのモンスターキャラクタとともに他のユーザのモンスターキャラクタを攻撃することで、より積極的に他のユーザのバトルを手助けすることができるようになる。よって、ユーザ間で互いに協力してゲームを進行させやすくなり、ゲームにおけるユーザ間のコニュニティの活性化を図ることができる。
(2)第2の実施形態
以下、第2の実施形態について説明する。第2の実施形態のゲームサーバ20及びデータベースサーバ30の構成については、第1の実施形態と同様のハードウエア構成とすることができる。
以下、第2の実施形態について説明する。第2の実施形態のゲームサーバ20及びデータベースサーバ30の構成については、第1の実施形態と同様のハードウエア構成とすることができる。
第1の実施形態では、ユーザのバトル相手となるモンスターキャラクタが1種類である場合(図11~14参照)、つまりモンスターキャラクタが単一の属性に対応付けられている場合を例として説明したが、これに限られない。ユーザのバトル相手となるモンスターキャラクタが複数の属性のいずれかと対応付けられてもよい。なお、モンスターキャラクタの属性とは、例えばモンスターキャラクタの形態および/または色、模様、キャラクタそのものや能力を数値化したもの(レベル等)に加えて、モンスターキャラクタに設定された特定音(鳴き声等)など、モンスターキャラクタの違いを視覚的および/または聴覚的に区別可能な如何なる特性も含みうる。以下、本実施形態では、図9に示したように、属性(図9の例では、外観の画像)が異なる複数のモンスターキャラクタ(図9では、モンスターキャラクタMC1~3)の少なくともいずれかがユーザのバトル相手となる場合について説明する。
第1の実施形態では、ユーザによる攻撃指示の操作(図13のメニューm23の選択操作)によって、そのユーザのウェブページに表示されているすべてのモンスターキャラクタのHPが低下したが、本実施形態では、ユーザのウェブページに表示されているモンスターキャラクタの中で攻撃指示の操作によってHPが低下するモンスターキャラクタを、ユーザが選択操作可能に構成されている。
本実施形態では、制御手段524は、支援要請元のユーザ(第1のユーザ)のバトル相手のモンスターキャラクタと支援要請を受諾したユーザ(第2のユーザ)のバトル相手のモンスターキャラクタとが同じ属性である場合に、第2のユーザの操作に応じて第1のユーザのモンスターキャラクタのHP(キャラクタデータ)を変更する機能を備える点が、第1の実施形態と異なる。
図17を参照すると、本実施形態の制御手段524の機能は、具体的に以下のとおり実現される。図17では、例えば複数のユーザからの支援要請を受諾したユーザ:ABCの通信端末10に表示される一連のウェブページを例示する図である。図17のステップS20では、自らのバトル相手となる3体のモンスターキャラクタがそれぞれ表示領域100のサブ領域101~103に配置され、かつ、他の2人のユーザのバトル相手である2体のモンスターキャラクタがそれぞれ表示領域200のサブ領域201,202に配置されて表示されている場合の例を示している。図17のステップS20が表示される時点では、ユーザ:ABCの通信端末10に対して、他のユーザのモンスターキャラクタを特定する情報(モンスターキャラクタMC1,MC3)が既に提供されている。
この場合、例えば図17のステップS20に示すように、「最も多いモンスターを攻撃する」というテキストを表記したメニューm25を設けてもよい。このメニューm25は、ウェブページに表示されているモンスターキャラクタの中で、ユーザ:ABCのバトル相手のモンスターキャラクタのいずれかと同じ属性であって、かつ最も多い同じ属性のモンスターキャラクタに対する攻撃指示を行うためのメニューである。メニューm25が選択されると、攻撃指示メッセージが通信端末10からゲームサーバ20宛に送信される。ゲームサーバ20のCPU21は、攻撃指示メッセージを受信すると、ユーザ:ABCに対して提供されているモンスターキャラクタの中で、ユーザ:ABCのバトル相手のモンスターキャラクタのいずれかと同じ属性であって、最も多い同じ属性のモンスターキャラクタ(図17のステップS21の例では、3体のモンスターキャラクタMC1)を特定し、その特定したモンスターキャラクタ3体を、ユーザ:ABCが保有する複数の戦士カード(C2)が同時に攻撃する状態を表示するためのHTMLデータを生成してユーザ:ABCの通信端末10宛に送信する。その結果、図17のステップS21に示すウェブページがユーザ:ABCの通信端末10で表示される。このウェブページでは、3体のモンスターキャラクタMC1の各々に、HPを示すゲージGが表示される。
図17のステップS20に示すウェブページ上で、ユーザ:ABCがメニューm25を表示せずに、いずれかのサブ領域を選択操作することによって、攻撃指示の対象とするモンスターキャラクタを選択するように構成してもよい。この構成によれば、ユーザは、いずれのモンスターキャラクタを攻撃することによって他のユーザを支援できるか考慮しながら、攻撃対象のモンスターキャラクタを選択することができるようになる。
複数の戦士カードとモンスターキャラクタとのバトルは、第1の実施形態で説明した方法と同様の方法であってよい。CPU21は、メニューm25が選択されたことを認識すると、戦士カードの攻撃力に応じて、1回分の攻撃ポイントの消費によって3体のモンスターキャラクタMC1のHPの値をすべて低下させる処理を行う。CPU21は、低下後のモンスターキャラクタのHPの値をRAM23内のバトルデータに書き込むとともに、低下後の値に応じてゲージGの目盛りの量を決定し、HTMLデータを生成してユーザ:ABCの通信端末10宛に送信する。その結果、図17のステップS22に示すように、3体のモンスターキャラクタすべてのHPが低下したことを示すウェブページがユーザ:ABCの通信端末10に表示される。
CPU21は、メニューm25の選択操作に応じた処理が終了すると、ユーザ:ABCによる操作に基づく攻撃によってモンスターキャラクタのHPを示すゲージが更新されるように、関連するユーザ向けに新たなHTMLデータを生成して送信する。例えば、図17の表示領域200のサブ領域201に表示されているモンスターキャラクタMC1がユーザ:KNMからの支援要請に基づくものであった場合には、モンスターキャラクタMC1のHPを示すゲージを更新するように、ユーザ:ABC及びユーザ:KNM向けに新たなHTMLデータを生成して送信する。その結果、図18のステップS23に示すウェブページが、ユーザ:KNM、及びユーザ:ABCの通信端末10に表示される。図17のステップS20を図18のステップS23と比較すると、ユーザ:ABCによる攻撃によって、ユーザ:ABC及びユーザ:KNMの双方のバトル相手であるモンスターキャラクタMC1のHPが低下したことが分かる(ユーザ:KNM宛に表示されるゲージ101g、ユーザ:ABC宛に表示される102g,103g,201gを参照)。
図18に示すように、本実施形態では、支援要請を行ったユーザ:KNMに提示する表示画面には、ユーザ:KNMのバトル相手のモンスターキャラクタが下段に表示されるが、ユーザ:ABCのバトル相手のモンスターキャラクタは表示されない。一方、支援要請を受諾したユーザ:ABCに提示する表示画面には、ユーザ:KNMのバトル相手のモンスターキャラクタと、ユーザ:KNM以外のユーザで支援要請を行ったユーザのバトル相手のモンスターキャラクタとが上段に表示され、ユーザ:ABCのバトル相手のモンスターキャラクタが下段に表示される。つまり、本実施形態では、支援要請に基づく共通のモンスターキャラクタ(敵キャラクタ)のみが各ユーザの表示画面に表示され、それ以外のモンスターキャラクタ(つまり、自身のバトル相手のモンスターキャラクタ)については、個々のユーザの表示画面にのみ表示される。要するに、本実施形態では、ユーザ間で協力バトルを行っているものの、ユーザ間で表示画面が異なりユーザ間で仮想空間を共有するものではない。
図18に示すように、本実施形態では、支援要請を行ったユーザ:KNMに提示する表示画面には、ユーザ:KNMのバトル相手のモンスターキャラクタが下段に表示されるが、ユーザ:ABCのバトル相手のモンスターキャラクタは表示されない。一方、支援要請を受諾したユーザ:ABCに提示する表示画面には、ユーザ:KNMのバトル相手のモンスターキャラクタと、ユーザ:KNM以外のユーザで支援要請を行ったユーザのバトル相手のモンスターキャラクタとが上段に表示され、ユーザ:ABCのバトル相手のモンスターキャラクタが下段に表示される。つまり、本実施形態では、支援要請に基づく共通のモンスターキャラクタ(敵キャラクタ)のみが各ユーザの表示画面に表示され、それ以外のモンスターキャラクタ(つまり、自身のバトル相手のモンスターキャラクタ)については、個々のユーザの表示画面にのみ表示される。要するに、本実施形態では、ユーザ間で協力バトルを行っているものの、ユーザ間で表示画面が異なりユーザ間で仮想空間を共有するものではない。
本実施形態では、属性が異なる複数のモンスターキャラクタがゲーム上に登場する場合に、支援を行うユーザによる攻撃指示によって、支援を行うユーザのモンスターキャラクタと支援要請元のユーザのモンスターキャラクタとで同一の属性のモンスターキャラクタに対して攻撃が加えられる。そのため、本実施形態によれば、属性が異なる複数のモンスターキャラクタがゲーム上に登場する場合に、他のユーザのモンスターキャラクタを含めて最も攻撃の効果の高いモンスターキャラクタに対して、ユーザが攻撃を加えられるようになる。
また、本実施形態では、属性が異なる複数のモンスターキャラクタがゲーム上で設定されている場合であっても、支援要請を受諾したユーザは、自らのモンスターキャラクタのうち、支援要請元のゲームの進行に対して影響を与えることができるキャラクタを認識しながらゲームを進めることができる。つまり、いずれのモンスターキャラクタを攻撃することによって他のユーザを支援できるかについてユーザに判断させる構成となるため、ゲームの興趣性が増す。
また、本実施形態では、属性が異なる複数のモンスターキャラクタがゲーム上で設定されている場合であっても、支援要請を受諾したユーザは、自らのモンスターキャラクタのうち、支援要請元のゲームの進行に対して影響を与えることができるキャラクタを認識しながらゲームを進めることができる。つまり、いずれのモンスターキャラクタを攻撃することによって他のユーザを支援できるかについてユーザに判断させる構成となるため、ゲームの興趣性が増す。
(3)変形例
以下、上述した各実施形態の変形例について説明する。
以下、上述した各実施形態の変形例について説明する。
(3-1)変形例1
制御手段524は、複数のユーザからの支援要請を受けたユーザ(第2のユーザ)に対してその複数のユーザのモンスターキャラクタを特定する情報が提供された場合には、支援要請を受けたユーザによる選択操作に基づいて、いずれかのモンスターキャラクタを選択する機能を備えてもよい。つまり、他のユーザからの支援要請を複数受けた場合、支援要請によって提供されるモンスターキャラクタの中からいずれのモンスターキャラクタを選択するかについて、ユーザが選択可能とすることが好ましい。その場合、支援要請を受けたユーザは、例えば、自らのバトル相手であるモンスターキャラクタと同一の属性のモンスターキャラクタを選択することができるため、他のユーザを支援しやすくなる。
制御手段524は、複数のユーザからの支援要請を受けたユーザ(第2のユーザ)に対してその複数のユーザのモンスターキャラクタを特定する情報が提供された場合には、支援要請を受けたユーザによる選択操作に基づいて、いずれかのモンスターキャラクタを選択する機能を備えてもよい。つまり、他のユーザからの支援要請を複数受けた場合、支援要請によって提供されるモンスターキャラクタの中からいずれのモンスターキャラクタを選択するかについて、ユーザが選択可能とすることが好ましい。その場合、支援要請を受けたユーザは、例えば、自らのバトル相手であるモンスターキャラクタと同一の属性のモンスターキャラクタを選択することができるため、他のユーザを支援しやすくなる。
上述した制御手段524の機能は、以下のようにして実現することができる。ゲームサーバ20のCPU21は、例えば一定期間内に特定のユーザ宛の支援要請メッセージを複数受信した場合には、その複数の支援要請メッセージによって特定される支援要請元のユーザとそのユーザのバトル相手のモンスターキャラクタを特定する情報を一覧形式に表示するためのHTMLデータを生成して、支援要請先のユーザの通信端末10宛に送信する。その結果、支援要請先のユーザの通信端末10には、例えば図19に示すウェブページが表示される。このウェブページ上で、支援要請先のユーザによって、いずれかのユーザあるいはモンスターキャラクタが選択されると、CPU21は、その選択結果に基づいて支援対象とするユーザ(支援要請の受諾の返信先のユーザ)を決定する。
(3-2)変形例2
図11では、ユーザ:KNMは、支援要請先のユーザを選択するためのリストからいずれかのユーザを選択した後に(ステップS5)、自らのバトル相手となるモンスターキャラクタの属性を認識するように構成されている(ステップS6)。このステップS5及びステップS6は逆であってもよい。つまり、ユーザは、先に自らのバトル相手となるモンスターキャラクタの属性を確認した後に、支援要請先のユーザを選択する構成であってもよい。その場合、ユーザは、既に自らのバトル相手のモンスターキャラクタが分かっているため、それに応じて支援要請先のユーザを選択できるようにすることが好ましい。
図11では、ユーザ:KNMは、支援要請先のユーザを選択するためのリストからいずれかのユーザを選択した後に(ステップS5)、自らのバトル相手となるモンスターキャラクタの属性を認識するように構成されている(ステップS6)。このステップS5及びステップS6は逆であってもよい。つまり、ユーザは、先に自らのバトル相手となるモンスターキャラクタの属性を確認した後に、支援要請先のユーザを選択する構成であってもよい。その場合、ユーザは、既に自らのバトル相手のモンスターキャラクタが分かっているため、それに応じて支援要請先のユーザを選択できるようにすることが好ましい。
さらに、変形例2では、制御手段524は、支援要請元のユーザ(第1のユーザ)から支援要請がなされた場合、第1のユーザに対して複数のユーザのモンスターキャラクタを特定する情報を提供し、第1のユーザによる選択操作に基づいて、いずれかのモンスターキャラクタを選択し、そのモンスターキャラクタをバトル相手とするユーザを支援要請先のユーザとして決定してもよい。例えば、図11のステップS6のウェブページが表示された後、ユーザ:KNMの通信端末10に対して図20に示すウェブページを表示させるようにする。このウェブページは、支援要請先の候補となる複数のユーザと、各ユーザのバトル相手のモンスターキャラクタを特定する情報のリストを含む。このウェブページを見たユーザ:KNMは、自らのバトル相手のモンスターキャラクタ(ステップS6ではモンスターキャラクタMC1)が分かっているため、そのモンスターキャラクタと同一の属性のモンスターキャラクタを図20のリストの中から選択することが動機付けられる。同一の属性のモンスターキャラクタを選択することにより、支援を行うユーザにとって負担にならないため(つまり、自らの攻撃ポイントを他のユーザのモンスターキャラクタだけに対する攻撃で消費することにならないため)、支援要請を受けたユーザがその支援要請を受諾する可能性が高いためである。
上述した制御手段524の機能は、以下のようにして実現することができる。ゲームサーバ20のCPU21は、例えば図11のステップS4のウェブページにおいてメニューm11が選択されると、ステップS6に示すウェブページが表示されるように表示の更新を行う。このステップS6のウェブページ上では、例えば、ユーザ1人で戦うことを選択するためのメニューm10と、仲間のユーザに対してバトルの支援要請を行うためのメニューm11とを表示することが好ましい(図示せず)。そして、メニューm11が選択されたことを認識した場合に、CPU21は、図20のステップS5のウェブページが表示されるように表示の更新を行う。このとき、図20に表示されるリスト内のユーザは、ユーザ:KNMの仲間のユーザであることが好ましい。CPU21は、仲間のユーザのリストを作成するに当たってRAM23内のバトルデータを参照し、仲間のユーザのバトル相手のモンスターキャラクタを特定する情報を取得する。
(3-3)変形例3
図11のステップS5では、ユーザ:KNMが支援要請先のユーザを選択する構成としたが、これに限られない。提供手段523は、第1のユーザ(支援要請元のユーザ)の仲間の複数のユーザ(第1のユーザと関連付けられている複数のユーザ)のうち、支援要請を受諾するか否か(つまり、第1のユーザのモンスターキャラクタを特定する情報の提供を希望するか否か)について問い合わせをし、受諾すること(つまり、当該情報の提供を希望すること)を最初に回答したユーザを、支援要請先のユーザ(第2のユーザ)として特定してもよい。これにより、仲間を早く助けたいという、支援要請を受諾したユーザの欲求を満たすことができる。
この場合、ゲームサーバ20のCPU21は、図11のステップS4のウェブページにおけるメニューm11の選択操作を認識すると、ステップS5のウェブページには移行せずに、ユーザ:KNMのユーザデータを参照して、ユーザ:KNMのすべての仲間の通信端末10宛に、支援要請メッセージを送信する。各仲間の通信端末10では、図11のステップS5に示したように、支援要請を受諾するか否かを選択するためのメニューm20,m21を含むウェブページが表示される。その後、CPU21は、支援要請メッセージに応じて最初にメニューm20の選択操作を行ったユーザ(つまり、最初に受諾メッセージを送信した通信端末10のユーザ)を特定し、そのユーザを支援要請先のユーザとする。
図11のステップS5では、ユーザ:KNMが支援要請先のユーザを選択する構成としたが、これに限られない。提供手段523は、第1のユーザ(支援要請元のユーザ)の仲間の複数のユーザ(第1のユーザと関連付けられている複数のユーザ)のうち、支援要請を受諾するか否か(つまり、第1のユーザのモンスターキャラクタを特定する情報の提供を希望するか否か)について問い合わせをし、受諾すること(つまり、当該情報の提供を希望すること)を最初に回答したユーザを、支援要請先のユーザ(第2のユーザ)として特定してもよい。これにより、仲間を早く助けたいという、支援要請を受諾したユーザの欲求を満たすことができる。
この場合、ゲームサーバ20のCPU21は、図11のステップS4のウェブページにおけるメニューm11の選択操作を認識すると、ステップS5のウェブページには移行せずに、ユーザ:KNMのユーザデータを参照して、ユーザ:KNMのすべての仲間の通信端末10宛に、支援要請メッセージを送信する。各仲間の通信端末10では、図11のステップS5に示したように、支援要請を受諾するか否かを選択するためのメニューm20,m21を含むウェブページが表示される。その後、CPU21は、支援要請メッセージに応じて最初にメニューm20の選択操作を行ったユーザ(つまり、最初に受諾メッセージを送信した通信端末10のユーザ)を特定し、そのユーザを支援要請先のユーザとする。
(3-4)変形例4
上述した第2の実施形態では、図17及び図18に示したように、属性が異なる複数のモンスターキャラクタがゲーム上に登場する場合には、支援要請を受諾したユーザ:ABCの操作に応じて、支援要請元のユーザ:KNMとの間で同一の属性のモンスターキャラクタMC1のみのHPを低下させる場合を示したが、これに限られない。HPの低下対象のモンスターキャラクタを様々に設定できるようにしてもよい。例えば、ユーザ:ABCの操作に応じて、属性の如何に関わらずすべてのモンスターキャラクタのHPを低下させてもよい。その場合、支援要請を受諾したユーザ:ABCのバトル相手と支援要請元のユーザ:KNMのバトル相手が同一の属性のモンスターキャラクタ(図17のMC1)のHP変化量を、両者で同一でない属性のモンスターキャラクタ(図17のMC2,MC3)のそれよりも大きくしてもよい。
上述した第2の実施形態では、図17及び図18に示したように、属性が異なる複数のモンスターキャラクタがゲーム上に登場する場合には、支援要請を受諾したユーザ:ABCの操作に応じて、支援要請元のユーザ:KNMとの間で同一の属性のモンスターキャラクタMC1のみのHPを低下させる場合を示したが、これに限られない。HPの低下対象のモンスターキャラクタを様々に設定できるようにしてもよい。例えば、ユーザ:ABCの操作に応じて、属性の如何に関わらずすべてのモンスターキャラクタのHPを低下させてもよい。その場合、支援要請を受諾したユーザ:ABCのバトル相手と支援要請元のユーザ:KNMのバトル相手が同一の属性のモンスターキャラクタ(図17のMC1)のHP変化量を、両者で同一でない属性のモンスターキャラクタ(図17のMC2,MC3)のそれよりも大きくしてもよい。
なお、上述した各実施形態、及び各変形例では、支援要請元のユーザと、支援要請先のユーザとが、仲間(関連付けられているユーザ同士)である場合について説明したが、仲間に限られない。ユーザは、仲間でない他のユーザをも支援することができる。但し、支援要請先を仲間に限定することで、仲間間のコミュニティの活性化を図ることができる。
以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。
例えば、上記説明では、支援を行うユーザが1人(上記実施形態の説明では、ユーザ:ABC)の場合について説明したが、これに限られない。支援を行うユーザが複数可能となるように構成されてよい。その場合、ウェブページに表示可能な、他のユーザのモンスターキャラクタの最大数(例えば図11では、3体)は、支援を行うユーザの数に応じて増加させることが好ましい。
上述した実施形態では、モンスターキャラクタの属性が視覚的に異なる場合について説明したが、前述したように、モンスターキャラクタの属性は聴覚的に異なる場合であってもよい。その場合、例えば、通信端末10に表示されているモンスターキャラクタを選択操作することによって、そのモンスターキャラクタの鳴き声が出力されるように構成される。そして、支援を行うユーザによる攻撃指示によって、支援を行うユーザのモンスターキャラクタと支援要請元のユーザのモンスターキャラクタとで同一の鳴き声を出力するモンスターキャラクタに対して攻撃が加えられるようにしてもよい。
上述した実施形態では、掘削実行処理のバトルモードにおいて、ユーザのバトル相手がモンスターキャラクタである場合を例として説明したが、これに限られない。例えば、ユーザのバトル相手は、そのユーザの仲間以外の他のユーザの戦士カードなどであってもよい。
上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、各ユーザによるゲームの進行を制御できることは言うまでもない。
例えば、上記説明では、支援を行うユーザが1人(上記実施形態の説明では、ユーザ:ABC)の場合について説明したが、これに限られない。支援を行うユーザが複数可能となるように構成されてよい。その場合、ウェブページに表示可能な、他のユーザのモンスターキャラクタの最大数(例えば図11では、3体)は、支援を行うユーザの数に応じて増加させることが好ましい。
上述した実施形態では、モンスターキャラクタの属性が視覚的に異なる場合について説明したが、前述したように、モンスターキャラクタの属性は聴覚的に異なる場合であってもよい。その場合、例えば、通信端末10に表示されているモンスターキャラクタを選択操作することによって、そのモンスターキャラクタの鳴き声が出力されるように構成される。そして、支援を行うユーザによる攻撃指示によって、支援を行うユーザのモンスターキャラクタと支援要請元のユーザのモンスターキャラクタとで同一の鳴き声を出力するモンスターキャラクタに対して攻撃が加えられるようにしてもよい。
上述した実施形態では、掘削実行処理のバトルモードにおいて、ユーザのバトル相手がモンスターキャラクタである場合を例として説明したが、これに限られない。例えば、ユーザのバトル相手は、そのユーザの仲間以外の他のユーザの戦士カードなどであってもよい。
上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、各ユーザによるゲームの進行を制御できることは言うまでもない。
上述した実施形態では、ネットワーク上のゲームサーバ20及びデータベースサーバ30によって、図7に示した各手段の機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末10によって実現する構成としてもよいし、少なくとも一部の手段を通信端末10によって実現する構成としてもよい。通信端末10とゲームサーバ20とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末10によっても各機能を実現できる。その場合、上述した実施形態において、ユーザデータベース、モンスターキャラクタデータ、及びバトルデータのうち少なくともいずれかを、各ユーザの通信端末10内の記憶装置(RAM13、あるいは図示しないHDD(Hard Disk Drive)などの大容量記憶装置等)や、例えばネットワーク上の別の記憶装置に記憶させてもよい。
Claims (11)
- 複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御するゲーム制御装置であって、
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶する記憶手段と、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する制御手段と、
前記複数のユーザのうち第1のユーザのキャラクタを特定する情報を、第1のユーザとは異なる第2のユーザに対して提供する提供手段と、
を備え、
前記制御手段は、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータと同時に、第1のユーザのキャラクタのキャラクタデータを変更することを特徴とする、
ゲーム制御装置。 - 前記第2のユーザに提示する表示画面において、前記第1のユーザのキャラクタと前記第2のユーザのキャラクタの各々のキャラクタデータを表示させることを特徴とする、
請求項1に記載されたゲーム制御装置。 - 各ユーザのキャラクタは属性と対応付けられており、
前記制御手段は、前記第1のユーザのキャラクタと前記第2のユーザのキャラクタとが同じ属性である場合に、前記第2のユーザの操作に応じて前記第1のユーザのキャラクタのキャラクタデータを変更することを特徴とする、
請求項1または2に記載されたゲーム制御装置。 - 前記制御手段は、前記第2のユーザに対して複数のユーザのキャラクタを特定する情報が提供された場合には、前記第2のユーザによる選択操作に基づいて、いずれかのキャラクタを選択し、
第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータとともに、選択したキャラクタのキャラクタデータを変更することを特徴とする、
請求項1~3のいずれかに記載されたゲーム制御装置。 - 前記複数のユーザの間の関連付けを記憶する第2の記憶手段、を備え、
前記提供手段は、前記第1のユーザと関連付けられているユーザを前記第2のユーザとして特定することを特徴とする、
請求項1~4のいずれかに記載されたゲーム制御装置。 - 前記複数のユーザの間の関連付けを記憶する第2の記憶手段、を備え、
前記提供手段は、前記第1のユーザと関連付けられている複数のユーザのうち、前記第1のユーザのキャラクタを特定する情報の提供を希望するか否かについて問い合わせをし、当該情報の提供を希望することを最初に回答したユーザを、前記第2のユーザとして特定することを特徴とする、
請求項1~4のいずれかに記載されたゲーム制御装置。 - 複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御するゲーム制御装置であって、
ゲーム上のユーザの敵キャラクタと、敵キャラクタのデータであるキャラクタデータとを対応付けて記憶する記憶手段と、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する制御手段と、
前記複数のユーザのうち第1のユーザの敵キャラクタを特定する情報を、第1のユーザとは異なる第2のユーザに対して提供する提供手段と、
を備え、
前記制御手段は、第2のユーザに対して第1のユーザの敵キャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザの敵キャラクタのキャラクタデータと同時に、第1のユーザの敵キャラクタのキャラクタデータを変更することを特徴とする、
ゲーム制御装置。 - 複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御するゲーム制御方法であって、
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶装置に記憶させるステップと、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更するステップと、
前記複数のユーザのうち第1のユーザのキャラクタを特定する情報を、第1のユーザとは異なる第2のユーザに対して提供するステップと、
を含み、
前記変更するステップは、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータと同時に、第1のユーザのキャラクタのキャラクタデータを変更することを特徴とする、
ゲーム制御方法。 - 複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御するために、コンピュータに、
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶装置に記憶させる機能と、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する機能と、
前記複数のユーザのうち第1のユーザのキャラクタを特定する情報を、第1のユーザとは異なる第2のユーザに対して提供する機能と、
を実現させるためのプログラムであって、
前記変更する機能は、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータと同時に、第1のユーザのキャラクタのキャラクタデータを変更することを特徴とする、
プログラム。 - 請求項8に記載されたプログラムを記録したことを特徴とする、コンピュータ読み取り可能な記録媒体。
- ユーザによって操作される通信端末と、当該通信端末とネットワークを介して接続され、各ユーザの操作に応じて、各ユーザによるゲームの進行を制御するゲーム制御装置と、を備えたゲームシステムであって、
ゲーム上のキャラクタと、キャラクタのデータであるキャラクタデータとを対応付けて記憶する記憶手段、
ユーザごとに、ユーザの操作に応じてキャラクタデータを変更する制御手段、及び、
前記複数のユーザのうち第1のユーザのキャラクタを特定する情報を、第1のユーザとは異なる第2のユーザに対して提供する提供手段、
の各手段を、前記通信端末又は前記サーバのいずれか一方が備え、
前記制御手段は、第2のユーザに対して第1のユーザのキャラクタを特定する情報が提供された場合には、第2のユーザの操作に応じて、第2のユーザのキャラクタのキャラクタデータと同時に、第1のユーザのキャラクタのキャラクタデータを変更することを特徴とする、
ゲームシステム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013550106A JP5715266B2 (ja) | 2011-12-19 | 2012-12-13 | ゲーム制御装置、プログラム、ゲームシステム |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011277722 | 2011-12-19 | ||
JP2011-277722 | 2011-12-19 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2013094160A1 true WO2013094160A1 (ja) | 2013-06-27 |
Family
ID=48668079
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2012/007982 WO2013094160A1 (ja) | 2011-12-19 | 2012-12-13 | ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム |
Country Status (2)
Country | Link |
---|---|
JP (1) | JP5715266B2 (ja) |
WO (1) | WO2013094160A1 (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6262840B1 (ja) * | 2016-12-28 | 2018-01-17 | グリー株式会社 | 制御プログラム、制御方法及びコンピュータ |
JP2020124545A (ja) * | 2020-04-15 | 2020-08-20 | 株式会社コナミデジタルエンタテインメント | ゲームシステム及びプログラム |
JP2021041300A (ja) * | 2020-12-22 | 2021-03-18 | 株式会社コナミデジタルエンタテインメント | ゲーム制御装置、ゲームシステム、及びプログラム |
JP2022087150A (ja) * | 2012-10-03 | 2022-06-09 | グリー株式会社 | オンラインゲームの同期方法、オンラインゲームの同期システム、サーバ、及びオンラインゲームの同期プログラム |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7372071B2 (ja) | 2019-07-31 | 2023-10-31 | 任天堂株式会社 | 情報処理プログラム、情報処理装置、情報処理システムおよび情報処理方法 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002224450A (ja) * | 2000-11-29 | 2002-08-13 | Aruze Corp | 通信回線網を利用した多人数参加型ゲームが実行可能なサーバ及びそのゲーム提供方法並びに記憶媒体 |
JP2010082310A (ja) * | 2008-10-01 | 2010-04-15 | Square Enix Co Ltd | ゲームシステム、ゲーム装置及びプログラム |
-
2012
- 2012-12-13 WO PCT/JP2012/007982 patent/WO2013094160A1/ja active Application Filing
- 2012-12-13 JP JP2013550106A patent/JP5715266B2/ja active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002224450A (ja) * | 2000-11-29 | 2002-08-13 | Aruze Corp | 通信回線網を利用した多人数参加型ゲームが実行可能なサーバ及びそのゲーム提供方法並びに記憶媒体 |
JP2010082310A (ja) * | 2008-10-01 | 2010-04-15 | Square Enix Co Ltd | ゲームシステム、ゲーム装置及びプログラム |
Non-Patent Citations (1)
Title |
---|
DIGITAL GAME NO KYOKASHO SEISAKU IINKAI, DIGITAL GAME NO KYOKASHO, 25 February 2011 (2011-02-25), pages 168 - 169 * |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2022087150A (ja) * | 2012-10-03 | 2022-06-09 | グリー株式会社 | オンラインゲームの同期方法、オンラインゲームの同期システム、サーバ、及びオンラインゲームの同期プログラム |
JP7234440B2 (ja) | 2012-10-03 | 2023-03-07 | グリー株式会社 | オンラインゲームの同期方法、オンラインゲームの同期システム、サーバ、及びオンラインゲームの同期プログラム |
JP6262840B1 (ja) * | 2016-12-28 | 2018-01-17 | グリー株式会社 | 制御プログラム、制御方法及びコンピュータ |
JP2018108185A (ja) * | 2016-12-28 | 2018-07-12 | グリー株式会社 | 制御プログラム、制御方法及びコンピュータ |
JP2020124545A (ja) * | 2020-04-15 | 2020-08-20 | 株式会社コナミデジタルエンタテインメント | ゲームシステム及びプログラム |
JP7106152B2 (ja) | 2020-04-15 | 2022-07-26 | 株式会社コナミデジタルエンタテインメント | ゲームシステム及びプログラム |
JP2021041300A (ja) * | 2020-12-22 | 2021-03-18 | 株式会社コナミデジタルエンタテインメント | ゲーム制御装置、ゲームシステム、及びプログラム |
JP7180901B2 (ja) | 2020-12-22 | 2022-11-30 | 株式会社コナミデジタルエンタテインメント | ゲーム制御装置、ゲームシステム、及びプログラム |
Also Published As
Publication number | Publication date |
---|---|
JP5715266B2 (ja) | 2015-05-07 |
JPWO2013094160A1 (ja) | 2015-04-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5882188B2 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
JP5646537B2 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
JP5436612B2 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
JP5715615B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
JP5551210B2 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
JP5557876B2 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
JP5838149B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
JP5715266B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
JP5535272B2 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
WO2013140481A1 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム | |
JP5548240B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
WO2013154020A1 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲーム制御システム | |
JP5771587B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
JP5395210B2 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、コミュニケーション装置 | |
JP5562400B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
JP2014027983A (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
JP2013183768A (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
WO2013124932A1 (ja) | ゲーム制御装置、ゲーム制御方法、ゲーム制御プログラム、記録媒体、ゲームシステム | |
JP2015128668A (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
JP6240977B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
JP6206772B2 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
JP6007208B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
JP6168525B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
JP5839711B2 (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: 12858974 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2013550106 Country of ref document: JP Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 12858974 Country of ref document: EP Kind code of ref document: A1 |