JP2017055996A - Program, game device, and server system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a new technology for supporting determination about whether or not to select an object in the case that selection of the unused object is irreversible or that certain labor and costs are required to make the selection reversible.SOLUTION: A player selects a plurality of player characters 4 (4a, 4b,...) to use for play from acquired characters. When a player character 4a satisfying a trial generation condition is detected during play, the player character 4a is made to leave the game screen. In its place, a trial character 53 which is not acquired by the player, is on an evolution system of the player character 4a, and is higher in evolutional level is made to appear and display its capability. After the capability is displayed, the trial character 53 is made to leave and the original player character 4a is made to appear. That is, the trial character 53 is temporarily used (tried).SELECTED DRAWING: Figure 10

Description

  The present invention relates to a program or the like for causing a computer to execute a game in which a player selects a used object from among acquired objects.

In video games, “evolution” of an object is known as one of the methods for improving the ability of the object used by the player.
For example, when the object is a character, the player can evolve the player character.

  That is, the player character is set as an evolutionary lineage that grows step by step in the game world and increases its ability. Then, in accordance with the evolutionary lineage, with the beginning character as the starting point of evolution, the evolutionary character with the appearance that is more gorgeous than the original character and improved in ability (evolution level, evolution rank) A plurality of types are prepared in this order. When a player character satisfies a predetermined evolution permission condition (for example, an experience value acquired by battle reaches a threshold) during the game and the player inputs an evolution execution operation, the player character currently used is displayed on the evolutionary lineage. Can be irreversibly replaced with another character that is said to have evolved one level.

Depending on the content of the game, there may be cases where another character or item or in-game currency is required as a material or price for evolution. Depending on the content of the game, evolution may be referred to as “compositing”, “strengthening”, “job change”, “class change”, “transfer”, and the like.
Regardless of the name, the player can play the game while gradually growing the starting character (see, for example, Patent Document 1 and Patent Document 2).

JP 2007-159675 A JP 2014-161527 A

  Depending on the game, the genealogy of character evolution is not always one-way. For example, there are cases in which a branch is divided into a plurality of evolutionary pedigrees at the stage of evolution from level “3” to level “4”, and the player must select which evolutionary lineage character to evolve. Naturally, once selected, evolution cannot be reversed. If you choose an evolutionary lineage that doesn't fit your play style, you may be wasting the characters that you have nurtured. It is very annoying which character to select. Of course, information on the selection candidate characters (for example, how much attack power is used, names of special skills and special skills, etc.) are provided to the player to some extent, but it is difficult to solve the troubles by itself.

  It should be noted that such concerns regarding the selection of objects do not relate to character enhancement such as “evolution”. For example, the same may occur when purchasing a new object that has not been used after being paid. Further, the target is not limited to the character, and the same applies to other objects such as items used by the character.

  The present invention has been devised based on such a background, and the purpose of the present invention is that it takes a certain amount of labor and cost to make an irreversible selection of an object that has never been used, or to make it reversible. In some cases, a new technique for supporting the determination of whether or not to select the object is realized.

A first invention for solving the above-described problem is a program for causing a computer to execute a game in which a player selects and plays a use object from among acquired objects.
Selection means (for example, processing unit 200, game management unit 210, trial character selection unit 216 in FIG. 13, step S16 in FIG. 22, step S16, FIG. 22). S18),
Control means (for example, the processing unit 200, the game management unit 210, the trial control unit 218 in FIG. 13, FIG. 23) that causes the sample object to appear temporarily in the game and exerts the ability set in the sample object. Step S138) is a program for causing the computer to function.

  According to the first invention, the player can select a sample object from unacquired objects, and can temporarily appear in the game to exhibit its ability. In other words, it is possible to try the sample object temporarily, and a new technique for supporting the determination of whether or not to select the object can be realized. In addition, what corresponds to an object may be a character according to the game content, and an item, a vehicle, a building, or the like can be set as appropriate.

  A second invention is the program according to the first invention, wherein the selecting means selects an object when the acquired object has evolved as the sample object.

  According to the second invention, since the object when the acquired object has evolved can be used as the sample object, for example, when a plurality of evolution destination objects branching from the acquired object can be selected, It can help you decide whether to choose an evolution destination.

  A third invention is the program according to the first or second invention, wherein the selecting means selects an object having the same attribute as the attribute set for the acquired object as the sample object.

  According to the third aspect, an object having the same attribute as the attribute set for the acquired object can be used as the sample object. In a game where which attribute object to select affects the game play style (tactical meaning), it is possible to select and provide objects that are more useful to the player.

  A fourth invention is the program according to any one of the first to third inventions, wherein the selection means selects an object of a level higher than the level of the acquired object as the sample object.

  According to the fourth aspect, it is possible to select a higher level object that the player should acquire in the future as a sample object.

  A fifth invention is the program according to any one of the first to fourth inventions, wherein the selection means selects an object acquired by a friend player of the player as the sample object.

A friend player is another player who is recognized and registered as a friend by the player.
According to the fifth aspect, since the acquired object of the friend player is a sample object, for example, in the case of a multiplayer game that plays cooperatively with a friend player, the activity expected of the friend player can be confirmed. If the game is to play against a friend player, the inside of the friend player's hand can be estimated. In addition, it is possible to expect the effect of contributing to the creation of a topic by encouraging the ownership of a common object with a friend player.

  In a sixth aspect of the invention, the selection means selects, as the sample object, an object that has a given relationship with an object that has been acquired by a friend player of the player. It is a program.

  According to the sixth aspect of the present invention, an object that has a given relationship with an object that has been acquired by the friend player (for example, an object that exhibits a cooperative effect when used together) can be used as a sample object.

  The seventh invention is an information disclosing means for disclosing information on the sample object (for example, the information disclosing section 33 in FIG. 4, the information disclosing section 45 in FIG. 5, the information disclosing section 62 in FIG. 12, and the processing section 200 in FIG. 13). , A game management unit 210, an information disclosure control unit 220, and a program of any one of the first to sixth inventions for causing the computer to further function as step S256) in FIG.

  According to the seventh aspect, sample object information can be provided to the player.

  An eighth invention is the program according to the seventh invention, wherein the information disclosing means discloses information for the player to acquire the sample object.

  According to the eighth aspect, it is possible to provide the player with information on how to obtain the sample object.

  A ninth invention is the program according to any one of the first to eighth inventions, wherein the selection means sets a selection probability for each of the candidate objects and selects the sample object by lottery based on the selection probability. .

  According to the ninth aspect, the sample object can be selected by lottery.

  A tenth invention is the program according to the ninth invention, wherein the selection means sets the selection probability of the candidate object using the selection probability setting condition based on the play history of the player.

  In the eleventh invention, the setting condition is a condition determined based on a use history of a given item included in the play history (for example, step S116 in FIG. 22). It is a program.

  In the twelfth invention, the setting condition is a condition determined based on a value of a given parameter included in the play history (for example, step S130 in FIG. 23), and the program of the tenth invention It is.

  By referring to the player's play history and billing history, it is possible to know the play frequency, past play results, billing frequency, item usage history, and the like. From these, it can be estimated how familiar the player is with the game, whether it is a beginner or an advanced player. According to any of the tenth to twelfth inventions, the selection probability of the candidate object can be changed according to the player's familiarity with the game, the skill as the player, and the play style.

  A thirteenth aspect of the present invention is an object giving means for drawing an object to be given to the player and giving it to the player. When the sample object appears, the sample object is deleted from the lottery candidate objects. Alternatively, for further causing the computer to function as an object granting unit (for example, the object granting control unit 222 in FIG. 35 and the object granting control process in FIG. 36) that performs the lottery by reducing the winning probability of the sample object. A program according to any one of the first to twelfth inventions.

  According to the thirteenth aspect, in a situation where objects are given by lottery, the sample object given to the player can be prevented from being given or can hardly be given.

  In a fourteenth aspect, when the control means causes the sample object to appear, the sample object appears instead of the acquired object already appearing (for example, step S224 in FIG. 26). A program according to any one of the first to thirteenth inventions.

  According to the fourteenth aspect, the sample object can appear in the game in place of the object already acquired by the player.

  A fifteenth aspect of the present invention is a game device for executing a game in which a player selects a used object from among acquired objects and plays the sample object that is not acquired by the player from among a plurality of candidate objects. Selection means (for example, the control board 1550 in FIG. 2, the processing unit 200 in FIG. 28, the game management unit 210, the trial character selection unit 216, steps S16 and S18 in FIG. 22), and the sample object temporarily Control means (for example, the control board 1550 in FIG. 2, the processing unit 200 in FIG. 28, the game management unit 210, the trial control unit 218, FIG. 23 step S138).

According to a sixteenth aspect of the present invention, there is provided a server system for communicating with a player terminal so that the player selects a used object from among the acquired objects and plays the game on the player terminal. Selection means (for example, a control board 1150 in FIG. 1, a processing unit 200 in FIG. 13, a game management unit 210, a trial character selection unit 216, FIG. Steps S16 and S18),
Control means (for example, the control board 1150 in FIG. 1, the processing unit 200 in FIG. 13, the game management unit 210, the game management unit 210, and the like) that causes the sample object to temporarily appear in the game and exerts the ability set in the sample object. A server system including a trial control unit 218 and step S138 in FIG.

  According to the fifteenth or sixteenth invention, it is possible to realize a game device or a server system that obtains the same effects as those of the first invention.

