JP7115763B2 - Information processing device, program, information processing system - Google Patents

Description

The present invention relates to information processing technology for processing information about objects.

In recent years, so-called social games have become popular as applications executed in social networking services (SNS). Digital card games using cards are known as such social games.
In addition, a main card and a sub card are selected by the user from cards owned by the user, and the main card and the sub card are synthesized, thereby changing the ability parameters of the main card and replacing the sub card from the cards owned by the user. There are known games in which deletion is performed (Patent Literatures 1 and 2).

Japanese Patent No. 5086491 Japanese Patent No. 5153960

In the synthesizing process, the user must possess a plurality of reference objects (corresponding to the above sub cards) that satisfy the combination conditions corresponding to the base objects (corresponding to the above main cards) in order to realize the synthesizing process of the base objects (corresponding to the above main cards). may be a requirement. In that case,
The user must possess all reference objects that satisfy the combination conditions in order to perform the compositing process.

At this time, it may be impossible or difficult for the user to obtain a reference object that the user does not possess. However, a user who does not know the conditions for obtaining the reference object will recognize that it is impossible or difficult to obtain the reference object at the time of deciding whether or not to execute the process for obtaining the reference object. Can not. In such a case, the user will carry out the processing for obtaining the reference object, while being worried that it may be impossible or difficult to actually obtain the reference object.

The present invention has been made in view of the above-mentioned viewpoints, and its object is to identify a reference object necessary for a process of changing an object, which is executed when a change condition including information indicating at least a plurality of objects is satisfied. To provide an information processing device, a program, and an information processing system that eliminate user's uneasiness in processing for obtaining.

One aspect of the present invention is
In an information processing device capable of accessing 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 in a process of changing the object,
Based on a user's instruction, a plurality of objects identified by a plurality of object identification information contained in a change condition corresponding to the object identification information of the selection object, which is the selected object, is displayed in a display format that allows the user to identify each object. first to let
output means for outputting output data;
receiving means for receiving an instruction to designate one of the plurality of objects based on the user's instruction in response to the output of the first output data by the output means;
The output means further outputs second output data for displaying acquisition conditions of the specified object when the user does not possess the specified object, which is the object specified by the instruction received by the receiving means. Output,
It is an information processing device.

Another aspect of the invention is
In an information processing device capable of accessing 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 in processing for changing the object,
a plurality of objects specified by a plurality of pieces of object identification information included in a change condition corresponding to the object identification information of the selection object, which is the selected object, and one of the plurality of objects possessed by the user, based on an instruction from the user; An information processing apparatus comprising: output means for outputting output data for displaying acquisition conditions of objects that have not been acquired and data in a display format that can be identified by a user.

Another aspect of the invention is
In an information processing device capable of accessing 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 in a process of changing the object,
Based on a user's instruction, a plurality of objects identified by a plurality of object identification information included in a change condition corresponding to the object identification information of the selection object, which is the selected object, is displayed in a display format that allows the user to identify each object. first to let
output means for outputting output data;
receiving means for receiving an instruction to designate one of the plurality of objects based on the user's instruction 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 acquisition difficulty of the specified object when the user has never possessed the specified object, which is the object specified by the instruction received by the receiving means. output data,
It is an information processing device.

Another aspect of the invention is
A user terminal and a server configured to be able to communicate with the user terminal, and object identification information for specifying an object, and change conditions including a plurality of object identification information used for processing to change the object An information processing system capable of accessing a storage device stored in correspondence,
Either the user terminal or the server,
Based on a user's instruction, a plurality of objects identified by a plurality of object identification information included in a change condition corresponding to the object identification information of the selection object, which is the selected object, is displayed in a display format that allows the user to identify each object. first to let
output means for outputting output data;
receiving means for receiving an instruction to designate one of the plurality of objects based on the user's instruction in response to the output of the first output data by the output means;
The output means further outputs second output data for displaying acquisition conditions of the specified object when the user does not possess the specified object, which is the object specified by the instruction received by the receiving means. Output,
It is an information processing system.

Another aspect of the invention is
A computer capable of accessing a storage device that associates and stores object identification information that identifies an object and change conditions that include a plurality of object identification information used in processing for changing the object,
Based on a user's instruction, a plurality of objects identified by a plurality of object identification information contained in a change condition corresponding to the object identification information of the selection object, which is the selected object, is displayed in a display format that allows the user to identify each object. first to let
means for outputting output data;
means for receiving an instruction to designate one of the plurality of objects based on the user's instruction in response to the output of the first output data;
a second method for displaying acquisition conditions for the specified object when the user does not possess the specified object, which is the object specified by the received instruction;
means for outputting output data;
It is a program for functioning as

Another aspect of the invention is
In an information processing device capable of accessing 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 in a process of changing the object,
a 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 change conditions corresponding to object identification information of the selected object; means and
requesting, in response to the output of the first output data by the first output means, to limit the use of a first specified object, which is an object specified by a user, in a predetermined process; a first receiving means for receiving;
a first restricting means for restricting the first specified object from being used in the process in response to the acceptance of the request by the first accepting means;
An information processing device comprising

Another aspect of the invention is
A user terminal and a server configured to be able to communicate with the user terminal, and object identification information for specifying an object, and change conditions including a plurality of object identification information used for processing to change the object An information processing system capable of accessing a storage device stored in correspondence,
Either the user terminal or the server,
a 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 change conditions corresponding to object identification information of the selected object; means and
requesting, in response to the output of the first output data by the first output means, to limit the use of a first specified object, which is an object specified by a user, in a predetermined process; a first receiving means for receiving;
a first restricting means for restricting the first specified object from being used in the process in response to the acceptance of the request by the first accepting means;
An information processing system comprising:

Another aspect of the invention is
A computer capable of accessing a storage device that associates and stores object identification information that identifies an object and change conditions that include a plurality of object identification information used in processing for changing the object,
means for outputting first output data for displaying acquisition conditions of a plurality of objects specified by a plurality of object identification information included in change conditions corresponding to object identification information of the selected object;
means for receiving a request to limit use of a first specified object, which is an object specified by a user, in a predetermined process in response to output of the first output data;
means for restricting the first specified object from being used in the process in response to the acceptance of the request;
It is a program that functions as

The figure which shows the basic composition of the game system of 1st Embodiment. 2 is a block diagram showing the configuration of a user terminal according to the first embodiment; FIG. 1 is a block diagram showing the configuration of a game server according to the first embodiment; FIG. FIG. 4 is a diagram for conceptually explaining the presentation of conditions for obtaining a reference card according to the first 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 synthesis 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 possessed card data table of 1st Embodiment. The figure which shows the structural example of the reservation data table of 1st Embodiment. 4 is a diagram showing a configuration example of a possession history data table according to the first embodiment; FIG. The figure which shows the structural example of the card circulation data table of 1st Embodiment. FIG. 7 is a diagram showing an example of an image displayed on the user terminal when the game of the first embodiment is executed; FIG. 7 is a diagram showing an example of an image displayed on the user terminal when the game of the first embodiment is executed; FIG. 7 is a diagram showing an example of an image displayed on the user terminal when the game of the first embodiment is executed; FIG. 7 is a diagram showing an example of an image displayed on the user terminal when the game of the first embodiment is executed; FIG. 7 is a diagram showing an example of an image displayed on the user terminal when the game of the first embodiment is executed; 3 is a functional block diagram of the game server of the first embodiment; FIG. FIG. 4 is a sequence chart showing an example of acquisition condition presentation processing according to the first embodiment; FIG. FIG. 4 is a sequence chart showing an example of acquisition condition presentation processing according to the first embodiment; FIG. 4 is a sequence chart showing an example of evolutionary synthesis processing according to the first embodiment; FIG. 11 is a diagram showing an example of an image displayed on the user terminal when the game of the second embodiment is executed; The sequence chart which shows an example of the Qwest process of 2nd Embodiment. FIG. 12 is a diagram showing an example of an image displayed on the user terminal when the game of the third embodiment is executed; FIG. 11 is a sequence chart showing an example of reservation processing for evolutionary synthesis according to the third embodiment; FIG. FIG. 12 is a diagram showing an example of an image displayed on the user terminal when executing the game of the fourth embodiment; FIG. 14 is a sequence chart showing an example of acquisition condition presentation processing according to the fourth embodiment; FIG. FIG. 12 is a diagram for conceptually explaining reservation registration and favorite registration of a reference card according to the fifth embodiment; The figure which shows the structural example of the possessed card data table of 5th Embodiment. FIG. 12 is a diagram showing an example of an image displayed on the user terminal when executing the game according to the fifth embodiment; FIG. 12 is a diagram showing an example of an image displayed on the user terminal when executing the game according to the fifth embodiment; FIG. 12 is a diagram showing an example of an image displayed on the user terminal when executing the game according to the fifth embodiment; FIG. 12 is a diagram showing an example of an image displayed on the user terminal when executing the game according to the fifth embodiment; FIG. 12 is a sequence chart showing an example of registration processing according to the fifth embodiment; FIG. FIG. 14 is a sequence chart showing an example of acquisition condition presentation processing according to the sixth embodiment; FIG. FIG. 14 is a sequence chart showing an example of acquisition condition presentation processing according to the sixth embodiment; FIG.

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

FIG. 1 shows a system configuration example of a game system 1 of an embodiment. As shown in FIG. 1, this game system 1 includes user terminals 10a, 10b, 10c, . The game server 20 can be accessed from each user terminal 10a, 10b, 10c through a communication network NW such as the Internet. The game server 20 is an example of an information processing device.
Each user terminal 10a, 10b, 10c, . . . is a terminal operated by an individual user. Also includes so-called multifunctional smart TVs.), communication terminals such as portable game machines with communication functions. In the following description, user terminals 10a, 10b, 10c, . . .

The game server 20 is a server that executes games. The game server 20 stores image data that can be interpreted by a web browser (eg, 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 has a web browser that interprets and displays HTML data provided by the game server 20. Requests based on user operations on web pages from the user terminal 10 are sent to the game server 20 via the network. to the game server 20
Executes game processing by receiving the processing results from
The communication network NW includes the Internet, WAN (Wide Area Network), LAN (Local Area Network),
network), leased lines, or an information communication network configured by a combination of these.

(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, R
It has an OM (Read Only Memory) 12, a RAM (Random Access Memory) 13, an operation input section 15, a display section 16, a communication interface section 17, and a storage 18, and transmits control signals or data signals between each section. A bus 19 is provided for

The CPU 11 reads out programs and data stored in the ROM 12 and controls the overall operation within the user terminal 10 , such as timing processing of control signals and data signals with each unit within the user terminal 10 . The CPU 11 also reads programs stored in the storage 18 and various data necessary for executing the programs, develops them 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 programs. 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 the web browser stored in the storage 18 into the RAM 1
3 and run it. Then, the CPU 11 controls the communication interface unit 17 based on the specification of the URL (Uniform Resource Locator) input by the user through the operation input unit 15 or the like.
Data for displaying a web page from the game server 20, that is, HT
Object data such as ML (HyperText Markup Language) documents and images associated with the documents (hereinafter collectively referred to as "HTML data" as appropriate) is acquired via the communication interface unit 17, and the web browser to interpret the HTML data. Note that the user terminal 10 may be equipped with various plug-ins for extending the browser functions of the web browser. An example of such a plug-in is Flash Player by Adobe Systems, USA. Alternatively, the HTML data in the present embodiment may be in HTML5 format with video and audio playback functions.

The web browser communicates with the game server 20 according to HTTP (HyperText Transfer Protocol). When a user selects a URL (Uniform Resource Locator) or an operation target (for example, a software button (hereinafter simply referred to as a "button") on a web page by operating the operation input unit 15, the web browser , sends an HTTP request containing the selection result to the game server 20 for updating the web page. The web browser acquires HTML data from the game server 20 as an HTTP response,
After interpreting, the web page is displayed on the display unit 16 .

The display unit 16 is, for example, an LCD (Liquid Crystal Display) or an organic EL (Electro Luminous Display).
A display device such as a luminescence) display. When an LCD (Liquid Crystal Display) monitor including thin film transistors arranged in a matrix for each pixel is applied, the display unit 1
6 displays the image of the web page on the display screen by driving the thin film transistor.

When the user terminal 10 is a button input type user terminal, the operation input unit 15 includes a plurality of instruction input buttons such as a direction instruction button, an enter button, and a numeric keypad for accepting user operation input. includes an interface circuit for recognizing the pressing (operation) input of 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
It accepts touch panel type input mainly by touching the display screen with a fingertip or a pen.

The storage 18 is a storage device configured by, for example, flash memory or 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 section 24, and a storage 25. A bus 26 is provided for transmitting control signals or data signals between the sections. ing. In addition, the game server 20
As for hardware, it can have the same configuration as a general-purpose network server.

The CPU 21 reads out programs and data stored in the ROM 22 and controls the overall operation within the game server 20 , such as timing processing of control signals and data signals with each unit within the game server 20 . The CPU 21 also reads programs stored in the storage 25 and various data necessary for executing the programs, develops them 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 programs. I do. RAM2
3 temporarily stores data for arithmetic processing, determination processing, etc. by the CPU 21;

For example, the storage 25 stores a program for providing web services by communicating with the web browser of the user terminal 10, which is a client, according to HTTP. The CPU 21 expands the program stored in the storage 25 to 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 HTML data including the execution result (image data described later). 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 HDD (Hard Disk Drive), and stores the data table group 70 in addition to the programs described above. The data table group 70 (to be described later) includes a card data table, an evolution synthesis data table, a quest data table, a possessed card data table, a reservation data table, a possessed history data table, and a card circulation data table. Each data table is accessed by the CPU 21 for reading and writing data as appropriate.

(1-4) Presentation of Conditions for Acquisition of Cards for Game of the Present Embodiment A game executed in the game system 1 of the present embodiment is a game executed by a user using cards as objects. In this game, for example, the user searches the game area to obtain cards and items, or uses the cards owned by the user to compete against other users or NPCs (Non-Player Characters).
In the game of the present embodiment, card evolution synthesis processing (hereinafter simply referred to as “evolutionary synthesis” as appropriate) is processing for evolving a card possessed by a user when a predetermined condition is satisfied. In the example of the present embodiment, card evolution synthesis is a process of changing a card ID as described later, but it may be a process of changing at least part of card data (described later) corresponding to a card. In this case, the change target of the card data is not particularly limited. For example, card parameters such as card name, card image, and rarity may be changed. Evolutionary synthesis of cards is an example of a process of changing an object.
In order to perform evolutionary synthesis, the user must have a card in his/her possession (hereinafter referred to as “possession card” as appropriate).
It says. ), select the base card as the card to be evolved (that is, the card to be processed to change the card data). A card selected as a base card is an example of a selection object.
In evolutionary synthesis, conditions for combining a plurality of cards (referred to as "reference cards") necessary for evolving the base card are determined for each base card. When the evolutionary synthesis is executed, the reference card used for the evolutionary synthesis disappears from the user's possession cards.
In the game of this embodiment, the condition for evolving the selected card ( An example of change conditions).

