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

Video game processing apparatus and video game processing program Download PDF

Info

Publication number
JP5890331B2
JP5890331B2 JP2013005738A JP2013005738A JP5890331B2 JP 5890331 B2 JP5890331 B2 JP 5890331B2 JP 2013005738 A JP2013005738 A JP 2013005738A JP 2013005738 A JP2013005738 A JP 2013005738A JP 5890331 B2 JP5890331 B2 JP 5890331B2
Authority
JP
Japan
Prior art keywords
player
mission
virtual
rescue
special
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2013005738A
Other languages
Japanese (ja)
Other versions
JP2014136022A (en
Inventor
端 田畑
端 田畑
匡泰 西田
匡泰 西田
Original Assignee
株式会社スクウェア・エニックス
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社スクウェア・エニックス filed Critical 株式会社スクウェア・エニックス
Priority to JP2013005738A priority Critical patent/JP5890331B2/en
Publication of JP2014136022A publication Critical patent/JP2014136022A/en
Application granted granted Critical
Publication of JP5890331B2 publication Critical patent/JP5890331B2/en
Application status is Active legal-status Critical
Anticipated expiration legal-status Critical

Links

Description

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

  Conventional video game systems have improved sociality by allowing exchange of in-game items between players. As such a video game system, there is also a configuration in which game elements are extracted and transmitted from other players in response to a support request from a certain 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, a player who supports other players in the conventional system 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.

  In order to solve the above-described problems, an object of the present invention is to improve the interest of the act of rescuing other players.

  The video game processing apparatus of the present invention is a video game processing apparatus that controls the progress of a video game in which a plurality of players participate, and that stores virtual mission information storage means for storing virtual mission information that is information relating to a virtual mission that the player is tackling. Virtual mission providing means for providing the player with a virtual mission based on the virtual mission information, failure determination means for determining whether or not the player has failed in the virtual mission, and the failure determination means A special mission identifying means for identifying a special mission provided to a player different from the player who failed the virtual mission in response to the determination that the mission has failed, and a player that executes the special mission Special mission execution player specifying means for specifying a special mission execution player, and the special mission execution player succeeds in the special mission A privilege for the success determination means for determining whether or not the special mission has been successful by the success determination means, and the player who has failed the virtual mission in response to the determination that the special mission has been successful. And a privilege granting means for granting.

  By having said structure, the interest of the act itself of rescuing other players can be improved now.

  Rescue player specifying means for specifying a player who has failed in the virtual mission as a rescue player, notification means for notifying the plurality of players of the presence of the rescue player, and the notification means of the rescue player Rescue execution request accepting means for accepting a rescue execution request by any one of the players whose presence has been notified, and the special mission specifying means should be achieved to rescue the rescue required player according to a predetermined rule The rescue mission may be specified as the special mission, and the special mission execution player specifying unit may be configured to specify a player who satisfies a predetermined rescue execution condition according to the rescue execution request as the special mission execution player. .

  Player information storage means for storing player information, which is information relating to each of the plurality of players, and execution of the special mission according to a specific rule regarding at least one of the player information of the special mission execution player and the player who has failed the virtual mission A privilege specifying means for specifying a privilege to be given to at least one of the player and the player who has failed in the virtual mission, and the privilege granting means is configured to grant the privilege specified by the privilege specifying means. Also good.

  A restriction means for restricting an operation permitted for a player determined to have failed in the virtual mission by the failure judgment means; and a release means for releasing the restriction when a predetermined release condition is satisfied, The predetermined release condition may include use of a game element, and the privilege may include the game element.

  It may be configured to include difficulty adjustment means for adjusting the difficulty of the special mission based on failure mission related information that is information related to the failed virtual mission.

  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 in which a plurality of players participate, and is a virtual game information that is related to a virtual mission that the player is tackling. A virtual mission providing function for providing a virtual mission to the player based on the virtual mission information in a computer having virtual mission information storage means for storing mission information, and whether or not the player has failed in the virtual mission. A failure determination function for determining, a special mission specifying function for specifying a special mission provided to a player different from the player who has failed in the virtual mission in response to determining that the virtual mission has failed, Special mission execution player identification that identifies a special mission execution player that is a player performing a special mission , A success determination function for determining whether or not the special mission execution player has succeeded in the special mission, and the special mission execution player and the virtual mission in response to determining that the special mission has been successful. It is for realizing the privilege grant function which grants a privilege with respect to the player who failed.

  According to the present invention, it is possible to improve the interest of the act of rescuing 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.

  Further, the video game in this example can use 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) 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 cancellation | release process) predetermined as a case where the server 10 needs to be rescued at this time. In this case, the rescue mission release process may be configured so that the rescue mission execution player can recognize that the rescue mission is released . 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 that effect, 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 in which a rescue object 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) elapses after the rescue request is made. .

  As described above, in the above-described embodiment, the video game processing device (for example, the video game processing server 10, the user terminal 21, or the video game processing system) that controls the progress of the video game in which a plurality of players participate. 100. The same applies hereinafter) includes a virtual mission information storage unit 16a that stores virtual mission information that is information related to the virtual mission that the player X1 is tackling, and provides the virtual mission to the player X1 based on the virtual mission information (for example, In step S104, it is determined whether or not the player X1 has failed in the virtual mission (for example, step S106), and in response to determining that the virtual mission has failed (for example, Y in step S106), Special missions provided to players other than the failed player X1 (eg, video game The rescue server provided to the user terminal 22 by the management server 11 is identified (for example, step S302), and the special mission execution player (for example, rescue mission execution player X2) that is the player who executes the special mission is identified (for example, rescue mission execution player X2). In step S304), it is determined whether the special mission execution player X2 has succeeded in the special mission (for example, step S307), and in response to the determination that the special mission has been successful (for example, Y in step S307), Since a privilege (eg, achievement privilege or success privilege) is given to the mission execution player X2 and the player X1 who failed in the virtual mission (eg, steps S308 and 309), other players are rescued. The fun of the act itself can be improved.

  That is, when a certain player fails a predetermined mission, a rescue request is made to another player (particularly a friend), and when another player undertakes a rescue request, the other player responds to a mission (in response to the rescue request ( For example, if the player who made the rescue request performs a failed mission or another special mission (rescue mission in the above-described embodiment), and the other player succeeds in the mission, both players will be Since it is configured to give a rescue success reward (for example, an achievement privilege or a success privilege), when supporting other players (for example, rescue), it is only necessary to provide game elements such as in-game items as in the past. And the player will perform a special mission that may fail, and as a result, it is possible to improve the interest of the act of rescuing other players. Uninaru. Note that the special mission is not limited to a mission based on the assumption that another player is rescued. For example, the video game processing device is caused by a mission in which a certain player has failed from the middle or a failure of the mission. Any other configuration may be used in which a mission that allows a player to be rescued by giving a certain privilege to a player who has failed in the mission as a special mission, such as making another mission a special mission.

  In the above-described embodiment, the video game processing device identifies the player X1 who has failed in the virtual mission as a rescue-required player (for example, step S301), and notifies the plurality of players of the presence of the rescue-required player. (For example, step S303), a rescue mission execution request is received by one of the players notified of the presence of the rescue-required player (for example, step S304), and a predetermined rule (for example, the same as the failed virtual mission). According to the rule that the virtual mission is a rescue mission), a rescue mission for rescuing a rescue-required player is specified as a special mission (for example, step S302), and a player who satisfies a predetermined rescue mission execution condition according to the rescue mission execution request (For example, a player who has the amount of rescue points necessary to undertake a rescue mission) Since it is configured to be specified as an execution player (for example, rescue mission execution player) (for example, step S304), various rescue missions are specified by a combination of the failed virtual mission and the content of the predetermined rule, and rescue is performed. You will be able to improve the interest of the mission.

  In the above-described embodiment, the video game processing apparatus includes the player information storage unit 16b that stores player information that is information about each of the plurality of players, and is a special mission execution player (for example, rescue mission execution player X2). And a specific rule (for example, a rule for giving a privilege to both players X1 and X2 according to the content of the rescue mission, etc.) according to at least one of the player information of each player who has failed in the virtual mission (for example, rescue player X1 required) ), A 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 identified (for example, steps S105 and S306), and the identified privilege is identified by the player. (E.g., both players X1, X2) -Up S109, S308, S309) since the configuration, will be able to provide a benefit to the side to be rescued not performed rescue mission, it is possible to improve the interest of rescue mission.

  Further, in the above-described embodiment, the video game processing device restricts an operation permitted for the player X1 determined to have failed in the virtual mission (for example, step S107), and a predetermined release condition is satisfied. (For example, step S113), the predetermined release condition includes the use of a game element (for example, a class point), and the privilege (for example, the achievement privilege or the success privilege) includes a game element. Since the game element 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 actions performed for others are evaluated. become.