The figure which shows an example of a structure of a game system. The front external view which shows the structural example of a player terminal. The figure which shows the example of a game screen. The figure which shows the example of the evolution lineage of a player character. The figure which shows the example of a trial character selection screen. The figure for demonstrating the automatic selection pattern of an "evolution" type. The figure for demonstrating the automatic selection pattern of an "attribute" type. The figure for demonstrating the automatic selection pattern of a "friend possession" type. The figure for demonstrating the automatic selection pattern of a "compatibility" type. Transition diagram of an example of a game screen for explaining an example from appearance of a trial character to a game to exit (part 1). Transition diagram of an example game screen for explaining an example from appearance of the trial character to the game to exit (part 2). The figure which shows the example of the appearing trial character confirmation screen. The figure which shows the function structural example of a server system. The figure which shows the example of the program and data which the memory | storage part of a server system memorize | store. The figure which shows the data structural example of candidate character initial setting data. The figure which shows the data structural example of character evolution lineage setting data. The figure which shows the data structural example of character compatibility setting data. The figure which shows the data structural example of the trial character candidate list for manual selection. The figure which shows the data structural example of user management data. The figure which shows the data structural example of play data. The figure which shows the data structural example of deck management data. The flowchart for demonstrating the flow of a process in a server system. The flowchart following FIG. The flowchart for demonstrating the flow of a trial character manual selection process. The flowchart for demonstrating the flow of a trial character automatic selection process. The flowchart for demonstrating the flow of trial control processing. The flowchart for demonstrating the flow of an appearance probability setting process. The functional block diagram which shows the function structural example of a game device. The figure which shows the example of the program and data which the memory | storage part of a game device memorize | store. The transition figure of the game screen which shows the modification of the appearance to a game of a trial character. The flowchart for demonstrating the flow of the modification of a trial control process. The flowchart for demonstrating the modification of the flow of a process in a server system. The flowchart following FIG. The flowchart for demonstrating the flow of a priority character list optimization process. The functional block diagram which shows the modification of the function structure of a server system. The flowchart for demonstrating the example of the flow of an object provision control process.

  In the present embodiment, an online game in which a player selects and plays a player character from among acquired characters will be described as an example of a game in which a player selects a used object from among acquired objects.

[Description of game system]
FIG. 1 is a diagram illustrating an example of a configuration of a game system in the present embodiment. The game system of this embodiment includes a server system 1100 that can be connected to the communication line 9 and a player terminal 1500 that can perform data communication with the server system 1100.

  The communication line 9 means a communication path capable of data communication. That is, the communication line 9 includes a communication network such as a telephone communication network, a cable network, and the Internet in addition to a dedicated line (dedicated cable) for direct connection and a LAN (Local Area Network) using Ethernet (registered trademark). This means that the communication method may be wired or wireless.

  The server system 1100 includes, for example, a main device 1101, a keyboard 1106, a touch panel 1108, and a storage 1140. A control board 1150 is mounted on the main device 1101. The control board 1150 includes various microprocessors such as a CPU (Central Processing Unit) 1151, GPU (Graphics Processing Unit), and DSP (Digital Signal Processor), various IC memories 1152 such as a VRAM, a RAM, and a ROM, and a communication device 1153. Has been. A part or all of the control board 1150 may be realized by an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a system on a chip (SoC).

  The server system 1100 performs arithmetic processing on the control board 1150 based on a predetermined program and data, whereby 1) a user management function related to user registration and the like, and 2) a player who is a user plays a game on the player terminal 1500. And a game management function that provides data necessary for the game, and 3) an online shopping function that sells content such as characters and items that can be used in the game. That is, the game of this embodiment is realized as a kind of client-server online game.

  In the illustrated example, the server system 1100 is described as a single unit, but a plurality of blade servers that share the user management function, the online shopping function, and the game management function are mounted, and data communication is performed via an internal bus. A configuration in which connection is possible is also possible. Alternatively, the server system 1100 may be configured to function as a whole by performing data communication with a plurality of independent servers installed at remote locations via the communication line 9.

FIG. 2 is a front external view showing a configuration example of the player terminal 1500.
The player terminal 1500 is a portable computer that is connected to the communication line 9 and can access the server system 1100, and is a small electronic device. The player terminal 1500 according to the present embodiment is a device classified as a so-called smartphone, but is a portable game device, a stationary home game device, a game controller for a stationary home game device, an arcade game device, a personal computer, or a tablet type. The device may be classified as a computer, a wearable computer, or the like.

  The player terminal 1500 in this embodiment includes a direction input key 1502, a button switch 1504, a touch panel 1506 functioning as an image display device / contact position input device, a built-in battery 1509, a speaker 1510, a microphone 1512, and a control board. 1550 and a memory card reader 1542 that can read and write data from a memory card 1540 that is a computer-readable storage medium. In addition, a power button, a volume control button, an image sensor unit (photographing means), etc., not shown are provided. In addition, an IC card reader or the like that can read and write data without contact with an IC card type credit card or prepaid card may be provided.

  The control board 1550 wirelessly communicates with the CPU 1551, various microprocessors such as GPU and DSP, various IC memories 1552 such as VRAM, RAM, and ROM, and mobile phone base stations and wireless LAN base stations connected to the communication line 9. The wireless communication module 1553 is mounted. In addition, a driver circuit of the touch panel 1506, a circuit that receives signals from the direction input key 1502 and the button switch 1504, an output amplifier circuit that outputs an audio signal to the speaker 1510, and an input signal that generates an audio signal collected by the microphone 1512 A so-called I / F circuit 1557 (interface circuit) such as a generation circuit and a signal input / output circuit for the memory card reader 1542 is mounted. Each element mounted on the control board 1550 is electrically connected via a bus circuit or the like, and is connected so that data can be read and written and signals can be transmitted and received. Part or all of the control board 1550 may be realized by an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a system on a chip (SoC).

  The control board 1550 stores a program and data for realizing game play on the player terminal 1500 in the IC memory 1552. Then, the program is executed to execute arithmetic processing, and game play is enabled by controlling each part of the player terminal 1500 in accordance with operation inputs from the direction input key 1502, the button switch 1504, and the touch panel 1506. In this embodiment, the player terminal 1500 is configured to acquire necessary programs and various setting data from the server system 1100, but may be configured to read from a storage medium such as a memory card 1540 obtained separately.

  As a preliminary preparation for playing the game of this embodiment, the player obtains a player ID (account) by performing a user registration procedure, and “candidate character (candidate object)”, which is a character object that can be used as a player character. It is necessary to obtain / acquire. Note that “obtaining” as used herein includes not only acquisition of physical ownership but also acquisition of the right to use or use electromagnetic information.

  User registration is realized by accessing a website provided by the server system 1100 and performing a predetermined procedure. When the user is registered, a player ID (account) is issued. Therefore, by logging in with the issued player ID, game play, online shopping, and the like are possible. When user registration is performed, user management data 600 associated with the player ID is created in the server system 1100 (for example, the storage 1140).

  The “candidate character” is selected or automatically given by the player at the time of user registration, for example. Alternatively, the purchase may be made through online shopping provided by the server system 1100. Further, a game card may be purchased and available.

  The “game card” referred to here is an information carrier medium prepared by the game producer, and may be a card with an entity (so-called “trading card”), or a virtual card with only an electronic information without an entity. It may be. In the case of a card having an entity, for example, a predetermined number (for example, two or five) may be sold as one package at an actual store. In the case of a virtual card, a predetermined number of cards can be given by lottery whenever a login or separately acquired lottery right is exercised. The game card may be purchased at an online shopping site realized by the server system 1100 or a known online shopping site.

  Each game card is assigned one type of candidate character, is given a unique card ID, and has a barcode. After logging in with the player ID, the user performs a predetermined card registration procedure for making the obtained game card candidate character available (valid) in the game. When the card registration procedure is performed, information on the newly registered game card candidate character is registered in association with the player ID, and the character can be used in the game.

  The form of the information carrying medium is not limited to a game card and can be set as appropriate. For example, a three-dimensional modeled object (for example, a figure) imitating the appearance of characters, items, and the like may be used. In that case, it is more preferable to adopt a form having properties as a collection item in addition to game play including size and design.

[Description of game contents]
FIG. 3 is a diagram showing an example of a game screen in the present embodiment.
The game of the present embodiment is a game in which a predetermined number is selected as player characters (used objects used in game play) from among acquired candidate characters (acquired characters; acquired objects). Specifically, it is a stage clear type action RPG (role-playing game) game in which weapons such as swords and spears are equipped for each player character and aiming at a destination while defeating enemies encountered.

  A game space display unit 20 is provided at the upper part of the game screen W2 displayed on the touch panel 1506, and the state of the game space in which the player character 4 (4a, 4b,...) Encounters the enemy character 6 is displayed. The

