JP7038168B2 - Video game processing device and video game processing program - Google Patents

Description

The present invention relates to a video game processing device that controls the progress of a video game in which a plurality of players participate, and a video game processing program.

The conventional video game system enhances sociality by allowing the exchange of in-game items between players. As such a video game system, there is also a configuration in which a game element is extracted from another player and transmitted in response to a support request by one player (see Patent Document 1).

Japanese Patent No. 3873075

However, the conventional video game system has a problem that it lacks the interest of supporting other players. That is, in the conventional system, a player who supports another player often obtains the merit of the support, but there is a problem that it is difficult to find fun in the act of supporting itself.

It is an object of the present invention to be able to improve the interest of the act itself of rescuing another player in order to solve the above problem.

From a non-limiting point of view, the video game processing device according to the embodiment of the present invention is a video game processing device that controls the progress of a video game in which a plurality of players participate, and information on a virtual mission that the player engages in. Related to the first providing means for providing the virtual mission to the player based on the virtual mission information, and the continuation of the virtual mission to another player different from the player to which the virtual mission is provided. A second means of providing the special mission to be performed, and a restriction that, when the special mission has occurred, limits the operations allowed to the player to which the virtual mission has been provided, as compared with the case where the special mission has not occurred. The second providing means, including means, is characterized in that the special mission is provided to another player who satisfies a predetermined condition regarding the relationship with the player to which the virtual mission is provided.

From a non-limiting point of view, the video game processing program according to the embodiment of the present invention is a video game processing program for realizing a function of controlling the progress of a video game in which a plurality of players participate in a computer. The first function of providing a virtual mission to the player based on the virtual mission information, which is information about the virtual mission that the player works on, and to other players different from the player to which the virtual mission is provided. , The second provision function that provides a special mission related to the continuation of the virtual mission from the middle, and when the special mission has occurred, the operation allowed to the player to which the virtual mission is provided is the special. The second provision function realizes a restriction function that limits the mission more than when the mission has not occurred, and in the second provision function, the special mission is provided to another player who satisfies a predetermined condition regarding the relationship with the player to which the virtual mission is provided. It is for realizing the function.

According to the present invention, it becomes possible to improve the interest of the act itself of rescuing another player.

It is a block diagram which shows the example of the structure of a video game processing system. It is a block diagram which shows the example of the configuration of a video game processing server. It is explanatory drawing for demonstrating the usage mode 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 the 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 the virtual mission-related processing. It is a flowchart which shows the example of the virtual card selection process. It is explanatory drawing for demonstrating the virtual card selection screen. It is explanatory drawing for demonstrating an example of a rescue request reception screen. It is a flowchart which shows the example of the rescue mission-related processing. It is explanatory drawing for demonstrating an example of a rescue mission selection screen. It is explanatory drawing for demonstrating the example of the rescue waiting screen. It is explanatory drawing for demonstrating the mission result display screen. It is explanatory drawing for demonstrating another 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 the video game processing system 100 according to the embodiment of the present invention. As shown in FIG. 1, the 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, respectively. The configuration of the video game processing system 100 is not limited to this, and a single user terminal may be used by a plurality of users, or may be configured to include 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 carrier via 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 the administrator of the video game processing system 100, and has various functions for providing information about the video game to the user terminals 21 to 2N.

The video game processing server 10 is composed of an information processing device such as a WWW server, and includes a storage medium for storing various information. In the video game processing system 100, it is preferable that the video game processing server 10 manages information about the video game from the viewpoint of reducing the processing load applied to each of the plurality of user terminals 21 to 2N. However, a part of the information about the video game may be managed by each of the plurality of user terminals 21 to 2N.

FIG. 2 is a block diagram showing 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 according to a control program stored in the video game information storage unit 16.

The communication unit 12 has a function for communicating 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 on each user terminal) from various information stored in the video game information storage unit 16. 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 the virtual mission-related processing (see FIG. 7) 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 as the video game progresses. The information used for the update process may be acquired 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 composed of, for example, a database device, and is a storage medium that stores various information about a video game whose progress is controlled by the video game processing system 100 and various data such as a control program for a video game. 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 on each of a 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 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 so that the player (that is, the user of the user terminal) can obtain experience points, in-game items, and various points by completing the mission (virtual mission) in the virtual space. .. Here, the "virtual mission" is a configuration in which the player can participate by consuming "activity", and the mission is completed when the player battles multiple enemy characters in succession and defeats the last boss (continuously). Battle composition). Then, in this video game, when a player fails a mission by satisfying a predetermined failure condition (for example, when the player becomes incapable of fighting in the middle of the mission), the player is rescued by another player to perform the mission. You can get the benefits (experience points and in-game items in this example) given when you achieve.

