JP2017018679A - Computer, control method, and control program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a server device capable of preventing a user from diminishing eagerness for continuation of a game by means of supporting a progress of a game according to a game progress situation.SOLUTION: A server device 3 progresses a game, while executing communication with terminals 2. The server device 3 includes: a first display data creation part that, when a first event occurs during progress of a game, decreases a parameter value of a game object and creates first display data corresponding thereto; a number-of-event-occurrences counting part for counting the number of occurrences of a first event; a processing part that sets a winning probability of an occurrence of a second event on the basis of the number of occurrences of the first event and the parameter value, and determines occurrence/non-occurrence of the second event on the basis of a lottery according to the winning probability; a second display data creation part that, when the occurrence of the second event is determined, decreases the parameter value, and creates second display data corresponding thereto; and a transmission part for transmitting the first display data and the second display data to the terminals 2.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a game server device, a server control method, and a server control program.

  In recent years, server devices that provide games via a network have become widespread. Some games provided by such a server device can be participated by a plurality of users (so-called “social games”), and other users can communicate with each other in addition to battles and cooperation. (For example, see Patent Document 1).

  However, since the difficulty level of the game generally increases as the game progresses (for example, stronger enemies appear as the game progresses), even if the users cooperate with each other, the game progresses over time. It becomes difficult (for example, an enemy whose strength exceeds the attack power of the user and the cooperating user appears and cannot win), and the user's willingness to continue the game may be reduced.

JP 2005-034303 A

  The present invention has been made to solve such a conventional problem, and an object of the present invention is to provide a server device that can prevent a user's willingness to continue playing a game.

  The server device according to the present invention is a server device that progresses a game that changes a parameter value of a game target while communicating with a terminal. When a first event occurs during the progress of the game, the parameter value is A first display data creation unit that creates a first display data corresponding to the first event, and an event occurrence number counting unit that counts the number of occurrences of the first event; A processing unit that sets a winning probability of occurrence of the second event based on the number of occurrences of the first event and the parameter value, and determines whether or not the second event occurs based on a lottery according to the winning probability; A second table for reducing the parameter value by a second predetermined value and generating second display data corresponding to the second event when the processing unit determines the occurrence of the second event. It has a data generation unit, a transmission unit for transmitting the first display data and second display data to the terminal.

  The server device according to the present invention further includes a user number counting unit that counts the number of users participating in the game other than the user of the terminal, and the processing unit includes the number of occurrences of the first event, the parameter value, and It is preferable to set the winning probability of occurrence of the second event based on the number of users.

  The server control method according to the present invention is a server control method for controlling a server device that progresses a game that changes a parameter value of a game target while communicating with a terminal, and the server device is in progress of a game. When the first event occurs, the parameter value is decreased by the first predetermined value, the first display data corresponding to the first event is created, the number of occurrences of the first event is counted, A winning probability of occurrence of the second event is set based on the number of occurrences of the first event and the parameter value, and the presence / absence of occurrence of the second event is determined based on the lottery corresponding to the winning probability, When the occurrence of the event is determined, the parameter value is decreased by the second predetermined value, and the second display data corresponding to the second event is generated, and the first display data and It transmits the second display data to the terminal, comprising.

  A server control program according to the present invention is a server control program for controlling a server device that progresses a game that changes a parameter value of a game object while communicating with a terminal. When the first event occurs during the progress of the process, the parameter value is decreased by the first predetermined value, the first display data corresponding to the first event is created, and the number of occurrences of the first event is determined. Count, set the winning probability of occurrence of the second event based on the number of occurrences of the first event and the parameter value, and determine whether the second event has occurred based on the lottery according to the winning probability When the occurrence of the second event is determined, the parameter value is decreased by a second predetermined value, and second display data corresponding to the second event is created. Transmitting the first display data and second display data to the terminal, to execute the.

  The server device according to the present invention determines whether or not the second event has occurred based on the number of occurrences of the first event corresponding to the progress of the game and the parameter value of the game target, thereby continuing the user's game. It is possible to prevent a decrease in motivation and keep attracting users to the game.

1 is a schematic configuration diagram of a game system according to a first embodiment. It is a functional block diagram of the process part of a server apparatus. It is an operation | movement flowchart of the system for games. It is an operation | movement flowchart of the system for games. It is a schematic diagram which shows an example of the display screen of a terminal. It is a schematic diagram which shows an example of the display screen of a terminal. It is a functional block diagram of the process part of the server apparatus by 2nd Embodiment. It is an operation | movement flowchart of the system for games. It is a schematic block diagram of the game terminal by 3rd Embodiment.

  Hereinafter, various embodiments of the present invention will be described with reference to the drawings. However, it should be noted that the technical scope of the present invention is not limited to these embodiments, and extends to the invention described in the claims and equivalents thereof.