A set of player characters 4 selected from the acquired characters is called a “deck”, and selecting a player character is called “editing a deck”.
The deck display unit 22 provided at the lower part of the game screen W2 displays information on the player characters 4 (4a, 4b,...) That form the deck. In the present embodiment, a setting frame 23 is provided for each player character 4, and each setting frame 23 includes a character image 24 indicating the player character 4 (4a, 4b,...) Assigned to the setting frame, An attribute display unit 25 and an equipment item display body 26 are included.

  Each candidate character is assigned at least one “character attribute” which is a characteristic classification of the character, and the attribute display unit 25 indicates the character attribute of the player character 4 assigned to the setting frame 23. The type and number of character attributes can be set as appropriate.

  The equipment item display 26 displays items such as weapons and armor equipped on the player character 4 assigned to the setting frame 23. Various items including weapons and armor can be acquired in the game or purchased online.

  In this embodiment, the game progresses in a turn system in which a player turn in which the player character 4 (4a, 4b,...) Acts in response to an operation input by the player and an enemy turn in which the enemy character 6 is automatically controlled are alternately switched. To do. Of course, it may be a real-time strategy type.

  Although the operation input method can be set as appropriate, in this embodiment, the action menu is displayed by touching the character image 24 of the player character 4 to be acted, and “attack” “defense” “equipment item” is selected from the action menu. Select actions such as “use” and “friend support”. When it is necessary to further select an action target such as attack or support, a touch operation on the player character 4 (4a, 4b,...) Or the enemy character 6 displayed on the game space display unit 20 following the action selection. To do. Of course, other operation input methods may be employed.

  A life value is set for each of the player character 4 and the enemy character 6, and the life value is subtracted if damage is received during the battle. When the life value becomes “0”, the character is considered to be unable to act, that is, destroyed. If all the player characters 4 become unable to act before reaching the destination, the game is over. If the enemy character 6 encountered is defeated and at least the player character 4 reaches the goal without being disabled, the stage is cleared. And if you clear all the stages, it will be fine and the game will be cleared.

FIG. 4 is a diagram illustrating an example of the evolutionary lineage of the player character 4.
Many candidate characters that can be player characters 4 (hereinafter simply referred to as player characters 4) acquire experience values in battle with the enemy character 6 and can evolve to higher levels when the experience values reach a reference value. Is set to Of course, the candidate character corresponding to the final evolution level is not limited.

  The evolutionary lineage (the order of evolution, the progression from lower to higher evolution levels) is not limited to one, and there may be cases where the evolutionary level is divided into multiple evolutionary lineages. In the example of FIG. 4, there is one evolutionary lineage from evolution level “1” to evolutionary level “3”, but the evolutionary lineage is divided into two at the stage of transition from evolutionary level “3” to evolutionary level “4”. After that, each will be a different evolutionary lineage. The number of evolution levels and the number of branches in the evolutionary lineage can be set as appropriate.

  When the experience value of the player character 4 (acquired character that has organized the deck) reaches a reference value that allows evolution, an evolution selection screen W3 is displayed. In the evolution selection screen W3, the evolutionable character 31 that is the player character 4 that has become capable of evolution, the evolution destination character 32 (32a, 32b) at a higher evolution level that can evolve from the evolution character, the information disclosure unit 33, An evolution execution operation icon 34 and an evolution cancellation operation icon 35 are displayed.

  In the example of FIG. 4, two evolution destination characters 32 (32a, 32b) are displayed, but change depending on the number of branches of the evolutionary lineage. When one of the evolution destination characters 32 (32a, 32b) is touched, information about the touched character is displayed on the information disclosure unit 33. Then, if the evolution execution operation icon 34 is touched, the evolution destination character currently selected can be caused to perform the evolution. The evolution can be stopped by touching the evolution cancel operation icon 35.

Different evolutionary genea- tions have different characteristics for improving their capabilities as they evolve.
Then, if selection of the evolutionary lineage (in the example of FIG. 4, selection of whether to select the evolution destination character 32a or the evolution destination character 32b) is performed, it cannot be reversed. If an evolutionary lineage that changes in line with your play style is selected, the player character 4 that has been carefully nurtured until then can be wasted. It's very annoying which one to choose. Of course, the information disclosure unit 33 provides the player with information on the evolution destination character 32 to some extent, but it is difficult to solve all the troubles by itself. The same can be said when purchasing a candidate character regardless of evolution.

  Therefore, in the present embodiment, a candidate character (unacquired character) that has not been acquired by the player temporarily appears in the game as a sample object, and a part of the ability is exhibited. Further information for determining whether or not to purchase the candidate character is provided to the player.

[Explanation of trial system]
A mechanism in which a player makes a candidate character (unacquired character) that has not been acquired temporarily appear in the game as a sample and a part of the ability is exhibited is called a “trial system”, and an unacquired character that appears on the trial system. (Sample object) is called a “trial character”.

  In the present embodiment, the selection of the trial character is 1) “manual selection” selected by the player himself, and 2) “automatic selection” selected by the computer based on the player character 4 organizing the deck. You can choose from two selection patterns. The player can select whether to use manual selection or automatic selection.

FIG. 5 is a diagram showing an example of the trial character selection screen W4.
The trial character selection screen W4 includes a manual selection / designation operation icon 41 for designating “manual selection” and an automatic selection / designation operation icon 42 for designating “automatic selection”.

  When the manual selection designating operation icon 41 is touched, it is determined that the selection pattern “manual selection” is designated, and the trial character selection screen W4 includes a setting frame 43, an option display unit 44, and an information disclosure unit 45. Is displayed.

  The setting frame 43 indicates the number of settable trial characters. In the present embodiment, the number of setting frames 43 is five, but the number can be set as appropriate. At the beginning of display, all setting frames 43 are “color (unselected)”.

  The option display unit 44 displays options for unacquired characters that can be manually selected. The display form can be set as appropriate. For example, the character images of the characters to be selected are displayed in an array, and when the slide operation is performed along the array direction, the array of the options changes like page turning, and the target is displayed. A three-dimensional graphical user interface that displays selections at predetermined positions and performs selection operations may be used.

  The information disclosure unit 45 displays information related to the unacquired character currently selected in the option display unit 44, and the player makes a selection decision based on this information. Then, the character image displayed on the option display unit 44 is set by dragging and dropping on the setting frame 43. If the selection confirmation operation icon 47 is touched, manual selection is confirmed.

Although manual selection allows the player to freely select a trial character, selection of some unacquired characters may require a fee for trial use as a trial character.
The consideration is called “trial cost” and is set for some unacquired characters. When the trial cost is set, a cost display 46 is displayed along with the information disclosure unit 45. If the character for which the trial cost is set is a trial character, payment of the consideration is executed. The payment method of consideration can be set as appropriate, such as item consumption, virtual currency consumption, and handicap application. In this embodiment, the virtual currency used in the game world is consumed.

Next, automatic selection will be described.
When the automatic selection designating operation icon 42 is touched, any one of a plurality of automatic selection patterns is automatically lottery, and a trial character is automatically determined according to the lottery-selected automatic selection pattern. In this embodiment, four patterns of “evolution”, “attribute”, “friend possession”, and “compatibility” are prepared as automatic selection patterns.

FIG. 6 is a diagram for explaining an “evolution” type automatic selection pattern.
In the “evolution” type automatic selection pattern, the trial character is selected based on the evolutionary lineage of the player character 4 that forms the deck. Specifically, an unacquired character that is higher in the evolution level in the evolutionary lineage of the player character 4 that forms the deck and has not been acquired by the player is selected as a candidate for trial character selection. In the example of FIG. 6, when the player character 4 is at the evolution level “2”, a character that is at the evolution level “3” or higher on all evolution lineages and that has not been acquired by the player is selected as a trial character selection candidate.

FIG. 7 is a diagram for explaining an “attribute” type automatic selection pattern.
In the “attribute” type automatic selection pattern, a character that has the same character attribute as the player character 4 that forms the deck and has not been acquired is selected as a candidate for trial character selection. At that time, the evolutionary lineage of the character does not matter.

FIG. 8 is a diagram for explaining an automatic selection pattern of the “friend possession” type.
In the “friend-owned” type automatic selection pattern, a candidate character possessed by a friend is set as a trial character selection candidate. Specifically, the acquired character 81 possessed by the player 80 is compared with the acquired character 84 of a friend player 83, which is another player that the player separately registers as a friend. Then, an unacquired character 85 that the player 80 does not have but the friend player 83 has is set as a trial character selection candidate. At that time, the character's evolution level, evolutionary lineage, and character attributes are irrelevant.

FIG. 9 is a diagram for explaining a “compatibility” type automatic selection pattern.
In the “Compatibility” type automatic selection pattern, when you are simultaneously knitted to a deck, you can select a trial character as an unacquired character with “goodness” that improves the ability to be demonstrated mutually Candidate.

  A configuration in which some of these four types are omitted is also possible. Moreover, the structure which replaces a part with automatic selection patterns other than these four types is also possible.