In addition, in the game of this embodiment, for example, a normal combining process and a selling process are provided as processes in which the user loses his own card. In order to perform normal synthesizing processing, the user selects a base card as a card to be grown from the cards owned by the user. In normal synthesizing processing, conditions for changing cards (e.g., evolutionary synthesizing processing) are defined. Change conditions are not defined for each base card. can be selected. When the normal synthesizing process is executed, the reference card disappears from the user's possession cards instead of changing the card parameters of the base card (for example, increasing the card level or skill level).
In the selling process, a card selected from among the cards possessed by the user (for example, a card that the user does not need) is sold instead of the user obtaining a selling price (for example, game points) corresponding to the card. The card that has been deleted disappears from the user's possession card.

In the game of this 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 for evolving the card. In this case, it is necessary to wait to perform the evolutionary synthesis of the desired cards until the user has available a new card (ie, the remaining reference cards) to satisfy the reference card combination condition. However, if the user forgets the conditions for obtaining the remaining reference cards (hereinafter referred to as "conditions for obtaining"), obtaining the reference cards becomes difficult. In particular, as the number of acquired cards increases, the possibility of forgetting the acquisition conditions for each card increases.
Therefore, in the present embodiment, it is possible to present acquisition conditions for a reference card that the user does not possess (unpossessed card or unknown card) among the plurality of reference cards required to evolve the base card. The non-possessed card is a card that has been possessed by the user and is not possessed by the user when the base card is selected. on the other hand,
An unknown card is a card that has never been possessed by a user.

Presenting the conditions for obtaining the reference card will be specifically described with reference to FIG. FIG. 4 is a diagram for conceptually explaining the presentation of conditions for obtaining a reference card.
In FIG. 4, consider a case where the user wants to evolve card Q, which is a card owned by the user. Here, in order to evolve card Q, cards A, B, and C are used as a plurality of reference cards.
Assume that a combination of Since the user does not have card B at the moment, evolutionary synthesis cannot be performed on card Q. In addition, since the user has forgotten the conditions for obtaining Card B, it is difficult for the user to obtain Card B. In this case, in the present embodiment, the conditions for obtaining card B are presented to the user in response to a request for presentation of the conditions for obtaining card B so that the user can easily obtain card B. FIG. As a result, the user can easily obtain card B.

(1-5) Configuration of Data Table Next, a card data table, an evolution synthesis data table, a quest data table, a possession card data table, a reservation data table, a possession history data table, and , about the card circulation data table, Fig. 5 ~
11, will be described in order.

(i) Card data table Card data used in the game of this embodiment is recorded in the card data table. FIG. 5 shows a configuration example of the card data table. In the example shown in FIG. 5, the card ID
Each card name, card image, and card parameter data are included.
A card ID is identification information that identifies a card, which is an example of an object. Card I
D is uniquely assigned to each card. A card ID identifies one card out of a plurality of cards. 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. A card image is an image of a character displayed on a card. Card parameters consist of rarity, attribute, cost, skill, selling price, attack power, defense power, and limited flag data.
The rarity is an index indicating the rarity value of the card, and in the example shown in FIG. 5, the rarity is set in the order of R1 to R5.
The attribute is the attribute of the character displayed on the card, and is one of N1 to N3 in the example shown in FIG.
A cost is a value that is referenced when a card is incorporated into a user's card team. For example, when a card team battles, the total cost of the cards included in the card team is limited to a predetermined value or less.
A skill is information indicating an advantageous effect when playing a game using a card.
In the example shown in FIG. 4, skills SK1 to SK12 with various effects are set on each card. Not all cards need to have skills.
The selling price is the points in the game that the user obtains when he/she sells the card that the user owns.
Attack power and defense power are parameters that are referred to when cards are used in battle.
The limited flag is a flag indicating whether or not the card is issued for a limited period of time. In the example shown in FIG. 4, a card with a limited flag of "1" means that the card is issued for a limited period, and a card with a limited flag of "0" means that the card is not limited to a limited period. do.

(ii) Evolutionary Synthesis Data Table In the evolutionary synthesis data table, conditions for evolutionary synthesis of cards in the game of this embodiment are recorded. 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 content of evolutionary synthesis, a pre-evolution card ID (that is, a card ID of a base card before evolution), a card ID after evolution (a card ID of a base card before evolution), card IDs after evolution), and conditions for changing the card IDs of reference cards required for executing evolutionary synthesis (five reference cards in columns C1 to C5) are recorded. For example, evolution ID: 000
2, the user selects a card with card ID: 0072 as a base card from among the cards possessed by the user, and card IDs: 0025, 0060, 00 among the cards possessed by the user.
When there are 70 combinations of three cards, a card with card ID: 0072 can be evolved into a card with card ID: 9072 by executing evolutionary synthesis.
Here, as an example of the process of changing an object, the 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. In other words, FIG. 6 shows that the change condition includes a plurality of object identification information used in the process of changing the object.
In addition, the same card ID may be recorded in at least any two columns of C1 to C5 indicating combinations of card IDs of reference cards. For example, two or more of the same reference cards may be included in the combination of reference cards used when evolving the base card. The combination condition of the reference card for evolving the base card is the same card I
In the case where a predetermined number of D reference cards are included, the data format may be a data format consisting of the card ID of the reference card and the number thereof, instead of the data format shown in FIG.

(iii) Quest Data Table The quest data table records data of quests, which are one of the events carried out in the game of this embodiment. Quests are used to obtain cards and items.
It is an event for the purpose of the user searching the area in the game and achieving a predetermined quest condition. FIG. 7 shows a configuration example of the quest data table. In the example shown in FIG. 7, for each quest ID, an area name, energy consumption, information on available cards (card ID and availability), information on available items (item ID and availability), boss ID
, and quest UI data.
The area name is a character string indicating the name of the area used in the quest.
Consumed physical strength is a value referred to when carrying out a quest. In order to carry out the quest, the physical strength value, which is one of the user's parameters, must be greater than or equal to the consumed physical strength value. When the quest is executed, the value of the user's physical strength is consumed by the value of the consumed physical strength.
Information on available cards (available card data 1, 2, . . . ) consists of card IDs and availability rates. The card ID is identification information of a card that can be obtained when the quest condition is fulfilled. The availability rate is a numerical value that indicates the probability of obtaining the card when the quest conditions are met.
Information on available items (available item data 1 . . . ) consists of item IDs and availability rates. The item ID is identification information of an item that can be obtained when the quest condition is fulfilled. Availability is a numerical value that indicates the probability of obtaining an item when the quest conditions are met.
The boss ID is identification information of an NPC (for example, a boss character) that will be your opponent in the quest. A quest condition is achieved, for example, by winning a battle against a boss character.
The quest UI data is user interface data used in the quest (for example, image data used in the quest).

(iv) Possessed Card Data Table In the possessed card data table, information on user's possessed cards is recorded. FIG. 8 shows a configuration example of the possessed card data table. Although FIG. 8 illustrates the possessed card data table for one user, the possessed card data table is provided for all users registered in the game.
In the possessed card data table shown in FIG. 8, each data of serial number, card level, skill level, and reservation ID are associated with each card ID and recorded.
A serial number is a unique number determined when a card is given to a user. Different serial numbers are assigned to cards with the same card ID. When the card evolves, the serial number may or may not change before and after the card evolves.
The card level is a parameter indicating the level of card development, and is increased, for example, by performing the above normal synthesis. The card level value (initial value) when the user acquires the card is 1, and the user can grow the card (that is, increase the card level) by performing normal synthesis or the like.
The skill level is a parameter indicating the training level of a card, and particularly a parameter indicating the skill level of the card. The skill level value (initial value) at the time the user acquires a card with a skill is 1. For example, the skill level of the card is increased by performing normal synthesis using a card that satisfies a predetermined condition as a reference card. can be made As a card's skill level increases, the effect produced by the skill increases.
The reservation ID is identification information for identifying reservation contents for evolutionary synthesis. A reserved card owned by a user is associated with a reservation ID. For example, in the example shown in FIG. 8, five cards with card IDs: 0591, 0010 (two cards), 0033, and 2005 are reserved cards. The reservation ID recorded in the possessed 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 evolutionary synthesis of users. FIG. 9 shows a configuration example of the reservation data table. Although the reservation data table for one user is illustrated in FIG. 9, the reservation data table is provided for all users registered in the game.
In FIG. 9, the reservation ID is an ID issued in the order in which reservations for evolutionary synthesis are made. Figure 9
2, numbers are recorded in ascending order such as 01, 02, . . . . The evolutionary ID corresponds to the evolutionary ID shown in the evolutionary synthesis data table, and is an ID that specifies the contents of the evolutionary synthesis.
is.
Of the reserved card serial numbers, the serial number of the pre-evolution card is the serial number of the possessed card selected by the user as the base card for evolutionary synthesis. The columns C1 to C5 of the reference card in the serial numbers of the reserved cards respectively correspond to the columns C1 to C5 forming 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 a non-possessed 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 to the serial number of the reference card. Data indicating "no reservation" (for example, NULL) is recorded in the column corresponding to the card ID of the reference card that is not reserved.
In addition, although the case where the reservation data table is provided will be described below, it is not essential to provide the reservation data table independently. As a method of managing reservations for evolutionary synthesis,
Data to be recorded in the reservation data table may be recorded in the possessed card data table. In that case, in the possession card data table, in association with the card ID of the reserved card, a reservation ID, an evolution ID, or a character string of one of C1 to C5 (corresponding to the C1 to C5 columns of the evolution synthesis data table) Any character string that

(vi) Possession History Data Table In the possession history data table, information on cards possessed by the user is recorded. FIG. 10 shows a configuration example of the possession history data table. Although the possession history data table for one user is illustrated in FIG. 10, 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 associated with each card ID and recorded. The acquisition count is a value indicating the number of times the user has acquired the card in the game. A card that has been obtained 0 times is an unknown card.

(vii) Card Distribution Data Table The card distribution data table stores information about cards distributed within the game. FIG. 11 shows a configuration example of the card circulation data table. In the example shown in FIG. 11, the card distribution data table records the number of cards in circulation and the average transaction price for each card ID.
The number of cards in circulation is a value that indicates the total number of cards set by the user as cards to be traded (for example, traded) in the game. The higher the number of cards in circulation, the lower the difficulty of obtaining the card.
The average transaction price is the average price at which cards are traded between users. The higher the average transaction price, the more difficult it is to obtain the card.