Further, in the video game in this example, a game medium of another player (for example, one displayed in a card format on a game screen showing a virtual space. A virtual card) can be used 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 showing a mineral or a living thing, in addition to a general card form (for example, a trading card or the like, a square paper-like form on which a pattern is drawn). ..

FIG. 3 is an explanatory diagram for explaining how to use the virtual card. Specifically, FIG. 3 shows an example of a game screen (mission execution screen) displayed on a display screen provided in a user terminal when a player is executing a virtual mission. As shown in FIG. 3, in this example, during the execution of the mission, a player character (for example, three player characters PC1 to PC3) and an enemy character operating according to a predetermined rule (for example, two enemy characters). 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 can be selected and displayed are provided. The game screen (battle screen) is displayed.

Here, the player character is managed by the virtual card. That is, before the start of the mission, the player determines the combination (party) of the player characters participating in the virtual mission by selecting the virtual card (character card) in which the information about the player character is set. 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. Be separated. Further, the player card is classified into either a "friend card" or a "guest card" according to the relationship between the player possessing the player card and the player associated with the player card. A player who participates in a video game will be involved with other players via the virtual card, for example, exchanging 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 is set for the player character. When the battle begins, four command cards are distributed to the player and displayed in the command card display area 302. The player selects a command to use from among them. Then, when the ATB gauge is accumulated up to a predetermined amount with the passage of time, 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 command cards dealt, the plurality of command cards are temporarily fused.

Note that FIG. 3 also shows an image K (kill site) showing 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 a player character in the process of a virtual mission, for example, based on the information set in the virtual card.

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 associates it with another player, for example, the display form and operation method of the command card are different from the above-mentioned contents. Any configuration may be used as long as the created virtual card can 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 (FIG. FIG. 2).

The virtual mission information storage unit 16a is a storage medium for storing virtual mission information, which is information related to a mission (virtual mission) that the player works on 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 completed the virtual mission. Is shown.

FIG. 4 is an explanatory diagram showing 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, the action power (necessary action power) consumed by the player to tackle the virtual mission, and the battle constituting the virtual mission. (Number of consecutive battles), information about enemy characters that appear (or may appear) during virtual missions (enemy character information), experience points that players can acquire when completing virtual missions, and Includes in-game items that players acquire (or may acquire) when they complete virtual missions. In this example, the in-game items as achievement benefits include those associated with enemy characters (for example, monsters) appearing in virtual missions.

The configuration of the virtual mission information is not limited to this, and may be any configuration that shows some issues and benefits, such as a configuration that includes issues other than combat.

The player information storage unit 16b is a storage medium for storing player information, which is information about a player participating in a 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 the other players associated with the virtual card.

FIG. 5 is an explanatory diagram showing 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's status includes the player's level in the video game, the action power used to receive the virtual mission, various points that increase or decrease as the video game progresses, and the player virtually possesses it. Includes virtual cards (possessed virtual cards).

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

Rescue points are points used by a player to perform a mission to rescue another player (rescue mission). In this example, the upper limit of the rescue points is 5 points, and the rescue points are fully recovered at a predetermined time (for example, once a day).

Class points are points used to determine a player's class as the video game progresses. In this example, class points are given to the player as a privilege of completing a virtual mission.

Friend points are points used by the player to synthesize virtual cards. By consuming a predetermined amount of friend points, the player can select and synthesize a plurality of virtual cards from the possessed virtual cards. The combined virtual card may be another virtual card of a different type, or the level (or other status) of the virtual card itself may increase.

The structure of the player information is not limited to this, and indicates 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, and the relationship between the players. It is assumed that various information about the player may be included, such as a configuration including information (for example, information indicating a player who has registered a so-called friend. Friend information).

The virtual card information storage unit 16c is a storage medium for storing virtual card information which is information about 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 the 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 showing an example of a storage state of virtual card information in the virtual card information storage unit 16c. As shown in FIG. 6, the virtual card information includes a virtual card number that can uniquely identify the virtual card, a type of the virtual card, and various parameters of the virtual card.

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

The configuration of virtual card information is not limited to this, for example, the rules for changing the parameters according to the level of the virtual card, the rules for changing the parameters of the virtual card according to the status of the player (for example, the level), or the rarity of the virtual card. It may contain various information about the virtual card.