Next, how to use the trial character will be described.
10 to 11 are transition diagrams of game screen examples for explaining an example from the appearance of the trial character to the game to the exit.
Of the player characters 4 that form the deck, a character that satisfies the trial activation condition is recognized as a “trial activation character”, and as shown in FIG. 10A, the corresponding player character 4 (in the example shown in the figure). A trial activation notification 50 is attached to the player character 4a). Then, as shown in FIG. 10 (2), the character replacement effect 52 (trial activation effect) is applied to the trial activation character (player character 4a in the illustrated example), and the character disappears. Next, as shown in FIG. 10 (3), a trial character 53 appears instead and an appearance notice 54 is displayed instead. Further, the trial character 53 is identified and displayed so that the player can recognize that it is a trial character. In the example of FIG. 10 (3), identification display is performed by enlarging the display size of the character once. Of course, the display size of the trial character 53 is the same as that of the other player characters 4 by separately displaying an identification display (for example, a cross star mark in FIG. 10 (3)). May be identified.

  The contents of the character replacement effect 52 can be set as appropriate. In the example shown in the figure, an example in which the trial character 53 (player character 4a) gradually disappears while being wrapped in ring-shaped light and the trial character 53 appears. An effect display such as “don't stop” from the trial activation character to the trial character 53 may be used.

As shown in FIG. 11 (1), the appearing / appearing trial character 53 exhibits a part of its ability. The content of the ability to be exhibited can be set as appropriate, but it is preferable to control so that the ability that characterizes the character, for example, the special skill is preferentially exhibited as shown in the figure.
Then, when the ability has been fully demonstrated, as shown in FIGS. 11 (2) to 11 (3), the character replacement effect 52 is displayed again, the trial character 53 disappears, and the original trial activation character (player character) is displayed. 4a) appears.

  The trial characters 53 that appear during the game play are separately registered in the list, and at the end of the game, the player can reconfirm which trial character 53 appeared and what kind of character it was. Yes. Specifically, for example, an appearing trial character confirmation screen W6 as shown in FIG. 12 is displayed. On the appearing trial character confirmation screen W6, a character list 61 in which character images of the appearing trial characters are arranged and an information disclosure unit 62 are displayed.

  When the player touches and selects any one of the character images in the character list 61, information on the trial character 53 corresponding to the character image selected and operated is displayed on the information disclosure unit 62. In this embodiment, the information disclosure unit 62 displays a character explanation 63 and an acquisition guide 64.

In the character explanation 63, an explanation of the ability of the trial character is displayed.
In the obtaining guide 64, an explanation of how to obtain the trial character and how to obtain it and hints are displayed. In the example of FIG. 12, the selected trial character can be acquired by character evolution, but since it is a setting that can be purchased through online shopping, an explanation of each acquisition method is displayed.

  As shown in FIGS. 10 to 11, the player tries the character by experiencing and experiencing the ability of the trial character 53 limitedly (in other words, by using the trial character 53). It can be used as a material for determining whether or not to evolve into the character 53 and as a material for determining whether or not to purchase the trial character 53. In addition, as shown in FIG. 12, since the information of the appearing trial character can be confirmed again after the game, it is convenient for tracing and reconfirming even if several trial characters appear. It is. In particular, the provision of the acquisition guide 64 is significant in that it helps the acquisition of the character that he / she wanted to do among the trial characters.

[Description of functional configuration]
FIG. 13 is a functional block diagram illustrating a functional configuration example of the server system 1100 according to the present embodiment. The server system 1100 in this embodiment includes an operation input unit 100, a processing unit 200, a sound output unit 390, an image display unit 392, a communication unit 394, and a storage unit 500.

  The operation input unit 100 is a means for inputting various operations for managing the server system 1100. In the example of FIG. 1, the keyboard 1106 corresponds.

  The processing unit 200 is realized by, for example, a microprocessor such as a CPU or a GPU, or an electronic component such as an IC memory, and performs data input / output control with each functional unit including the operation input unit 100 and the storage unit 500. Various arithmetic processes are executed based on predetermined programs and data, operation input signals from the operation input unit 100, and data received from the player terminal 1500. In the example of FIG. 1, the control board 1150 corresponds to this.

  The processing unit 200 according to the present embodiment includes a user management unit 202, an online shopping management unit 204, a game management unit 210, a sound generation unit 290, an image generation unit 292, a communication control unit 294, a current date and time. And a time measuring unit 296 that measures time such as management and timer control.

  The user management unit 202 performs processing related to the user registration procedure and registration management processing of various data associated with registered users. For example, 1) a process for issuing a unique player ID to a user who has undergone a predetermined registration procedure, 2) a card registration procedure process for enabling use of a game card, 3) an electronic payment medium linking process, 4) It is possible to perform account setting for electronic settlement, 5) deposit processing to an account using cash or a credit card, 6) settlement processing such as payment of play consideration, and 7) storage management of settlement history.

  The online shopping management unit 204 is a functional unit that realizes online purchase of candidate characters and items, a lottery right, an event participation right, and the like. This can be realized in the same manner as known online shopping.

  The game management unit 210 performs various processes related to game play. Since this embodiment is a client-server online game, the game management unit 210 receives an execution request from the player terminal 1500, activates the game of this embodiment, and performs game play while communicating with the player terminal 1500. To provide the player terminal 1500 with data necessary for the operation.

  And the game management part 210 of this embodiment contains the selection pattern setting part 212, the priority character setting part 214, the trial character selection part 216, the trial control part 218, and the information disclosure control part 220. . Of course, functional units other than these can be included as appropriate.

  The selection pattern setting unit 212 sets a method for selecting a trial character from unacquired characters. In the present embodiment, a trial character selection screen W4 (see FIG. 5) is displayed and set according to a designation operation input for manual selection or automatic selection. When automatic selection is designated, any one of “evolution”, “attribute”, “friend possession”, and “compatibility” is selected and set as an automatic selection pattern.

  The priority character setting unit 214 sets an unacquired candidate character (priority candidate object) that appears preferentially as a trial character. In this embodiment, the priority character definition data is updated in accordance with the setting operation by the game administrator.

The trial character selection unit 216 selects a trial character (sample object) from among a plurality of candidate characters (unacquired characters) not acquired by the player.
In particular,
1) When the automatic selection pattern is “evolved”, an unacquired character when the character has evolved is selected as a trial character for each player character 4 that is an acquired character organizing the deck.
2) When the automatic selection pattern is “attribute”, an unacquired character having the same attribute as the attribute set for the character is selected as a trial character for each player character 4.
3) When the automatic selection pattern is “owned by friends”, a candidate character that has not been acquired by the player and has been acquired by the friend player is selected as a trial character.
4) When the automatic selection pattern is “compatibility”, the test character is an unacquired character that satisfies the compatibility condition that the compatibility set between the player character 4 and the unacquired character is considered to be compatible. Choose as.
5) For each player character 4, an unacquired character with a level equal to or higher than the level of the character is selected as a trial character.
6) When a plurality of trial characters are selected, a selection probability is set for each trial character, and a trial character that appears in the game is selected by a lottery based on the selection probability.

In selecting a trial character to appear in 6), more specifically,
6-1) Using the difference between the attribute set for the player character 4 and the attribute set for the trial character, the selection probability of the trial character is set.
6-2) The selection probability of the trial character is set using the difference between the level of the player character 4 and the level of the trial character.
6-3) The selection probability of the priority character set by the priority character setting unit 214 is set higher than other trial characters.
6-4) The selection probability of the trial character is set using the selection probability setting condition based on the play history of the player.
6-5) The selection probability of the trial character is set using the selection probability setting condition based on the charging history of the player.

The trial control unit 218 performs activation control of the trial system.
In particular,
1) It is detected that the game progress condition satisfies the trial activation condition, and the trial activation character to be replaced with the trial character is specified.
2) Display control of the trial activation notification 50 is performed.
3) Character replacement control is performed between the trial activation character with the character replacement effect 52 and the trial character to appear.
4) Notification control of the appearance notification 54 is performed.
5) Make the trial character appear and appear temporarily in the game, and demonstrate the ability set for the trial character.

However, the trial control unit 218 does not allow the trial character to appear / appear when the game progress status is the given appearance prohibition status, and causes the trial character to appear / appear when the game progress status is not the appearance prohibition status.
As the activation prohibition situation, for example, a situation in which a given milestone in the game progress can be cleared can be set. For example, the situation is such that a stage character is cleared or a game is cleared by the appearance and activation of a trial character.

  The information disclosure control unit 220 performs control to disclose information related to the trial character to the player. In the present embodiment, display control of the information disclosure unit 45 (see FIG. 5) on the trial character selection screen W4 and the information disclosure unit 62 (see FIG. 12) on the appearing trial character confirmation screen W6 is performed. The information disclosure unit 62 can disclose information (acquisition guide 64) for the player to acquire a trial character that appeared in the game. The information disclosure method is not limited to display control. For example, an e-mail including disclosure information may be created and transmission controlled to an e-mail address specified at the time of user registration.

  The sound generation unit 290 is realized by, for example, a digital signal processor (DSP), a processor such as a voice synthesis IC, an audio codec that can play back an audio file, and generates an audio signal and outputs it to the sound output unit 390. The sound output unit 390 is realized by a speaker or the like that emits sound based on the audio signal output from the sound generation unit 290. Since the present embodiment is an online game, the sound generation unit 290 of the present embodiment may be configured to further generate data for playing BGM and sound effects of the game on the player terminal 1500.

  The image generation unit 292 is realized by, for example, a processor such as a GPU or a digital signal processor (DSP), a program such as a video signal IC or a video codec, an IC memory for a drawing frame such as a frame buffer, or the like. Then, the image generation unit 292 generates data for displaying an image of the game screen on the player terminal 1500 based on the processing result by the game management unit 210. In addition, other images necessary for system management are generated and an image signal is output to the image display unit 392.

  The image display unit 392 displays various images for system management based on the image signal input from the image generation unit 292. For example, it can be realized by an image display device such as a flat panel display, a cathode ray tube (CRT), a projector, or a head mounted display. In the example of FIG. 1, the touch panel 1108 corresponds.

  The communication control unit 294 executes data processing related to data communication, and realizes data exchange with an external device via the communication unit 394.

  The communication unit 394 is connected to the communication line 9 to realize communication. For example, it is realized by a wireless communication device, a modem, a TA (terminal adapter), a cable communication cable jack, a control circuit, or the like. In the example of FIG. 1, the communication device 1153 corresponds.

  The storage unit 500 stores a system program for realizing various functions for causing the processing unit 200 to control the server system 1100 in an integrated manner, a program necessary for managing a game, various data, and the like. Further, it is used as a work area of the processing unit 200, and temporarily stores calculation results and the like executed by the processing unit 200 according to various programs. Such a function is realized by, for example, an IC memory such as a RAM or a ROM, a magnetic disk such as a hard disk, an optical disk such as a CD-ROM or DVD, an online storage, or the like. In the example of FIG. 1, a storage medium such as an IC memory 1152 and a hard disk, and a storage 1140 correspond to this.

  FIG. 14 is a diagram illustrating examples of programs and data stored in the storage unit 500 according to the present embodiment. The storage unit 500 includes a system program 501, a server program 502, a distribution client program 503, game stage initial setting data 510, enemy character initial setting data 512, item initial setting data 514, and candidate character initial setting data. 520, character evolution lineage setting data 530, character compatibility setting data 540, manual selection trial character candidate list 550, and priority character list 560 are stored in advance.