In the following description, information associated with the card ID in the card data table, quest data table, possession card data table, possession history data table, and card distribution data table (e.g., card name, card image, card parameters, Quest ID, area name, consumed physical strength, acquisition rate, boss ID, quest UI data, serial number,
card level, skill level, reservation ID, number of acquisitions, number of circulations, and average transaction price) are collectively referred to as "card data" as appropriate. Card data is an example of information indicating an object.

(1-6) Specific Examples of Acquisition Condition Presentation Processing and Evolutionary Synthesis Processing Specific examples of card acquisition condition presentation processing and evolutionary synthesis processing of the game of this embodiment will be described below with reference to FIGS. 12A, 12B, 13A, Description will be made with reference to FIGS. 13B and 14. FIG. 12A, 12B, 13A, 13B, and 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 processing (1-6-1-1) Acquisition condition presentation processing for non-possessed cards (Figs. 12A and 12B)
FIG. 12A and FIG. 12B show a series of changes in display screens in the process of presenting acquisition conditions for presenting the acquisition conditions of an unpossessed 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 this embodiment. In the image P1, as the user's operation objects, a button b1 ("View owned monsters"), a button b2 ("Team formation"), a button b3 ("Normal synthesis"), a button b4 ("Evolutionary synthesis"), a button b5 (“Sale”) is provided.
The button b1 is a button that is operated when requesting processing for viewing the user's card. The button b2 is a button operated when the user selects a card to be used in a battle against another user or NPC from among the cards owned by the user. The button b3 is a button that is operated when the user requests a normal synthesis process for a card selected as a base card from among the cards in his/her possession. The button b4 is a button operated when the user requests an evolutionary synthesis process for a card selected as a base card from among the cards in his/her possession. The button b5 is a button that is operated when the user requests a sale process for a card selected from the cards in his/her possession.

When the button b4 ("evolutionary synthesis") is operated in the image P1, the image changes as shown in P2. In the image P2, a list of a plurality of possessed cards is displayed in order to select one of the user's possessed cards as a base card. The image is configured so that cards that cannot evolve (cards TOM, TED, and DSG in the illustrated example) cannot be selected as base cards. In other words, in the image P2, among the cards possessed by the user, the cards that can be evolved and the cards that cannot be evolved are shown in a display format that allows the user to identify them. The method of displaying the cards that can be evolved and the cards that cannot be evolved in a display format that allows the user to identify them is not limited to the example shown in the image P2 in FIG. 12A. The list of possessed cards may be a list of character strings of the card names of each card. In that case, cards that can be evolved and cards that cannot be evolved can be identified by the brightness, size, etc. of the character strings. may
When the card KLM, for example, is selected as one of the cards that can evolve in the image P2, the image changes as shown in P3. The image P3 includes a button b6 ("Select") for confirming the selected card as the base card for evolutionary synthesis, and a button b7 ("Return") for returning to the image P2 and selecting another card as the base card. ”).
When the button b6 is operated in the image P3, the card K selected as the base card
If the LM does not meet the reference card conditions necessary for evolution, the image is updated as shown in P4. The image P4 is an image for requesting presentation of acquisition conditions for non-possessed cards among the reference cards necessary for evolving the card KLM selected as the base card. 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 evolution synthesis of the card KLM is executed. An image (not shown) is displayed for the request.

In the image P4, a display area 101 showing a pre-evolution card (here, card KLM which is a base card) and a post-evolution card (for example, card QRS), a reference card necessary for evolution synthesis and its state (possessed, not a display area 102 indicating possessed, reserved, or unknown); and
A button b8 ("display conditions of acquisition") for requesting the presentation of the conditions of acquisition of the reference card is included. In the image P4, the reference card (here, the display area 1
02) is selected and the button b8 is operated, an image P5 showing the acquisition conditions of the reference card selected by the user is displayed as shown in FIG. 12B. is displayed.
The reference card selected by the user is also referred to as "the reference card specified by the user". Also, since a reference card is an example of an object, the "reference card designated by the user" is an example of a "designated object" that is an object designated by the user.

Image P5 in FIG. 12B includes a reference card selected by the user (here, card D
SG), a display area 103 showing the card image, card name, and rarity of the reference card, and a display area 104 showing acquisition conditions of the reference card. In the display area 104, information 104a (here, the number of acquisitions, the number of circulations, and the average transaction price) on acquisition difficulty and information 104b (here, available area) on acquisition routes are displayed.

(1-6-1-2) Processing for presenting unknown card acquisition conditions (FIGS. 13A and 13B)
FIG. 13A and FIG. 13B show a series of changes in display screens in the acquisition condition presentation process for presenting the acquisition condition of an unknown card. Images P1 to P3 in FIG. 13A are respectively shown in FIG.
It is the same as the images P1 to P3 of A.
Image P4 of FIG. 13A is similar to that of FIG. 1 in that an unknown card is shown in display area 102.
It is different from the image P4 in 2A. An unknown card is an unpossessed card that the user has never possessed (for example, the value of "acquisition count" in the possession history data table is 0). In the image P4, when a reference card whose acquisition conditions are to be displayed (here, a card whose status is indicated as "unknown" in the display area 102) is selected and the button b8 is operated, as shown in FIG. 13B , an image P5 showing the conditions for obtaining the reference card selected by the user is displayed.

An image P5 in FIG. 13B shows an image indicating that the reference card selected by the user is an unknown card for the user in the display area 103, and the display area 10
4 shows only the information 104b (here, the number of acquisitions and the number of circulations) relating to the acquisition difficulty level among the acquisition conditions of the reference card (that is, the information 104a relating to the acquisition route in the image P5 of FIG. 12B is masked). 12B) in that it differs from the image P5 in FIG. 12B.

(1-6-2) Evolutionary synthesis processing (Fig. 14)
FIG. 14 shows a series of changes in the display screen when the evolutionary synthesis process is executed based on the user's operation. An image P10 in FIG. 14 is an example of an image displayed when the user obtains a new card DSG while playing the game.
When obtaining the new card DSG satisfies the reserved evolutionary synthesis change conditions, the user is notified that the change conditions have been satisfied by obtaining the new card. should preferably be notified to More preferably, an image for executing evolutionary synthesis is displayed as shown in P11.
The image P11 includes a display area 101 showing the pre-evolution card (card KLM) and the post-evolution card (card QRS), a display area 102 showing the reference card required for evolutionary synthesis and its state (in this case, possession), and Button b2 for accepting a request as to whether or not to execute evolutionary synthesis
0 ("yes") and button b21 ("no") 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, card name, and at least part of the parameters of the evolved card are displayed.

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

The receiving unit 51 has a function of receiving various requests from the user based on information regarding user's operation input. In the game of the present embodiment, the user's request includes, for example, a card acquisition condition presentation request, an evolutionary synthesis processing request, a quest processing request, an evolutionary synthesis reservation processing request, an evolutionary synthesis execution request, a request for viewing processing of the user's possession card;
For example, there is a request for processing to sell the user's possession card.
The acquisition condition presentation processing request is a request to present the acquisition conditions of the reference card required for the evolutionary synthesis of the base card in response to the output of the image data by the output means 56 .
The evolutionary synthesis reservation processing request is for evolutionary synthesis of a base card in evolutionary synthesis and at least one of a plurality of reference cards corresponding to the base card in response to output of image data by the output means 56. of the processes other than the evolutionary synthesis (
For example, it is a request to restrict the use of the card in the process of selling the card, or the process of transferring the card to another user. The evolutionary synthesis reservation processing request includes the card ID of the reference card to be reserved.
In order to realize the function of the receiving means 51, the game server 20 includes the communication interface section 2
4, receives from the user terminal 10 a request corresponding to the button operation input by the user in the web page, which is an image. 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 request acceptance processing. The request is recorded in the RAM 13 in the acceptance process. The CPU 21 sequentially executes processes according to the received requests.

The game processing means 52 has a function of executing various game processes other than evolutionary synthesis based on requests and instructions from the user received by the receiving means 51 . The processing of the game of this embodiment may be provided as appropriate, but for example, processing of a match between users, processing of a match between a user and an NPC, processing of a quest by a user, processing of normal synthesis of cards possessed by a user, processing of cards possessed by a user, is the sale of
Although the battle process will not be described in detail, for example, the user organizes a team consisting of a plurality of possessed cards in advance so that the total cost is equal to or less than a predetermined upper limit, and the team battles against other users or NPCs. Battle results are determined by parameters such as offensive power, defensive power, and skill of each card that constitutes the team.

The functions of the game processing means 52 when executing quest processing are realized as follows. When the CPU 21 of the game server 20 receives a quest processing request containing a quest ID, the quest data associated with the quest ID (area name, consumed physical strength, acquired card data (card ID and acquisition rate) is retrieved from the quest data table. ), acquired item data (item ID and acquisition rate), boss ID, and quest UI data) are read out and developed 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 the user's 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 conditions in the match,
The CPU 21 executes a process of giving a card according to the value of "availability" associated with the quest ID. In the process of granting 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 "acquisition count" associated with the card ID in the possessed history data table. .
It should be noted that when the user satisfies the victory condition in the match, the process of giving the item is also executed in the same manner as the process of giving the card.

The functions of the game processing means 52 when executing normal synthesis processing of the user's possession cards are as follows:
It is realized as follows. When the CPU 21 of the game server 20 receives a request to execute normal synthesis including the user's selection results for the base card and the reference card, the CPU 21 reads out the card data of the base card and the reference card from the possessed card data table, and executes the RA.
Deploy to M23. Next, the CPU 21 changes the parameters of the base card (for example, card level and skill level) based on the parameters of the base card and the reference card,
The parameter of the base card after change is written in the possessed card data table, and the card data of the possessed card used as the reference card is deleted from the possessed card data table. Note that the card level and skill level of the base card do not always increase each time normal synthesis is performed. For example, each time normal synthesis is performed, the value of the training parameter associated with the card is increased, and when the value of the training parameter reaches a predetermined value, the card level is increased by one and the value of the training parameter is set to zero. may be reset to

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

The card data changing means 54 has a function of executing evolutionary synthesis to change the card data of the base card when all of the plurality of reference cards that satisfy the change condition are included in the user's possession cards.
In the example of the present embodiment, in order to implement the function of the card data changing means 54, when the CPU 21 of the game server 20 accepts the execution request for evolutionary synthesis, the pre-evolution card (that is, evolutionary synthesis) is added to the possessed card data table. base card) card data,
Newly write the card data of the evolved card. As a result, the base card of the user's possession card will evolve. As shown in the evolutionary synthesis data table, card IDs before and after evolution are different, so at least one of the card name, card image, and card parameters is changed by evolutionary synthesis.

The acquisition unit 55 acquires the base card (an example of the selected object) selected by the user.
A plurality of reference card IDs that are combination conditions (an example of change conditions) of reference cards corresponding to
It has a function to get from the evolutionary synthesis data table. In addition, when the reference card selected by the user is not a possessed card (for example, a non-possessed card or an unknown card), the acquisition unit 55 stores the card data of the reference card in the quest data table, possession history data table, It also has a function of obtaining from the card distribution data table. again,
Acquisition means 55 acquires the 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 when reserving a card for evolutionary synthesis. It has functions.
When the acquiring means 55 acquires a plurality of reference card IDs that are the combination condition of reference cards,
When the CPU 21 of the game server 20 acquires the selection result of the base card from the user terminal 10, the CPU 21 refers to the evolutionary synthesis data table and reads out a plurality of reference card IDs constituting the combination condition corresponding to the base card. .
When the acquiring means 55 acquires the card data of the reference card selected by the user,
In response to obtaining the selection result of the reference card from the user terminal 10, the CPU 21 of the game server 20 refers to the quest data table, possession history data table, and card circulation data table to obtain the card data of the reference card. read out.
When the acquiring means 55 acquires the serial number of the card, the CPU 21 of the game server 20
receives a request for reservation processing of evolutionary synthesis from the user terminal 10, possesses a possessed card that has not been reserved from among the base card to be the target of evolutionary synthesis and a plurality of reference cards corresponding to the base card. Identify by referring to the card data table, and read the serial number of the identified card.

The output unit 56 uses the card data of the plurality of reference cards included in the change condition acquired by the acquisition unit 55 to provide a first output for displaying the plurality of reference cards in an identifiable display format for the user. It has a function of outputting data (for example, image data) (hereinafter referred to as "first output function").
In the example of this embodiment, in order to realize the first output function of the output means 56, the game server 2
For example, when a base card is selected by the user, the CPU 21 at No. 0 reads a combination of a plurality of reference card IDs necessary for evolving the base card from the evolution synthesis data table, Card status (
"Reserved", "Possessed", "Not Possessed", and "Unknown").
The CPU 21 also generates first output data for displaying the status of each reference card in a display format that is identifiable to the user.
For example, in the reservation data table of FIG. 9, if the serial number or provisional serial number included in the possessed card data is recorded in columns C1 to C5 associated with the evolution ID corresponding to the base card, The status of the reference card identified by the card ID corresponding to the applicable column is identified as "reserved."
For example, for a card whose card status is other than "reserved", in the evolution synthesis data table of FIG. If it is included in the "card ID" column of the data table, the state of the reference card identified by the card ID is identified as "in possession".
For example, for a card whose status is other than "reserved" and "possessed", if the "number of acquisitions" column corresponding to the card ID is not 0 in the possession history data table of FIG. If the status of the reference card identified by
The state of the reference card identified by is identified as "unknown."
The first output data indicates the state of the specified reference card.