Each of the plurality of user terminals 21 to 2N is managed by a user (player) who plays a video game, and can play a network distribution type game such as a mobile phone terminal, a PDA (Personal Digital Assistants), or a portable game device. Consists of possible mobile communication terminals. Each of the plurality of user terminals 21 to 2N is connected to the communication network 30, and hardware for executing a video game by communicating with the video game processing server 10 (for example, a display device for displaying a game screen or a display device). Equipped with audio output device, etc.) and software. The plurality of user terminals 21 to 2N may be configured so that they can directly communicate with each other without going through the video game processing server 10.

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

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

The virtual mission-related processing starts, for example, when the server 10 receives a virtual mission provision request from any one of a plurality of user terminals 21 to 2N (hereinafter, the user terminal 21 will be described as an example). Will be done.

In the virtual mission-related processing, first, the server 10 identifies the virtual mission 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 from the user terminal 21 and presents the virtual mission number, thereby determining the virtual mission indicated by the virtual mission number as the virtual mission to be provided to the player X1. Further, the server 10 specifies the content of the privilege preset for the virtual mission (for example, the type of privilege and the condition for granting the privilege) as the content of the privilege corresponding to the specified 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 showing an example of the 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 from the present) from the selection candidates.

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

The friend card is a virtual card associated with the player registered as a friend by the player. The server 10 acquires the login time of the player (that is, the friend) corresponding to the friend card possessed by the player X1. This is cached on the client side (in this example, the user terminal 21 side) for a few minutes. This is because it is possible to reduce the inability to communicate between the server 10 and the user terminal 21 by caching. 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 people. In this example, the friend whose login time is early is ranked high. If 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. Further, if there is no friend card included in the possessed virtual card, the server 10 does not select the friend card.

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

When the virtual card is selected, the server 10 identifies the player (other 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 to specify 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 updates the parameters of the selected guest card in the same manner. 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 of determining the parameters of the non-player card is not limited to this, and the parameters may be updated by another process different from that of the player card (friend card and guest card), or the predetermined parameters may not be updated. It may be the configuration used for.

When the virtual card is selected and the parameters of the selected virtual card are updated as necessary, the server 10 shifts 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 the virtual card selection screen (step S102). In this example, the user terminal 21 receives the virtual card information indicating the virtual card selected in the virtual card selection process from the server 10 and displays the virtual card selection screen.

FIG. 9 is an explanatory diagram for explaining the virtual card selection screen. As shown in FIG. 9, the virtual card selection screen in this example has a deck button 901, a mission button 902 for accepting a request to start a virtual mission, and a party display area showing members (party) participating in the virtual mission. A participation candidate display area 920 indicating a participation candidate for a virtual mission is 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 on the 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 deck of command cards set for members belonging to the party (character indicated by the virtual card). Display the edit screen (not shown).

The party display area 910 and the participation candidate display area 920 indicate an image of the character indicated by the virtual card, the level of the player corresponding to the virtual card, and the attributes of the command card associated with the virtual card, based on the virtual card information. A plurality of images 911, 912, 921 to 924 (hereinafter, appropriately referred to as virtual cards 911, 912, 921 to 924) showing information such as a gauge that serves as a reference for selecting a virtual card by the player X1 are displayed. Further, 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; virtual card 912) so as to be distinguishable from other virtual cards. , 923.) Is displayed. When the user terminal 21 accepts the selection of the virtual card displayed in the participation candidate display area 920, the user terminal 21 moves the virtual card for which the selection is accepted to the party display area 910. Further, when the user terminal 21 accepts the selection of the virtual card displayed in the party display area 910, the user terminal 21 displays the virtual card for which the selection is accepted 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 accepts the selection of the mission button 902 while 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 used. Judge that it is decided.

Here, when it is determined that the virtual card to be 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 the virtual mission by displaying the start screen of the virtual mission based on the virtual mission information received together with the virtual card information, for example.

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 completed (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 defeated enemy characters). .. Further, at this time, in this example, the user terminal 21 specifies the player card corresponding to the player X1 as a privilege (used privilege) given to the other player X2 corresponding to the player card used by the player X1. The used privilege is given to the other player X2 by the server 10 when the player engaged in the virtual mission satisfies a predetermined distribution condition (for example, acquisition of the privilege according to the virtual mission). In addition, the time when the achievement privilege and the used privilege are specified is not particularly limited, and is specified either at the start of the virtual mission, during the virtual mission (for example, when the grant condition is satisfied), or at the end of the virtual mission. It may be configured to be. Further, each privilege may be independently specified.

Upon specifying the achievement privilege, the user terminal 21 determines whether or not the player X1 has failed in the virtual mission (step S106). In this example, after the start of 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 HP of the party satisfies a predetermined condition (for example, a character belonging to the party). When all the HPs of the above become 0), it is determined that the player X1 has failed in the virtual mission.

