JP7475721B2 - Program, information processing system, and output method for output data - 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 on social networking services (SNSs). As such social games, digital card games that use cards are known.
There is also known a game in which a user selects a main card and a sub card from among the cards owned by the user, and the main card and the sub card are combined to change the ability parameters of the main card and delete the sub card from the user's cards (Patent Documents 1 and 2).

Patent No. 5086491 Patent No. 5153960

In the synthesis process, in order to realize the synthesis process of a base object (base object; equivalent to the above-mentioned main card), it may be required that the user possesses a plurality of objects (reference objects; equivalent to the above-mentioned sub-cards) that satisfy the combination conditions corresponding to the base object. In such a case, a game is also known that has a mechanism in which a reference object required for executing a synthesis process on an object selected as a base object is presented to the user. However, in that case, only a reference object required for executing the most recent synthesis process on the selected card is presented to the user, and the user cannot know a reference object required for further executing a synthesis process after the most recent synthesis process is executed (i.e., a reference object required for a future synthesis process). Therefore, for example, in a game in which an object changes (evolves) into a different object in sequence every time a synthesis process is executed, a situation occurs in which a reference object that will be required in the future in the evolution process is given up even though the reference object is currently possessed. In such a case, in a future synthesis process, the user must obtain the object that was given up in the past again, and later regrets having given up the object.

The present invention has been made in consideration of the above-mentioned viewpoints, and its purpose is to provide an information processing device, an information processing system, and a program that can reduce the possibility of an object possessed by a user being lost due to being used for processing other than the user's desired purpose of using the object.

One aspect of the present invention is an information processing device that can access a storage device that stores object identification information for identifying an object and a change condition for performing a change process that changes the object, the change condition including a plurality of object identification information, in association with each other, the information processing device comprising:
a first receiving means for receiving, based on an operation by a user, a designation of a selected object which is an object selected from among objects possessed by the user;
an acquisition means for acquiring, from the storage device, each change condition for performing each of a plurality of change processes on the selected object, when the selected object is an object that can be changed stepwise so as to become a different object each time the change process is performed;
an output means for outputting output data for displaying a plurality of objects specified by a plurality of pieces of object identification information included in each of the change conditions acquired by the acquisition means in a display format that allows each of the objects to be identified by the plurality of object identification information to be displayed by a user;
The present invention is an information processing device comprising:

Another aspect of the present invention is an information processing system including a user terminal and a server configured to be able to communicate with the user terminal, wherein at least one of the user terminal and the server can access a storage device that stores object identification information for identifying an object and a change condition for performing a change process that changes the object, the change condition including a plurality of object identification information, in association with each other. In the information processing system,
a first receiving means for receiving, based on an operation by a user, a designation of a selected object which is an object selected from among objects possessed by the user;
an acquisition means for acquiring from the storage device each change condition for performing each of a plurality of change processes on the selected object, when the selected object is an object that can be changed stepwise so as to become a different object each time the change process is performed;
an output means for outputting output data for displaying a plurality of objects specified by a plurality of pieces of object identification information included in each of the change conditions acquired by the acquisition means in a display format that allows each of the objects to be identified by the plurality of object identification information.
The information processing system is provided in at least one of the user terminal and the server.

Another aspect of the present invention is a method for controlling a computer that can access a storage device that stores object identification information for identifying an object and a change condition for performing a change process that changes the object, the change condition including a plurality of object identification information, in association with each other.
a first receiving means for receiving, based on an operation by a user, a designation of a selected object which is an object selected from among objects possessed by the user;
an acquisition means for acquiring from the storage device each change condition for performing each of a plurality of change processes on the selected object, when the selected object is an object that can be changed stepwise so as to become a different object each time the change process is performed;
an output means for outputting output data for displaying a plurality of objects specified by a plurality of pieces of object identification information included in each of the change conditions acquired by the acquisition means in a display format that allows each of the objects to be identified by the plurality of object identification information.
This is a program that functions as a

FIG. 1 is a diagram showing a basic configuration of a game system according to a first embodiment. FIG. 2 is a block diagram showing a configuration of a user terminal according to the first embodiment. FIG. 2 is a block diagram showing the configuration of a game server according to the first embodiment. A diagram for conceptually explaining how to notify a user of cards required for evolutionary synthesis. FIG. 13 is a diagram showing an example of the configuration of a card data table. FIG. 13 is a diagram showing an example of the configuration of an evolutionary synthesis data table. FIG. 13 is a diagram showing an example of the configuration of a possessed card data table. FIG. 4 is a diagram showing an example of an image displayed on a user terminal according to the first embodiment. FIG. 4 is a diagram showing an example of an image displayed on a user terminal according to the first embodiment. FIG. 4 is a diagram showing an example of an image displayed on a user terminal according to the first embodiment. FIG. 2 is a functional block diagram of the game server according to the first embodiment. 11 is a sequence chart showing an example of a process for confirming evolutionary synthesis. 11 is a sequence chart showing an example of a process for confirming evolutionary synthesis. 11 is a sequence chart showing an example of an execution process of evolutionary synthesis. FIG. 13 is a diagram showing an example of an image displayed on a user terminal in a modification of the embodiment. FIG. 13 is a diagram showing an example of an image displayed on a user terminal in a modification of the embodiment. FIG. 13 is a diagram showing an example of an image displayed on a user terminal in a modification of the embodiment. FIG. 13 is a diagram showing an example of an image displayed on a user terminal in a modification of the embodiment. FIG. 13 is a diagram showing an example of an image displayed on a user terminal in a modification of the embodiment. FIG. 13 is a diagram showing an example of an image displayed on a user terminal in a modification of the embodiment. FIG. 4 is a diagram showing an example of the configuration of a reservation data table. FIG. 13 is a diagram showing an example of an image displayed on a user terminal in a modification of the embodiment.

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

FIG. 1 shows an example of the system configuration of a game system 1 according to an embodiment. As shown in FIG. 1, the game system 1 includes user terminals 10a, 10b, 10c, and a game server 20. The game server 20 can be accessed from each of the user terminals 10a, 10b, and 10c via a communication network NW such as the Internet.
0 is an example of an information processing device.
Each of the user terminals 10a, 10b, 10c, ... is a terminal operated by an individual user, and is, for example, a communication terminal such as a feature phone, a smartphone, a tablet terminal, a personal computer, a television receiver with a two-way communication function (including a so-called multi-function smart TV), a portable game machine with a communication function, etc. In the following description, when referring to each of the user terminals 10a, 10b, 10c, ... in common, they will be referred to as the user terminal 10.

The game server 20 is a server that executes a game. A program capable of creating image data that can be interpreted by a web browser (e.g., image data described in a format such as HTML or XML. In the embodiment of the present invention, HTML data will be used as an example.) is implemented in the game server 20. Note that image data is an example of output data.
The user terminal 10 is equipped with a web browser that interprets and displays HTML data provided by the game server 20, and transmits requests based on user operations on a web page by the user terminal 10 to the game server 20 via a network.
The game processing is executed by receiving the processing results from the.
The communication network NW may be, for example, the Internet, a Wide Area Network (WAN), a Local Area Network (LAN), or a Local Area Network (LAN).
A communications network is an information and communications network that is composed of a Multi-area Network, a Private Area Network, a leased line, or a combination of these.

(1-2) Configuration of the 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,
The device is equipped with an OM (Read Only Memory) 12, a RAM (Random Access Memory) 13, an operation input unit 15, a display unit 16, a communication interface unit 17, and a storage 18, and is provided with a bus 19 for transmitting control signals or data signals between each unit.

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

For example, the CPU 11 may execute a web browser stored in the storage 18 in the RAM 1
Then, the CPU 11 loads the program into the communication interface unit 17 based on a URL (Uniform Resource Locator) input by the user through the operation input unit 15 or the like.
The game server 20 transmits data for displaying a web page, i.e.,
The user terminal 10 acquires data of objects such as ML (HyperText Markup Language) documents and images associated with the documents (hereinafter collectively referred to as "HTML data") via the communication interface unit 17, and executes the web browser to interpret the HTML data. The user terminal 10 may be equipped with various plug-ins for expanding the browser functions of the web browser. One example of such a plug-in is Flash Player by Adobe Systems Incorporated of the United States. Alternatively, the HTML data in this 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 operates the operation input unit 15 to select a URL (Uniform Resource Locator) or an operation target (for example, a software button (hereinafter simply referred to as "button")) on a web page, the web browser sends an HTTP request including the selection result to the game server 20 in order to update the web page. The web browser obtains HTML data from the game server 20 as an HTTP response,
The web page image is interpreted and displayed on the display unit 16 .
In this embodiment, the HTML data is an example of image data.

The display unit 16 is, for example, an LCD (Liquid Crystal Display) or an organic EL (Electro Luminescence) display.
In the case of a liquid crystal display (LCD) monitor including thin film transistors arranged in a matrix on a pixel basis, the display unit 1
6 displays an image of a web page on a display screen by driving the thin film transistors.

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

The storage 18 is a storage device configured by, for example, a flash memory or a hard disk drive (HDD).

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

