JP6123060B2 - Information processing apparatus, program, information processing system - Google Patents

Description

  The present invention relates to an information processing technique for processing information about an object.

In recent years, so-called social games have become widespread as applications executed in social networking services (SNS). As such a social game, a digital card game using a card is known.
In addition, the main card and the sub card are selected by the user from the user's own cards, and the main card and the sub card are combined to change the main card ability parameter, and the sub card is changed from the user's own card. A game that is to be deleted is known (Patent Documents 1 and 2).

Japanese Patent No. 5086491 Japanese Patent No. 5153960

  In the compositing process, the user possesses a plurality of reference objects (corresponding to the sub-cards) satisfying the combination condition corresponding to the base object in order to realize the compositing process of the base object (corresponding to the main card). May be a requirement. In that case, the user needs to possess all the reference objects that satisfy the combination conditions in order to execute the synthesis process.

  At this time, it may be impossible or difficult for the user to obtain a reference object that the user does not have. However, a user who does not know the conditions for obtaining the reference object recognizes that it is impossible or difficult to obtain the reference object when deciding whether to execute the process for obtaining the reference object. Can not. In such a case, the user executes a process for obtaining the reference object with anxiety that it may be impossible or difficult to actually obtain the reference object.

  The present invention has been made in view of the above-described viewpoints, and an object of the present invention is to provide a reference object necessary for processing for changing an object, which is executed when a change condition including information indicating at least a plurality of objects is satisfied. An object is to provide an information processing apparatus, a program, and an information processing system that can eliminate anxiety that a user feels in the process for obtaining.

One embodiment of the present invention provides:
In an information processing apparatus accessible to a storage device that associates and stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for processing to change the object,
Based on a user instruction, a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to the object identification information of the selected object that is the selected object are displayed in a display format that can be identified to the user. Output means for outputting first output data for causing
Receiving means for receiving an instruction to specify any one of the plurality of objects based on an instruction of the user in response to the output of the first output data by the output means;
The output means further includes second output data for displaying an acquisition condition of the designated object when the user does not have the designated object that is the object designated by the instruction accepted by the accepting means. Output,
Information processing apparatus.

Another aspect of the present invention provides:
In an information processing apparatus accessible to a storage device that associates and stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for processing to change the object,
Based on the user's instruction, the user has a plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object that is the selected object, and the user has among the plurality of objects An information processing apparatus comprising: output means for outputting output data for causing a user to display an acquisition condition of an object that has not been displayed in a display format that can be identified by a user.

Another aspect of the present invention provides:
In an information processing apparatus accessible to a storage device that associates and stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for processing to change the object,
Based on a user instruction, a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to the object identification information of the selected object that is the selected object are displayed in a display format that can be identified to the user. Output means for outputting first output data for causing
Receiving means for receiving an instruction to specify any one of the plurality of objects based on an instruction of the user in response to the output of the first output data by the output means;
The output means further outputs a second output for displaying the degree of difficulty of obtaining the designated object when the user has never possessed the designated object that is the object designated by the instruction accepted by the accepting means. Output data,
Information processing apparatus.

Another aspect of the present invention provides:
A user terminal and a server configured to be communicable with the user terminal, and object identification information that identifies an object, and a change condition that includes a plurality of object identification information used for processing to change the object, An information processing system that can access a storage device that stores information in association with each other,
One of the user terminal and the server is
Based on a user instruction, a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to the object identification information of the selected object that is the selected object are displayed in a display format that can be identified to the user. Output means for outputting first output data for causing
Receiving means for receiving an instruction to specify any one of the plurality of objects based on an instruction of the user in response to the output of the first output data by the output means;
The output means further includes second output data for displaying an acquisition condition of the designated object when the user does not have the designated object that is the object designated by the instruction accepted by the accepting means. Output,
Information processing system.

Another aspect of the present invention provides:
A computer that can access a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for processing to change the object in association with each other,
Based on a user instruction, a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to the object identification information of the selected object that is the selected object are displayed in a display format that can be identified to the user. Means for outputting first output data for causing
Means for receiving an instruction to specify any one of the plurality of objects based on an instruction from the user in response to the output of the first output data;
Means for outputting second output data for displaying an acquisition condition of the designated object when the user does not have the designated object which is an object designated by the accepted instruction;
It is a program to make it function as.

Another aspect of the present invention provides:
In an information processing apparatus accessible to a storage device that associates and stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for processing to change the object,
First output for outputting first output data for displaying acquisition conditions for a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to the object identification information of a selected object that is a selected object Means,
In response to the output of the first output data by the first output means, a request for restricting the first specified object, which is an object specified by the user, from being used in a predetermined process is issued. First receiving means for receiving;
First restriction means for restricting the first designated object from being used in the processing in response to the request being accepted by the first acceptance means;
Is an information processing apparatus.

Another aspect of the present invention provides:
A user terminal and a server configured to be communicable with the user terminal, and object identification information that identifies an object, and a change condition that includes a plurality of object identification information used for processing to change the object, An information processing system that can access a storage device that stores information in association with each other,
One of the user terminal and the server is
First output for outputting first output data for displaying acquisition conditions for a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to the object identification information of a selected object that is a selected object Means,
In response to the output of the first output data by the first output means, a request for restricting the first specified object, which is an object specified by the user, from being used in a predetermined process is issued. First receiving means for receiving;
First restriction means for restricting the first designated object from being used in the processing in response to the request being accepted by the first acceptance means;
An information processing system comprising:

Another aspect of the present invention provides:
A computer that can access a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for processing to change the object in association with each other,
Means for outputting first output data for displaying acquisition conditions for a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to the object identification information of the selected object that is the selected object;
Means for accepting a request for restricting the first designated object, which is an object designated by the user, from being used for a predetermined process in response to the output of the first output data;
Means for restricting the first designated object from being used in the processing in response to the request being accepted;
It is a program that functions as

The figure which shows the basic composition of the game system of 1st Embodiment. The block diagram which shows the structure of the user terminal of 1st Embodiment. The block diagram which shows the structure of the game server of 1st Embodiment. The figure for demonstrating conceptually presentation of the acquisition conditions of the reference card of 1st Embodiment. The figure which shows the structural example of the card data table of 1st Embodiment. The figure which shows the structural example of the evolution synthetic | combination data table of 1st Embodiment. The figure which shows the structural example of the quest data table of 1st Embodiment. The figure which shows the structural example of the possession card data table of 1st Embodiment. The figure which shows the structural example of the reservation data table of 1st Embodiment. The figure which shows the structural example of the possession log | history data table of 1st Embodiment. The figure which shows the structural example of the card | curd distribution data table of 1st Embodiment. The figure which shows an example of the image displayed on the user terminal at the time of execution of the game of 1st Embodiment. The figure which shows an example of the image displayed on the user terminal at the time of execution of the game of 1st Embodiment. The figure which shows an example of the image displayed on the user terminal at the time of execution of the game of 1st Embodiment. The figure which shows an example of the image displayed on the user terminal at the time of execution of the game of 1st Embodiment. The figure which shows an example of the image displayed on the user terminal at the time of execution of the game of 1st Embodiment. The functional block diagram of the game server of 1st Embodiment. The sequence chart which shows an example of the presentation process of the acquisition conditions of 1st Embodiment. The sequence chart which shows an example of the presentation process of the acquisition conditions of 1st Embodiment. The sequence chart which shows an example of the evolution synthetic | combination process of 1st Embodiment. The figure which shows an example of the image displayed on the user terminal at the time of execution of the game of 2nd Embodiment. The sequence chart which shows an example of the quest process of 2nd Embodiment. The figure which shows an example of the image displayed on the user terminal at the time of execution of the game of 3rd Embodiment. The sequence chart which shows an example of the reservation process of the evolutionary synthesis of 3rd Embodiment. The figure which shows an example of the image displayed on the user terminal at the time of execution of the game of 4th Embodiment. The sequence chart which shows an example of the presentation process of the acquisition conditions of 4th Embodiment. The figure for demonstrating notion of reservation registration and favorite registration of the reference card of 5th Embodiment. The figure which shows the structural example of the possession card data table of 5th Embodiment. The figure which shows an example of the image displayed on the user terminal at the time of execution of the game of 5th Embodiment. The figure which shows an example of the image displayed on the user terminal at the time of execution of the game of 5th Embodiment. The figure which shows an example of the image displayed on the user terminal at the time of execution of the game of 5th Embodiment. The figure which shows an example of the image displayed on the user terminal at the time of execution of the game of 5th Embodiment. The sequence chart which shows an example of the process of registration of 5th Embodiment. The sequence chart which shows an example of the presentation process of the acquisition conditions of 6th Embodiment. The sequence chart which shows an example of the presentation process of the acquisition conditions of 6th Embodiment.

(1) First Embodiment (1-1) Configuration of Game System Hereinafter, a game system 1 will be described as an embodiment of an information processing system.

FIG. 1 shows a system configuration example of a game system 1 according to the embodiment. As shown in FIG. 1, the game system 1 includes user terminals 10a, 10b, 10c,... And a game server 20. Each user terminal 10a, 10b, 10c can access the game server 20 through a communication network NW such as the Internet. The game server 20 is an example of an information processing device.
Each of the user terminals 10a, 10b, 10c,... Is a terminal operated by an individual user. For example, a feature phone, a smartphone, a tablet terminal, a personal computer, a television receiver (two-way communication function) It includes so-called multi-function smart TVs), and communication terminals such as portable game machines with communication functions. In the following description, when referring to the user terminals 10a, 10b, 10c,.

The game server 20 is a server that executes a game. The game server 20 includes image data that can be interpreted by a web browser (for example, image data described in a format such as HTML or XML. In the embodiment of the present invention, HTML data will be described as an example). A program that can be created is implemented.
The user terminal 10 includes a web browser that interprets and displays HTML data provided by the game server 20, and requests based on user operations on the web page by the user terminal 10 via the network. And the game process is executed by receiving the processing result of the game server 20.
The communication network NW is an information communication network configured by the Internet, a WAN (Wide Area Network), a LAN (Local Area Network), a dedicated line, or a combination thereof.

(1-2) Configuration of User Terminal The user terminal 10 will be described with reference to FIG.
As shown in FIG. 2, the user terminal 10 includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, an operation input unit 15, a display unit 16, a communication interface unit 17, A storage 18 is provided, and a bus 19 for transmitting control signals or data signals between the respective units is provided.

  The CPU 11 reads out programs and data stored in the ROM 12 and controls the overall operation in the user terminal 10 such as control signals with each unit in the user terminal 10 and timing processing of data signals. The CPU 11 also reads out the program stored in the storage 18 and various data necessary for executing the program, expands it in the RAM 13, and performs various processes such as data input / output processing, arithmetic processing, and determination processing associated with the execution of the program. I do. The RAM 13 temporarily stores data for arithmetic processing, determination processing, and the like by the CPU 11.

  For example, the CPU 11 loads a web browser stored in the storage 18 into the RAM 13 and executes it. And CPU11 is based on designation | designated of URL (Uniform Resource Locator) input by a user by the operation input part 15 grade | etc., Via the communication interface part 17, the data for displaying a web page from the game server 20, ie, Data of an object such as an HTML (HyperText Markup Language) document and an image associated with the document (hereinafter collectively referred to as “HTML data” as appropriate) is acquired via the communication interface unit 17 and is then used as a web browser. To interpret the HTML data. Various plug-ins for extending the browser function of the web browser may be mounted on the user terminal 10. An example of such a plug-in is a flash player by Adobe Systems Inc. in the United States. Alternatively, the HTML data in the present embodiment may be in the HTML5 format having a video and audio playback function.

  The web browser performs communication with the game server 20 in accordance with HTTP (HyperText Transfer Protocol). When a URL (Uniform Resource Locator) on a web page or an operation target (for example, a software button (hereinafter simply referred to as “button”)) is selected by the user operating the operation input unit 15, the web browser. In order to update the web page, an HTTP request including the selection result is transmitted to the game server 20. The web browser acquires HTML data from the game server 20 as an HTTP response, interprets it, and displays the web page on the display unit 16.

  The display unit 16 is a display device such as an LCD (Liquid Cristal Display) or an organic EL (Electro Luminescence) display. When an LCD (Liquid Cristal Display) monitor including thin film transistors arranged in pixel units in a matrix is applied, the display unit 16 displays the image of the web page on the display screen by driving the thin film transistors.

When the user terminal 10 is a button input type user terminal, the operation input unit 15 includes, for example, a plurality of instruction input buttons such as a direction instruction button, a determination button, and a numeric keypad for receiving a user operation input. It includes an interface circuit for recognizing a pressing (operation) input and outputting it to the CPU 11.
When the user terminal 10 is a touch panel input type user terminal, the operation input unit 15 mainly accepts touch panel type input by touching the display screen with a fingertip or a pen.

  The storage 18 is a storage device configured by, for example, a flash memory or an HDD (Hard Disk Drive).

(1-3) Configuration of Game Server The configuration of the game server 20 will be described with reference to FIG.
As shown in FIG. 3, the game server 20 includes a CPU 21, a ROM 22, a RAM 23, a communication interface unit 24, and a storage 25, and a bus 26 is provided for transmitting control signals or data signals between the units. ing. The game server 20 can have the same configuration as a general-purpose network server in terms of hardware.

  The CPU 21 reads out the programs and data stored in the ROM 22 and controls the overall operation in the game server 20 such as control signals for each part in the game server 20 and data signal timing processing. The CPU 21 also reads out a program stored in the storage 25 and various data necessary for executing the program, expands it in the RAM 23, and performs various processes such as data input / output processing, arithmetic processing, and determination processing associated with the execution of the program. I do. The RAM 23 temporarily stores data for arithmetic processing, determination processing, and the like by the CPU 21.

  For example, the storage 25 stores a program for providing a web service by performing communication according to HTTP with a web browser of the user terminal 10 as a client. The CPU 21 expands the program stored in the storage 25 on the RAM 23 and executes the program. Along with the execution of the program, the CPU 21 acquires an HTTP request from the user terminal 10 via the communication interface unit 24, executes processing according to the HTTP request, and includes HTML data (image data to be described later) including the execution result. An example) is returned to the user terminal 10 as an HTTP response.

  The storage 25 is an information recording device configured by, for example, a flash memory or an HDD (Hard Disk Drive), and stores a data table group 70 in addition to the above-described program. The data table group 70 (described later) includes a card data table, an evolutionary synthesis data table, a quest data table, a possessed card data table, a reservation data table, a possession history data table, and a card distribution data table. Each data table is appropriately accessed from the CPU 21 for reading and writing data.

