U.S. Pat. No. 8,961,287

DETAILED DESCRIPTION OF THE INVENTION

Before describing an embodiment of the present invention, first, a summary of the present invention will be described. The present invention relates to a technique for enhancing the game's strategic element by increasing the number of variations of action taken by a player to succeed in capturing in a game in which an enemy character can be captured.

In putting down or capturing (hereinafter, also referred to as conquering) an enemy character in a conventional game, even if a user has hunted down an enemy character to the brink of conquer, once the battle has ended, even if the user has re-encountered the same enemy character, he/she needs to conquer the enemy character all over again. Therefore, the conquer difficulty level is significantly high for high-rarity enemy characters and characters with lots of hit points, which is one of the factors in reducing the zest for the game.

In addition, a nearly-conquered enemy character is considered to be close to a dead status. However, even if the user has encountered the same enemy character after the battle, since the status of the enemy character has been back to its original one, there may be lots of users feeling a sense of strangeness.

In the present invention, the above-described problems are solved. Since another battle with a re-encountered enemy character starts using a status of the enemy character obtained upon the end of the last battle, the user can play the game while feeling a sense of reality. In addition, since the user is given a chance to re-encounter a missed enemy character, the number of options for conquer to be selected by the user for each battle can be increased. Accordingly, the game's strategic element and the zest for the game can be enhanced.

The present invention will be described below using an example in which the present invention is applied to a network game, particularly, a social game.

Now, a social game will be briefly described. A social game generally refers to application game software that uses a platform such as an API (Application Programming Interface) which operates on a web browser using SNS information, and operates based on the platform. In the following, the social game is simply referred to as a browser game.

Some social games are played such that SNS information is used but an application program is downloaded to each terminal device operated by a user, and the application program is executed in each terminal device, and various types of parameters are transmitted and received between each terminal device and a server device. In the following, such social games are simply referred to as application games.

Note that an example described below is provided to understand the present invention, and thus, the technical scope of the present invention is not limited thereto. The following processes which are an example of the present invention can be processed by a server device that provides a game as a browser game, and can also be processed by a program that is executed on the terminal device side as an application game. In addition, the following processes which are an example of the present invention can also be executed on a stationary game machine and a game machine that does not have a network function.

[First Embodiment]

First, a first embodiment will be described.FIG. 1is a diagram illustrating a social game system100according to the first embodiment of the present invention. The social game system100includes a server device10; a network30that connects the server device10to base stations40by wired lines; a first base station40ato a third base station40cwhich are represented by a base station40; a first mobile terminal50ato a third mobile terminal50cwhich are represented by a mobile terminal50; and a PC terminal70.

Note that although only three base stations40and three mobile terminals50are illustrated for convenience of depiction, the configuration is not limited thereto, and there may be more base stations40and more mobile terminals50. The same also applies to the PC terminal70. Note also that although the drawing illustrates that the first mobile terminals50ato the third mobile terminals50care connected to different base stations40, the configuration is not limited thereto, and even if a plurality of mobile terminals50are connected to one base station40, needless to say, the present invention is applicable.

The server device10is a device for performing and providing social game services. The server device10performs a communication process for game processing with the mobile terminals50or the PC terminal70through the network30and the base stations40. Note that in the following, for simplification of description, such a communication process is simply expressed as, for example, “a communication process is performed between the server device10and the mobile terminals50or the PC terminal70”, and the description “through the network30and the base stations40” is omitted. Note also that in the following the mobile terminals50and the PC terminal70may be collectively represented as user terminals. Note also that the server device10may be a platform that provides services related to a network game, or may be a server that provides an application for a network game.

The server device10manages the start and progress of a game. Upon progress, the server device10selects by lot one event from among a plurality of events. Selection of an event by lot uses a predetermined probability. In addition, the server device10creates a battle screen taking into account user information, information on an enemy character that a user has encountered, etc., and displays the battle screen on the screen of a user terminal.

The user terminal performs a game by accessing the server device10through a communication line. After the start of the game, an owner of the user terminal performs a predetermined input process according to a message, an image, etc., displayed on the screen of the user terminal Thereafter, information about the input process performed by the user is passed to the server device10from the user terminal The server device10performs a process according to the information, and allows the user terminal to display a predetermined image, etc.