(First embodiment)
The server device according to the present embodiment advances the game while communicating with the terminal, and transmits display data relating to the progress of the game to the terminal. The terminal requests the server device for the progress of the game in accordance with an instruction from the user, receives display data related to the progress of the game from the server device, and performs display.

  In the present embodiment, the game progressed by the server device is a so-called card battle game using card data. In a card battle game, a user performs a battle (first event) using card data and an enemy (game target) that appears as the game progresses and is prepared on the game program. The user can possess any number of card data. The card data has parameters such as level, attack power, defense power and physical strength, and damages the enemy according to the parameters. The enemy also has status data having the same parameters as the card data, and damages the card data according to the parameters. As a result of mutual damage, when the health parameter of the card data becomes 0 or when the enemy's health parameter becomes 0, the battle is temporarily ended.

  While the game by the server device is in progress, an enemy appears at a predetermined timing. When an enemy appears, the user can perform battles as many times as possible until the enemy's health parameter becomes zero. If the enemy's health parameter does not become 0 even after a predetermined number of battles, a special battle (second event, hereinafter referred to as “support battle”) is performed according to a predetermined probability, and the enemy's health parameter is Reduced by a predetermined amount. In this way, a support battle is performed according to a predetermined probability according to the progress of the battle, and the enemy's physical strength parameter is reduced by a predetermined amount, thereby increasing the user's expectation for the progress of the battle and continuing the user's game. Try to prevent a decline in motivation.

  FIG. 1 is a schematic configuration diagram of a game system.

  As shown in FIG. 1, the game system 1 includes at least one terminal 2 and a server device 3. The terminal 2 and the server device 3 are connected to each other via a communication network such as a public communication line or a wireless communication line. For example, the terminal 2 and the server apparatus 3 are mutually connected via the base station 4, the mobile phone network 5, the gateway 6, and the Internet 7. Connected. A program (for example, a browsing program) executed on the terminal 2 and a program (for example, a game program) executed on the server device 3 use a communication protocol such as a hypertext transfer protocol (HTTP). Communicate.

  The terminal 2 requests the server device 3 to advance the game by operating the operation unit 24 (button or the like) by the user. The terminal 2 receives display data related to the progress of the game from the server device 3 and displays the display data. For this purpose, the terminal 2 includes a communication unit 21, a storage unit 22, a processing unit 23, an operation unit 24, and a display unit 25.

  The communication unit 21 includes a communication interface circuit for connecting the terminal 2 to the mobile communication network 5. The communication unit 21 passes data received from the server device 3 via the Internet 7 and the mobile phone network 5 to the processing unit 23. In addition, the data received from the processing unit 23 is transmitted to the server device 3 via the mobile phone network 5 and the Internet 7.

  The storage unit 22 includes, for example, at least one of a semiconductor memory, a magnetic disk device, and an optical disk device. The storage unit 22 stores various programs and data used for controlling the terminal 2. The storage unit 22 stores, for example, an identification number (ID) of the terminal 2, user authentication data, display data related to the progress of the game received from the server device 3, a program for performing display based on the display data, and the like. To do. Furthermore, the storage unit 22 may temporarily store temporary data related to a predetermined process.

  The processing unit 23 has one or a plurality of processors and their peripheral circuits. The processing unit 23 performs display based on display data relating to the progress of the game received from the server device 3.

  The operation unit 24 may be any device that can operate the terminal 2, for example, a touch pad, a keyboard, or the like. The display unit 25 may be any device that can display a game screen, such as a liquid crystal display or an organic EL display.

  The server device 3 advances the game in response to a request from the terminal 2. Also, when an enemy appears while the game is in progress, a battle and a support battle are performed. For this purpose, the server device 3 includes a communication unit 31, a storage unit 32, and a processing unit 33.

  The communication unit 31 includes a communication interface circuit for connecting the server device 3 to the Internet 7. The communication unit 31 passes data received from the terminal 2 via the mobile phone network 5 and the Internet 7 to the processing unit 33. The data received from the processing unit 33 is transmitted to the terminal 2 via the Internet 7 and the mobile phone network 5.

  The storage unit 32 includes, for example, at least one of a semiconductor memory, a magnetic disk device, and an optical disk device. The storage unit 32 stores various programs and data used for controlling the server device 3. The memory | storage part 32 memorize | stores the program for advancing a game and outputting the display data which concerns, for example. The storage unit 32 also stores a program for performing a battle and a support battle when an enemy appears while the game is in progress. The storage unit 32 stores the ID of the terminal 2. The storage unit 32 also includes the user name, user ID, authentication data, attributes, possessed card data, enemy ID indicating the enemy who is executing the battle, status data of the enemy, and execution of battle with the enemy. A battle execution count counter indicating the number of times, a support battle execution flag indicating whether or not a support battle is executed with the enemy, and the like (hereinafter referred to as “user management table”) are also stored. Furthermore, the storage unit 32 may temporarily store temporary data related to a predetermined process.

  The processing unit 33 includes one or a plurality of processors and their peripheral circuits. The processing unit 33 performs a process of progressing the game and outputting display data related to the game. Also, when an enemy appears while the game is in progress, a battle and a support battle are performed.

  FIG. 2 is a functional block diagram of the processing unit 33 of the server device 3.

  The processing unit 33 includes a control unit 331, a support battle execution determination unit 332, a battle execution unit 333, and a support battle execution unit 334. Each of these units included in the processing unit 33 is a functional module implemented by a computer program executed on a processor included in the processing unit 33. Or these each part which the process part 33 has may be mounted in the server apparatus 3 as firmware.

  After a user authentication unit (not shown) authenticates the user of the terminal 2, the control unit 331 advances the game according to a program when the terminal 2 requests the start of the game. In addition, the control unit 331 causes an enemy to appear as the game progresses. When an enemy appears, the control unit 331 creates display data related to a screen for receiving an instruction from the user, transmits the display data to the terminal 2 via the communication unit 31, and causes the screen to be displayed. An instruction is received from the user, and the instruction data is returned to the control unit 331.

  When the instruction from the user is execution of the battle, the control unit 331 checks the battle execution number counter stored in the storage unit 32, and when the value is a predetermined value (for example, once), The control unit 331 instructs the support battle execution determination unit 332 to execute the process.

  The support battle execution determination unit 332 determines whether to perform a support battle according to a predetermined probability. That is, the winning probability of the support battle is set based on the progress of the battle, and it is determined whether or not to perform the support battle by performing a lottery according to the winning probability.