In addition, the storage unit 500 includes user management data 600 as data to be sequentially generated and updated,
The play data 700 and the current date and time 900 are stored. In addition, information such as timers, counters, and various flags can be stored as appropriate.

  The system program 501 is a basic program for realizing basic input / output functions necessary as a computer by being read and executed by the processing unit 200.

  The server program 502 is a program for realizing a function as a game server for online games. In the present embodiment, functions as the user management unit 202, the online shopping management unit 204, and the game management unit 210 can be realized.

  The distribution client program 503 is a program to be executed on the player terminal 1500 in order to execute the game. The distribution client program 503 may be realized as a dedicated program, for example. Or if the game of this embodiment is implement | achieved as a web game, the web technique which controls a screen display actively using Java (registered trademark), CSS (Cascading Style Sheets), etc. with HTML based on a web browser. Alternatively, it may be realized by using a plug-in such as Adobe (registered trademark) Flash. Of course, other methods may be used.

  The game stage initial setting data 510 is prepared for each game stage, and defines the game space of each game stage, the definition data of the types and appearance timings of the enemy characters 6 that appear on the stage, the stage clear conditions, and the like.

The enemy character initial setting data 512 is prepared for each type of the enemy character 6 appearing in the game, and stores various data necessary for displaying and operating the character.
One enemy character initial setting data 512 is, for example, display data (for example, character model, texture data, motion data, etc.) for displaying the character on the game screen in association with the character type, and the character's ability. Parameter values (for example, life value, attack power, defense power, range, etc.). Of course, data other than these can be included as appropriate.

Item initial setting data 514 is prepared for each type of item appearing in the game, and stores various data necessary for displaying the item and exhibiting the effect in the game.
One item initial setting data 514 includes, for example, display data for displaying the item on the game screen in association with the item type, and effect definition data for defining the action effect of the item. Of course, data other than these can be included as appropriate.

The candidate character initial setting data 520 is character initial setting data that can be acquired by the player and can be used as the player character 4, and is prepared for each character type.
One candidate character initial setting data 520 includes, for example, as shown in FIG. 15, a character type 521, an evolution level 522, a character attribute 523, an initial ability parameter value list 524, comment data 525, and acquisition guide data 526. And including. Of course, data other than these can be included as appropriate.

  The initial ability parameter value list 524 stores data indicating initial values of various ability values of the character. In the present embodiment, data such as life value, attack power, defense power, skill setting data that defines the type and effect of special skills, and the like are stored. Of course, data other than these can be included as appropriate.

  The explanation data 525 is data explaining the ability of the character, and is text data or moving picture data. Information disclosure section 33 (see FIG. 4) of evolution selection screen W3, information disclosure section 45 (see FIG. 5) of trial character selection screen W4, and character explanation 63 (see FIG. 12) of appearance trial character confirmation screen W6. Is displayed.

  The acquisition guide data 526 is text data or moving image data for explaining how to obtain the character and how to obtain the character and hint data. It is displayed on the acquisition guide 64 of the appearing trial character confirmation screen W6 (see FIG. 12).