The CPU 21 reads out the programs and data stored in the ROM 22, and controls the overall operation of the game server 20, such as timing processing of control signals and data signals between each unit in the game server 20. The CPU 21 also reads out the programs stored in the storage 25 and various data required for the execution of the programs, expands them in the RAM 23, and performs various processes such as data input/output processing, calculation processing, and judgment processing associated with the execution of the programs.
The reference numeral 3 temporarily stores data for the CPU 21 to carry out calculations, determinations, and the like.

For example, the storage 25 stores a program for providing a web service by communicating with a web browser of the user terminal 10, which is a client, according to HTTP. The CPU 21 loads the program stored in the storage 25 into the RAM 23 and executes the program. As the program is executed, 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 returns HTML data including the execution result to the user terminal 10 as an HTTP response.

The storage 25 is a storage device configured, for example, by a flash memory or a hard disk drive (HDD), and stores the above-mentioned programs as well as a data table group 70 (described later). The data table group 70 includes a card data table, an evolution synthesis data table, and a possession card data table. Each data table in the storage 25 is accessed by the CPU 21 as appropriate to read and write data.

(1-4) Presenting cards necessary for card evolution synthesis The game executed in the game system 1 of this embodiment is a game in which the user uses cards as objects.
For example, it is a game in which a user explores an area in the game to obtain cards and items, or plays against other users or NPCs (Non-Player Characters) using cards owned by the user.
In the following explanation, "possessing" a card means that the user is able to use the card for a transaction using that card. "Not possessing" a card means that the user is unable to use the card for a transaction using that card. "Acquiring" a card means that the user has moved from a state of not possessing the card to a state of possessing the card.
In the game of this embodiment, the card evolution synthesis process (hereinafter simply referred to as "evolution synthesis" or "evolution") is a process of evolving a card owned by a user when a certain condition is satisfied. In the example of this embodiment, the card evolution synthesis is a process of changing the card ID as described later, but it may also be a process of changing at least a portion of the card data (described later) corresponding to the card. In this case, there is no particular restriction on what card data is changed, but it may be, for example, card parameters such as the card name, card image, and rarity. The card evolution synthesis is an example of an object change process.
To perform evolution synthesis, the user must use a card they own (hereinafter referred to as "possessed card" as appropriate).
The user selects a card that he or she wants to evolve as a base card from the list of cards in the list. The card selected as the base card is an example of a selection object.
In evolutionary synthesis, a combination condition (an example of a change condition) of the card IDs of multiple cards (called "reference cards") required to evolve the base card is determined for each base card ID. When evolutionary synthesis is executed, the reference cards used in the evolutionary synthesis disappear from the user's possession of cards.
In this embodiment, the possession card and the reference card are examples of the possession object and the reference object, respectively.
In the game of this embodiment, the condition for evolving a selected card is that the user possesses multiple reference cards that are included in the combination conditions corresponding to the card selected by the user as a base card.

The card presentation required for the evolution synthesis of cards will be specifically described with reference to Fig. 4. Fig. 4 is a diagram for conceptually explaining the card presentation required for the evolution synthesis of cards.
4, it is assumed that the user has cards A, D, G, Q1, M2, ... and wishes to evolve card Q1. In this example, it is assumed that card Q1 is an object that can be transformed into different cards (Q1 → Q2 → Q3) each time evolution synthesis is performed.
In this example, the reference cards required to evolve card Q1 to card Q2 are card A, card B, and card C, and the reference cards required to evolve card Q2 to card Q3 are card E, card F, card G, and card H.

In this embodiment, not only the reference cards (card A, card B, and card C) required for card Q1 selected as a base card are presented to the user, but also the cards (cards A, B, C, E, F, G, and H) required when card Q1 evolves into different cards in stages. Therefore, the user can easily select the cards presented to him/her (cards A, B, C, E, F, G, and H).
However, it is possible to recognize in advance that these cards are necessary for the future evolution synthesis of card Q1, which is the card selected as the base card, and this prevents the user from mistakenly giving up the presented multiple cards. For example, if, in FIG. 4, only the cards (card A, card B, and card C) necessary for one evolution synthesis of card Q1 selected as the base card were presented to the user, there is a risk that the user will give up (e.g., dispose of) card G, even though card G owned by the user is necessary for the future evolution of card Q1 (in this example, the evolution of card Q2 to Q3). In contrast, in this embodiment,
When card Q1 selected as a base card evolves step by step into different cards, the cards required (cards A, B, C, E, F, G, and H) are presented to the user, thereby avoiding a situation where the user mistakenly gives up card G, for example.

(1-5) Data Table Configuration Next, the card data table, evolution synthesis data table, and possession card data table stored in the storage 25 of the game server 20 will be described in order with reference to Figures 5 to 8. The storage 25 of the game server 20 is an example of a storage device.

(i) Card Data Table The card data table records data of cards used in the game of this embodiment. An example of the configuration of the card data table is shown in Fig. 5. In the example shown in Fig. 5, the card ID
Each card contains the card name, card image, and card parameter data.
D is an example of object identification information.
The card name is a character string that indicates the name of the character that is displayed on the card. The card image is an image of the character that is displayed on the card. The card parameters are composed of the following data: rarity, attributes, cost, skills, selling price, attack power, defense power, and limited flag.
Rarity is an index that indicates the rarity of a card, and in the example shown in FIG. 5, rarity is set in the order of increasing rarity from R1 to R5.
The attribute is the attribute of the character displayed on the card, and in the example shown in FIG. 5, it is one of N1 to N3.
The cost is a value that is referenced when a card is incorporated into a user's card team. For example, when a battle is to be played using card teams, the sum of the costs of the cards included in the card team is limited to a predetermined value or less.
The skill is information indicating an advantageous effect when playing a game using a card,
4, skills with various effects, SK1 to SK12, are set for each card. Note that it is not necessary for all cards to have skills.
The selling price is the game points that a user can obtain when selling a card that the user owns.
Attack power and defense power are parameters that are referenced when using a card in a battle.
The limited flag is a flag that indicates whether or not the card is issued for a limited time. In the example shown in Fig. 4, a card with a limited flag of "1" indicates that the card is issued for a limited time, and a card with a limited flag of "0" indicates that the card is not issued for a limited time.

(ii) Evolutionary Synthesis Data Table The evolutionary synthesis data table records the conditions for evolutionary synthesis of cards in the game of this embodiment. FIG. 6 shows an example of the configuration of the evolutionary synthesis data table. In the example shown in FIG. 6, for each evolution ID for identifying the contents of evolutionary synthesis, a pre-evolutionary card ID (i.e., the card ID of the card that is the base card before evolution), a post-evolutionary card ID (the card ID of the evolved card of the base card), and a post-evolutionary card ID are stored.
D), and the combination conditions of the card IDs of the reference cards required to perform evolution synthesis (the five reference cards in the C1 to C5 columns) are recorded. For example, Evolution ID: 0002
In the condition shown in FIG. 1, the user selects the card with card ID: 0072 as the base card from among the cards in his possession, and the card IDs: 0025, 0060, 007 are among the cards in his possession.
If a combination of three cards with the number 0 exists, the card with card ID: 0072 can be evolved into the card with card ID: 9072 by performing evolutionary synthesis.
In other words, the combination conditions of the reference card IDs in the evolution synthesis data table are an example of change conditions that change the card corresponding to the pre-evolution card ID.
In addition, the same card ID may be recorded in at least two of the columns C1 to C5, which indicate the combination conditions of the card IDs of the reference cards. For example, the combination conditions of the reference cards used when evolving and synthesizing the base card may include two or more identical reference cards. If the combination condition of the reference cards for evolving the base card is that a predetermined number of reference cards with the same card ID are included, the data format may be composed of the card IDs of the reference cards and the number of reference cards, rather than the data format shown in FIG. 6.

(iii) Possessive card data table The possessive card data table records information on the possessive cards of the user. An example of the configuration of the possessive card data table is shown in Fig. 7. Fig. 7 shows an example of the possessive card data table for one user, but a possessive card data table is provided for each user registered in the game.
In the owned card data table shown in FIG. 7, the serial number, card level, and skill level data are recorded in association with each card ID. The serial number is a unique number that is determined when a card is given to a user.
A different serial number is also assigned to the card of D. When a card evolves, the serial number of the card before and after the evolution may or may not be changed.
The card level is a parameter that indicates the development level of a card, and is increased, for example, by performing normal synthesis. When a user acquires a card, the card level value (initial value) is 1, and the user can grow the card (i.e., increase the card level) by performing normal synthesis.
The skill level is a parameter that indicates the level of development of a card, and in particular, the level of the skill that the card has. When a user acquires a card with a skill, the value (initial value) of the skill level is 1, and the skill level of the card can be increased by, for example, performing normal synthesis using a card that satisfies a certain condition as a reference card. As the skill level of a card increases, the effect generated by the skill increases.

In the following description, the card name, card image, serial number, and
The card parameters are collectively referred to as "card data" as appropriate. The card parameters constituting the card data include each card parameter recorded in the card data table,
The card level and skill level recorded in the possessed card data table are included. In other words, the card name, card image, serial number, and any data among each card parameter correspond to card data. The card ID, card name, and card image are each an example of object identification information.