FIG. 2is a diagram illustrating an exemplary configuration of the server device10ofFIG. 1. The server device10includes a server communication unit12, a user information managing unit14, an event lottery unit16, a command accepting unit18, a game processing unit20, a capture determining unit22, a screen display control unit24, and a server memory26.

The server communication unit12receives a signal from a user terminal and performs a predetermined demodulation process on the signal and then transmits the demodulated signal to the user information managing unit14, the event lottery unit16, the command accepting unit18, the game processing unit20, the capture determining unit22, and the screen display control unit24.

In addition, the server communication unit12receives an instruction from the game processing unit20or the screen display control unit24and performs a modulation process on predetermined data and then transmits the modulated data to the user terminal. The predetermined data includes, for example, an image related to the game, information on a monster appearing in the game, etc.

Note that, for the modulation and demodulation processes performed by the server communication unit12, conventionally used modulation and demodulation techniques may be used, and it is to be understood by those skilled in the art that even in such a mode the present invention can be applied.

The user information managing unit14manages, in the server memory26, information on users registered in the social game system100. The information on the users includes user identification information, user names, avatar image information, comments inputted by the users. These pieces of information on the users are referred to by the game processing unit20, etc.

The server memory26stores information about a game, in addition to the information on the users. The information about the game includes card information used in the game and includes, for each user, identification information of a game performed, the date and time when the game is performed, the number of times the game is performed, progress status, identification information of items obtained in the game and acquired monsters, and identification information of monsters encountered in the game, etc. These pieces of information are referred to by the game processing unit20, the capture determining unit22, or the screen display control unit24. In addition, the server memory26stores the statuses of enemy characters obtained after processed by the game processing unit20, which will be described later.

The event lottery unit16performs a selection-by-lot process in a predetermined area where the game is performed (hereinafter, referred to as a game area), to select one event from a plurality of events. The events include an encounter event with an enemy character, a treasure finding event where an item or in-game currency is provided, a raid boss event where a boss is defeated in cooperation with another player, a battle event with another player, an event where nothing occurs, etc. Each event is selected according to a lottery probability set for each event.

When an encounter event with an enemy character is selected, the event lottery unit16selects one of enemy characters present in the game area. In this selection, the event lottery unit16accesses the server memory26to set, according to the number of encounters, the probability of selecting by lot an encounter event with each enemy character. Namely, the user is more likely to re-encounter an enemy character that he/she has encountered once.

When an encounter event is selected by lot by the event lottery unit16, the command accepting unit18accepts from the user a command indicating action taken on an encountered enemy character. The commands include an attack command, a capture command, a getaway command, and a special skill command.

The attack command is a command for attacking the encountered enemy character and reducing the hit points of the enemy character. The hit points are an integer value indicating hit points. When the attack command is accepted, the command accepting unit18allows the game processing unit20to perform an attack process. Damage that can be done to a monster in the attack process is determined by the power of a friend character. The power includes, for example, attack strength, defense strength, HP, and speed, and some or all of them may affect the damage done to the enemy character.

The capture command is a command for capturing the encountered enemy character. When the capture command is accepted, the command accepting unit18allows the capture determining unit22to determine whether capture has been succeeded. When capture has been succeeded, the captured enemy character is stored in the server memory26, as a user's friend character, and thereafter the user can use the character as his/her friend character in the game.

The getaway command is a getaway command for getting away from the encountered enemy character, or a command that lets the encountered enemy character get away. When the getaway command is accepted, the command accepting unit18compares a user's character with the enemy character to determine whether the user's character can get away. When the user's character can get away, the encounter event ends. When the user's character cannot get away, the battle continues. On the other hand, when the let-get-away command is accepted, the command accepting unit18unconditionally ends the battle.

The special skill command is a command for the user to use a selectable special skill in the game. Special skills include one that brings an enemy character to a status abnormality, one that recovers the hit points of a character used by the user, etc. Status abnormalities include a poisoned status, a confused status where an enemy character itself attacks him/herself, etc.