Returning to FIG. 14, the character evolution lineage setting data 530 is data defining which candidate character evolves to which candidate character, and is prepared for each evolutionary lineage.
For example, as shown in FIG. 16, the character types 532 of candidate characters on the evolutionary lineage are stored in the order of the evolution level 531.

  Returning to FIG. 14, the character compatibility setting data 540 defines the compatibility between candidate characters. For example, as shown in FIG. 17, for each character type 541, a friendly character type list 542 that is a list of character types of other candidate characters having good affinity with the character is stored in association with each other.

  Returning to FIG. 14, the manual selection trial character candidate list 550 is data that is referred to when the trial character selection pattern is designated as “manual selection”, and is a candidate character to be a trial character. It is a list. For example, as shown in FIG. 18, in association with a character type 551, a trial available condition 552 that is a condition that allows selection as a trial character candidate and a trial cost 553 are stored in association with each other. Of course, data other than these can be included as appropriate.

  The testable condition 552 is, for example, a condition based on the game progress status (for example, clearing the third stage), a condition based on the play history (for example, the player level “2” or higher, the number of times played 100 times or more, the game over 10 Conditions based on the item being used (for example, the player character 4 is equipped with a predetermined item, the specific item has been acquired, etc.), conditions based on the charging history (for example, the charging frequency is above the reference value, charging The total amount can be set as appropriate according to the game content.

  Returning to FIG. 14, the priority character list 560 is a list of character types that preferentially appear as trial characters. In this embodiment, a game maker or administrator performs setting operations in advance and manages them. For example, it is preferable to set a special character provided for a limited time, etc. and use it for indirect notification using a trial system.

  User management data 600 is prepared for each player registered as a user. For example, as shown in FIG. 19, one user management data 600 includes a unique player ID 601, a player level 602 that is automatically given based on play results, play history, and the like, and indicates the skill level of the player. A friend list 603 for storing a player ID; a consideration payment point 604 used to set a candidate character set with a trial cost as a trial character; acquired character management data 610; play history data 620; Billing history data 622 is stored. Of course, other data can be stored as appropriate.

  Since the setting of the friend list 603 can be realized in the same manner as a known online game, a description thereof is omitted here.

  The consideration payment point 604 stores parameter values consumed for consideration payment in the game, such as the remaining amount of virtual currency and the amount of a predetermined item. In this embodiment, the remaining amount of virtual currency is stored.

Acquired character management data 610 is prepared for each candidate character already acquired and acquired by the player (registered user), that is, the acquired character, and stores various data describing the state of the character at the time of data saving.
Specifically, one acquired character management data 610 includes, for example, a character ID 611, an experience value 612 at save, an evolution level 613 at save, an ability parameter value list 614 at save, and an equipment item list 615 at save. , Usage frequency data 616 is stored. Of course, data other than these may be stored as appropriate.

  The character ID 611 is unique identification information composed of a combination of a character type, a serial number, and a code representing a character attribute. The usage frequency data 616 is the frequency at which the acquired character is used for game play. When the acquired character is used as a player character 4 for game play, the saved experience value 612, saved evolution level 613, saved ability parameter value list 614, saved equipment item list 615, and usage frequency data 616 are: After the game play, the game is updated to reflect the latest play result.

  The play history data 620 stores the character ID of the player character 4 organized in the deck, game play results, and the like in association with the game play date and time. Updated at the end of game play.

  The charge history data 622 includes payment for game play, payment for extended game play time, payment for paid lottery in the game, and payment for purchasing items and candidate characters through online shopping using the player ID 601. It is a history such as. It is updated for each consideration payment subject to restoration.

Returning to FIG. 14, the play data 700 stores various data prepared for each game being played and describing the progress of the game.
For example, as shown in FIG. 20, one play data 700 includes a player ID 701, a stage ID 703 for storing identification information of a game stage currently being played, deck management data 710, a trial character selection pattern 720, and manual operation. A selection trial character list 722, an automatic selection trial character list 730, an appearance probability list by trial character 738, enemy character management data 740, a trial activation count 742, an appearance trial character list 744, Play result data 746 is stored. Of course, other data can be stored as appropriate depending on the game content and the like.

  The deck management data 710 stores various data describing the latest status of the acquired characters forming the deck, that is, the player character 4 (4a, 4b,...; See FIG. 3). For example, as shown in FIG. 21, for each deck setting frame 711, a player character ID 712 indicating a set character, an experience value 713, an ability parameter value list 714, and an equipment item list 715 are stored in association with each other. To do. Of course, data other than these may be stored as appropriate.

  The experience value 713 is copied from the saved experience value 612 of the acquired character management data 610 of the user management data 600 at the start of the game, and is updated step by step as the game progresses.

  Returning to FIG. 20, the trial character selection pattern 720 stores the type of selection pattern (information indicating manual selection or automatic selection) selected and input by the player on the trial character selection screen W4 (see FIG. 5).

  The manually selected trial character list 722 stores the character ID 611 of the acquired character that the player designates manual selection on the trial character selection screen W4 and is selected as the trial character by the player himself from the option display unit 44. The order of the list is the order of appearance.

  The automatic selection trial character list 730 stores a character ID 611 of an acquired character that the player designates automatic selection on the trial character selection screen W4 and is automatically selected as a trial character by the computer. For example, the trial character list 732 is stored for each player character ID 731 indicating the player character 4 that forms the deck.

  The appearance probability list 738 for each trial character is the appearance probability for each trial character, and stores the appearance rate for each character that can appear at that timing for each trial activation.

  The enemy character management data 740 is prepared for each enemy character 6 that has appeared in the game space, and stores various data describing the latest situation of the enemy character. For example, data indicating the status of the enemy character such as hit points and the number of remaining bullets is stored.

  The trial activation count 742 is reset before the game play starts, and is counted up every time the trial system is activated during the game play to indicate the total number of times.

  The appearing trial character list 744 is reset before the game play starts, and when a trial character appears and appears during the game play, the character ID of the trial character is newly updated.

  The play result data 746 stores game play result information. It is initialized before the game starts and is updated sequentially as the game progresses. The content of the grade information stored can be set as appropriate according to the content of the game.

[Description of process flow]
22 to 23 are flowcharts for explaining the flow of processing in the server system 1100. The processing flow described here is implemented by the server system 1100 executing the server program 502. It is assumed that the player has already completed user registration and acquisition of candidate characters. In addition, it is assumed that the player terminal 1500 of the player executes the distribution client program 503, establishes data communication with the server system 1100, and completes login.

  The server system 1100 first secures a storage area for the play data 700, sets a player ID 701, and executes a game stage selection process to be played (step S8).

  Next, the server system 1100 executes deck organization processing, and accepts selection of acquired characters used in the game. That is, selection of the player character 4 is accepted (step S10). The deck organization process can be realized in the same manner as a game using a known deck. That is, an empty (colored) deck setting frame and a list of acquired characters are displayed, and a character is set in the relationship of one acquired character in one deck setting frame in accordance with a selection setting operation by the player. The setting result is stored in the play data 700 as deck management data 710.

  Next, the server system 1100 executes selection acceptance processing for a selection pattern of trial characters (step S12). That is, the trial character selection screen W4 (see FIG. 5) is displayed on the player terminal 1500, and the trial character selection pattern of the play data 700 is displayed according to the operation input to the manual selection designation operation icon 41 or the automatic selection designation operation icon 42. 720 is set (see FIG. 20).

  If “manual selection” is designated (manual in step S14), the server system 1100 executes a trial character manual selection process (step S16), and if “automatic selection” is designated (step S16). The automatic test character selection process is executed (step S18).

  FIG. 24 is a flowchart for explaining the flow of trial character manual selection processing in the present embodiment. In this process, the server system 1100 first displays the setting frame 43 (see FIG. 5) on the trial character selection screen W4, and displays options by referring to the manual selection trial character candidate list 550 (see FIG. 14). The part 44 is displayed, and the comment data 525 (see FIG. 15) of the selected character is displayed on the information disclosing part 45 (step S40).

  Next, the server system 1100 sets the manually selected trial character list 722 of the play data 700 in accordance with the character selection operation input (step S42; see FIG. 20). Here, referring to the trial selection candidate character list for manual selection 550 (see FIG. 18), if a value is set for the trial cost 553 for the selected trial character (YES in step S44), This is notified to the player by the cost display 46 (see FIG. 5) (step S46).

  If a predetermined selection confirmation operation input is detected (YES in step S48), payment processing for the trial cost 553 of the manually selected character, that is, processing related to user authentication and settlement of payment is executed (step S50). ). Then, the characters registered in the manually selected trial character list 722 are rearranged in descending order of the trial costs, the appearance order is set and determined (step S52), and the trial character manual selection process is terminated.

  FIG. 25 is a flowchart for explaining the flow of the trial character automatic selection process in the present embodiment. In this process, the server system 1100 first determines in the lottery process which automatic selection pattern among “evolution”, “attribute”, “friend possession”, and “compatibility” is to be used when automatically selecting a trial character ( Step S70).

  The lottery probabilities in the lottery may be equal to each of the four patterns, or a weighting process may be appropriately executed. As an example of the weighting process, the user management data 600 of the player is referred to, and a given specific attribute high ratio condition such as the ratio of the character attribute of the acquired character being biased to a reference value or more is satisfied (for example, the whole 80% or more of a specific character attribute), it may be determined that the biased character attribute is concerned and the lottery probability of the automatic selection pattern “attribute” may be weighted higher than others. Further, when the number of registrations in the friend list 603 is “0”, the lottery probability of the automatic selection pattern “owned by friends” may be set to “0”. Also, by determining the compatibility between acquired characters, if the ratio of the combination that is a good match falls below the reference value and satisfies a given good combination minority condition, the lottery probability of the automatic selection pattern “compatibility” is increased more than others It is good.

  When the automatic selection pattern “evolution” is selected (YES in step S72), the server system 1100 has an unacquired character with a higher evolution level on its evolution lineage for each player character 4 that forms the deck. Is extracted and registered in the automatically selected trial character list 730 of the play data 700 (step S74). Then, the trial character automatic selection process ends.

  If the automatic selection pattern “attribute” is selected (YES in step S76), the server system 1100 has the same attribute and the same character attribute as the player character 4 for each player character 4 organizing the deck. Unacquired characters of higher levels are extracted and registered in the trial character list 730 (step S78). Then, the trial character automatic selection process ends.

  If the automatic selection pattern “owned by friends” is selected (owned by friends in step S80), the server system 1100 displays the player's acquired character management data 610 (see FIG. 19) and the friend list of the player. Compared with the acquired character management data 610 of the user management data 600 of the friend player registered in 603, a candidate character that has been acquired by the friend player but not yet acquired by the player himself is extracted, and the trial character list 730 is extracted. (Step S82). Then, the trial character automatic selection process ends.

  If the automatic selection pattern “compatibility” is selected (compatibility in step S80), the server system 1100 refers to the usage frequency data 616 of the acquired character management data 610, and determines the acquired character of the player. A predetermined number in the order of use frequency is extracted as a high use frequency character from the inside (step S84). Then, an unacquired character having a good compatibility with the frequently used character is extracted and registered in the trial character list 730 (step S86), and the trial character automatic selection process is terminated.

  Returning to FIG. 22, if the trial character manual selection process or the trial character automatic selection process is executed, the server system 1100 initializes the trial activation count 742 of the play data 700 to “1” (step S100). Then, the appearance trial character list 744 is initialized to an unregistered state (step S102), and the game progress control is started (step S104).

  When the game progress control is started, the turn control is started so that the player and the enemy alternate with the attack turn. If the game progresses in real time without distinguishing the turn, of course, the turn control is unnecessary.

  Since the start of the game, the server system 1100 always monitors the detection of trial activated characters. Specifically, if there is a player character 4 that satisfies the trial activation condition at the operation control timing of the player character 4 (YES in step S106) (YES in step S108), the trial activation character is selected. It is considered to have been detected. In the present embodiment, if there is a player character 4 for which an attacking action is designated by the player in the player turn, the character is recognized as a trial activation character.

  Then, if a trial activation character is detected (YES in step S108) and the trial character selection pattern 720 is set to “manual” (manual in step S110), does the server system 1100 activate the trial? The trial activation probability used for the lottery of “No” is set as a predetermined standard value (step S112).

  If a trial trigger character is detected (YES in step S108), but the trial character selection pattern 720 is set to “automatic” (automatic in step S110), the server system 1100 further determines the trial promotion item. The presence or absence of use is determined (step S114).

  The trial promotion item is a paid item that can make the trial activation higher than when it is not used, and can be purchased through online shopping. Of course, it may be given to the player as a bonus in the game. In this embodiment, when the trial activation character is equipped with this trial promotion item, it determines with the said item being used.

  If not used (NO in step S114), the server system 1100 sets the trial activation probability to a predetermined standard value as in the case where the selection pattern is “manual” (step S112). Is used (YES in step S114), a predetermined correction value k1 is added to the trial activation probability to correct the probability higher (step S116).

23, the server system 1100 refers to the play history data 620 and the charge history data 622 (see FIG. 19) of the user management data 600 of the player, and adds a correction value k2 corresponding to the play history and the charge history. And correct it (step S130).
Specifically, for example, the correction value k2 can be set to be smaller as the play frequency is higher, and the correction value k2 can be smaller as the billing frequency is higher. As a result, the frequency of trial activation for players who are familiar with playing the game many times can be kept lower than that for beginners.

  Next, the server system 1100 executes an activation lottery to which the trial activation probability is applied (step S132). If the lottery result is a trial activation (YES in step S134), it is determined whether the current game progress status corresponds to the activation prohibition status (step S136).

  The activation prohibition situation is a situation in which a given milestone in the game progress can be cleared, and the trial character can exert a cheat-like effect in the game and can have a significant impact on the game progress It is. The definition of the activation prohibition situation can be appropriately set according to the game content. For example, if you defeat a boss character, the battle with that boss character when you clear the stage, if you win the battle, rare items and skills, the battle when you can acquire the right to challenge the secret stage, etc. Can be set to the activation prohibition status.

  If it is determined that the activation prohibition situation is not satisfied (NO in step S136), the server system 1100 executes a trial control process (step S138).

  FIG. 26 is a flowchart for explaining the flow of trial control processing in the present embodiment. In this process, the server system 1100 refers to the trial character selection pattern 720 of the play data 700 (see FIG. 20). When the trial character selection pattern 720 is set to “manual” (manual in step S150), the server system 1100 registers the trial character that appears in the current trial in the order of registration in the manual selection trial character list 722. A character whose (order of registration rearranged in step S52) matches the trial activation count 742 is determined (step S152).

  On the other hand, when the trial character selection pattern 720 is set to “automatic” (automatic in step S150), the server system 1100 executes the appearance probability setting process for each character in the automatic selection trial character list 730. An appearance probability is set (step S154).

  FIG. 27 is a flowchart for explaining the flow of appearance probability setting processing in the present embodiment. In this process, the server system 1100 first sets the trial activated character and the character associated with the trial activated character certified in step S108 (see FIG. 22) in the automatically selected trial character list 730 as the trial activated character. The appearance probability for each character based on the level difference from the character is provisionally (step S180).

  Specifically, the appearance probability is set to be relatively higher as the difference from the level of the trial activated character is smaller. Since the characters in the automatic selection trial character list 730 are higher than the trial activation character level, it can be said that the appearance probability is set higher as the level is closer to the trial activation character level. The set appearance probability is stored in a trial character-specific appearance probability list 738 (see FIG. 20). The level referred to here is not limited to the evolution level. In the configuration in which the character level is set separately from the evolution level, the character level may be set based on the difference between the character levels.

  Next, the server system 1100 executes loop A for each character associated with the trial activated character in the automatic selection trial character list 730 (steps S182 to S204).

  First, in the loop A, the server system 1100 statistically processes the character attributes that have been made the player character 4 in the past from the player's play history data 620 (see FIG. 19), and calculates the use frequency for each character attribute (step S184). ).

  Then, if the frequently used character attribute satisfies the high use frequency condition in which the character attribute is biased toward the specific character attribute (YES in step S186) and the processing target character corresponds to the specific character attribute (in step S188) YES), the server system 1100 determines that the player is concerned with the use of the character with the specific character attribute, and makes the appearance probability of the processing target character appear more easily than the character with the other attribute. (Step S190). However, although there is a bias toward the specific character attribute, if the character to be processed does not correspond to the specific character attribute (NO in step S188), the appearance probability is relatively lowered (step S192).

  Next, the server system 1100 calculates the purchase frequency of candidate characters from the charging history data 622 (see FIG. 19) of the player (step S194). If the purchase frequency has reached a predetermined high frequency authorization value (YES in step S196), the appearance probability of the processing target character is lowered (step S198).

  Next, the server system 1100 refers to the priority character list 560, and when the character to be processed corresponds to the priority character (YES in step S200), increases the appearance probability (step S202) and ends the loop A. (Step S204).

  Then, if the loop A is executed for all characters associated with the trial activated character in the automatic selection trial character list 730, the appearance probability setting process is terminated.

  Returning to FIG. 26, when the appearance probability setting process is completed, the server system 1100 displays each appearance probability from among all the characters associated with the trial activated characters in the automatically selected trial character list 730. The lottery process is executed so as to be selected in step S210, and a trial character appearing in the current trial is selected (step S210).

  If the trial character to appear in step S152 or S210 is selected, the server system 1100 additionally registers the selected trial character in the appearance trial character list 744 (see FIG. 20) of the play data 700. (Step S220).

  Next, the server system 1100 displays the trial activation notification 50 on the game screen (step S222; see FIG. 10 (1)), displays the character replacement effect 52, and selects the trial activation character in step S152 or step S210. It replaces with the selected trial character, and the appearance notification 54 is displayed, and the identification display of the trial character 53 is started (step S224; see FIGS. 10 (2) to 10 (3)). Then, motion control is performed so that the ability of the trial character is exhibited (step S226; see FIG. 11 (1)), and the play result data 746 is updated (step S228).

  Note that the identification display of the trial character 53 is limited to the game screen displayed on the player terminal 1500 of the player to which the trial character 53 is assigned in multi-play, and the player terminal of another player playing together. The game screen displayed at 1500 may not be identified.

  The “replacement” referred to here is an apparent replacement on the game screen. Even if the appearance of the trial activation character disappears from the game screen, the data of the character remains on the deck management data 710 as it is.

  Next, the server system 1100 executes the character replacement effect 52 again, this time erasing the trial character and returning it to the trial activation character (step S230; see FIGS. 11 (2) to 11 (3)). Then, the trial activation count 742 is incremented by “1” (step S232), and the trial control process is terminated.

  Returning to FIG. 22, if there is no player character 4 that satisfies the trial activation condition (NO in step S108), the server system 1100 moves to FIG. 23 in response to an operation input instead of executing steps S110 to S138. Then, the motion control of the player character 4 is executed (step S240).

  Next, the server system 1100 executes automatic control of the enemy character 6 (step S250), and updates the play score (step S252).