(1-6) Specific Examples of Card Evolution and Synthesis Processing Specific examples of card evolution and synthesis processing in the game of this embodiment are described below with reference to FIGS.
8 to 10 are diagrams showing examples of screens displayed on the user terminal 10 when the game processing of this embodiment is being executed.

8 shows a series of changes in the display screen when a process related to the evolution synthesis of a user's owned card is executed. In FIG. 8, image P1 is an image including the main menu of the game of this embodiment. In image P1, buttons b1 ("View Owned Monsters"), b2 ("Team Creation"), b3 ("Normal Synthesis"), b4 ("Evolution Synthesis"), and b5 ("Sell") are provided as objects of user operation.
Button b1 is a button designated when making a request to view cards owned by the user. Button b2 is a button designated when the user selects a card from his/her owned cards to use in a battle with another user or an NPC. Button b3 is a button designated when making a request to execute a normal synthesis of a card selected as a base card from the cards owned by the user. Button b4 is a button designated when making a request to execute an evolution synthesis process of a card selected as a base card from the cards owned by the user. Button b5 is a button designated when making a request to execute a selling process for a card selected from the cards owned by the user.

When button b4 ("Evolution Synthesis") is selected in image P1, the image changes to that shown in P2. In image P2, a list of multiple owned cards is displayed so that the user can select one of the cards he or she owns as a base card. For cards that cannot be evolved, it is preferable that the card image is displayed in a display format that allows the user to recognize that the card cannot be selected as a base card.
When, for example, card Q01 is selected in image P2, the image changes to that shown in P3. Image P3 includes text indicating that card Q01 has been selected as the base card, as well as a button b11 ("Confirm") for confirming the reference cards required at each stage of the evolution of the selected card Q01, and a button b12 ("Reselect Card") for returning to image P2 and reselecting a card in your possession to be used as the base card.
When "Confirm" is selected, the image changes to that shown in P4 (FIG. 9).