Further, the output means 56 outputs second output data (for example, image data) for presenting acquisition conditions of the reference card (unpossessed card or unknown card) corresponding to the reference card ID acquired by the acquisition means 55. It has an output function (hereinafter referred to as "second output function").
In the example of this embodiment, in order to realize the second output function of the output means 56, the game server 2
0, for example, when the reference card ID is acquired by the acquisition means 55, based on the acquired reference card ID, the quest data table, possession history data table,
Then, referring to the card circulation data table, the acquisition condition of the reference card corresponding to the reference card ID is specified, and second output data for presenting the acquisition condition is generated.
For example, in the quest data table of FIG. 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, "
The values in the "Number in Circulation" and "Average Transaction Price" columns are specified as the number in circulation and the average transaction price, respectively.
The second output data indicates at least one of the specified availability area, number of acquisitions, circulation number, and average transaction price.

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

In order to realize the function of the recording means 57, the CPU 21 of the game server 20 accesses the reservation data table and writes the serial number of the reservation target card upon receiving a request for reservation processing of evolutionary synthesis. More specifically, when the serial number of the card selected as the base card among the reserved 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. Furthermore, among the cards to be reserved, the same "reference card ID" as the card ID corresponding to the serial number of the reference card
D" column (one of the columns C1 to C5) is specified, and the serial number of the reference card among the reserved cards is written in the specified column.
On the other hand, if the reservation ID has already been issued, the serial number is already recorded in the column of "pre-evolution card", so the CPU 21 only writes the serial number of the reference card among the cards to be reserved. .

The restriction means 58 determines that a card recorded as a reserved card in the reservation data table is
It has a function to restrict its use for processes other than the intended evolutionary synthesis. ``Used for processing other than the intended evolutionary synthesis'' means that a card that is associated with the intended evolutionary synthesis and recorded as a reserved card is an evolutionary synthesis other than the intended evolutionary synthesis or a normal synthesis It also includes cases where it is used for
Various methods are conceivable for the limiting method by the limiting means 58 . For example, a method of prohibiting a card subject to restriction from processing other than the intended evolutionary synthesis by the user, or a method for prohibiting a card subject to restriction 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.
It should be noted that "limiting the use of reserved cards for processing" is not limited to prohibiting processing itself other than the intended evolutionary synthesis using reserved cards. Although processing other than the intended evolutionary synthesis can be executed, the procedure for executing the processing may be made difficult or complicated. "Processing other than evolutionary synthesis" for a reserved card is executed on the condition that the reserved card disappears from the user's possession cards It is particularly preferred that the treatment is restricted when it is a treatment to be performed).

For example, when the CPU 21 of the game server 20 receives a request to execute any one of the various processes of the game of the present embodiment, when the user's possession card is selected as the card to be processed, the possession card data table to determine whether or not the reservation ID is associated with the card ID of the selected card. The CPU 21 associates the card ID of the selected card with the reservation ID, and performs the processing related to the execution request with the reservation ID.
If the evolutionary synthesis process does not correspond to , the process may be prohibited, or the user may be notified that the selected card is a reserved card. Alternatively, the user may be notified that the selected card is a reserved card, and the user may be asked whether to continue the process. Since the evolution ID and the serial number of the reserved card are associated in the reservation data table, the CPU 21 of the game server 20 performs the desired evolution synthesis (that is, the evolution ID corresponding to the specific evolution ID) corresponding to the reserved card. evolutionary synthesis) can be identified. Therefore, it is possible to determine whether or not the processing that the user intends to execute using a specific possessed card is the target evolutionary synthesis processing.

Although it is not essential to provide the recording means 57 and the limiting means 58, by providing the recording means 57 and the limiting means 58, for example, some of the plurality of reference cards required for evolutionary synthesis can be evolutionarily synthesized. , and waiting for the evolutionary synthesis until the rest of the reference cards are obtained from erroneously using the possessed cards for a process other than the evolutionary synthesis.

(1-8) Game Processing Flow of the Present Embodiment Next, an example of the game processing flow of the present embodiment will be described with reference to the sequence charts of FIGS. 16A, 16B, and 17. FIG.
16A and 16B are sequence charts showing processing for presenting acquisition conditions. FIG. 17 is a sequence chart showing evolutionary synthesis processing.
12A, 12B, 13A, 13B, and 14. Steps in which images P1 to P5 and P10 to P12 shown in FIG. be.

(1-8-1) Acquisition condition presentation processing (Fig. 16A to Fig. 16B)
In the acquisition condition presentation processing 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, a non-possessed or unknown Suppose that a request is made to present the conditions for obtaining a reference card for

In FIG. 16A, a predetermined button (for example, the
2A or the button b4) of the image P1 in FIG. 13A is operated by the user, the CPU 11 of the user terminal 10 receives a request for evolutionary synthesis processing (S10), and transmits the request to the game server 20 (S12).
When the CPU 21 of the game server 20 receives the acquisition condition presentation process request from the user terminal 10, it refers to the evolution synthesis data table and the possessed card data table, and reads out the evolveable user's possessed cards (S14). That is, the CPU 21 reads the card data of the user's possession card from the possession card data table, and reads out all the pre-evolution card IDs (that is, the card IDs of the cards that can be evolved) in the evolution synthesis data table. Next, the CPU 21 identifies cards that can be evolved (that is, base card candidates) from among the cards possessed by the user, and generates image data including the card data of the base card candidates (S
16), the image data is transmitted to the user terminal 10 (S18).
It should be noted that the image data generated in S16 is displayed in different display modes, such as the image P2 in FIG. 12A or FIG. It is preferable to generate 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 image displayed in S20 includes images of a plurality of cards that are base card candidates, as exemplified by the image P2 in FIG. 12A or FIG. 13A. It is configured so that the number can be selected. When the user performs an operation to select one of the plurality of base card candidates displayed in S20 as the base card,
The CPU 11 receives the selection result (serial number) of the base card (S22), and transmits the selection result to the game server 20 (S24).

Upon receiving the selection result (serial number) transmitted in S24, the CPU 21 of the game server 20 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 columns C1 to C5) corresponding to the pre-evolution card ID are read out (S26). then the CPU
21 refers to the possessed card data table and the reservation data table to specify the state of the card (not possessed, possessed, reserved, or unknown) corresponding to each reference card ID read in S26; Image data is generated based on the identification result (S28).

At S28, the CPU 21 of the game server 20 identifies the status of the card corresponding to each reference card ID as follows.
The CPU 21 reads the serial number recorded in the "serial number of reserved card" column of the reservation data table, refers to the possessed card data table, and identifies the card ID associated with the serial number. If the reference card ID read in S26 matches the specified card ID, or if the serial number is a provisional serial number, the status of the card specified by the card ID is set to "reserved". Identify.
Regarding a reference card other than the card specified as "reserved", if the reference card ID of the reference card is included in the card IDs recorded in the possessed card data table, the CPU 21 reserves the reference card. The state of the card specified by the ID is "possessed"
Identify as
For cards other than "reserved" and "possessed", if the value associated with the reference card ID in the "acquisition count" column of the possession history data table is not 0, the CPU 21 selects the card specified by the reference card ID. is specified as "not possessed", and the value associated with the reference card ID in the "acquisition count" column of the possession history data table is 0, the status of the card specified by the reference card ID is specified as " identified as “unknown”.

In S28, the CPU 21 of the game server 20 receives an instruction from the user as to whether or not to execute the evolutionary synthesis of the card KLM when the states of all the reference cards read out in S26 are "possessed" or "reserved". Generate image data for When the state of at least one of the reference cards read out in S26 is "unpossessed" or "unknown", the CPU 21 presents the acquisition conditions for the reference card in the state of "not possessed" or "unknown". image data. Here, it is assumed that image data based on which the image P4 in FIG. 12A or FIG. 13A is based is generated.

Next, the CPU 21 of the game server 20 transmits the image data generated in S28 to the user terminal 1.
0 (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).

The image displayed in S32 is the image displayed in S2 as shown in the image P4 in FIG. 12A or 13A.
A plurality of reference cards required for evolutionary synthesis of the base card selected in 2 are displayed so that the user can identify them. The image P4 in FIG. 12A or FIG. 13A displays the state of each reference card in association with the reference card, and is configured to be able to accept a request for presentation processing of acquisition conditions for an unpossessed card or an unknown card. . Here, after the image P4 of FIG. 12A or FIG. 13A is displayed, the user performs an operation (for example, operation of the button b8 of the image P4 of FIG. 12A or FIG. 13A) for requesting the process of presenting the acquisition conditions. Then, the CPU 11 of the user terminal 10 accepts the request for the presentation process of the acquisition condition based on the user's instruction corresponding to the operation (S34), and transmits the request to the game server 20 (
S36). The request sent from the user terminal 10 to the game server 20 in S36 includes the card ID of the unpossessed card or unknown card selected by the user (that is, the card whose acquisition conditions should be presented in the acquisition condition presentation process). be
As described above, the reference card selected by the user is an example of a designated object, which is an object designated by the user. In other words, the processing of S34 and S36 is an example of processing for receiving an instruction to designate any one of a plurality of objects based on a user's instruction.

When the CPU 21 of the game server 20 accepts the acquisition condition presentation processing request transmitted in S36, the card data of the reference card selected by the user is retrieved from the card data table, the quest data table, and the card circulation data table. acquire (S3
8). 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 obtained from the quest data table. The acquisition count is obtained from the possession history table. The number of circulation and the average transaction price are
Obtained from the card distribution data table.

If the status of the card identified in S28 is "unknown" (S40: YES), S4
Proceeding to 2, if the status of the card specified in S28 is not "unknown" (S40: NO)
, to S44.
Here, as an example of a card whose status is not "unknown" (that is, an unknown card),
An example of a case where the card status is "unpossessed" (that is, a non-possessed card) will be described. note that,
Both "unknown" and "unpossessed" are common in that they indicate a state in which the user does not possess a card (that is, the card ID is not included in the possessed card data table).

At S42, the CPU 21 of the game server 20 selects information on the acquisition difficulty (here, the number of acquisitions,
Mask processing is applied to the image so that information (here, card name, card image, rarity, and available area) other than the number of circulation and average transaction price) is not displayed.
In the present embodiment, the purpose of not displaying information other than information about the difficulty of obtaining unknown cards is to give the user a sense of anticipation for the game (in particular, to obtain unknown cards) and The aim is to improve interest.

At S44, the CPU 21, based on the card data of the reference card acquired at S38,
Image data ( FIG. 12B or FIG. 1
3B image data that is the basis of the image P5), and transmits the image data 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).
If it is determined in S40 that it is not "unknown" (for example, "unowned"), the card image, card name, rarity, acquisition count, circulation count, average transaction price, And the available area is displayed.
On the other hand, if it is determined to be "unknown" in S40, as shown in image P5 in FIG. 13B,
The number of acquisitions, the number of circulations, and the average transaction price are displayed, but the card image, card name, rarity, and available area are not displayed.
In other words, the information displayed as acquisition conditions for unknown cards is more limited than the information displayed as acquisition conditions for unpossessed cards. In other words, in S48, when the specified object is an unknown object that the user has never possessed, the information displayed as the acquisition condition is restricted compared to when the specified object is an unpossessed object. is an example.

As described above, in this embodiment, when the user does not possess the reference card selected by the user (when the reference card is an unknown card or an unpossessed card), the acquisition condition of the reference card is displayed. explained. This is an example of processing for displaying the conditions for obtaining the specified object when the user does not possess the specified object.

(1-8-2) Evolutionary synthesis processing (Fig. 17)
For example, when the card newly obtained by the user satisfies the change condition of the reference card in the evolutionary synthesis, the evolutionary synthesis process can be executed.
17, on the image displayed on the user terminal 10, a predetermined button (for example,
When the user operates the button b20) of the image P11 of the user terminal 10, CP
U11 accepts a request to execute evolutionary synthesis (S150), and transmits the request to the game server 20 (S152).