(1-4) Presentation of card acquisition conditions for game of this embodiment A game executed in the game system 1 of this embodiment is a game executed by a user using a card as an object. In this game, for example, a user searches for an area on the game to acquire a card or an item, or a user battles against another user or NPC (Non-Player Character) using a card possessed by the user.
In the game of the present embodiment, card evolution synthesis processing (hereinafter simply referred to as “evolution synthesis” as appropriate) is processing for evolving a card possessed by a user when a predetermined condition is satisfied. The evolution synthesis of the card is a process of changing the card ID as will be described later in the example of the present embodiment, but may be a process of changing at least a part of card data (to be described later) corresponding to the card. In this case, the change target of the card data is not particularly limited, but for example, card parameters such as a card name, a card image, and rarity. Card evolution synthesis is an example of processing to change an object.
In order to execute evolutionary synthesis, the user selects a card he / she wants to evolve (that is, a card subject to processing for changing card data) from among the cards he / she owns (hereinafter referred to as “owned card” as appropriate). Select a base card. The card selected as the base card is an example of the selected object.
In evolutionary synthesis, for each base card, a combination condition of a plurality of cards (referred to as “reference cards”) necessary to evolve the base card is determined. When evolutionary synthesis is performed, the reference card used for evolutionary synthesis disappears from the user's possession card.
In the game of the present embodiment, the fact that the user possesses all of the plurality of reference cards that are combination conditions corresponding to the card selected as the base card by the user is a condition for evolving the selected card ( An example of a change condition).

In the game of the present embodiment, for example, a normal synthesis process and a sale process are provided as a process for the user to lose his / her possession card. In order to execute the normal compositing process, the user selects a base card as a card to be grown from his / her possessed cards. In normal synthesis processing, a change condition in which conditions for performing card change processing (for example, evolution synthesis processing) are defined is not determined for each base card, and the user can select a reference card from among possession cards as appropriate. You can choose. When the normal synthesis process is executed, the reference card disappears from the user's possessed card instead of the card parameter of the base card changing (for example, the card level and skill level increase).
In the selling process, a card selected from the user's possessed card (for example, a card unnecessary for the user) is sold instead of the user obtaining a selling price (for example, a point on the game) corresponding to the card. The lost card disappears from the user's possession card.

In the game of the present embodiment, consider a case where the user wants to evolve a desired card by evolutionary synthesis, but the user does not possess some or all of the reference cards necessary to evolve the card. In this case, it is necessary to wait for the evolutionary synthesis of the desired card until the user can obtain a new card (that is, the remaining reference card) that satisfies the reference card combination condition. However, if the user forgets the conditions for obtaining the remaining reference cards (hereinafter referred to as “acquisition conditions”), it is difficult to obtain the reference cards. In particular, the greater the number of cards obtained, the higher the possibility of forgetting the acquisition conditions for each card.
Therefore, in the present embodiment, it is possible to present acquisition conditions for a reference card (an unowned card or an unknown card) that the user does not possess among a plurality of reference cards necessary for evolving the base card. An unowned card is a card that has been possessed by a user and is not possessed by the user when a base card is selected. On the other hand, an unknown card is a card that has never been possessed by a user.

The presentation of the reference card acquisition conditions will be specifically described with reference to FIG. FIG. 4 is a diagram for conceptually explaining the presentation of the reference card acquisition conditions.
In FIG. 4, consider a case where the user wants to evolve the card Q that is the possessed card. Here, it is assumed that a combination of cards A, B, and C as a plurality of reference cards is required to evolve the card Q. Since the user does not possess the card B at the present time, the evolution synthesis cannot be performed on the card Q. Further, since the user forgets the conditions for obtaining the card B, it is difficult to obtain the card B. In this case, in the present embodiment, the acquisition condition of the card B is presented to the user in response to a request for presentation of the acquisition condition of the card B so that the user can easily obtain the card B. As a result, the user can easily obtain the card B.

(1-5) Configuration of Data Table Next, a card data table, an evolutionary synthesis data table, a quest data table, a possessed card data table, a reservation data table, a possession history data table, and the like stored in the storage 25 of the game server 20 The card distribution data table will be described in order with reference to FIGS.

(I) Card Data Table The card data table records card data used in the game of the present embodiment. FIG. 5 shows a configuration example of the card data table. In the example shown in FIG. 5, the card name, card image, and card parameter data are included for each card ID.
The card ID is identification information that identifies a card that is an example of an object. The card ID is uniquely assigned to each card. One card is specified from a plurality of cards by the card ID. That is, the card ID is an example of object identification information that identifies an object.
The card name is a character string indicating the name of the character displayed on the card. The card image is an image of a character displayed on the card. The card parameter is composed of data of rarity, attribute, cost, skill, sale price, attack power, defense power, and limited flag.
The rarity is an index indicating the rare value of the card. In the example shown in FIG. 5, the rarity is set higher in the order of R1 to R5.
The attribute is an attribute of the character displayed on the card, and is one of N1 to N3 in the example shown in FIG.
The cost is a value referred to when the card is incorporated into the user's card team. For example, when a battle is played by a card team, the total cost of cards included in the card team is limited to a predetermined value or less.
The skill is information indicating an advantageous effect when a game is executed using a card. In the example shown in FIG. 4, skills having various effects of SK1 to SK12 are set for each card. Note that not all cards need to have skills.
The sale price is a point on the game that the user can obtain when selling the card that the user owns.
Attack power and defense power are parameters that are referred to when a card is used in a battle.
The limited flag is a flag indicating whether or not the card is issued for a limited time. In the example shown in FIG. 4, a card with a limited flag “1” means a card issued for a limited time, and a card with a limited flag “0” means a card that is not limited in time. To do.

(Ii) Evolutionary synthesis data table The evolutionary synthesis data table records the conditions for evolutionary synthesis of the cards of the game of this embodiment. FIG. 6 shows a configuration example of the evolutionary synthesis data table. In the example shown in FIG. 6, for each evolution ID for identifying the contents of evolutionary synthesis, a pre-evolution card ID (that is, a card ID of a card that becomes a base card before evolution), a post-evolution card ID (base card The card ID after evolution) and the card ID change conditions (five reference cards in the columns C1 to C5) necessary for executing evolutionary synthesis are recorded. For example, under the condition indicated by the evolution ID: 0002, the user selects the card with the card ID: 0072 as the base card from the possessed cards, and the three cards with the card IDs: 0025, 0060, and 0070 are included in the user's possessed cards. If there is a combination of cards, the card with the card ID: 0072 can be evolved into the card with the card ID: 9072 by executing evolutionary synthesis.
Here, as an example of a process for changing an object, a process of evolutionary synthesis of a card, which is an example of an object, will be described. As described above, the card ID is an example of object identification information. That is, FIG. 6 shows that the change condition includes a plurality of pieces of object identification information used for the process of changing the object.
In the C1 to C5 column indicating the combination of the card IDs of the reference cards, the same card ID may be recorded in at least any two columns. For example, two or more identical reference cards may be included in a combination of reference cards used when base cards are evolved and synthesized. If the reference card combination condition for evolving the base card includes a predetermined number of reference cards having the same card ID, the card of the reference card is used instead of the data format shown in FIG. A data format composed of an ID and the number thereof may be used.

(Iii) Quest data table In the quest data table, data of a quest that is one of events executed in the game of the present embodiment is recorded. A quest is an event for the purpose of a user searching for an area in a game and achieving a predetermined quest condition in order to obtain cards and items. FIG. 7 shows a configuration example of the quest data table. In the example shown in FIG. 7, for each quest ID, area name, physical strength, information on available cards (card ID and availability), information on available items (item ID and availability), boss ID, and Quest UI data is included.
The area name is a character string indicating the name of the area used in the quest.
Consumable health is a value that is referenced when a quest is performed. In order to execute a quest, the value of physical strength, which is one of the parameters of the user, needs to be equal to or greater than the value of consumption physical strength. When the quest is executed, the value of the user's physical strength is consumed by the amount of the physical strength consumed.
Information on available cards (obtained card data 1, 2,...) Is composed of a card ID and an acquisition rate. The card ID is card identification information that can be obtained when the quest condition is achieved. The acquisition rate is a numerical value indicating the probability that the card can be acquired when the quest condition is achieved.
Information about available items (acquired item data 1) includes an item ID and an acquisition rate. The item ID is item identification information that can be obtained when the quest condition is achieved. The acquisition rate is a numerical value indicating the probability that an item can be acquired when the quest condition is achieved.
The boss ID is identification information of an NPC (for example, a boss character) that is an opponent in the quest. The quest condition is achieved, for example, by winning a battle with a boss character.
The quest UI data is user interface data used in the quest (for example, image data used in the quest).

(Iv) Possession card data table The possession card data table stores information on the possession card of the user. FIG. 8 shows a configuration example of the possessed card data table. Although FIG. 8 illustrates the possession card data table for one user, the possession card data table is provided corresponding to all users registered in the game.
In the possession card data table shown in FIG. 8, each data of serial number, card level, skill level, and reservation ID is recorded in association with each card ID. The serial number is a unique number determined when the card is given to the user. Different serial numbers are assigned to cards having the same card ID. When the card has evolved, the serial number may or may not be changed before and after the evolution of the card.
The card level is a parameter indicating a card growth level, and is increased by executing, for example, the normal synthesis. The value (initial value) of the card level at the time when the user acquires the card is 1, and the user can grow the card (that is, increase the card level) by executing normal synthesis or the like.
The skill level is a parameter indicating a card development level, and particularly a parameter indicating a skill level of the card. The skill level (initial value) at the time when the user obtains a skill-equipped card is 1, and the skill level of the card is increased by performing normal synthesis using, for example, a card satisfying a predetermined condition as a reference card. Can be made. As the skill level of the card increases, the effect generated by the skill increases.
The reservation ID is identification information for identifying reservation contents for evolutionary synthesis. Reservation ID is matched with the possession card of the user who is a reserved card. For example, the example shown in FIG. 8 indicates that five cards with card IDs: 0591, 0010 (2 cards), 0033, and 2005 are reserved cards. The reservation ID recorded in the possession card data table corresponds to the reservation ID recorded in the reservation data table described later.

(V) Reservation data table The reservation data table records information on reserved cards for user evolutionary synthesis. FIG. 9 shows a configuration example of the reservation data table. Although FIG. 9 illustrates a reservation data table for one user, the reservation data table is provided corresponding to all users registered in the game.
In FIG. 9, reservation IDs are IDs issued in the order in which reservations for evolutionary synthesis are made. In the example shown in FIG. 9, numbers are recorded in ascending order such as 01, 02,. The evolution ID corresponds to the evolution ID shown in the evolution synthesis data table, and is an ID that specifies the content of evolution synthesis.
Of the reserved card serial numbers, the serial number of the pre-evolution card is the possessed card serial number selected by the user as the base card for evolutionary synthesis. Of the serial number of the reserved card, the columns C1 to C5 of the reference card respectively correspond to the columns C1 to C5 constituting the combination of the reference card IDs in the evolutionary synthesis data table.
If the reserved reference card is a possessed card, the serial number of the possessed card data is recorded in the column corresponding to the card ID of the reference card. If the reserved reference card is an unowned card, a temporary serial number (for example, “00000000”) is recorded in the field corresponding to the card ID of the reference card, and the reference card becomes a possessed card (that is, After the possessed card data specified by the card ID and serial number of the reference card is added), the temporary serial number is rewritten with the serial number of the reference card. Data indicating “no reservation” (for example, NULL) is recorded in the field corresponding to the card ID of the reference card that has not been reserved.
In the following, a case where a reservation data table is provided will be described, but it is not essential to provide a reservation data table independently. As a reservation management method for evolutionary synthesis, data to be recorded in the reservation data table may be recorded in the possession card data table. In that case, in the possessed card data table, it corresponds to the card ID of the reserved card, and any one of the reservation ID, evolution ID, and C1 to C5 character strings (corresponding to the columns C1 to C5 of the evolutionary synthesis data table). Any character string can be recorded.

(Vi) Possession history data table The possession history data table records information on cards that the user has possessed. FIG. 10 shows a configuration example of the possession history data table. Although FIG. 10 illustrates the possession history data table for one user, the possession history data table is provided for all users registered in the game.
In the possession history table shown in FIG. 10, the number of acquisitions is recorded in association with each card ID. The number of times of acquisition is a value indicating the number of times the user has acquired the card in the game. A card that is obtained 0 times is an unknown card.

(Vii) Card Distribution Data Table The card distribution data table stores information related to cards distributed in the game. FIG. 11 shows a configuration example of the card distribution data table. In the example shown in FIG. 11, the card distribution data table records the number of distributions and the average transaction price for each card ID.
The number of circulation is a value indicating the total number of cards set by the user as cards to be traded (for example, trading) in the game. The greater the number of circulation, the lower the difficulty of obtaining cards.
The average transaction price is an average value of prices when cards are traded between users. The higher the average transaction price, the higher the difficulty of obtaining the card.

  In the following description, information associated with a card ID in the card data table, quest data table, possession card data table, possession history data table, and card distribution data table (for example, card name, card image, card parameter, Quest ID, area name, physical strength, acquisition rate, boss ID, quest UI data, serial number, card level, skill level, reservation ID, number of acquisitions, number of circulation, and average transaction price) It is called “card data”. Card data is an example of information indicating an object.

(1-6) Specific Examples of Acquisition Conditions Presentation Processing and Evolutionary Synthesis Processing Specific examples of the game card acquisition conditions presentation processing and evolutionary synthesis processing of this embodiment will be described below with reference to FIGS. 12A, 12B, and 13A. This will be described with reference to FIGS. 13B and 14. FIG. 12A, FIG. 12B, FIG. 13A, FIG. 13B, and FIG. 14 are diagrams each showing an example of a screen displayed on the user terminal 10 when executing the game processing of this embodiment.

(1-6-1) Acquisition condition presentation process (1-6-1-1) Unowned card acquisition condition presentation process (FIGS. 12A and 12B)
FIG. 12A and FIG. 12B show changes in a series of display screens in the acquisition condition presenting process for presenting the acquisition condition for an unowned card. In FIG. 12A, an image P1 is an image when the user makes a processing request for a monster card (hereinafter simply referred to as “card”) in the game of the present embodiment. In the image P1, as the operation target of the user, the button b1 (“see the possessed monster”), the button b2 (“team organization”), the button b3 (“normal composition”), the button b4 (“evolution composition”), the button b5 ("sale") is provided.
The button b1 is a button operated when making a request for a browsing process of the user's possession card. The button b2 is a button that is operated when the user selects a card to be used in a battle with another user or NPC from his / her own card. The button b3 is a button operated when making a request for a normal composition process of a card selected as a base card from the possessed cards by the user. The button b4 is a button operated when making a request for the evolution synthesis process of the card selected as the base card from the possessed cards by the user. The button b5 is a button operated when making a sale processing request for a card selected from the possessed cards by the user.