Here, for example, when it is determined that the virtual mission has not failed because the player X1 has achieved the virtual mission (N in step S106), the user terminal 21 shifts to the process of 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 limits the operations allowed to the player to predetermined contents (step S107). In this example, the user terminal 21 determines that the current state of the player X1 is in a rescue-requiring state, and makes it impossible to select an operation permitted in a normal state (for example, a virtual mission selection operation).

When the operation allowed to the player is restricted, the user terminal 21 determines whether or not the rescue request has been accepted (step S108). In this example, the user terminal 21 determines whether or not the rescue request has been accepted by displaying a predetermined rescue request reception screen in response to the determination that the virtual mission has failed. The method of receiving the rescue request is not limited to this, and for example, when it is determined that the virtual mission has failed, the user terminal 21 may be configured to 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 reception screen, a message input area 1001 for accepting the input of the rescue request message by the player, a transmission button 1002 for accepting the transmission request of the rescue request message, and a rescue request message are displayed. A cancel button 1003 is provided for accepting a request to cancel the transmission.

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

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

When the rescue-requiring player is specified, the server 10 identifies the rescue mission and the privilege content corresponding to the rescue mission (step S302). In this example, the server 10 identifies a virtual mission that the player X1 has failed as a rescue mission. Further, the server 10 sets the in-game item and the conditions for granting the in-game item to the specified rescue mission according to the content of the specified rescue mission (for example, the type of the enemy character appearing in the failed virtual mission). Specify as the corresponding privilege content.

When the rescue mission and the privilege content are specified, the server 10 notifies the other players of the rescue mission (step S303). In this example, the server 10 notifies a player who satisfies a predetermined condition (for example, the level difference is within 3) in relation to the player X1 of the rescue mission. It should be noted that a designated time limit (for example, within 12 hours) may be provided as a required condition to limit an act in which a certain player A continuously rescues another player B. Further, when the number of players satisfying the predetermined number is less than the predetermined number, the server 10 may be configured to select other conditions (for example, players close to the predetermined condition) until the predetermined number is reached. Hereinafter, a case where the server 10 notifies a plurality of players including the player X2 of the rescue mission will be described as an example.

Upon notifying the rescue mission, the server 10 identifies the rescue mission execution player who executes the rescue mission (step S304). In this example, when the server 10 receives the rescue mission execution request from the user terminal 22, for example, the server 10 specifies the player X2 who is the user of the user terminal 22 as the rescue mission execution player. The user terminal 22 displays a predetermined rescue mission selection screen in response to the notification of the rescue mission from the server 10 (specifically, in response to the reception of information indicating the existence of the rescue mission). do. Then, when the operation input from the player X2 to the rescue mission selection screen is received, the user terminal 22 transmits the rescue mission execution request corresponding to the received 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 requester list display area in which a list of rescue-requiring players (rescue requester list) is displayed. The player X2 selects a rescue mission to be undertaken from among a plurality of rescue-requiring players 1201 to 1203 shown in the rescue requester list, for example, based on the class of the rescue-requiring person and the rescue mission name.

When the server 10 identifies the player X2 as the rescue mission execution player, the server 10 transmits the rescue mission information to the user terminal 22 operated by the player X2 (step S305). In this example, the server 10 subtracts the rescue points corresponding to the rescue mission from the rescue points of the player X2 at this time. That is, the server 10 does not provide the rescue mission to the player whose rescue points have not reached the amount required to undertake the rescue mission even if the rescue mission execution request is received. However, in this example, the server 10 also notifies the specified rescue mission to the player who does not have the rescue point necessary for undertaking the rescue mission. With such a configuration, the player can confirm the contents of the rescue mission and then decide whether or not to undertake the rescue mission. Therefore, if the rescue points can be obtained according to the progress of the video game, the player who has confirmed the rescue mission can be motivated to play the video game. Further, the server 10 may be configured to limit the target for notifying the rescue mission according to the progress of the video game (for example, the amount of rescue points owned). With such a configuration, it is possible to prevent the load on the server 10 from becoming excessive due to an increase in communication targets.

When the user terminal 22 receives the rescue mission information from the server 10, the user terminal 22 performs a process for causing the player X2 to play the rescue mission based on the received rescue mission information. As the process for playing the rescue mission, the rescue request may be accepted in response to the failure of the rescue mission, as in the case of the virtual mission.