These status abnormalities have different degrees of effect, depending on the attribute(s) of the enemy character. When the effect is great, the enemy character is likely to go into a status abnormality. When the effect is small, even if the user uses a special skill to bring the enemy character to a status abnormality, the enemy character may not go into the status abnormality. Note that a status abnormality may probabilistically occur in the enemy character even when an attack command is selected. This probability may be determined by the chemistry between the attribute(s) of the enemy character and the status abnormality.

The game processing unit20accepts a request to start a game that can be performed on the social game system100, from the user terminal through the server communication unit12, and then starts the game. After the start of the game, the game processing unit20accepts from the user an instruction to select a game area. Thereafter, the game processing unit20manages the progress of the game in the accepted game area. In addition, upon the progress of the game, the game processing unit20accesses user information and card management data which are stored in the server memory26, to perform a predetermined process.

The game processing unit20receives the result of selection by lot performed by the event lottery unit16, and notifies the user terminal of information about the result of selection by lot, in synchronization with the screen display control unit24. For example, when an encounter event with an enemy character is selected, the game processing unit20accesses the server memory26to read the parameters of the selected enemy character, and notifies the user terminal of the parameters of the enemy character. Note that when the encounter with the enemy character is a re-encounter, the game processing unit20reads from the server memory26a status of the re-encountered enemy character obtained at a past encounter, and sets the status as the initial status of the re-encountered enemy character.

Note that when the game area is cleared, the game processing unit20clears the status of an enemy character encountered in the game area. Therefore, even if the same enemy character is encountered in a different game area, it is treated as the first encounter.

Note also that the game processing unit20performs a process on the enemy character, based on a command accepted by the command accepting unit18. When the command accepted from the user is an attack command, the game processing unit20reduces the hit points of the enemy character according to attack action, and stores the reduced hit points in the server memory26in association with the user. When the hit points of the enemy character reach 0, the game processing unit20causes the enemy character to disappear. When the user's hit points reach 0, the game processing unit20performs the process of ending the game.

When the command accepting unit18accepts a capture command from the user terminal, the capture determining unit22determines, according to a predetermined capture success rate, whether the capture of the enemy character has been succeeded. When the capture has been succeeded, the user can allow the obtained enemy character to participate in a battle as his/her friend character, or can sell the obtained enemy character, or can use the obtained enemy character as a material for fusion, or can trade off the obtained enemy character.

A higher capture success rate may be determined for fewer hit points of the enemy character. Alternatively, the capture success rate may be calculated using one or more of the elements such as the strengths of a character and a deck (attack strength, defense strength, HP, and speed), the number of encounters with the enemy character, and the number of combos. Note that the combo is a flag that holds by another player attacking the same monster within a fixed period of time after a player attacks the monster.

Alternatively, a higher capture success rate may be set for a re-encounter than that for the first encounter. Alternatively, the capture success rate of the enemy character may be changed according to the status abnormality. In this case, the difference in effect caused by the chemistry between the attribute(s) of the enemy character and the status abnormality may be reflected on the capture success rate. The above-described elements may be set such that the more the conditions are met the higher the capture success rate. The capture success rate may be set by different calculation methods for a normal enemy character and a boss character.

The screen display control unit24performs control to display a predetermined image on the screen of the user terminal, according to the progress of the game or in response to an instruction from the game processing unit20. The screen display control unit24performs control to access the server memory26to read image information of a selected enemy character, transmit the image information to the user terminal, and display the image information on the screen of the user terminal.

FIG. 3is a diagram illustrating an example of a user information table210managed in the server memory26by the user information managing unit14ofFIG. 2. As exemplified in the user information table210ofFIG. 3, the server memory26may have data in table format. Here, the user name may be a user name on the SNS or may be the name of a user set for each game.

The user identification information is a unique code for identifying a user. The level is a user level that sequentially increases based on the number of participations in the game and obtained experience points. The progress status is information indicating how far the game has progressed by each user. The possessed card identification information is various types of card identification information such as character cards that can be used in a battle by the user.

FIG. 4is a diagram illustrating an example of a card information table220managed in the server memory26by the user information managing unit14ofFIG. 2. As exemplified in the card information table220ofFIG. 4, the server memory26may have data in table format as card management data. In the card information table220, the name indicates the name of a card itself or a character shown on the card. The rarity value indicates the degree of the rarity value of the card, and is divided into ranks such that rarity increases step by step, e.g., common, uncommon, rare, and super rare. The initial attack value is the initial attack value of the character in a team battle, and the initial hit point value is the initial value of the hit points of the character in a team battle. Since these values are initial values, the values change every time the character is evolved or reinforced by repeating battles.