When the button b4 ("evolutionary synthesis") is operated in the image P1, the image changes as shown in P2. In the image P2, a plurality of possession cards are displayed in a list in order to select one of the possession cards of the user as a base card. Note that images are configured so that cards that cannot be evolved (in the example shown, cards TOM, TED, DSG) cannot be selected as base cards. That is, in the image P2, the card that can be evolved and the card that cannot be evolved among the cards possessed by the user are shown in a display format that can be identified by the user. The method of showing the card that can be evolved and the card that cannot be evolved in a display format that can be identified by the user is not limited to the example shown in the image P2 of FIG. 12A. The list of possessed cards may be a list of character strings of the card names of each card, and in that case, it is possible to identify the card that can evolve and the card that cannot evolve by the brightness, size, etc. May be.
In the image P2, for example, when the card KLM is selected as one of the cards that can be evolved, the image changes as shown in P3. In the image P3, a button b6 (“Select”) for confirming the selected card as the base card for evolutionary synthesis and a button b7 (“Back” for selecting another card as the base card after returning to the image P2). ]).
When the button b6 is operated in the image P3, when the card KLM selected as the base card does not satisfy the reference card condition necessary for evolution, the image is updated as shown in P4. The image P4 is an image for requesting presentation of an acquisition condition for an unowned card among the reference cards necessary for the card KLM selected as the base card to evolve. Note that when the user selects the button b6 in the image P3, if the card KLM selected as the base card satisfies the reference card conditions necessary for evolution, the card KLM is subjected to evolution synthesis. An image (not shown) for requesting is displayed.

The image P4 includes a display area 101 indicating a pre-evolution card (here, the card KLM as a base card) and a post-evolution card (for example, a card QRS), a reference card necessary for evolutionary synthesis and its state (possessed, not yet possessed). A display area 102 indicating possession, reserved, unknown), and a button b8 (“display acquisition conditions”) for requesting presentation of the acquisition conditions for the reference card. In the image P4, when a reference card (here, a card DSG whose display area 102 indicates “not possessed”) to display the acquisition condition is selected and the button b8 is operated, FIG. As shown, an image P5 indicating the acquisition conditions for the reference card selected by the user is displayed.
Note that the reference card selected by the user is also referred to as a “reference card specified by the user”. Further, since the reference card is an example of an object, the “reference card specified by the user” is an example of the “specified object” that is an object specified by the user.

  In the image P5 of FIG. 12B, the reference card (here, the card DSG) selected by the user, the display image 103 indicating the card image, card name, and rarity of the reference card, and acquisition of the reference card are displayed. Display area 104 indicating the conditions. In the display area 104, information 104a (here, the number of times of acquisition, the number of distributions, and the average transaction price) related to the difficulty level of acquisition, and information 104b (here, available area) related to the acquisition route are displayed.

(1-6-1-2) Unknown card acquisition condition presentation process (FIGS. 13A and 13B)
FIG. 13A and FIG. 13B show changes in a series of display screens in the acquisition condition presentation process for presenting the unknown card acquisition condition. Images P1 to P3 in FIG. 13A are the same as images P1 to P3 in FIG. 12A, respectively.
Image P4 in FIG. 13A differs from image P4 in FIG. 12A in that an unknown card is shown in display area 102. An unknown card is a card that has never been held by a user (for example, the value of “number of times of acquisition” in the possession history data table is 0) among unowned cards. When a reference card (in this case, a card whose “unknown” state is displayed in the display area 102) is selected in the image P4 and the button b8 is operated, as shown in FIG. 13B. Then, an image P5 indicating the acquisition condition of the reference card selected by the user is displayed.

  In the image P5 of FIG. 13B, an image indicating that the reference card selected by the user is an unknown card for the user is shown in the display area 103, and the acquisition conditions for the reference card are shown in the display area 104. 12B, only the information 104b relating to the difficulty level of acquisition (here, the number of times of acquisition and the number of distribution) is shown (that is, the information 104a relating to the acquisition route in the image P5 of FIG. 12B is masked). Different from image P5.

(1-6-2) Evolutionary synthesis processing (FIG. 14)
FIG. 14 shows a series of display screen changes when the evolutionary synthesis process is executed based on a user operation. In FIG. 14, an image P10 is an example of an image displayed when the user obtains a new card DSG while the game is being executed.
If the new card DSG is acquired and the change condition of the reserved evolutionary synthesis is satisfied, the user can confirm that the change condition is satisfied by acquiring the new card. Is preferably notified. More preferably, as shown in P11, it is preferable to display an image for executing evolutionary synthesis.
The image P11 includes a display area 101 indicating a pre-evolution card (card KLM) and a post-evolution card (card QRS), a reference area 102 indicating a reference card necessary for evolutionary synthesis and its state (here possession), and A button b20 (“Yes”) and a button b21 (“No”) for accepting a request whether or not to execute evolutionary synthesis are displayed.
When the button b20 is operated in the image P11, the image changes as shown in P12. In the example of the image P12, the card image of the card after evolution, the card name, and at least a part of the parameters are displayed.

(1-7) Overview of Functions Provided by Information Processing Device Next, functions provided by the game server 20 in order to realize the above-described game of the present embodiment will be described. FIG. 15 is a functional block diagram for explaining functions that play major roles in the game server 20 of the present embodiment. In FIG. 15, as described above, the data table group 70 includes a card data table, an evolution synthesis data table, a quest data table, a possessed card data table, a reservation data table, a possession history data table, and a card distribution data table. . Note that not all the means included in the functional block diagram shown in FIG. 15 are essential elements of the present invention.

The accepting unit 51 has a function of accepting various requests from the user based on information related to the user's operation input. As a request from the user in the game of the present embodiment, for example, a request for a card acquisition condition request, a request for evolutionary synthesis processing, a request for quest processing, a request for reservation processing for evolutionary synthesis, a request for execution of evolutionary synthesis, There are a request for a browsing process of a user's possession card, a request for a sale process of a user's possession card, and the like.
The request for obtaining the acquisition condition is a request for presenting the acquisition condition of the reference card necessary for the evolution synthesis of the base card in response to the output of the image data by the output means 56.
In response to the image data output from the output means 56, the evolution synthesis reservation process requests evolution synthesis of at least one of the base card in evolution synthesis and a plurality of reference cards corresponding to the base card. Of the process executed on condition that the card is deleted from the user's possession card (for example, the process of selling the card or the card to another user) This is a request that restricts the use of the data for transfer). The request for evolutionary synthesis reservation processing includes the card ID of the reference card to be reserved.
In order to realize the function of the accepting unit 51, the game server 20 receives a request corresponding to the button operation input by the user in the web page as an image from the user terminal 10 via the communication interface unit 24. The CPU 21 of the game server 20 determines the content of the request based on the information included in the received request and performs a request acceptance process. In the reception process, the request is recorded in the RAM 13. The CPU 21 sequentially executes processes corresponding to the accepted requests.

The game processing unit 52 has a function of executing various game processes other than evolutionary synthesis based on the request and instruction from the user received by the receiving unit 51. The game process of the present embodiment may be provided as appropriate. For example, a battle process between users, a battle process between a user and an NPC, a quest process by a user, a normal synthesis process of a user possession card, a user possession card The sale process.
Although the battle process will not be described in detail, for example, the user forms a team composed of a plurality of possessed cards in advance so that the total cost is equal to or less than a predetermined upper limit value, and battles with other users or NPCs by the team. The match result is determined by parameters such as attack power, defense power, and skill of each card constituting the team.

The function of the game processing means 52 when executing the quest process is realized as follows. When the CPU 21 of the game server 20 receives the request for the quest process including the quest ID, the quest data associated with the quest ID (area name, consumer strength, acquired card data (card ID and acquisition rate) is received from the quest data table. ), Acquired item data (item ID and acquisition rate), boss ID, and quest UI data) are read out and expanded in the RAM 23. Next, the CPU 21 displays a quest execution screen based on the quest UI data, and advances the quest according to a user operation. When the quest progresses to a predetermined level, the CPU 21 executes a battle between the boss character associated with the boss ID and the user. When the user satisfies the victory condition in the battle, the CPU 21 executes a process of giving a card according to the value of “acquisition rate” associated with the quest ID. In the process of assigning a card, the CPU 21 writes the card ID associated with the quest ID to the possessed card data table and increases the value of “number of acquisitions” associated with the card ID in the possession history data table. .
In addition, when the user satisfies the victory condition in the battle, the process of giving an item is executed in the same manner as the process of giving a card.

  The function of the game processing means 52 when executing the normal synthesis process for the user's possessed card is realized as follows. When the CPU 21 of the game server 20 receives a normal synthesis execution request including the user's selection result for the base card and the reference card, the CPU 21 reads the card data of the base card and the reference card from the possessed card data table and develops them in the RAM 23. Next, the CPU 21 changes the base card parameters (for example, card level and skill level) based on the base card and reference card parameters, writes the changed base card parameters to the possessed card data table, and possessed card data. Delete the card data of the possession card used as the reference card from the table. Note that the card level and skill level of the base card are not always increased every time normal synthesis is executed. For example, each time the normal synthesis is executed, the value of the growth parameter associated with the card is increased, and when the value of the growth parameter reaches a predetermined value, the card level is increased by 1 and the value of the growth parameter is set to zero. You may make it reset to.

  The function of the game processing means 52 when executing the selling process of the user's possessed card is realized as follows. When the CPU 21 of the game server 20 receives the request for the sale process and receives the selection result of the sale target card, the card data of the sale target card is deleted from the possessed card data table. Next, the CPU 21 reads the sale price value (point) of the card to be sold from the card data table, and performs a process of giving the read point to the user. The process of giving points to the user is, for example, a process of updating the value of the user's possessed points recorded in a user database (not shown).

The card data changing unit 54 has a function of executing evolutionary synthesis for changing the card data of the base card when all of the plurality of reference cards satisfying the change condition are included in the user's possessed card.
In the example of this embodiment, in order to realize the function of the card data changing unit 54, when the CPU 21 of the game server 20 receives the evolution synthesis execution request, the pre-evolution card (that is, evolution synthesis) is received in the possessed card data table. The card data of the base card) is erased, and the card data of the evolved card is newly written. Thereby, the base card of the user's possession card will evolve. As shown in the evolution synthesis data table, since the card ID is different between before evolution and after evolution, at least one of the card name, the card image, and the card parameter is changed by evolution synthesis.

The acquisition means 55 has a function of acquiring a plurality of reference card IDs, which are reference card combination conditions (an example of change conditions) corresponding to a base card (an example of a selected object) selected by the user, from the evolutionary synthesis data table Prepare. In addition, when the reference card selected by the user is not a possessed card (for example, an unacquired card or an unknown card), the acquisition unit 55 uses the quest data table, possessed history data table, And a function of obtaining from the card distribution data table. In addition, when making a reservation for a card for evolutionary synthesis, the acquisition unit 55 obtains a serial number (an example of information indicating an object) of one of the cards possessed by the user based on the user's operation input. It has a function to acquire.
When the acquisition unit 55 acquires a plurality of reference card IDs, which are reference card combination conditions, the CPU 21 of the game server 20 creates an evolutionary synthesis data table in response to acquiring a base card selection result from the user terminal 10. Referring to, a plurality of reference card IDs constituting a combination condition corresponding to the base card is read out.
When the acquisition unit 55 acquires the card data of the reference card selected by the user, the CPU 21 of the game server 20 acquires the result of selecting the reference card from the user terminal 10, and the quest data table, possession history data The card data of the reference card is read with reference to the table and the card distribution data table.
When the acquisition unit 55 acquires the serial number of the card, when the CPU 21 of the game server 20 receives a request for evolutionary synthesis reservation processing from the user terminal 10, the CPU 21 receives the base card to be subjected to evolutionary synthesis and From a plurality of corresponding reference cards, a possessed card that has not been reserved is identified by referring to the possessed card data table, and the serial number of the identified card is read out.