On the other hand, the user terminal 21 operated by the player X1 specified as the rescue-requiring player limits the operations related to the virtual mission by the player X1. In this example, the user terminal 21 displays a game screen (rescue waiting screen) for indicating to the player X1 that the player X1 is waiting for rescue 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 waiting screen. As shown in FIG. 13, the rescue standby screen is 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, the release button 1303 for accepting the release request of the rescue standby state from the player, and the current rescuer list display area where a list of other players who are executing the rescue mission in response to the rescue request by the player is displayed. 1304 is provided. In this example, while the rescue standby screen is displayed, the user terminal 21 displays the progress of the rescue mission at predetermined time intervals (for example, every minute) in order to confirm the rescue status of the player X1. Check with 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 (to clarify the explanation, the achievement of the rescue mission is "success"" based on the specified privilege content. The privilege (success privilege) to be given to the rescue mission execution player is specified in (expressed. The same shall apply hereinafter) (step S306). In this example, the server 10 compares the progress of the rescue virtual mission by the player X2 (for example, the type and number of defeated enemy characters) with the privilege content (for example, the conditions for granting in-game items). Identify success benefits. Specifically, the server 10 specifies a success privilege including class points, friend points, and other drop rewards (that is, rewards given to the player who succeeds in the virtual mission) for the player who succeeds in the rescue. Further, in this example, the server 10 determines the content of the success privilege according to the success privilege determination rule influenced by the relationship between the rescued player and the rescued player (for example, level difference or whether or not the player is a friend). Identify. The rule for determining success benefits may be such that if you rescue a lower level than yourself, the class points will be higher than the normal rescue, and if you rescue a friend, the class points will be higher than the normal rescue. In addition, the success privilege determination rule may be configured to specify command cards and equipment materials that can only be obtained by rescue. The time to specify the success privilege is not particularly limited, and may be at the start of the rescue mission, during the rescue mission (for example, when the grant conditions are satisfied), or at the end of the rescue mission.

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

Here, when it is determined that the rescue mission is successful (Y in step S307), the server 10 gives the rescue mission execution player the privilege of the rescue-requiring player (in this example, the achievement privilege) and the rescue mission execution player. A privilege (in this example, a success privilege) is given (step S308). It should be noted that the player who succeeds in the rescue mission may be configured to give only the success privilege. Further, when the player who succeeded in the rescue mission uses the friend card in the rescue mission, the server 10 may use the player card corresponding to the player who succeeded in the rescue mission with respect to the player corresponding to the friend card. It may be configured to give a player card corresponding to the rescue-requiring player.

When the privilege (achievement privilege and success privilege in this example) is given to the rescue mission execution player, the server 10 grants the rescue-required player privilege (achievement privilege in this example) to the rescue-required player. Then (step S309), the process here is terminated. 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, if the rescue mission is successful, the server 10 grants the player corresponding to the friend card a player card corresponding to the player requiring rescue and a player card corresponding to the player who succeeded in the rescue mission. May be.

Further, 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 because the player X1 has achieved the virtual mission (N in step S106), the server 10 has achieved the virtual mission. The specified achievement privilege is given to the player X1 (step S109). In this example, the server 10 causes the user terminal 21 operated by the rescued player X1 to display a predetermined mission result display screen, and the user terminal 22 operated by the rescued player X2 displays a predetermined rescue result display screen ( (Not shown) is displayed. The server 10 appropriately updates various information stored in the video game information storage unit 16 when or before and after the privilege is given. In this example, the server 10 leaves the rescued virtual mission completion flag intact. That is, the player cannot break the completion flag of the virtual mission unless he / she completes the virtual mission by himself / herself.

FIG. 14 is an explanatory diagram for explaining the mission result display screen. As shown in FIG. 14, the user terminal 21 pops up an image 1401 indicating that the rescue has been performed 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, the mission result display screen may be configured to display an image 1510 prompting the rescued player X1 to input a predetermined operation. In this case, the image 1510 has information about a player who has succeeded in the rescue mission, a friend request button 1511 for receiving a friend request for the player, and a reward message input area 1512 for receiving a reward message input for the player. A transmission button 1513 for accepting a request for sending a reward message and a cancel button 1514 for accepting a request for canceling the transmission of the reward message may be provided.

When the achievement privilege is given, the server 10 grants the player card corresponding to the player X1 to another player (that is, the player corresponding to the friend card used by the player X1 in the virtual mission) (step S110), and here. Ends the processing in.

When it is determined in the process of step S108 in the virtual mission-related process that the user terminal 21 does not accept the rescue request, for example, 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 process related to the virtual mission, the server 10 succeeds in the rescue mission because, for example, the player X2 fails the rescue mission or the player X1 has not been rescued from anyone for a certain period of time. When it is determined that there is no such (N in step S307), the user terminal 21 determines whether or not to give up the rescue of the player X1 (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 accepted. That is, in this example, whether or not the rescue-requiring player gives up being rescued does not matter whether the rescue is executed or not. In this example, the selection of the release button 1303 is subject to the consumption of a predetermined amount of class points.

Here, if it is determined that the rescue has not been given up (N in step S111), the user terminal 21 displays the rescue waiting screen (see FIG. 13) (step S112), and proceeds to the process of step S300. do. On the other hand, when it is determined that the rescue is given up by accepting the selection of the release button 1303 (Y in step S111), the user terminal 21 releases the restriction on the operation allowed by the player (see step S107). (Step S113), the process here is terminated. At this time, the server 10 may be configured to execute a predetermined process (rescue mission release process) in case the rescue-requiring player gives up being rescued. In this case, the rescue mission cancellation process may be configured so that the rescue mission execution player can recognize that the rescue mission is canceled. For example, the server 10 cancels the rescue mission for the player who is executing the rescue mission. It may be configured to notify the fact, or it may be configured to let the rescue mission execution player select whether or not to continue the rescue mission as a virtual mission (that is, as a mission in which the rescue target does not exist). 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) has elapsed from the time when the rescue request is made. ..

As described above, in the above-described embodiment, a video game processing device (for example, a video game processing server 10, a user terminal 21, or a video game processing system) that controls the progress of a video game in which a plurality of players participate. 100. The same shall apply hereinafter) comprises a virtual mission information storage unit 16a that stores virtual mission information that is information about the virtual mission that the player X1 works on, and provides the player X1 with a virtual mission based on the virtual mission information (for example, Step S104), it is determined whether or not the player X1 has failed the virtual mission (for example, step S106), and in response to the determination that the virtual mission has failed (for example, Y in step S106), the virtual mission is assigned. A player who identifies a special mission provided to a player different from the failed player X1 (for example, a rescue mission provided by the video game processing server 11 to the user terminal 22) (for example, step S302) and executes the special mission. The special mission execution player (for example, rescue mission execution player X2) is identified (for example, step S304), and it is determined whether or not the special mission execution player X2 succeeds in the special mission (for example, step S307). Depending on the determination that the mission was successful (for example, Y in step S307), a privilege (for example, an achievement privilege or a success privilege) is given to the special mission execution player X2 and the player X1 who failed in the virtual mission. (For example, steps S308 and 309), it is possible to improve the interest of the act itself of rescuing another player.

That is, when a certain player fails a predetermined mission, a rescue request is made to another player (especially a friend), and when another player undertakes the rescue request, the other player has a mission corresponding to the rescue request (especially). For example, if the player who made the rescue request performs a failed mission or another special mission; the rescue mission in the embodiment described above) and another player succeeds in the mission, both players Since the rescue success reward (for example, achievement privilege or success privilege) is given, when supporting (for example, rescue) other players, it is only necessary to provide game elements such as in-game items as in the past. Instead, the player will perform a special mission that may fail, and as a result, the interest of the act of rescuing another player can be improved. Note that the special mission is not limited to the mission that is premised on rescuing another player. For example, the video game processing device is generated by a mission in which a certain player continues a mission that failed from the middle or a mission that fails. The mission may be a special mission in which the player is rescued by giving some privilege to the player who has failed the mission as a result, such as making another mission a special mission.