FIG. 5is a diagram illustrating an example of a monster information table230managed in the server memory26by the user information managing unit14ofFIG. 2. As illustrated in the monster information table230ofFIG. 5, the server memory26stores, for each monster which is an enemy character, monster information, rarity value, initial attack value, updated hit point value, status information, etc. The updated hit point value is the hit points of the monster updated by the game processing unit20after a battle, and is a value less than or equal to the initial hit point value. The status is “normal”, “poison”, etc., indicating the status of the monster after the battle. After the start of the game, for an enemy character that has not encountered a user's character, the same value as the initial hit point value is set as the updated hit point value, and the status is set to “normal”.

Now, description of the progress of the game will be made usingFIGS. 6 to 8. Note that for easy understanding user terminal's screen displays are used, and the screen displays are generated by the screen display control unit24based on instructions from the event lottery unit16, the command accepting unit18, the game processing unit20, and the capture determining unit22of the server device10, and are displayed on the screen of the user terminal. Note also that although the following embodiment is described assuming that input operations are performed on a touch panel which is the screen of the terminal, operations such as mouse operations may also be performed.

First, the flow of the game will be briefly described. When the user selects “quest” on my page by operating the user terminal, the entire map is displayed. On the entire map, a plurality of game areas are displayed. When the user selects any one of the game areas, a pop-up screen for selecting a character is displayed. After the selection of a character, “quest” starts. After the start of the quest, the character moves forward from the entrance to exit of the game area, according to a player's operation (e.g., pressing the “MOVE” button displayed on the user terminal). In the course of moving forward to the exit, selection of an event by lot is performed by the event lottery unit16ofFIG. 2.

As a result of the selection of an event by lot, the user obtains in-game currency or acquires a recovery item or finds a treasure box or encounters a monster (enemy character) or no event occurs. When an encounter event with an enemy character is selected by lot, a battle with the enemy character starts, and the user selects one command from selectable commands. When a capture command is selected during the battle, capture of the enemy character such as that described above is attempted. After the battle ends, selection of an event by lot is repeated until reaching the exit.

In the game of the present embodiment, there is a possibility of selecting by lot an event where the user re-encounters an enemy character that he/she has met before. In this case, if the hit points of the enemy character have been reduced by damaging the enemy character by attack at the last encounter with the enemy character, then the enemy character at the re-encounter appears, being damaged. Alternatively, if a status abnormality has been caused by a special skill command, then a monster with the status abnormality appears.

When the player encounters a monster having such a status, he/she succeeds in capturing with a higher probability. Note that information indicating that the player has met a monster (damage or a status abnormality given to the monster) is held only while the player is present in the game area. Hence, the player needs to develop a strategy as to whether to attempt to capture a monster that the player has encountered for the first time, or whether to do some damage to such a monster and then challenge to capture the monster next time when the player encounters the monster. In the latter case, although the capture success rate is certainly high, the player takes the risk that the stage may be cleared with no chance for the player to re-encounter the monster, resulting in missing the chance of capturing the damaged monster.

FIG. 6is a diagram illustrating a first screen display example310of the user terminal ofFIG. 1. When the user starts a game (quest) by operating the user terminal, the first screen display example310ofFIG. 6is displayed. The first screen display example310is a screen displayed after the start of the game, and is the entire map showing a stage including a plurality of game areas. In the first screen display example310there are displayed a zoom-in/out button402, a first area404A to a sixth area404F which are represented by an area404, a user's character406, routes408, and an area selection means410.

The area404is a game area displayed in hexagonal form. The number of stars displayed under the hexagon indicates the difficulty level of the area404, and the larger the number of stars, the higher the difficulty level. The user's character406is an image indicating a character operated by the user. As illustrated in the drawing, the user's character406may be displayed superimposed on the area404.