Although not particularly mentioned in the above-described embodiment, the video game processing device relates 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. It is good also as a structure which adjusts the difficulty of a rescue mission based on various information (failure mission related information) . By adopting such a configuration, it becomes possible to provide difficulty in achieving the special mission, and it becomes possible to strengthen the connection between the rescued player and the rescued player. That is, so-called game sociality can be improved.

  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 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 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.

  The present invention is useful for improving the interest of the act of rescuing 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)

  1. A video game processing device for controlling the progress of a video game in which a plurality of players participate,
    Virtual mission information storage means for storing virtual mission information, which is information relating to the virtual mission that the player is tackling,
    Virtual mission providing means for providing a virtual mission to the player based on the virtual mission information;
    Failure determination means for determining whether or not the player has failed in the virtual mission;
    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 virtual mission being determined to have failed by the failure determination means;
    Special mission execution player specifying means for specifying a special mission execution player which is a player for executing the special mission;
    Success determination means for determining whether or not the special mission execution player has succeeded in the special mission;
    Privilege granting means for granting a privilege to the special mission execution player and the player who failed the virtual mission, in response to the success determination unit determining that the special mission was successful;
    Determining means for determining whether or not a player who has failed in the virtual mission gives up the success of the special mission in response to determining that the special mission is not successful by the success determining means;
    Termination means for executing the process for causing the special mission execution player to recognize that the special mission is completed and terminating the provision of the special mission when it is determined by the determination means that the special mission is to be given up. And a video game processing device.
  2. A rescue player specifying means for specifying a player who has failed in the virtual mission as a rescue player required;
    Informing means for informing the plurality of players of the presence of the rescue required player,
    Rescue execution request accepting means for accepting a rescue execution request by any one of the players notified of the presence of the rescue required player by the notification means,
    The special mission identifying means identifies, as the special mission, a rescue mission to be achieved in order to rescue the rescue required player according to a predetermined rule.
    The video game processing apparatus according to claim 1, wherein the special mission execution player specifying unit specifies a player who satisfies a predetermined rescue execution condition according to the rescue execution request as the special mission execution player.
  3. Player information storage means for storing player information which is information relating to each of the plurality of players;
    According to a specific rule regarding at least one of the player information of each of the special mission execution player and the player who failed the virtual mission, a privilege to be given to at least one of the special mission execution player and the player who failed the virtual mission is specified. Benefits identification means,
    The video game processing device according to claim 1, wherein the privilege granting unit grants the privilege specified by the privilege specifying unit.
  4. Restriction means for restricting an operation permitted for the player determined to have failed in the virtual mission by the failure determination means;
    Release means for releasing the restriction when a predetermined release condition is satisfied,
    The predetermined release condition includes use of a game element,
    The video game processing device according to any one of claims 1 to 3, wherein the bonus may include the game element.
  5. 5. The video game processing according to claim 1, further comprising difficulty level adjustment means for adjusting a difficulty level of the special mission based on failure mission related information that is information related to the failed virtual mission. apparatus.
  6. A video game processing program for causing a computer to realize a function of controlling the progress of a video game in which a plurality of players participate,
    In a computer provided with virtual mission information storage means for storing virtual mission information, which is information relating to a virtual mission that the player works on,
    A virtual mission providing function for providing 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 in the virtual mission;
    A special mission identification function for identifying a special mission provided to a player different from the player who failed the virtual mission in response to determining that the virtual mission has failed;
    A special mission execution player specifying function for specifying a special mission execution player that is a player for executing the special mission;
    A success determination function for determining whether or not the special mission execution player has succeeded in the special mission;
    In response to determining that the special mission has succeeded, a privilege grant function for granting a privilege to the special mission execution player and a player who has failed the virtual mission;
    A determination function for determining whether a player who failed in the virtual mission gives up the success of the special mission in response to determining that the special mission has not been successful;
    In order to realize an end function for executing the processing for causing the special mission execution player to recognize that the special mission is terminated when it is determined to give up the success of the special mission and terminating the provision of the special mission. Video game processing program.
