WO2022065502A1 - マルチバトルを含むゲームのためのプログラム、方法、電子装置及びシステム - Google Patents

マルチバトルを含むゲームのためのプログラム、方法、電子装置及びシステム Download PDF

Info

Publication number
WO2022065502A1
WO2022065502A1 PCT/JP2021/035493 JP2021035493W WO2022065502A1 WO 2022065502 A1 WO2022065502 A1 WO 2022065502A1 JP 2021035493 W JP2021035493 W JP 2021035493W WO 2022065502 A1 WO2022065502 A1 WO 2022065502A1
Authority
WO
WIPO (PCT)
Prior art keywords
player
battle
enemy character
input
participation request
Prior art date
Application number
PCT/JP2021/035493
Other languages
English (en)
French (fr)
Inventor
伊織 大内
見 岩間
貴文 佐藤
亮 北沢
Original Assignee
株式会社Cygames
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社Cygames filed Critical 株式会社Cygames
Priority to CN202180066274.9A priority Critical patent/CN116209504A/zh
Publication of WO2022065502A1 publication Critical patent/WO2022065502A1/ja
Priority to US18/191,473 priority patent/US20230233939A1/en

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/50—Controlling the output signals based on the game progress
    • A63F13/53—Controlling the output signals based on the game progress involving additional visual information provided to the game scene, e.g. by overlay to simulate a head-up display [HUD] or displaying a laser sight in a shooting game
    • A63F13/537—Controlling the output signals based on the game progress involving additional visual information provided to the game scene, e.g. by overlay to simulate a head-up display [HUD] or displaying a laser sight in a shooting game using indicators, e.g. showing the condition of a game character on screen
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/45—Controlling the progress of the video game
    • A63F13/48—Starting a game, e.g. activating a game device or waiting for other players to join a multiplayer session
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/55—Controlling game characters or game objects based on the game progress
    • A63F13/58—Controlling game characters or game objects based on the game progress by computing conditions of game characters, e.g. stamina, strength, motivation or energy level
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A63F13/795—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for finding other players; for building a team; for providing a buddy list
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/80—Special adaptations for executing a specific game genre or game mode
    • A63F13/822—Strategy games; Role-playing games
    • 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