The winning probability is set to be higher as the battle progress is worse. For example, the winning probability is set to be higher as the remaining amount of the enemy physical strength parameter stored in the storage unit 32 is larger. When the remaining amount of the enemy's physical strength parameter is a variable, the winning probability can be calculated by the following mathematical formula, for example.
P = (R / T) / 10 (Formula 1)
Here, P is the winning probability, R is the remaining amount of enemy health parameters, and T is the total amount of enemy health parameters. For example, when R is 90 and T is 100, P is
P = (90/100) /10=0.09
And can be calculated.

  After setting the winning probability, the support battle execution determination unit 332 performs a lottery according to the winning probability. For example, a lottery is performed by determining a numerical range corresponding to the winning probability in advance and determining whether a pseudo-random number generated using the current time or the like as a seed belongs to the numerical range. When the lottery is won, the support battle execution determination unit 332 sets the support battle execution flag stored in the storage unit 32 to ON, and then ends the process.

  The control unit 331 instructs the battle execution unit 333 to execute the process.

  The battle execution unit 333 performs a battle using card data stored in the storage unit 32 and associated with the user. For example, the enemy is damaged according to the attack power parameter of the card data. Similarly, the card data is damaged according to the enemy's attack power parameter. Card health parameters are initialized (set to the maximum value) each time a battle is executed, while enemy health parameters are not initialized, and the values after the previous battle are maintained. Shall be. When the card data and the enemy's physical strength parameter become 0, the battle execution unit 333 adds 1 to the battle execution count counter stored in the storage unit 32, and shows a battle execution status The display data is generated, and the display data is transmitted to the terminal 2 via the communication unit 31 to display the screen. Then, the process ends.

  The control unit 331 confirms the remaining amount of the enemy's physical strength parameter stored in the storage unit 32. If the remaining amount is 0, the control unit 331 determines that the enemy has been defeated, and the game progresses in a normal state ( Return to the state where no enemy appears. On the other hand, when the remaining amount is not 0 (that is, the physical strength parameter of the card data is 0), the control unit 331 determines that the enemy has lost, and the support battle execution flag stored in the storage unit 32 Confirm. When the support battle execution flag is on, the control unit 331 instructs the support battle execution unit 334 to execute the process.

  The support battle execution unit 334 reduces the enemy's physical strength parameter stored in the storage unit 32 by a predetermined amount as execution of the support battle. For example, a certain ratio to the remaining amount of enemy health parameters is reduced. Further, the amount to be reduced may be changed according to a predetermined probability. The amount to be reduced is preferably smaller than the remaining amount of the enemy's physical strength parameter in consideration of the progress of the game / battle. The support battle execution unit 334 sets the support battle execution flag to OFF, creates display data related to the screen for indicating the execution status of the support battle, and transmits the display data to the terminal 2 via the communication unit 31. After displaying the screen, the process is terminated.

  FIG. 3 is an operation flowchart of the game system 1. The operation flow described below is executed mainly by the processing units 23 and 33 in cooperation with the elements of the terminal 2 and the server device 3 based on the programs stored in the storage units 22 and 32 in advance. The

  The processing unit 23 transmits user authentication data to the server device 3 via the communication unit 21 (step S301).

  When receiving the user authentication data from the terminal 2, the processing unit 33 instructs the user authentication unit (not shown) to execute the process (step S302).

  When the user is authenticated by the user authentication unit, the processing unit 33 creates display data related to a screen for receiving an instruction from the user, and transmits the display data to the terminal 2 via the communication unit 31 (step S303). ).

  When receiving display data related to a screen for receiving an instruction from the user from the server device 3, the processing unit 23 displays the screen on the display unit 25 based on the display data, and prompts the input of the instruction (step S304). .

  FIG. 5 is a schematic diagram illustrating an example of the display screen of the terminal 2.

  FIG. 5A shows a display screen 501 before the game is started. Four buttons are displayed in the lower part of the display screen 501, and when the “story” button 502 is pressed, the server apparatus 3 is requested to start the game.

  Returning to FIG. 3, when an instruction to start a game is input from the user via the operation unit 24, the processing unit 23 transmits the instruction data to the server device 3 via the communication unit 21 (step S305).

  When the game start instruction data is received from the terminal 2, the control unit 331 advances the game and causes an enemy to appear according to the progress of the game (step S306).

  When an enemy appears, the control unit 331 initializes a battle execution number counter and a support battle execution flag stored in the storage unit 32 (step S307). That is, the battle execution number counter is set to 0, and the support battle execution flag is set to OFF.

  And the control part 331 produces | generates the display data which concern on the screen for receiving an instruction | indication from a user, and transmits the display data to the terminal 2 via the communication part 31 (step S308).

  When receiving display data related to a screen for receiving an instruction from the user from the server device 3, the processing unit 23 displays the screen on the display unit 25 based on the display data and prompts the input of the instruction (step S309). .

  FIG. 5B shows a display screen 503 when an enemy appears. An enemy 504 that appears is displayed in the upper part of the display screen 503, and three buttons are displayed in the lower part. When the “battle” button 505 is pressed, the server apparatus 3 is requested to execute the battle, and when the “escape” button 507 is pressed, the server apparatus 3 is requested to avoid the battle.

  Returning to FIG. 3, when an instruction is input from the user via the operation unit 24, the processing unit 23 transmits the instruction data to the server device 3 via the communication unit 21 (step S <b> 310).

  When the instruction indicated by the instruction data received from the terminal 2 is a battle avoidance (step S311-No), the control unit 331 enters a process for returning the progress of the game to a normal state (step S320).

  On the other hand, when the instruction is execution of a battle (step S311-Yes), the control unit 331 checks the battle execution number counter stored in the storage unit 32, and when the value is not a predetermined value ( In step S312-No), the control unit 331 determines that the execution of the support battle is unnecessary, and instructs the battle execution unit 333 to execute the process (step S314).

  On the other hand, when the value is a predetermined value (step S312—Yes), the control unit 331 instructs the support battle execution determination unit 332 to execute the process (step S313).

  FIG. 4A is an operation flowchart of the support battle execution determination unit 332.

  The support battle execution determination unit 332 sets the winning probability of support battle based on the progress of the battle (step S401).

  And the support battle execution determination part 332 performs the lottery according to the winning probability (step S402).

  When the lottery is won (step S403-Yes), the support battle execution determination unit 332 sets the support battle execution flag stored in the storage unit 32 to on (step S404).

  Then, the support battle execution determination unit 332 ends the process.

  Returning to FIG. 3, the control unit 331 instructs the battle execution unit 334 to execute the process (step S314).

  FIG. 4B is an operation flowchart of the battle execution unit 333.

  The battle execution unit 333 performs a battle using the card data stored in the storage unit 32 and associated with the user (step S405). For example, the enemy's physical strength parameter stored in the storage unit 32 is reduced by a predetermined amount according to the attack power parameter of the card data.

  After the battle is over, the battle execution unit 333 adds 1 to the battle execution number counter stored in the storage unit 32 (step S406).

  Moreover, the battle execution part 333 produces the display data which concern on the screen for showing the execution condition of a battle, and transmits the display data to the terminal 2 via the communication part 31 (step S407).

  And the battle execution part 333 complete | finishes a process.

  Returning to FIG. 3, when display data related to the screen for indicating the execution status of the battle is received from the server device 3, the processing unit 23 performs screen display on the display unit 25 based on the display data (step S <b> 315). .

  FIG. 5C shows a display screen 508 during the execution of the battle. An enemy 504 is displayed at the upper center of the display screen 508, and an enemy's physical strength parameter 509 is displayed thereon. In the lower row, card data 512 associated with the user is displayed. Each card data and the enemy attack each other alternately, and the effect that the battle progresses is displayed by damaging each other.

  Returning to FIG. 3, the control unit 331 confirms the remaining amount of the enemy's physical strength parameter stored in the storage unit 32, and if the remaining amount is 0 (Yes in step S <b> 316), it is assumed that the enemy has been defeated. A determination is made and processing for returning the progress of the game to a normal state is entered (step S320).

  On the other hand, if the remaining amount is not 0 (step S316-No), the control unit 331 determines that the enemy has lost, and checks the support battle execution flag stored in the storage unit 32. When the support battle execution flag is off (step S317-No), the control unit 331 determines that the execution of the support battle is unnecessary, and returns the control after initialization of the battle execution number counter or the like.

  On the other hand, when the support battle execution flag is on (step S317-Yes), the control unit 331 instructs the support battle execution unit 334 to execute the process.

  FIG. 4C is an operation flowchart of the support battle execution unit 334.

  The support battle execution unit 334 reduces the enemy physical strength parameter stored in the storage unit 32 by a predetermined amount as the support battle is executed (step S408).

  After the support battle ends, the support battle execution unit 334 sets the support battle execution flag to off (step S409).

  In addition, the support battle execution unit 334 creates display data related to a screen for indicating the execution status of the support battle, and transmits the display data to the terminal 2 via the communication unit 31 (step S410).

  Then, the support battle execution unit 334 ends the process.

  Returning to FIG. 3, when receiving display data related to the screen for indicating the execution result of the battle and the execution status of the support battle from the server device 3, the processing unit 23 displays the screen on the display unit 25 based on the display data. Is performed (step S319).

  FIG. 6A shows a display screen 601 when the enemy is defeated, and FIG. 6B displayed next shows a display screen 602 during the execution of the support battle. The enemy 504 is displayed on the right side of the display screen 602, and the physical strength parameter 509 of the enemy 504 is displayed thereon. Also, on the left side, the card data 603 is displayed formally, and an effect that the card data 603 attacks the enemy and causes damage is displayed.

  Returning to FIG. 3, the control unit 331 returns the control after initialization of the battle execution counter and the like.

  On the other hand, when a battle is avoided (step S311-No) or when an enemy is defeated (step S316-Yes), the control unit 331 enters a process for returning the game progress to a normal state. That is, the control unit 331 creates display data relating to a screen for indicating the execution result of the battle (only when the enemy is defeated) and a screen for receiving an instruction from the user, and the display data is transmitted via the communication unit 31. To the terminal 2 (step S320).

  When receiving display data relating to a screen for showing the execution result of the battle and a screen for receiving an instruction from the user from the server device 3, the processing unit 23 performs screen display on the display unit 25 based on the display data. (Step S321).

  FIG. 6C shows a display screen 604 when the enemy is defeated, and FIG. 6D displayed next shows a display screen 605 after the battle is over. Two buttons are displayed in the lower part of the display screen 605. When the “Yes” button 606 is pressed, the server device 3 is requested to continue the game. When the “No” button 607 is pressed, the game is ended. Required for device 3.

  Returning to FIG. 3, when an instruction is input from the user via the operation unit 24, the processing unit 23 transmits the instruction data to the server device 3 via the communication unit 21 (step S <b> 322).

  When the instruction indicated by the instruction data received from the terminal 2 is a continuation of the game (step S323-No), the control unit 331 receives the game start instruction data to return the game progress to a normal state. Return control.

  On the other hand, if the instruction is to end the game (step S323-Yes), the game is ended.