JP2013005738A 2013-01-16 2013-01-16 Video game processing apparatus and video game processing program Active JP5890331B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2013005738A JP5890331B2 (en) 2013-01-16 2013-01-16 Video game processing apparatus and video game processing program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013005738A JP5890331B2 (en) 2013-01-16 2013-01-16 Video game processing apparatus and video game processing program

Publications (2)

Publication Number Publication Date
JP2014136022A JP2014136022A (en) 2014-07-28
JP5890331B2 true JP5890331B2 (en) 2016-03-22

Family

ID=51413883

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013005738A Active JP5890331B2 (en) 2013-01-16 2013-01-16 Video game processing apparatus and video game processing program

Country Status (1)

Country Link
JP (1) JP5890331B2 (en)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5746787B1 (en) 2014-11-28 2015-07-08 グリー株式会社 Game program, game control method, and computer
JP5792406B1 (en) * 2015-01-30 2015-10-14 グリー株式会社 game control method, computer and control program
JP5819559B1 (en) * 2015-05-08 2015-11-24 グリー株式会社 Game program, game control method, and computer
JP6348470B2 (en) * 2015-09-30 2018-06-27 グリー株式会社 Game program, game control method, and computer
JP2017064251A (en) * 2015-10-01 2017-04-06 株式会社コロプラ Game program
JP6621064B2 (en) * 2016-06-02 2019-12-18 グリー株式会社 program
JP2017196538A (en) * 2017-08-15 2017-11-02 グリー株式会社 Program, server control method, and server