Next, the server system 1100 determines whether the game end condition is satisfied.
In this embodiment, an affirmative determination is made when a predetermined game end operation input is detected, when all player characters 4 are defeated, or when the stage is cleared.

  If the game end condition is not satisfied (NO in step S254), the process returns to step S106. If the game end condition is satisfied (YES in step S254), the appearance trial character confirmation screen W6 is displayed on the player terminal 1500 with reference to the appearance trial character list 744 of the play data 700 (step S256). ; See FIG.

  Next, the server system 1100 displays the evolution selection screen W3 for each player character 4 that satisfies the evolution possibility condition (step S260; see FIG. 4), and satisfies the evolution possibility condition according to the selection operation on the evolution selection screen W3. The player character 4 is evolved (step S262).

  Specifically, the acquired character management data 610 of the player character 4 that satisfies the evolving condition is deleted from the user management data 600 of the player, and the acquired character management data of the candidate character selected as the evolution destination instead. 610 is added. That is, the player character 4 satisfying the evolution possible condition is replaced with the evolution destination character. At this time, the usage frequency data 616 may be taken over from the deleted player character 4.

  Then, the server system 1100 saves data in the user management data 600 of the player, that is, updates the acquired character management data 610 and the play history data 620 (step S264), and ends the series of processes.

  As described above, according to the present embodiment, by realizing a trial system, when selection of an object that has not been used is irreversible, or when it takes a certain amount of labor and cost to make it reversible, It becomes possible to realize a new technique for supporting the determination of whether or not to select an object.

  In the present embodiment, the character (trial character; sample object) that appears in the trial system can be manually selected by the player himself or can be automatically selected. In the case of automatic selection, a character having a higher evolution level in the evolutionary lineage of the player character 4 can be selected as a trial character, or a character having the same attribute as the attribute of the player character 4 can be selected as a trial character. In addition, the player can select a character that is owned by the friend player but not owned, or can select a character that is compatible with the player character 4. That is, useful information can be selectively provided by paying attention to four different viewpoints of evolution, character attributes, friendship status, and compatibility between characters.

  Furthermore, among the automatically selected trial characters, the selection probability of a character that actually appears / appears in the game can be set such that the closer to the evolution level of the player character 4 is, the more likely it is to appear. By setting the characters so that they are more likely to appear, it is possible to preferentially provide information that is highly useful to the player.

  On the other hand, the usefulness of providing information through the trial system is relative for players who are proficient in the game, and for players who frequently purchase candidate characters and who are considered to already have many candidate characters. Therefore, by adjusting the probability that the trial will be activated for such players, the frequency of information provision through the trial system is relatively lowered, and known information is repeatedly provided so that play is not disturbed. Consideration.

[Modification]
As mentioned above, although embodiment which applied this invention was described, the form of this invention is not limited to said example, The addition, omission, and change of a component can be given suitably.

[Part 1]
For example, in the above embodiment, the action RPG is taken as an example, but the game genre to which the present invention is applicable is not limited to this. If the selection of an object that has never been used is irreversible, or if it takes a certain amount of labor and cost to make it reversible, puzzle games, RPG, shooting, war games, simulation games, training The present invention can be applied to other genres such as games and music games.

  The case where a certain amount of labor or cost is required to make the selection of an object that has never been used reversible is, for example, the following case. In other words, by selecting a new object that has never been used, the original object before selection becomes unusable, and after the player makes some burden, the original object before selection can be used. . The burden on the player is to collect items for reversibility in the game until a predetermined numerical condition is satisfied, or to pay a predetermined price in in-game currency.

[Part 2]
Moreover, in the said embodiment, although the character was illustrated as an example of an object, the item which a player character uses may be sufficient. Specifically, the evolution of characters can be read as the evolution of weapons, armor, and vehicles.

[Part 3]
Further, the evolution of the object (character) in the above embodiment can be appropriately read as composition or modification of the object depending on the game contents.