As described above, by setting the winning probability of occurrence of the second event (support battle) based on the number of occurrences of the first event (battle) and the parameter value of the game target (physical strength parameter of the enemy) It is possible to make the progress of the battle advantageous to the user. Thereby, it becomes possible to prevent the user's willingness to continue the game from decreasing.
For example, even if a predetermined number of battles are performed, if the remaining amount of the enemy's physical strength parameters is large, increasing the winning probability of occurrence of the support battle makes it easier for the user to generate a support battle in a situation where the user is likely to lose, The possibility that the user can defeat the enemy can be improved. Further, when a support battle occurs, the possibility that the user can defeat the enemy can be further improved by reducing the enemy's physical strength parameter by a predetermined amount (for example, halving the remaining amount). Thereby, it becomes possible to improve a user's willingness to rejoin a battle, and it is possible to prevent a decrease in the user's willingness to continue the game.

  Note that, according to the modification, the control unit 331 may use an arbitrary number of executions as the number of executions required for determining whether or not the support battle is executed. Furthermore, once the number of times is exceeded, the presence / absence determination may be performed each time the battle is executed until the support battle is won.

  Further, the support battle execution determination unit 332 may calculate the winning probability of the support battle based on the remaining amount of the physical strength parameter in the future (after execution of the battle), not the remaining amount of the current physical strength parameter of the enemy. . This is because in the present embodiment, the support battle is performed after the execution of the battle. In addition, since the amount of damage given to the enemy by the execution of the battle is uniquely determined by parameters such as the attack power of the card data, the remaining amount of the physical strength parameter after the execution of the battle is determined before the execution of the battle It is possible.

  In addition, when the support battle is not won even if the lottery is performed a predetermined number of times, the support battle execution determination unit 332 may adjust the win probability of the support battle. Alternatively, the support battle execution unit 334 may change the amount by which the enemy's physical strength parameter is reduced.

  Moreover, the battle execution part 333 performs only a battle execution, and the terminal 2 may perform the production | generation of the display data which concern on the screen for showing the execution condition of a battle. In this case, the battle execution unit 333 may transmit data required for creating display data (for example, enemy physical strength parameters before and after the battle execution) to the terminal 2 via the communication unit 31. The same applies to the support battle execution unit 334.

  The control unit 331 may limit the number of battle executions. For example, a parameter related to the execution of the battle is provided, and the parameter is reduced by a predetermined amount every time the battle is executed, and if the remaining amount falls below the predetermined amount, the execution of the battle may be disabled.