Definitions

  • the present invention relates to a program or the like for a game including a multi-battle, and more particularly to a program or the like for increasing a player's motivation to play a game.
  • Patent Document 1 a system in which a player who has started a battle with an enemy character requests another player to participate in the battle, and after the other player participates, a support effect for strengthening the status under specific conditions is given.
  • the present invention has been made to solve such a problem, and an object of the present invention is to provide a program or the like for increasing a player's motivation to play a game.
  • the program in one embodiment of the present invention is a program for a game including a multi-battle in which a plurality of players play against a common enemy character, and the computer is multi-player from the player.
  • the stage of accepting the participation request input from the player for the purpose and the stage of executing the process of damaging the enemy character when the participation request input is received are executed.
  • the player possesses one or more characters, plays against an enemy character using the possessed character, and executes the process of inflicting the damage regardless of whether or not the player possesses the character. It may include a step of displaying an effect expressing damage to an enemy character by an effect character selected from a predetermined character.
  • the step of executing the process of giving damage can include a step of selecting a production character from characters preselected by another player.
  • the stage of executing the process of damaging the enemy character is the stage of executing the lottery process for determining whether or not to damage the enemy character, and the step of executing the lottery process to the enemy character. It may include a step of inflicting damage on the enemy character when it is determined to inflict damage on the enemy character.
  • the probability for determining that the enemy character is damaged may be determined based on the parameters assigned to the enemy character.
  • the damage is a value equal to or greater than the remaining hit points of the enemy character, and it is possible to prevent another player from executing the participation request process based on the participation request input.
  • the damage is a value less than the remaining hit points of the enemy character, and the participation request processing can be executed for other players based on the participation request input.
  • the method in one embodiment of the present invention is a method for a game including a multi-battle in which a plurality of players play against a common enemy character, and is a stage of accepting a multi-battle start input from a player to a computer. Based on the multi-battle start input, the stage of starting a multi-battle to play against a predetermined enemy character and the participation request input from the player for requesting another player to participate in the started multi-battle. And when the participation request input is received, the stage of executing the process of damaging the enemy character is executed.
  • the electronic device is an electronic device for a game including a multi-battle in which a plurality of players play against a common enemy character, and receives and accepts a multi-battle start input from the player. Based on the start input, a multi-battle to play against a predetermined enemy character is started, and a participation request input from the player for requesting another player to participate in the started multi-battle is accepted and a participation request is made. When the input is received, the process of damaging the enemy character is executed.
  • the system in one embodiment of the present invention is a system for a game including a multi-battle in which a plurality of players play against a common enemy character, and the system is a server and a player of each player connected to the server.
  • the server including the terminal receives the player's multi-battle start input transmitted from the player terminal, starts a multi-battle against a predetermined enemy character based on the received multi-battle start input, and starts the multi-battle from the player terminal.
  • the transmitted participation request input of the player for requesting the other player to participate in the started multi-battle is accepted and the participation request input is received, the process of damaging the enemy character is performed.
  • the game system 1 is realized by a system in which a plurality of player terminals are connected to a server via a network.
  • FIG. 1 shows an example of the overall configuration of the game system 1 according to the embodiment of the present invention.
  • the game system 1 includes a plurality of player terminals 10 and a server 20, and the player terminals 10 and the server 20 are connected to a network 2 such as the Internet and can communicate with each other.
  • the game system 1 of the present embodiment will be described assuming a server-client system.
  • the game system 1 in the present embodiment executes a battle in which the player character plays against an enemy character. You may play against an enemy character by yourself, or you may request the participation of another player and play against a common enemy character in collaboration with the other players who participated in response to the participation request. A battle in which multiple players can jointly play against a common enemy character is called a multi-battle.
  • FIG. 2 is a block diagram showing a hardware configuration of a player terminal 10 and a server 20 according to an embodiment of the present invention.
  • the player terminal 10 includes a processor 11, a display device 12, an input device 13, a storage device 14, and a communication device 15. Each of these components is connected by a bus 16. It is assumed that an interface is interposed between the bus 16 and each component as necessary.
  • the player terminal 10 is a smartphone.
  • the player terminal 10 can be an electronic device such as a tablet computer, a personal computer, or a game device as long as it has the above configuration.
  • the server 20 also includes a processor 21, a display device 22, an input device 23, a storage device 24, and a communication device 25. Each of these components is connected by a bus 26. It is assumed that an interface is interposed between the bus 26 and each component as necessary.
  • the server 20 is realized by a computer.
  • the processors 11 and 21 control the operation of the player terminal 10 or the server 20 as a whole, and are, for example, a CPU. As the processors 11 and 21, an electronic circuit such as an MPU may be used. The processors 11 and 21 execute various processes by reading and executing programs and data stored in the storage devices 14 and 24. In one example, the processors 11 and 21 are composed of a plurality of processors.
  • the display devices (displays) 12 and 22 display the application screen and the like to the user (player) of the player terminal 10 or the user (administrator) of the server 20 according to the control of the processors 11 and 21.
  • a liquid crystal display is preferable, but a display using an organic EL, a plasma display, or the like may be used.
  • the input devices 13 and 23 are user interfaces that receive input from the user to the player terminal 10 and the server 20, and are, for example, a touch panel, a touch pad, a keyboard, or a mouse. Since the player terminal 10 is a smartphone in the present embodiment, the player terminal 10 includes a touch panel as an input device 13, the touch panel also functions as a display device 12, and the display device 12 and the input device 13 have an integrated structure. .. The display device 12 and the input device 13 may be in separate forms arranged at different positions. Since the server 20 is a computer, it is assumed that a keyboard and a mouse are provided as an input device and a liquid crystal display is provided as a display device.
  • the storage devices 14 and 24 include general smartphones and computers including a storage device using a flash memory such as RAM which is a volatile memory and eMMC, UFS, SSD which is a non-volatile memory, and a magnetic storage device. It is a storage device.
  • the storage devices 14 and 24 may also include an external memory.
  • the storage device 14 stores a browser program or a game program
  • the storage device 24 stores a server game program.
  • the browser program and the game program are started in response to a user's operation on the player terminal 10 and executed on an operating system (OS) previously implemented by the player terminal 10.
  • the game program for a server includes a browser program executed on each player terminal as a client, a function for processing information so that the game progresses appropriately on the game program, and various data.
  • the storage devices 14 and 24 include a main storage device and an auxiliary storage device.
  • the main storage device is a volatile storage medium capable of high-speed reading and writing of information, and is used as a storage area and a work area when the processors 11 and 21 process information.
  • the auxiliary storage device stores various programs and data used by the processors 11 and 21 when executing each program.
  • the auxiliary storage device is, for example, a hard disk device, but may be any non-volatile storage or non-volatile memory as long as it can store information, and may be removable.
  • the auxiliary storage device stores, for example, an operating system (OS), middleware, application programs, various data that can be referred to when these programs are executed, and the like.
  • OS operating system
  • middleware middleware
  • application programs various data that can be referred to when these programs are executed, and the like.
  • a database physically separated from the player terminal 10 and the server 20 can also be used.
  • Communication devices 15 and 25 exchange data with other devices via network 2 (omitted in FIG. 2).
  • the communication devices 15 and 25 perform wireless communication such as mobile communication and wireless LAN, and connect to the network 2.
  • the player terminal 10 communicates with the server 20 via the network by using the communication device 15.
  • the communication devices 15 and 25 may perform wired communication using an Ethernet (registered trademark) cable or the like.
  • FIG. 3 shows an example of a functional block diagram of the player terminal 10 and the server 20 according to the embodiment of the present invention.
  • the player terminal 10 includes an input unit 31, a display unit 32, a communication unit 33, a game control unit 34, and a storage unit 35
  • the server 20 includes an input unit 41, a display unit 42, a communication unit 43, a game control unit 44, and a storage unit.
  • a unit 45 is provided.
  • these functions are realized by the processors 11 and 21 executing the program.
  • the program to be executed is a browser program or a game program stored in the storage devices 14 and 24. In this way, since various functions are realized by reading the program, another part may have a part or all of one part (function).
  • These functions may also be realized by hardware by configuring an electronic circuit or the like for realizing a part or all of each function.
  • the input units 31 and 41 are configured by using the input devices 13 and 23, and receive input from the user to the player terminal 10 and the server 20.
  • the player terminal 10 and the server 20 receive user input by the input units 31 and 41.
  • the user input may include, for example, a command input indicating a player's command in the game.
  • the player terminal 10 can use the touch detection function generally possessed by a smartphone provided with a touch panel.
  • the display unit 32 of the player terminal 10 displays the game screen using the display device 12, and displays the game screen according to the progress of the game and the user operation.
  • the display unit 42 of the server 20 displays a management screen for the game administrator on the display device 22 as needed.
  • the game control units 34 and 44 store the control processing for executing the game of the present embodiment and various data necessary for the processing in the storage units 35 and 45.
  • the game control unit 34 of the player terminal 10 is realized by using a browser program, and processes input / output information to the user, processing of transmission / reception signals to the server 20, and the like.
  • the game application may be realized by installing it on the player terminal 10.
  • the game control unit 44 of the server 20 executes and realizes the game program for the server, and performs processing for the game executed on the player terminal 10.
  • the game control unit 44 needs to be periodically or required when the browser is launched on the player terminal 10 to realize the game control unit 34 and access the server 20 to advance the game. Data is sent and received according to the above, and the game progresses.
  • the game control unit 44 stores control processing and various necessary data for executing the game of the present embodiment in the storage unit 45, and appropriately provides the player terminal 10.
  • the game control unit 44 executes the process associated with the command based on the command input received via the communication unit 43.
  • command input participation request input (participation request command input) and attack input (attack command input) to other players will be described, but it is possible to include other commands such as ability use commands to those skilled in the art. Is clear.
  • the storage units 35 and 45 are configured by using the storage devices 14 and 24.
  • player parameters include, for example, information such as a player ID, a name, a level, a weapon possessed, a character possessed, an item possessed, a favorite character, a guild to which the player belongs, and a player ID of a player who is a friend.
  • the parameters related to the possessed character can include a character ID, a name, a level, an attack power, a defense power, a hit point, and the like.
  • a guild is a group consisting of multiple players, and enjoys chatting within the group, cooperates to defeat enemies, and competes among guilds for the total number of points earned by members in an event.
  • Friend does not form a specific group unlike guild, but it means that players have a predetermined cooperative relationship, for example, friendship is set by mutual agreement and lending and borrowing of items possessed. It is possible to cooperate such as doing.
  • Player parameters may include information about multi-battles that can participate. For example, in a battle started by one player, when that player inputs a participation request command to another player, another player who issues a participation request is executed by executing the participation request processing described later. Information for participating in the multi-battle can be stored as a part of the parameters of the determined player (participation requesting player).
  • Enemy character parameters include, for example, the enemy character's ID, name, level, attack power, defense power, hit points, and the like.
  • the battle parameters include the parameters of the players participating in the battle and the parameters of the enemy character.
  • the player selects four characters from the plurality of possessed characters and starts the battle. It is assumed that the information of the selected player character is included as the player parameter in the battle parameter.
  • each parameter can change as the battle progresses. For example, hit points are reduced by the opponent's attack, and attack power and defense power can be increased or decreased by special abilities. Further, when a plurality of players are participating in the battle, the parameters of these participating players are stored in association with each other.
  • the server 20 when the server 20 receives an attack input (attack input command) from the player, it executes a process of giving the first damage determined based on the attack ability value of the player character to the enemy character (S554). .. Further, in the present embodiment, when the server 20 receives the participation request input (participation request input command) and the attack input (attack input command) from the player, the enemy character receives a second damage different from the first damage. (S518 and S548).
  • the second damage the magnitude of the damage is determined based on a predetermined probability without depending on the ability value of the player character.
  • the first damage is the ability value-dependent damage and the second damage is the non-ability value-dependent damage, but the second damage may also be the ability value-dependent type.
  • the predetermined probability for non-ability value dependent damage is determined in advance based on the level of the enemy character, and is stored in the storage unit 45 of the server 20 as a damage probability table.
  • the damage probability table for the participation request input and the damage probability table for the attack input are prepared respectively.
  • the non-ability value dependent damage is not limited to the attack power of the player character, for example, it is a one-shot deadly damage that causes damage equal to or more than all the hit points of the enemy character with a single blow, or it is less than the remaining hit points of the enemy character. It can be a large amount of damage such as 80% of the total HP of the enemy character or 1 million damage.
  • the non-ability value dependent damage may be determined not based on the defense power of the enemy character, unlike the normal ability value dependent damage. Tables 1 and 2 show an example of the damage probability table.
  • Table 1 shows the damage probability table for the participation request input.
  • the probability of inflicting non-ability value dependent damage on the enemy character is determined in advance according to the enemy character level. For example, when the enemy character level is 40, when the participation request input is accepted, the enemy character is damaged with a probability of 20.0%.
  • Table 2 shows the damage probability table for attack input.
  • the probability of inflicting non-ability value dependent damage on the enemy character is determined in advance according to the enemy character level and the elapsed turn. For example, when the enemy character level is 40 and an attack input is made during the elapsed turns 0 to 4, the enemy character is damaged with a probability of 1.0%. After the non-ability value dependent damage is given to the attack input with a predetermined probability, if the enemy character is alive, the ability value dependent damage based on the normal attack input can be given.
  • the damage probability is determined according to the elapsed turn, but the damage probability is determined regardless of the turn-based strategy, for example.
  • the damage probability can be determined regardless of the elapsed turn.
  • the damage probability may be determined according to the elapsed time.
  • the game system in the present embodiment is a system for a game in which a plurality of players can play against a common enemy character.
  • the battle with the enemy character is started based on the multi-battle start input by one player, but a plurality of people may cooperate to start the battle.
  • the player may defeat the enemy character alone.
  • the player may make a participation request to another player, respond to the participation request, and collaborate with another player who participated in the multi-battle to defeat a common enemy character.
  • the player terminal 10 of each player is connected to the server 20, and the players participating in the battle attack a common enemy, and when the HP of the common enemy character becomes zero, the player wins and all. If the HP of the player character of the participating player becomes zero, the enemy character wins.
  • the flowchart shown in FIG. 4 shows information processing executed between the server 20 and one player terminal 10, and the same processing is performed in parallel for the player terminals 10 of all the players participating in the battle. Can be executed separately.
  • the processes executed in parallel can be executed, for example, in association with each player ID.
  • the battle start request (S401) and the battle start process (S402) are processes for the player terminal 10 that starts the battle, and the participation request (S401) and the participation request (S401) for the player terminal 10 that participates in the battle in response to the participation request.
  • the participation start process (S402) is executed instead.
  • the term player means the player of the player terminal 10 executing the information processing of the flowchart, and the player character is associated with the player ID of the player and is selected for the battle. It is a player character that has been processed.
  • one of the players inputs an operation via the player terminal 10 and sends a battle start request to the server 20 (S401).
  • the server 20 receives the battle start request, the server 20 generates a battle parameter based on the player ID (PID) included in the battle start request, stores it in the storage unit 45, and starts the battle (S402).
  • PID player ID
  • the server 20 generates battle screen information corresponding to the PID and transmits it to the player terminal 10 associated with the PID (S404).
  • screen information including an image of an enemy character and a player character associated with the PID is generated. It was
  • the player terminal 10 When the player terminal 10 receives the battle screen information, the player terminal 10 displays the battle screen including the command input button on the display unit 32 (S406). Then, the player terminal 10 listens for a command input from the player (S408), and when the input unit 31 receives the command input from the player, the player terminal 10 transmits the command input to the server 20 via the communication unit 33 (S410).
  • FIG. 7 shows an example of the battle screen.
  • the battle screen includes an enemy character image 701, an enemy character remaining HP (%) 702, a player character image 711 to 714, an attack button 721, a player character designation button 731 to 734, and a participation request button 741.
  • the input unit 31 of the player terminal 10 detects the touch of the attack button 721 or the participation request button 541 by the player, the input unit 31 receives a command input (attack input or participation request input) instructing the execution of the attack command or the participation request command. It is transmitted to the server 20 via the communication unit 33 (S410). Further, when the player character images 731 to 734 are touched, the ability button for executing the ability peculiar to each character is further displayed, and by touching the ability button by the player, it is accepted as a command input instructing the ability execution, and the server. It can also be transmitted to 20.
  • the server 20 listens for a command input (attack input or participation request input) from the player terminal 10 (S412), and when it receives the command input, executes the command specified by the command input (S414), and by executing the command.
  • the generated effect screen information (effect information) is transmitted to the player terminal 10 (S416).
  • the player terminal 10 displays the effect screen on the display unit 32 based on the effect screen information (S418).
  • the effect is not limited to the screen display effect, and may be an effect of only the sound, or an effect including the screen and the sound may be performed.
  • the server 20 determines whether or not the battle has ended by executing the command (S414) (S420). It is determined whether or not the remaining HP of the enemy character has become zero by executing the command, and whether or not the remaining HP of the player character has become zero. do. If the battle is not completed, the process returns to the command input standby (S412), and the server 20 repeatedly executes the above process until the battle end is determined.
  • the battle end notification including the battle result and the effect screen information is transmitted from the server 20 to the player terminal 10 (S422).
  • the player terminal 10 waits for the battle end notification (S424) and receives the battle end notification, the effect screen is displayed on the display unit 32 and the battle result is displayed on the player based on the battle result and the effect screen information (S426). ), End the battle (S430). If the player terminal 10 does not accept the battle end notification, it returns to the standby for command input (S408) and repeatedly executes the above process until the battle end notification is received.
  • the server 20 determines the type of the command input (S501). In the present embodiment, it is assumed that there are two types, an attack command input when the attack button 721 is touched and a participation request command input when the participation request button 741 is touched, but only one of these is used. It doesn't matter if there is any other command input.
  • the server 20 When the command input is a participation request command input, the server 20 generates information for displaying an effect screen for the player to specify a target for participation request, and transmits the information to the player terminal 10 (S502). .
  • the player terminal 10 When the player terminal 10 receives the effect screen information, it displays the effect screen for designating the participation request target based on the effect screen information (S504), and when it receives the participation request target input from the player, it transmits this to the server 20.
  • Figure 8 shows an example of the production screen for specifying the target for requesting participation.
  • the "everyone" button 801 for sending the participation request to all the players
  • the “friend” button 802 for sending to the player's friends, and the guild.
  • a “guild” button 803 to send to the member is displayed.
  • the participation request is made to a predetermined number of players randomly selected from all the players.
  • the participation request button 810 is touched, the participation request target input is transmitted to the server 20.
  • Participation requests can also be made by generating an identifier that identifies the battle and disclosing the identifier via a social networking service or the like. Another player who sees this can participate in the battle by inputting an identifier on a predetermined screen.
  • the incompetence value-dependent damage processing can be executed.
  • the "Everyone” button 801 is touched and turned on, a display indicating that incompetence value-dependent damage may be given as "special relief” as shown in FIG. (820).
  • the incompetence value-dependent damage processing may be executed, or "everyone” may be executed.
  • “Friends” and “Guilds” may be used to execute the incompetence value-dependent damage processing when a participation request is input to any one or more of them.
  • it may be configured so that only one or two of "everyone", “friend”, and “guild” can be selected to participate, or a request to participate in some other player's group may be made. It doesn't matter if you can select it.
  • the server 20 determines whether or not the player who input the participation request is the player who started the battle, that is, a so-called spontaneous person (S508).
  • the incompetence value-dependent damage processing to the enemy character is executed only for the participation request input of the spontaneous person.
  • a player consumes a predetermined item and starts a battle with an enemy character
  • the execution of the damage processing to the enemy character based on the participation request input may not be limited to the spontaneous person.
  • the process proceeds to the participation request player determination process (S526), and when it is determined that the player is a spontaneous person, the participation request is dependent on the non-ability value. It is determined whether or not the participation request target to be the target of the damage processing execution, here, "everyone" is specified (S510). If “everyone” is not included, the process proceeds to the participation request player determination process (S526), and if "everyone” is included, the enemy character is inflicted with non-ability value dependent damage. Whether or not it is determined (S512).
  • the server 20 determines whether or not to inflict damage based on the damage probability table stored in the storage unit 45 by a lottery process, but the server 20 may always inflict damage or is predetermined. You may decide whether to do damage according to the pattern. Further, the lottery process may be executed a predetermined number of times, and if the damage dealt is not determined even once within the predetermined number of times, the damage may be determined.
  • the damage probability table for the participation request input shown in Table 1 it is determined whether or not to damage the enemy character by using the damage probability table for the participation request input shown in Table 1.
  • the enemy character level is read from the battle parameters stored in the storage unit 45, the damage probability is determined based on the read enemy character level, and a lottery is performed to determine whether or not to inflict damage based on the determined damage probability. Processing shall be performed using random numbers. Any process may be used as long as the damage dealt can be determined with a predetermined probability.
  • the damage-damaged character is an effect of damaging an enemy character displayed on the display unit 32 of the player terminal 10, and is a character for effect that is the main component of the damage. Here, it is a single character, but it may be a plurality of characters.
  • FIG. 6 shows the process for determining the damaged character in this embodiment.
  • the damaged character is randomly selected from the characters registered as favorite characters by other players in the guild in which the player who entered the participation request is participating, or is randomly selected from the predetermined characters. do.
  • the damage character does not need to be selected from the characters of the player to whom the participation request is sent.
  • the player belongs to the guild based on the guild ID included in the player parameter of the player who input the participation request (S601). If it is determined that the player belongs to a guild, the number of players of other players participating in the guild is specified based on the guild ID. Then, it is determined whether or not the number of players participating in the guild is a predetermined number, here 5 or more (S602), and if it is determined that the number of players is 5 or more, the guild is entered by lottery processing. Another player is determined, and the determined favorite character of the other player is determined as the damage character.
  • each player may be allowed not to set a favorite character.
  • another player may be determined by the lottery process from the players who have set the favorite character in the guild, or after the other player is determined by the lottery process from all the players in the guild, the other player may be determined.
  • the damage character may be determined from the predetermined character by the lottery process. It is also possible that not all other players in the guild have set their favorite characters. In such a case, a character randomly selected from a predetermined character may be determined as a damage character.
  • the determination of the number of players participating in the guild (S602) may be used as the number of players for which a favorite character is set.
  • a character selected from a plurality of predetermined characters can be selected regardless of whether or not the player possesses it.
  • Even if the characters themselves are the same, other versions with different rarities, attributes, and other parameters may be provided. Here, even if they are the same character, they are treated as different characters if they have different versions.
  • the incompetence value-dependent damage processing includes a process of determining the amount of damage given to an enemy character and calculating the remaining HP of the enemy character based on the determined damage.
  • the damage given to the enemy character is a one-shot deadly damage
  • the magnitude of the damage given to the remaining HP of the enemy character is set
  • the remaining HP in the enemy character parameter is set to zero. If there are multiple enemy characters, all the enemy characters shall be defeated with a single blow, but only some of the enemy characters may be defeated. You may randomly inflict damage equal to or greater than the remaining HP of the enemy character.
  • the points given in one battle are calculated according to the amount of damage done to the enemy character, and the ranking of the participating players is determined according to the number of points, and rewards are given according to the ranking.
  • the point calculation for determining this ranking may be performed without including the incompetence value-dependent damage.
  • the effect screen information is generated based on the determined damaged character and transmitted to the player terminal 10 (S520), and the player terminal 10 displays the effect screen on the display unit 32 based on this (S522). ..
  • FIG. 9 shows an example of the production screen.
  • the message "A powerful companion recommended by player F has come to the rescue!” (901) is displayed, and the favorite character of player F uses the special move A against the enemy character.
  • the effect of making an attack is displayed (902).
  • the character of the player who requested the participation is not displayed during this effect.
  • a character selected from the recommended characters of other players in the guild instead of the character of the player who entered the participation request, displays the effect of defeating the enemy character, the effect of the character that he does not own can be displayed. It becomes possible to see it, and it is possible to enhance the interest.
  • the player name such as the guild member who possesses the character who came to the rescue is displayed.
  • the simulated experience that the characters of other players in the guild come to the rescue can enhance the sense of unity with other players. Also, by making your favorite character appear in the battle of other players, you can feel the fun of introducing your favorite character.
  • the server 20 stores the information for generating the effect image information of the character in the storage unit 45, so that the effect image information is generated based on this. , Can be transmitted to the player terminal 10.
  • the player terminal 10 only needs to display the effect image based on the received effect image information.
  • the participation request player who is the player who receives the participation request is determined based on the participation request target input selected by the player (S526).
  • the non-ability value-dependent damage is one-shot deadly damage, so if it is decided to inflict damage, the remaining HP of the enemy character will be zero. In this case, the participation request processing for other players including the determination of the participation request player and the participation request player registration is not executed.
  • participation request target input is "everyone”
  • one or more players are randomly determined from all the players, and if it is "friend”, the friends of the player who input the participation request are randomly selected.
  • One or more players are determined, and in the case of "guild”, all guild members are determined as participating request players (S526).
  • Participation request player registration is executed by adding the participation request information that enables participation in the battle to the player parameters stored in the storage unit 45 of the determined participation request player (S528).
  • the participation request reward is provided to the player who requested the participation.
  • a potion which is an item for recovering the HP of the player character, is registered in the player parameter of the player (S530).
  • the processing for incapacity-dependent damage for example, S512 to S516 may be executed only once, or the participation request is made.
  • the number of damage processing to be executed may be determined based on the number of groups. For example, even when a participation request is issued to two groups, S512 to S516 may be executed only once, S512 to S518 may be executed twice, or S512.
  • ⁇ S516 may be executed only once, and only the process of giving damage to S518 and S520 and displaying the effect may be executed twice.
  • the participation request After entering the participation request, after a predetermined period of time has passed, the participation request can be entered repeatedly, and every time the participation request is re-entered, the processing for incapacity-dependent damage is executed. You may. For example, when the participation request is input to "everyone", the participation request processing is executed only for some players randomly selected from all the players. By repeatedly inputting participation requests, it is possible to increase the number of players who issue participation requests.
  • a participation request is issued to all players in the guild by one participation request for the "guild", and for such a group, the participation request can be input only once. It can also be.
  • the participation request can be executed only for the "guild” and the participation request can be input only once
  • the participation request is input once and the processing for the incapacity value type damage is executed.
  • the display is changed to the participation request button, for example, the special participation request button is displayed, and if there is a touch input to the special participation request button, the processing for damage is executed. You may do so. Even in a mode in which the participation request cannot be input again, it is possible to execute the processing for inflicting damage at predetermined time intervals.
  • the game control unit 44 reads out the player parameters for the player from the storage unit 45, and determines that the participation request information is included. Display a button on the player terminal 10 to encourage participation in the battle. When the button is touched, a request to participate in the battle is input, the process of participating in the battle is executed, and the battle screen information is transmitted. The battle screen is displayed on the player terminal 10 that receives this.
  • a participation request input is transmitted from the player terminal 10 instead of the battle start request described above (S401), and the server 20 executes the participation start process instead of the battle start process (S402). Subsequent processing may be the same as the processing described above in relation to FIG. 4, so that the battle processing of the battle participants can be executed.
  • the effect screen information is generated (S560). For example, it generates exercise screen information such as displaying information indicating that a participation request has been made or displaying information indicating that a potion has been acquired as a participation reward.
  • the attack input damage probability table shown in Table 2 is used as the damage probability table used for determining the non-ability value dependent damage damage based on the attack input.
  • the damage probability is set to increase as the turn progresses. For example, if the damage dealt is a one-shot deathblow, if you continue fighting while avoiding annihilation, a one-shot deathblow will occur, increasing the possibility that even an enemy that cannot normally be defeated can be defeated. Even a player with insufficient strength can feel the joy of making a strategy and playing against a strong enemy, so that the motivation to voluntarily battle can be increased and the number of battles generated can be increased. In addition, even a player with sufficient strength can finish a battle that takes a certain amount of time to defeat an enemy in a shorter time, and it is possible to increase the motivation to voluntarily perform more battles. can.
  • the normal ability value dependent damage processing is executed (S554).
  • the ability value-dependent damage (first damage) given to the enemy character is determined based on the attack power of the player character, the defense power of the enemy character, and the like.
  • the damage to the enemy character is determined, the remaining HP of the enemy character is calculated.
  • it is determined whether or not the remaining HP of the enemy character is larger than zero S556, and if it is zero, the process proceeds to the effect screen information generation process (S560), and if it is larger than zero, it is due to the attack of the enemy character.
  • the damage processing of the player character is executed (S558).
  • the damage received by the player character is determined based on the attack power of the enemy character, the defense power of the player character, and the like. If it is determined that the HP of the enemy character is zero, the damage processing is skipped.
  • the effect screen information is generated (S540). For example, it generates information for displaying a screen that directs an attack of a player character or an enemy character.
  • the generated effect image information is transmitted to the player terminal 10 in S416 of FIG. 4 and displayed on the display unit 32 of the player terminal 10. For example, when the enemy HP becomes zero in the damage processing (S516), as shown in FIG. 10, the effect image when the enemy character is defeated is displayed. While the damage processing is executed and the effect image as shown in FIG. 9 is displayed, the self-character that has been hidden may be displayed again.
  • the player can increase the possibility of defeating the enemy character by the second damage such as the non-ability value dependent damage.
  • the second damage such as the non-ability value dependent damage.
  • the second damage a one-shot kill, that is, the amount of damage dealt to the remaining HP of the enemy character or more, even a player with insufficient strength can start a battle with a powerful enemy character. Can motivate you. Even if the player's strength is sufficient, the time required to defeat the enemy character can be shortened, and more battles can be started.
  • the player's strength is not sufficient, the enemy character cannot be defeated in the first place and items etc. cannot be acquired. Even if the enemy character can be defeated by the participation of another player with sufficient strength, if the reward is determined in the order of the amount of damage given to the enemy character, the reward will be given to the other player with sufficient strength. A player who is given and has insufficient strength cannot sufficiently acquire items and the like that are useful for strengthening the strength. For this reason, the difference in strength with a player with high strength will increase more and more. By using this embodiment, even a player with low strength can defeat an enemy character with a certain probability and give the possibility of acquiring an item. As a result, even a beginner who has just started the game can actively voluntarily take part in the battle and motivate him to continue playing.
  • the motivation of the player to play the game is increased, the number of battles in the entire game system is increased, the number of requests for participation is increased, and the number of battles that can be played even if the player does not voluntarily increases. , It becomes possible to activate the whole game.
  • the process or operation described above can be freely performed as long as there is no contradiction in the process or operation such as using data that should not be available in that step at a certain step. Can be changed.
  • the examples described above are examples for explaining the present invention, and the present invention is not limited to these examples.
  • the present invention can be carried out in various forms as long as it does not deviate from the gist thereof.
  • Game system 2 Network 10: Player terminal 11: Processor 12: Display device 13: Input device 14: Storage device 15: Communication device 16: Bus 20: Server 21: Processor 22: Display device 23: Input device 24: Storage Device 25: Communication device 26: Bus 31: Input unit 32: Display unit 33: Communication unit 34: Game control unit 35: Storage unit 41: Input unit 42: Display unit 43: Communication unit 44: Game control unit 45: Storage unit 541: Participation request button 721: Attack button 741: Participation request button 810: Participation request button

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Optics & Photonics (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

プレイヤのゲームプレイ意欲を高めるためのプログラム等を提供する。複数のプレイヤが共通の敵キャラクタと対戦するマルチバトルを含むゲームのためのプログラムであって、コンピュータに、プレイヤからのマルチバトル開始入力を受け付ける段階と、受け付けたマルチバトル開始入力に基づいて、所定の敵キャラクタと対戦するマルチバトルを開始する段階と、他のプレイヤに対して前記開始されたマルチバトルへ参加を依頼するための前記プレイヤからの参加依頼入力を受け付ける段階と、参加依頼入力を受け付けると、前記敵キャラクタに対してダメージを与える処理を実行する段階と、を実行させることを特徴とするプログラム。

Description

マルチバトルを含むゲームのためのプログラム、方法、電子装置及びシステム
　本発明は、マルチバトルを含むゲームのためのプログラム等であって、特に、プレイヤのゲームプレイ意欲を高めるためのプログラム等に関する。
　近年のオンラインゲーム等の普及に伴い、複数のプレイヤが共通の敵キャラクタとの対戦（バトル）を行うゲームがリリースされている。このようなゲームにおいて、敵キャラクタとのバトルを開始したプレイヤが他のプレイヤにバトルへの参加依頼を行い、他のプレイヤが参加した後、特定の条件下においてステータスを強化するサポート効果を与えるシステムが知られている（特許文献１）。
特開２０１９－１９３８９０号公報
　しかしながら、プレイヤの戦力が低い場合にはステータスの強化程度ではバトルに勝利できないおそれがあり、また参加依頼を出したとしても他のプレイヤがバトルに参加するのか、また参加したとしても即座に参加するものかは約束されていない。このため、バトルになかなか勝利することができず、ゲームをプレイすることへの意欲を低下させるおそれがある。
　本発明は、このような課題を解決するためになされたものであり、プレイヤのゲームプレイ意欲を高めるためのプログラム等を提供することを主目的とする。
　上記の目的を達成するために、本発明の一実施態様におけるプログラムは、複数のプレイヤが共通の敵キャラクタと対戦するマルチバトルを含むゲームのためのプログラムであって、コンピュータに、プレイヤからのマルチバトル開始入力を受け付ける段階と、受け付けたマルチバトル開始入力に基づいて、所定の敵キャラクタと対戦するマルチバトルを開始する段階と、他のプレイヤに対して前記開始されたマルチバトルへ参加を依頼するための前記プレイヤからの参加依頼入力を受け付ける段階と、参加依頼入力を受け付けると、前記敵キャラクタに対してダメージを与える処理を実行する段階と、を実行させる。
　前記ゲームにおいては、プレイヤは１以上のキャラクタを所持し、所持するキャラクタを用いて敵キャラクタと対戦し、前記ダメージを与える処理を実行する段階は、前記プレイヤが所持するか否かによらず、所定のキャラクタの中から選択された演出用キャラクタによって敵キャラクタに対してダメージを与えることを表現する演出を表示させる段階を含んでもよい。
　前記ダメージを与える処理を実行する段階は、他のプレイヤによって予め選択されたキャラクタから演出用キャラクタを選択する段階を含むことができる。
　前記敵キャラクタに対してダメージを与える処理を実行する段階は、前記敵キャラクタに対してダメージを与えるか否かを決定するための抽選処理を実行する段階と、抽選処理の結果、前記敵キャラクタに対してダメージを与えることが決定した場合に、前記敵キャラクタに対してダメージを与える段階と、を含んでもよい。
　また、前記抽選処理において、前記敵キャラクタに対してダメージを与えると決定するための確率は前記敵キャラクタに割り当てられたパラメータに基づいて決定されるようにしてもよい。
　前記ダメージは前記敵キャラクタの残りヒットポイント以上の値であり、前記参加依頼入力に基づいて、他のプレイヤに対して参加依頼処理を実行しないようにすることができる。
　前記ダメージは前記敵キャラクタの残りヒットポイント未満の値であり、前記参加依頼入力に基づいて、他のプレイヤに対して参加依頼処理を実行することができる。
　本発明の一実施態様における方法は、複数のプレイヤが共通の敵キャラクタと対戦するマルチバトルを含むゲームのための方法であって、コンピュータに、プレイヤからのマルチバトル開始入力を受け付ける段階と、受け付けたマルチバトル開始入力に基づいて、所定の敵キャラクタと対戦するマルチバトルを開始する段階と、他のプレイヤに対して前記開始されたマルチバトルへ参加を依頼するための前記プレイヤからの参加依頼入力を受け付ける段階と、参加依頼入力を受け付けると、前記敵キャラクタに対してダメージを与える処理を実行する段階と、を実行させる。
　本発明の一実施形態における電子装置は、複数のプレイヤが共通の敵キャラクタと対戦するマルチバトルを含むゲームのための電子装置であって、プレイヤからのマルチバトル開始入力を受け付け、受け付けたマルチバトル開始入力に基づいて、所定の敵キャラクタと対戦するマルチバトルを開始し、他のプレイヤに対して前記開始されたマルチバトルへ参加を依頼するための前記プレイヤからの参加依頼入力を受け付け、参加依頼入力を受け付けると、前記敵キャラクタに対してダメージを与える処理を実行する。
　本発明の一実施形態におけるシステムは、複数のプレイヤが共通の敵キャラクタと対戦するマルチバトルを含むゲームのためのシステムであって、前記システムは、サーバ及び前記サーバに接続される各プレイヤのプレイヤ端末を含み、前記サーバは、プレイヤ端末から送信されたプレイヤのマルチバトル開始入力を受け付け、受け付けたマルチバトル開始入力に基づいて、所定の敵キャラクタと対戦するマルチバトルを開始し、前記プレイヤ端末から送信された、他のプレイヤに対して前記開始されたマルチバトルへ参加を依頼するための前記プレイヤの参加依頼入力を受け付け、参加依頼入力を受け付けると、前記敵キャラクタに対してダメージを与える処理を実行し、前記敵キャラクタに対してダメージを与えることを表現する演出のための演出情報を前記プレイヤ端末に送信し、プレイヤ端末はプレイヤのマルチバトル開始入力及び参加依頼入力を受け付けてサーバに送信し、サーバからの演出情報に基づいて演出を表示する。
　本発明によれば、プレイヤのゲームプレイ意欲を高めることができる。
本発明の一実施形態に係るシステム構成図である。 本発明の一実施形態に係るシステムのハードウェア構成図である。 本発明の一実施形態に係るシステムの機能ブロック図である。 本発明の一実施形態に係る情報処理を示すフローチャートである。 本発明の一実施形態に係る情報処理を示すフローチャートである。 本発明の一実施形態に係る情報処理を示すフローチャートである。 本発明の一実施形態に係るゲーム用画面の一例である。 本発明の一実施形態に係るゲーム用画面の一例である。 本発明の一実施形態に係るゲーム用画面の一例である。 本発明の一実施形態に係るゲーム用画面の一例である。
　以下、図面を参照して、本発明の実施形態によるゲームシステム１について説明する。本明細書においては、説明の便宜上、必要以上に詳細な説明は省略する場合がある。例えば、既によく知られた事項の詳細説明や実質的に同一の構成についての重複説明を省略する場合がある。
　ゲームシステム１は、複数のプレイヤ端末がサーバにネットワークを介して接続されるシステムによって実現されるものとする。図１は本発明の一実施形態によるゲームシステム１の全体構成の一例を示す。図１に示すように、ゲームシステム１は、複数のプレイヤ端末１０と、サーバ２０とを備え、プレイヤ端末１０及びサーバ２０は、インターネットなどのネットワーク２に接続され、互いに通信可能である。なお、本実施形態のゲームシステム１は、サーバ－クライアントシステムを想定して説明する。
　本実施形態におけるゲームシステム１は、プレイヤのキャラクタが敵キャラクタと対戦するバトルを実行するものである。１人で敵キャラクタと対戦してもよいし、他のプレイヤの参加を依頼し、参加依頼に応じて参加した他のプレイヤと共同して共通の敵キャラクタと対戦を行ってもよい。このような複数のプレイヤが共同して共通の敵キャラクタと対戦可能なバトルをマルチバトルという。
　図２は本発明の一実施形態によるプレイヤ端末１０及びサーバ２０のハードウェア構成を示すブロック図である。プレイヤ端末１０は、プロセッサ１１、表示装置１２、入力装置１３、記憶装置１４及び通信装置１５を備える。これらの各構成装置はバス１６によって接続される。なお、バス１６と各構成装置との間には必要に応じてインタフェースが介在しているものとする。本実施形態において、プレイヤ端末１０はスマートフォンである。ただし、プレイヤ端末１０は、上記の構成を備えるものであれば、タブレット型コンピュータ、パソコンやゲーム装置などの電子装置とすることができる。
　サーバ２０もまた同様に、プロセッサ２１、表示装置２２、入力装置２３、記憶装置２４及び通信装置２５を備える。これらの各構成装置はバス２６によって接続される。なお、バス２６と各構成装置との間には必要に応じてインタフェースが介在しているものとする。本実施形態においてサーバ２０はコンピュータによって実現される。
　プロセッサ１１、２１は、プレイヤ端末１０ないしサーバ２０全体の動作を制御するものであり、例えばＣＰＵである。なお、プロセッサ１１、２１としては、ＭＰＵ等の電子回路が用いられてもよい。プロセッサ１１、２１は、記憶装置１４、２４に格納されているプログラムやデータを読み込んで実行することにより、様々な処理を実行する。１つの例では、プロセッサ１１、２１は、複数のプロセッサから構成される。
　表示装置（ディスプレイ）１２、２２は、プロセッサ１１、２１の制御に従って、アプリケーション画面などをプレイヤ端末１０のユーザ（プレイヤ）ないしサーバ２０のユーザ（管理者）に表示する。好ましくは液晶ディスプレイであるが、有機ＥＬを用いたディスプレイやプラズマディスプレイ等であってもよい。
　入力装置１３、２３は、プレイヤ端末１０及びサーバ２０に対するユーザからの入力を受け付けるユーザインタフェースであり、例えば、タッチパネル、タッチパッド、キーボード、又はマウスである。本実施形態においてプレイヤ端末１０はスマートフォンであるため、プレイヤ端末１０は入力装置１３としてタッチパネルを備え、タッチパネルは表示装置１２としても機能し、表示装置１２と入力装置１３は一体となった構造である。表示装置１２と入力装置１３は、別の位置に配置される別個の形態であってもよい。サーバ２０はコンピュータであるため、入力装置としてキーボード及びマウスを備え、表示装置として液晶ディスプレイを備えるものとする。
　記憶装置１４、２４は、揮発性メモリであるＲＡＭ及び不揮発性メモリであるｅＭＭＣ、ＵＦＳ、ＳＳＤのようなフラッシュメモリを用いた記憶装置及び磁気記憶装置等を含む、一般的なスマートフォン及びコンピュータが備える記憶装置である。記憶装置１４、２４は、外部メモリを含むこともできる。例えば記憶装置１４は、ブラウザプログラムやゲームプログラムを記憶し、記憶装置２４はサーバ用ゲームプログラムを記憶する。ブラウザプログラムやゲームプログラムは、プレイヤ端末１０に対するユーザの操作に応じて起動され、プレイヤ端末１０が予め実装するオペレーティングシステム（ＯＳ）上で実行される。サーバ用ゲームプログラムはクライアントである各プレイヤ端末において実行されるブラウザプログラムやゲームプログラム上でゲームを適切に進行させるように情報処理を行うための機能及び各種データを含む。
　１つの例では、記憶装置１４、２４は、主記憶装置及び補助記憶装置を含む。主記憶装置は、情報の高速な読み書きが可能な揮発性の記憶媒体であり、プロセッサ１１、２１が情報を処理する際の記憶領域及び作業領域として用いられる。補助記憶装置は、様々なプログラムや、各プログラムの実行に際してプロセッサ１１、２１が使用するデータを格納する。補助記憶装置は、例えばハードディスク装置であるが、情報を格納できるものであればいかなる不揮発性ストレージ又は不揮発性メモリであってもよく、着脱可能なものであっても構わない。補助記憶装置は、例えば、オペレーティングシステム（ＯＳ）、ミドルウェア、アプリケーションプログラム、これらのプログラムの実行に伴って参照され得る各種データなどを格納する。また、記憶装置として、プレイヤ端末１０及びサーバ２０から物理的に分離されたデータベースを用いることもできる。
　通信装置１５、２５は、ネットワーク２（図２においては省略）を介して他の装置との間でデータの授受を行う。例えば通信装置１５、２５は、移動体通信や無線ＬＡＮ等の無線通信を行い、ネットワーク２へ接続する。プレイヤ端末１０は通信装置１５を用いることで、ネットワークを介してサーバ２０と通信を行う。通信装置１５、２５は、イーサネット（登録商標）ケーブル等を用いた有線通信を行ってもよい。
　図３は本発明の一実施形態によるプレイヤ端末１０及びサーバ２０の機能ブロック図の一例を示す。プレイヤ端末１０は、入力部３１、表示部３２、通信部３３及びゲーム制御部３４及び記憶部３５を備え、サーバ２０は、入力部４１、表示部４２、通信部４３、ゲーム制御部４４及び記憶部４５を備える。本実施形態においては、プロセッサ１１及び２１がプログラムを実行することによりこれらの機能が実現される。例えば実行されるプログラムは、記憶装置１４、２４に記憶されているブラウザプログラムやゲームプログラムである。このように、各種機能がプログラム読み込みにより実現されるため、１つのパート（機能）の一部又は全部を他のパートが有していてもよい。各機能の一部又は全部を実現するための電子回路等を構成することによりハードウェアによってもこれらの機能は実現してもよい。
　入力部３１、４１は、入力装置１３、２３を用いて構成されるものであり、プレイヤ端末１０及びサーバ２０に対するユーザからの入力を受け付ける。プレイヤ端末１０及びサーバ２０は、入力部３１、４１によりユーザ入力を受け付ける。ユーザ入力は例えばゲームにおけるプレイヤの命令を示すコマンド入力を含んでもよい。本実施形態では、プレイヤ端末１０においてはタッチパネルを備えるスマートフォンが一般的に有しているタッチ検出機能を用いることができる。
　プレイヤ端末１０の表示部３２は、表示装置１２を用いてゲーム用画面を表示し、ゲームの進行やユーザ操作に応じたゲーム用画面を表示する。サーバ２０の表示部４２は、必要に応じてゲーム管理者のための管理用画面を表示装置２２に表示する。
　ゲーム制御部３４、４４は、本実施形態のゲームを実行するにあたっての制御処理及び処理に必要な各種データの記憶部３５、４５への格納を行う。本実施形態においては、プレイヤ端末１０のゲーム制御部３４はブラウザプログラムを用いて実現され、ユーザへの入出力情報の処理及びサーバ２０への送受信信号の処理等を行う。ゲームアプリケーションをプレイヤ端末１０にインストールして、実現されてもよい。
　サーバ２０のゲーム制御部４４は、サーバ用ゲームプログラムが実行されて実現され、プレイヤ端末１０において実行されるゲームのための処理を行う。１つの例では、ゲーム制御部４４は、プレイヤ端末１０においてブラウザが起動されて、ゲーム制御部３４が実現されて、ゲームを進行させるためにサーバ２０へアクセスされると、定期的に、又は必要に応じてデータの送受信を行い、ゲームを進行させる。例えばゲーム制御部４４は、本実施形態のゲームを実行するにあたっての制御処理及び必要な各種データ等を記憶部４５に記憶し、適宜プレイヤ端末１０に提供する。
　ゲーム制御部４４は、通信部４３を介して受信したコマンド入力に基づいてコマンドに関連付けられた処理を実行する。コマンド入力としては、他のプレイヤに対するバトルへの参加依頼入力（参加依頼コマンド入力）及び攻撃入力（攻撃コマンド入力）について説明するが、アビリティ使用コマンド等その他のコマンドが含まれ得ることは当業者には明らかである。
　記憶部３５、４５は、記憶装置１４、２４を用いて構成される。サーバ２０の記憶部４５においては、プレイヤのパラメータ、敵キャラクタのパラメータ及びバトルに関するバトルパラメータ等が記憶される。プレイヤのパラメータは、例えば、プレイヤＩＤ、名前、レベル、所持する武器、所持するキャラクタ、所持するアイテム、お気に入りのキャラクタ、所属するギルド、フレンドとなっているプレイヤのプレイヤＩＤ等の情報が含まれる。所持するキャラクタに関連するパラメータとしてキャラクタＩＤ、名前、レベル、攻撃力、防御力、ヒットポイント等を含むことができる。
　ギルドは、複数のプレイヤで構成されるグループであり、グループ内でチャットを楽しんだり、協力して敵を倒したり、イベントにおいてメンバーの獲得ポイント総数をギルド間で競い合ったりするものである。フレンドは、ギルドとは異なり特定のグループを形成するものではないが、プレイヤ間が所定の協力関係にあることを意味し、例えば、互いの合意によってフレンド関係が設定され、所持するアイテムの貸し借りを行うといった協力を行うことが可能となる。
　プレイヤのパラメータは、参加可能なマルチバトルについての情報を含んでもよい。例えば、１人のプレイヤによって開始されたバトルにおいて、そのプレイヤが他のプレイヤに対して参加依頼のコマンドを入力すると、後述する参加依頼処理を実行することによって、参加依頼を発行する他のプレイヤを決定し、その決定されたプレイヤ（被参加依頼プレイヤ）のパラメータの一部として、当該マルチバトルへ参加するための情報を記憶することができる。
　敵キャラクタのパラメータは、例えば、敵キャラクタのＩＤ、名前、レベル、攻撃力、防御力、ヒットポイント等が含まれる。バトルパラメータは、バトルに参加しているプレイヤのパラメータ及び敵キャラクタのパラメータが含まれる。本実施形態においては、プレイヤは所持する複数のキャラクタのうち４体のキャラクタを選択してバトルを開始する。バトルパラメータにおけるプレイヤパラメータとして、この選択されたプレイヤキャラクタの情報を含むものとする。また、各パラメータはバトルの進行に伴って変化しうる。例えば、ヒットポイントは相手の攻撃によって減少するし、攻撃力や防御力は特殊なアビリティによって上昇したり減少させたりすることもできる。また、複数のプレイヤがバトルに参加している場合には、これらの参加プレイヤのパラメータが関連付けて記憶される。
　後述するとおり、プレイヤからの攻撃入力（攻撃入力コマンド）をサーバ２０が受け付けると、プレイヤキャラクタの攻撃能力値等に基づいて決定される第１のダメージを敵キャラクタへ与える処理を実行する（Ｓ５５４）。さらに、本実施形態においては、プレイヤからの参加依頼入力（参加依頼入力コマンド）及び攻撃入力（攻撃入力コマンド）をサーバ２０が受け付けると、第１のダメージとは別の第２のダメージを敵キャラクタに与える処理を実行するものとする（Ｓ５１８及びＳ５４８）。ここでは、第２のダメージは、所定の確率に基づいて、プレイヤキャラクタの能力値に依存せずにダメージの大きさが決定されるものである。本実施形態においては、第１のダメージは能力値依存型ダメージとし、第２のダメージは非能力値依存型ダメージとするが、第２のダメージも能力値依存型としてもよい。
　非能力値依存型ダメージのための所定の確率は、敵キャラクタのレベルに基づいて予め決定し、与ダメージ確率表としてサーバ２０の記憶部４５に記憶される。ここでは、与ダメージ確率表は参加依頼入力に対する与ダメージ確率表と攻撃入力に対する与ダメージ確率表がそれぞれ用意される。非能力値依存型ダメージは、プレイヤキャラクタの攻撃力によらず、例えば、一撃で敵キャラクタの全ヒットポイント以上のダメージを与える一撃必殺ダメージとしたり、敵キャラクタの残りのヒットポイント未満であるものの、敵キャラクタの全ＨＰの８０％や１００万ダメージのような大ダメージとすることができる。非能力値依存型ダメージは、通常の能力値依存型与ダメージと異なり、敵キャラクタの防御力に基づかずに決定してもよい。与ダメージ確率表の一例を表１及び表２に示す。
Figure JPOXMLDOC01-appb-T000001
Figure JPOXMLDOC01-appb-T000002
　表１は参加依頼入力に対する与ダメージ確率表を示す。参加依頼入力を受け付けた場合に、敵キャラクタに対して非能力値依存型ダメージを与える確率を敵キャラクタレベルに応じて予め定める。例えば、敵キャラクタレベルが４０の場合には、参加依頼入力を受け付けた場合に、２０．０％の確率で敵キャラクタに対してダメージを与える。
　表２は攻撃入力に対する与ダメージ確率表を示す。攻撃入力を受け付けた場合に、敵キャラクタに対して非能力値依存型ダメージを与える確率を敵キャラクタレベル及び経過ターンに応じて予め定める。例えば、敵キャラクタレベルが４０の場合に、経過ターン０～４の間に攻撃入力がなされた場合、１．０％の確率で敵キャラクタに対してダメージを与える。攻撃入力に対して所定の確率で非能力値依存型ダメージが与えられた後、敵キャラクタが生存している場合には、通常の攻撃入力に基づく能力値依存型ダメージを与えることができる。
　本実施形態においては、プレイヤキャラクタと敵キャラクタとが交互に攻撃を行うターン制のバトルを想定し、経過ターンに応じて、与ダメージ確率を決定するものとしたが、ターン制によらない、例えば、リアルタイムに双方が攻撃を行うゲームにおいては、経過ターンによらない与ダメージ確率を決定することができる。経過時間に応じて与ダメージ確率を決定してもよい。
　次に、本発明の一実施形態によるゲームシステム１において実行される情報処理について図４に示したフローチャートを用いて説明する。本実施形態におけるゲームシステムは、複数のプレイヤが共通の敵キャラクタと対戦できるゲームのためのシステムである。敵キャラクタとの対戦は、１人のプレイヤによるマルチバトル開始入力に基づいて開始されるものとするが、複数人で協力して開始するようにしてもよい。当該プレイヤが単独で敵キャラクタを倒してもかまわない。当該プレイヤは他のプレイヤに対して参加依頼を行い、参加依頼に応答して、マルチバトルに参加した他のプレイヤと協働して共通する敵キャラクタを倒してもよい。
　各プレイヤのプレイヤ端末１０がサーバ２０に接続されており、バトルに参加しているプレイヤは共通の敵に対して攻撃を行い、共通の敵キャラクタのＨＰがゼロとなるとプレイヤ側の勝利とし、すべての参加プレイヤのプレイヤキャラクタのＨＰがゼロとなれば敵キャラクタ側の勝利となる。
　図４に示したフローチャートは、サーバ２０と１つのプレイヤ端末１０との間で実行される情報処理を示しており、同様の処理がバトルに参加するすべてのプレイヤのプレイヤ端末１０に対して並行して別々に実行されうる。並列に実行される処理は例えばそれぞれプレイヤＩＤに対応付けて実行することができる。ただし、バトル開始要求（Ｓ４０１）及びバトル開始処理（Ｓ４０２）はバトルを開始するプレイヤ端末１０に対する処理であり、参加依頼を受けてバトルに参加するプレイヤ端末１０に対しては参加要求（Ｓ４０１）及び参加開始処理（Ｓ４０２）が代わりに実行される。図４のフローチャートとの関係においてプレイヤという場合には、そのフローチャートの情報処理を実行しているプレイヤ端末１０のプレイヤを意味し、プレイヤキャラクタはそのプレイヤのプレイヤＩＤに関連付けられ、バトルのために選択されたプレイヤキャラクタである。
　まず、いずれかのプレイヤがプレイヤ端末１０を介して操作入力を行い、バトル開始要求をサーバ２０へ送信する（Ｓ４０１）。サーバ２０はバトル開始要求を受信すると、バトル開始要求に含まれるプレイヤＩＤ（ＰＩＤ）に基づいてバトルパラメータを生成して記憶部４５に記憶し、バトルを開始する（Ｓ４０２）。
　次に、サーバ２０は、ＰＩＤに対応するバトル画面情報を生成して、当該ＰＩＤに対応付けられたプレイヤ端末１０へ送信する（Ｓ４０４）。ここでは、敵キャラクタと当該ＰＩＤに対応付けられるプレイヤキャラクタの画像を含む画面情報を生成するものとする。　
　プレイヤ端末１０は、バトル画面情報を受信すると表示部３２に、コマンド入力用ボタンを含むバトル画面を表示する（Ｓ４０６）。そして、プレイヤ端末１０はプレイヤからのコマンド入力を待ち受け（Ｓ４０８）、入力部３１がプレイヤからのコマンド入力を受け付けると通信部３３を介してサーバ２０へコマンド入力を送信する（Ｓ４１０）。
　バトル画面の一例を図７に示す。バトル画面は、敵キャラクタ画像７０１、敵キャラクタの残りＨＰ（％）７０２、プレイヤキャラクタ画像７１１～７１４、攻撃ボタン７２１、プレイヤキャラクタ指定ボタン７３１～７３４、参加依頼ボタン７４１を含む。
　プレイヤ端末１０の入力部３１は、プレイヤによる攻撃ボタン７２１または参加依頼ボタン５４１へのタッチを検出すると、攻撃コマンドまたは参加依頼コマンドの実行を指示するコマンド入力（攻撃入力又は参加依頼入力）を受け付け、通信部３３を介してサーバ２０へ送信される（Ｓ４１０）。また、プレイヤキャラクタ画像７３１～７３４にタッチすると、各キャラクタに特有のアビリティを実行するためのアビリティボタンがさらに表示され、プレイヤによるアビリティボタンへのタッチにより、アビリティ実行を指示するコマンド入力として受け付け、サーバ２０へ送信されるようにすることもできる。
　サーバ２０は、プレイヤ端末１０からのコマンド入力（攻撃入力又は参加依頼入力）を待ち受け（Ｓ４１２）、コマンド入力を受け付けると、当該コマンド入力によって指定されたコマンドを実行し（Ｓ４１４）、コマンドの実行によって生成された演出画面情報（演出情報）をプレイヤ端末１０へ送信する（Ｓ４１６）。プレイヤ端末１０は演出画面情報を受信すると、これに基づいて演出画面を表示部３２に表示する（Ｓ４１８）。演出は画面表示演出に限定せず、音声だけの演出であってもかまわないし、画面と音声を含む演出を行ってもよい。
　サーバ２０は、コマンド実行（Ｓ４１４）によってバトルが終了したか否かを判定する（Ｓ４２０）。コマンド実行によって敵キャラクタの残りＨＰがゼロとなったか否か、及び、プレイヤキャラクタの残りＨＰがゼロとなったか否かを判定し、いずれかの条件を満たす場合には、バトルが終了したものとする。バトルが終了していない場合には、コマンド入力の待ち受け（Ｓ４１２）に戻り、サーバ２０は、バトル終了の判定がなされるまで、上記の処理を繰り返し実行する。
　バトルが終了したと判定された場合、バトルの結果及び演出画面情報を含むバトル終了通知がサーバ２０からプレイヤ端末１０へ送信される（Ｓ４２２）。プレイヤ端末１０はバトル終了通知を待ち受け（Ｓ４２４）、バトル終了通知を受信すると、バトルの結果及び演出画面情報に基づいて、演出画面を表示部３２に表示するとともにバトル結果をプレイヤに表示し（Ｓ４２６）、バトルを終了させる（Ｓ４３０）。プレイヤ端末１０は、バトル終了通知を受け付けない場合には、コマンド入力の待ち受けに戻り（Ｓ４０８）、バトル終了通知を受け付けるまで、上記の処理を繰り返し実行する。
　次に、図５に示したフローチャートに基づいて、コマンド実行（Ｓ４１４）の処理をより詳細に説明する。サーバ２０は、プレイヤ端末１０よりコマンド入力を受け付けると、当該コマンド入力の種別を判定する（Ｓ５０１）。本実施形態においては、攻撃ボタン７２１がタッチされたことによる攻撃コマンド入力及び参加依頼ボタン７４１がタッチされたことによる参加依頼コマンド入力の２種類があるものとするが、これらのうちの一方だけであってもかまわないし、その他のコマンド入力があってもかまわない。
　コマンド入力が参加依頼コマンド入力であった場合、サーバ２０は、参加依頼を行う対象をプレイヤが指定するための演出画面を表示するための情報を生成して、プレイヤ端末１０へ送信する（Ｓ５０２）。プレイヤ端末１０は演出画面情報を受信すると、これに基づいて参加依頼対象指定用の演出画面を表示し（Ｓ５０４）、プレイヤからの参加依頼対象入力を受け付けると、これをサーバ２０へ送信する。
　参加依頼を行う対象を指定するための演出画面の一例を図８に示す。本実施形態においては、参加依頼を行う対象のプレイヤとして、すべてのプレイヤへ参加依頼を送信するための「みんな」ボタン８０１、プレイヤのフレンドに対して送信するための「フレンド」ボタン８０２及びギルドのメンバーに対して送信する「ギルド」ボタン８０３が表示される。「みんな」ボタン８０１がプレイヤによってタッチされた場合には、すべてのプレイヤからランダムに選択された所定数のプレイヤに対して参加依頼がなされる。ボタン８０１～８０３の一つ以上をタッチして、参加依頼ボタン８１０をタッチすると、参加依頼対象入力がサーバ２０へ送信される。また、参加依頼は、バトルを識別する識別子を生成し、当該識別子をソーシャルネットワーキングサービス等を介して公開することにより行うこともできる。これを見た他のプレイヤが所定の画面において識別子を入力することで、当該バトルへの参加を行うことができる。
　本実施形態においては、「みんな」への参加依頼入力が行われた場合に、非能力値依存型の与ダメージ処理が実行されうるものとする。演出画面においては、「みんな」ボタン８０１がタッチされてオンになっている場合に、図８に示すように「特別救援」として非能力値依存型ダメージが与えられる可能性があることを示す表示を行うものとする（８２０）。他の実施形態においては、「みんな」への参加依頼以外のいずれかの参加依頼入力がなされた場合に、非能力値依存型の与ダメージ処理が実行されるようにしてもよいし、「みんな」、「フレンド」及び「ギルド」のいずれか１つ以上への参加依頼入力がなされた場合に非能力値依存型与ダメージ処理が実行されるようにしてもよい。また、「みんな」、「フレンド」及び「ギルド」のうちのいずれか１つないし２つのみへの参加依頼しか選択できないような構成としてもよいし、他の何らかのプレイヤのグループへの参加依頼を選択できるようにしてもかまわない。
　サーバ２０は、参加依頼対象入力を受け付けると、参加依頼入力を行ったプレイヤがバトルを開始したプレイヤ、いわゆる自発者であるか否かを判定する（Ｓ５０８）。本実施形態においては、自発者の参加依頼入力に対してのみ、敵キャラクタへの非能力値依存型与ダメージ処理を実行するものとする。プレイヤが所定のアイテムを消費して敵キャラクタとのバトルを開始するようなゲームにおいては、他のプレイヤが開始したバトルに参加した方がアイテム消費をせずに参加できるから有利となる場合がある。そのような場合には、バトルを開始するプレイヤが減少し、プレイヤがバトルを楽しむ機会が減少してしまう。自発した場合に、参加依頼入力を行うと敵キャラクタへ一撃必殺等のダメージを与えることができれば、バトルを自発する意欲が高まる。また、他のプレイヤが参加できるバトル数が増加し、ゲーム全体が活性化される。他の実施形態として、参加依頼入力に基づく、敵キャラクタへの与ダメージ処理の実行を自発者に限定しないようにしてもよい。
　プレイヤが自発者ではないと判定された場合（Ｓ５０８）、被参加依頼プレイヤ決定処理（Ｓ５２６）に移行し、プレイヤが自発者であると判定された場合、参加依頼対象として非能力値依存型の与ダメージ処理実行の対象となる参加依頼対象、ここでは、「みんな」が指定されているか否かを判定する（Ｓ５１０）。「みんな」が含まれていない場合には、被参加依頼プレイヤ決定処理（Ｓ５２６）に移行し、「みんな」が含まれている場合には、敵キャラクタに対して非能力値依存型ダメージを与えるか否かの決定を行う（Ｓ５１２）。本実施形態においては、サーバ２０は記憶部４５に記憶された与ダメージ確率表に基づいてダメージを与えるか否かを抽選処理によって決定するが、必ずダメージを与えるようにしてもよいし、所定のパターンに従ってダメージを与えるかを決定してもよい。また、所定回数は抽選処理を実行し、所定回数内に一度も与ダメージの決定がなされない場合には、ダメージを与える決定をするようにしてもよい。
　ここでは、表１に示した参加依頼入力に対する与ダメージ確率表を用いて敵キャラクタに対してダメージを与えるか否かを決定する。記憶部４５に記憶されたバトルパラメータから敵キャラクタレベルを読み出し、読み出された敵キャラクタレベルに基づいて与ダメージ確率を決定し、決定された与ダメージ確率に基づいてダメージを与えるか否かの抽選処理を乱数を用いて行うものとする。所定の確率で与ダメージの決定ができる処理であればどのような処理であってもかまわない。
　ダメージを与えないことが決定されたと判定された場合（Ｓ５１４）には、被参加依頼プレイヤ決定処理（Ｓ５２６）に移行し、ダメージを与えることが決定されたと判定された場合、非能力値依存型与ダメージキャラクタの決定処理が実行される（Ｓ５１６）。与ダメージキャラクタとは、プレイヤ端末１０の表示部３２において表示される敵キャラクタに対してダメージを与える演出で、ダメージを与える主体となる演出用キャラクタである。ここでは一体のキャラクタとするが複数のキャラクタであってもかまわない。
　本実施形態における与ダメージキャラクタを決定するための処理を図６に示した。与ダメージキャラクタは参加依頼入力を行ったプレイヤが参加しているギルドの他のプレイヤがお気に入りのキャラクタとして登録しているキャラクタからランダムに選択するか、所定のキャラクタの中からランダムに選択するものとする。与ダメージキャラクタは、参加依頼を送る対象のプレイヤのキャラクタから選択される必要はない。
　まず、参加依頼入力を行ったプレイヤのプレイヤパラメータに含まれるギルドＩＤに基づいて、ギルドに所属しているか否かを判定する（Ｓ６０１）。ギルドに所属していると判定された場合には、当該ギルドＩＤに基づいてギルドに参加する他のプレイヤのプレイヤ数を特定する。そして、ギルドに参加しているプレイヤ数が所定人数、ここでは５人以上であるか否かを判定し（Ｓ６０２）、５人以上であると判定された場合には、抽選処理にてギルド内の他のプレイヤを決定し、その決定された他のプレイヤのお気に入りキャラクタを与ダメージキャラクタとして決定する。
　なお、各プレイヤがお気に入りのキャラクタを設定しないことを許容するようにしてもよい。この場合、ギルド内でお気に入りキャラクタを設定しているプレイヤの中から抽選処理にて他のプレイヤを決定してもよいし、ギルド内のすべてのプレイヤから抽選処理で他のプレイヤを決定した後、決定されたプレイヤがお気に入りキャラクタを設定していない場合には、所定のキャラクタから抽選処理にて与ダメージキャラクタを決定してもよい。また、ギルド内のすべての他のプレイヤがお気に入りのキャラクタを設定していない場合もありえる。そのような場合には、所定のキャラクタからランダムに選択されたキャラクタを与ダメージキャラクタとして決定してもよい。ギルドに参加しているプレイヤ数の判定（Ｓ６０２）を、お気に入りキャラクタを設定しているプレイヤ数としてもよい。
　一方、プレイヤがギルドに所属していないと判定された場合（Ｓ６０１）またはギルドに所属しているもののメンバーが５人未満であると判定された場合（Ｓ６０２）、所定の複数のキャラクタの中から抽選によってキャラクタを選択するものとする（Ｓ６０６）。ギルドの参加メンバーが少ない場合には、抽選処理によっても選択されるメンバーが限定されるから、同じメンバーのお気に入りキャラクタが複数回にわたって選択される可能性が高くなり、興趣性が低下する。そのため、ギルドメンバーが所定数未満である場合には、所定の複数のキャラクタから選択するものとする。
　好ましくは、所定の複数のキャラクタから選択されるキャラクタは、プレイヤが所持しているか否かにかかわらず、選択されることを可能とする。プレイヤが所持していないキャラクタから選択されたキャラクタの演出が表示させることで、プレイヤが通常見ることができない演出を見せることが可能となる。なお、キャラクタ自体は同一であっても、レア度、属性、その他のパラメータが異なる他のバージョンが設けられる場合がある。ここでは、同一のキャラクタであっても、異なるバージョンであれば異なるキャラクタとして扱う。
　与ダメージキャラクタが決定された後、敵キャラクタへの非能力値依存型与ダメージ処理が実行される（Ｓ５１８）。非能力値依存型与ダメージ処理は、敵キャラクタへ与えられるダメージの大きさを決定し、決定されたダメージに基づいて敵キャラクタの残りＨＰを計算する処理を含む。本実施形態においては、敵キャラクタへ与えるダメージは一撃必殺ダメージとし、敵キャラクタの残りＨＰを与えるダメージの大きさとし、敵キャラクタパラメータにおける残りＨＰをゼロに設定する。敵キャラクタが複数いる場合には、すべての敵キャラクタを一撃必殺で倒すものとするが、一部の敵キャラクタのみを倒すようにしてもよい。敵キャラクタの残りＨＰ以上のダメージをランダムに与えてもよい。与えたダメージの大きさに応じて獲得ポイント数が計算されるような場合に、より多くのポイントを獲得するチャンスをプレイヤに与えることができる。
　敵キャラクタに対して与えたダメージの大きさに応じて、一回のバトルにおいて与えられるポイントが算出され、このポイント数に応じて、参加プレイヤの順位が決定されたり、順位に従って報酬が与えられるような場合には、この順位を定めるためのポイント算出においては非能力値依存型与ダメージを含めずに計算してもよい。
　次に、決定された与ダメージキャラクタに基づいて演出画面情報を生成して、プレイヤ端末１０へ送信し（Ｓ５２０）、プレイヤ端末１０はこれに基づいて演出画面を表示部３２に表示する（Ｓ５２２）。
　演出画面の一例を図９に示す。図９においては、「プレイヤＦがオススメする強力な仲間が救援に来てくれた！」との表示（９０１）をするとともに、プレイヤＦのお気に入りキャラクタが敵キャラクタに対して必殺技Ａを用いて攻撃を行う演出が表示される（９０２）。好ましくは、この演出の間は参加依頼を行ったプレイヤ自身のキャラクタは表示されない。
　このように、参加依頼入力を行ったプレイヤのキャラクタではなく、ギルドの他のプレイヤのおすすめキャラクタから選択されたキャラクタが敵キャラクタを倒す演出を表示すれば、自分が所持していないキャラクタの演出を見ることが可能となり、興趣性を高めることができる。好ましくは、演出表示においては、救援に来たキャラクタを所持するギルドメンバー等のプレイヤ名を表示する。ギルドの他のプレイヤのキャラクタが救援に来てくれたという擬似体験によって他のプレイヤとの一体感を高めることができる。また、自分のお気に入りのキャラクタを他のプレイヤのバトルに登場させることで、お気に入りのキャラクタを紹介する楽しさを感じさせることもできる。
　本実施形態のようにプレイヤ端末１０のブラウザを用いて実行するゲームにおいては、このような構成を容易に実現することができる。すなわち、プレイヤが所持しないキャラクタであってもサーバ２０においては、そのキャラクタの演出画像情報を生成するための情報を記憶部４５に記憶しているから、これに基づいて演出画像情報を生成して、プレイヤ端末１０へ送信することができる。プレイヤ端末１０においては受信された演出画像情報に基づいて演出画像を表示するだけでよい。
　所定の複数のキャラクタの中から抽選によってキャラクタを選択された場合には（Ｓ６０６）、「『プレイヤ名』のもとに『キャラクタ名』が駆けつけた！」といった表示とともに、選択されたキャラクタが必殺技を用いて攻撃を行う演出を行うことができる。
　そして、与ダメージ処理（Ｓ５１８）によって与えられた敵キャラクタへのダメージによって、敵キャラクタの残りＨＰがゼロになっていないか否かを判定する（Ｓ５２４）。残りＨＰがゼロである場合は、敵キャラクタを倒したとのゲーム結果に基づいて、演出画面情報を生成する（Ｓ５６０）。
　残りＨＰがゼロより大きいと判定された場合、プレイヤによって選択された参加依頼対象入力に基づいて、参加依頼を受けるプレイヤである被参加依頼プレイヤを決定する（Ｓ５２６）。本実施形態においては、非能力値依存型の与ダメージは一撃必殺ダメージであるから、ダメージを与えることが決定された場合には、敵キャラクタの残りＨＰはゼロとなる。この場合には、被参加依頼プレイヤの決定及び被参加依頼プレイヤ登録を含む他のプレイヤに対する参加依頼処理を実行しない。
　参加依頼対象入力が「みんな」である場合には、全プレイヤの中からランダムに１以上のプレイヤを決定し、「フレンド」の場合には、参加依頼入力を行ったプレイヤのフレンドの中からランダムに１以上のプレイヤを決定し、「ギルド」の場合にはすべてのギルドメンバーを被参加依頼プレイヤとして決定する（Ｓ５２６）。決定された被参加依頼プレイヤの、記憶部４５に記憶されたプレイヤパラメータに当該バトルに参加可能とする被参加依頼情報を追加することで、被参加依頼プレイヤ登録を実行する（Ｓ５２８）。
　本実施形態においては、参加依頼を行ったプレイヤに対して、参加依頼報酬を提供するものとする。参加依頼報酬として、プレイヤキャラクタのＨＰを回復するためのアイテムであるポーションを当該プレイヤのプレイヤパラメータに登録する（Ｓ５３０）。参加依頼報酬を提供することにより、参加依頼を出すことを促し、他のプレイヤのゲームへの参加機会を増加させることができる。
　２以上のグループに対して参加依頼を発行した場合、非能力値依存型の与ダメージのための処理、例えば、Ｓ５１２～Ｓ５１６は一回のみ実行されるものとしてもよいし、参加依頼を行ったグループ数に基づいて実行される与ダメージ処理の実行数を決定してもよい。例えば、２つのグループに対して参加依頼を発行した場合であっても、Ｓ５１２～Ｓ５１６は一回のみ実行するようにしてもよいし、Ｓ５１２～Ｓ５１８を２回繰り返し実行してもよいし、Ｓ５１２～Ｓ５１６は一回のみ実行し、Ｓ５１８及びＳ５２０のダメージを与えて演出を表示する処理のみを２回実行するようにしてもよい。
　参加依頼入力後、所定期間経過後、参加依頼入力を繰り返し行うことができるようにし、参加依頼の再入力が行われる度に、非能力値依存型の与ダメージのための処理を実行するようにしてもよい。例えば、「みんな」へ参加依頼入力を行った場合には、全プレイヤからランダムに選択された一部のプレイヤのみに対して参加依頼処理が実行される。繰り返し参加依頼入力を行うことで、参加依頼を出すプレイヤを増やすことが可能となる。
　ここでは、「ギルド」に対しては一度の参加依頼によってすべてのギルド内のプレイヤに参加依頼が発行されるものとし、このようなグループに対しては、参加依頼入力を一回しか行えないようにすることもできる。「ギルド」に対してのみ参加依頼を実行可能とし、参加依頼入力は一度のみ可能とする態様においては、一度、参加依頼入力を行って、非能力値型与ダメージのための処理の実行を行った後、所定期間の経過後、参加依頼ボタンの表示に変えて、例えば、特別参加依頼ボタンを表示し、当該特別参加依頼ボタンへのタッチ入力があると与ダメージのための処理の実行を行うようにしてもよい。再度の参加依頼入力ができない態様においても、所定の時間間隔毎に、与ダメージのための処理の実行を可能とする。
　被参加依頼登録がなされた他のプレイヤは、例えば、サーバ２０にアクセスすると、ゲーム制御部４４は当該プレイヤのためのプレイヤパラメータを記憶部４５より読み出し、被参加依頼情報が含まれると判定した場合には、バトルへの参加を促すボタンをプレイヤ端末１０において表示させる。当該ボタンがタッチされると、バトルへの参加要求入力がなされ、バトルへの参加処理が実行され、バトル画面情報が送信される。これを受信したプレイヤ端末１０においてバトル画面表示がなされる。図４の示したフローチャートにおいて、前述したバトル開始要求の代わりに参加要求入力がプレイヤ端末１０から送信され（Ｓ４０１）、サーバ２０がバトル開始処理の代わりに参加開始処理を実行する（Ｓ４０２）。その後の処理は、図４に関連して前述した処理と同様とすることで、バトル参加者のバトル処理を実行することができる。
　Ｓ５２６～Ｓ５３０の結果に基づいて、演出画面情報を生成する（Ｓ５６０）。例えば、参加依頼を行ったことを示す情報を表示したり、参加報酬としてポーションを取得したことを示す情報を表示するような演習画面情報を生成する。
　コマンド種別判定（Ｓ５０１）において、コマンド入力が攻撃コマンド入力であった場合、敵キャラクタへの通常の能力値依存型の与ダメージ処理（Ｓ５５４）の前に、非能力値依存型のダメージを与える与ダメージ処理Ｓ５４０～Ｓ５５２及びＳ５２２が実行される。
　攻撃入力に基づく非能力値依存型与ダメージ決定に用いられる与ダメージ確率表は、表２に示す攻撃入力与ダメージ確率表を用いることとする。与ダメージ確率はターン経過が進むほど、高まっていくように設定されている。例えば、与ダメージが一撃必殺の場合には、全滅を避けながら戦い続ければ一撃必殺が発生して、通常倒せない敵であっても倒せる可能性が高まっていく。戦力が不十分なプレイヤであっても戦略を立てて強敵と対戦を行う楽しさを感じさせることができるから、バトルを自発する意欲が高まり、発生されるバトル数を増加させることができる。また、十分な戦力を有するプレイヤであっても、敵を倒すまでに一定の時間を要するようなバトルをより短い時間で終了させることが可能となり、より多くのバトルを自発する意欲を高めることができる。
　その他の点においては、参加依頼対象入力に「みんな」が含まれるか否かの判定処理（Ｓ５１０）を除き、参加依頼コマンドに関連して実行されるＳ５０８～Ｓ５２４と同様であるから、詳細な説明は省略する。
　非能力値依存型与ダメージ処理によって、敵キャラクタを倒せなかった場合（Ｓ５５２）、通常の能力値依存型の与ダメージ処理を実行する（Ｓ５５４）。敵キャラクタへ与える能力値依存型のダメージ（第１のダメージ）は、プレイヤキャラクタの攻撃力及び敵キャラクタの防御力等に基づいて決定される。敵キャラクタへのダメージが決定されると、敵キャラクタの残りＨＰを算出する。そして、敵キャラクタの残りＨＰがゼロよりも大きいか否かを判定し（Ｓ５５６）、ゼロであれば、演出画面情報生成処理（Ｓ５６０）に移行し、ゼロよりも大きければ、敵キャラクタの攻撃による、プレイヤキャラクタの被ダメージ処理を実行する（Ｓ５５８）。プレイヤキャラクタの被ダメージは、敵キャラクタの攻撃力及びプレイヤキャラクタの防御力等に基づいて決定される。敵キャラクタのＨＰがゼロであると判定された場合には、被ダメージ処理はスキップされる。
　能力値依存型の与ダメージ処理（Ｓ５５４）及び被ダメージ処理（Ｓ５５５８）の結果に基づいて、演出画面情報を生成する（Ｓ５４０）。例えば、プレイヤキャラクタや敵キャラクタの攻撃を演出する画面を表示するための情報を生成する。生成された演出画像情報は図４のＳ４１６においてプレイヤ端末１０へ送信され、プレイヤ端末１０の表示部３２において表示される。例えば、与ダメージ処理（Ｓ５１６）において敵ＨＰがゼロとなった場合には、図１０に示すように、敵キャラクタが倒された場合の演出画像を表示させる。与ダメージ処理が実行されて図９に示すような演出画像が表示されている間は非表示となっていた自己のキャラクタを再度表示してもよい。
　参加依頼を出すことへの報酬としてプレイヤのステータスの強化することで、積極的に参加依頼を出すことへの動機付けを行うことは可能である。ステータスの強化によってバトルを有利に進めることが可能となり、またバトルに参加するプレイヤの人数が増える可能性があるため、バトルに勝利できる可能性を高めることができるからである。
　一方、プレイヤの戦力が低い場合にはステータス強化程度ではバトルに勝利できないおそれがあり、また参加依頼を出したとしても他のプレイヤがバトルに参加するのか、また参加したとしても即座に参加するものかは約束されていない。このため、バトルになかなか勝利することができず、バトルを自発することへの意欲が低下し、ひいてはゲーム内におけるバトル数及び参加依頼数が減少することでゲーム全体におけるマルチバトルへの参加機会やプレイヤのゲームプレイ時間を低下させるおそれがある。
　本実施形態を用いることにより、プレイヤは非能力値依存型与ダメージのような第２のダメージによって、敵キャラクタを倒せる可能性を高めることができる。特に、第２のダメージを一撃必殺、すなわち、敵キャラクタの残りＨＰ以上の与ダメージ量とすることにより、戦力が不十分なプレイヤであっても、強力な敵キャラクタとのバトルを開始することへの意欲を高めることができる。プレイヤの戦力が十分な場合であっても、敵キャラクタを倒すための所要時間を短縮することができ、よりたくさんのバトルを開始することができるようになる。
　敵キャラクタを倒すと一定の確率で得られる武器やアイテムを複数集めることで、プレイヤの戦力を強化できるようなゲームがある。このようなゲームにおいては、武器等を収集するために同じ敵キャラクタとのバトルを何度も繰り返し実行することが予定されている。敵キャラクタを倒すための所要時間を短縮させることは、一定時間でより多くのアイテム等を取得できるようになるから、プレイヤにとって大きなメリットがある。
　プレイヤの戦力が十分でない場合には、そもそも敵キャラクタを倒せず、アイテム等を取得できない。戦力が十分な他のプレイヤの参加によって敵キャラクタを倒すことができたとしても、敵キャラクタへ与えたダメージ量の順番に報酬が決まるような場合には、戦力が十分な他のプレイヤに報酬が与えられ、戦力が不十分なプレイヤは戦力強化に役立つアイテム等を十分に獲得することができない。このため、戦力が高いプレイヤとの戦力差がますます増大する。本実施形態を用いれば、戦力の低いプレイヤであっても、一定の確率で敵キャラクタを倒し、アイテムを取得できる可能性を与えることができる。これによって、ゲームを開始したばかりの初心者であっても、積極的にバトルを自発して、継続的にプレイする意欲を高めることができる。
　本実施形態を用いることにより、プレイヤがゲームをプレイする意欲が高まり、ゲームシステム全体でのバトル数が増加するとともに、参加依頼が増加し、自発しない場合であってもプレイできるバトル数も増加し、ゲーム全体を活性化することが可能となる。
　以上に説明した処理又は動作において、あるステップにおいて、そのステップではまだ利用することができないはずのデータを利用しているなどの処理又は動作上の矛盾が生じない限りにおいて、処理又は動作を自由に変更することができる。また以上に説明してきた各実施例は、本発明を説明するための例示であり、本発明はこれらの実施例に限定されるものではない。本発明は、その要旨を逸脱しない限り、種々の形態で実施することができる。
１　　　　：ゲームシステム
２　　　　：ネットワーク
１０　　　：プレイヤ端末
１１　　　：プロセッサ
１２　　　：表示装置
１３　　　：入力装置
１４　　　：記憶装置
１５　　　：通信装置
１６　　　：バス
２０　　　：サーバ
２１　　　：プロセッサ
２２　　　：表示装置
２３　　　：入力装置
２４　　　：記憶装置
２５　　　：通信装置
２６　　　：バス
３１　　　：入力部
３２　　　：表示部
３３　　　：通信部
３４　　　：ゲーム制御部
３５　　　：記憶部
４１　　　：入力部
４２　　　：表示部
４３　　　：通信部
４４　　　：ゲーム制御部
４５　　　：記憶部
５４１　　：参加依頼ボタン
７２１　　：攻撃ボタン
７４１　　：参加依頼ボタン
８１０　　：参加依頼ボタン

Claims (10)

  1. 　複数のプレイヤが共通の敵キャラクタと対戦するマルチバトルを含むゲームのためのプログラムであって、コンピュータに、
    　プレイヤからのマルチバトル開始入力を受け付ける段階と、
    　受け付けたマルチバトル開始入力に基づいて、所定の敵キャラクタと対戦するマルチバトルを開始する段階と、
    　他のプレイヤに対して前記開始されたマルチバトルへ参加を依頼するための前記プレイヤからの参加依頼入力を受け付ける段階と、
    　参加依頼入力を受け付けると、前記敵キャラクタに対してダメージを与える処理を実行する段階と、
    　を実行させることを特徴とするプログラム。
  2. 　前記ゲームにおいては、プレイヤは１以上のキャラクタを所持し、所持するキャラクタを用いて敵キャラクタと対戦し、
     前記ダメージを与える処理を実行する段階は、前記プレイヤが所持するか否かによらず、所定のキャラクタの中から選択された演出用キャラクタによって敵キャラクタに対してダメージを与えることを表現する演出を表示させる段階を含む、
    　請求項１に記載のプログラム。
  3. 　前記ダメージを与える処理を実行する段階は、他のプレイヤによって予め選択されたキャラクタから演出用キャラクタを選択する段階を含む、請求項１または２に記載のプログラム。
  4. 　前記敵キャラクタに対してダメージを与える処理を実行する段階は、
    　前記敵キャラクタに対してダメージを与えるか否かを決定するための抽選処理を実行する段階と、
    　抽選処理の結果、前記敵キャラクタに対してダメージを与えることが決定した場合に、前記敵キャラクタに対してダメージを与える段階と、
    　を含む、
    　ことを特徴とする請求項１～３のいずれか１項に記載のプログラム。
  5. 　前記抽選処理において、前記敵キャラクタに対してダメージを与えると決定するための確率は前記敵キャラクタに割り当てられたパラメータに基づいて決定される、
    　ことを特徴とする請求項４に記載のプログラム。
  6. 　前記ダメージは前記敵キャラクタの残りヒットポイント以上の値であり、前記参加依頼入力に基づいて、他のプレイヤに対して参加依頼処理を実行しない、ことを特徴とする請求項１～５のいずれか１項に記載のプログラム。
  7. 　前記ダメージは前記敵キャラクタの残りヒットポイント未満の値であり、前記参加依頼入力に基づいて、他のプレイヤに対して参加依頼処理を実行する、ことを特徴とする請求項１～５のいずれか１項に記載のプログラム。
  8. 　複数のプレイヤが共通の敵キャラクタと対戦するマルチバトルを含むゲームのための方法であって、コンピュータに、
    　プレイヤからのマルチバトル開始入力を受け付ける段階と、
    　受け付けたマルチバトル開始入力に基づいて、所定の敵キャラクタと対戦するマルチバトルを開始する段階と、
    　他のプレイヤに対して前記開始されたマルチバトルへ参加を依頼するための前記プレイヤからの参加依頼入力を受け付ける段階と、
    　参加依頼入力を受け付けると、前記敵キャラクタに対してダメージを与える処理を実行する段階と、
    　を実行させることを特徴とする方法。
  9. 　複数のプレイヤが共通の敵キャラクタと対戦するマルチバトルを含むゲームのための電子装置であって、
    　プレイヤからのマルチバトル開始入力を受け付け、
    　受け付けたマルチバトル開始入力に基づいて、所定の敵キャラクタと対戦するマルチバトルを開始し、
    　他のプレイヤに対して前記開始されたマルチバトルへ参加を依頼するための前記プレイヤからの参加依頼入力を受け付け、
    　参加依頼入力を受け付けると、前記敵キャラクタに対してダメージを与える処理を実行する、
    　ことを特徴とする電子装置。
  10. 　複数のプレイヤが共通の敵キャラクタと対戦するマルチバトルを含むゲームのためのシステムであって、
    　前記システムは、サーバ及び前記サーバに接続される各プレイヤのプレイヤ端末を含み、
    　前記サーバは、
    　　プレイヤ端末から送信されたプレイヤのマルチバトル開始入力を受け付け、
    　　受け付けたマルチバトル開始入力に基づいて、所定の敵キャラクタと対戦するマルチバトルを開始し、
    　　前記プレイヤ端末から送信された、他のプレイヤに対して前記開始されたマルチバトルへ参加を依頼するための前記プレイヤの参加依頼入力を受け付け、
    　　参加依頼入力を受け付けると、前記敵キャラクタに対してダメージを与える処理を実行し、
    　前記敵キャラクタに対してダメージを与えることを表現する演出のための演出情報を前記プレイヤ端末に送信し、
    　プレイヤ端末は、
    　　プレイヤのマルチバトル開始入力及び参加依頼入力を受け付けてサーバに送信し、
    　　サーバからの演出情報に基づいて演出を表示する、
    　ことを特徴とするシステム。
PCT/JP2021/035493 2020-09-28 2021-09-28 マルチバトルを含むゲームのためのプログラム、方法、電子装置及びシステム WO2022065502A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202180066274.9A CN116209504A (zh) 2020-09-28 2021-09-28 用于包括多人对决的游戏的程序、方法、电子装置以及***
US18/191,473 US20230233939A1 (en) 2020-09-28 2023-03-28 Program, method, electronic device, and system for game involving multi-battle

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020-162395 2020-09-28
JP2020162395A JP6909915B1 (ja) 2020-09-28 2020-09-28 マルチバトルを含むゲームのためのプログラム、方法、電子装置及びシステム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/191,473 Continuation US20230233939A1 (en) 2020-09-28 2023-03-28 Program, method, electronic device, and system for game involving multi-battle

Publications (1)

Publication Number Publication Date
WO2022065502A1 true WO2022065502A1 (ja) 2022-03-31

Family

ID=76967440

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/035493 WO2022065502A1 (ja) 2020-09-28 2021-09-28 マルチバトルを含むゲームのためのプログラム、方法、電子装置及びシステム

Country Status (4)

Country Link
US (1) US20230233939A1 (ja)
JP (1) JP6909915B1 (ja)
CN (1) CN116209504A (ja)
WO (1) WO2022065502A1 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015205203A (ja) * 2012-10-03 2015-11-19 グリー株式会社 オンラインゲームの同期方法及びサーバ装置

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015205203A (ja) * 2012-10-03 2015-11-19 グリー株式会社 オンラインゲームの同期方法及びサーバ装置

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Castle & Dragon Character Information MEMO wiki", 16 August 2020 (2020-08-16), XP055914320, Retrieved from the Internet <URL:https://seesaawiki.jp/castle_and_dragon/d/%CB%C9%B1%D2%BA%EE%C0%EF> *
ANONYMOUS: "Collection of Tips We Want to Share with Merc Storia Newcomers", 28 November 2019 (2019-11-28), XP055914324, Retrieved from the Internet <URL:https://yugalab.net/archives/9196> *
COFFEE'S GRANBLUE STRATEGY GUIDE: "[Granblue Fantasy] Thorough explanation of the mechanism of multi-battle for beginners!", 21 September 2020 (2020-09-21), JP, pages 1 - 18, XP009535812, Retrieved from the Internet <URL:https://web.archive.org/web/202009211040500/https://gurabulu-kouryaku.com/520.html> [retrieved on 20211122] *

Also Published As

Publication number Publication date
JP6909915B1 (ja) 2021-07-28
CN116209504A (zh) 2023-06-02
US20230233939A1 (en) 2023-07-27
JP2022055040A (ja) 2022-04-07

Similar Documents

Publication Publication Date Title
JP7170381B2 (ja) プログラム、ゲーム装置、サーバ装置及びゲーム実行方法
JP2002239237A (ja) ゲームシステム及びゲーム報酬分配プログラム
JP7266379B2 (ja) ゲームシステム及びプログラム
JP2022020788A (ja) ゲームプログラム、およびゲームシステム
JP7245213B2 (ja) プログラム、情報処理装置、および情報処理装置の制御方法
JP2017176514A (ja) プログラム、サーバ及びゲームシステム
JP6446213B2 (ja) プログラム及びゲームシステム
WO2022065502A1 (ja) マルチバトルを含むゲームのためのプログラム、方法、電子装置及びシステム
JP6523239B2 (ja) ゲームプログラムおよびゲーム装置
JP7353322B2 (ja) プログラム、情報処理装置及びゲームシステム
JP6403625B2 (ja) 情報処理装置、及び、ゲームプログラム
JP6286197B2 (ja) プログラム及びゲームシステム
JP6337185B1 (ja) 情報処理装置、ゲームプログラム、及び、情報処理方法
JP6920090B2 (ja) プログラム及びゲームシステム
JP2019025307A (ja) 情報処理装置、ゲームプログラム、及び、情報処理方法
JP7281283B2 (ja) プログラム、ゲームシステム及びゲームサービス提供方法
JP5735681B1 (ja) 情報処理装置、及び、ゲームプログラム
JP7386294B1 (ja) プログラム、情報処理装置、方法、及びシステム
JP7488479B2 (ja) 情報処理装置、情報処理方法およびプログラム
JP7210796B1 (ja) 情報処理装置、ゲームプログラム、情報処理方法
JP7210798B1 (ja) 情報処理装置、ゲームプログラム、情報処理方法
JP6858727B2 (ja) ゲームを提供するためのシステム、方法、及びプログラム
JP6941461B2 (ja) プログラム及びゲームシステム
JP2023091468A (ja) 情報処理システムおよびプログラム
JP6833333B2 (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: 21872627

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21872627

Country of ref document: EP

Kind code of ref document: A1