Upon receiving the request transmitted in S152, the CPU 21 of the game server 20 erases the card data of the pre-evolution card (that is, the evolution synthesis base card) in the possessed card data table (S154), and erases the card data of the post-evolution card. Write new data (S15
6).
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 ( 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, 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 cards, which is an example of processing for changing an object, a base card to be subjected to evolutionary synthesis and a plurality of reference cards corresponding to it are required. It is a requirement that the user possesses all of the cards. Therefore, for example, if the player does not possess some of the reference cards, evolutionary synthesis of the base card cannot be executed. At this time, it may be impossible or difficult for the user to obtain a reference card that the user does not possess.
However, a user who does not know the conditions for obtaining the reference card may decide whether or not to execute the process (for example, quest process) to obtain the reference card because it is impossible or difficult to obtain the reference card. cannot be recognized at the time of determining In such a case, the user will carry out the processing for obtaining the reference card, while being worried that it may be impossible or difficult to obtain the reference object.
The game server 20 of this embodiment presents conditions for obtaining a reference card that the user does not possess in response to a request from the user. Therefore, even if there is a reference card that is impossible or difficult for the user to obtain among the plurality of reference cards corresponding to the base card to be the target of evolutionary synthesis, the user cannot obtain the reference card. Recognizing the difficulty, a decision can be made as to whether or not to proceed with 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.

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

In addition, as the acquisition conditions for unknown cards, the acquisition difficulty is displayed, but the acquisition route is not presented (that is, the information displayed as the acquisition conditions for unknown cards is the information displayed as the acquisition conditions for unowned cards). is limited compared to ). In this case, it is possible to give a sense of security to the user who executes the process (for example, the quest process) for obtaining the unknown card while keeping the difficulty of the game at an appropriate level.

(1-9) Modifications of this Embodiment Hereinafter, modifications of this embodiment will be described. It should be noted that the following modified examples can be combined as appropriate.

(1-9-1) First Modification Image P4 in FIG. 12A or FIG. 13A shows a display format in which only the card image of the reference card is displayed. It is not limited.
For example, instead of a display format in which only card images are displayed, a display format in which only card names are displayed, or a display format in which a combination of card images and card names is displayed may be used.
In other words, the display format of the present embodiment may be any format as long as the reference cards are displayed so that they can be identified by the user.

(1-9-2) Second Modification In the above-described embodiment, in S42 of FIG. 16B, the image Although an example in which mask processing is applied to , the processing for preventing the information from being displayed is not limited to this.
For example, instead of applying the masking process, information other than the information regarding the difficulty 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, in S42 of FIG. Embodiments are not limited to this.
For example, the card image and available area may not be displayed, but the card name and rarity may be displayed.
Also, information to be hidden from display may be arbitrarily set by the user.

(1-9-4) Fourth Modification In the above-described embodiment, in S42 of FIG. 16B, among the information on the card indicated by the card data acquired in S38, information other than the information on the acquisition difficulty is not displayed. Although the example in which it is made so is explained, S42 can be omitted.
If S42 is omitted, all of the card data obtained in S38 (that is, the information about the reference card whose acquisition conditions are presented) is displayed, so that the user may be able to obtain the reference card. It can give you a sense of hope.

(1-9-5) Fifth Modified Example An unpossessed card, which is a reference card that the user has possessed in the past and is not currently possessed by the user, is selected as a card for which acquisition conditions should be presented. In this case, it is desirable to display at least one of information regarding the area where the card can be obtained and the degree of difficulty of obtaining the card as an acquisition condition.
If the specified object is an unpossessed object that the user has possessed in the past and is not currently possessed by the user, the obtaining conditions are as follows:
This is an example of processing for displaying at least one of the obtaining route and obtaining difficulty of the designated object.
According to this modification, the user can easily know the degree of difficulty in obtaining the card.

(1-9-6) Sixth Modification In the above-described embodiment, an example of displaying the acquisition condition of the non-possessed card was shown, but the acquisition condition of a card other than the non-possessed card may be displayed.
As an example, the acquisition conditions for possessed cards may be displayed. For example, when the user has many cards, the user may forget the conditions for obtaining a certain card. In this case, by displaying the conditions for obtaining the possessed card, the user can re-recognize the degree of difficulty in obtaining the possessed card. If the user recognizes that the possessed card is difficult to obtain, the use of the possessed card (for example, which base card to use as a reference card for the evolutionary synthesis process).
It can give an opportunity to think carefully about On the other hand, when the user recognizes that the possession card is difficult to obtain, it is possible to provide an opportunity for the user to casually use the possession card.

(1-9-7) Seventh Modification In the above-described embodiment, an example was described in which the change condition is satisfied when all reference cards corresponding to the base card are in possession. In addition to being in possession, the change condition may be met if a predetermined additional condition is met.
For example, an additional condition may be met if the card level of all reference cards reaches the maximum level, or if the user possesses a predetermined amount of in-game points. .

(2) Second Embodiment In the first embodiment, the case of displaying an image showing the conditions for obtaining a non-possessed card has been described. An example of displaying an image including an operation target for guiding the user to an acquisition route of the software will be described. In addition, description similar to that of the first embodiment will be omitted as appropriate.

(2-1) Concrete Example of Acquisition Condition Presentation Processing and Quest Processing A specific example of the card acquisition condition presentation processing of the game according to the present embodiment will be described below with reference to FIG. FIG. 18 is a diagram showing an example of a screen displayed on the user terminal 10 when the game processing of this embodiment is being executed.

(2-1-1) Acquisition condition presentation process (Fig. 18)
In the image P4 of FIG. 12A of the first embodiment, a reference card whose acquisition conditions are to be displayed (here, the card DSG showing the state of "unpossessed" in the display area 102) is selected, and the button b8 is selected. When is operated, as shown in FIG. 18, an image P5 showing acquisition conditions of the reference card selected by the user is displayed.

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

(2-1-2) Quest processing (Fig. 18)
When the button b9 (“go to available area”) is operated in the image P5, the image changes as shown in P6. The image P6 shows a quest execution screen. 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 fulfilled, the user can obtain the non-possessed card based on the probability corresponding to the value of "availability" in the quest data table.

(2-2) Game Processing Flow of the Present Embodiment Next, an example of the game processing flow of the present embodiment will be described with reference to the sequence chart of FIG.
FIG. 19 is a sequence chart showing quest processing. In FIG. 19, the steps at which the images P5 and P6 shown in FIG. 18 are displayed are denoted by the reference numerals of the respective images.

(2-2-1) Acquisition condition presentation processing In this embodiment, in S44 (FIG. 16A), the CPU 21 of the game server 20 adds the card data of the reference card acquired in S38 to the acquisition path of the reference card. Image data (FIG. 18
2) is different from the first embodiment in that the image data that is the basis of the image P5 of (1) is generated.

(2-2-2) Quest processing (Fig. 19)
19, on the image displayed on the user terminal 10, a predetermined button (for example,
When the button b9) of the image P5 of is operated, the CPU 11 of the user terminal 10 receives a request for quest processing (S70), and transmits the request to the game server 20 (S72).

When the CPU 21 of the game server 20 accepts the request transmitted in S72, the quest data (
Based on the area name, consumed physical strength, acquired card data (card ID and availability), acquired item data (item ID and availability), boss ID, and quest UI data), image data of quest processing (Fig. 18 (S7
4), the image data is transmitted 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, image P6 in FIG. 18) on the display unit 16 (S78
).

After that, the CPU 11 of the user terminal 10 sends an instruction to the game server 2 according to the user's operation.
Send to 0. 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 conditions in the match, the CPU 21 executes a process of giving a card according to the value of "availability" associated with the quest ID. In the process of giving a card, the CPU 21
The card ID associated with D is written in the possessed card data table, and the value of "acquisition count" associated with the card ID is increased in the possession history data table. As a result, the user can obtain the card selected in the image P4 of FIG. 12A of the first embodiment (the reference card whose acquisition conditions are to be displayed).

As described above, the game server 20 of the present embodiment presents conditions for obtaining a reference card that the user does not possess, as well as an operation target for guiding the user to the route to obtain the reference card. can request the execution of a process for obtaining an object simply by operating the operation target, so that the operability when requesting the execution of the process can be improved.

(3) Third Embodiment In the second embodiment, the case of displaying an image including an operation target for guiding the user to a route to obtain a card not possessed has been described. In addition to the operation target for guiding the user to the acquisition route of the possessed card, the user is guided to the acquisition route of the non-possessed card, and after the user acquires the non-possessed card, evolutionary synthesis reservation processing is executed. An example of displaying an image including an operation target for performing the operation will be described. Note that the same description as in the above-described embodiment will be omitted as appropriate.

(3-1) Specific examples of acquisition condition presentation processing, quest processing, and evolutionary synthesis reservation processing Hereinafter, the card acquisition condition presentation processing, quest processing, and evolutionary synthesis reservation processing of the game of the present embodiment will be described. A specific example of is described with reference to FIG. FIG. 20 is a diagram showing an example of a screen displayed on the user terminal 10 when the game processing of this embodiment is being executed.

(3-1-1) Acquisition condition presentation processing (Fig. 20)
In the image P4 of FIG. 12A of the first embodiment, a reference card whose acquisition conditions are to be displayed (here, the card DSG showing the state of "unpossessed" in the display area 102) is selected, and the button b8 is selected. is operated, as shown in FIG. 20, an image P5 showing the acquisition conditions of the reference card selected by the user is displayed.
The image P5 in FIG. 20 includes, in addition to the display areas 103 and 104, a button b10 (“do not reserve/go to available area”) and a button b11 (“reserve/go to available area”). It differs from the first embodiment (image P5 in FIG. 12B) in that respect. button b
A button 10 is operated when the user requests a quest process for obtaining an unpossessed card. The button b11 is a button operated when requesting both the quest process and the evolutionary synthesis reservation process.

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

(3-1-3) Reservation process for evolutionary synthesis (Fig. 20)
When the button b11 (“reserve/go to available area”) is operated in the image P5, together with the quest process, the reservation process is executed for the reference card possessed by the user, indicating that the reservation process has been completed. Image P7 is displayed.

(3-2) Game processing flow of the present embodiment (Fig. 21)
Next, an example of the game processing flow of the present embodiment will be described with reference to the sequence chart of FIG. It should be noted that 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 steps at which the images P5 to P7 shown in FIG. 20 are displayed are denoted by the reference numerals of the respective images.

In the reservation processing described below, as an example, it is assumed that the user reserves a reference card that the user does not possess for evolutionary synthesis of the base card among a plurality of reference cards for evolutionary synthesis of the base card.

21, on the image displayed on the user terminal 10, a predetermined button (for example,
By the user operating the button b11) of the image P5, the CPU of the user terminal 10
11 accepts a request for evolutionary synthesis reservation processing (S50), and sends the request to the game server 20
(S52). The request includes a card ID that identifies the reference card not possessed displayed in the display area 103 of FIG.
Note that S52 is an example of processing for receiving a request for restricting the designated object from being used for processing other than the processing for changing the selected object, based on the user's operation.