Moreover, in the operation | movement flow shown by FIG. 3, execution of a battle (S314) and execution of a support battle (S318) were performed separately. However, when the execution of the battle is instructed, a lottery may be performed in advance, and display data combining the battle and the support battle may be generated and transmitted to the terminal 2.
For example, the processing unit 33 may perform processing according to the following operation flow.
When the instruction indicated by the instruction data received from the terminal 2 is a battle execution, the control unit 331 instructs the battle execution unit 333 to execute the process.
The battle execution unit 333 reduces the enemy physical strength parameter stored in the storage unit 32 by a predetermined amount in accordance with the card data stored in the storage unit 32.
In addition, the battle execution unit 333 adds 1 to the battle execution number counter stored in the storage unit 32.
And the battle execution part 333 complete | finishes a process.
The control unit 331 confirms the remaining amount of the enemy's physical strength parameter stored in the storage unit 32. If the remaining amount is 0, the control unit 331 receives an instruction from the screen and a user for displaying the battle execution result. Display data relating to the screen is generated, and the display data is transmitted to the terminal 2 via the communication unit 31.
On the other hand, when the remaining amount is not 0, the control unit 331 checks the battle execution number counter stored in the storage unit 32, and when the value is not a predetermined value, the control unit 331 Display data relating to the screen for indicating the execution result is created, and the display data is transmitted to the terminal 2 via the communication unit 31.
On the other hand, when the value is a predetermined value, the control unit 331 instructs the support battle execution determination unit 332 to execute the process.
The support battle execution determination unit 332 sets the winning probability of the support battle based on the progress of the battle.
In addition, the support battle execution determination unit 332 performs a lottery according to the winning probability.
And the support battle execution determination part 332 stores the result in the memory | storage part 32, and complete | finishes a process.
When the lottery is not won, the control unit 331 creates display data related to the screen for indicating the execution result of the battle, and transmits the display data to the terminal 2 via the communication unit 31.
On the other hand, when the lottery is won, the control unit 331 instructs the support battle execution unit 334 to execute the process.
The support battle execution unit 334 reduces the enemy's physical strength parameter stored in the storage unit 32 by a predetermined amount.
Further, the support battle execution unit 334 creates display data related to a screen for indicating the execution status of the battle and the support battle, and transmits the display data to the terminal 2 via the communication unit 31.
Then, the support battle execution unit 334 ends the process.