Also Published As

Publication number Publication date
JP2014136022A (en) 2014-07-28

Similar Documents

Publication Publication Date Title
JP5457146B2 (en) Server system and item management method
JP5406350B2 (en) Game management device, game system, game management method, and program
US9675891B2 (en) System and method for granting in-game bonuses to a user
US9345959B2 (en) Non-transitory computer-readable record medium, game system and information processing device
US9101828B2 (en) Non-transitory computer-readable storage medium storing game program, and game system
JP5105497B1 (en) Game control device, item lottery method, item lottery program, game system
KR20090122887A (en) Network game system
JP2012176135A (en) Game system, method of controlling the same, game controller, and program
JP2015008985A (en) Computer system and program
JP2004180765A (en) Data delivery system
JP2009119049A (en) Game program, recording medium recorded with game program and game device to which game program is applied
US20130288766A1 (en) Game device, game system, control method, and program
WO2013099334A1 (en) Game management device, game system, game management method, program and recording medium
JP5345728B1 (en) Game system, program, and object
US9272205B2 (en) Non-transitory computer-readable storage medium storing game program, and game system
US9656164B2 (en) Video game processing apparatus and video game processing program
US8821235B2 (en) Non-transitory computer-readable storage medium and server device
JP5436612B2 (en) Game control device, game control method, program, game system
WO2013069361A1 (en) Gaming system, management server, display management method and program
US20160023106A1 (en) Method of controlling a server, server, and non-transitory computer-readable recording medium
JP4445544B2 (en) Video game processor
JP5420044B1 (en) Game management server device and game management server device program
WO2013014928A1 (en) Game control device, point processing method, and point processing program
JP5789007B2 (en) game management device and program
JP5993062B2 (en) Program, information processing apparatus control method, and information processing apparatus

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20141021

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20141217

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20150818

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20151118

A911 Transfer of reconsideration by examiner before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20151126

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160126

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160218

R150 Certificate of patent or registration of utility model

Ref document number: 5890331

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250