In FIG. 9, image P4 shows card Q0 selected as the base card by the user.
The first stage evolution of 1 (card Q01 → R01) and the reference cards required for that evolution (cards A01, B03, C12), the second stage evolution (card R01 → S01) and the reference cards required for that evolution (cards A01, K14, M03, R05), and the final stage evolution (
The evolution of the base card Q01 is displayed in a format that is easy for the user to distinguish. The final stage of evolution is also called the "final evolution." In addition, the final stage of evolution is displayed in a format that is easy for the user to distinguish.
In each of the figures from FIG. 9 onwards, the display of the card image of the reference card is omitted as appropriate.

Cards A01, B03, and C included in the first stage evolution synthesis conditions of card Q01
If the user has all of the cards (i.e., the reference cards for evolving card Q01), image P4 of FIG. 10 will be displayed instead of image P4 of FIG.
A is displayed.
Image P4a includes text ("All cards are ready") notifying the user that all cards for the first stage of evolutionary synthesis are ready, and a button b21 ("Evolve") requesting the execution of the first stage of evolutionary synthesis. When button b21 is selected in image P4a, the image changes as shown in P5. That is, evolutionary synthesis from card Q01 to card R01 is executed, and the card image, card name, and at least a part of the parameters of the evolved card are displayed as shown in image P5. When the first stage of evolutionary synthesis is executed, cards A01, B03, and C12, which are reference cards for evolutionary synthesis, disappear from the user's possession cards.

(1-7) Overview of Functions of Information Processing Device Next, the functions of the game server 20 for implementing the game of this embodiment described above will be described. FIG. 11 is a functional block diagram for explaining the functions that play the main role in the game server 20 of this embodiment. In FIG. 11, the data table group 70 includes a card data table, an evolution synthesis data table, and a possessed card data table, as described above. Note that not all of the means included in the functional block diagram shown in FIG. 11 are essential elements of the present invention. For example, in one aspect of the present invention, a reception means 51, an acquisition means 53, and a
, and output means 54. Also, recording means 57, limiting means 58, and registration means 59 will be mentioned in modified examples.

The reception unit 51 has a function of receiving various requests from the user based on information regarding the user's operation input. In the game of this embodiment, the requests from the user include, for example, a request for card evolution synthesis processing, a request for execution of evolution synthesis, a request for execution of normal synthesis, and a request for sale processing.
Furthermore, the acceptance means 51, as a first acceptance means, has a function of accepting designation of a card selected as a base card from among the cards possessed by the user, based on information regarding the user's operational input.
In order to realize the function of the reception means 51, the game server 20 includes a communication interface unit 2
A request corresponding to a user's button operation input in a web page image from the user terminal 10, or information on a card selected as a base card (e.g., a serial number) is received from the user terminal 10 via the game server 20. The CPU 21 of the game server 20 determines the content of the request based on the information included in the received request, and performs a request reception process. In the reception process, the request is stored in the RAM
The serial number of the received card is recorded in RAM 13. The CPU 21 executes the processes according to the received requests in order. The CPU 21 also records the received card serial number in RAM 23.

The game execution means 52 has a function of executing various game processes other than evolutionary synthesis based on requests from the user terminal 10 received by the reception means 51. The game processes of this embodiment may be provided as appropriate, and may include, for example, battle processing between users, battle processing between a user and an NPC, quest processing by a user, and normal synthesis processing of cards owned by a user.
Although the battle process will not be described in detail, for example, a user may organize a team of cards owned in advance so that the total cost is equal to or less than a predetermined upper limit, and the team may battle against other users or NPCs. The outcome of the battle is determined by parameters such as the attack power, defense power, and skills of each card in the team.
The quest process is a process in which the user explores areas within the game to obtain cards and items.

The functions of the game execution means 52 when executing the normal synthesis process of the user's owned cards are as follows:
This is realized as follows. When the CPU 21 of the game server 20 receives a request to execute a normal synthesis including the user's selection results for the base card and the reference card, the CPU 21 reads the card data of the base card and the reference card from the possession card data table and executes the RA.
M23. Next, the CPU 21 of the game server 20 changes the parameters of the base card (e.g., card level and skill level) based on the parameters of the base card and the reference card, writes the changed parameters of the base card into the owned card data table, and deletes the card data of the owned card that was set as the reference card from the owned 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, the value of the development parameter associated with the card may be increased each time normal synthesis is performed, and when the value of the development parameter reaches a predetermined value, the card level may be increased by one and the value of the development parameter may be reset to zero.

The function of the game execution means 52 when executing the selling process of the user's owned cards is realized as follows. Although not shown in FIG. 5, in the card data table, the selling price (points) is associated with each card ID.
When the PU 21 receives a request for a selling process and obtains the selection result of the card to be sold, it deletes the card data of the card to be sold from the owned card data table. Furthermore, the CPU 21 of the game server 20 reads the selling price value (points) of the card to be sold from the card data table and performs a process of granting the read points to the user. The process of granting points to the user is, for example, a process of updating the value of the user's owned points recorded in a user database (not shown).

The acquisition means 53 has a function of acquiring each combination condition for performing multiple stages of evolutionary synthesis on the selected card from the evolutionary synthesis data table when the card selected as the base card (an example of a selected object) is a card that can evolve in stages to become a different card each time evolutionary synthesis is performed.
The function of the acquisition means 53 can be realized by the CPU 21 of the game server 20 executing the following procedure.
(Step 1) The card ID corresponding to the serial number of the card selected as the base card is identified by referring to the possessed card data table.
(Step 2) In the evolution synthesis data table, identify an evolution ID in which the same "pre-evolution card ID" as the card ID identified in step 1 is recorded. Then, read out the "evolution card ID" corresponding to the identified evolution ID and the reference card ID included in the combination conditions.
(Step 3) Identify an evolution ID in which the same "pre-evolution card ID" as the read "evolution card ID" is recorded. Then, the "evolution card ID" corresponding to the identified evolution ID is
and the reference card ID included in the combination condition are read out. Then, step 3 is repeated until the evolution ID cannot be specified.

The output means 54 has a function of outputting image data (an example of output data) for displaying multiple cards identified by the card IDs of multiple reference cards included in each combination condition acquired by the acquisition means 53 in a display format that is identifiable to the user.
In order to realize the function of the output means 54, the CPU 21 of the game server 20 acquires the pre-evolution card ID, the post-evolution card ID, and the reference card ID included in the combination condition, which correspond to the evolution ID in each evolution synthesis when the user's owned card selected as the base card evolves sequentially each time evolution synthesis is performed, and reads out card data (e.g., card name, card image, etc.) corresponding to these card IDs from the card data table. Next, the CPU 21 generates image data to be presented to the user based on the read card data and transmits it to the user terminal 10. An example of an image displayed on the user terminal 10 based on this image data is image P4 in FIG. 9.

The determination means 55 has a function of determining whether or not a combination condition that a plurality of reference cards corresponding to a card selected as a base card is included in the user's owned cards is satisfied.
To realize the function of the determination means 55, for example, the CPU 21 of the game server 20 refers to a possessed card data table to determine whether or not the user possesses a card identified by a plurality of reference card IDs included in the combination conditions corresponding to the card ID of the card selected as the base card.

The modification means 56 has a function of executing evolutionary synthesis to modify the card data of the base card when the determination means 55 determines that the conditions are satisfied. Evolutionary synthesis is an example of a process of modifying a card as an object.
In the example of this embodiment, in order to realize the function of the change means 56, the CP of the game server 20
When U21 receives a request to execute evolution synthesis, it erases the card data of the pre-evolution card (i.e., the base card of the evolution synthesis) in the possession card data table and writes new card data of the evolved card. This evolves the base card of the user's possession card. As shown in the evolution synthesis data table, since the card IDs of the pre-evolution and evolved cards are different, at least one of the card name, card image, and card parameters is changed by the evolution synthesis.

(1-8) Process flow of evolution synthesis in the game of this embodiment Next, an example of the process flow of evolution synthesis in the game of this embodiment will be described with reference to FIG.
The following description will be given with reference to the sequence charts of Fig. 12A and Fig. 13.
FIG. 2B is a sequence chart showing an example of a process for confirming evolutionary synthesis. FIG. 13 is a sequence chart showing an example of a process for executing evolutionary synthesis.
The timing of processing for displaying each image shown in FIG.

(A) Evolutionary synthesis confirmation process (FIG. 12A, FIG. 12B)
In the main menu of the game of this embodiment (see FIG. 8), the button b4 ("Evolution Synthesis")
When the user selects the evolutionary synthesis process, the CPU 11 of the user terminal 10 accepts the request for the evolutionary synthesis process (S
10), and transmits the request to the game server 20 (S12).
When the game server 21 receives a request for evolution synthesis processing from the user terminal 10, it identifies the card ID of the requesting user's owned card from the owned card data table, reads the card data of the owned card from the card data table and the owned card data table, generates image data including a list of the owned cards (S14), and transmits the image data to the user terminal 10 (S16). When the CPU 11 of the user terminal 10 acquires the image data received in S16, it displays an image (for example, image P2 of FIG. 8) on the display unit 16 based on the image data (S18). In addition, in S14, the CPU 21 of the game server 20 determines whether each of the user's owned cards is an evolvable card by determining whether the card ID of each of the user's owned cards is recorded in the evolution synthesis data table as a pre-evolution card ID, and preferably generates image data in a display format that allows the user to recognize that the owned cards that cannot be evolved cannot be selected as base cards.

The image displayed in S18 includes images and names of the aligned cards owned by the user, as exemplified by image P2 in Fig. 8, and is configured so that the serial number of each card can be selected by selecting the image of each card. When an operation is performed to select one of the multiple owned cards displayed in S18 as a base card, the CPU 11 of the user terminal 10 accepts the selection result (serial number) of the base card (S20).
The CPU 2 of the game server 20 transmits the selection result to the game server 20 (S22).
Based on the received base card selection result, the user terminal 1 generates confirmation image data for confirming the base card selection result (S24) and transmits the image data to the user terminal 10 (S26). When the CPU 11 of the user terminal 10 acquires the image data received in S26, it displays an image (e.g., image P3 in FIG. 8) on the display unit 16 based on the image data (S28).
The image displayed in S28 has buttons (b11, b12) for confirming the selection result of the base card, as shown in image P3 of FIG. 8.
Based on the user's operation of this button, U11 receives a response as to whether or not to confirm the base card selection result transmitted in S22, and transmits the response to the game server 20. Here, it is assumed that the CPU 11 receives a response (base card confirmation response) that confirms the base card selection result transmitted in S22, and transmits the confirmation response to the game server 20 (S30).
When the CPU 21 of the game server 20 receives the confirmation response of the base card, the CPU 21 refers to the possessed card data table based on the serial number of the card selected as the base card,
The card ID of the selected card is identified (S32).

Next, the CPU 21 checks the card ID specified in S32 in the evolution synthesis data table.
It is determined whether an evolution ID in which the same "pre-evolution card ID" is recorded is specified (S
34). When an evolution ID is specified (S34: YES), the CPU 21 reads out the evolved card ID corresponding to the specified evolution ID and the reference card ID included in the combination condition (S36). Note that when the image displayed in S18 is displayed in a display format in which a possessed card that cannot be evolved cannot be selected as a base card, the card selected as the base card in S20 is an evolvable card, so in S34, the evolution ID
will definitely be identified.
Next, the CPU 21 determines whether or not an evolution ID is specified in which the same pre-evolution card ID as the evolved card ID read in S36 is recorded (S38). If an evolution ID is specified (S38: YES), the process returns to S36 and reads out the evolved card ID corresponding to the evolution ID specified in S38 and the reference card ID included in the combination condition.
The processes of S36 and S38 are repeated until the evolution ID is no longer specified, and
Each combination condition (i.e., reference card ID required for each evolution) for performing evolution synthesis at each stage multiple times on the owned card selected as the base card is read out. Note that, although the processing flow in this embodiment is described using a method using the "pre-evolution card ID" and the "evolution card ID" in the evolution synthesis data table, it is not limited to this method. For example, it may be a method of defining all stages of evolution for each card ID in the evolution synthesis data table and the reference card ID required for that evolution, and reading out each combination condition for performing evolution synthesis at each stage multiple times on the owned card selected as the base card. It may also be other methods. In other words, any method may be used as long as it is a method of reading out each combination condition for performing evolution synthesis at each stage multiple times on the owned card selected as the base card.

If the evolution ID is no longer specified (S38: NO), the CPU 21 proceeds to S40. In S40, the CPU 21 refers to the possessed card data table to check whether the user possesses all of the cards specified by the reference card IDs included in the combination condition corresponding to the evolution ID specified in S34 (S40). In other words, it is checked whether the user possesses all of the reference cards necessary to evolve the card selected by the user as the base card.

Next, the CPU 21 generates image data to be presented to the user based on the evolved card ID and the reference card ID in each evolution read out in S36 and the confirmation result of S40 (S42), and transmits the image data to the user terminal 10 (S44). When the CPU 11 of the user terminal 10 acquires the image data received in S44, it displays an image on the display unit 16 based on the image data (S46). If it is confirmed in S40 that the user possesses all the reference cards necessary to evolve the card selected as the base card, an image including a button for evolving the card selected as the base card is displayed, for example, as shown in image P4a of FIG. 10, and if not, an image not including a button for evolving the card selected as the base card is displayed, as shown in image P4 of FIG. 9. Note that an image including a button for evolving the card may be displayed when it is confirmed that the user possesses all the reference cards and that other conditions are met (for example, the base card has reached the maximum level). In other words, the card selected as the base card has reached the maximum level,
A condition for evolving the selected card may also be that the user possesses all of the reference cards. In either case, the generated image data is image data for displaying multiple cards specified by the card IDs of multiple reference cards included in each evolution combination condition in a display format that allows the user to identify each of the cards.
If the evolution ID is not specified in S34 (S34: NO), this means that the card selected as the base card by the user is a card that cannot be evolved.
The image data generated at 42 is data for displaying an image (not shown) including text such as "The selected card cannot be evolved."

(B) Execution process of evolutionary synthesis (Figure 13)
The sequence chart shown in Fig. 13 shows the flow of processing when an image including a button for evolving a card selected as a base card is displayed in S46 of Fig. 12B, for example as illustrated in image P4a of Fig. 10. For example, image P4a of Fig. 10 has a button b21 ("Evolve") for confirming whether or not to request the execution of evolution synthesis. In Fig. 13, when the CPU 11 of the user terminal 10 accepts a request to execute evolution synthesis based on the user's operation of specifying this button (S50), the request is transmitted to the game server 20 (S52).

When the CPU 21 of the game server 20 accepts a request to execute evolution synthesis received from the user terminal 10, it erases the card data of the pre-evolution card (i.e., the base card of the evolution synthesis) from the possessed card data table (S54), and writes new card data of the evolved card (S56). At this time, the card data includes, for example, a serial number issued in correspondence with the evolved card ID. Next, the CPU 21 of the game server 20 erases the card data of the reference card used for evolution synthesis from the possessed card data table (S5
8).
After executing the evolution synthesis, the CPU 21 generates image data including card data of the evolved card (S60), and transmits the image data to the user terminal 10 (S62). When the CPU 11 of the user terminal 10 acquires the image data transmitted in S62, it displays an image (e.g., image P5 in FIG. 10) on the display unit 16 based on the image data (S64).

As described above, in the game system of this embodiment, when a user's owned card (an example of a selected object) selected as a base card is a card that can evolve step by step to become a different card each time evolution synthesis is performed, the user is presented with not only the combination conditions (an example of change conditions) required for one stage of evolution of the selected owned card, but also multiple cards specified by multiple reference card IDs included in the combination conditions for multiple stages of evolution synthesis in the future. Therefore, the user can recognize in advance that the multiple presented cards are reference cards required for the future evolution of the selected owned card, and is prevented from accidentally giving up any of the multiple presented owned cards.

In the above-described embodiment, a case has been described in which the output means 54 outputs image data by displaying multiple cards identified by multiple reference card IDs included in each combination condition acquired by the acquisition means 53, distinguishing them according to the corresponding combination condition.
When such image data is output, the following advantages are obtained.
As shown in FIG. 4, multiple reference cards included in the combination conditions for the first stage evolution synthesis, the second stage evolution synthesis, ... are displayed for each combination condition, so that the user can distinguish and recognize cards that will be needed for evolution synthesis in the relatively near future from cards that will be needed in the relatively distant future. Therefore, the user can select to use cards that will be needed in the relatively distant future for a process other than evolution synthesis, for example, for another purpose.

(2) Second embodiment In the first embodiment, communication is performed between the user terminal 10 and the game server 20 according to HTTP, and the user terminal 10 displays game images by interpreting HTML documents acquired from the game server 20, so that the present invention is realized in a so-called browser format. However, the present invention is not limited to this. The user terminal 10 executes a game program downloaded by the user terminal 10, thereby independently executing game processing.
Alternatively, the above-mentioned application may be realized by a so-called native application format, which suppresses the transmission and reception processing between the user terminal 10 and the game server 20. In the native application format, image data is generated and displayed within the user terminal 10 without using a web browser.
In the second embodiment, an example of the case where the game of the first embodiment is realized in a native application format will be described. The hardware configuration of this embodiment may be the same as that of the first embodiment. In the native application format of this embodiment,
It is assumed that most of the processing will be performed on the user terminal 10 side, but some of the game processing not described below (e.g., lottery processing in which a prize is awarded to a user through a lottery, and gift processing in which a game operator awards a card to a user, etc.) may be performed on the game server 20 side, and the processing results by the game server 20 may be transmitted to the user terminal 10.
In this embodiment, the user terminal 10 is an example of an information processing device.

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, a login process is performed, and a group of data tables (card data table, evolution synthesis data table, and possessed card data table) is transmitted from the game server 20 to the user terminal 10. The group of data tables transmitted to the user terminal 10 includes:
The data is stored in the storage 18 of the user terminal 10. In this case, the data tables in the storage 18 are updated every time a user logs in.
In order to prevent the possessed card data table from being tampered with in the user terminal 10,
Each time a predetermined process is completed by the user terminal 10, or when the user 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 after confirming that the data has not been tampered with, updates the possessed card data table in the storage 25 to the received one.

Although not shown in the figure, in this embodiment, the user terminal 10 is
The process flow of evolutionary synthesis shown in is executed by referring to the data tables in the storage 18.
In this embodiment, the case where the card data table, evolution synthesis data table, and possession card data table are stored in the game server 20 has been described, but this is not limited to this case. In a game in a native application format, the storage allocation of each data table can be set appropriately, and each data table may be stored in at least one of the user terminal 10, the game server 20, or another device accessible from the user terminal 10 or the game server 20, and is not limited to a specific storage mode.

(3) Modifications Modifications common to the above-described embodiments will now be described.

(3-1) Modification 1
In this modified example, the output means 54 outputs image data by displaying multiple reference cards identified by multiple reference card IDs included in each combination condition acquired by the acquisition means 53, distinguishing them by reference card ID.
In order to realize the function of the output means 54 of this modified example, the CPU 21 of the game server 20
When the pre-evolution card ID, evolved card ID, and reference card ID included in the combination conditions corresponding to the evolution ID in each evolution synthesis are obtained, the card data corresponding to these card IDs are read from the card data table, and image data is generated to display each reference card ID separately. An example of an image displayed based on the generated image data is shown in Figure 14. Image P4b shown in Figure 14 is an example of an image that displays image P4 of Figure 9 according to this modified example.
In this configuration, the cards included in each combination condition are presented to the user separately for each card ID, allowing the user to quantitatively recognize how many of each card are required. This allows the user to get an overview of all the cards required to evolve the selected card into different cards, and also allows the user to easily recognize how many types of cards they need to obtain.
Furthermore, the display may be made so that it is clear whether the user owns or does not own cards of each card ID. Even if the user owns cards, the display may be made so that it is clear whether the user owns all the cards or not all the cards. Furthermore, if the user does not own all the cards, the display may be made so that it is clear how many cards the user owns and how many cards the user will need to own. By displaying the information in this way, the user can check the current status of cards that the user should obtain. For example,
If the number of reference cards possessed is N and the number of reference cards that need to be possessed is M, information in the form of N/M may be displayed in association with each card.

(3-2) Modification 2
In this modified example, the output means 54 may output image data by displaying a card identified by a reference card ID that is included in at least two or more stages of combination conditions among the multiple reference card IDs included in each combination condition acquired by the acquisition means 53 in a display format different from that of a card identified by a card ID other than the overlapping card IDs.
In order to realize the function of the output means 54 of this modified example, the CPU 21 of the game server 20
When the pre-evolution card ID, the evolved card ID, and the reference card ID included in the combination conditions corresponding to the evolution ID in each evolution synthesis are obtained, the reference card IDs (duplicate reference card IDs) that are included in at least two or more stages of combination conditions are identified. Then, the pre-evolution card ID, the evolved card ID, and the reference card ID included in the combination conditions are identified.
The card data corresponding to the duplicate reference card I is read from the card data table.
Image data is generated so that D and reference card IDs that are not duplicate reference card IDs are displayed in different formats. An example of an image displayed based on the generated image data is shown in Fig. 15. Image P4c shown in Fig. 15 is an example of an image in which image P4 in Fig. 9 is displayed according to this modified example, and cards A01, C12, and M03 are cards corresponding to the duplicate reference card IDs.
In this configuration, cards with overlapping reference card IDs among multiple reference card IDs included in the combination conditions of the multiple stages of evolution synthesis for the card selected as the base card are presented to the user in different display formats. Therefore, the user can get an overview of all the cards required to evolve the selected card into different cards in sequence, and can easily recognize cards that should be obtained in large quantities.
Furthermore, the display may be made so that it is clear whether the user has a card with a card ID corresponding to the duplicate reference card ID. Even if the user has a card,
The display may be made so that it is clear whether the user possesses all the duplicate reference cards or not all the duplicate reference cards. If the user does not possess all the duplicate reference cards, the display may be made so that it is clear that the user possesses the number of duplicate reference cards and the number of duplicate reference cards that will need to be possessed. By displaying in this manner, the user can confirm the current possession status of cards that the user should obtain. For example, if the number of duplicate reference cards possessed is N and the number of duplicate reference cards that will need to be possessed is M, information in the form of N/M may be displayed in association with each card.

(3-3) Modification 3
In this modified example, the card ID is associated with information indicating the conditions for a user to obtain a card. The information indicating the conditions for obtaining a card may be, for example, the rarity or limited flag of the card as shown in FIG. 5, or a level according to the number of cards in circulation. Although not shown in FIG. 5, the level according to the number of cards in circulation is recorded in a card data table. The game server 20 periodically (for example, every day) counts the cards owned by all users registered in the game for each card ID, determines the level based on the counted value, and updates the value of the level in the card data table.
In this example, the output means 54 may output image data by displaying, among the multiple reference card IDs included in each combination condition acquired by the acquisition means 53, a card identified by a reference card ID whose acquisition conditions satisfy a specified condition in a display format different from that of a reference card identified by a reference card ID whose acquisition conditions do not satisfy the specified condition.
In order to realize the function of the output means 54 of this modified example, the CPU 21 of the game server 20
When the pre-evolution card ID, evolved card ID, and reference card ID included in the combination conditions corresponding to the evolution ID in each evolution synthesis are obtained, the card data corresponding to these card IDs are read from the card data table, and image data is generated to display the information indicating the acquisition conditions of the card separately. An example of an image displayed based on the generated image data is shown in FIG. 16. Image P4d shown in FIG. 16 is an example of an image that displays image P4 of FIG. 9 according to this modified example. In the example of image P4d, the information indicating the acquisition conditions of the card is rarity, and the rarity of the card is R5 as the predetermined condition. A reference card with a rarity of R5 is displayed in a different display format from reference cards with a rarity of R4 or less.
In this configuration, for example, if the acquisition condition is related to the difficulty of acquiring the card,
Since the difficulty of obtaining cards with multiple card IDs included in the combination conditions of the multi-stage evolution synthesis for a card selected as a base card is known, the user can determine to what stage the evolution synthesis for the selected card should be performed, taking into account the difficulty of obtaining the cards.
Furthermore, the display may be made to show whether the user owns or does not own cards that are considered to be difficult to obtain. Even if the user owns cards, the display may be made to show whether the user owns all the cards or does not own all the cards. If the user does not own all the cards, the display may show the number of cards owned and the number of cards that will need to be owned. By displaying in this way, the user can check the current ownership status of cards to be obtained. For example, if the number of reference cards owned is N and the number of reference cards that will need to be owned is M, information in the form of N/M may be displayed in association with each card.

(3-4) Modification 4
In this modified example, the receiving means 51 as the second receiving means receives, when the card selected as the base card is a card that can be evolved gradually to become a different card each time evolutionary synthesis is performed, specification of information regarding the number of evolutionary synthesis steps to be performed to gradually evolve the selected card to become a different card each time evolutionary synthesis is performed.
In addition, in this modified example, when the receiving means 51 receives information regarding the number of evolutionary synthesis, the acquisition means 53 acquires the combination conditions for performing that number of evolutionary synthesis on the card selected as the base card.
An example of a series of images displayed on the user terminal 10 in this modified example is shown in FIG.
When button b11 ("Confirm") is selected in image P3 (the same as image P3 in FIG. 8), the image changes to that shown in P10. In image P10, buttons b31 to b33 are provided as options for the number of evolutions of card Q01, selected as the base card. Selecting any of buttons b31 to b33 corresponds to selecting information regarding the number of evolution synthesis times.
In image P10, for example, when button b32 ("evolution to the second stage") is selected,
The image changes to as shown in P11. Image P11 displays the reference cards required to evolve card Q01 to the second stage, as specified by button b32.

In order to realize this modified example, when the CPU 11 of the user terminal 10 accepts an operation to specify information regarding the number of evolutionary synthesis (for example, a specification operation of one of buttons b31 to b33 in FIG. 17), the CPU 21 of the game server 20 transmits information regarding the number of evolutionary synthesis to the game server 20. When the CPU 21 of the game server 20 acquires information regarding the number of evolutionary synthesis from the user terminal 10, the CPU 21 acquires from the evolutionary synthesis data table the pre-evolutionary card ID, the post-evolutionary card ID, and the reference card ID included in the combination condition, which correspond to the evolutionary ID in each evolutionary synthesis of the card selected as the base card. Then, from the acquired information, the card ID corresponding to the information regarding the number of evolutionary synthesis specified by the user is extracted, and the card data corresponding to the extracted card ID is read from the card data table, and image data is generated for displaying each stage of evolution separately. An example of an image displayed based on the generated image data is the image P11 illustrated in FIG. 17.
In addition, the information that the CPU 21 obtains from the evolutionary synthesis data table does not have to correspond to all evolutions of the card selected as the base card up to its final evolution; it only needs to be information corresponding to the number of evolutionary synthesis events identified by the information regarding the number of evolutionary synthesis events.

In this configuration, the reference cards required for the evolutionary synthesis of the selected card are presented to the user according to the number of evolutionary synthesis times specified by the user. This allows the user to avoid situations that would be cumbersome for the user, such as when the types and number of reference cards required for all evolutionary synthesis of the selected card are very large and all of them are presented to the user. Since the user can specify the number of evolutionary synthesis times, for example, by specifying a relatively small number of times for evolutionary synthesis (e.g., 2 to 3 times), it is possible to extract and check only the reference cards that will be required for the selected card in the near future,
Alternatively, the user can check all reference cards required for the evolution synthesis of the selected card at once. In other words, the user's desired presentation mode can be realized depending on the user's designation.
Furthermore, the display may be made so that it is clear whether the user owns each card or not. Even if the user owns each card, it may be clear whether the user owns all the cards.
The display may be made so that it is clear whether all the cards are not possessed. In addition, if all the cards are not possessed, the number of cards possessed and the number of cards that need to be possessed may be displayed so that it is clear. By displaying in this way, the user can check the current possession status of cards that need to be obtained to perform the specified number of evolution synthesis. For example, if the number of reference cards possessed is N and the number of reference cards that need to be possessed is M, information in the form of N/M may be displayed in association with each card.

(3-5) Modification 5
In this modified example, when a card selected as a base card is a card that evolves over multiple stages, the user can reserve cards required for each stage of the card's evolution so that the user does not accidentally discard them. The reserved cards (hereinafter also referred to as "reserved cards") are restricted from being used in any process other than the evolution synthesis of the target card.
More specifically, in this modified example, the above-mentioned reception means 51 serves as a request reception means and receives a restriction request, which is a request based on a user operation in response to image data being output by the determination means 54, for restricting processing on at least one of the multiple cards.
In this modified example, when a restriction request is accepted by the accepting means 51, the modifying means 58 has a function of restricting cards identified as restricted cards that should be restricted from being used for processes other than evolutionary synthesis, among the cards owned by the user who requested the restriction request, from being used for processes other than evolutionary synthesis, based on multiple reference card IDs included in the combination conditions acquired by the acquiring means 53.

An example of a card reservation method of this modified example will be described with reference to image P4e in Fig. 18. Image P4e in Fig. 18 is a modified example of the display mode of image P4 in Fig. 9. In image P4e,
Reference cards required for each stage of evolution are displayed, and the status of the card corresponding to the displayed reference card is displayed. The status of the card may be "not possessed" indicating that the user does not possess the card, "reserved" indicating that the user possesses the card and has reserved the card, or "not reserved" indicating that the user possesses the card but has not reserved the card (in this case, the buttons b41 and b42 for reserving the card are not pressed).
("Make a reservation") or similar will be displayed.)
In image P4e, when either button b41 or b42 is designated, the state of the reference card corresponding to the button changes from "unreserved" to "reserved."