(Second Embodiment)
The server device according to the first embodiment may be provided with means for inviting another user (hereinafter referred to as “inviting user”). FIG. 7 is a functional block diagram of the processing unit of such a server apparatus.

  The processing unit 33 ′ includes a control unit 331 ′, a support battle execution determination unit 332 ′, a battle execution unit 333 ′, a support battle execution unit 334, and an invited user registration unit 335.

  The control unit 331 'corresponds to the control unit 331 of the processing unit 33 according to the first embodiment. However, when user invitation instruction data is received from the terminal 2, the invitation user registration unit 335 is instructed to execute the process.

The support battle execution determination unit 332 ′ corresponds to the support battle execution determination unit 332 of the processing unit 33 according to the first embodiment. However, the difference is that the winning probability is set based not only on the remaining amount of enemy physical strength parameters but also on the number of invited users. For example, the winning probability is set to be higher as the remaining amount of enemy physical strength parameters stored in the storage unit 32 is larger, and the winning probability is set to be higher as the number of invited users is larger. When the remaining amount of the enemy's physical strength parameter and the number of invited users are variables, the winning probability can be calculated by the following mathematical formula, for example.
P = (R / T × 100 + U) / 1000 (Formula 2)
Here, P is the winning probability, R is the remaining amount of enemy health parameters, T is the total amount of enemy health parameters, and U is the number of invited users. For example, if R is 90, T is 100, and U is 10, P is
P = (90/100 × 100 + 10) /1000=0.10
And can be calculated.

  The battle execution unit 333 'corresponds to the battle execution unit 333 of the processing unit 33 according to the first embodiment. However, the difference is that the battle is performed using not only the card data associated with the user but also the card data associated with the invited user. Card data 510 and 511 associated with the invited user are also displayed on the upper and left sides of the display screen 508 shown in FIG.

  Returning to FIG. 7, the support battle execution unit 334 is the same as the support battle execution unit 334 of the processing unit 33 according to the first embodiment.

  The invited user registration unit 335 refers to the user management table stored in the storage unit 32 and creates display data related to a screen for accepting an invitation user instruction from the user. Then, the invited user registration unit 335 transmits the display data to the terminal 2 via the communication unit 31, causes the screen to be displayed, causes the user to receive an invitation user instruction, and sends the instruction data to the invitation user registration unit 335. Let me reply. The invited user registration unit 335 ends the process after storing the user ID of the invited user indicated by the instruction data in the storage unit 32.

  FIG. 8 is an operation flowchart of the game system 1 '. FIG. 8 shows only differences from the operation flowchart of FIG.

  When the game start instruction data is received from the terminal 2, the control unit 331 'advances the game and causes an enemy to appear according to the progress of the game (step S306).

  When an enemy appears, the control unit 331 ′ indicates a battle execution number counter indicating the number of battle executions with the same enemy, a support battle execution flag indicating whether a support battle is executed, and the number of invited users. An area for storing the invited user number counter is secured in the storage unit 32, and those values are initialized (step S307 ′). That is, the battle execution number counter is set to 0, the support battle execution flag is turned off, and the invited user number counter is set to 0.

  Then, the control unit 331 ′ creates display data related to a screen for receiving an instruction from the user, and transmits the display data to the terminal 2 via the communication unit 31 (step S <b> 308 ′).

  When receiving display data related to a screen for receiving an instruction from the user from the server device 3 ′, the processing unit 23 displays the screen on the display unit 25 based on the display data, and prompts the input of the instruction (step S309). ).

  When an instruction is input from the user via the operation unit 24, the processing unit 23 transmits the instruction data to the server device 3 'via the communication unit 21 (step S310').

  When the instruction indicated by the instruction data received from the terminal 2 is a battle avoidance (step S311-No, step S801-No), the control unit 331 ′ enters a process of returning the game progress to a normal state ( Step S320).

  On the other hand, when the instruction is a user invitation (step S311-No, step S801-Yes), the control unit 331 'instructs the invitation user registration unit 335 to execute the process (step S802).

  The invited user registration unit 335 refers to the user management table stored in the storage unit 32 and creates display data related to a screen for accepting an invitation user instruction from the user. Then, the invited user registration unit 335 transmits the display data to the terminal 2 via the communication unit 31 (step S802).

  When receiving display data related to a screen for accepting an invitation user instruction from the user from the server device 3 ′, the processing unit 23 displays the screen on the display unit 25 based on the display data and prompts the user to input the instruction. (Step S803).

  FIG. 5D shows a display screen 513 when inviting a user. A user image 514 and a name 515 are displayed on the left side of the display screen 513, and an “Invite” button 516 is displayed on the right side. By pressing the “Invite” button, the server device 3 ′ is requested to invite the corresponding user.

  Returning to FIG. 8, when an invitation user instruction is input from the user via the operation unit 24, the processing unit 23 transmits the instruction data to the server device 3 ′ via the communication unit 21 (step S <b> 804).

  The invited user registration unit 335 stores the user ID of the invited user indicated by the instruction data received from the terminal 2 in the storage unit 32 (step S805).

  The invited user registration unit 335 adds the number of invited users to the invited user number counter stored in the storage unit 32 (step S806).

  Then, the invited user registration unit 335 ends the process.

  The control unit 331 ′ returns the control after initialization of the battle execution counter and the like.

  As described above, by setting the winning probability of occurrence of a support battle based not only on the remaining amount of enemy health parameters but also on the number of invited users, the user to the progress of the battle by cooperation between users It is possible to increase the sense of expectation. Thereby, it becomes possible to prevent the user's willingness to continue the game from decreasing.

  In addition, according to the modification, the invited user registration unit 335 may select an invited user from users who have an exchange relationship with the user. For example, the server device 3 ′ transmits user names such as a user who has exchanged e-mails with the user and a user registered in the user's address book to the terminal 2, and displays the user name on the screen. The user name instruction may be accepted and returned to the invited user registration unit 335.

  In addition, the invited user registration unit 335 may select an invited user from users selected based on user attributes (such as age, sex, and area (country) in which they live) set in the social networking service (SNS). Good.

  The invited user registration unit 335 may use identification information other than the user name as the identification information of the invited user. Such identification information includes, for example, a combination of a user ID, a user ID, and attributes (such as age, sex, and region (country) where the SNS is set).

  Also, some of the functions of the processing unit 33 ′ of the server device 3 ′ may be realized by the processing unit 23 of the terminal 2. For example, only functions that are important for the progress of the game (support battle lottery, etc.) may be realized in the processing unit 33 ′ of the server device 3 ′, and other functions may be realized in the processing unit 23 of the terminal 2.