Each route408indicates a route that links a plurality of areas404. The first screen display example310shows that the third area404C, the fourth area404D, and the sixth area404F have routes with the fifth area404E. The routes408indicate those areas404that can be selected by the user. Hence, in the first screen display example310, the first area404A and the second area404B that do not have routes408cannot be selected. A route408is newly created based on the conditions set for each area, e.g., the number of conquered areas, the number of captured monsters, etc. The conditions for this creation become more difficult depending on the difficulty level, i.e., the number of stars, for each area404.

The area selection means410is a pointer indicating a game area that the user is going to select. By moving the pointer, the user can select a game area where a quest is to be performed.

The zoom-in/out button402is a button for zooming in or out the entire map. By the user touching a location where the button is displayed, the entire map is zoomed in or out. When the user touches the zoom-in/out button402on the screen in the first screen display example310, a second screen display example320where a part of the entire map is displayed is displayed.

FIG. 7is a diagram illustrating the second screen display example320of the user terminal ofFIG. 1. The second screen display example320is a screen where a region including the fifth area404E and the sixth area404F which is part of display provided in the first screen display example310is zoomed in. The second screen display example320further includes monster images411. The monster images411are the images of monsters present in the stage shown in the entire map.

The game world of the game of the present embodiment has a plurality of stages, and furthermore, one stage includes a plurality of game areas. Not all of the game areas are selectable from the start, and the number of selectable game areas gradually increases according to the progress of the game by the player. Specifically, when the player clears the area404F the area404E appears, and when the player clears the area404E the area404C appears. Here, the area404D is a hidden area and is configured not to be able to be selected only by clearing the area404E. To release the area404D, a predetermined condition needs to be satisfied. In the present embodiment, the condition is that the number of types of captured monsters is greater than or equal to a predetermined number. For example, if the number of all types of monsters present in a certain stage is10, then when the player has succeeded in capturing8or more types of monsters, the area404D is released.

FIG. 8is a diagram illustrating a third screen display example330of the user terminal ofFIG. 1. The third screen display example330is a screen displayed when the player encounters a monster while performing a quest, and includes a progress meter412, an already-encountered monster image414, an already-encountered monster status meter416, a battle message418, an avatar image420, a user's character status meter422, a monster image424, a capture difficulty level426, an enemy monster status meter428, a monster message430, and a first command button432A to a third command button432C which are represented by a command button432.

The progress meter412is a meter indicating the degree of the progress of the quest. The already-encountered monster image414is the image of an enemy character that the user has encountered in the same quest. The already-encountered monster status meter416is a meter indicating the hit points of the enemy character obtained after battling with the enemy character that the user has encountered. When the user re-encounters this enemy character, a battle starts using the hit points indicated by the already-encountered monster status meter416.

The battle message418is a message displayed when a battle starts. The avatar image420is the image of a character operated by the user in the game. The user's character status meter422is a meter indicating the hit points of the character operated by the user in the game.

The monster image424is the image of an encountered enemy character. The capture difficulty level426indicates the capture difficult level of the enemy character. The larger the number of solid stars, the higher the difficulty level. The enemy monster status meter428is a meter indicating the hit points of the enemy character. The monster message430is a message from the encountered enemy character.

The command buttons432are buttons for selecting commands that can be selected by the user. In the third screen display example330, the first command button432A is a button for an attack command for attacking the enemy character. The second command button432B is a button for a capture command for capturing the enemy character. The third command button432C is a button for a getaway command.

In the third screen display example330, since the user's character is superior to the enemy character, the third command button432C is displayed as “let it get away”. In the opposite case, the third command button432C is displayed as “get away”. In addition, the third command button432C can also be a button for exercising a special skill command instead of a getaway command. In this case, the third command button432C may display a name indicating a special skill, e.g., “poison”, “charm”, “sleep”, etc.

Next, a configuration of the user terminal side will be described usingFIG. 9.FIG. 9is a diagram illustrating an exemplary configuration of the mobile terminal50or the PC terminal70ofFIG. 1. Here, although, for convenience of description, a configuration of the mobile terminal50is described, the PC terminal70also has the same configuration.

The mobile terminal50includes a terminal communication unit52, a terminal control unit54, a user interface56, and a terminal memory58. The terminal communication unit52receives an application downloaded from the server device10and various types of information transmitted from the server device10.