When the CPU 21 of the game server 20 receives the evolutionary synthesis reservation process request, it accesses the reservation data table to determine whether the reservation ID corresponding to the serial number of the base card obtained in S24 (FIG. 16A) has been issued ( That is, it is determined whether or not the same serial number is recorded in the column of "pre-evolution card" (S54).
If the reservation ID has been issued (S54: YES), proceed to S58. If the reservation ID has not been issued (S54: NO), after issuing the reservation ID (S56), proceed to S58. In S58, the CPU 21 writes the provisional serial number in the reservation data table in association with the reservation ID. At this time, when a new reservation ID is issued, the CPU 21 writes the serial number of the base card among the cards to be reserved in the "pre-evolved card" column, and also writes C1 to C5 corresponding to the reservation ID. Data indicating that the card is not a reserved card (for example, N
ULL).

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

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

After that, when the user obtains the reservation target card (that is, when the card ID and serial number of the reservation target card are associated with the user's possession card data and recorded), CP
U21 overwrites the temporary serial number written in the reservation data table in S58 with the serial number included in the possessed card data.

Note that in FIG. 21, a predetermined button (for example,
When the button b10) of the image P5 of FIG. 20 is operated, the Qwest process (FIG. 19) similar to that of the second embodiment is performed.

As described above, the game server 20 of the present embodiment guides the user to the acquisition route of the reference card and reserves the reference card, along with the conditions for obtaining the reference card that the user does not possess. By presenting an operation target for requesting, it is possible to restrict the reserved card from being used for processing other than the intended evolutionary synthesis. Therefore, during the waiting period until the user obtains the rest of the reference cards that the user does not possess, it is possible to prevent the card possessed by the user from being mistakenly used for processing other than the intended evolutionary synthesis. .

(4) Fourth Embodiment In the above-described embodiment, an image showing the conditions for obtaining the reference card is displayed when the user operates the button for requesting the presentation of the conditions for obtaining the reference card. 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 the evolutionary synthesis of the base card is displayed. An example of displaying will be described. Note that the same description as in the above-described embodiment will be omitted as appropriate.

(4-1) Specific Example of Acquisition Condition Presentation Processing A specific example of the game card acquisition condition presentation processing according to the present embodiment will be described below with reference to FIG. FIG. 22 is a diagram showing an example of a screen displayed on the user terminal 10 when the game processing of this embodiment is being executed.

・Presentation processing of acquisition conditions (Fig. 22)
FIG. 22 shows a series of changes in display screens in the acquisition condition presentation process for presenting the acquisition condition of the card not possessed. Images P1 to P3 in FIG. 22 are the same as those in FIG. 12 of the first embodiment, respectively.
It is the same as the images P1 to P3 of A.

When the button b6 is operated in the image P3, the card K selected as the base card
If the LM does not meet the reference card conditions 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 evolving the card KLM selected as the base card. 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 required for evolution, evolution synthesis of the card KLM is executed. An image (not shown) is displayed for the user to indicate whether or not.

The image P4 in FIG. 22 shows, in the display area 102, in addition to the reference cards necessary for evolutionary synthesis and their states (possessed, not possessed, reserved, or unknown), acquisition conditions for the not possessed card or the unknown card are set. The points shown are the first to third embodiments (FIGS. 12A, 13A and
It differs from the image P4) in FIG. 21A. In the display area 102, as an example, information (here, area name "Area 1") indicating the acquisition route of the non-possessed card is displayed.

(4-2) Game processing flow of the present embodiment (Fig. 23)
Next, an example of the processing flow of the game according to this embodiment will be described with reference to the sequence chart of FIG. FIG. 23 is a sequence chart showing processing for presenting acquisition conditions.
In FIG. 23, the steps at which the images P1 to P4 shown in FIG. 22 are displayed are denoted by the reference numerals of the respective images. In addition, in FIG. 23, the same reference numerals are assigned to the same processes as in FIGS. 16A and 16B.

In the acquisition condition presentation processing 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 unpossessed reference Assume that a request is made to present conditions for obtaining a card.

After S26 (FIG. 16A) of the first embodiment is executed, the CPU 21 of the game server 20
, based on the plurality of reference card IDs read in S26, the card data of the reference card (card name, card image, rarity, quest ID, available The area name of the area, the number of acquisitions, the number of circulations, and the average transaction price) are acquired (S38). 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 acquisition count is obtained from the possession history table. The number of cards in circulation and the average transaction price are obtained from the card circulation data table.

Next, the CPU 21 of the game server 20 executes S40 to S42 in the same manner as S40 to S42 of the first embodiment (FIG. 16B), and then, based on the card data of the reference card acquired in S38, Image data (image data based on image P4 in FIG. 22) for presenting the acquisition conditions of the reference card 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, image P4 in FIG. 22) on the display unit 16 based on the image data (S4
8).

As described above, the game server 20 of the present embodiment selects a base card to be the target of evolutionary synthesis as a condition for obtaining a reference card that is not possessed by the user and is necessary for the target evolutionary synthesis. By presenting it according to the user's operation, it is possible to improve the operability of the operation of presenting the acquisition condition of the reference card necessary for the evolutionary synthesis of the base card.

(5) Fifth Embodiment In the above-described embodiments, an example of displaying a screen presenting conditions for obtaining an unpossessed card has been described. Also, an example of processing for preventing the card specified by the user from disappearing due to being used for some processing on the screen will be described.

(5-1) Reservation registration and favorite registration of game cards of the present embodiment (Fig. 24)
In the game of this embodiment, consider a case where the user wants to evolve a desired base card by evolutionary synthesis, but the user does not possess some or all of the reference cards required to evolve the base card. In this case, it is necessary to wait to perform evolutionary synthesis of the base card until a new card (ie, the remaining reference cards) is available to the user to satisfy the condition of the reference card combination. However, before the user obtains the rest of the reference cards, the reference card in his possession is used for a purpose other than the evolution of the base card, and the reference card is lost. If it is difficult to fulfill, it will be difficult to evolve the base card. For example, in a case where the user has erroneously lost (for example, sold) the reference card before executing the evolutionary synthesis, the probability of obtaining the reference card is low, or obtaining the reference card If the time period is limited, it becomes difficult for the user to evolve the desired base card.
Therefore, in the present embodiment, it is possible to reliably prevent the reference cards necessary for evolving a desired base card from disappearing against the user's intention.

Reservation registration and favorite registration of a reference card will be specifically described with reference to FIG. FIG. 24 is a diagram for conceptually explaining reservation registration and favorite registration of a reference card.
In FIG. 24, consider a case where the user wants to evolve card Q, which is a card owned by the user. Here, in order to evolve card Q, cards A, B, and C are used as a plurality of reference cards.
Assume that a combination of Since the user does not have card B at the moment, evolutionary synthesis for card Q cannot be performed. If it is difficult to meet the conditions for obtaining Card A, and the user uses Card A for a purpose other than the evolution of Card Q and makes it disappear from the possession cards, then Card Q cannot be evolved. it gets harder. Therefore, in this embodiment, in order to prevent the user from unintentionally losing Card A from his or her possession cards, after presenting the acquisition conditions of Card A, for Card A,
Accept reservation registration or favorite registration.
Reservation registration is a state in which card A is restricted from being used for processes other than the evolutionary synthesis of card Q, which is selected as a base card, among the processes that are executed on the condition that card A is deleted from the possession cards. be.
Favorite registration is a state in which card A is restricted from being used for processing (including evolutionary synthesis of card Q selected as a base card) that is executed on the condition that card A is eliminated from possession cards.
Note that reservation registration and favorite registration are examples of processing for restricting use of a designated object, which is an object designated by a user, in predetermined processing. The "predetermined process" is a process that is executed under the condition that the specified object disappears from the possessed object. In other words, the object specified from among the possessed objects, which are the objects possessed by the user, becomes the object to be restricted by reservation registration and favorite registration.

In this way, by presenting the acquisition conditions of card A and accepting reservation registration or favorite registration for card A, the user immediately recognizes that card A is a card that is difficult to obtain from the presented acquisition conditions. In addition, it becomes possible to make a request to limit the use of card A in the process of deleting it from the possessed cards. Therefore, it is possible to reliably prevent the card A from disappearing against its intention.

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

The possessed card data table records the information of the user's possessed cards. FIG. 25 shows a configuration example of the possessed card data table. Although FIG. 25 illustrates the possessed card data table for one user, the possessed card data table is provided for all users registered in the game.
The possessed card data table of FIG. 25 differs from the possessed card data table of FIG. 8 in that registration type data is recorded in association with each card ID.
The registration information consists of the type of registration (reservation registration or favorite registration) performed on the possessed card data and the type of screen on which the request for registration was made (the screen for presenting the acquisition conditions (hereinafter referred to as the "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 reserved and registered via the acquisition condition presentation screen, and "1" is recorded for a card registered as a favorite via the acquisition condition presentation screen. "2" is recorded in the registration information, and "4" is recorded in the registration information for cards that have been registered as favorites via the card list screen, and cards that have not been reserved or registered as favorites is recorded with "N/A".

(5-3) Specific example of game display processing of the present embodiment (5-3-1) Specific example of display processing of acquisition condition presentation screen for game of the present embodiment (Fig. 26)
In the image P4 of FIG. 12A of the first embodiment, when the reference card whose acquisition conditions are to be displayed is selected and the button b8 is operated, the reference card selected by the user is displayed as shown in FIG. An image P5 corresponding to the acquisition condition presentation screen is displayed.

An image P5 in FIG. 26 differs from the first embodiment (image P5 in 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.
The button b13 (“favorite registration”) is a button operated when the user requests the favorite registration of the 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) A specific example of display processing of the game change condition list screen of the present embodiment (FIG. 27A
~ Figure 27C)
In the image P1 of FIG. 12A of the first embodiment, when the button b4 (“evolutionary synthesis”) is operated, as shown in FIG. 27A, an image P23a corresponding to the change condition list screen of the present embodiment
is displayed. The image P23a is also called a change condition list screen.

Image P23a includes display area 105, button b12 (“reservation registration”), and button b13 (“favorite registration”). A button b12 (“reservation registration”) and a button b13 (“favorite registration”) are the same as those in the image P5 in FIG.
In the display area 105, the card images and card names of the base card and reference card are displayed for each combination of base card and reference card. In other words, the display area 105 displays a reference card for each base card. In the example of FIG. 27A, the reference cards required for evolutionary synthesis of card KLM are cards VIC, DSG, and MIT, and the reference cards required for evolutionary synthesis of card SAM are cards MIT, KAY, and TED.
In the display area 105, with respect to the reference cards, possessed cards and non-possessed cards are displayed so as to be identifiable. In the example of FIG. 27A, the cards VIC, DSG, MIT, and KAY are displayed with solid lines indicating that they are possessed cards, and the card TED is displayed with broken lines indicating that they are not possessed cards.
In addition, in the display area 105, a mark m1 is displayed on the card image of the card for which reservation registration is performed via the acquisition condition presentation screen. The mark m1 is a mark displayed on the card image of a card that is restricted from being used for processes other than evolutionary synthesis of the base card among the processes that are executed on the condition that the card is erased from the possessed card (" It is also called "symbol", "mark", etc.). 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. In other words, FIG. 27A shows that the card DSG is in a state of being restricted from being used for processes other than the evolutionary synthesis of the card KLM, among the processes that are executed on the condition that the card DSG disappears from the possessed cards. ing.
In addition, in the display area 105, a mark m2 is displayed on the card image of the card that has been registered as a favorite via the acquisition condition presentation screen. The mark m2 is a mark displayed on the card image of a card whose use in processing (including evolutionary synthesis of the base card) is restricted on the condition that the card is deleted from the possessed card. In the example of FIG. 27A, a mark m2 is displayed on the card image of card KAY. In other words, FIG. 27A can be used for all the processes executed on the condition that the card KAY disappears from the possessed cards (for example, the process of evolutionary synthesis of the card SAM and the process of selling the card KAY). is in a restricted state.
By selecting a card image, the user can select the card corresponding to 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 evolutionary synthesis of the card KLM is selected, and when the card image b15 is selected, evolutionary synthesis of the card SAM is performed. The card MIT as the required reference card becomes selected.
By operating the button b12 ("reservation registration") or the button b13 ("favorite registration") after selecting the card, the user can request reservation registration or favorite registration for the selected card. In the example of FIG. 27A, when the card image b14 is selected and the button b12 ("reservation registration") or the button b13 ("favorite registration") is operated, the card MIT as a reference card required for evolutionary synthesis of the card KLM Subscription or favorite registration is requested.

When the user selects the card image b14 in the image P23a and then operates the button b12 ("reservation registration"), the image P23a changes to the image P23b. 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 evolutionary synthesis of the card KLM. The mark m3 is a mark that indicates a reference card that has been reserved and registered 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 evolutionary synthesis of the card SAM. The mark m4 is a mark indicating that reservation registration has been made as a reference card necessary for evolutionary synthesis of another base card (card KLM).
In the example of FIG. 27B, the card MIT as a reference card required for the evolutionary synthesis of the card KLM
A mark m3 is displayed on the card image of , and a mark m4 is displayed on the card image of the card MIT as a reference card necessary for evolutionary synthesis of the card SAM. In this case, the card MIT is restricted from being used for processes other than evolutionary synthesis of the card KLM among the processes executed on the condition that the card MIT is eliminated from the possessed cards. In other words, the card MIT can be used for processing the evolutionary synthesis of the card KLM, but the card SA
It can no longer be used for M's evolution synthesis process or sale process.

When the user selects the card image b14 in the image P23a and then operates the button b13 (“Register Favorites”), the image P23a changes to the image P23c. The image P23c is the mark m5
is displayed on the card image of the card MIT, which is different from the image P23a. A mark m5 is a mark indicating a reference card that has been registered as a favorite via the change condition list screen.
In the example of FIG. 27B, the card MIT as a reference card required for the evolutionary synthesis of the card KLM
and card MI as a reference card required for evolutionary synthesis of card SAM
A mark m5 is displayed on T's card image. In this case, for the card MIT,
It is restricted from being used for all the processing executed on the condition that the card MIT is erased from the possessed cards. In other words, the card MIT is processed for the evolutionary synthesis of the card KLM, the card SA
It can no longer be used for either the evolutionary synthesis process of M or the sale process.

In the images P23a-P23c, the marks m1-m5 are displayed in mutually identifiable shapes, patterns, or combinations thereof. As a result, the user can view 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, the change condition It becomes possible to easily identify the reference card that is the target of reservation registration performed via the list screen and the reference card that is the target of favorite registration performed via the change condition list screen.
Specifically, for marks m1 to m5, the type of registration (reservation registration or favorite registration) is identified by the shape of the mark, and the screen on which the registration is requested (acquisition condition presentation screen or change condition list screen) is identified by the pattern of the marks.

(5-4) Processing flow of registration processing in 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 steps at which the images P5, P21, and P22 shown in FIG. 26 are displayed are denoted by the reference numerals of the respective images. In addition, in FIG. 28, the same reference numerals are assigned to the same processing as in FIG. 16B.

In the registration processing described below, reservation registration processing or favorite registration processing is performed as an example of processing for restricting use of a designated object, which is an object designated by a user, from being used in a predetermined processing. Assuming you request it.

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

When receiving the request from the user terminal 10, the CPU 21 of the game server 20 executes the registration (reservation registration or favorite registration) processing according to the request (S172).
It should be noted that the process of S172 is an example of a process of restricting the designated object from being used in a predetermined process.

If the request accepted in S170 is a request for reservation registration processing, the CPU 21 executes the possessed card data specified by the serial number of the reference card included in the request via the acquisition condition presentation screen. registration information (registration information "1" in FIG. 25) indicating that the card is the object of reserved registration. In addition, the CPU 21 records the serial number of the reference card in the column corresponding to the card ID of the reference card among C1 to C5 for the reservation data specified by the serial number of the base card included in the request. 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 a base card other than the base card), and delete it from the possessed card data (that is, make the reference card disappear from the possessed card (for example, execute a sale process))
is restricted.
On the other hand, if the request accepted in S170 is a request for favorite registration processing, CP
U21 provides registration information ( The registration information "2" in FIG. 25) is recorded. As a result, the serial number of the reference card to be registered as a favorite can be recorded in the reservation data table and deleted from the possessed card data (that is,
erasing the reference card from the possessed card) is restricted.

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). As a result, the user terminal 1
0, the image P21 or P22 of FIG. 26 is displayed.
Note that S174 is a process of outputting data for displaying an object subject to restriction due to reservation registration and an object subject to restriction due to favorite registration in a display format that allows the user to distinguish between them. is an example.

By using the registration information in FIG. 25, marks m1 to m are obtained as shown in FIGS.
5 can be used to display to the user the type of registration and the type of screen that was being displayed when the registration request was made. For example, when the user operates the button b4 (“evolutionary synthesis”) of the image P1 in FIG. 12A, the display unit 16 displays the image P23b in FIG. When favorite registration processing is executed in S172, image P23c in FIG. 27C is displayed.

As described above, the game server 20 of the present embodiment, on the acquisition condition presentation screen,
A request for pre-registration processing to limit the use of the reference card in possession for processing other than evolutionary synthesis of the base card, or a processing executed on the condition that it disappears from the possessed card ( (including base card evolution synthesis processing).
As a result, the user can prevent the reference card from disappearing unintentionally immediately after recognizing that it is difficult to obtain the reference card that the user has on the acquisition condition presentation screen. .
In particular, as the number of cards to be used as base cards and reference cards used for evolutionary synthesis of the base cards increases, it becomes more difficult for users to manage which reference cards should be used for evolutionary synthesis of which base cards. Become. As a result, there is a risk that the user will lose the reference card against his or her intention due to an operation error or forgetting the purpose of the reference card.
On the other hand, in this 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 under the condition that the reference card is erased. A request can be made to limit the use of a given process. Therefore, it is possible to reliably prevent the reference card from disappearing against the user's intention.

Also, in this embodiment, the user can request two types of registration (reservation registration and favorite registration). Therefore, the user can use different registrations (that is, select the range of restrictions to be applied to the reference card) depending on the purpose. For example, a user who wants to use a reference card for evolutionary synthesis of a specific base card can prevent loss of the reference card due to processing other than evolutionary synthesis of the specific base card by requesting reservation registration. can be done. Also, without deciding the base card to evolve using the reference card,
A user who wants to prevent the reference card from disappearing can reliably prevent the reference card from disappearing by requesting registration of the reference card as a favorite. Therefore, the user can flexibly manage the usage of the reference card.

In addition, the game server 20 of the present embodiment has a reference card to be reserved and registered via the change condition list screen, and a The reference card that has been registered as a favorite is displayed in an identifiable manner.
Furthermore, the game server 20 of the present embodiment identifiably displays the combination of the base card and the reference card for which reservation registration has been made.
Furthermore, the game server 20 of the present embodiment displays the reference cards targeted for reservation registration and the reference cards targeted for favorites registration so as to be identifiable.
As a result, the user can visually grasp the purpose of the possessed card (specifically, to use it for evolutionary synthesis of a specific base card, or to keep it although the purpose is undecided). Become.

(5-5) Modifications of this Embodiment Hereinafter, modifications of this embodiment will be described. It should be noted that the following modified examples can be combined as appropriate.
(5-5-1) First Modified Example In this embodiment, a case where a reference card to be registered (reservation registration or favorite registration) is a possessed card has been described. However, in this embodiment, the reference card to be registered may be a non-possessed card.
For example, the change condition list screen is configured to be able 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 for which the request is made (that is, the card ID and serial number of the card are recorded in the possessed card data table) , the reservation registration process or the favorite registration process is executed for the card.

(5-5-2) Second Modified Example In this embodiment, an example of displaying the marks m1 to m5 on the change condition list screen has been described. may

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

As another example, marks m1 to m5 may be displayed on a screen showing a list of possessed cards (hereinafter referred to as "possessed card list screen").
Specifically, when the button b1 (“View Possessed Monsters”) is operated in the image P1, the possessed card list screen is displayed. On the possessed card list screen, information (for example, card image and card name) related to the possessed card is displayed in a list like the change condition list screens of FIGS. 27A to 27C. Any of the marks m1 to m5 is displayed on the card image of the card that is subject to reservation registration or favorite registration among the owned cards.

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

For example, when the user selects a card image displaying any of the marks m1 to m5 in FIGS. 27A to 27C, the card corresponding to the selected card image (that is,
A request for cancellation of reservation registration or favorite registration for a card that has been reserved or registered as a favorite is accepted. Specifically, in FIG. 27A, when the card image displaying the mark m1 is selected, the card DSG that has been reserved and registered is in the selected state, and it is specified when requesting cancellation of registration. button is displayed. At this time,
When the button is operated by the user, the reservation registration made to the card DSG is cancelled, and the mark m1 displayed on the card image disappears. As a result, the card DS
G becomes a state in which no registration has been made (that is, a state in which it can be used for all processes).

According to this modified example, it is possible to cancel the favorite registration and perform reservation registration for a reference card to be registered as a favorite when its use has not been determined.
In addition, it is possible to cancel the reservation registration and perform the favorite registration for the reference card that is the object of the reservation registration performed when the usage of evolutionary synthesis for a specific base card is decided. Therefore, the user can flexibly manage the usage of the reference card and the range of restrictions placed on the reference card.

(5-5-4) Fourth Modification In this embodiment, as shown in FIGS. 26 and 27A to 27C, the button b12 (
"reservation registration") and the button b13 ("favorite registration") are displayed side by side, but only one of these two buttons may be displayed.

(5-5-5) Fifth Modification In this embodiment, an example has been described in which a reservation registration or favorite registration process is requested via the acquisition condition presentation screen shown in image P5 in FIG. is the image P2 in FIG.
The request may be made via a change condition list screen as shown in 3a. An example of registration processing when the request is made via the change condition list screen will be described below with reference to FIG.

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

Upon receiving a request from the user terminal 10, the CPU 21 of the game server 20 executes processing for registration (reservation registration or favorite registration) in response to the request (S172), and sends the execution result of the registration processing 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). As a result, the user terminal 1
The image P23b in FIG. 27B or the image P23c in FIG.

As described above, the registration process in this modification includes four types of registration (reservation registration performed via the acquisition condition presentation screen, favorite registration performed via the acquisition condition presentation screen, change condition list screen reservation registration performed via , 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 embodiments, communication is performed between the user terminal 10 and the game server 20 according to HTTP, and the user terminal 10 interprets the HTML document obtained from the game server 20. Although the case where the present invention is realized in a so-called browser format, in which game images are displayed in , has been described, the present invention is not limited to this case. By executing the game program downloaded by the user terminal 10, the user terminal 10 proactively executes game processing, and the user terminal 10
0 and the game server 20 in a so-called native application format that suppresses transmission/reception processing. In the native application format, the CPU 11 of the user terminal 10 generates image data without using a web browser, so that the display unit 16
to display the image.
In this embodiment, an example in which the game of the above-described embodiment is implemented 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 some of the processing of the game not described below (for example, lottery processing given to the user by lottery, The game operator gives a card to the user, etc.), the process is executed on the game server 20 side,
The processing result by the game server 20 may be configured to be transmitted to the user terminal 10 .

In this 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 login processing is performed. Synthetic data table, possessed card data table, possessed history data table, and card distribution data table) are transmitted. A data table group to be 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 login is performed.
In order to prevent the possessed card data table from being falsified in the user terminal 10,
Each time the user terminal 10 completes a predetermined process or logs out of the game, the possessed card data table in the user terminal 10 is transmitted to the game server 20 .
The game server 20 compares the received possessed card data table with the possessed card data table in the storage 25, and confirms that the data has not been tampered with.
The possessed card data table in the storage 25 is updated based on the received possessed card data table.

29A and 29B are sequence charts showing processing for presenting acquisition conditions according to this embodiment. In FIGS. 29A and 29B, the same processing as in FIGS. 16A and 16B is given the same reference numerals.
In the evolutionary synthesis reservation process (FIGS. 29A and 29B) of the present embodiment, for example, at the time of login, the game server 20 sends the data table group (card data table, evolutionary synthesis data table, possessed card) in the storage 25 to the user terminal 10 data table, possession history data table, and card distribution data table) are transmitted (S8). User terminal 10
The CPU 11 stores the received data table group in the storage 18, and based on the operation input from the operation input unit 15, cooperates with the RAM 13, the display unit 16, etc. to perform S14
The processing of to S48 is executed.
Although not shown, in the present embodiment, the user terminal 10 proactively executes the evolutionary synthesis process, the Qwest process, and the evolutionary synthesis reservation process in the same manner.
In this embodiment, the card data table, evolutionary synthesis data table, quest data table, possession card data table, possession history data table, and card distribution data table are held in the game server 20, and the reservation data table is held in the user terminal 10.
Although the case of holding in the above has been described, the present invention is not limited to this case. In a native application format game, it is possible to appropriately set the share of holding each data table, and it is sufficient to hold at least one of the user terminal 10 and the game server 20, and a specific holding mode is not limited to If any data table 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. be done.

(7) Modifications Common to All Embodiments (7-1) Modifications Regarding Application to Applications Other than Games In the above-described embodiments and modifications, the case where the present invention is applied to games has been described. It may be applied to other applications. For example, if multiple types of electronic coupons are distributed each time a product is purchased at a shopping mall on the Internet, the electronic coupons may be an example of the object of the present invention. In this case, for example, in order to upgrade the privilege contents of coupon Q as a base object (an example of processing for changing the object), coupons A to A as reference objects corresponding to coupon Q are used.
It is conceivable that the user possesses and uses C. In this example, for the purpose of upgrading coupon Q, the conditions for obtaining a coupon (for example, coupon B) that the user does not possess among the coupons A to C required for that purpose are presented.
Applications other than the above examples can also be applied as appropriate.

(7-2) Modified example of operation input method In the above-described embodiment, the predetermined operation input to the user terminal is the input of the operation of pressing a predetermined instruction button on the user terminal, or the display on the user terminal equipped with the touch panel function. Although it is assumed that 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 equipped with an acceleration sensor, or an operation input by a gesture (gesture input). In the gesture input, by performing a predetermined gesture on a user terminal equipped with an imaging function, the user terminal recognizes the gesture as an image,
Recognizing an operation input associated with a gesture in advance. Moreover, in the case of a user terminal capable of executing a voice recognition program, the operation input may be performed by inputting voice.

(7-3) Modified Example of User ID Handling In the above-described embodiment, the user ID is included in the request sent from the user terminal 10 to the game server 20 (that is, the game server 20 receives Although the description has been made on the premise that the user who requested the process can be identified based on the transmitted request, the method for identifying the user who requested the process by the game server 20 is not limited to this.
For example, when a session based on a user ID is established between the user terminal 10 and the game server 20, the game server 20 may specify the user who requests the processing after the session based on the user ID. . In this case, the request sent from the user terminal 10 to the game server 20 does not need to include the user ID (that is, the user ID does not need to be sent from the user terminal 10 to the game server 20).

(7-4) Modifications Regarding Operation Targets In the above-described embodiments, buttons displayed on images are shown as examples of user operation targets. It can be.

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

One aspect of the present invention is
In an information processing device capable of accessing 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 in processing for changing the object,
Based on a user's instruction, a plurality of objects identified by a plurality of object identification information included in a change condition corresponding to the object identification information of the selection object, which is the selected object, is displayed in a display format that allows the user to identify each of them. first to let
output means (56) for outputting output data;
receiving means (51) for receiving an instruction to designate one of the plurality of objects based on the user's instruction in response to the output of the first output data by the output means (56); , and
The output means (56) further displays the conditions for obtaining the specified object when the user does not possess the specified object, which is the object specified by the instruction received by the receiving means (51). outputting the second output data of
Information processing equipment.

The “information processing device” may be a stand-alone game machine, a user terminal (for example, a mobile terminal, a personal computer, etc.), a server on a network, or the like. The substance of the information processing device can be appropriately defined depending on the implementation form of the game. For example, when a user operates a game machine or a user terminal to realize the function of each part of the information processing device, the game machine or the user terminal corresponds to the information processing device of the present invention. Alternatively, when a user terminal, which is a client, has a function of receiving operation input from a user and displaying an image, and the function of each part of the information processing device is substantially realized by a server that can communicate with the user terminal. , the server corresponds to the information processing apparatus of the present invention.
A “storage device” may be a memory device of any configuration, such as a flash memory or a HDD (Hard Disk Drive). Further, the storage device may be a device built in the information processing device, or an external device configured to be accessible from the information processing device by wire or wirelessly.
"Acquisition conditions" include subjective conditions (e.g., information about the user who owns the object), temporal conditions (e.g., object availability period), content conditions (e.g., average transaction price, first object It may be a second object (eg, item) required to obtain (eg, card), or a combination thereof), a location condition (eg, available area), or a combination thereof.

In the information processing apparatus described above, the process of changing the selected object is executed based on a change condition including at least information indicating a plurality of objects and the user's possession information. Therefore, for example, if the change condition is not satisfied, the process of changing the selected object cannot be executed. At this time, it may be impossible or difficult for the user to obtain the designated object that the user does not possess. However, the user who does not know the acquisition conditions of the designated object decides whether or not to execute the processing (for example, quest processing) to obtain the designated object because it is impossible or difficult to obtain the designated object. unrecognizable at this time. In such a case, the user will carry out the processing for obtaining the specified object while being worried that it may be impossible or difficult to obtain the reference object.
The above information processing apparatus presents conditions for obtaining a reference object that the user does not possess in response to a request from the user. Therefore, even if there is a designated object that is impossible or difficult for the user to obtain among the plurality of reference cards corresponding to the selected object, the user recognizes that it is impossible or difficult to obtain the designated object. Above, a decision can be made as to whether or not to perform processing to obtain the specified object. As a result, it is possible to give a sense of security to the user who executes the processing for obtaining the designated object.

The receiving means (51) further outputs the selected object to the specified object based on the user's operation in response to the output of the second output data by the output means (56). Receiving a request to limit its use for processing other than changing processing,
further comprising restricting means (58) for restricting the specified object from being used in processes other than the process of changing the selected object in response to acceptance of the request by the accepting means (51). may
``Restrict use for processes other than those that change the selected object'' does not mean that any process other than the process that changes the selected object is prohibited, and any process that changes the selected object is allowed. However, it is also possible to increase the requirements necessary for requesting execution of the process, or to make the operation necessary for requesting execution of the process complicated.
This restricts the designated object from being used in 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 specified object for a process other than the process of changing the selected object before the change condition is satisfied.

The acquisition condition may be an acquisition route of the specified object.
The “acquisition path” may be, for example, an area where the designated object can be obtained, or an area where the object can be traded between users (for example, an in-game shop).
In addition, the "acquisition route" is a combination of temporal conditions and location conditions (for example, information indicating whether or not the specified object was issued for a limited time (for example, a limited flag), a limited time acquisition area (for example, the day of the week when the limited-time quest is held), or a combination thereof).
This makes it possible to give a sense of security to the user who executes the processing for obtaining the specified object. In particular, when the "acquisition path" is a combination of temporal conditions and locational conditions, it is determined whether it is impossible or difficult to obtain the specified object when the user issues a request to change the selected object. It is particularly useful because it presents information to more accurately determine whether or not.

The second output data may include an operation target for guiding the user to the acquisition route.
This makes it possible to improve the operability when requesting execution of processing for obtaining the specified object.

The second output data indicates that the specified object has been possessed by the user and is not possessed by the user at the time when information indicating the specified object is acquired by the acquisition means (55). In the case of an unpossessed object, at least one of an acquisition path and acquisition difficulty of the specified object may be included.
This makes it possible to give a sense of security to the user who executes the process for obtaining the non-possessed object.

Information displayed as the acquisition condition may be restricted when the specified object is an unknown object that has never been possessed by the user, compared to when the specified object is the unpossessed object.
This makes it possible to give the user a sense of security while executing the process for obtaining the unknown object while keeping the game difficulty at an appropriate level.

Another aspect of the invention is
a user terminal and a server configured to be able to communicate with the user terminal, and object identification information for specifying an object; and change conditions including a plurality of object identification information used for processing to change the object. An information processing system capable of accessing a storage device stored in correspondence,
Either the user terminal or the server,
Based on a user's instruction, a plurality of objects identified by a plurality of object identification information included in a change condition corresponding to the object identification information of the selection object, which is the selected object, is displayed in a display format that allows the user to identify each of them. first to let
output means (56) for outputting output data;
receiving means (51) for receiving an instruction to designate one of the plurality of objects based on the user's instruction in response to the output of the first output data by the output means (56); , and
The output means (56) further displays the conditions for obtaining the specified object when the user does not possess the specified object, which is the object specified by the instruction received by the receiving means (51). outputting the second output data of
It is an information processing system.

Another aspect of the invention is
A computer capable of accessing a storage device that associates and stores object identification information that identifies an object and change conditions that include a plurality of object identification information used in processing for changing the object,
Based on a user's instruction, a plurality of objects identified by a plurality of object identification information included in a change condition corresponding to the object identification information of the selection object, which is the selected object, is displayed in a display format that allows the user to identify each of them. first to let
means (56) for outputting output data;
means (51) for receiving an instruction to designate one of the plurality of objects based on the user's instruction in response to the output of the first output data;
a second method for displaying acquisition conditions for the specified object when the user does not possess the specified object, which is the object specified by the received instruction;
means (56) for outputting output data;
It is a program for functioning as

Another aspect of the invention is
In an information processing device capable of accessing 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 in processing for changing the object,
A 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 the change condition corresponding to the object identification information of the selected object. means and
requesting, in response to the output of the first output data by the first output means, to limit the use of a first specified object, which is an object specified by a user, in a predetermined process; a first receiving means for receiving;
a first restricting means for restricting the first specified object from being used in the process in response to the acceptance of the request by the first accepting means;
An information processing device comprising:

As a result, the user can prevent the reference card from disappearing immediately after recognizing that it is difficult to obtain the reference card on the screen presenting the acquisition conditions. Therefore, it is possible to reliably prevent the unintentional loss of the reference card.

a second output means for outputting second output data for displaying a plurality of objects in a display format that can be identified by a user;
In response to the output of the second output data by the second output means, a second designated object, which is an object designated by a user among the plurality of objects, is used for a predetermined process. a second receiving means for receiving a request for restriction;
a second restricting means for restricting the second specified object from being used in the process 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 defines 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 to be displayed in a display format that is identifiable to each user.

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

"Processing executed on the condition that the specified object disappears from the possessed object" means that when the process is executed, the specified object disappears from the possessed object (that is, the specified object disappears from the possessed object). becomes an unowned object)
, is the process.

Further, at least one of the request received by the first reception means and the request received by the second reception means is provided on the condition that the object subject to the restriction is deleted from the possessed object. A first request for restricting the use of the selected object in the process executed as a second request, and a request to limit the use of the selected object in processes other than the process of changing the selected object among the processes executed on the condition that the selected object is deleted from the possessed object. and a second request to restrict.

Both of the "process of changing the selected object" and the "process other than the process of changing the selected object" are aspects of the "process executed on the condition that the selected object disappears from the possessed object".
The 'first request' is a request to limit all of the processes that are executed on the condition that the first specified object disappears from the possessed object.
The "second request" is a restriction on all of the processes other than the process of changing the selected object among the processes that are executed under the condition that the first specified object disappears from the possessed objects (in other words, change the selected object). is a request to allow only processing that causes

Further, 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 allows the user to identify each object. may be

The "object that is the target of the first request" is an object whose use is restricted to all processes that are executed on the condition that it is deleted from the possessed object (i.e., a state that cannot be deleted from the possessed object). object).
The ``object that is the target of the second request'' is limited to use for processes other than the process of changing the selected object (in other words, it is permitted to be used only for the process of changing the selected object). ) is an object.

