JP6243323B2 - Video game processing apparatus and video game processing program - Google Patents

Description

  The present invention relates to a video game processing apparatus and a video game processing program for controlling the progress of a multiplayer video game played using a game medium in which parameters are set.

  A conventional video game system (for example, an online game system) is a game medium (for example, a game screen showing a virtual space) in which information about itself is registered among a plurality of players in order to introduce itself and exchange in-game items. It was displayed in a card format. Virtual card.) Some of such video game systems have realized communication battles between players by making it possible to register character information in a game medium (see, for example, Patent Document 1).

JP 2010-142306 A

  However, in the conventional video game system, it is difficult to provide each player with a sense that the video game is progressing in cooperation with other players who play the same video game. There was a problem of lacking.

  In order to solve the above-described problem, an object of the present invention is to provide each player with a sense of cooperating with other players.

  The video game processing apparatus of the present invention is a video game processing apparatus that controls the progress of a multiplayer video game that is played using a game medium in which parameters are set. Virtual mission information storage means for storing virtual mission information which is information relating to a virtual mission to be tackled, virtual mission provision means for providing a virtual mission to the player based on the virtual mission information, and game media used in the virtual mission A game medium providing means for providing a game medium associated with the player using the game medium to another player associated with the game medium.

  With the above configuration, it is possible to provide each player with a sense of cooperating with other players.

  Player information storage means for storing player information indicating a status of each of the plurality of players, a game medium possessed by each of the plurality of players, and other players associated with the game medium, and possessed by the player Other player status specifying means for specifying the status of another player corresponding to the game medium to be played at a predetermined time, and parameter updating means for updating a predetermined parameter set in the game medium based on the specified status of the other player It may be set as the structure containing these.

  Game medium display means for selectively displaying the game medium, and the game medium display means, when the parameter of the game medium is updated by the parameter update means, at least a part of the updated parameter In addition, the game media may be displayed.

  Based on virtual rescue information stored in the virtual mission information storage means, the rescue-required player is required based on the rescue mission specifying means for identifying a player who has failed the virtual mission provided by the virtual mission providing means as a rescue-required player. A rescue mission identifying means for identifying a rescue mission for rescue, a reporting means for notifying the rescue mission to the plurality of players, and a rescue for identifying a rescue mission executing player who is a player executing the rescue mission A mission execution player specifying means, wherein the virtual mission providing means provides the rescue mission to the identified rescue mission execution player, and the game medium giving means is a rescue mission execution player who has succeeded in the rescue mission. On the other hand, a game medium associated with the rescue-required player may be provided.

  Information about the game medium, which includes information about a player-compatible game medium that is a game medium associated with a specific player and information about a non-compatible game medium that is a game medium not associated with a specific player Corresponding to a plurality of player-compatible game media selected by the player according to a predetermined rule. A non-corresponding game medium determining means for determining a non-compatible game medium, and a non-compatible game medium providing means for giving the player the non-compatible game medium determined by the non-compatible game medium determining means. May be.

  Furthermore, the video game processing program of the present invention is a video game processing program for causing a computer to realize a function of controlling the progress of a video game of a multiplayer participation type that is played using a game medium in which parameters are set. And providing a virtual mission to the player based on the virtual mission information in a computer having virtual mission information storage means for storing virtual mission information, which is information relating to a virtual mission that the player works on using the game media. A task providing function and a game medium providing function for providing a game medium associated with a player using the game medium to another player associated with the game medium used in the virtual mission It is for making it happen.

  According to the present invention, it is possible to provide each player with a sense of cooperating with other players.