The terminal control unit54accepts an instruction from the user through the user interface56, and performs application install control, social game execution control, etc., while accessing the terminal memory58.

The user interface56includes a screen interface for displaying a message to the user and various types of screens such as a battle screen; an input interface that accepts an input from the user, such as a keyboard or a touch panel; and an image capturing means such as a camera.

The user interface56accepts, from the user, selection of a quest or selection of a command, or an input of various types of comments, an action button operation, etc., and passes it to the terminal control unit54.

The terminal memory58is used to store, when an application game is downloaded from an application provision platform, an application program of the application game. In addition, in a browser game, too, the terminal memory58is used as a cache memory or used to temporarily save image data, etc.

FIG. 10is a sequence diagram illustrating a processing procedure example of the social game system100ofFIG. 1. The sequence diagram may be performed triggered by the start of the game.

First, when the mobile terminal50makes a quest start request (S10), the request is notified to the server device10, by which a quest starts. When the quest starts, the server device10performs selection of an event by lot (S12), and performs a process for displaying a quest screen on the mobile terminal50and notifies the mobile terminal50of data on the event selected by lot (S14), and then the quest progresses on the mobile terminal50(S16). When an encounter event is selected as a result of the selection by lot, an enemy character is displayed as a monster on the screen of the mobile terminal50(S18).

Here, when the user selects a command through the user interface56of the mobile terminal50, the command is notified to the server device10(S20). The server device10performs a determination process for the notified command (S22), and notifies the mobile terminal50of the result of the process (S24). In the determination process, in the case of an attack command, the amount of hit points to be taken away from the enemy character is determined, and in the case of a capture command, it is determined whether capture has been succeeded.

FIG. 11is a flowchart illustrating a first processing procedure example of the event lottery unit16ofFIG. 2. The flowchart may start triggered by the start of a quest. Note that in the drawing LP indicates “remaining life points”, lp indicates “life points consumed per progress”, EXP indicates “experience value required before the next level”, exp indicates “experience value obtained per progress”, PG indicates the degree of the progress of the quest with 100% being a MAX value, and pg indicates “the degree of progress (%) that increases per progress”.

The event lottery unit16compares the life points (LP) with the points required to perform selection of an event by lot (S30). If the life points are insufficient (NO at S30), the event lottery unit16ends the process. If the life points are sufficient (YES at S30), the event lottery unit16performs an experience value determination (S32). In the experience value determination, the event lottery unit16determines whether the experience value required before the next level is 0 or less, i.e., whether level-up can be done.

If it is determined that level-up can be done (YES at S32), the event lottery unit16ends the process. If it is determined that level-up cannot be done (NO at S32), the event lottery unit16performs a mission clear determination (S34). In the mission clear determination, the event lottery unit16determines whether a mission is cleared, i.e., whether the player has reached the goal point of the quest.

If it is determined that a mission is cleared (YES at S34), the event lottery unit16ends the process. If it is determined that a mission is not cleared (NO at S34), the event lottery unit16performs selection of an event by lot and stores the result thereof (S36). If an encounter event with a monster is selected in the selection of an event by lot (YES at S38), the event lottery unit16ends the process. In this case, of the events selected by lot, an encounter event with a monster is the last event taken place. Upon an encounter event with a monster, there is a need to accept command selection from the player and transmit a selected command to the server device10, and thus, it is preferred that, as described above, an encounter event with a monster be the last one of the events selected by lot. If an event other than an encounter event is selected (NO at S38), the event lottery unit16updates LP, EXP, and PG (S40) and returns to the process at S30.

Note that in the above-described processing procedure example, when an encounter event with a monster is selected by lot, the selection-by-lot process ends; however, the selection-by-lot process may end when an event other than an encounter event is selected by lot. For example, when an event where a treasure box is found is selected by lot, the selection-by-lot process may end. This is because when a treasure box is found, a flash movie or a treasure box obtaining status is displayed, and thus, there is a need to perform communication between the server device10and the mobile terminal50.

FIG. 12is a flowchart illustrating a second processing procedure example of the event lottery unit16ofFIG. 2. The flowchart may be performed when the event lottery unit16performs a selection-by-lot process.