(Third embodiment)
The function of the server device according to the second embodiment can be realized in a stand-alone game terminal. FIG. 9 is a schematic configuration diagram of such a game terminal.

  The game terminal 8 includes a communication unit 81, a storage unit 82, a processing unit 83, an operation unit 84, and a display unit 85.

  The communication unit 81 includes a communication interface circuit compliant with a communication standard such as IrDA (registered trademark), Bluetooth (registered trademark), or ZigBee (registered trademark) for communicating with other game terminals 5. The communication unit 81 is used, for example, to exchange card data with other game terminals 5.

  The storage unit 82 and the processing unit 83 correspond to the storage unit 32 and the processing unit 33 ′ of the server device 3 ′ according to the second embodiment, respectively. However, the point which handles the user of the other game terminal 8 as an invited user differs.

  The operation unit 84 may be any device as long as the operation of the game terminal 8 is possible, for example, a touch pad, a keyboard, or the like. The display unit 85 may be any device as long as it can display a game screen, such as a liquid crystal display or an organic EL display.

  The game terminal according to the present embodiment has functions equivalent to those of the server device according to the second embodiment, and can achieve the same effects.

  A computer program that causes a computer to realize the functions of the server device according to the first and second embodiments and the processing unit of the game terminal according to the third embodiment is readable by a computer such as a magnetic recording medium or an optical recording medium It may be provided in a recorded form on a simple recording medium.

  The present invention is not limited to application to card battle games and card data, but can also be applied to games and data having other similar mechanisms.

  It should be understood by those skilled in the art that various changes, substitutions, and modifications can be made thereto without departing from the spirit and scope of the present invention.

DESCRIPTION OF SYMBOLS 1 Game system 2 Terminal 21 Communication part 22 Storage part 23 Processing part 24 Operation part 25 Display part 3 Server 31 Communication part 32 Storage part 33, 33 'Processing part 331, 331' Control part 332, 332 'Support battle execution determination part 333, 333 ′ Battle execution unit 334 Support battle execution unit 335 Invited user registration unit 4 Base station 5 Mobile phone network 6 Gateway 7 Internet 8 Game terminal 81 Communication unit 82 Storage unit 83 Processing unit 84 Operation unit 85 Display unit