Further, in the above-described embodiment, the video game processing device identifies the player X1 who has failed in the virtual mission as a rescue-requiring player (for example, step S301), and notifies a plurality of players of the existence of the rescue-requiring player. (For example, step S303), the rescue mission execution request by any of the players notified of the existence of the rescue-requiring player is accepted (for example, step S304), and the predetermined rule (for example, the same as the failed virtual mission). A player who specifies a rescue mission for rescuing a player requiring rescue as a special mission (for example, step S302) according to a rule that the virtual mission is a rescue mission, and satisfies a predetermined rescue mission execution request according to a rescue mission execution request. (For example, a player having a necessary amount of rescue points to undertake a rescue mission) is specified as a special mission execution player (for example, a rescue mission execution player) (for example, step S304). Various rescue missions will be specified by the combination of the above and the contents of the prescribed rules, and it will be possible to improve the interest of the rescue missions.

Further, in the above-described embodiment, the video game processing device includes a player information storage unit 16b that stores player information that is information about each of a plurality of players, and is a special mission execution player (for example, rescue mission execution player X2). And a specific rule regarding at least one of the player information of each player (for example, rescue required player X1) who failed in the virtual mission (for example, a rule for granting a privilege to both players X1 and X2 according to the content of the rescue mission and the like. ), The privilege to be given to at least one of the special mission execution player and the player who failed the virtual mission (for example, both players X1 and X2) is specified (for example, steps S105 and S306), and the specified privilege is given to the player. Since it is configured to be given to (for example, both players X1 and X2) (for example, steps S109, S308, S309), it becomes possible to provide a merit to the rescued side who does not perform the rescue mission, and the rescue mission can be provided. You will be able to improve the interest of.