The output unit 56 uses the card data of the plurality of reference cards included in the change condition acquired by the acquiring unit 55 to display the plurality of reference cards in a display format that can be identified by the user. A function of outputting data (for example, image data) (hereinafter referred to as “first output function”) is provided.
In the example of the present embodiment, in order to realize the first output function of the output means 56, the CPU 21 of the game server 20 is necessary for evolving the base card, for example, when the base card is selected by the user. A plurality of reference card ID combinations are read from the evolutionary synthesis data table, and for each reference card, based on the information stored in the possession card data table, reservation data table, and possession history data table, the card status (" (Reserved), "possessed", "not possessed", and "unknown" status). In addition, the CPU 21 generates first output data for displaying the state of each reference card in a display format that can be identified by the user.
For example, in the reservation data table of FIG. 9, when the serial number or temporary serial number included in the possessed card data is recorded in the columns C1 to C5 associated with the evolution ID corresponding to the base card, The state of the reference card specified by the card ID corresponding to the corresponding column is specified as “reserved”.
For example, for cards other than “reserved”, the card IDs in the columns C1 to C5 associated with the evolution IDs corresponding to the base cards in the evolutionary synthesis data table of FIG. When it is included in the “card ID” column of the data table, the state of the reference card specified by the card ID is specified as “possession”.
For example, for a card whose card status is other than “reserved” and “possessed”, if the “obtained number” column corresponding to the card ID is not 0 in the possession history data table of FIG. When the status of the reference card specified by is specified as “not possessed” and the “number of times of acquisition” field corresponding to the card ID is 0, the status of the reference card specified by the card ID is “ Identified as "unknown".
The first output data indicates the state of the identified reference card.

In addition, the output unit 56 provides second output data (for example, image data) for presenting the acquisition condition of the reference card (unowned card or the unknown card) corresponding to the reference card ID acquired by the acquiring unit 55. A function for outputting (hereinafter referred to as “second output function”) is provided.
In the example of the present embodiment, in order to realize the second output function of the output unit 56, the CPU 21 of the game server 20 uses the acquired reference card ID when the reference unit ID is acquired by the acquiring unit 55, for example. Based on the quest data table, possession history data table, and card distribution data table, the acquisition condition of the reference card corresponding to the reference card ID is specified, and the second output data for presenting the acquisition condition Generate.
For example, in the quest data table of FIG. 7, the information in the “area name” column corresponding to the quest ID including the reference card ID acquired in the “card ID” column of “acquired card” is the available area. Identified.
In the possession history table of FIG. 10, the value in the “Number of times of acquisition” column corresponding to the acquired reference card ID is specified as the number of times of acquisition.
In the card distribution data table of FIG. 11, values in the “distribution number” and “average transaction price” fields corresponding to the acquired reference card ID are specified as the distribution number and the average transaction price, respectively.
The second output data indicates at least one of the specified available area, the number of times of acquisition, the number of distribution, and the average transaction price.

  The recording unit 57 has a function of recording the serial number acquired by the acquiring unit 55 in the reservation data table in the storage 25 as a reserved card in response to receiving a request for evolutionary synthesis reservation processing. In the example of the present embodiment, the reservation target card is a card that is restricted from being used for processing other than the evolution synthesis of the selected base card.

In order to realize the function of the recording means 57, when the CPU 21 of the game server 20 receives a request for reservation processing for evolutionary synthesis, it accesses the reservation data table and writes the serial number of the reservation target card. More specifically, when the serial number of the card selected as the base card among the reservation target cards is not recorded in the reservation data table, a new reservation ID is issued. The CPU 21 writes the serial number of the card selected as the base card in the “pre-evolution card” column in association with the issued reservation ID. Further, the column of “reference card ID” (any one of columns C1 to C5) that is the same as the card ID corresponding to the serial number of the reference card among the reservation target cards is specified, and among the reservation target cards in the specified column Write the serial number of the reference card.
On the other hand, when the reservation ID has already been issued, the serial number has already been recorded in the “pre-evolution card” column, and therefore the CPU 21 only writes the serial number of the reference card among the reservation target cards. .

The restriction unit 58 has a function of restricting use of a card recorded as a reserved card in the reservation data table for processing other than the target evolutionary synthesis. “Used for processing other than the desired evolutionary synthesis” means that a card recorded as a reserved card associated with the desired evolutionary synthesis is an evolutionary synthesis other than the intended evolutionary synthesis or normal synthesis. The case where it is used for is also included.
Various limiting methods by the limiting means 58 can be considered. For example, when a card to be restricted is selected for a method for prohibiting processing other than the evolutionary synthesis intended by the user, or when the card to be restricted is selected for processing other than the intended evolutionary synthesis, On the other hand, there is a method of performing processing for confirming the continuation of the processing.
Note that “restricting use for processing” with respect to reserved cards is not limited to prohibiting the processing itself other than the intended evolutionary synthesis using reserved cards, but using reserved cards. Processes other than the target evolutionary synthesis can be executed, but the procedure for executing the process may be made difficult, or the procedure for executing the process may be complicated. Processing other than evolutionary synthesis for reserved cards is executed on condition that the reserved card disappears from the user's possessed card (that is, executed on the condition that the reserved card is set as an unowned card) It is particularly preferable that the processing is limited.

  For example, when the CPU 21 of the game server 20 receives an execution request for any of the various processes of the game of the present embodiment, the possessed card data table is selected when the possessed card of the user is selected as the processing target card. , It is determined whether or not the reservation ID is associated with the card ID of the selected card. When the reservation ID is associated with the card ID of the selected card and the process related to the execution request is not the evolutionary synthesis process corresponding to the reservation ID, the CPU 21 may prohibit the process or select The user may be notified that the card that has been reserved is a reserved card. Alternatively, the user may be notified that the selected card is a reserved card, and the user may be confirmed as to whether or not to continue the process. Since the reservation data table associates the evolution ID with the serial number of the reserved card, the CPU 21 of the game server 20 corresponds to the target evolutionary synthesis (that is, corresponding to a specific evolution ID) corresponding to the reserved card. Evolving synthesis). Therefore, it is possible to determine whether or not the process that the user intends to execute using a specific possession card is the target evolutionary synthesis process.

  It is not essential to provide the recording unit 57 and the limiting unit 58, but by providing the recording unit 57 and the limiting unit 58, for example, some reference cards out of a plurality of reference cards necessary for evolutionary synthesis are evolved and synthesized. It is possible to prevent a user who reserves before executing and waits for evolutionary synthesis until the remaining reference card is obtained and erroneously uses the possessed card for processing other than evolutionary synthesis.

(1-8) Game Processing Flow of this Embodiment Next, an example of the game processing flow of this embodiment will be described with reference to the sequence charts of FIGS. 16A, 16B, and 17. FIG.
16A and 16B are sequence charts showing acquisition condition presentation processing. FIG. 17 is a sequence chart showing the evolution synthesis process.
In each figure, each image P1 to P5 and P10 to P12 shown in FIG. 12A, FIG. 12B, FIG. 13A, FIG. 13B, and FIG. is there.

(1-8-1) Acquisition condition presentation process (FIGS. 16A to 16B)
In the process for presenting the acquisition conditions described below, as an example, when the user possesses a base card and some of a plurality of reference cards for evolving and synthesizing the base card, the possession or unknown Suppose that the request for the acquisition of the reference card is requested.

In FIG. 16A, when the user operates a predetermined button (for example, the button b4 of the image P1 in FIG. 12A or 13A) on the image displayed on the user terminal 10, the CPU 11 of the user terminal 10 performs the evolution synthesis process. The request is accepted (S10), and the request is transmitted to the game server 20 (S12).
When the CPU 21 of the game server 20 receives a request for the acquisition condition presentation process from the user terminal 10, the CPU 21 reads out the evolved user possession card with reference to the evolutionary synthesis data table and possession card data table (S14). That is, the CPU 21 reads the card data of the user's possessed card from the possessed card data table, and reads all the pre-evolution card IDs (that is, the card IDs of the cards that can be evolved) in the evolutionary synthesis data table. Next, the CPU 21 identifies an evolving card (that is, a base card candidate) from among the possessed cards of the user, generates image data including the card data of the base card candidate (S16), and uses the image data as the user terminal 10. (S18).
Note that the image data generated in S16 is a display mode in which the image of the card that can be evolved and the image of the card that cannot be evolved among the cards possessed by the user are different as shown in the image P2 of FIG. 12A or 13A. It is preferable to be generated as follows.

  When receiving the image data transmitted in S18, the CPU 11 of the user terminal 10 displays an image on the display unit 16 based on the image data (S20). The images displayed in S20 include images of a plurality of cards that are base card candidates as illustrated in the image P2 in FIG. 12A or FIG. 13A. By manipulating the images of the cards, The number is configured to be selectable. When the user performs an operation for selecting one of the plurality of base card candidates displayed in S20 as a base card, the CPU 11 accepts the selection result (serial number) of the base card (S22), The selection result is transmitted to the game server 20 (S24).

  When the CPU 21 of the game server 20 receives the selection result (serial number) transmitted in S24, it refers to the evolutionary synthesis data table and matches the card ID associated with the serial number of the base card selected by the user. A plurality of reference card IDs (card IDs in the columns C1 to C5) corresponding to the pre-evolution card ID are read (S26). Next, the CPU 21 refers to the possessed card data table and the reservation data table and specifies the state of the card corresponding to each reference card ID read in S26 (any of possessed, possessed, reserved, or unknown). Then, image data is generated based on the identification result (S28).

In S28, the CPU 21 of the game server 20 specifies the state of the card corresponding to each reference card ID as follows.
The CPU 21 reads the serial number recorded in the “reserved card serial number” column of the reservation data table, and refers to the possessed card data table to identify the card ID associated with the serial number. When the reference card ID read in S26 matches the specified card ID, or when the serial number is a temporary serial number, the state of the card specified by the card ID is set to “reserved”. Identify.
When the reference card other than the card specified as “reserved” includes the reference card ID of the reference card in the card ID recorded in the possessed card data table, the CPU 21 refers to the reference card. The state of the card specified by the ID is specified as “possession”.
If the value associated with the reference card ID in the “number of times obtained” column of the possession history data table is not 0 for the cards other than “reserved” and “possession”, the CPU 21 specifies the card specified by the reference card ID. If the value associated with the reference card ID in the “Obtain count” column of the possession history data table is 0, the state of the card specified by the reference card ID is “ Identify as “unknown”.

  In S28, the CPU 21 of the game server 20 instructs the user whether to execute the evolution synthesis of the card KLM when the state of all the reference cards read out in S26 is “possessed” or “reserved”. To generate image data. When the state of at least one of the reference cards read in S26 is “not possessed” or “unknown”, the CPU 21 presents the acquisition conditions for the reference card in the “not possessed” or “unknown” state. Image data is generated. Here, it is assumed that image data that is the basis of the image P4 in FIG. 12A or 13A is generated.

  Next, the CPU 21 of the game server 20 transmits the image data generated in S28 to the user terminal 10 (S30). When receiving the image data transmitted in S30, the CPU 11 of the user terminal 10 displays an image based on the image data on the display unit 16 (S32).

As shown in the image P4 in FIG. 12A or 13A, the image displayed in S32 is displayed so that the user can identify a plurality of reference cards that are required to evolve and synthesize the base card selected in S22. doing. The image P4 in FIG. 12A or 13A is configured so that the state of each reference card is displayed in association with the reference card, and a request for a process for presenting an acquisition condition for an unowned card or an unknown card can be accepted. . Here, after the image P4 of FIG. 12A or FIG. 13A is displayed, an operation (for example, operation of the button b8 of the image P4 of FIG. 12A or FIG. 13A) for requesting the acquisition condition presentation processing is performed by the user. Then, the CPU 11 of the user terminal 10 receives a request for acquisition condition presentation processing based on a user instruction corresponding to the operation (S34), and transmits the request to the game server 20 (S36). The request transmitted from the user terminal 10 to the game server 20 in S36 includes the card ID of the unowned card or the unknown card selected by the user (that is, the card for which the acquisition condition should be presented in the acquisition condition presentation process). It is.
As described above, the reference card selected by the user is an example of a designated object that is an object designated by the user. That is, the processes of S34 and S36 are an example of a process of receiving an instruction for designating any one of a plurality of objects based on a user instruction.

  When the CPU 21 of the game server 20 receives the request for the acquisition condition presentation process transmitted in S36, the card data of the reference card selected by the user is selected from the card data table, the quest data table, and the card distribution data table. Obtain (S38). The card name, card image, and rarity are obtained from the card data table. The quest ID and the area name of the available area are acquired from the quest data table. The number of times of acquisition is acquired from the possession history table. The number of distributions and the average transaction price are acquired from the card distribution data table.

If the status of the card specified in S28 is "unknown" (S40: YES), the process proceeds to S42, and if the status of the card specified in S28 is not "unknown" (S40: NO), S44. Proceed to
Here, as an example of a case where the card state is not “unknown” (that is, an unknown card), an example where the card state is “not owned” (that is, an unowned card) will be described. “Unknown” and “not possessed” are both common in that the user does not possess a card (that is, the card ID is not included in the possessed card data table).

In S <b> 42, the CPU 21 of the game server 20 includes information (in this case, the number of acquisitions, the number of circulations, and the average transaction price) other than information related to the difficulty of acquisition among the information related to the cards indicated by the card data acquired in S <b> 38. Here, mask processing is applied to the image so that the card name, card image, rarity, and available area are not displayed.
In the present embodiment, the purpose of preventing the display of information other than information related to the difficulty of obtaining unknown cards is to give the user a sense of expectation for the game (particularly, to obtain an unknown card), and It is to improve the taste.

  In S44, based on the card data of the reference card acquired in S38, the CPU 21 sets the reference card acquisition conditions (however, if it is determined as “unknown” in S40, information on the difficulty of acquisition). Image data to be presented to the user (image data based on the image P5 in FIG. 12B or 13B) is generated, and the image data is transmitted to the user terminal 10 (S46).

When receiving the image data transmitted in S46, the CPU 11 of the user terminal 10 displays an image based on the image data on the display unit 16 (S48).
When it is determined in S40 that it is not “unknown” (for example, “not possessed”), as shown in an image P5 in FIG. 12B, a card image, a card name, a rarity, the number of times of acquisition, a circulation number, an average transaction price, And the available area is displayed.
On the other hand, when it is determined as “unknown” in S40, as shown in the image P5 of FIG. 13B, the number of times of acquisition, the number of circulation, and the average transaction price are displayed, but the card image, card name, rarity, And the available area is not displayed.
In other words, the information displayed as the unknown card acquisition condition is more limited than the information displayed as the unowned card acquisition condition. That is, in S48, when the designated object is an unknown object that has not been possessed by the user, the information displayed as the acquisition condition is limited as compared with the case where the designated object is an unowned object. It is an example.

  As described above, in the present embodiment, when the user does not possess the reference card selected by the user (when the reference card is an unknown card or an unowned card), an example of displaying the acquisition condition of the reference card is displayed. explained. This is an example of processing for displaying the acquisition condition of the designated object when the user does not have the designated object that is the designated object.

(1-8-2) Evolutionary synthesis processing (FIG. 17)
For example, when the user newly obtains a card that satisfies the reference card change condition in evolutionary synthesis, the evolutionary synthesis process can be executed.
In FIG. 17, when the user operates a predetermined button (for example, the button b20 of the image P11 in FIG. 14) on the image displayed on the user terminal 10, the CPU 11 of the user terminal 10 issues an execution request for evolutionary synthesis. The request is received (S150), and the request is transmitted to the game server 20 (S152).

When the CPU 21 of the game server 20 receives the request transmitted in S152, the card data of the pre-evolution card (that is, the base card of evolutionary synthesis) is deleted from the possessed card data table (S154), and the card of the post-evolutionary card Data is newly written (S156).
Next, the CPU 21 of the game server 20 deletes the card data of the reference card used for evolutionary synthesis in the possessed card data table (S158).

  Next, the CPU 21 of the game server 20 generates image data including the card data of the evolved card (image data based on the image P12 in FIG. 14) (S160), and transmits the image data to the user terminal 10 (S160). S162). When receiving the image data transmitted in S162, the CPU 11 of the user terminal 10 displays an image based on the image data (for example, the image P12 in FIG. 14) on the display unit 16 (S164).