It is a block diagram which shows the example of a structure of a video game processing system. It is a block diagram which shows the example of a structure of a video game processing server. It is explanatory drawing for demonstrating the usage condition of a virtual card. It is explanatory drawing which shows the example of the storage state of virtual mission information. It is explanatory drawing which shows the example of the storage state of player information. It is explanatory drawing which shows the example of the storage state of virtual card information. It is a flowchart which shows the example of a virtual mission related process. It is a flowchart which shows the example of a virtual card selection process. It is explanatory drawing for demonstrating a virtual card selection screen. It is explanatory drawing for demonstrating the example of a rescue request reception screen. It is a flowchart which shows the example of a rescue mission related process. It is explanatory drawing for demonstrating the example of a rescue mission selection screen. It is explanatory drawing for demonstrating the example of a rescue waiting screen. It is explanatory drawing for demonstrating a mission result display screen. It is explanatory drawing for demonstrating the other example of a mission result display screen.

  Hereinafter, an example of an embodiment of the present invention will be described with reference to the drawings.

  FIG. 1 is a block diagram showing an example of the configuration of a video game processing system 100 according to an embodiment of the present invention. As shown in FIG. 1, a video game processing system 100 includes a video game processing server 10 and user terminals 21 to 2N (N is an arbitrary integer) used by a plurality of users. Note that the configuration of the video game processing system 100 is not limited thereto, and a single user terminal may be used by a plurality of users, or a configuration including a plurality of servers.

  The video game processing server 10 and the plurality of user terminals 21 to 2N are each connected to a communication network 30 such as the Internet. Although not shown, the plurality of user terminals 21 to 2N are connected to the communication network 30 by performing data communication with a base station managed by a communication provider through a wireless communication line.

  The video game processing system 100 has various functions for controlling the progress of a video game (so-called online game) in which a plurality of players play in the same virtual space (including a synchronized virtual space and an asynchronous virtual space). Have.

  The video game processing server 10 is managed by an administrator of the video game processing system 100, and has various functions for providing information relating to the video game to the user terminals 21 to 2N.

  The video game processing server 10 is configured by an information processing apparatus such as a WWW server, and includes a storage medium that stores various types of information. In the video game processing system 100, it is preferable that the video game processing server 10 manages information related to the video game from the viewpoint of reducing the processing load on each of the plurality of user terminals 21 to 2N. However, it is good also as a structure which each of the some user terminal 21-2N manages a part of information regarding a video game.

  FIG. 2 is a block diagram illustrating an example of the configuration of the video game processing server 10. As shown in FIG. 2, the video game processing server 10 includes a control unit 11, a communication unit 12, a search unit 13, a determination unit 14, an update unit 15, and a video game information storage unit 16.

  The control unit 11 includes a CPU, a ROM, and the like, and has a function for controlling the entire video game processing server 10 in accordance with a control program stored in the video game information storage unit 16.

  The communication unit 12 has a function for performing communication with a plurality of user terminals 21 to 2N via a communication network 30 such as the Internet.

  The search unit 13 searches for information according to the progress of the video game (for example, information according to the progress of the video game at each user terminal) from various information stored in the video game information storage unit 16. It has the function of.

  The determination unit 14 has a function for making various determinations according to the progress of the video game. In this example, the determination unit 14 has a function of performing various determinations in a virtual mission-related process (see FIG. 7) to be described later based on various determination conditions stored in the video game information storage unit 16.

  The update unit 15 has a function for updating various information stored in the video game information storage unit 16 in accordance with the progress of the video game. The information used for the update process may be obtained from a plurality of user terminals 21 to 2N, or may be prepared in advance in the video game information storage unit 16.

  The video game information storage unit 16 is constituted by, for example, a database device, and stores various information related to the video game that the video game processing system 100 controls its progress, and various data such as a video game control program. It is.

  Here, an outline of a video game whose progress is controlled by the video game processing system 100 will be described. In this example, the video game processing system 100 controls the progress of a so-called social RPG (social role playing game) played at each of the plurality of user terminals 21 to 2N. That is, the video game processing system 100 controls the progress of the video game in which some kind of relationship occurs between the plurality of users who operate the plurality of user terminals 21 to 2N.

  In this example, the video game is configured such that a player (that is, a user terminal user) can obtain experience points, in-game items, and various points by achieving a mission in the virtual space (virtual mission). . Here, the “virtual mission” means that a player can participate by consuming “action power”, and is configured to achieve a mission by continuously playing against multiple enemy characters and defeating the last boss (continuous). (Battle composition). In this video game, if a player fails a mission by satisfying a predetermined failure condition (for example, when the battle becomes impossible during the mission), the player is rescued by another player, The privilege (in this example, an experience value and an in-game item) given when the above is achieved can be acquired.

  In addition, the video game in this example can use game media of other players in a virtual mission. Hereinafter, a case where a “virtual card” is adopted as a game medium used by a player to play a video game will be described as an example. The form of the game medium is not particularly limited, and may be a form of a general card (for example, a square paper-like form on which a picture is drawn, such as a trading card), for example, a form showing minerals or organisms. .

  FIG. 3 is an explanatory diagram for explaining a usage mode of the virtual card. Specifically, FIG. 3 shows an example of a game screen (duty execution screen) displayed on a display screen provided in the user terminal when the player is executing a virtual mission. As shown in FIG. 3, in this example, during the execution of a mission, a player character (for example, three player characters PC1 to PC3) and an enemy character (for example, two enemy characters) that move according to a predetermined rule. NPC1, NPC2), a status display area 301 in which the status of the player character (for example, ATB gauge, HP, and MP) is displayed, and a command card display area 302 in which a command card is selectably displayed is provided. A game screen (battle screen) is displayed.

  Here, the player character is managed by a virtual card. That is, the player determines a combination (party) of player characters participating in the virtual mission by selecting a virtual card (character card) in which information related to the player character is set before starting the mission. In the video game of this example, there are two types of character cards: a virtual card (player card) associated with a specific player and a virtual card (non-player card) not associated with a specific player. Separated. The player card is classified into either a “friend card” or a “guest card” according to the relationship between the player who owns the player card and the player associated with the player card. A player who participates in a video game is involved with another player through a virtual card, for example, exchange of a virtual card. The processing related to various virtual cards will be described in detail later.

  The command card is a virtual card in which a command to be executed by the player character is set. When the battle starts, four command cards are distributed to the player and displayed in the command card display area 302. The player selects a command to be used from among them. When the ATB gauge is accumulated up to a predetermined amount as time passes, the corresponding player character executes the selected command. Further, when there are a plurality of command cards (for example, the same command card) satisfying a predetermined condition among the four distributed command cards, the plurality of command cards are temporarily merged.

  FIG. 3 also shows an image K (kill site) indicating that when the enemy character satisfies a predetermined condition, the enemy character can be crushed with a single blow when the player character makes an attack. The video game processing system sets a kill site for an enemy character or player character in the course of a virtual mission based on, for example, information set on a virtual card.

  Note that the configuration of the video game whose progress is controlled by the video game processing system 100 is not limited to this, and the player is associated with other players, for example, the display form of the command card and the operation method are different from those described above. Any configuration that can use the virtual card that has been used may be used.

  In this example, the video game information storage unit 16 includes a virtual mission information storage unit 16a, a player information storage unit 16b, and a virtual card information storage unit 16c in order to control the progress of the video game described above (see FIG. 2).

  The virtual mission information storage unit 16a is a storage medium that stores virtual mission information that is information related to a task (virtual mission) that a player works using a virtual card. In this example, the virtual mission information includes a virtual mission provided to the player (that is, a mission imposed on the player in the virtual space), and a privilege (achievement privilege) given to the player who has achieved the virtual mission. Indicates.

  FIG. 4 is an explanatory diagram illustrating an example of a storage state of virtual mission information in the virtual mission information storage unit 16a. As shown in FIG. 4, the virtual mission information includes a virtual mission number that can uniquely identify the virtual mission, an action power consumed by the player to tackle the virtual mission (necessary action power), and a battle that constitutes the virtual mission. (Number of consecutive battles), information on enemy characters that appear (or may appear) during the virtual mission (enemy character information), experience values that the player can acquire when the virtual mission is achieved, And in-game items that a player acquires (or may acquire) when a virtual mission is achieved. In this example, in-game items as achievement bonuses include items associated with enemy characters (for example, monsters) appearing in a virtual mission.

  In addition, the structure of virtual mission information is not limited to this, For example, what is necessary is just the structure which shows a certain subject and privilege, such as a structure containing the subjects other than a battle.

  The player information storage unit 16b is a storage medium that stores player information that is information related to players participating in the video game. In this example, the player information indicates the status of each of the plurality of players, the virtual card possessed by each of the plurality of players, and other players associated with the virtual card.

  FIG. 5 is an explanatory diagram illustrating an example of a storage state of player information in the player information storage unit 16b. As shown in FIG. 5, the player information includes a player number that can uniquely identify the player and various statuses of the player. In this example, the player has virtually the player's status, the level of the player in the video game, the action power used to receive the virtual mission, various points that increase or decrease as the video game progresses, Virtual card (owned virtual card).

  Here, the various points include rescue points, class points, and friend points.

  A rescue point is a point used by a player to perform a mission to rescue another player (rescue mission). In this example, the rescue points have a maximum value of 5 points and are fully recovered at a predetermined time (for example, once a day).

  Class points are points used to determine a player's class according to the progress of the video game. In this example, the class point is given to the player as a privilege for achieving the virtual mission.

  A friend point is a point used by a player to synthesize a virtual card. The player can select and combine a plurality of virtual cards from the possessed virtual cards by consuming a predetermined amount of friend points. The synthesized virtual card may be another virtual card of a different type, or the level (or other status) of the virtual card itself may be increased.

  The configuration of the player information is not limited to this. For example, information indicating the current status of the player (player status information) such as the virtual mission being executed by the player and the progress status of the virtual mission (player status information) and the relationship between the players are shown. Various information regarding the player may be included, such as a configuration including information (for example, information indicating a player who is performing so-called friend registration; friend information).

  The virtual card information storage unit 16c is a storage medium that stores virtual card information that is information related to a virtual card. In this example, the virtual card information indicates various parameters related to the virtual card such as the attack power and HP of a character (player character) that can be operated by the player when the player card is used for a virtual mission.

  FIG. 6 is an explanatory diagram illustrating an example of a storage state of virtual card information in the virtual card information storage unit 16c. As illustrated in FIG. 6, the virtual card information includes a virtual card number that can uniquely identify a virtual card, a type of virtual card, and various parameters of the virtual card.

  Here, the types of virtual cards include a player card that is a virtual card that is associated with a specific player and a non-player card that is a virtual card that is not associated with a specific player. In this example, “corresponding to a player” is a concept different from “a player has” and means “a virtual card indicating a player”. The association between the player and the player card may be changed according to the progress of the video game, or may not be changed according to the progress of the video game. In the case of the former configuration, for example, the video game processing system 100 may be configured to specify one possessed virtual card as a player card corresponding to the player in response to a request from the player. . On the other hand, in the case of the latter configuration, for example, the video game processing system 100 may be configured to specify that the player card corresponding to each player cannot be changed according to a specific rule.

  The configuration of the virtual card information is not limited to this. For example, the parameter according to the level of the virtual card, the rule for changing the parameter of the virtual card according to the player status (for example, level), or the rare degree of the virtual card It is assumed that various types of information related to virtual cards may be included.

  Each of the plurality of user terminals 21 to 2N is managed by a user (player) who plays a video game. For example, a network distribution type game such as a mobile phone terminal, a PDA (Personal Digital Assistants), or a portable game device can be played. It is composed of possible mobile communication terminals. Each of the plurality of user terminals 21 to 2N is connected to the communication network 30 and communicates with the video game processing server 10 to execute a video game (for example, a display device or a display device that displays a game screen) Audio output device etc.) and software. The plurality of user terminals 21 to 2N may be configured to be able to perform direct communication without using the video game processing server 10.

  Next, the operation of the video game processing system 100 of this example will be described. Note that the contents of operations and processes not related to the present invention may be omitted.

  FIG. 7 is a flowchart illustrating an example of virtual mission related processing executed by the video game processing system 100. In the virtual mission-related processing, processing from provision of a virtual mission to the player to provision of a privilege according to the result of the virtual mission to the player is performed. Hereinafter, referring to FIG. 7 showing a flowchart including processing executed by each of the plurality of user terminals 21 to 2N and processing executed by the video game processing server 10 (server 10), the virtual mission-related processing is executed. The operation of the video game processing system 100 will be described.

  The virtual mission-related processing is started in response to, for example, the server 10 receiving a virtual mission provision request from any one of the plurality of user terminals 21 to 2N (hereinafter described using the user terminal 21 as an example). Is done.

  In the virtual mission-related process, first, the server 10 specifies the virtual mission to be provided to the user (player X1) of the user terminal 21 and the privilege content corresponding to the virtual mission (step S101). In this example, the server 10 receives the virtual mission provision request presenting the virtual mission number from the user terminal 21 and thereby determines the virtual mission indicated by the virtual mission number as the virtual mission to be provided to the player X1. Moreover, the server 10 specifies the content of the privilege preset for the virtual mission (for example, the type of privilege and the conditions for granting the privilege) as the privilege content corresponding to the identified virtual mission.

  When the virtual mission to be provided and the privilege content are specified, the server 10 executes a process (virtual card selection process) for selecting a virtual card to be selected by the player X1 (step S200).

  FIG. 8 is a flowchart illustrating an example of a virtual card selection process executed by the server 10. In the virtual card selection process, first, the server 10 matches a plurality of virtual cards by selecting various virtual cards according to a predetermined selection rule (step S201). In this example, the server 10 selects three non-player cards, three friend cards, and three guest cards. At this time, the server 10 excludes the virtual card used by the player X1 for the virtual mission within a predetermined time (for example, within 3 hours before the present) from the selection candidates.

  The non-player card is a virtual card associated with an important character appearing in the video game. The server 10 randomly selects three non-player cards from the virtual cards possessed by the player X1. Note that when the number of non-player cards included in the virtual card possessed by the player X1 is less than the number selected, the server 10 selects only the number possessed by the player X1. Further, when there is no non-player card included in the possessed virtual card, the server 10 does not select a non-player card.

  A friend card is a virtual card associated with a player registered as a friend by the player. The server 10 acquires the login time of the player (that is, friend) corresponding to the friend card possessed by the player X1. This is cached for several minutes on the client side (in this example, on the user terminal 21 side). This is because caching can reduce the inability to communicate between the server 10 and the user terminal 21. When the login time is acquired, the server 10 creates a list of friends, sorts them in the order of login, and selects friend cards corresponding to the top three names. In this example, a friend whose login time is early is set as a higher rank. When the number of friend cards included in the virtual card possessed by the player X1 is less than the number selected, the server 10 selects only the number possessed by the player X1. If there is no friend card included in the possessed virtual card, the server 10 does not select a friend card.

  The guest card is a virtual card corresponding to a player who corresponds to a player card that the player does not have and is not a friend of the player. The server 10 is a player of a level similar to the level of the player X1 (for example, within 5 levels above and below), and three users who have logged in within a specific time (for example, within 3 hours before the present) Three player cards corresponding to the three extracted players are selected as guest cards.

  When the virtual card is selected, the server 10 specifies a player (another player) corresponding to the selected player card (step S202). Hereinafter, the case where the server 10 specifies the user X2 (other player X2) of the user terminal 22 as another player will be described as an example.

  When the other player is specified, the server 10 specifies the status of the specified other player (step S203). In this example, the server 10 refers to the player information and identifies the level of the other player X2.

  When the status of the other player X2 is specified, the server 10 updates the parameters (for example, attack power and HP) of the player card corresponding to the other player X2 based on the specified status of the other player X2 (step S204). In this example, the server 10 similarly updates the parameters for the selected guest card. On the other hand, for the selected non-player card, the server 10 updates the parameters based on the status (for example, level) of the player X1. The method for determining the parameters of the non-player card is not limited to this, and the parameter may be updated by another process different from the player card (friend card and guest card), or the predetermined parameter is not updated. It is good also as a structure used for.

  When the virtual card is selected and the parameters of the selected virtual card are updated as necessary, the server 10 proceeds to the process of step S102 in the virtual mission related process (see FIG. 7).

  When the server 10 executes the virtual card selection process, the user terminal 21 displays a virtual card selection screen (step S102). In this example, the user terminal 21 receives virtual card information indicating the virtual card selected in the virtual card selection process from the server 10 and displays a virtual card selection screen.

  FIG. 9 is an explanatory diagram for explaining a virtual card selection screen. As shown in FIG. 9, on the virtual card selection screen in this example, a deck button 901, a mission button 902 for accepting a virtual mission start request, and a party display area indicating members (party) participating in the virtual mission 910 and a participation candidate display area 920 indicating candidates for participation in the virtual mission are provided. The user terminal 21 displays at least a part of the virtual card information received from the server 10 in the participation candidate display area 920 so as to be selectable.

  The deck button 901 is a virtual button for accepting a display request for a deck edit screen. For example, when the display position of the deck button 901 is pressed by the finger P of the player X1, the user terminal 21 displays a command card set (deck) set as a member (character indicated by the virtual card) belonging to the party. An editing screen is displayed (not shown).

  The party display area 910 and the participation candidate display area 920 indicate, based on the virtual card information, the character image indicated by the virtual card, the level of the player corresponding to the virtual card, and the attribute of the command card associated with the virtual card. A plurality of images 911, 912, 921 to 924 (hereinafter, referred to as virtual cards 911, 912, 921 to 924 as appropriate) are displayed that indicate information that serves as a selection criterion for the virtual card by the player X 1 such as a gauge. In this example, the virtual card (friend card) corresponding to the friend of the player X1 has an identification image (for example, a star-shaped image in FIG. 9; a virtual card 912 so that it can be distinguished from other virtual cards). , 923) is displayed. When receiving the selection of the virtual card displayed in the participation candidate display area 920, the user terminal 21 moves the virtual card that has received the selection to the party display area 910. In addition, when the user terminal 21 receives selection of the virtual card displayed in the party display area 910, the user terminal 21 displays the virtual card that has received the selection in the participation candidate display area 920.

  When the virtual card selection screen is displayed, the user terminal 21 determines whether or not the virtual card used for the virtual mission has been determined (step S103). In this example, when the user terminal 21 receives the selection of the mission button 902 in a state where a predetermined number (for example, three) of virtual cards are displayed in the party display area 910, the virtual card used for the virtual mission is It is determined that it has been determined.

  If it is determined that the virtual card used for the virtual mission has been determined (Y in step S103), the user terminal 21 starts the virtual mission (step S104). In this example, the user terminal 21 starts a virtual mission, for example, by displaying a virtual mission start screen based on the virtual mission information received together with the virtual card information.

  When the virtual mission is started, the user terminal 21 specifies a privilege (achievement privilege) to be given to the player X1 when the virtual mission is achieved (step S105). In this example, the user terminal 21 specifies the achievement privilege according to the privilege content preset for the virtual mission and the achievement status of the virtual mission by the player X1 (for example, the type and number of enemy characters that have been defeated). . At this time, in this example, the user terminal 21 specifies a player card corresponding to the player X1 as a privilege (used privilege) to be given to the other player X2 corresponding to the player card used by the player X1. The bonus to be used is given to the other player X2 by the server 10 when a player who has tackled the virtual mission satisfies a predetermined distribution condition (for example, acquisition of a privilege according to the virtual mission). In addition, the timing when the achievement privilege and the used privilege are specified is not particularly limited, and is specified at the start of a virtual mission, during a virtual mission (for example, when a grant condition is satisfied), or at the end of a virtual mission. It may be configured. Moreover, the structure by which each privilege is specified independently may be sufficient.

  When the achievement privilege is specified, the user terminal 21 determines whether or not the player X1 has failed in the virtual mission (step S106). In this example, after starting the virtual mission, the user terminal 21 controls the progress of the virtual mission based on the operation input by the player X1, and as a result, when the party's HP satisfies a predetermined condition (for example, a character belonging to the party It is determined that the player X1 has failed in the virtual mission.

  Here, for example, if it is determined that the virtual mission has not failed due to the player X1 achieving the virtual mission (N in step S106), the user terminal 21 proceeds to the processing in step S109 described later. On the other hand, when it is determined that the player X1 has failed in the virtual mission (Y in step S106), the user terminal 21 restricts the operation permitted to the player to a predetermined content (step S107). In this example, the user terminal 21 determines that the current state of the player X1 is in a rescue state and prevents an operation that is permitted in a normal state (for example, a virtual mission selection operation) from being selected.

  When the operations permitted to the player are restricted, the user terminal 21 determines whether or not a rescue request has been accepted (step S108). In this example, the user terminal 21 determines whether or not a rescue request has been received by displaying a predetermined rescue request reception screen in response to determining that the virtual mission has failed. Note that the rescue request acceptance method is not limited to this, and for example, when it is determined that the virtual mission has failed, the user terminal 21 may determine that the rescue request has been accepted.

  FIG. 10 is an explanatory diagram for explaining an example of a rescue request reception screen. As shown in FIG. 10, on the rescue request acceptance screen, a message input area 1001 for accepting an input of a rescue request message by the player, a send button 1002 for accepting a rescue request message transmission request, and a rescue request message A cancel button 1003 for accepting a request to cancel transmission is provided.

  If it is determined that the rescue request has been accepted by accepting the selection of the send button 1002 (Y in step S108), the user terminal 21 causes the server 10 to execute rescue mission related processing (step S300).

  FIG. 11 is a flowchart illustrating an example of rescue mission-related processing executed by the server 10. In the rescue mission-related process, first, the server 10 specifies a rescue-required player (step S301). In this example, the server 10 receives the rescue request message from the user terminal 21 and identifies the player X1 as a rescue-needed player.

  When the rescue-required player is identified, the server 10 identifies the rescue mission and the privilege content corresponding to the rescue mission (step S302). In this example, the server 10 specifies the virtual mission that the player X1 has failed as the rescue mission. Further, the server 10 sets the in-game item and the provision condition of the in-game item to the identified rescue mission according to the content of the identified rescue mission (for example, the type of enemy character that appears in the failed virtual mission). It is specified as the corresponding privilege content.

  When the rescue mission and the privilege content are specified, the server 10 notifies the rescue mission to the other players (step S303). In this example, the server 10 notifies the rescue mission to a player who satisfies a predetermined condition (for example, the level difference is within 3) in relation to the player X1. In addition, it is good also as a structure which restrict | limits the action which a certain player A rescues the other player B continuously by providing designation | designated time limit (for example, within 12 hours) in a required condition. Further, when the number of players satisfying the predetermined condition is less than the predetermined number, the server 10 may select another condition (for example, a player close to the predetermined condition) until the predetermined number is reached. Hereinafter, a case where the server 10 notifies the rescue mission to a plurality of players including the player X2 will be described as an example.

  When the rescue mission is notified, the server 10 specifies a rescue mission execution player who executes the rescue mission (step S304). In this example, when the server 10 receives a rescue mission execution request from the user terminal 22, for example, the server 10 identifies the player X2 who is a user of the user terminal 22 as a rescue mission execution player. The user terminal 22 displays a predetermined rescue mission selection screen in response to the rescue mission being notified from the server 10 (specifically, in response to receiving information indicating the presence of the rescue mission). To do. And when the operation input from the player X2 with respect to the rescue mission selection screen is received, the user terminal 22 transmits a rescue mission execution request according to the accepted operation input to the server 10.

  FIG. 12 is an explanatory diagram for explaining an example of a rescue mission selection screen. As shown in FIG. 12, the rescue mission selection screen is provided with a rescue request list display area in which a list of rescue required players (rescue applicant list) is displayed. The player X2 selects a rescue mission to be entrusted from among a plurality of rescue-required players 1201 to 1203 shown in the rescue requester list, using, for example, the class of the rescuer and the rescue mission name as judgment criteria.

  When the server 10 specifies the player X2 as a rescue mission execution player, the server 10 transmits rescue mission information to the user terminal 22 operated by the player X2 (step S305). In this example, the server 10 subtracts the rescue point corresponding to performing the rescue mission from the rescue point of the player X2 at this time. That is, the server 10 does not provide a rescue mission to a player whose rescue points have not reached the amount necessary for undertaking the rescue mission, even if a rescue mission execution request is received. However, in this example, the server 10 notifies the specified rescue mission even to a player who does not have a rescue point necessary for undertaking the rescue mission. By adopting such a configuration, the player can determine whether or not to undertake the rescue mission after confirming the content of the rescue mission. Therefore, if the rescue points can be acquired according to the progress of the video game, the player who has confirmed the rescue mission can be given a motivation to play the video game. Moreover, it is good also as a structure which the server 10 restrict | limits the object which alert | reports a rescue mission according to the progress condition (for example, quantity of the rescue point to own) of a video game. With such a configuration, it is possible to prevent an excessive load on the server 10 due to an increase in communication targets.

  When receiving the rescue mission information from the server 10, the user terminal 22 performs processing for causing the player X2 to play the rescue mission based on the received rescue mission information. In addition, as a process for making a rescue mission play, it is good also as a structure which receives a rescue request according to the failure of a rescue mission similarly to the case of a virtual mission.

  On the other hand, the user terminal 21 operated by the player X1 specified as the rescue-required player restricts operations related to the virtual mission by the player X1. In this example, the user terminal 21 displays a game screen (rescue standby screen) for indicating to the player X1 that the player X1 is in the rescue standby and cannot perform any operation other than the “operation to give up rescue”.

  FIG. 13 is an explanatory diagram for explaining an example of a rescue standby screen. As shown in FIG. 13, on the rescue standby screen, a player status display area in which a character PC (player character PC) indicated by a virtual card corresponding to the player, a player level 1301, and a player status 1302 are displayed. And a release button 1303 for receiving a request for canceling the rescue standby state from the player, and a current rescuer list display area in which a list of other players performing rescue missions in response to the rescue request by the player is displayed. 1304 is provided. In this example, the user terminal 21 displays the rescue mission progress status at predetermined time intervals (for example, every minute) in order to confirm the rescue status of the player X1 while the rescue standby screen is displayed. Confirm with the server 10.

  In the rescue mission-related process, when the user terminal 21 transmits the rescue mission information, the server 10 determines that the rescue mission is “successful” in order to clarify the explanation when the rescue mission is successful based on the specified privilege content. The privilege (successful privilege) to be given to the rescue mission execution player is specified (step S306). In this example, the server 10 compares the progress status of the rescue virtual mission by the player X2 (for example, the type and number of defeated enemy characters) and the privilege content (for example, the in-game item grant condition), Identify success benefits. Specifically, the server 10 identifies a success privilege including class points, friend points, and other drop rewards (that is, rewards given to players who have successfully completed virtual missions) for players who have successfully rescued. Further, in this example, the server 10 displays the content of the success privilege according to the success privilege determination rule that is affected by the relationship between the rescued player and the rescued player (for example, level difference or friendship). Identify. Note that the success privilege determination rule may be configured such that when a lower level is rescued than itself, the class point is higher than normal rescue, and when the friend is rescued, the class point is higher than normal rescue. Further, the success privilege determination rule may be configured such that command cards and equipment materials that can be acquired only by rescue are specified. The timing for specifying the success privilege is not particularly limited, and may be any time when the rescue mission is started, during the rescue mission (for example, when the grant conditions are satisfied), or when the rescue mission is completed.

  When the success privilege is specified, the server 10 determines whether or not the rescue mission indicated by the transmitted rescue mission information is successful (step S307). In this example, the server 10 receives information (rescue mission result information) indicating the result of the rescue mission from the user terminal 22, and determines whether or not the rescue mission is successful based on the received rescue mission result information. .

  Here, if it is determined that the rescue mission is successful (Y in step S307), the server 10 gives the rescue mission execution player a privilege of the rescue required player (achieved privilege in this example) and the rescue mission execution player. A privilege (success privilege in this example) is given (step S308). In addition, it is good also as a structure which gives only a success privilege with respect to the player who succeeded in the rescue mission. In addition, when a player who has succeeded in the rescue mission uses a friend card in the rescue mission, the server 10 has a player card corresponding to the player who has succeeded in the rescue mission to the player corresponding to the friend card, It is good also as a structure which gives the player card corresponding to a rescue required player.

  When a privilege (in this example, an achievement privilege and a success privilege) is granted to the rescue mission execution player, the server 10 grants a privilege for the rescue required player (in this example, an achievement privilege) to the rescue-required player. (Step S309), and the process here ends. In this example, when the player fails in the virtual mission, the friend card (that is, the virtual card corresponding to the player who failed in the virtual mission) is not given to the player corresponding to the friend card used by the player. However, when the rescue mission is successful, the server 10 gives the player corresponding to the friend card a player card corresponding to the rescue required player or a player card corresponding to the player who succeeded in the rescue mission. It is good.

  In the process of step S106 in the virtual mission-related process, for example, when it is determined that the virtual mission has not failed due to the player X1 achieving the virtual mission (N in step S106), the server 10 achieves the virtual mission. The achieved achievement privilege is granted to the player X1 who has played (step S109). In this example, the server 10 displays a predetermined mission result display screen on the user terminal 21 operated by the rescued player X1, and also displays a predetermined rescue result display screen (on the user terminal 22 operated by the rescued player X2). (Not shown). Note that the server 10 appropriately updates various information stored in the video game information storage unit 16 at the time of granting the privilege or before and after granting the privilege. In this example, the server 10 leaves the rescue mission completion flag as it is. That is, the player cannot break the virtual mission completion flag unless he or she completes the virtual mission.

  FIG. 14 is an explanatory diagram for explaining the mission result display screen. As illustrated in FIG. 14, the user terminal 21 pops up an image 1401 indicating that the user terminal 21 has been rescued on the rescue standby screen.

  FIG. 15 is an explanatory diagram for explaining another example of the mission result display screen. As shown in FIG. 15, an image 1510 that prompts the rescued player X1 to perform a predetermined operation input may be displayed on the mission result display screen. In this case, the image 1510 includes information on the player who succeeded in the rescue mission, a friend application button 1511 for receiving a friend application request for the player, and a reward message input area 1512 for receiving an input of a reward message for the player. And a send button 1513 for accepting a request for sending an appreciation message, and a cancel button 1514 for accepting a request for canceling the send of an appreciation message.

  When the achievement privilege is granted, the server 10 grants a player card corresponding to the player X1 to another player (that is, a player corresponding to the friend card used by the player X1 in the virtual mission) (step S110). The process in is terminated.

  In the process of step S108 in the virtual mission-related process, for example, when it is determined that the user terminal 21 does not accept the rescue request by accepting the selection of the cancel button 1003 on the rescue request acceptance screen (N in step S108), Alternatively, in the process of step S307 in the virtual mission related process, the server 10 succeeds in the rescue mission because, for example, the player X2 fails in the rescue mission or the player X1 has not been rescued from anyone for a certain period of time. When it determines with there being (N of step S307), the user terminal 21 determines whether the player X1 gives up rescuing (step S111). In this example, the user terminal 21 determines that the player X1 has given up being rescued when the selection of the release button 1303 on the rescue standby screen is received. That is, in this example, whether or not a rescue-required player gives up being rescued does not relate to execution / non-execution of rescue. In this example, it is assumed that a predetermined amount of class points is consumed for selection of the cancel button 1303.

  If it is determined that the user has not given up being rescued (N in step S111), the user terminal 21 displays a rescue standby screen (see FIG. 13) (step S112), and the process proceeds to step S300. To do. On the other hand, if it is determined that the user has given up being rescued by accepting the selection of the release button 1303 (Y in step S111), the user terminal 21 releases the restriction on the operation permitted to the player (see step S107). (Step S113), the process here ends. In addition, it is good also as a structure which the server 10 performs a process (rescue mission interruption process) predetermined as a case where the server 10 needs to be rescued at this time. In this case, the rescue mission interruption process may be configured so that the rescue mission executing player can recognize that the rescue required player is rescued. For example, the server 10 cancels the rescue mission for the player who is executing the rescue mission. It is good also as a structure which notifies to the effect of doing, and it is good also as a structure which makes a rescue mission execution player select whether a rescue mission is continued as a virtual mission (namely, as a mission without a rescue object). Further, when there is a player who is executing a rescue mission, the user terminal 21 may not accept the selection of the release button 1303 until a specific time (for example, 1 hour) elapses after the rescue request is made. .

  As described above, in the above-described embodiment, the video game processing apparatus (for controlling the progress of a multiplayer video game played using a game medium (for example, a virtual card) in which parameters are set (for example, a virtual game card) For example, the video mission processing server 10, the user terminal 21, or the video game processing system 100. The same applies hereinafter.) A virtual mission information storage unit that stores virtual mission information that is information related to a virtual mission that a player tackles using a game medium. 16a, providing a virtual mission to the player X1 based on the virtual mission information (for example, step S104), and providing the game medium to the other player X2 associated with the game medium used in the virtual mission. Configuration in which a game medium associated with the used player X1 is provided (for example, step S110) Since it is, and it is possible to provide a feeling of cooperation with another player for each player.

  That is, since a certain player can increase the chances of using the game media of other players, it is possible to provide each player with a sense of cooperating with other players.

  In the above-described embodiment, the video game processing device supports the status (for example, level) of each of the plurality of players, the game medium (for example, virtual card) possessed by each of the plurality of players, and the game medium. The player information storage unit 16b for storing player information indicating the attached other players, and the status of the other player X2 corresponding to the game medium possessed by the player X1 are specified as predetermined times (for example, step S203). Since predetermined parameters (for example, attack power and HP) set in the game medium are updated (for example, step S204) based on the statuses of the other identified players, each player's current The status of other players affects other players who use game media associated with them Can be recognized, and when using a game medium associated with another player, it can be recognized that the current status of the other player has an effect. Become.

  In the above-described embodiment, when the video game processing apparatus displays a game medium (for example, a virtual card) in a selectable manner (for example, step S102), and the parameters of the game medium are updated ( For example, since the game medium is displayed together with at least a part of the updated parameters (for example, the level of the virtual card) (for example, see FIG. 9), other players possessed by the player are configured. The information on the game medium corresponding to the above can be updated as appropriate when the player selects the game medium.

  Further, in the above-described embodiment, the video game processing device identifies the player X1 who fails the provided virtual mission as a rescue-required player (for example, step S301), and based on the virtual mission information, the rescue-required player X1 A rescue mission to be rescued is specified (for example, step S302), the rescue mission is notified to a plurality of players (for example, step S303), and a rescue mission execution player is a player who executes the rescue mission. (For example, step S304), providing the rescue mission to the identified rescue mission execution player X2 (for example, step S305), and making the rescue mission execution player X2 successful in the rescue mission to the rescue-required player X1 An associated game medium (for example, a virtual card) is given (for example, step S308). S309) Since a configuration, it is possible to increase the chance that a player will win the game medium other players.

  Although not specifically mentioned in the above-described embodiment, the video game processing apparatus is information relating to a game medium (for example, a virtual card) and is a game medium that is a game medium associated with a specific player. A game medium information storage unit (for example, a game medium information storage unit) that stores game medium information including information about a medium (for example, a player card) and a non-compatible game medium (for example, a non-player card) that is a game medium that is not associated with a specific player. A virtual card information storage unit 16c), which accepts selection of a plurality of player-compatible game media by the player and is performed by the player in accordance with a predetermined rule (for example, a rule in which a virtual card to be synthesized according to a combination of virtual cards is determined). A non-compatible game medium corresponding to the selected plurality of player-compatible game media; Constant, and non-compatible game medium determined may be used as the structure to be given to the player. By having such a configuration, it is possible to interact with a larger number of players for each player (for example, use of a player-compatible game medium corresponding to another player or acceptance of a mission to rescue other players). Can be encouraged. In addition, when the video game processing device gives a non-corresponding game medium determined in response to selection of a plurality of player-corresponding game media by the player, the selected player-corresponding game media are used as the player. May be deleted from the game medium possessed by the player (for example, the corresponding virtual card is deleted from the list of possessed virtual cards in the player information). With such a configuration, each player can be encouraged to interact with more players.

  In the above-described embodiment, the video game processing device is configured to give a privilege to the rescued player X1 when the rescue mission is successful. The player can be encouraged to rescue the player. In addition, the video game processing device gives a point (for example, a class point), which is an evaluation index of the player in the virtual space, as a privilege to the player who rescues another player, for example, according to the difficulty level of the rescue mission. By adopting the configuration, it is possible to provide a player with a virtual space in which an action performed for another person is evaluated.

  In the above-described embodiment, the video game processing apparatus determines the privilege content (for example, the privilege type and the condition for granting the privilege) before the player starts the virtual mission (including the rescue mission). (For example, Steps S101 and S302) Since it is configured, cheat action can be prevented. That is, for example, even if a cheat of changing the game medium parameters unfairly is performed, it is possible to prevent an unfairly expensive privilege from being obtained compared to the degree of difficulty of the achieved virtual mission, etc. convenient.

  In the above-described embodiment, the plurality of user terminals 21 to 2N and the video game processing server 10 are configured according to various control programs (for example, video game processing programs) described above according to various control programs (for example, video game processing programs) stored in a storage device provided therein. Execute the process.

  Note that the configuration of the video game processing system 100 is not limited to the above-described configuration, and for example, the server 10 may be configured to execute a part or all of the processing described as the processing executed by the user terminal. A part or all of the processing described as the processing to be performed may be configured to be executed by any one of the plurality of user terminals 21 to 2N (for example, the user terminal 21). Moreover, it is good also as a structure with which the user terminals 21-2N are provided with a part or all of the memory | storage part with which the server 10 is provided. That is, a part or all of the functions of either the user terminal 21 or the video game processing server 10 in the video game processing system 100 may be included in the other one.

  According to the present invention, it is useful for providing each player with a sense of cooperating with other players.