Further, in the above-described embodiment, the video game processing device limits the operations allowed for the player X1 determined to have failed in the virtual mission (for example, step S107), and a predetermined release condition is satisfied. By doing so, the restriction is released (for example, step S113), the predetermined release condition includes the use of the game element (for example, class points), and the privilege (for example, achievement privilege or success privilege) includes the game element. Since it is configured so that it may be included, for example, by using the game element as an evaluation index of the player in the virtual space, it is possible to provide the player with a virtual space in which the action done for another person is evaluated. become.

Although not particularly mentioned in the above-described embodiment, the video game processing device is related to the failed virtual mission such as the difficulty level of the failed virtual mission and the player information of the rescued player and the rescued player. The difficulty level of the rescue mission may be adjusted based on various information (information related to the failed mission). With such a configuration, it becomes possible to provide difficulty in accomplishing the special mission, and it becomes possible to strengthen the connection between the rescued player and the rescued player. That is, it becomes possible to improve the sociality of the so-called game.

Further, in the above-described embodiment, the video game processing device identifies the player X1 who has failed in the provided virtual mission as a rescue-requiring player (for example, step S301), and the rescue-requiring player X1 is based on the virtual mission information. Rescue mission execution player who is a player who identifies a rescue mission to be accomplished in order to rescue (for example, step S302), notifies a plurality of players of the rescue mission (for example, step S303), and executes the rescue mission. (For example, step S304), the rescue mission is provided to the identified rescue mission execution player X2 (for example, step S305), and the rescue mission execution player X2 who succeeds in the rescue mission becomes the rescue required player X1. Since the configuration is such that the associated game medium (for example, a virtual card) is added (for example, steps S308 and S309), it becomes possible to increase the chance that one player acquires another player's game medium.

Although not particularly mentioned in the above-described embodiment, a player-compatible game in which the video game processing device is information about a game medium (for example, a virtual card) and is a game medium associated with a specific player. A game medium information storage unit (eg, for example) 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. The virtual card information storage unit 16c) is provided, and the player accepts the selection of a plurality of player-compatible game media by the player, and the player follows a predetermined rule (for example, a rule in which a virtual card synthesized according to a combination of virtual cards is determined). A configuration may be configured in which a non-compatible game medium corresponding to a plurality of selected player-compatible game media is determined, and the determined non-compatible game medium is given to the player. With such a configuration, each player can interact with more players (for example, use a player-compatible game medium corresponding to another player, or accept a mission to rescue another player). You will be able to encourage. Further, when the video game processing device gives the player a non-compatible game medium determined in response to the selection of the plurality of player-compatible game media by the player, the player can use the selected plurality of player-compatible game media. It may be configured to erase from the game medium possessed by the player (for example, erase the corresponding virtual card from the list of possessed virtual cards in the player information). With such a configuration, it becomes possible to encourage each player to interact with more players.

Further, in the above-described embodiment, the video game processing device determines the privilege content (for example, the type of privilege and the condition for granting the privilege) before the player starts the virtual mission (including the rescue mission). (For example, steps S101 and S302), so that cheating can be prevented. That is, for example, even if a cheat that unreasonably modifies the parameters of the game medium is performed, it is possible to prevent the user from obtaining an unreasonably expensive privilege compared to the difficulty level of the virtual mission achieved. convenient.

Further, in the above-described embodiment, the plurality of user terminals 21 to 2N and the video game processing server 10 have various control programs (for example, a video game processing program) stored in their own storage device. Executes the processing of.

The configuration of the video game processing system 100 is not limited to the above-described configuration. For example, the server 10 may execute a part or all of the processing described as the processing executed by the user terminal, or the server 10 may execute the processing. A part or all of the processing described as the processing to be performed may be executed by any one of the plurality of user terminals 21 to 2N (for example, the user terminal 21). Further, the user terminals 21 to 2N may be configured to include a part or all of the storage unit included in the server 10. That is, the other one may have a part or all of the functions provided by either the user terminal 21 or the video game processing server 10 in the video game processing system 100.