As an example of a case where a reserved card is used for a process other than the intended evolutionary synthesis, the process of selling a reserved card will be explained.
19 shows a series of changes in the display screen when the user executes a process for selling a reserved card. In FIG. 19, image P1 is the same as that shown in FIG.
When the button b5 ("Sell") is specified in the image P1, the image changes to P20. In the image P20, a list of cards owned by the user is displayed. The user selects a card that he/she wishes to sell from the list of cards owned in the image P20. At this time, if a reserved card is selected as the target for sale from among the cards owned, the image changes to P21. The image P21 includes text for notifying the user that the card selected by the user is a reserved card, and buttons b50 ("Continue") and b51 ("Back") for selecting whether or not to continue the selling process. When the button b50 is specified in the image P21, the selling process is performed even for a reserved card, and the user thereby gains points for the selling price corresponding to the card and loses the reserved card.

As shown in image P21, complicating the procedure for executing the selling process for reserved cards is one example of restricting reserved cards from being used for processes other than evolutionary synthesis.
19, the list of cards owned by the user may be displayed in a manner that makes reserved cards unselectable in the image P20. In other words, in order to more reliably prevent reserved cards from being used in processes other than evolution synthesis, the execution of a sale process for reserved cards may be prohibited.

In addition to the above-mentioned selling process, in the game of this embodiment, owned cards may be lost by executing a normal synthesis process. In the normal synthesis process, the user selects a base card from among the cards he or she owns as a card to be developed. In the normal synthesis process, the combination conditions of the reference card do not need to be determined for each base card, and the user can select an appropriate reference card from among the cards he or she owns. When the normal synthesis process is executed, the card parameters of the base card change (for example, the card level or skill level increases).
Instead, the reference card disappears from the user's possession. In the case of the normal synthesis process, similar to the above-mentioned selling process, if the reference card used in the normal synthesis is a reserved card when the normal synthesis is executed, the execution of the normal synthesis is restricted.