Another aspect of the invention is
a user terminal and a server configured to be able to communicate with the user terminal, and object identification information for specifying an object; and change conditions including a plurality of object identification information used for processing to change the object. An information processing system capable of accessing a storage device stored in correspondence,
Either the user terminal or the server,
A 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 the change condition corresponding to the object identification information of the selected object. means and
requesting, in response to the output of the first output data by the first output means, to limit the use of a first specified object, which is an object specified by a user, in a predetermined process; a first receiving means for receiving;
a first restricting means for restricting the first specified object from being used in the process in response to the acceptance of the request by the first accepting means;
An information processing system comprising

Another aspect of the invention is
A computer capable of accessing a storage device that associates and stores object identification information that identifies an object and change conditions that include a plurality of object identification information used in processing for changing the object,
means for outputting first output data for displaying acquisition conditions of a plurality of objects specified by a plurality of object identification information included in change conditions corresponding to object identification information of the selected object;
means for receiving a request to limit the use of a first specified object, which is an object specified by a user, in a predetermined process in response to the output of the first output data;
means for restricting the first specified object from being used in the process in response to the acceptance of the request;
It is a program that functions as

In the above, in order to facilitate understanding of the present invention, the reference numerals shown in the drawings are appropriately written in parentheses, but this limits the information processing apparatus and the like according to the present invention to the illustrated embodiments. 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 section 25 Storage 26 Bus 51 Reception means 52 Game processing means 54 Card data change means 55 Acquisition means 56 Output means 57 Recording means 58 Restriction means 70 Data table group