As described above, in the game system of the present embodiment, in order to execute evolutionary synthesis of a card, which is an example of a process for changing an object, a base card to be subjected to evolutionary synthesis and a plurality of references corresponding thereto The requirement is that the user has all of the cards. Therefore, for example, when some of the plurality of reference cards are not possessed, the base card cannot be evolved and synthesized. At this time, it may be impossible or difficult for the user to obtain a reference card that the user does not have. However, whether or not the user who does not know the conditions for obtaining the reference card executes a process (for example, a quest process) for obtaining the reference card to make it impossible or difficult to obtain the reference card. Cannot be recognized at the time of decision. In such a case, the user executes a process for obtaining the reference card while having anxiety that it may be impossible or difficult to actually obtain the reference object.
The game server 20 according to the present embodiment presents a reference card acquisition condition that the user does not possess in response to a request from the user. Therefore, even if there is a reference card that cannot be obtained or difficult for the user among a plurality of reference cards corresponding to the base card to be subjected to evolutionary synthesis, the user cannot obtain the reference card or After recognizing that it is difficult, it is possible to decide whether or not to execute processing for obtaining the reference card. As a result, it is possible to give a sense of security to the user who executes the process for obtaining the reference card.

  Moreover, it is preferable that at least one of the acquisition route and the acquisition difficulty is presented as the acquisition condition of the unowned card. In this case, the user can give a sense of security to the user who executes a process (for example, a quest process) for obtaining the unowned card.

  In addition, as the acquisition condition of the unknown card, the acquisition difficulty level is displayed, but the acquisition route is not presented (that is, the information displayed as the acquisition condition of the unknown card is the information displayed as the acquisition condition of the unowned card) It is preferable to be limited in comparison with In this case, it is possible to give a sense of security to a user who executes a process (for example, a quest process) for obtaining the unknown card while maintaining the difficulty level of the game at an appropriate level.

(1-9) Modified Example of Embodiment Hereinafter, a modified example of the present embodiment will be described. The following modifications can be combined as appropriate.

(1-9-1) First Modification The image P4 in FIG. 12A or FIG. 13A shows a display format for displaying only the card image of the reference card, but this is the display format of the present embodiment. It is not limited.
For example, instead of a display format that displays only card images, a display format that displays only card names or a display format that displays combinations of card images and card names may be used.
That is, the display format of the present embodiment may be any format as long as the reference card is displayed so as to be identifiable to the user.

(1-9-2) Second Modification In the above-described embodiment, in order to prevent information other than information related to the difficulty level of acquisition from the card data acquired in S38 in S42 of FIG. 16B, an image is displayed. However, the process for preventing the information from being displayed is not limited to this.
For example, instead of applying the mask process, information other than the information regarding the difficulty level of acquisition may be deleted, or the information may be replaced with a predetermined symbol.

(1-9-3) Third Modification In the above-described embodiment, the example in which the card name, the card image, the rarity, and the available area are not displayed in S42 of FIG. 16B has been described. The embodiment is not limited to this.
For example, the card image and the available area may not be displayed, and the card name and rarity may be displayed.
The information that is not displayed may be arbitrarily set by the user.

(1-9-4) Fourth Modification In the above-described embodiment, in S42 of FIG. 16B, information other than information related to the difficulty level is not displayed among the information related to the card indicated by the card data acquired in S38. Although an example of doing so has been described, S42 can be omitted.
When S42 is omitted, since all of the card data acquired in S38 (that is, information on the reference card for which the acquisition conditions are presented) is displayed, there is a possibility that the user can obtain the reference card. Can give a sense of expectation.

(1-9-5) Fifth Modification A user has possessed in the past and an unowned card, which is a reference card that the user does not currently possess, has been selected as a card to be presented In this case, it is desirable to display at least one of the information regarding the area where the card is available and the difficulty level of the card as an acquisition condition.
If the specified object is an unowned object that the user has possessed in the past and the user does not currently possess, the acquisition condition of the designated object acquisition route and difficulty level It is an example of the process which displays at least one.
According to this modification, the user can easily know the difficulty level of obtaining the card.

(1-9-6) Sixth Modification In the above-described embodiment, an example of displaying the acquisition conditions for unowned cards has been shown. However, the acquisition conditions for cards other than unowned cards may be displayed.
As an example, the possession card acquisition conditions may be displayed. For example, when there are many possession cards, the user may forget the acquisition conditions for a possession card. In this case, by displaying the possession card acquisition conditions, the user can re-recognize the difficulty level of the possession card. If the user recognizes that the possession card is difficult to obtain, it is a chance to carefully consider the use of the possession card (for example, which base card is used as a reference card for evolutionary synthesis processing). Can be given. On the other hand, when the user recognizes that the possession card is difficult to obtain, the user can be given an opportunity to easily use the possession card.

(1-9-7) Seventh Modification In the above-described embodiment, the example in which the change condition is satisfied when all the reference cards corresponding to the base card are possessed has been described. In addition to possession, the change condition may be satisfied when a predetermined additional condition is satisfied.
For example, the additional condition may be satisfied when the card levels of all the reference cards have reached the maximum level, or may be satisfied when the user owns a predetermined amount of points on the game. .

(2) Second Embodiment In the first embodiment, a case has been described in which an image indicating acquisition conditions for unowned cards is displayed. In the second embodiment, in addition to the acquisition conditions, unowned cards are displayed. An example of displaying an image including an operation target for guiding the user to the acquisition route will be described. Note that descriptions similar to those of the first embodiment are omitted as appropriate.

(2-1) Specific Example of Acquisition Conditions Presentation Process and Quest Process Hereinafter, a specific example of the game card acquisition conditions presentation process of the present embodiment will be described with reference to FIG. FIG. 18 is a diagram illustrating an example of a screen displayed on the user terminal 10 when executing the game processing of the present embodiment.

(2-1-1) Acquisition condition presentation process (FIG. 18)
In the image P4 of FIG. 12A of the first embodiment, the reference card (here, the card DSG whose display area 102 indicates “not possessed”) to be displayed is selected, and the button b8. When is operated, as shown in FIG. 18, an image P5 indicating the acquisition condition of the reference card selected by the user is displayed.

Image P5 in FIG. 18 is different from the first embodiment (image P5 in FIG. 12B) in that it includes a button b9 (“go to available area”) in addition to display areas 103 and 104. The button b9 is a button that is operated when the user requests a quest process for obtaining an unowned card.
The button b9 is an example of an operation target for guiding the user to the acquisition route.

(2-1-2) Quest process (FIG. 18)
When the button b9 ("go to available area") is operated in the image P5, the image changes as shown in P6. In the image P6, a quest execution screen is shown. The user can search for an area (here, area 1) used in the quest by performing a predetermined operation on the image P6. When the quest condition is achieved, the user can obtain an unowned card based on the probability according to the value of “acquisition rate” in the quest data table.

(2-2) Game Process Flow of the Present Embodiment Next, an example of the game process flow of the present embodiment will be described with reference to the sequence chart of FIG.
FIG. 19 is a sequence chart showing the quest process. In FIG. 19, the step of displaying each of the images P5 to P6 shown in FIG.

(2-2-1) Acquisition Condition Presentation Process In this embodiment, in S44 (FIG. 16A), the CPU 21 of the game server 20 obtains the reference card acquisition route in addition to the card data of the reference card acquired in S38. This is different from the first embodiment in that image data (image data based on the image P5 in FIG. 18) for presenting an operation target for guiding the user to (here, the available area) is generated.

(2-2-2) Quest processing (FIG. 19)
19, when a predetermined button (for example, button b9 of image P5 in FIG. 18) is operated on the image displayed on user terminal 10, CPU 11 of user terminal 10 accepts a request for quest processing (S70). ), The request is transmitted to the game server 20 (S72).

  When the CPU 21 of the game server 20 receives the request transmitted in S72, the quest data associated with the quest ID acquired in S38 (area name, consumer strength, acquired card data (card ID and acquisition) are received from the quest data table. Rate), acquired item data (item ID and acquisition rate), boss ID, and quest UI data), image data for the quest process (image data based on the image P6 in FIG. 18) is generated (S74). ), And transmits the image data to the user terminal 10 (S76).

  When receiving the image data transmitted in S76, the CPU 11 of the user terminal 10 displays an image based on the image data (for example, the image P6 in FIG. 18) on the display unit 16 (S78).

  Thereafter, the CPU 11 of the user terminal 10 transmits an instruction according to the user's operation to the game server 20. The CPU 21 of the game server 20 advances the quest based on the transmitted instruction. When the quest progresses to a predetermined level, the CPU 21 executes a battle between the boss character associated with the boss ID and the user. When the user satisfies the victory condition in the battle, the CPU 21 executes a process of giving a card according to the value of “acquisition rate” associated with the quest ID. In the process of assigning a card, the CPU 21 writes the card ID associated with the quest ID to the possessed card data table and increases the value of “number of acquisitions” associated with the card ID in the possession history data table. . As a result, the user can obtain the card (reference card on which the acquisition conditions are to be displayed) selected in the image P4 of FIG. 12A of the first embodiment.

  As described above, the game server 20 according to the present embodiment presents the operation target for guiding the user to the reference card acquisition route together with the acquisition condition of the reference card that the user does not possess, Since it is possible to request execution of a process for obtaining an object simply by operating the operation target, it is possible to improve the operability when requesting the execution of the process.

(3) Third Embodiment In the second embodiment, a case has been described in which an image including an operation target for guiding a user to an unowned card acquisition route is displayed. In addition to the operation target for guiding the user to the possession card acquisition route, the user is guided to the unacquired card acquisition route, and the reservation process of evolutionary synthesis is executed after the user obtains the unowned card An example of displaying an image including an operation target for performing the operation will be described. In addition, about the description similar to the above-mentioned embodiment, it abbreviate | omits suitably.

(3-1) Specific Examples of Acquisition Conditions Presentation Processing, Quest Processing, and Evolutionary Synthesis Reservation Processing Hereinafter, game card acquisition conditions presentation processing, quest processing, and evolutionary synthesis reservation processing of the present embodiment. A specific example will be described with reference to FIG. FIG. 20 is a diagram illustrating an example of a screen displayed on the user terminal 10 when executing the game process of the present embodiment.

(3-1-1) Acquisition condition presentation process (FIG. 20)
In the image P4 of FIG. 12A of the first embodiment, the reference card (here, the card DSG whose display area 102 indicates “not possessed”) to be displayed is selected, and the button b8. When is operated, as shown in FIG. 20, an image P5 indicating the acquisition condition of the reference card selected by the user is displayed.
In addition to the display areas 103 and 104, the image P5 in FIG. 20 includes a button b10 (“do not reserve / go to available area”) and a button b11 (“reserve / go to available area”). This is different from the first embodiment (image P5 in FIG. 12B). The button b10 is a button operated when the user requests a quest process for obtaining an unowned card. The button b11 is a button operated when requesting both the quest process and the reservation process for evolutionary synthesis.

(3-1-2) Quest processing (FIG. 20)
When the button b10 ("do not reserve / go to available area") is operated in the image P5, the image changes as shown in P6. The image P6 is the same as that in the second embodiment (image P6 in FIG. 18).

(3-1-3) Evolutionary synthesis reservation process (FIG. 20)
When the button b11 ("Reserve / Go to available area") is operated in the image P5, the reservation process is executed for the reference card possessed by the user together with the quest process, and the reservation process is completed. An image P7 is displayed.

(3-2) Process flow of game of this embodiment (FIG. 21)
Next, an example of the processing flow of the game of this embodiment will be described with reference to the sequence chart of FIG. The acquisition condition presentation process and the quest process of the present embodiment are executed in the same manner as in the second embodiment.
FIG. 21 is a sequence chart showing reservation processing for evolutionary synthesis. In FIG. 21, the step of displaying each of the images P5 to P7 shown in FIG.

  In the reservation process described below, as an example, it is assumed that the user reserves an unowned reference card for evolution synthesis of a base card among a plurality of reference cards for evolution synthesis of a base card.

In FIG. 21, when the user operates a predetermined button (for example, button b11 of image P5 in FIG. 20) on the image displayed on user terminal 10, CPU 11 of user terminal 10 performs the process of reservation processing for evolutionary synthesis. The request is accepted (S50), and the request is transmitted to the game server 20 (S52). The request includes a card ID that identifies an unowned reference card displayed in the display area 103 of FIG.
Note that S52 is an example of a process of receiving a request for restricting a specified object from being used for a process other than the process of changing the selected object based on an operation by the user.