A method for implementing this modified example will now be described.
In this modified example, a reservation data table is provided in the storage 25 of the game server 20. The reservation data table is a data table for managing the reservation of cards for each evolution synthesis, an example of which is shown in FIG.
The reservation data table records information on reserved cards for evolution synthesis by the user. FIG. 20 shows an example of a reservation data table for one user. The reservation data table includes the following:
A reservation ID is provided for each user registered in the game. In FIG. 20, the reservation ID is an ID issued in the order in which reservations for evolutionary synthesis are made. The evolution ID corresponds to the evolution ID shown in the evolutionary synthesis data table, and is an ID that specifies the content of the evolutionary synthesis. Among the serial numbers of reserved cards, the serial number of the pre-evolution card is the serial number corresponding to the owned card selected by the user as the base card for evolutionary synthesis. Among the serial numbers of reserved cards, the C1 to C5 columns of the reference cards correspond respectively to the C1 to C5 columns that make up the combination conditions of the reference card ID in the evolutionary synthesis data table, and if the reference card corresponding to each column is a reserved card, the serial number of that card is recorded. If the reference card corresponding to each column has not been reserved, data indicating "no reservation" (for example, N
ULL) is recorded.
In the example of the reservation data table shown in Fig. 20, the example shown in image P4e of Fig. 18 is shown. That is, the evolution ID: 0033 corresponds to the evolution of card Q01 → R01, and the evolution ID
:0044 corresponds to the evolution of card R01 → S01, and evolution ID:0020 corresponds to card S01
Here, when the button b41 ("Reserve") is selected in the image P4e of FIG. 18, the CPU 21 of the game server 20
In place of the data indicating "no reservation", the serial number of the card K14 possessed by the user is written in the column for "2". At this time, the CPU 21 refers to the user's possessed card data table in order to obtain the serial number of the card K14.

When generating image data that is the basis of image P4e in Fig. 18, the CPU 21 of the game server 20 refers to the reservation data table and the owned card data table to determine the status of the user's owned cards. The CPU 21 refers to the reservation data table and determines that the reference card in which the serial number is written is in the "reserved" status, that the card in which the user owns but whose serial number is not written in the reservation data table is in the "unreserved" status, and that the card not owned by the user is in the "unowned" status.
Furthermore, the CPU 21 of the game server 20 performs the following process when restricting a reserved card. When a reserved card is selected as a card to be used in a process, the CPU 21 refers to the reservation data table to determine whether the process is an evolutionary synthesis corresponding to the reserved card (i.e., the desired evolutionary synthesis). In other words, the content of the evolutionary synthesis is specified by the evolution ID corresponding to the reserved card, so it is possible to determine whether the process is the desired evolutionary synthesis. If it is determined that the process is not the desired evolutionary synthesis, the CPU 21 generates data for an image (e.g., image P21 in FIG. 19) for warning the user, and transmits the data to the user terminal 10.