DESCRIPTION OF SYMBOLS 10 Video game processing server 11 Control part 12 Communication part 13 Search part 14 Determination part 15 Update part 16 Video game information storage part 21-2N User terminal 30 Communication network 100 Video game processing system

Claims (6)

A video game processing device for controlling the progress of a video game,
Storage means for storing a player and a virtual mission that the player cannot execute in association with each other;
Notification means for notifying a player different from the player of the presence of the player associated with the virtual mission;
Look including a display means for said virtual mission to display that it is played on the display screen of the display device a game screen including an image in which the player, which is correlated with the virtual mission can be recognized,
The display means displays a game screen for requesting that a player associated with the virtual mission sets a predetermined relationship with the player who has achieved the virtual mission when the virtual mission is achieved. A video game processing apparatus characterized by displaying . The video game processing device according to claim 1, further comprising granting means for granting a privilege to a player associated with the virtual mission when the virtual mission is achieved by the player. The video game processing apparatus according to claim 2, wherein the granting unit grants a privilege that is different from the privilege or the privilege to a player who has played the virtual mission. The video game processing device according to claim 2, wherein the granting unit grants a point that is an evaluation index of a player in the virtual space as the privilege. The display means displays a game screen for selecting an in-game element associated with one of the plurality of players set with the predetermined relationship for the other to use in the virtual mission. The video game processing device according to any one of claims 1 to 4. A video game processing program for causing a computer to perform a function of controlling the progress of a video game,
In a computer provided with storage means for storing a player and a virtual mission that the player cannot execute in association with each other,
A notification function for notifying a player different from the player of the presence of the player associated with the virtual mission;
Said virtual mission to realize a display function of displaying on the display screen of the display device a game screen including the images that give recognized association by the player within the virtual mission that has been played,
In the display function, when the virtual mission is achieved, a game screen for requesting that a player associated with the virtual mission sets a predetermined relationship with the player who has achieved the virtual mission is displayed. A video game processing program for realizing a display function .