When the CPU 21 of the game server 20 accepts the request for the reservation process for evolutionary synthesis, it accesses the reservation data table, and whether the reservation ID corresponding to the serial number of the base card acquired in S24 (FIG. 16A) has been issued ( That is, it is determined whether or not the same serial number is recorded in the “pre-evolution card” field (S54).
If the reservation ID has been issued (S54: YES), the process proceeds to S58. If the reservation ID has not been issued (S54: NO), the process proceeds to S58 after issuing the reservation ID (S56). In S58, the CPU 21 writes a temporary serial number in the reservation data table in association with the reservation ID. At this time, when the reservation ID is newly issued, the CPU 21 writes the serial number of the base card among the reservation target cards in the “pre-evolution card” column, and C1 to C5 corresponding to the reservation ID. In the column, data (for example, NULL) indicating that the card is not a reservation target card is written in a column corresponding to the card ID of a card that is not a reservation target card.

Next, the CPU 21 of the game server 20 writes the reservation ID to be written in S58 in the “reservation ID” field corresponding to the card ID of the reservation target card in the possession card data table (S60).
Note that S60 is an example of a process for restricting a specified object from being used for processes other than the process of changing the selected object.

  Next, the CPU 21 generates image data indicating that the reservation is completed (S62), and transmits the image data to the user terminal 10 (S64). When acquiring the image data transmitted in S66, the CPU 11 of the user terminal 10 displays an image (for example, the image P7 in FIG. 20) on the display unit 16 based on the image data (S66).

  Thereafter, when the user obtains the reservation target card (that is, when the card ID and serial number of the reservation target card are recorded in association with the user's possessed card data), the CPU 21 writes the reservation target card in the reservation data table in S58. The temporary serial number is rewritten to the serial number included in the possessed card data.

  In FIG. 21, when a predetermined button (for example, the button b10 of the image P5 in FIG. 20) is operated on the image displayed on the user terminal 10, a quest process similar to that in the second embodiment (FIG. 19). Is done.

  As described above, the game server 20 of this embodiment guides the user to the reference card acquisition route and reserves the reference card together with the acquisition conditions of the reference card that the user does not have. By presenting the operation target for requesting, it is possible to limit the use of the reserved card for processing other than the intended evolutionary synthesis. Therefore, it is possible to prevent the card possessed by the user from being erroneously used for another process other than the intended evolutionary synthesis in the standby period until the remaining reference card not possessed by the user is obtained. .

(4) Fourth Embodiment In the above-described embodiment, the case where an image indicating the acquisition condition is displayed when the user operates a button for requesting the presentation of the acquisition condition of the reference card has been described. In the fourth embodiment, when the user operates a button for confirming the selected card as the base card for evolutionary synthesis, an image showing the acquisition conditions of the reference card for satisfying the change conditions for evolutionary synthesis of the base card is displayed. An example of display will be described. In addition, about the description similar to the above-mentioned embodiment, it abbreviate | omits suitably.

(4-1) Specific Example of Acquisition Condition Presenting Process A specific example of the game card acquisition condition presenting process of the present embodiment will be described below with reference to FIG. FIG. 22 is a diagram illustrating an example of a screen displayed on the user terminal 10 when executing the game process of the present embodiment.

・ Presentation process of acquisition conditions (Figure 22)
FIG. 22 shows a change in a series of display screens in the acquisition condition presenting process for presenting the acquisition condition for the unowned card. Images P1 to P3 in FIG. 22 are the same as the images P1 to P3 in FIG. 12A of the first embodiment, respectively.

  When the button b6 is operated in the image P3, when the card KLM selected as the base card does not satisfy the reference card condition necessary for evolution, the image is updated as shown in P4. The image P4 is an image for presenting conditions for obtaining a card that the user does not possess among the reference cards necessary for the card KLM selected as the base card to evolve. When the user selects the button b6 in the image P3, if the card KLM selected as the base card satisfies the reference card condition necessary for evolution, the card KLM is evolved and synthesized. An image (not shown) for the user to instruct whether or not is displayed.

  In the image P4 of FIG. 22, in the display area 102, in addition to the reference card necessary for evolutionary synthesis and its state (whether possessed, not possessed, reserved, unknown), the acquisition conditions for the unowned card or the unknown card are The points shown are different from the first to third embodiments (image P4 in FIGS. 12A, 13A, and 21A). In the display area 102, as an example, information (in this case, the area name “Area 1”) indicating the acquisition route of the unowned card is shown.

(4-2) Process flow of game of this embodiment (FIG. 23)
Next, an example of the processing flow of the game of this embodiment will be described with reference to the sequence chart of FIG. FIG. 23 is a sequence chart showing acquisition condition presentation processing.
In FIG. 23, the step of displaying each of the images P1 to P4 shown in FIG. Further, in FIG. 23, the same processing as in FIGS. 16A and 16B is denoted by the same reference numeral.

  In the acquisition condition presentation process described below, as an example, when the user has a base card and some of a plurality of reference cards for evolving and synthesizing the base card, an unowned reference Assume that you are requesting the card acquisition conditions.

  After S26 (FIG. 16A) of the first embodiment is executed, the CPU 21 of the game server 20 determines the card data table, the quest data table, and the card distribution data based on the plurality of reference card IDs read in S26. Card data (card name, card image, rarity, quest ID, area name of available area, number of times of acquisition, number of circulations, and average transaction price) are acquired from the table (S38). The card name, card image, and rarity are obtained from the card data table. The quest ID and the area name of the available area are acquired from the quest data table. The number of times of acquisition is acquired from the possession history table. The number of distributions and the average transaction price are acquired from the card distribution data table.

  Next, the CPU 21 of the game server 20 executes S40 to S42 in the same manner as S40 to S42 (FIG. 16B) of the first embodiment, and then based on the card data of the reference card acquired in S38. Image data (image data based on the image P4 in FIG. 22) for presenting the reference card acquisition condition to the user is generated (S44), and the image data is transmitted to the user terminal 10 (S46).

  When receiving the image data transmitted in S46, the CPU 11 of the user terminal 10 displays an image (for example, the image P4 in FIG. 22) on the display unit 16 based on the image data (S48).

  As described above, the game server 20 according to the present embodiment selects a base card that is the target of evolutionary synthesis, based on the acquisition conditions of the reference card that is not possessed by the user and that is necessary for the intended evolutionary synthesis. By presenting according to the user's operation, the operability of the operation for presenting the acquisition conditions for the reference card necessary for the evolutionary synthesis of the base card can be improved.

(5) Fifth Embodiment In the above-described embodiment, the example of displaying the screen for presenting the acquisition conditions for unowned cards has been described. However, in the present embodiment, the screen for presenting the possession card acquisition conditions is displayed. An example of processing for preventing the card specified by the user from being lost in some processing on the screen will be described.

(5-1) Game card reservation registration and favorite registration of this embodiment (FIG. 24)
In the game of the present embodiment, a case is considered in which the user wants to evolve a desired base card by evolution synthesis, but the user does not possess some or all of the reference cards necessary to evolve the base card. In this case, it is necessary to wait for the evolution synthesis of the base card until a new card (that is, the remaining reference card) for satisfying the reference card combination condition is available to the user. However, the user loses the reference card that he / she has before obtaining the remaining reference card by using it for a purpose other than the evolution of the base card, and the conditions for obtaining the reference card are If it is difficult to meet, it will be difficult to evolve the base card. For example, in the case where the user accidentally lost the reference card (e.g., sold) before performing the evolution synthesis, the probability that the reference card can be obtained is low, or the reference card is obtained. When the time period that can be performed is limited, it becomes difficult for the user to evolve the desired base card.
Therefore, in this embodiment, it is possible to reliably prevent the reference card necessary for evolving a desired base card from being lost against the user's intention.

Reference card reservation registration and favorite registration will be specifically described with reference to FIG. FIG. 24 is a diagram for conceptually explaining reference card reservation registration and favorite registration.
In FIG. 24, consider a case where the user wants to evolve the card Q that is the possessed card. Here, it is assumed that a combination of cards A, B, and C is required as a plurality of reference cards in order to evolve the card Q. Since the user does not possess the card B at the present time, the evolution synthesis for the card Q cannot be executed. In addition, when it is difficult to satisfy the conditions for obtaining the card A, if the user disappears from the possession card by using the card A for a purpose other than the evolution of the card Q, the card Q may be evolved. It becomes difficult. Therefore, in the present embodiment, in order to prevent the user from unintentionally erasing the card A from the possessed card, after obtaining the acquisition conditions for the card A, the reservation registration or favorite for the card A is made. Accept registration.
Reservation registration is a state in which the card A is restricted from being used for processing other than the evolution synthesis of the card Q selected as the base card among the processing executed on condition that the card A disappears from the possessed card. is there.
Favorite registration is a state in which the card A is restricted from being used for processing (including evolutionary synthesis of the card Q selected as the base card) that is executed on condition that the card A disappears from the possessed card.
Note that reservation registration and favorite registration are examples of processing for restricting a designated object, which is an object designated by a user, from being used in a predetermined process. The “predetermined process” is a process that is executed on condition that the designated object disappears from the possessed object. That is, an object designated from possessed objects that are objects possessed by the user becomes an object to be restricted by reservation registration and favorite registration.

  In this way, after presenting the acquisition conditions for the card A and accepting reservation registration or favorite registration for the card A, the user immediately recognizes that the card A is difficult to obtain from the presented acquisition conditions. In addition, it is possible to make a request for restricting the use of the card A for the process of disappearing from the possessed card. Therefore, the loss | disappearance contrary to the intention of the card | curd A can be prevented reliably.

(5-2) Configuration of Data Table Next, the possession card data table stored in the storage 25 of the game server 20 will be described in order with reference to FIG.

In the possession card data table, information on the possession card of the user is recorded. FIG. 25 shows a configuration example of the possessed card data table. Although FIG. 25 illustrates the possession card data table for one user, the possession card data table is provided corresponding to all users registered in the game.
The possessed card data table in FIG. 25 is different from the possessed card data table in FIG. 8 in that registration type data is recorded in association with each card ID.
The registration information includes the type of registration performed for possessed card data (reservation registration or favorite registration) and the type of screen on which the registration request is made (screen for presenting acquisition conditions (hereinafter referred to as “acquisition condition presentation screen”). ") Or a reference card list screen required for evolutionary synthesis for each base card"))). In the example of FIG. 25, “1” is recorded in the registration information for a card that has undergone reservation registration via the acquisition condition presentation screen, and a card for which favorite registration has been performed via the acquisition condition presentation screen. “2” is recorded in the registration information, and “4” is recorded in the registration information for a card that has been registered as a favorite via the viewing screen. “N / A” is recorded.

(5-3) Specific Example of Game Display Processing of This Embodiment (5-3-1) Specific Example of Display Processing of Game Acquisition Conditions Presentation Screen of this Embodiment (FIG. 26)
In the image P4 of FIG. 12A of the first embodiment, when the reference card to display the acquisition condition is selected and the button b8 is operated, as shown in FIG. 26, the reference card selected by the user is displayed. An image P5 corresponding to the acquisition condition presentation screen is displayed.

The image P5 of FIG. 26 is different from the first embodiment (image P5 of FIG. 12B) in that it includes a button b12 (“reservation registration”) and a button b13 (“favorite registration”).
The button b12 ("reservation registration") is a button operated when the user requests reservation registration of the possessed card.
A button b13 ("favorite registration") is a button operated when the user requests favorite registration of a possessed card.

When the button b12 ("reservation registration") is operated in the image P5, the image changes as shown in P21. The image P21 shows the execution result of the reservation registration process.
When the button b13 ("favorite registration") is operated in the image P5, the image changes as shown in P22. The image P22 shows the execution result of the favorite registration process.

(5-3-2) Specific example of display processing of game change condition list screen of this embodiment (FIGS. 27A to 27C)
In the image P1 of FIG. 12A of the first embodiment, when the button b4 (“evolution synthesis”) is operated, an image P23a corresponding to the change condition list screen of the present embodiment is displayed as shown in FIG. 27A. The The image P23a is also referred to as a change condition list screen.

The image P23a includes a display area 105, a button b12 (“reservation registration”), and a button b13 (“favorite registration”). The button b12 (“reservation registration”) and the button b13 (“favorite registration”) are the same as the image P5 in FIG.
In the display area 105, the card images and card names of the base card and the reference card are displayed for each combination of the base card and the reference card. In other words, a reference card for each base card is displayed in the display area 105. In the example of FIG. 27A, the reference cards required for the evolution synthesis of the card KLM are the cards VIC, DSG, and MIT, and the reference cards required for the evolution synthesis of the card SAM are the cards MIT, KAY, and TED.
In the display area 105, with respect to the reference card, the possessed card and the unoccupied card are displayed in an identifiable manner. In the example of FIG. 27A, the cards VIC, DSG, MIT, and KEY are displayed with a solid line indicating that they are possessed cards, and the card TED is displayed with a broken line indicating that they are not possessed cards.
In the display area 105, a mark m1 is displayed on the card image of the card that is the target of the reservation registration performed via the acquisition condition presentation screen. The mark m1 is a mark ("" displayed on a card image of a card that is restricted to be used for processing other than evolution synthesis of the base card among the processing executed on the condition that it disappears from the possessed card. Also referred to as “symbol” or “mark”. In the example of FIG. 27A, the mark m1 is displayed on the card image of the card KLM and on the card image of the card DSG. That is, FIG. 27A shows that the card DSG is in a state where use of the card DSG for processing other than the evolution synthesis of the card KLM is restricted among the processing executed on the condition that the card DSG disappears from the possessed card. ing.
In the display area 105, a mark m2 is displayed on the card image of the card that is the target of favorite registration performed via the viewing screen. The mark m2 is a mark displayed on a card image of a card that is restricted to be used for processing (including evolution of base cards) that is executed on the condition that it disappears from the possessed card. In the example of FIG. 27A, the mark m2 is displayed on the card image of the card KAY. That is, FIG. 27A shows that the card KAY is used for all of the processes executed on the condition that the card KAY disappears from the possessed card (for example, the process of evolution synthesis of the card SAM and the process of selling the card KAY). Is in a restricted state.
The user can select a card corresponding to the card image by selecting the card image. In the example of FIG. 27A, when the card image b14 is selected, the card MIT as a reference card necessary for the evolution synthesis of the card KLM is selected, and when the card image b15 is selected, the evolution of the card SAM is performed. The card MIT as a necessary reference card is selected.
The user can request reservation registration or favorite registration for a selected card by operating the button b12 ("reservation registration") or the button b13 ("favorite registration") after selecting the card. In the example of FIG. 27A, when the card image b14 is selected and then the button b12 (“reservation registration”) or the button b13 (“favorite registration”) is operated, the card MIT as a reference card necessary for the evolution synthesis of the card KLM is selected. Reservation registration or favorite registration is required.

In the image P23a, when the user selects the card image b14 and operates the button b12 ("reservation registration"), the image P23b is changed. The image P23b differs from the image P23a in that the mark m3 is displayed on the card image of the card MIT as a reference card necessary for the evolution synthesis of the card KLM. The mark m3 is a mark indicating a reference card that is a target of reservation registration performed via the change condition list screen.
A mark m4 is displayed on the card image of the card MIT as a reference card necessary for the evolution synthesis of the card SAM. The mark m4 is a mark indicating that reservation registration has been performed as a reference card necessary for evolutionary synthesis of another base card (card KLM).
In the example of FIG. 27B, the mark m3 is displayed on the card image of the card MIT as a reference card necessary for the evolution synthesis of the card KLM, and the card MIT card as a reference card necessary for the evolution synthesis of the card SAM. A mark m4 is displayed on the image. In this case, among the processes executed on the condition that the card MIT is erased from the possessed card, the card MIT is restricted from being used for processes other than the evolution synthesis of the card KLM. That is, the card MIT can be used for the evolution synthesis process of the card KLM, but cannot be used for the evolution synthesis process or the sale process of the card SAM.

In the image P23a, when the user selects the card image b14 and operates the button b13 ("favorite registration"), the image P23c is changed. The image P23c is different from the image P23a in that the mark m5 is displayed on the card image of the card MIT. The mark m5 is a mark indicating the reference card that is the target of favorite registration performed via the change condition list screen.
In the example of FIG. 27B, a mark m5 is displayed on the card image of the card MIT as a reference card necessary for the evolution synthesis of the card KLM and the card image of the card MIT as a reference card necessary for the evolution synthesis of the card SAM. Has been. In this case, the card MIT is restricted from being used for all processes executed on condition that the card MIT is erased from the possessed card. That is, the card MIT cannot be used for any of the card KLM evolution process, the card SAM evolution process, and the sale process.

In the images P23a to P23c, the marks m1 to m5 are displayed by shapes, patterns, or combinations thereof that can be distinguished from each other. As a result, the user can use the reference card that is the target of reservation registration performed via the acquisition condition presentation screen, the reference card that is the target of favorite registration performed via the acquisition condition presentation screen, and the change condition. It becomes possible to easily identify the reference card that is the target of the reservation registration performed via the list screen and the reference card that is the target of the favorite registration performed via the change condition list screen.
Specifically, for the marks m1 to m5, the type of registration (reservation registration or favorite registration) is identified by the shape of the mark and a registration request is made (an acquisition condition presentation screen or a change condition) List screen) is identified by the mark pattern.