Claims (5)

A base object and a change condition including a plurality of reference objects, which are reference objects having a plurality of loss factors including a process for changing the base object and are used for the process for changing the base object, are stored in association with each other. A computer with access to a storage device that
display means for displaying a plurality of reference objects included in the change condition corresponding to the selected base object, based on a user's instruction;
selecting means for selecting, from among the plurality of reference objects displayed by the display means, a reference object whose disappearance from the reference object owned by the user is restricted;
means for displaying acquisition conditions of the reference object selected by the selection means;
a first registration means for registering , after displaying the acquisition conditions, restriction of erasure based on the plurality of erasure factors;
a second registration means, which is the first registration means and a selective registration means, for registering restriction of erasure based on a part of erasure factors among erasures based on the plurality of erasure factors;
program to function as The second registering means does not limit disappearance caused by the process of changing the base object as a cause of disappearance.
A program according to claim 1. wherein the second registration means does not restrict only disappearance caused by a process of changing a specific base object among the base objects,
3. A program according to claim 2. A base object and a change condition including a plurality of reference objects, which are reference objects having a plurality of loss factors including a process for changing the base object and are used for the process for changing the base object, are stored in association with each other. In an information processing device that can access a storage device that
display means for displaying a plurality of reference objects included in the change condition corresponding to the selected base object, based on a user's instruction;
selecting means for selecting, from among the plurality of reference objects displayed by the display means, a reference object whose disappearance from the reference object owned by the user is restricted;
means for displaying acquisition conditions of the reference object selected by the selection means;
a first registration means for registering , after displaying the acquisition conditions, restriction of erasure based on the plurality of erasure factors;
a second registration means for registering restriction of erasure based on a part of the erasure factors among the erasure factors based on the plurality of erasure factors;
with
The first registration means and the second registration means are selectable,
Information processing equipment. A base object and a change condition including a plurality of reference objects, which are reference objects having a plurality of loss factors including a process for changing the base object and are used for the process for changing the base object, are stored in association with each other. In an information processing system that can access a storage device that
display means for displaying a plurality of reference objects included in the change condition corresponding to the selected base object, based on a user's instruction;
selecting means for selecting, from among the plurality of reference objects displayed by the display means, a reference object whose disappearance from the reference object owned by the user is restricted;
means for displaying acquisition conditions of the reference object selected by the selection means;
a first registration means for registering , after displaying the acquisition conditions, restriction of erasure based on the plurality of erasure factors;
a second registration means for registering restriction of erasure based on a part of the erasure factors among the erasure factors based on the plurality of erasure factors;
with
The first registration means and the second registration means are selectable,
Information processing system.

Images