According to this modification, in response to a user's request, at least some or all of the reference cards required to evolve a card selected as a base card among the cards owned by the user are restricted from being used for processes other than the evolution synthesis of each stage of the selected card. This can reliably prevent the user from mistakenly using the reference cards required to evolve the selected card in the future for processes other than the evolution before the combination conditions are met.

(3-6) Modification 6
In this modified example, a registration means 59 is provided. The registration means 59 has a function of registering, as a favorite (bookmark), an instruction card selected from among the user's owned cards based on the user's operation when a card ID corresponding to the user's owned card is included among the multiple card IDs included in each combination condition acquired by the acquisition means 53 for the card selected as the base card. That is, in this modified example,
If a card necessary for future evolution of the card selected as the base card is included, the card can be registered as a favorite.

An example of a method for registering a card as a favorite in this modified example will be described with reference to Fig. 21. Image P4f in Fig. 21 is a modified example of the display mode of image P4 in Fig. 9. Image P4f displays reference cards required for each stage of evolution, and also displays the state of the card corresponding to the displayed reference card. The state of the card is either a "not possessed" state, which indicates that the user does not possess the card, or a "possessed" state, which indicates that the user possesses the card.
When one of the owned cards (in this example, K14) is selected in the image P4f, the selected card is displayed as a favorites registration target, as shown in the image P15. The image P15 includes a button b5 for registering the selected card as a favorites registration.
0 ("Register as favorites"). When the button b50 ("Register as favorites") is designated, the selected card (K14) is registered as a favorite of the user.
The method of distinguishing between the "possessed" and "not possessed" states is not limited to the method using text as shown in image P4f, but may be displayed so as to be distinguishable using images. For example, for a possessed card, a card image corresponding to the possessed card is displayed, and for a not possessed card, an image different from the card image corresponding to the not possessed card is displayed. The different image may be any image that is clearly different from the normal card image, for example,
It may be an image in which the brightness of a normal card image is darkened, such as a "?" mark, or the like.
In addition, when a card is selected in image P4f, the card may be immediately registered as the user's favorite without displaying image P15. In addition, in image P4f, the user may be prompted to select multiple cards, and then the selected multiple cards may be registered collectively by having the user press a confirm button.
Although not shown, when a file is registered as a favorite, the file is displayed in response to a user's request for viewing.
A list of the user's cards registered as favorites is displayed. In addition, in order to distinguish the favorite cards from the list of cards displayed when the button b1 ("View Owned Monsters") is specified in the image P1 of FIG. 8, the favorite cards may be displayed in a distinguishable manner from the cards not registered as favorites. For example, the favorite cards may be displayed with a mark indicating that the favorite cards are registered, so that the favorite cards can be displayed in a distinguishable manner from the cards not registered as favorites. Note that the favorite registration may not only be performed by marking the favorite cards, but also by restricting the process of removing the favorite cards from the list of favorite cards. This prevents the user from accidentally selling the favorite cards. Note that, in the same manner as described in the modified example 6, a reservation button may be provided for a desired card from the list of favorite cards, and the reservation button may be designated to make the card available for reservation.
To realize this modified example, a flag (1: registered as favorite, 0: not registered as favorite) may be set in the owned card data table (see FIG. 7) corresponding to the card ID of the owned card. When the CPU 21 of the game server 20 receives a request to view a card registered as a favorite, it reads out card data with a flag of "1" from the owned card data table, and generates image data including a list of cards based on the read card data.
According to this modification, if it is confirmed that the user has a card necessary for the future evolution of the card selected as the base card, the user can immediately register it as a favorite, so that the user can reliably mark the card he or she owns that is necessary for future evolution without relying on his or her own memory. Also, when the user has many cards, for example, the user can quickly check which cards are important to the user and are necessary for evolution.

(4) Application to Applications Other Than Games In the above-mentioned embodiment and modified example, the present invention has been described as being applied to games, but it may also be applied to other applications. For example, when 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 an object of the present invention. In this case, for example, in order to upgrade (an example of a change process) the benefits of coupon Q as a base coupon, a user may possess and use coupons A to C as reference coupons corresponding to coupon Q. In this example, it is assumed that coupon Q changes into a different coupon through a change process in multiple stages. At this time, the shopping server identifies a reference coupon required for each stage of evolution of coupon Q as a base coupon, generates image data for the user to present the reference coupon, and transmits the image data to the user terminal.
The present invention can also be applied to other applications besides the above-mentioned examples.

Although the embodiment and the modified examples of the present invention have been described in detail above, the present invention is not limited to the above-mentioned embodiment. Furthermore, the embodiment may of course be improved or modified in various ways without departing from the spirit of the present invention. The technical matters described in the above-mentioned embodiment and each modified example may be applied in appropriate combination.
The method of receiving the request is not limited to the above. For example, the method of receiving the request may be a method of receiving an instruction input by shaking a user terminal equipped with an acceleration sensor, or an instruction input by a gesture (gesture input). In the gesture input, a user makes a predetermined gesture on a user terminal equipped with an imaging function, and the user terminal recognizes the image of the gesture and recognizes an operation input previously associated with the gesture.
In addition, in the case of a user terminal capable of executing a voice recognition program, the request may be received by inputting a predetermined voice instruction.

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

According to one aspect of the present invention, there is provided an information processing device (10) that can access a storage device (25) that stores object identification information for identifying an object and a change condition for performing a change process that changes the object, the change condition including a plurality of object identification information, in association with each other.
Or 20)
a first receiving means (51) for receiving, based on an operation by a user, a designation of a selected object which is an object selected from among objects possessed by the user;
When the selected object is an object that can be changed stepwise so as to become a different object each time the change processing is performed, an acquisition means (25) acquires each change condition for performing each change processing of a plurality of steps on the selected object from the storage device (25).
53) and
an output means (54) for outputting output data (e.g., image data) for displaying a plurality of objects identified by a plurality of pieces of object identification information included in each of the change conditions acquired by the acquisition means (53) in a display format that allows each of the objects to be identified by the plurality of objects;
The information processing device is provided with:

The "information processing device" may be a stand-alone game machine, a user terminal (e.g., a mobile terminal, a personal computer, etc.), or a server on a network. The entity of the information processing device can be defined as appropriate depending on the implementation form of the game. For example, when the functions of each part of the information processing device are realized by a user operating a game machine or a user terminal, 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 images, and the functions of each part of the information processing device are realized by a server that can substantially communicate with the user terminal, the server corresponds to the information processing device of the present invention.
An "object" may be any display object as long as it is visually recognizable by the user, and may be set appropriately according to the processing content of the information processing device of the present invention. For example, when the information processing device of the present invention processes information related to a game, the object may include a character or an item in the game. A character is, for example, a virtual person, creature, or monster in the game, and includes those displayed on a card.
"Object identification information" refers to identification information that allows a user to identify an object, and information associated with that identification information. Examples of identification information that allows a user to identify an object include an object name and an object image. An object ID (e.g., a card ID if the object is a card) is also an example of "object identification information" as information associated with the object name and object image.
The "storage device" may be a memory device of any configuration, such as a flash memory, a hard disk drive (HDD), etc. The storage device may be built into the information processing device, or may be an external device that can be accessed from the information processing device via a wired or wireless connection.
"Possession" of an object means that the user is in a state where the object can be used for processing using that object. "Not possession" of an object means that the user is in a state where the object cannot be used for processing using that object. "Acquisition" of an object means that the user has moved from a state where the object is not possessed to a state where the object is possessed.

In the above information processing device, when the selected object selected by the user is an object that can be changed stepwise so as to become a different object each time a change process is performed, not only the change conditions necessary for one step of the change process of the selected object but also a plurality of objects identified by a plurality of object identification information included in the change conditions for a plurality of steps of change processes in the future are presented to the user. Therefore, the user can recognize in advance that the presented plurality of objects are objects necessary for the future change process of the selected object, and thus is prevented from accidentally releasing any of the presented plurality of objects.

The output means (54) may output the output data by displaying a plurality of objects identified by a plurality of object identification information included in each change condition acquired by the acquisition means (53) in a manner that distinguishes between the corresponding change conditions.
In this configuration, a plurality of objects included in the change conditions for the first stage change process, the second stage change process, ... are displayed for each change condition, so that the user can distinguish and recognize objects that will be required for the change process in the relatively near future from objects that will be required in the relatively distant future. Therefore, the user can select to use the objects that will be required in the relatively distant future for a process other than the change process, for example, for another purpose.

The information processing device may further include a registration means (59) for registering a possessed object selected based on the user's operation from among the possessed objects when object identification information corresponding to an object possessed by the user is included among the multiple object identification information included in each change condition acquired by the acquisition means.
In this configuration, the user can register possessed objects necessary for future change processing of the selected object, so that, for example, when the user possesses a large number of objects, the user can quickly check objects that are important to the user and will be required for change processing.