(5-4) Processing flow of registration processing of this embodiment (FIG. 28)
Next, an example of the processing flow of the game of this embodiment will be described with reference to the sequence chart of FIG. FIG. 28 is a sequence chart showing registration processing.
In FIG. 28, the reference numerals of the images are attached to the steps in which the images P5, P21, and P22 shown in FIG. 26 are displayed. In FIG. 28, the same processing as in FIG. 16B is denoted by the same reference numeral.

  In the registration process described below, as an example of a process for restricting a specified object, which is an object specified by the user, from being used for a predetermined process, a reservation registration process or a favorite registration process is performed. Assume a request.

After S48 (FIG. 16B) of the first embodiment is executed, the CPU 21 of the game server 20 uses the button b12 (“reservation registration”) or the button b13 (“favorite registration”) displayed on the image P5 of FIG. ) Is received (S170), and the request is sent to the game server 20 (S171).
Note that the image P5 in FIG. 26 is an output for displaying the acquisition conditions of the plurality of objects specified by the plurality of object identification information included in the change conditions corresponding to the object identification information of the selected object that is the selected object. It is an example of data.
The reservation registration processing request includes the user ID, the base card serial number, the reference card serial number, and the type of image displayed when the reservation registration processing request is made (for example, FIG. Information specifying the image 26 (P5 or the image P23a in FIG. 27A) (that is, information specifying the type of screen via which a request for reservation registration processing is made) and a request for reservation registration processing. Information to be identified.
The request for favorite registration processing includes the user ID, the serial number of the reference card, and the type of image displayed when the favorite registration processing request is made (for example, image P5 in FIG. 26 or FIG. 27A). Information specifying the image P23a) (that is, information specifying the type of screen via which the request for the favorite registration process is made) and information specifying the request for the favorite registration process are included. .
The request for the reservation registration process and the request for the favorite registration process are examples of a request for restricting a designated object, which is an object designated by the user, from being used for a predetermined process.

When receiving a request from the user terminal 10, the CPU 21 of the game server 20 executes a registration (reservation registration or favorite registration) process corresponding to the request (S172).
Note that the process of S172 is an example of a process for restricting a specified object from being used for a predetermined process.

When the request accepted in S170 is a request for reservation registration processing, the CPU 21 performs the possessed card data specified by the serial number of the reference card included in the request via the acquisition condition presentation screen. The registration information (registration information “1” in FIG. 25) indicating that the card is the target of the reservation registration that was received is recorded. Further, the CPU 21 records the serial number of the reference card in the column corresponding to the card ID of the reference card in C1 to C5 for the reservation data specified by the serial number of the base card included in the request. To do. As a result, the serial number of the reference card subject to reservation registration is recorded in the reservation data specified by the serial number other than the serial number of the base card subject to reservation registration (that is, the reference card is Reserve for evolutionary synthesis of base cards other than the base card) and delete from possession card data (that is, delete the reference card from the possession card (for example, execute a sale process)) Limited.
On the other hand, when the request accepted in S170 is a request for favorite registration processing, the CPU 21 passes the acquisition condition presenting screen to the possessed card data specified by the serial number of the reference card included in the request. The registration information (registration information “2” in FIG. 25) indicating that the card is the target of the favorite registration performed in this way is recorded. As a result, the serial number of the reference card to be registered as a favorite is recorded in the reservation data table and deleted from the possessed card data (that is, the reference card is deleted from the possessed card). Is limited.

  Next, the CPU 21 transmits the execution result of the registration process to the user terminal 10 (S173).

When receiving the execution result of the registration process from the game server 20, the CPU 11 of the user terminal 10 displays a screen based on the execution result (S174). Thereby, the image P21 or P22 of FIG. 26 is displayed on the display unit 16 of the user terminal 10.
Note that S174 is a process of outputting data for displaying an object that is subject to restriction by reservation registration and an object that is subject to restriction by favorite registration in a display format that can be identified by the user. It is an example.

  By using the registration information of FIG. 25, as shown in FIGS. 27A to 27C, using the marks m1 to m5, the type of registration, the type of screen displayed when the registration request is made, and Can be displayed for the user to identify. For example, when the user operates the button b4 (“evolutionary synthesis”) of the image P1 in FIG. 12A, the image P23b in FIG. 27B is displayed on the display unit 16 when the reservation registration process is executed in S172. When the favorite registration process is executed in S172, an image P23c in FIG. 27C is displayed.

As described above, the game server 20 of the present embodiment uses the reservation registration for restricting the reference card possessed in the acquisition condition presentation screen to be used for processes other than the base card evolution synthesis. Or a favorite registration process request for restricting the use of the process to a process executed on the condition that the card is erased from the possessed card (including evolution process of the base card).
As a result, the user can make the reference card unintentionally disappear immediately after recognizing that it is difficult to obtain the possessed reference card on the acquisition condition presentation screen. .
In particular, as the number of cards used as base cards and the reference cards used for the evolutionary synthesis of the basecards increases, it becomes more difficult for the user to manage which reference card should be used for the evolutionary synthesis of which basecards. Become. As a result, the user may lose the reference card against the user's intention due to an operation error or forgetting the use of the reference card.
On the other hand, in the present embodiment, immediately after the user recognizes that the reference card is difficult to obtain from the acquisition condition presentation screen, the reference card is executed on the condition that the reference card is lost. Requests can be made to limit what is used in the process being performed. Therefore, the disappearance of the reference card contrary to the user's intention can be surely prevented.

  In the present embodiment, the user can request two types of registration (reservation registration and favorite registration). Therefore, the user can use the registration properly according to the purpose (that is, select a range of restriction applied to the reference card). For example, a user who wants to use a reference card in the evolutionary synthesis of a specific base card can prevent the loss of the reference card by executing a process other than the evolutionary synthesis of a specific base card by making a reservation registration request. Can do. Further, a user who wants to prevent the reference card from disappearing without determining a base card to be evolved using the reference card can reliably prevent the reference card from disappearing by making a request for favorite registration. . Therefore, the user can flexibly manage the use of the reference card.

In addition, the game server 20 according to the present embodiment is performed on the change condition list screen via the reference card that is the target of the reservation registration performed via the change condition list screen and the acquisition condition presentation screen. The reference card that is the target of favorite registration is displayed in an identifiable manner.
Furthermore, the game server 20 of this embodiment displays the combination of the base card and the reference card that are the targets of reservation registration so that they can be identified.
Furthermore, the game server 20 of the present embodiment displays the reference card that is the object of reservation registration and the reference card that is the object of favorite registration so that they can be identified.
As a result, the user can visually grasp the usage of the possessed card (specifically, it is used for the evolutionary synthesis of a specific base card, or the usage is not yet determined). Become.

(5-5) Modified Example of the Present Embodiment Hereinafter, a modified example of the present embodiment will be described. Note that the following modifications can be combined as appropriate.
(5-5-1) First Modification In the present embodiment, the case has been described where the reference card to be registered (reservation registration or favorite registration) is a possessed card. However, in this embodiment, the reference card to be registered may be an unowned card.
For example, the change condition list screen is configured to accept a reservation registration request or a favorite registration request. When the request is accepted via the change condition list screen, after the user obtains the card subject to the request (that is, the card ID and serial number of the card are recorded in the possessed card data table) Then, reservation registration processing or favorite registration processing is executed for the card.

(5-5-2) Second Modification In this embodiment, the example in which the marks m1 to m5 are displayed on the change condition list screen has been described. However, the marks m1 to m5 are displayed on a screen other than the change condition list screen. May be.

  As an example, the marks m1 to m5 may be displayed on the acquisition condition presentation screen (for example, the image P21 showing the execution result of the reservation registration process or the image P22 showing the execution result of the favorite registration process).

As another example, marks m1 to m5 may be displayed on a screen showing a list of possessed cards (hereinafter referred to as “possession card list screen”).
Specifically, when the button b1 ("see the possessed monster") is operated in the image P1, the possessed card list screen is displayed. On the possessed card list screen, as in the change condition list screens of FIGS. 27A to 27C, information (for example, card images and card names) related to the possessed cards is displayed in a list. Among the possessed cards, any of the marks m1 to m5 is displayed on the card image of the card that is the object of reservation registration or favorite registration.

(5-5-3) Third Modification In this embodiment, an example of accepting a reservation registration or favorite registration request for a selected card has been described. Good.

  For example, when the user selects a card image on which any of the marks m1 to m5 in FIGS. 27A to 27C is displayed, the card corresponding to the selected card image (that is, a reservation registration or a favorite registration state) A request for cancellation of reservation registration or favorite registration is received. Specifically, in FIG. 27A, when the card image on which the mark m1 is displayed is selected, the card DSG for which reservation registration has been made is in a selected state, and is designated when a registration cancellation request is made. Button is displayed. At this time, when the button is operated by the user, the reservation registration made to the card DSG is canceled, and the mark m1 displayed on the card image disappears. As a result, the card DSG enters a state in which no registration is made (that is, a state that can be used for all processes).

  According to this modification, it is possible to cancel the favorite registration and perform reservation registration for a reference card that is a target of favorite registration performed when the usage is not determined. Further, the reservation registration can be canceled and the favorite registration can be performed on the reference card that is the target of the reservation registration performed when the use for the evolutionary synthesis for a specific base card is determined. Therefore, the user can flexibly manage the use of the reference card and the range of restrictions applied to the reference card.

(5-5-4) Fourth Modified Example In this embodiment, as shown in FIG. 26 and FIGS. 27A to 27C, the button b12 (“reservation registration”) and the button b13 (“favorite registration”). However, only one of these two buttons may be displayed.

(5-5-5) Fifth Modification In the present embodiment, an example in which a request for reservation registration or favorite registration processing is made via an acquisition condition presentation screen as shown in an image P5 in FIG. 26 has been described. However, the request may be made via a change condition list screen as shown in the image P23a of FIG. Hereinafter, an example of registration processing when the request is made via the change condition list screen will be described with reference to FIG.

  Specifically, when the user performs an operation on the button b12 (“reservation registration”) or the button b13 (“favorite registration”) with the card image b14 of the image P23a selected, the CPU 11 of the user terminal 10 Based on the operation, a request for reservation registration processing or a request for favorite registration processing is received (S170), and the request is transmitted to the game server 20 (S171).

  When receiving a request from the user terminal 10, the CPU 21 of the game server 20 executes registration (reservation registration or favorite registration) processing according to the request (S172), and displays the execution result of the registration processing as the user terminal 10. (S173).

  When receiving the execution result of the registration process from the game server 20, the CPU 11 of the user terminal 10 displays a screen based on the execution result (S174). Thereby, the image P23b in FIG. 27B or the image P23c in FIG. 27C is displayed on the display unit 16 of the user terminal 10.

  As described above, the registration process in the present modification includes four types of registration (reservation registration performed via the acquisition condition presentation screen, favorite registration performed via the acquisition condition presentation screen, and the change condition list screen. Reservation registration performed via the network and favorite registration performed via the change condition list screen). Each screen displays information about the card in a display format that allows the user to identify the four types of registration.

(6) Sixth Embodiment In the above-described embodiment, communication according to HTTP is performed between the user terminal 10 and the game server 20, and the user terminal 10 interprets an HTML document acquired from the game server 20. In the above description, the case where the present invention is realized by a so-called browser format for displaying game images has been described, but the present invention is not limited to this case. It is realized by a so-called native application format in which the user terminal 10 executes the game program downloaded by the user terminal 10 to execute the game process and suppresses the transmission / reception process between the user terminal 10 and the game server 20. May be. In the native application format, the CPU 11 of the user terminal 10 generates image data without using a web browser, thereby displaying an image on the display unit 16.
In the present embodiment, an example in which the game of the above-described embodiment is realized in a native application format will be described. Note that the hardware configuration of this embodiment may be the same as that of the first embodiment. In the native application format of the present embodiment, it is assumed that most of the processing is performed on the user terminal 10 side, but part of the game processing not described below (for example, lottery processing given to the user by lottery, As for the present process in which the game operator gives a card to the user, etc., the process may be executed on the game server 20 side and the processing result by the game server 20 may be transmitted to the user terminal 10.

In the present embodiment, the user terminal 10 receives a game program from the game operator's server based on a predetermined operation by the user, and the received game program is stored in the storage 18. When the game is started by the user terminal 10, communication is established between the user terminal 10 and the game server 20, and a login process is performed. A data table group (card data table, evolution) is transferred from the game server 20 to the user terminal 10. Composite data table, possession card data table, possession history data table, and card distribution data table) are transmitted. The data table group transmitted to the user terminal 10 is held in the storage 18 of the user terminal 10. In this case, the data table group in the storage 18 is updated each time the user logs in.
In order to prevent the possessed card data table from being falsified in the user terminal 10, the possessed card data table in the user terminal 10 is stored in the game every time predetermined processing by the user terminal 10 is completed or when the user terminal 10 logs out It is transmitted to the server 20. In the game server 20, after comparing the received possessed card data table with the possessed card data table in the storage 25 and confirming that the data has not been tampered with, based on the received possessed card data table, The possessed card data table in the storage 25 is updated.

FIG. 29A and FIG. 29B are sequence charts showing acquisition condition presentation processing of the present embodiment. In each of FIGS. 29A and 29B, the same reference numerals are given to the same processes as those in FIGS. 16A and 16B.
In the evolutionary synthesis reservation process (FIGS. 29A and 29B) of the present embodiment, for example, when logging in, the game server 20 sends the user terminal 10 data groups (card data table, evolutionary synthesis data table, possessed card) in the storage 25. Data table, possession history data table, and card distribution data table) are transmitted (S8). The CPU 11 of the user terminal 10 stores the received data table group in the storage 18 and executes the processes of S14 to S48 in cooperation with the RAM 13 and the display unit 16 based on the operation input from the operation input unit 15. To do.
Although not shown, in the present embodiment, the user terminal 10 performs the evolutionary synthesis process, the quest process, and the evolutionary synthesis reservation process in a similar manner.
In the present embodiment, a card data table, an evolutionary synthesis data table, a quest data table, a possessed card data table, a possession history data table, and a card distribution data table are held in the game server 20, and a reservation data table is stored in the user terminal 10. Although the case where it hold | maintained was demonstrated, it is not restricted to this case. In the game of the native application format, it is possible to appropriately set the holding share of each data table, and it is only necessary to hold it in at least one of the user terminal 10 and the game server 20, and a specific holding mode It is not limited to. When any one of the data tables is held in the game server 20, the data table held in the game server 20 is transmitted to the user terminal 10 when the game is executed, and is used for game processing performed in the user terminal 10. Is done.