[Additional Notes]
The description of the above-described embodiment describes at least the following invention so that a person having ordinary knowledge in the field to which the invention belongs can carry out the invention.
[1]
A video game processing device that controls the progress of a video game in which multiple players participate.
Virtual mission information storage means for storing virtual mission information, which is information about virtual missions that the player works on,
A virtual mission providing means for providing a virtual mission to the player based on the virtual mission information,
A failure determination means for determining whether or not the player has failed the virtual mission,
A special mission specifying means for specifying a special mission provided to a player different from the player who failed the virtual mission in response to the determination that the virtual mission has failed by the failure determining means.
A special mission execution player specifying means for specifying a special mission execution player who is a player who executes the special mission, and
A success determination means for determining whether or not the special mission execution player has succeeded in the special mission,
It includes a privilege granting means for granting a privilege to the player who executes the special mission and the player who fails the virtual mission in response to the determination that the special mission is successful by the success determining means. A featured video game processing device.
[2]
Rescue-requiring player identification means for identifying the player who failed the virtual mission as a rescue-requiring player, and
A notification means for notifying the plurality of players of the existence of the rescue-requiring player, and
The rescue execution request receiving means for receiving a rescue execution request by any of the players notified of the existence of the rescue-requiring player by the notification means is included.
The special mission specifying means identifies the rescue mission to be accomplished in order to rescue the rescue-requiring player as the special mission in accordance with a predetermined rule.
The video game processing device according to [1], wherein the special mission execution player specifying means identifies a player who satisfies a predetermined rescue execution condition in response to the rescue execution request as the special mission execution player.
[3]
A player information storage means for storing player information, which is information about each of the plurality of players,
According to the specific rule regarding at least one of the player information of the special mission execution player and the player who failed the virtual mission, the privilege to be given to at least one of the special mission execution player and the player who failed the virtual mission is specified. Including privilege identification means
The video game processing device according to [1] or [2], wherein the privilege granting means grants the privilege specified by the privilege specifying means.
[4]
A limiting means that limits the operations allowed for a player who is determined to have failed a virtual mission by the failure determining means, and a limiting means.
Including a release means for releasing the restriction when a predetermined release condition is satisfied,
The predetermined release conditions include the use of game elements.
The video game processing device according to any one of [1] to [3], wherein the privilege may include the game element.
[5]
The video game process according to any one of [1] to [4], which includes a difficulty level adjusting means for adjusting the difficulty level of the special mission based on the failed mission-related information which is the information related to the failed virtual mission. Device.
[6]
A video game processing program for providing a computer with a function to control the progress of a video game in which multiple players participate.
A computer equipped with a virtual mission information storage means that stores virtual mission information, which is information about the virtual mission that the player works on.
A virtual mission providing function that provides a virtual mission to the player based on the virtual mission information,
A failure determination function for determining whether or not the player has failed the virtual mission, and
A special mission identification function that identifies a special mission provided to a player different from the player who failed the virtual mission in response to the determination that the virtual mission has failed.
The special mission execution player identification function that identifies the special mission execution player that is the player who executes the special mission, and the special mission execution player identification function.
A success determination function for determining whether or not the special mission execution player has succeeded in the special mission, and
A video game processing program for realizing a privilege granting function of granting a privilege to a player who executes the special mission and a player who fails the virtual mission in response to the determination that the special mission is successful.

According to the present invention, it is useful for improving the interest of the act itself of rescuing another player.

10 Video game processing server 11 Control unit 12 Communication unit 13 Search unit 14 Judgment unit 15 Update unit 16 Video game information storage unit 21 to 2N User terminal 30 Communication network 100 Video game processing system

Claims (2)

A video game processing device that controls the progress of a video game in which multiple players participate.
A first providing means for providing a virtual mission to the player based on virtual mission information, which is information about a virtual mission that the player works on using in-game elements.
A special mission related to rescuing a player who has failed in the virtual mission, in which an in-game element associated with the player and an in-game element not associated with the player appear. Including the second providing means to provide
When the second providing means receives a request to cancel the special mission from the player on condition that the points owned by the player who failed the virtual mission are consumed, the second providing means cancels the provision of the special mission.
A video game processing device characterized by that. A video game processing program for providing a computer with a function to control the progress of a video game in which multiple players participate.
To the computer
The first provision function that provides a virtual mission to the player based on the virtual mission information, which is information about the virtual mission that the player works on using the in-game element, and
A special mission related to rescuing a player who has failed in the virtual mission, in which an in-game element associated with the player and an in-game element not associated with the player appear. Realize the second provision function to be provided,
In the second provision function, when a request to cancel the special mission is received from the player on condition that the points owned by the player who failed the virtual mission are consumed, the function of canceling the provision of the special mission is provided.
A video game processing program to make it happen.

Images