[Part 4]
In the above embodiment, an online game is exemplified, but the present invention can be similarly applied to a game such as a native application that is executed by the player terminal 1500 in a stand-alone manner.
In this case, the functional configuration shown in FIG. 13 is realized by the player terminal 1500 (in this case, the player terminal 1500 can also be called a game device). Specifically, for example, as shown in FIG. That is, the operation input unit 100 corresponds to the direction input key 1502, the button switch 1504, and the touch panel 1506 (see FIG. 2). The processing unit 200 corresponds to the CPU 1551 of the control board 1550, and the IC memory 1552 and the memory card 1540 mounted on the control board 1550 correspond to the storage unit 500. The sound output unit 390 corresponds to the speaker 1510, the image display unit 392 corresponds to the touch panel 1506, and the communication unit 394 corresponds to the wireless communication module 1553.

Further, for example, a program and data as shown in FIG. 29 are stored in the storage unit 500 in the configuration. The game program 505 is a program for causing the processing unit 200 to realize the user management unit 202 and the game management unit 210 in the configuration.
Further, the processing flow of the player terminal 1500 in this case is the same as that shown in FIGS. 22 to 27, and the execution subject may be read as the player terminal 1500.

[Part 5]
In the above embodiment, the trial character appears and appears in the game space by replacing the trial activated character. However, as shown in FIG. 30, the player character 4a recognized as the trial activated character is displayed. The trial character 53 may appear separately while remaining in the game space. In this case, after the trial character 53 activates the ability, it is only necessary to leave the game space.

[Part 6]
In the above-described embodiment, the trial character 53 replaced with the trial activation character is configured to automatically activate the ability a predetermined number of times after the appearance, and then exit. However, until the player turn ends, the trial character 53 A configuration in which the player itself can temporarily operate 53 is also possible.

  Specifically, as shown in FIG. 31, steps S226 to S230 are omitted, the trial activated character is excluded from the operation target by the player, and a setting frame 711 for the trial character 53 is separately added to the deck management data 710. In addition, the trial character is set as an operation input target of the player (step S231). Then, as shown in FIG. 32, after step S108, step S109 is executed, and when the trial character 53 has already appeared, step S110 to step S231 are skipped. Further, as shown in FIG. 33, after a negative determination is made in step S106 of FIG. 32, the trial character 53 is erased from the game space and returned to the player character 4a recognized as the trial activation character (step S242). The trial character 53 may be set out of the operation target, and the player character 4a recognized as the trial activation character may be returned to the operation target (step S244).

[Part 7]
In addition, a function for optimizing the priority character list 560 (see FIG. 14) for the player may be added to the embodiment and the modification.
Specifically, prior to starting the game, the priority character list optimization process shown in FIG. 34 is executed. In this process, the server system 1100 calculates the usage frequency for each character attribute from the player's play history data 620 (step S300), and if there is a usage frequency bias with a high usage frequency of a specific character attribute (step S302). YES), an unacquired character corresponding to the specific character attribute is extracted and added to the priority character list 560 (step S304).

Further, the server system 1100 calculates the purchase frequency of candidate characters and items from the player's charging history data 622 (step S306), and the calculated purchase frequency satisfies a high frequency condition for regarding the player as an advanced player. If so (YES in step S308), the priority character list 560 is thinned out (step S310).
In addition, when employ | adopting the said structure, step S184-S198 of the appearance probability setting process (refer FIG. 27) which brings about the same effect can be abbreviate | omitted.

[Part 8]
In addition, “friend possession” (see FIG. 8) in the above embodiment can be expanded to “friend possession related”. In other words, the friend user 83 of the player 80 may select an object (for example, an object having a good affinity with these objects) having a given relationship with the acquired objects 84 and 85 as a sample object. . In that case, the compatibility between the objects is predetermined.

[Part 9]
Moreover, the lottery event which provides an object can be inserted in the said embodiment suitably.
Specifically, as shown in FIG. 35, an object assignment control unit 222 can be added to the game management unit 210. The object assignment control unit 222 draws an object to be given to the player and performs an object assignment control process to be given to the player. The object assignment control process is executed by, for example, a so-called login lottery executed free of charge when the player logs in. If the game is in progress, it is executed by an object drop by the enemy character 6 or an object giving event that occurs at random. Of course, it may be executed in other situations depending on the game contents.

  For example, as shown in FIG. 36 (1), the server system 1100 extracts grant object candidates excluding the trial character 53 given to the player at that time (step S330), and gives the flow of object grant control processing. A random lottery process using random number generation is selected from among object candidates (step S332). Then, the player gives the lottery granted object to the player (step S340) and gives the player (step S342).

  Alternatively, as illustrated in FIG. 36 (2), the server system 1100 sets a winning probability for each grant object candidate. However, the winning probability of the trial character 53 given to the player is set lower than the others (step S334). Next, a grant object may be selected by a lottery process using a winning probability for each grant object candidate (step S336), notification of the selected grant object (step S340), and grant (step S342).

DESCRIPTION OF SYMBOLS 4 ... Player character 22 ... Deck display part 25 ... Attribute display part 31 ... Evolution possible character 32 ... Evolution destination character 33 ... Information disclosure part 41 ... Manual selection designation operation icon 42 ... Automatic selection designation operation icon 45 ... Information disclosure part 46 ... Cost display body 50 ... Invocation notification 52 ... Character replacement effect 53 ... Trial character 54 ... Appearance notification 62 ... Information disclosure part 63 ... Character explanation 64 ... Acquisition guide 200 ... Processing part 202 ... User management part 210 ... Game management part 212 ... Selection pattern setting unit 214 ... Priority character setting unit 216 ... Trial character selection unit 218 ... Trial control unit 220 ... Information disclosure control unit 500 ... Storage unit 502 ... Server program 503 ... Distribution client program 505 ... Game program 520 ... Candidate Character initial setting 521 ... Character type 522 ... Evolution level 523 ... Character attribute 525 ... Explanation data 526 ... Acquisition guide data 530 ... Character evolution lineage setting data 540 ... Character compatibility setting data 550 ... Character candidate list 560 ... Priority character list 600 ... User management Data 602 ... Player level 603 ... Friends list 604 ... Points for consideration payment 610 ... Acquired character management data 616 ... Usage frequency data 620 ... Play history data 622 ... Billing history data 700 ... Play data 710 ... Deck management data 720 ... Trial Character selection pattern 722 ... Manual selection trial character list 730 ... Automatic selection trial character list 738 ... Appearance probability list by trial character 744 ... Appearance trial character Actor list 746 ... Play results data 1100 ... Server system 1150 ... Control board 1500 ... Player terminal 1550 ... Control board W2 ... Game screen W3 ... Evolution selection screen W4 ... Character selection screen W6 ... Character confirmation screen

Claims (16)

A program for causing a computer to execute a game in which a player selects an object to be used from among acquired objects.
Selecting means for selecting, as a sample object, an object that the player has not acquired from a plurality of candidate objects;
Control means for causing the sample object to temporarily appear in the game and exhibiting the ability set in the sample object;
A program for causing the computer to function as The selection means selects an object when the acquired object has evolved as the sample object.
The program according to claim 1. The selecting means selects an object having the same attribute as the attribute set for the acquired object as the sample object.
The program according to claim 1 or 2. The selection means selects an object at a level higher than the level of the acquired object as the sample object.
The program as described in any one of Claims 1-3. The selection means selects an object acquired by the friend player of the player as the sample object.
The program as described in any one of Claims 1-4. The selection means selects, as the sample object, an object having a given relationship with an object acquired by a friend player of the player.
The program as described in any one of Claims 1-4. Information disclosing means for disclosing information of the sample object;
The program as described in any one of Claims 1-6 for making the said computer further function as. The information disclosing means discloses information for the player to acquire the sample object;
The program according to claim 7. The selection means sets a selection probability for each of the candidate objects, and selects the sample object by lottery based on the selection probability.
The program as described in any one of Claims 1-8. The selection means sets the selection probability of the candidate object using the selection probability setting condition based on the play history of the player;
The program according to claim 9. The setting condition is a condition determined based on a usage history of a given item included in the play history.
The program according to claim 10. The setting condition is a condition determined based on a value of a given parameter included in the play history.
The program according to claim 10. Object granting means for lottering objects to be given to the player and giving them to the player. When the sample object appears, the sample object is deleted from the lottery candidate objects, or the sample object Object giving means for reducing the winning probability of the above-mentioned lottery,
The program as described in any one of Claims 1-12 for making the said computer function further as. When the control means makes the sample object appear, the sample object appears instead of the acquired object that has already appeared,
The program as described in any one of Claims 1-13. A game device for executing a game in which a player selects a use object from among acquired objects and plays the game,
Selecting means for selecting, as a sample object, an object that the player has not acquired from among a plurality of candidate objects;
Control means for causing the sample object to temporarily appear in the game and exhibiting the ability set in the sample object;
A game device comprising: A server system for communicating with a player terminal and allowing a player to play a game in which the player selects an object to be used from acquired objects and plays the game on the player terminal.
Selecting means for selecting, as a sample object, an object that the player has not acquired from among a plurality of candidate objects;
Control means for causing the sample object to temporarily appear in the game and exhibiting the ability set in the sample object;
Server system with

Images