(7) Modification common to all embodiments (7-1) Modification regarding application to application other than game In the embodiment and modification described above, the case where the present invention is applied to a game has been described. It may be applied to other applications. For example, when a plurality of types of electronic coupon tickets are distributed each time a product is purchased at a shopping mall on the Internet, the electronic coupon tickets may be used as an example of the object of the present invention. In this case, for example, in order to upgrade the privilege content of the coupon ticket Q as a base object (an example of processing for changing the object), the user possesses and uses coupon coupons A to C as reference objects corresponding to the coupon ticket Q. It is possible to do. In this example, as the purpose of upgrading the coupon voucher Q, conditions for obtaining a coupon voucher (for example, coupon voucher B) that the user does not have among the coupon vouchers A to C necessary for that purpose are presented.
The present invention can be appropriately applied to other applications other than the above-described examples.

(7-2) Modified Example Regarding Operation Input Method In the above-described embodiment, the predetermined operation input to the user terminal is an input of a pressing operation of a predetermined instruction button to the user terminal or a display to the user terminal having a touch panel function. Although the input is a touch operation on the screen, the operation input is not limited to this. The operation input may be an operation input by shaking a user terminal provided with an acceleration sensor, or an operation input by gesture (gesture input). In gesture input, by performing a predetermined gesture on a user terminal having an imaging function, the user terminal recognizes the gesture and recognizes an operation input associated with the gesture in advance. In the case of a user terminal that can execute a voice recognition program, the operation input may be performed by inputting voice.

(7-3) Modification Regarding Handling of User ID In the embodiment described above, the user ID is included in the request transmitted from the user terminal 10 to the game server 20 (that is, the game server 20 is connected to the user terminal 10). Although the description has been made on the assumption that the user who has requested the processing can be specified based on the transmitted request), the method of specifying the user who has requested the processing by the game server 20 is not limited to this.
For example, when a session based on the user ID is established between the user terminal 10 and the game server 20, the game server 20 may specify a user who requests a process subsequent to the session by the user ID. . In this case, the user ID may not be included in the request transmitted from the user terminal 10 to the game server 20 (that is, the user ID may not be transmitted from the user terminal 10 to the game server 20).

(7-4) Modified example related to operation target In the above-described embodiment, the button displayed on the image is shown as an example of the operation target by the user. There may be.

[Summary of Invention]
From the above description, the present invention is grasped as follows, for example.

One embodiment of the present invention provides:
In an information processing apparatus accessible to a storage device that associates and stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for processing to change the object,
Based on a user instruction, a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to the object identification information of the selected object that is the selected object are displayed in a display format that can be identified to the user. Output means (56) for outputting first output data for causing
A receiving unit (51) for receiving an instruction for designating any one of the plurality of objects based on an instruction from the user in response to the output of the first output data by the output unit (56); With
The output means (56) further displays an acquisition condition of the designated object when the user does not have the designated object which is the object designated by the instruction accepted by the accepting means (51). Output the second output data of
Information processing device.

The “information processing apparatus” may be a stand-alone game machine, a user terminal (for example, a portable terminal or a personal computer), a network server, or the like. The entity of the information processing apparatus can be appropriately defined depending on the game implementation form. For example, when the function of each part of the information processing apparatus is realized by the user operating the game machine or the user terminal, the game machine or the user terminal corresponds to the information processing apparatus of the present invention. Alternatively, when the user terminal as a client has a function of accepting an operation input from the user and a function of displaying an image, and the function of each unit of the information processing apparatus is realized by a server that can substantially communicate with the user terminal. The server corresponds to the information processing apparatus of the present invention.
The “storage device” may be a memory device having any configuration, such as a flash memory or an HDD (Hard Disk Drive). The storage device may be a device built in the information processing device, or may be an external device configured to be accessible from the information processing device in a wired or wireless manner.
“Acquisition conditions” are subject conditions (for example, information about the user who owns the object), timing conditions (for example, availability period of the object), and content conditions (for example, average transaction price, first object It may be a second object (e.g., an item) or a combination thereof required for obtaining (e.g., a card), a location condition (e.g., an available area), or a combination thereof.

In the information processing apparatus, the process of changing the selected object is performed based on a change condition including information indicating at least a plurality of objects and user possession information. Therefore, for example, when the change condition is not satisfied, it is not possible to execute the process of changing the selected object. At this time, it may be impossible or difficult for the user to obtain a designated object that the user does not have. However, the user who does not know the acquisition condition of the designated object determines whether or not to execute a process (for example, a quest process) for obtaining the designated object, because it is impossible or difficult to obtain the designated object. It cannot be recognized at that time. In such a case, the user executes the process for obtaining the designated object with the anxiety that it may be impossible or difficult to actually obtain the reference object.
In the information processing apparatus, in response to a request from the user, a condition for obtaining a reference object that the user does not possess is presented. Therefore, even if there is a designated object that cannot be obtained or difficult for the user among the plurality of reference cards corresponding to the selected object, the user has recognized that it is impossible or difficult to obtain the designated object. From the above, it is possible to decide whether or not to execute processing for obtaining the designated object. As a result, it is possible to give a sense of security to the user who executes processing for obtaining the designated object.

The accepting means (51) further selects the selected object for the designated object based on an operation by the user in response to the output of the second output data by the output means (56). Accepts a request to limit the use of a process other than the process to be changed,
The apparatus further includes a restricting unit (58) for restricting the designated object from being used for a process other than the process of changing the selected object in response to the request being received by the receiving unit (51). May be.
“Restricting the use of a process different from the process of changing the selected object” is not limited to prohibiting the process itself other than the process of changing the selected object, and the process of changing the selected object is executable. However, the requirement necessary for the execution of the process may be increased, or the operation necessary for the request for the execution of the process may be complicated.
This restricts the use of the designated object for processes other than the process of changing the selected object in response to a request from the user. Therefore, it is possible to prevent the user from erroneously using the designated object for processing other than the processing for changing the selected object before the change condition is satisfied.

The acquisition condition may be an acquisition route of the designated object.
The “acquisition route” may be, for example, an area where a designated object can be obtained, or an area where an object can be traded between users (for example, a shop in a game).
The “acquisition route” is a combination of a time condition and a place condition (for example, information indicating whether or not a specified object has been issued for a limited time (for example, a limited flag), a limited time available area (For example, the day on which the limited time quest is held), or a combination thereof).
As a result, it is possible to give a sense of security to the user who executes the process for obtaining the designated object. In particular, when the “acquisition route” is a combination of a time condition and a place condition, is it difficult or difficult to obtain the specified object when the user makes a request to execute a process that changes the selected object? This is particularly useful since information for more accurately determining whether or not is presented.

The second output data may include an operation target for guiding a user to the acquisition route.
As a result, it is possible to improve the operability when requesting the execution of the process for obtaining the designated object.

The second output data is not possessed by the user when the designated object has been possessed by the user and information indicating the designated object is obtained by the obtaining means (55). When the object is an unowned object, it may include at least one of an acquisition route and an acquisition difficulty level of the designated object.
Thereby, it is possible to give a sense of security to the user who executes the process for obtaining the unowned object.

The information displayed as the acquisition condition may be limited when the designated object is an unknown object that has never been possessed by the user as compared to when the designated object is the unowned object.
Thereby, it is possible to give a sense of security to the user who executes the process for obtaining the unknown object while maintaining the difficulty level of the game at an appropriate level.

Another aspect of the present invention provides:
A user terminal and a server configured to be communicable with the user terminal, and object identification information that identifies an object, and a change condition that includes a plurality of object identification information used for processing to change the object, An information processing system that can access a storage device that stores information in association with each other,
One of the user terminal and the server is
Based on a user instruction, a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to the object identification information of the selected object that is the selected object are displayed in a display format that can be identified to the user. Output means (56) for outputting first output data for causing
A receiving unit (51) for receiving an instruction for designating any one of the plurality of objects based on an instruction from the user in response to the output of the first output data by the output unit (56); With
The output means (56) further displays an acquisition condition of the designated object when the user does not have the designated object which is the object designated by the instruction accepted by the accepting means (51). Output the second output data of
Information processing system.

Another aspect of the present invention provides:
A computer that can access a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for processing to change the object in association with each other,
Based on a user instruction, a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to the object identification information of the selected object that is the selected object are displayed in a display format that can be identified to the user. Means (56) for outputting first output data for
Means (51) for receiving an instruction to specify any one of the plurality of objects based on an instruction from the user in response to the output of the first output data;
Means (56) for outputting second output data for displaying the acquisition condition of the designated object when the user does not have the designated object which is the object designated by the accepted instruction;
It is a program to make it function as.

Another aspect of the present invention provides:
In an information processing apparatus accessible to a storage device that associates and stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for processing to change the object,
First output for outputting first output data for displaying acquisition conditions for a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to the object identification information of a selected object that is a selected object Means,
In response to the output of the first output data by the first output means, a request for restricting the first specified object, which is an object specified by the user, from being used in a predetermined process is issued. First receiving means for receiving;
First restriction means for restricting the first designated object from being used in the processing in response to the request being accepted by the first acceptance means;
Is an information processing apparatus.

  Thus, the user can make the reference card not disappear immediately after recognizing that it is difficult to obtain the reference card on the screen presenting the acquisition conditions. Therefore, the loss | disappearance contrary to the intention of a reference card can be prevented reliably.

A second output means for outputting second output data for displaying a plurality of objects in a display format identifiable to the user;
In response to the output of the second output data by the second output means, a second designated object that is an object designated by the user among the plurality of objects is used for a predetermined process. A second accepting means for accepting a request for restriction;
A second restricting means for restricting the second designated object from being used in the processing in response to the request being accepted by the second accepting means;
At least one of the first output data and the second output data includes an object subject to restriction by the first restricting means and an object subject to restriction by the second restricting means, It may be data for display in a display format that can be identified by the user.

Further, the object to be restricted is an object designated from possessed objects that are objects possessed by the user,
The predetermined process may be a process that is executed on condition that the specified object disappears from the possessed object.

  The “process executed on condition that the specified object disappears from the possessed object” means that the specified object disappears from the possessed object when the process is executed (that is, the specified object is It becomes an unowned object) process.

  Further, it is a condition that at least one of the request received by the first receiving unit and the request received by the second receiving unit is deleted from the possessed object with respect to the object to be restricted. Used for processing other than the processing that changes the selected object among the processing that is executed on the condition that the first request for restricting the usage to be executed as a processing and the disappearance from the possessed object. And a second request for restriction.

Both “the process of changing the selected object” and “the process other than the process of changing the selected object” are one form of “a process executed on the condition that the selected object disappears”.
The “first request” is a request for restriction on all processes executed on condition that the first designated object disappears from the possessed object.
The “second request” is a restriction on all processes other than the process of changing the selected object among the processes executed on condition that the first designated object disappears from the possessed object (in other words, the selected object is changed) Only the process to be allowed).

  The second output data is data for displaying the object that is the target of the first request and the object that is the target of the second request in a display format that can be identified by the user. It may be.

"The object that is the target of the first request" means an object that is restricted in use for all processing executed on the condition that it disappears from the possessed object (that is, a state that cannot be disappeared from the possessed object). Object).
The “object that is the target of the second request” is restricted to use for processes other than the process for changing the selected object (that is, only the use for the process for changing the selected object is permitted). ) Object.

Another aspect of the present invention provides:
A user terminal and a server configured to be communicable with the user terminal, and object identification information that identifies an object, and a change condition that includes a plurality of object identification information used for processing to change the object, An information processing system that can access a storage device that stores information in association with each other,
One of the user terminal and the server is
First output for outputting first output data for displaying acquisition conditions for a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to the object identification information of a selected object that is a selected object Means,
In response to the output of the first output data by the first output means, a request for restricting the first specified object, which is an object specified by the user, from being used in a predetermined process is issued. First receiving means for receiving;
First restriction means for restricting the first designated object from being used in the processing in response to the request being accepted by the first acceptance means;
An information processing system comprising:

Another aspect of the present invention provides:
A computer that can access a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for processing to change the object in association with each other,
Means for outputting first output data for displaying acquisition conditions for a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to the object identification information of the selected object that is the selected object;
Means for accepting a request for restricting the first designated object, which is an object designated by the user, from being used for a predetermined process in response to the output of the first output data;
Means for restricting the first designated object from being used in the processing in response to the request being accepted;
It is a program that functions as

  In the above, in order to facilitate the understanding of the present invention, the reference numerals described in the drawings are appropriately described in parentheses, but the information processing apparatus and the like according to the present invention are thereby limited to the illustrated embodiments. It is not a thing.

DESCRIPTION OF SYMBOLS 1 ... Game system 10 ... User terminal 11 ... CPU
12 ... ROM
13 ... RAM
DESCRIPTION OF SYMBOLS 15 ... Operation input part 16 ... Display part 17 ... Communication interface part 18 ... Storage 19 ... Bus 20 ... Game server 21 ... CPU
22 ... ROM
23 ... RAM
24 ... Communication interface unit 25 ... Storage 26 ... Bus 51 ... Accepting means 52 ... Game processing means 54 ... Card data changing means 55 ... Acquisition means 56 ... Output means 57 ... Recording means 58 ... Limiting means 70 ... Data table group

Claims (8)

In an information processing apparatus accessible to a storage device that associates and stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for processing to change the object,
Based on a user instruction, a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to the object identification information of the selected object that is the selected object are displayed in a display format that can be identified to the user. Output means for performing a first output control for
Receiving means for receiving an instruction to specify any one of the plurality of objects based on an instruction from the user in response to the first output control being performed by the output means;
And the output means, among the plurality of available pathways, operably an operation object for guiding the user to a possible acquisition route to obtain the given object is the object specified by the instruction accepted by said accepting means Performing second output control for display,
Information processing device. The output means performs a third output control for displaying information related to an acquisition route of a designated object that is an object designated by an instruction accepted by the accepting means;
The information processing apparatus according to claim 1. The output means performs fourth output control corresponding to the acquisition route of the designated object after an operation on the operation target by the user is performed.
The information processing apparatus according to claim 1 or 2. When the predetermined condition is satisfied, the second output control is performed.
The information processing apparatus according to any one of claims 1 to 3. The acquisition route is an in-game shop where the specified object can be traded.
The information processing apparatus according to any one of claims 1 to 4. The first output control displays an object possessed by the user and an object not possessed by the user in a display format that can be identified by the user among the plurality of objects to be displayed.
The information processing apparatus according to any one of claims 1 to 5.   The program for functioning a computer as each means of the information processing apparatus as described in any one of Claims 1-6.   An information processing system including a user terminal and a server configured to be able to communicate with the user terminal, wherein each unit of the information processing apparatus according to any one of claims 1 to 6 An information processing system provided in either the terminal or the server.