A server control program according to the present invention is a server control program for controlling a server device that progresses a game that changes a parameter value of a game object while communicating with a terminal. When the first event occurs during the progress of the process, the parameter value is decreased by the first predetermined value, the first display data corresponding to the first event is created, and the number of occurrences of the first event is determined. Count, set the winning probability of occurrence of the second event based on the number of occurrences of the first event and the parameter value, and determine whether the second event has occurred based on the lottery according to the winning probability When the occurrence of the second event is determined, the parameter value is decreased by a second predetermined value, and second display data corresponding to the second event is created. Transmitting the first display data and second display data to the terminal, to execute the.
Further, the computer according to the present invention includes a first battle execution unit that executes a first battle according to an instruction from the player, and whether or not a second battle has occurred based on a lottery when the player does not win in the first battle. When the processing unit and the processing unit determine the occurrence of the second battle, the second battle execution unit that executes the second battle and the second battle execution unit that does not execute the second battle, When the display data for indicating the execution result of the first battle is output without outputting the display data for indicating the execution status of one battle, and the second battle execution unit executes the second battle, the first battle and And an output unit for outputting display data for indicating the execution status of the second battle.
In the computer according to the present invention, it is preferable that the processing unit determines whether or not the second battle has occurred based on a lottery according to a specific winning probability.
In the computer according to the present invention, the first battle is a battle that attacks the game object, the second battle is a battle that further attacks the game object, and the processing unit is based on the parameter value related to the game object. Thus, it is preferable to set a specific winning probability.
Moreover, the control method according to the present invention is a method for controlling a computer including an output unit, and executes a first battle according to an instruction from a player. If the player does not win in the first battle, the control method is based on a lottery. Display data for indicating the execution status of the first battle when the second battle is executed when the occurrence of the second battle is determined and the occurrence of the second battle is determined, and when the second battle is not executed When the second battle is executed, the display data for indicating the execution status of the first battle and the second battle is output when the second battle is executed. Output to the part.
The control program according to the present invention is a control program for a computer including an output unit. When the first battle is executed according to an instruction from the player and the player does not win in the first battle, the control program is based on a lottery. Display data for indicating the execution status of the first battle when the second battle is executed when the occurrence of the second battle is determined and the occurrence of the second battle is determined, and when the second battle is not executed When the second battle is executed, the display data for indicating the execution status of the first battle and the second battle is output when the second battle is executed. To output to the computer.

Claims (11)

A first battle execution unit that executes a first battle according to an instruction from the player;
A processing unit that determines whether or not a second battle has occurred based on a lottery when the player does not win in the first battle;
When the processing unit determines the occurrence of the second battle, a second battle execution unit that executes the second battle;
If the second battle execution unit does not execute the second battle, display data for indicating the execution result of the first battle without outputting display data for indicating the execution status of the first battle. And when the second battle execution unit executes the second battle, an output unit that outputs display data for indicating the execution status of the first battle and the second battle;
A computer comprising:   The computer according to claim 1, wherein the processing unit determines whether or not the second battle has occurred based on a lottery corresponding to a specific winning probability. The first battle is a battle that attacks a game target,
The second battle is a battle that further attacks the game target,
The computer according to claim 2, wherein the processing unit sets the specific winning probability based on a parameter value related to the game target.   The computer according to claim 3, wherein the processing unit sets the specific winning probability so that the specific winning probability becomes higher as the remaining amount of the parameter value increases.   The computer according to claim 2, wherein the processing unit sets the specific winning probability based on the number of players who participate in the game other than the player.   The computer according to any one of claims 2 to 5, wherein the processing unit sets the specific winning probability based on the number of executions of the first battle.   The server device according to any one of claims 2 to 6, wherein the processing unit changes the specific winning probability when the occurrence of the second battle is not determined even if the lottery is performed a predetermined number of times or more. .   The computer according to any one of claims 1 to 7, wherein the processing unit determines whether or not the second battle is generated when the number of times of execution of the first battle becomes a predetermined value or more.   The first battle is a battle in which the player's card and the game target attack each other, and the player's card parameter is initialized each time the first battle is executed, and the game target parameter is The computer as described in any one of Claims 1-8 which maintains the value after execution of a 1st battle. A method for controlling a computer including an output unit,
The first battle is executed according to the instruction from the player,
When the player does not win in the first battle, the presence or absence of the second battle is determined based on the lottery,
When the occurrence of the second battle is determined, the second battle is executed,
When the second battle is not executed, the display data for indicating the execution result of the first battle is output to the output unit without outputting the display data for indicating the execution status of the first battle, When the second battle is executed, display data for indicating the execution status of the first battle and the second battle is output to the output unit.
A control method comprising: A computer control program including an output unit,
The first battle is executed according to the instruction from the player,
When the player does not win in the first battle, the presence or absence of the second battle is determined based on the lottery,
When the occurrence of the second battle is determined, the second battle is executed,
When the second battle is not executed, the display data for indicating the execution result of the first battle is output to the output unit without outputting the display data for indicating the execution status of the first battle, When the second battle is executed, display data for indicating the execution status of the first battle and the second battle is output to the output unit.
A control program for causing a computer to execute the above.

Images