a request receiving means (51) for receiving a request based on an operation by the user in response to the output of the output data by the output means (54), the request being for restricting processing of at least any one of the plurality of objects;
When the request is accepted by the request accepting means (51), the acquiring means (53
The method may further comprise a restriction means (58) for restricting, based on a plurality of object identification information included in the change conditions obtained by the change condition obtaining means, an object identified as a restricted object that should be restricted from being used for processes other than the change process, among the objects possessed by the requesting user, from being used for processes other than the change process.
"Restricting use for processes other than the change process" does not necessarily mean that processes other than the change process of the selected object are prohibited, but may mean that the change process of the selected object can be executed, but the procedure for executing the change process is made difficult or the procedure for executing the change process is made complicated. In the above-mentioned embodiment, the restriction on use for processes other than the change process of the object is realized by reserving the object. For example, in the above embodiment, a "reserved card" is restricted from being used for processes other than evolution reservations aimed at cards.
In the above configuration, in response to a request from a user, at least some or all of the objects possessed by the user that are necessary to change a selected object are restricted from being used for processing other than the processing for changing the selected object.
This can reliably prevent a user from erroneously using an object required for changing a selected object for a process other than the process for changing the selected object before a change condition is satisfied.

The output means (54) may output the output data by displaying a plurality of objects identified by a plurality of object identification information included in each change condition acquired by the acquisition means (53) in a manner distinguishing each object identification information.
In this configuration, the multiple objects included in each change condition are presented to the user with different object identification information, so the user can quantitatively recognize how many of each object are required. Therefore, the user can get an overview of all the objects required to change the selected object into different objects in sequence.
In addition, the number of types of objects that should be obtained can be easily recognized.

The output means (54) may output the output data by displaying, in a display format different from that of objects identified by object identification information that is included in duplicate in at least two or more stages of change conditions among the multiple object identification information included in each change condition acquired by the acquisition means (53), from objects identified by object identification information other than the duplicated object identification information.
In this configuration, objects with overlapping object identification information among a plurality of object identification information included in the change conditions of the multi-stage change process for the selected object are presented to the user in different display formats, so that the user can get an overview of all the objects required to change the selected object to different objects in sequence, and can easily recognize objects that should be obtained in large quantities.

The object identification information is associated with information indicating a condition under which the object may be obtained by the user;
The output means (54) displays, among the plurality of object identification information included in each change condition acquired by the acquisition means (53), an object identified by object identification information whose acquisition condition satisfies a predetermined condition in a display format different from that of an object identified by object identification information whose acquisition condition does not satisfy the predetermined condition,
The output data may be output.
In this configuration, for example, if the acquisition condition is a condition related to the difficulty of obtaining an object, the difficulty of obtaining objects of the multiple object identification information included in the change conditions of the multiple stages of change processing for the selected object is known, so the user can determine to what stage the change processing for the selected object should be performed, taking into account the difficulty of acquisition.

a second receiving means (51) for receiving, in the case where the selected object is an object that can be changed stepwise so as to become a different object each time the change process is performed, designation of information regarding the number of times the change process is performed to change the selected object stepwise so as to become a different object each time the change process is performed,
When the second receiving means (51) receives designation of information regarding the number of times of the change processing, the acquisition means (53) may acquire each change condition for performing the change processing of the selected object that number of times.
In this configuration, the objects required for the change processing of the selected object are presented to the user according to the number of times of the multiple-stage change processing specified by the user. Therefore, the user can avoid a situation where the types and number of objects required for all the change processing of the selected object are very large and all of them are presented to the user, which may be cumbersome for the user. Since the user can specify the number of times of the multiple-stage change processing, for example, by specifying a relatively small number of times (for example, 2 to 3 times) for the change processing, the user can extract and confirm only the objects that will be required for the selected object in the near future, or can confirm all the objects required for all the change processing of the selected object at once. In other words, the presentation mode desired by the user can be realized depending on the user's specification.

Another aspect of the present invention is an information processing system (1) including a user terminal (10) and a server (20) configured to be able to communicate with the user terminal (10),
10) and a storage device (25) in which at least one of the server (20) and the server (20) stores object identification information for identifying an object and a change condition for performing a change process for changing the object, the change condition including a plurality of object identification information, in association with each other.
In the information processing system,
a first receiving means (51) for receiving, based on an operation by a user, a designation of a selected object which is an object selected from among objects possessed by the user;
When the selected object is an object that can be changed stepwise so as to become a different object each time the change processing is performed, an acquisition means (25) acquires each change condition for performing each change processing of a plurality of steps on the selected object from the storage device (25).
53),
an output means (54) for outputting output data for displaying a plurality of objects identified by a plurality of pieces of object identification information included in each of the change conditions acquired by the acquisition means (53) in a display format that allows each of the objects to be identified by the plurality of object identification information.
At least one of the user terminal (10) and the server (20) is provided with
It is an information processing system.

Another aspect of the present invention is a method for storing object identification information for identifying an object and a change condition for performing a change process for changing the object, the change condition including a plurality of object identification information, in a storage device (25) that is accessible to the computer,
a first receiving means (51) for receiving, based on an operation by a user, a designation of a selected object which is an object selected from among objects possessed by the user;
When the selected object is an object that can be changed stepwise so as to become a different object each time the change processing is performed, an acquisition means (25) acquires each change condition for performing each change processing of a plurality of steps on the selected object from the storage device (25).
53),
an output means (54) for outputting output data for displaying a plurality of objects identified by a plurality of pieces of object identification information included in each of the change conditions acquired by the acquisition means (53) in a display format that allows each of the objects to be identified by the plurality of object identification information.
This is a program that functions as a

Another aspect of the present invention may be a computer-readable storage medium, such as an optical disk or a magnetic disk, that stores the above program.

In the above, in order to facilitate understanding of the present invention, the symbols shown in the drawings are written in parentheses as appropriate, but this does not mean that the information processing device etc. related to the present invention is limited to the form shown in the drawings.

1... Game system 10... User terminal 11... CPU
12...ROM
13...RAM
Reference Signs List 15: Operation input unit 16: Display unit 17: Communication interface unit 18: Storage 19: Bus 20: Game server 21: CPU
22...ROM
23...RAM
24: Communication interface unit 25: Storage 26: Bus 51: Acceptance means 52: Game execution means 53: Acquisition means 54: Output means 55: Determination means 56: Change means 57: Recording means 58: Restriction means 59: Registration means 70: Data table group

Claims (4)

A processor is provided.
A program for an information processing device for carrying out a change process for gradually changing an object into a different object, comprising:
The processor,
functioning as a first receiving means for receiving, based on an operation by a user, a designation of a selected object which is an object selected from among objects possessed by the user;
functioning as a second receiving means for receiving designation of information regarding the change process for the selected object, the designation of which has been received by the first receiving means;
when the second receiving means receives the designation of information related to the change processing, the change processing is performed on the selected object a number of times determined based on the designation of information related to the change processing , the change condition being associated with object identification information that identifies the object and including a plurality of pieces of object identification information;
and functioning as an output means for outputting output data for displaying a plurality of objects specified by a plurality of object identification information included in the change condition acquired by the acquisition means in a display format that allows each of the objects to be identified by the plurality of object identification information.
A program for an information processing device.
the output means outputs the output data by displaying information regarding possession of the user for a plurality of objects identified by a plurality of object identification information included in the change condition acquired by the acquisition means.
A program for the information processing device according to claim 1.
An information processing system for carrying out a change process for gradually changing an object to a different object in sequence, using an information processing device that can access a server, comprising:
The information processing device includes:
a first receiving means for receiving a designation of a selected object which is an object selected from among the objects possessed by the user based on an operation by the user;
a second receiving means for receiving designation of information related to the change process for the selected object, the designation of which has been received by the first receiving means;
an acquisition means for acquiring, when the second acceptance means accepts the designation of information related to the change process, a change condition for performing the change process on the selected object a number of times determined based on the designation of information related to the change process , the change condition being associated with object identification information for identifying an object and including a plurality of pieces of object identification information;
an output means for outputting output data for displaying a plurality of objects specified by a plurality of pieces of object identification information included in the change condition acquired by the acquisition means in a display format that allows each of the objects to be identified by the plurality of pieces of object identification information by a user;
An information processing system comprising:
A processor is provided.
1. A method for outputting output data of an information processing device for carrying out a change process for gradually changing an object into a different object, comprising the steps of:
accepting, based on a user's operation, a designation of a selected object which is an object selected from among the objects possessed by the user;
accepting a designation of information regarding the change process for the selected object whose designation has been accepted;
When the designation of the information regarding the change processing is accepted, a change condition for performing the change processing on the selected object a number of times determined based on the designation of the information regarding the change processing is acquired, the change condition being associated with object identification information for identifying the object and including a plurality of pieces of object identification information;
outputting output data for displaying a plurality of objects identified by a plurality of pieces of object identification information included in the acquired change condition in a display format that allows each of the objects to be identified by a user;
A method for outputting output data of an information processing device.

Images