First, the event lottery unit16sets, for each event, a probability for selecting by lot one event from among a plurality of events (S50). Then, the event lottery unit16performs a selection-by-lot process based on the set probabilities (S52). If an event other than an encounter event is selected as a result of the selection by lot (No at S54), the event lottery unit16ends the process.

If an encounter event is selected (Yes at S54), the event lottery unit16selects an enemy character to be encountered. If the encounter with the selected enemy character is the first encounter (No at S56), the event lottery unit16moves to the process at S60. If the encounter is a re-encounter (Yes at S56), the event lottery unit16sets, as an initial value, the latest status of the enemy character obtained upon the end of the last battle (S58), and moves to the process at S60.

Then, the event lottery unit16sets the capture rate for the encountered enemy character (S60), and waits for a command for starting a battle to be notified from the user, and then performs a battle process (S62). Note that the processes at S60and S62do not need to be included in the selection-by-lot process. In that case, when an encounter event with an enemy character takes place on the mobile terminal side and the selection of “capture” is received as a player's command selection, the game processing unit20may compute the capture rate and perform a battle process. When the selection of “battle” is received as a player's command selection, the game processing unit20may perform a battle process without computing the capture rate.

Variants of the first embodiment will be described below.

Although in the above-described embodiment it is premised that one character is operated, the configuration is not limited thereto, and a plurality of, e.g., four, characters may be operated. In this case, it may be configured such that the characters can be equipped with up to three monsters captured in the past, as their friend characters.

When, though the user has encountered an enemy character, the user has not been able to defeat the enemy character or the user has failed in capturing the enemy character and thus missed the enemy character, the user can transmit information on the finding of the enemy character to another player (player's friend, etc.). In this transmission, another player may be notified through the game processing unit20of the server device10, by the user selecting a share command. The player having received the information on the finding of a monster can easily encounter the monster, enabling to increase the chance of capturing the monster.

At this time, the game processing unit20may perform control such that the friend player having received the information on the finding of a monster can encounter, under the condition of within a predetermined period of time, the monster whose status is the one obtained at the time of being missed by the player providing the information. Then, when the friend player has succeeded in capturing the monster, the friend player can acquire the monster, and also the game processing unit20may provide the player providing the information with some kind of reward (in-game currency, an item, a monster captured by the friend player, etc.).

The capture determining unit22may perform setting such that the probability of an encounter with a monster or the capture success rate of a monster changes depending on the character going on to a quest. These probabilities may change depending on the chemistry between a character and a monster.

Upon capturing a monster, the user may use a capture material. A capture material may have ranks (capture material (N), capture material (R), etc.) and may be selected by the user following the selection of a capture command. The capture determining unit22may perform setting such that the capture success rate changes depending on the rank of a capture material used to capture a monster.

In addition, the game processing unit20may allow a plurality of monsters to appear. When the user attempts to capture a plurality of monsters, he/she may succeed in capturing the plurality of monsters.

In addition, the game processing unit20may extend a quest even if a predetermined game area is cleared. For example, a quest extension item is allowed to appear in the game, and a quest is extended by the user using the quest extension item. The quest extension item is available by, for example, defeating an enemy character in a battle, or performing a quest, or purchasing it at a shop using in-game currency. When a game area is cleared, the status of an enemy character encountered in the game area is also cleared. Therefore, when there is an enemy character hunted down in the game area, by the user extending the quest, he/she can get an opportunity to capture the enemy character in a more advantageous state.

When the player uses a quest extension item, the quest is extended by reducing the degree of the progress of the quest by, for example, reducing the degree of the progress of the quest (PG) or pg by half. The quest extension item may be allowed to be used immediately after the game area is cleared (i.e., immediately after PG reaches 100%), or during a period during which the quest is performed and which is before clearing the game area (when PG is less than 100%).

Note that some or all of the above-described processes performed by the server device10may be performed by the user terminal.

The present invention has been described above based on the embodiment. The present invention is not limited to the above-described embodiment and the content of each embodiment, and may be performed by making various modifications therein without departing from the spirit and scope of the present invention. It will be understood by those skilled in the art that the above-described embodiment is illustrative, and thus, various variants may be made by combining the components or processing processes of the embodiment, and such variants also fall within the spirit and scope of the present invention.