JP2017200608A - Information processing device, information processing system, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce the possibility that an object possessed by a user is used for processing other than a use purpose of the object desired by the user and is dissipated.SOLUTION: An information processing device that can access a storage device for associating and storing object identification information and a change condition including a plurality of pieces of the object identification information includes: first reception means for receiving the designation of a selection object from objects possessed by a user based on user operation; acquisition means for acquiring from the storage device each change condition for executing each change processing of a plurality of stages for the selection object, when the selection object is the object that can change in stages so that the selection object becomes different objects sequentially each time change processing is executed; and output means for outputting output data for causing a plurality of objects specified by the plurality of pieces of the object identification information included in each change condition acquired by the acquisition means to be displayed in a form that can be identified by the user respectively.SELECTED DRAWING: Figure 11

Description

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

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

Japanese Patent No. 5086491 Japanese Patent No. 5153960

  In the compositing process, in order to realize the compositing process of the base object (base object; corresponding to the main card), a plurality of objects (reference object; corresponding to the sub card) satisfying the combination condition corresponding to the base object are selected. It may be a requirement that the user possesses it. In this case, there is also known a game having a mechanism in which a reference object necessary for executing a composition process on an object selected as a base object is presented to the user. However, in that case, only the reference object necessary for executing the latest synthesis process on the selected card is presented to the user, and the synthesis process is further executed after the execution of the latest synthesis process. Therefore, the user cannot know the reference object necessary for the purpose (that is, the reference object necessary for future composition processing). For this reason, for example, in a game in which an object changes (evolves) sequentially to a different object each time a composition process is performed, the reference object that is required in the process of evolution is currently possessed. There was a situation that let go. In such a case, in the future compositing process, the user must obtain again the object that has been released in the past, and will regret later that he has released it.

  The present invention has been made in view of the above-described viewpoints, and the object of the present invention is to use an object possessed by the user for processing other than the intended use of the object desired by the user and to be lost. Information processing apparatus, information processing system, and program can be provided.

According to one embodiment of the present invention, a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information in association with a change process that changes the object An information processing apparatus that can access
First receiving means for receiving designation of a selected object that is an object selected from possessed objects possessed by the user based on a user operation;
In the case where the selected object is an object that can be changed in stages so as to be sequentially different objects each time the change process is performed, each change condition for performing each change process in a plurality of stages with respect to the selected object, Obtaining means for obtaining from the storage device;
Output means for outputting output data for displaying a plurality of objects specified by a plurality of object identification information included in each change condition acquired by the acquisition means in a display format that can be identified by the user;
Is an information processing apparatus.

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 identifies an object. In the information processing system capable of accessing a storage device that associates and stores object identification information and a change condition that includes a plurality of object identification information that is a condition for performing change processing that changes the object,
First accepting means for accepting designation of a selected object that is an object selected from possessed objects possessed by the user based on a user operation;
In the case where the selected object is an object that can be changed in stages so as to be sequentially different objects each time the change process is performed, each change condition for performing each change process in a plurality of stages with respect to the selected object, Obtaining means for obtaining from the storage device;
Output means for outputting output data for displaying a plurality of objects specified by a plurality of object identification information included in each change condition acquired by the acquisition means in a display format identifiable to the user,
Is an information processing system provided with at least one of the user terminal and the server.

Another aspect of the present invention is a memory for storing object identification information for identifying an object and a condition for performing a change process for changing the object, which includes a plurality of object identification information in association with each other. To a computer accessible to the device,
First accepting means for accepting designation of a selected object that is an object selected from possessed objects possessed by the user based on a user operation;
In the case where the selected object is an object that can be changed in stages so as to be sequentially different objects each time the change process is performed, each change condition for performing each change process in a plurality of stages with respect to the selected object, Obtaining means for obtaining from the storage device;
Output means for outputting output data for displaying a plurality of objects specified by a plurality of object identification information included in each change condition acquired by the acquisition means in a display format identifiable to the user,
It is a program to make it function as.

The figure which shows the basic composition of the game system of 1st Embodiment. The block diagram which shows the structure of the user terminal of 1st Embodiment. The block diagram which shows the structure of the game server of 1st Embodiment. The figure for demonstrating conceptually the notification to the user of the card | curd required for evolutionary synthesis. The figure which shows the structural example of a card data table. The figure which shows the structural example of an evolution synthetic | combination data table. The figure which shows the structural example of a possession card data table. The figure which shows an example of the image displayed on a user terminal in 1st Embodiment. The figure which shows an example of the image displayed on a user terminal in 1st Embodiment. The figure which shows an example of the image displayed on a user terminal in 1st Embodiment. The functional block diagram of the game server of 1st Embodiment. The sequence chart which shows an example of the confirmation process of evolutionary synthesis. The sequence chart which shows an example of the confirmation process of evolutionary synthesis. The sequence chart which shows an example of the execution process of evolutionary synthesis. The figure which shows an example of the image displayed on a user terminal in the modification of embodiment. The figure which shows an example of the image displayed on a user terminal in the modification of embodiment. The figure which shows an example of the image displayed on a user terminal in the modification of embodiment. The figure which shows an example of the image displayed on a user terminal in the modification of embodiment. The figure which shows an example of the image displayed on a user terminal in the modification of embodiment. The figure which shows an example of the image displayed on a user terminal in the modification of embodiment. The figure which shows the structural example of a reservation data table. The figure which shows an example of the image displayed on a user terminal in the modification of embodiment.

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

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

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

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

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

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

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

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

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

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

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

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

  For example, the storage 25 stores a program for providing a web service by performing communication according to HTTP with a web browser of the user terminal 10 as a client. The CPU 21 expands the program stored in the storage 25 on the RAM 23 and executes the program. Along with the execution of the program, the CPU 21 acquires an HTTP request from the user terminal 10 via the communication interface unit 24, executes a process according to the HTTP request, and uses the HTML data including the execution result as an HTTP response. Return to 10.

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

(1-4) Card Presentation Required for Card Evolution Synthesis The game executed in the game system 1 of the present embodiment is a game in which a user uses a card as an object. The type of the game in the present embodiment is not particularly limited. For example, the user searches for an area on the game to acquire a card or an item, or another user or NPC (Non-Player) using a card possessed by the user. This is a game against (Character)
In the following description, “owning” a card means that the user can use the card for processing using the card. “Not possessed” of a card means that the user cannot use the card for processing using the card. “Acquisition” of a card means that the card has shifted from an unowned state to a possessed state.
In the game of the present embodiment, the card evolution synthesis process (hereinafter simply referred to as “evolution synthesis” or “evolution” as appropriate) is a process for evolving a card possessed by a user when a predetermined condition is satisfied. is there. The evolution synthesis of the card is a process of changing the card ID as described later in the example of the present embodiment, but may be a process of changing at least a part of card data (described later) corresponding to the card. In this case, the change target of the card data is not particularly limited, but for example, card parameters such as a card name, a card image, and rarity. Card evolution synthesis is an example of object change processing.
In order to execute evolutionary synthesis, the user selects a card that the user wants to evolve as a base card from among the cards that the user possesses (hereinafter referred to as “owned card” as appropriate). The card selected as the base card is an example of the selected object.
In evolutionary synthesis, for each card ID of a base card, a combination condition (an example of a change condition) of card IDs of a plurality of cards (referred to as “reference cards”) necessary to evolve the base card is determined. . When evolutionary synthesis is performed, the reference card used for evolutionary synthesis disappears from the user's possession card.
In the present embodiment, the possessed card and the reference card are examples of the possessed object and the reference object, respectively.
In the game of the present embodiment, the fact that the user possesses a plurality of reference cards included in the combination condition corresponding to the card selected as the base card by the user is a condition for evolving the selected card. .

The card presentation required for the evolutionary synthesis of cards will be specifically described with reference to FIG. FIG. 4 is a diagram for conceptually explaining card presentation necessary for card evolution synthesis.
In FIG. 4, it is assumed that the user possesses cards A, D, G, Q1, M2,... And wants to evolve card Q1. In this example, it is assumed that the card Q1 is an object that can be sequentially changed to different cards (Q1 → Q2 → Q3) every time evolutionary 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 and card F. , Card G and card H.

  In the present embodiment, not only the reference cards (card A, card B, and card C) necessary for the card Q1 selected as the base card, but also the cards (cards required when the card Q1 sequentially evolves into different cards ( Cards A, B, C, E, F, G, H) are presented to the user. Therefore, the user is a card necessary for the future evolution synthesis of the card Q1, which is the card selected as the base card, the presented cards (cards A, B, C, E, F, G, H). Therefore, it is possible to prevent the plurality of presented cards from being accidentally released. For example, if only the cards (card A, card B, and card C) necessary for one evolutionary synthesis of the card Q1 selected as the base card in FIG. 4 are presented to the user, the user possessed card G However, there is a possibility that the user will give up (for example, dispose of) the card G even though the card is necessary for the future evolution of the card Q1 (in this example, the evolution of the card Q2 → Q3). On the other hand, in the present embodiment, the cards (cards A, B, C, E, F, G, and H) required when the card Q1 selected as the base card evolves sequentially into different cards are the users. Therefore, for example, a situation where the user releases the card G by mistake is avoided.

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

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

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

(Iii) Possession card data table The possession card data table records information on the possession card of the user. FIG. 7 shows a configuration example of the possessed card data table. Although FIG. 7 illustrates the possession card data table for one user, the possession card data table is provided for each user registered in the game.
In the possessed card data table shown in FIG. 7, serial number, card level, and skill level data are recorded in association with each card ID. The serial number is a unique number determined when the card is given to the user. Different serial numbers are assigned to cards having the same card ID. When the card has evolved, the serial number may or may not be changed before and after the evolution of the card.
The card level is a parameter indicating a card growth level, and is increased, for example, by executing normal synthesis. The value (initial value) of the card level at the time when the user obtains the card is 1, and the user can grow the card (that is, increase the card level) by executing normal synthesis.
The skill level is a parameter indicating a card development level, and particularly a parameter indicating a skill level of the card. The skill level (initial value) at the time when the user obtains a skill-equipped card is 1, and the skill level of the card is increased by performing normal synthesis using, for example, a card satisfying a predetermined condition as a reference card. Can be made. As the skill level of the card increases, the effect generated by the skill increases.

  In the following description, the card name, card image, serial number, and card parameters associated with the card ID 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. That is, any of the data in the card name, card image, serial number, and each card parameter corresponds to the card data. Each of the card ID, the card name, and the card image is an example of object identification information.

(1-6) Specific Example of Processing Related to Evolutionary Synthesis of Cards A specific example of processing related to evolutionary synthesis of cards in the game according to the present embodiment will be described below with reference to FIGS. FIGS. 8-10 is a figure which shows an example of the screen displayed on the user terminal 10 when performing the process of the game of this embodiment, respectively.

FIG. 8 shows a series of display screen changes when processing related to evolutionary synthesis of a user's possessed card is executed. In FIG. 8, an image P1 is an image including the main menu of the game of the present embodiment. In the image P1, as the operation target of the user, the button b1 (“see the possessed monster”), the button b2 (“team organization”), the button b3 (“normal composition”), the button b4 (“evolution composition”), b5 ("sale") is provided.
The button b1 is a button that is designated when a request for browsing processing of the user's possessed card is made. The button b2 is a button that is designated when the user selects a card to be used in a battle with another user or NPC from among his / her possessed cards. The button b3 is a button that is designated when a request for executing normal synthesis of a card selected as a base card from the possessed cards is made. The button b4 is a button that is designated when making a request for the evolution synthesis process of the card selected as the base card from the possessed cards by the user. The button b5 is a button that is designated when making a sale processing request to a card selected from the possessed cards by the user.

When the button b4 ("evolutionary synthesis") is designated in the image P1, the image changes as shown in P2. In the image P2, a plurality of possession cards are displayed in a list in order to select one of the possession cards of the user as a base card. 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.
For example, when the card Q01 is selected in the image P2, the image changes as shown in P3. The image P3 includes a button b11 (“Confirm”) for confirming a reference card required at each stage of evolution of the selected card Q01, together with text indicating that the card Q01 has been selected as a base card. , A button b12 ("reselect card") for returning to the image P2 and reselecting the possession card to be used as the base card is included. When the button b11 (“Confirm”) is designated, the image changes as shown in P4 (FIG. 9).

  In the image P4 in FIG. 9, the first stage evolution (card Q01 → R01) of the card Q01 selected as the base card by the user, the reference cards (cards A01, B03, C12) necessary for the evolution, and the second stage Evolution (card R01 → S01) and reference cards necessary for the evolution (cards A01, K14, M03, R05), final evolution (card S01 → T01) and reference cards necessary for the evolution (cards M03, C12) is displayed. That is, a plurality of reference cards included in each combination condition for performing a plurality of stages of evolutionary synthesis on the card Q01 selected as the base card is displayed in a display format that can be identified by the user. The final stage of evolution is also called “final evolution”. In addition, in each figure after FIG. 9, the display of the card image of a reference card is abbreviate | omitted suitably.

When the user possesses all the cards A01, B03, and C12 (that is, the reference cards for evolving the card Q01) included in the first-stage evolution / combination combination condition of the card Q01 (when the cards are ready) ), An image P4a in FIG. 10 is displayed instead of the image P4 in FIG.
In the image P4a, a text notifying the user that all the cards for executing the first stage of evolutionary synthesis are available ("all are ready") and requesting that the evolutionary synthesis of the first stage be executed. Button b21 ("evolve"). When the button b21 is designated in the image P4a, the image changes as shown in P5. That is, evolution synthesis from the card Q01 to the card R01 is executed, and the card image and card name of the post-evolution card and at least a part of the parameters are displayed as shown in the image P5. When the first-stage evolutionary synthesis is executed, the cards A01, B03, and C12, which are evolution synthesis reference cards, disappear from the user's possession card.

(1-7) Overview of Functions Provided by Information Processing Device Next, functions provided by the game server 20 in order to realize the above-described game of the present embodiment will be described. FIG. 11 is a functional block diagram for explaining functions that play major roles in the game server 20 of the present embodiment. In FIG. 11, the data table group 70 includes a card data table, an evolutionary 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, it is only necessary to include the reception unit 51, the acquisition unit 53, and the output unit 54. In addition, the recording unit 57, the limiting unit 58, and the registration unit 59 are referred to in the modification.

The accepting unit 51 has a function of accepting various requests from the user based on information related to the user's operation input. As a request from the user in the game of the present embodiment, there are, for example, a request for evolutionary synthesis processing of a card, a request for execution of evolutionary synthesis, a request for execution of normal synthesis, and a request for sale processing.
In addition, the accepting unit 51 has a function of accepting designation of a card selected as a base card from possession cards possessed by the user based on information related to the user's operation input as the first accepting unit.
In order to realize the function of the accepting unit 51, the game server 20 uses the communication interface unit 24 as a request corresponding to a button operation input by the user in the web page as an image from the user terminal 10 or as a base card. Receive information (eg, serial number) of the selected card. The CPU 21 of the game server 20 determines the content of the request based on the information included in the received request and performs a request acceptance process. In the reception process, the request is recorded in the RAM 13. The CPU 21 sequentially executes processes corresponding to the accepted requests. Further, the CPU 21 records the received serial number of the card in the RAM 23.

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

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

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

If the card selected as the base card (an example of the selected object) is a card that can be evolved step by step so that it becomes a different card each time evolution synthesis is performed, It has a function of acquiring each combination condition for performing each of the multiple stages of evolutionary synthesis from the evolutionary synthesis data table.
The function of the acquisition means 53 is realizable when CPU21 of the game server 20 performs the following procedures.
(Procedure 1) The card ID corresponding to the serial number of the card selected as the base card is specified with reference to the possessed card data table.
(Procedure 2) In the evolutionary synthesis data table, the evolution ID in which the same “pre-evolution card ID” as the card ID identified in the procedure 1 is recorded is identified. Then, the “evolved card ID” corresponding to the specified evolution ID and the reference card ID included in the combination condition are read.
(Procedure 3) The evolution ID in which the same “before evolution card ID” as the read “after evolution card ID” is recorded is specified. Then, the “evolved card ID” corresponding to the specified evolution ID and the reference card ID included in the combination condition are read. Thereafter, the procedure 3 is repeated until the evolution ID cannot be specified.

The output means 54 displays image data for displaying a plurality of cards specified by card IDs of a plurality of reference cards included in each combination condition acquired by the acquiring means 53 in a display format that can be identified by the user ( A function of outputting an example of output data.
In order to realize the function of the output means 54, the CPU 21 of the game server 20 corresponds to the evolution ID in each evolutionary synthesis when the user's possession card selected as the base card evolves sequentially every time evolutionary synthesis is performed. When the pre-evolution card ID, the post-evolution card ID, and the reference card ID included in the combination condition are acquired, card data (for example, card name, card image, etc.) corresponding to these card IDs is read 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 the image data to the user terminal 10. An example of an image displayed on the user terminal 10 based on this image data is an image P4 in FIG.

The determination unit 55 has a function of determining whether or not a condition that a plurality of reference cards, which are combination conditions corresponding to the card selected as the base card, are included in the user's possessed card is satisfied.
In order to realize the function of the determination means 55, for example, the CPU 21 of the game server 20 selects a card specified by a plurality of reference card IDs included in the combination condition corresponding to the card ID of the card selected as the base card. Is determined by referring to the possession card data table.

The changing unit 56 has a function of executing evolutionary synthesis for changing the card data of the base card when the determining unit 55 determines that the condition is satisfied. Evolutionary synthesis is an example of change processing of a card as an object.
In the example of this embodiment, in order to realize the function of the changing means 56, when the CPU 21 of the game server 20 accepts the evolution synthesis execution request, the pre-evolution card (that is, the base of evolution synthesis) is received in the possessed card data table. Card) data and erased card data is newly written. Thereby, the base card of the user's possession card will evolve. As shown in the evolution synthesis data table, since the card ID is different before and after evolution, at least one of the card name, the card image, and the card parameter is changed by evolution synthesis.

(1-8) Evolutionary Synthesis Process Flow in Game of the Present Embodiment Next, an example of the evolutionary synthesis process flow in the game of the present embodiment will be described with reference to the sequence charts of FIGS. 12A, 12B, and 13. explain. 12A and 12B are sequence charts showing an example of the confirmation process of evolutionary synthesis. FIG. 13 is a sequence chart showing an example of execution processing of evolutionary synthesis. In each figure, the reference numerals of the respective images are attached to the processing timing at which the respective images shown in FIGS. 8 to 10 are displayed.

(A) Confirmation process of evolutionary synthesis (FIGS. 12A and 12B)
When the button b4 ("evolutionary synthesis") is specified in the main menu (see FIG. 8) of the game of the present embodiment, the CPU 11 of the user terminal 10 receives a request for evolutionary synthesis processing (S10), and the request is sent to the game. It transmits to the server 20 (S12). When the CPU 21 of the game server 20 receives the request for the evolution synthesis process from the user terminal 10, the CPU 21 identifies the card ID of the user's possession card from the possession card data table, and possesses it from the card data table and possession card data table. The card data of the card is read, image data including a list of possessed cards is generated (S14), and the image data is transmitted to the user terminal 10 (S16). When acquiring the image data received in S16, the CPU 11 of the user terminal 10 displays an image (for example, the image P2 in FIG. 8) on the display unit 16 based on the image data (S18). In S14, the CPU 21 of the game server 20 can evolve each possessed card of the user by determining whether or not the card ID of each possessed card of the user is recorded in the evolved synthesis data table as the pre-evolution card ID. It is preferable that the image data is generated in a display format that allows the user to recognize that the possession card that cannot be evolved is determined as a base card and that it cannot be selected as a base card.

The image displayed in S18 includes the images and names of the user's possessed cards arranged as illustrated in the image P2 of FIG. 8, and the serial number of each card is selected by selecting the image of each card. It is configured to be selectable. When an operation for selecting one of the possessed cards displayed in S18 as a base card is performed, the CPU 11 of the user terminal 10 receives a selection result (serial number) of the base card (S20), The selection result is transmitted to the game server 20 (S22). Based on the received selection result of the base card, the CPU 21 of the game server 20 generates confirmation image data for confirming the selection result of the base card (S24), and transmits the image data to the user terminal 10 ( S26). When acquiring the image data received in S26, the CPU 11 of the user terminal 10 displays an image (for example, the image P3 in FIG. 8) on the display unit 16 based on the image data (S28).
The image displayed in S28 is provided with buttons (b11, b12) for confirming the selection result of the base card as exemplified in the image P3 of FIG. The CPU 11 of the user terminal 10 receives a response as to whether or not to confirm the selection result of the base card transmitted in S 22 based on the operation of the button by the user, and transmits the response to the game server 20. Here, it is assumed that the CPU 11 accepts a response (base card confirmation response) for confirming the selection result of the base card transmitted in S22 and transmits the confirmation response to the game server 20 (S30).
When acquiring the base card confirmation response, the CPU 21 of the game server 20 refers to the possessed card data table based on the serial number of the card selected as the base card, and specifies the card ID of the selected card (S32). ).

Next, the CPU 21 determines whether or not an evolution ID in which the same “pre-evolution card ID” as the card ID identified in S32 is recorded in the evolutionary synthesis data table is identified (S34). When the evolution ID is specified (S34: YES), the CPU 21 reads the post-evolution card ID corresponding to the specified evolution ID and the reference card ID included in the combination condition (S36). If 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 evolveable card. Therefore, the evolution ID is always specified in S34.
Next, the CPU 21 determines whether or not an evolution ID in which the same pre-evolution card ID as the post-evolution card ID read in S36 is recorded is specified (S38). When the evolution ID is specified (S38: YES), the process returns to S36, and the post-evolution card ID corresponding to the evolution ID specified in S38 and the reference card ID included in the combination condition are read. The CPU 21 repeats the processes of S36 and S38 until the evolution ID is no longer specified, whereby each combination condition for performing evolutionary synthesis at each stage a plurality of times on the possessed card selected as the base card (that is, , A reference card ID required for each evolution) is read out. Note that the processing flow in the present embodiment is described by a method using the “pre-evolution card ID” and the “post-evolution card ID” in the evolutionary synthesis data table, but is not limited to this method. For example, the evolution synthesis data table defines the evolution of all stages for each card ID and the reference card ID necessary for the evolution, and performs evolution synthesis at each stage multiple times for the possessed card selected as the base card. A method of reading each combination condition for performing may be used. Other methods may also be used. In other words, any method may be used as long as each combination condition for performing evolutionary synthesis at each stage a plurality of times is read from the possessed card selected as the base card.

  When the evolution ID is no longer specified (S38: NO), the CPU 21 proceeds to S40. In S40, it is checked by referring to the possessed card data table whether the user possesses all the cards identified by the reference card ID included in the combination condition corresponding to the evolution ID identified in S34 (S40). That is, it is confirmed whether the user has all the reference cards necessary for evolving the card selected as the base card by the user.

Next, the CPU 21 generates image data to be presented to the user based on the post-evolution card ID and reference card ID in each evolution read in S36 and the confirmation result in S40 (S42). Is transmitted to the user terminal 10 (S44). When acquiring the image data received in S44, the CPU 11 of the user terminal 10 displays an image on the display unit 16 based on the image data (S46). When it is confirmed that the user has all the reference cards necessary for evolving the card selected as the base card in S40, for example, as illustrated in the image P4a in FIG. 10, the base card is selected. When an image including a button for evolving the selected card is displayed and not confirmed, an image not including a button for evolving the card selected as the base card is displayed as illustrated in the image P4 of FIG. Is displayed. In addition to the user having all the reference cards, in order to evolve the card when it is confirmed that other conditions are satisfied (for example, the base card has reached the maximum level) An image including the button may be displayed. That is, the condition for evolving the selected card may be that the card selected as the base card has reached the maximum level and the user possesses all the reference cards. In any case, the generated image data is an image for displaying a plurality of cards specified by card IDs of a plurality of reference cards included in each evolutionary combination condition in a display format that can be identified by the user. It is data.
If the evolution ID is not specified in S34 (S34: NO), it means that the card selected as the base card by the user is a card that cannot be evolved. Therefore, the image data generated in S42 is, for example, “ This is data for displaying an image (not shown) including text such as “the selected card cannot be evolved”.

(B) Evolutionary synthesis execution process (FIG. 13)
The sequence chart shown in FIG. 13 is a process performed 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 the image P4a of FIG. The flow is shown. For example, the image P4a in FIG. 10 is provided with a button b21 (“evolve”) for confirming whether or not to make an evolution synthesis execution request. In FIG. 13, when the CPU 11 of the user terminal 10 receives an evolution synthesis execution request based on the user's operation specifying this button (S50), the request is transmitted to the game server 20 (S52).

When the CPU 21 of the game server 20 receives the evolution synthesis execution request received from the user terminal 10, the card data of the pre-evolution card (that is, the evolution synthesis base card) is deleted from the possessed card data table (S54). The card data of the post-evolution card is newly written (S56). At this time, the card data includes, for example, a serial number issued corresponding to the post-evolution card ID. Next, the CPU 21 of the game server 20 deletes the card data of the reference card used for evolutionary synthesis from the possessed card data table (S58).
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 acquiring the image data transmitted in S62, the CPU 11 of the user terminal 10 displays an image (for example, the image P5 in FIG. 10) on the display unit 16 based on the image data (S64).

  As described above, in the game system according to this embodiment, the possessed card (an example of the selected object) selected as a base card by the user can be evolved step by step so as to become a different card each time evolution synthesis is performed. If not, not only the combination conditions (an example of change conditions) necessary for the user's one-stage evolution of the selected possession card, but also the combination conditions for the multi-stage evolutionary synthesis in the future. A plurality of cards specified by a plurality of reference card IDs included in the are presented. Therefore, since the user can recognize in advance that the presented cards are reference cards necessary for the future evolution of the selected possessed card, one of the presented possessed cards is mistaken. It is prevented from letting go.

  In the embodiment described above, the output unit 54 displays the plurality of cards specified by the plurality of reference card IDs included in each combination condition acquired by the acquisition unit 53 separately for each corresponding combination condition. The case where image data is output has been described. The output of such image data has the following advantages. That is, as shown in the image P4 of FIG. 9, a plurality of reference cards included in the combination conditions for the first stage evolution synthesis, the second stage evolution synthesis,... Are displayed for each combination condition. The user can distinguish and recognize cards that are required for evolutionary synthesis in the relatively near future and cards that are required in the relatively distant future. Therefore, for example, the user can select to use a card that is required in a relatively distant future for processing other than evolutionary synthesis.

(2) Second Embodiment In the first embodiment, communication according to HTTP is performed between the user terminal 10 and the game server 20, and the user terminal 10 interprets an HTML document acquired from the game server 20. Although the case where the present invention is realized by a so-called browser format that displays a game image in this way has been described, the present invention is not limited to this case. It is realized by a so-called native application format in which the user terminal 10 executes the game program downloaded by the user terminal 10 to execute the game process and suppresses the transmission / reception process between the user terminal 10 and the game server 20. May be. In the native application format, image data is generated and displayed in the user terminal 10 without using a web browser.
In the second embodiment, an example in which the game of the first embodiment is realized in the native application format will be described. Note that the hardware configuration of this embodiment may be the same as that of the first embodiment. In the format of the native application of the present embodiment, it is assumed that most of the processing is performed on the user terminal 10 side. However, a part of the game processing not described below (for example, lottery processing given to the user by lottery, The present invention may be configured such that a game operator performs a process on the game server 20 side and transmits a processing result by the game server 20 to the user terminal 10.
In the present embodiment, the user terminal 10 is an example of an information processing apparatus.

In the present embodiment, the user terminal 10 receives a game program from the game operator's server based on a predetermined operation by the user, and the received game program is stored in the storage 18. When the game is started by the user terminal 10, communication is established between the user terminal 10 and the game server 20, and a login process is performed. A data table group (card data table, evolution) is transferred from the game server 20 to the user terminal 10. Composite data table, possessed card data table) are transmitted. The data table group transmitted to the user terminal 10 is held in the storage 18 of the user terminal 10. In this case, the data table group in the storage 18 is updated each time the user logs in.
In order to prevent the possessed card data table from being falsified in the user terminal 10, the possessed card data table in the user terminal 10 is stored in the game every time a predetermined process by the user terminal 10 is completed or when the user terminal 10 logs out. It is transmitted to the 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 whether the data has been tampered with, has received the possessed card data table in the storage 25. Update to stuff.

Although not shown, in this embodiment, the user terminal 10 executes the process flow of evolutionary synthesis shown in FIGS. 12A, 12B, and 13 with reference to the data table group in the storage 18.
In the present embodiment, the case where the card data table, the evolution synthesis data table, and the possessed card data table are held in the game server 20 has been described. However, the present invention is not limited to this case. In the game of the native application format, the holding share of each data table can be set as appropriate, and the user terminal 10, the game server 20, or other devices accessible from the user terminal 10 or the game server 20 Each data table may be held in at least one of them, and is not limited to a specific holding mode.

(3) Modified Examples Hereinafter, modified examples common to the above-described embodiments will be described.

(3-1) Modification 1
In this modification, the output unit 54 displays a plurality of reference cards specified by a plurality of reference card IDs included in each combination condition acquired by the acquiring unit 53 for each reference card ID. , Output image data.
In order to realize the function of the output means 54 of this modification, the CPU 21 of the game server 20 refers to the pre-evolution card ID, the post-evolution card ID, and the reference included in the combination condition corresponding to the evolution ID in each evolutionary synthesis. When the card IDs are acquired, the card data corresponding to these card IDs are read from the card data table, and image data to be displayed separately for each reference card ID is generated. An example of an image displayed based on the generated image data is shown in FIG. An image P4b shown in FIG. 14 is an example of an image that displays the image P4 of FIG. 9 according to the present modification.
In this configuration, since a plurality of cards included in each combination condition are presented to the user separately for each card ID, the user can quantitatively recognize how many cards are required. Therefore, the user can give an overview of the entire cards required to evolve the selected card into different cards one after another, and can easily recognize the number of types of cards to be obtained.
Furthermore, you may display so that it may be understood whether the user possesses the card | curd of each card | curd ID or not. Further, even if it is possessed, it may be displayed so that it can be seen whether all the cards are possessed or whether all the cards are possessed. In the case where all the cards are not possessed, the number of cards possessed and the number of cards that need possession may be displayed so as to be understood. By displaying in this way, the user can check the current possession state of the card to be obtained. For example, when the number of reference cards possessed is N and the number of reference cards that need to be possessed is M, information in a format such as N / M may be displayed in association with each card.

(3-2) Modification 2
In this modification, the output unit 54 is specified by a reference card ID that is included in duplicate in at least two or more combination conditions among a plurality of reference card IDs included in each combination condition acquired by the acquisition unit 53. The image data may be output so that the card to be displayed is displayed in a display format different from the card specified by the card ID other than the card ID included in duplicate.
In order to realize the function of the output means 54 of this modification, the CPU 21 of the game server 20 refers to the pre-evolution card ID, the post-evolution card ID, and the reference included in the combination condition corresponding to the evolution ID in each evolutionary synthesis. When the card ID is acquired, a reference card ID (duplicate reference card ID) that is duplicated in at least two or more combination conditions is specified. Then, the card data corresponding to the pre-evolution card ID, the post-evolution card ID, and the reference card ID included in the combination condition is read from the card data table, and the above-mentioned duplicate reference card ID and the reference card that is not the duplicate reference card ID Image data is generated in a display format different from the ID. An example of an image displayed based on the generated image data is shown in FIG. An image P4c shown in FIG. 15 is an example of an image that displays the image P4 of FIG. 9 according to this modification, and the cards A01, C12, and M03 are cards corresponding to the duplicate reference card IDs, respectively.
In this configuration, duplicate reference card ID cards among the plurality of 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 overview the entire cards necessary for sequentially evolving selected cards into different cards, and can easily recognize particularly many cards that should be obtained.
Further, it may be displayed so that it can be seen whether the user has a card ID corresponding to the duplicate reference card ID or not. Further, even if it is possessed, it may be displayed so that it can be seen whether all the duplicate reference cards are possessed or whether all the duplicate reference cards are possessed. Further, when all the number of duplicate reference cards are not possessed, the number of duplicate reference cards possessed and the number of duplicate reference cards that need to be possessed may be displayed so as to be understood. By displaying in this way, the user can check the current possession state of the card to be obtained. For example, if the number of duplicate reference cards possessed is N and the number of duplicate reference cards required to be possessed is M, information in a format such as N / M may be displayed in association with each card.

(3-3) Modification 3
In this modification, the card ID is associated with information indicating a card acquisition condition by the user. The information indicating the card acquisition conditions may be a card rarity or a limited flag as shown in FIG. 5, for example, or may be a level corresponding to the number of cards distributed. The level corresponding to the number of cards distributed is not shown in FIG. 5, but is recorded in the card data table. The game server 20 periodically (for example, every day) totals all user-owned cards registered in the game for each card ID, determines a level based on the total value, and the value of the level in the card data table. Update.
In this example, the output unit 54 obtains a card specified by the reference card ID whose acquisition condition satisfies a predetermined condition from among a plurality of reference card IDs included in each combination condition acquired by the acquisition unit 53. May be displayed in a display format different from that of the reference card specified by the reference card ID that does not satisfy the predetermined condition.
In order to realize the function of the output means 54 of this modification, the CPU 21 of the game server 20 refers to the pre-evolution card ID, the post-evolution card ID, and the reference included in the combination condition corresponding to the evolution ID in each evolutionary synthesis. When the card IDs are acquired, the card data corresponding to these card IDs is read from the card data table, and image data for distinguishing and displaying each information indicating the card acquisition conditions is generated. An example of an image displayed based on the generated image data is shown in FIG. An image P4d shown in FIG. 16 is an example of an image that displays the image P4 of FIG. 9 according to the present modification. In the example of the image P4d, the information indicating the card acquisition condition is rarity, and the card rarity is R5 as the predetermined condition. A reference card with a rarity R5 is displayed in a different display format from a reference card with a rarity R4 or lower.
In this configuration, for example, when the acquisition condition is a condition related to the difficulty of acquiring the card, acquisition of a card having a plurality of card IDs included in the combination condition of the multi-stage evolutionary synthesis for the card selected as the base card Therefore, the user can determine the level of evolutionary synthesis for the selected card in consideration of the difficulty of acquisition.
Furthermore, it may be displayed so that it can be seen whether the user possesses or does not possess a card that is determined to be highly difficult to obtain. Further, even if it is possessed, it may be displayed so that it can be seen whether all the cards are possessed or whether all the cards are possessed. In the case where all the cards are not possessed, the number of cards possessed and the number of cards that need possession may be displayed so as to be understood. By displaying in this way, the user can check the current possession state of the card to be obtained. For example, when the number of reference cards possessed is N and the number of reference cards that need to be possessed is M, information in a format such as N / M may be displayed in association with each card.

(3-4) Modification 4
In this modification, the accepting means 51 as the second accepting means is selected when the card selected as the base card is a card that can be evolved step by step so as to become a different card each time evolution synthesis is performed. Designation of information regarding the number of times of evolutionary synthesis that gradually evolves the different cards so as to become different cards.
Further, in this modification, when the receiving unit 51 receives designation of information related to the number of times of evolutionary synthesis, the acquisition unit 53 performs each evolutionary synthesis for the card selected as the base card. Get combination conditions.
An example of a series of images displayed on the user terminal 10 in this modification is shown in FIG. When the button b11 (“Confirm”) is designated in the image P3 in FIG. 17 (same as the image P3 in FIG. 8), the image changes as indicated by P10. In the image P10, buttons b31 to b33 are provided as options for the number of times of evolution of the card Q01 selected as the base card. The designation of any of the buttons b31 to b33 corresponds to designation of information regarding the number of evolutionary synthesis. In the image P10, for example, when the button b32 (“evolution to the second stage”) is designated, the image changes as shown in P11. In the image P11, as specified by the button b32, a reference card necessary for the evolution up to the second stage of the card Q01 is displayed.

In order to realize this modification, when the CPU 11 of the user terminal 10 receives an operation for specifying information related to the number of times of evolutionary synthesis (for example, designation operation for any of the buttons b31 to b33 in FIG. 17), the evolutionary synthesis is performed. Is transmitted to the game server 20. When the CPU 21 of the game server 20 obtains information on the number of evolutionary synthesis from the user terminal 10, the pre-evolution card ID corresponding to the evolution ID in each evolutionary synthesis of the card selected as the base card from the evolutionary synthesis data table, The post-evolution card ID and the reference card ID included in the combination condition are acquired. Then, from the acquired information, a card ID corresponding to information relating to the number of times of evolutionary synthesis specified by the user is extracted, card data corresponding to the extracted card ID is read from the card data table, and Image data to be displayed separately for each evolution is generated. An example of an image displayed based on the generated image data is the image P11 illustrated in FIG.
Note that the information acquired from the evolution synthesis data table by the CPU 21 does not have to be information corresponding to all the evolutions until the card selected as the base card finally evolves, and is specified by information on the number of evolution synthesis. Any information corresponding to the number of times of evolutionary synthesis may be used.

In this configuration, according to the number of times of evolutionary synthesis specified by the user, a reference card necessary for the number of times of evolutionary synthesis for the selected card is presented to the user. For this reason, the user has a situation where it is complicated for the user, such as when all of the types and number of reference cards required for the evolutionary synthesis of the selected card are presented to the user. Can be avoided. Since the user can designate the number of evolutionary synthesis, for example, by specifying a relatively small number of evolutionary synthesis (for example, 2 to 3 times), only the reference cards that will be required for the selected card in the near future can be specified. It can be extracted and confirmed, or the reference cards required for all evolutionary synthesis for the selected card can be confirmed at once. That is, a user-desired presentation mode can be realized depending on the user's designation.
Furthermore, you may display so that it may be understood whether each user has each card. Further, even if it is possessed, it may be displayed so that it can be seen whether all the cards are possessed or whether all the cards are possessed. In the case where all the cards are not possessed, the number of cards possessed and the number of cards that need possession may be displayed so as to be understood. By displaying in this way, the user can confirm the current possession state of the card to be obtained in order to perform the specified number of evolutionary synthesis. For example, when the number of reference cards possessed is N and the number of reference cards that need to be possessed is M, information in a format such as N / M may be displayed in association with each card.

(3-5) Modification 5
In this variation, if the card selected as the base card is a card that evolves over multiple stages, the user may accidentally dispose of a card that is required for evolution at each stage of the card. Make reservations so that there is no. A reserved card (hereinafter also referred to as a “reserved card”) is restricted from being used for processing other than the evolution synthesis of the target card.
More specifically, in the present modification, the reception unit 51 described above is a request based on an operation by the user in response to the output of the image data by the determination unit 54 as a request reception unit, and A restriction request for restricting processing to at least one of the cards is accepted.
In the present modification, when the limit request is received by the receiving unit 51, the changing unit 58 determines the request source of the limit request based on the plurality of reference card IDs included in the combination condition acquired by the acquiring unit 53. Among the cards possessed by the user, a card specified as a restriction card that should be restricted from being used for processing different from evolutionary synthesis is provided with a function for restricting use of processing different from evolutionary synthesis.

An example of the card reservation method of this modification will be described with reference to an image P4e in FIG. An image P4e in FIG. 18 is a modification of the display mode of the image P4 in FIG. In the image P4e, the reference card necessary for the evolution of each stage is displayed, and the state of the card is displayed corresponding to the displayed reference card. The status of the card is “not in possession” indicating that the user does not possess the card, “reserved” indicating that the user possesses the card and reserves the card, or A state of “unreserved” indicating that the user has the card but has not reserved the card (in this case, buttons b41 and b42 (“reserve”) for reserving the card) is displayed. ) Is one of the states.
When any of the buttons b41 and b42 is designated in the image P4e, the state of the reference card corresponding to the button changes from the “unreserved” state to the “reserved” state.

As an example of the case where the reserved card is used for processing other than the intended evolutionary synthesis, a reserved card selling process will be described.
FIG. 19 shows a series of changes in the display screen when the user executes processing when selling a reserved card. In FIG. 19, an image P1 is the same as that shown in FIG.
When the button b5 (“Sale”) is designated in the image P1, the image changes as shown in P20. In the image P20, a list of cards possessed by the user is displayed. The card that the user wishes to sell is selected from the list of possessed cards of the image P20. At this time, when a reserved card is selected from among possession cards for sale, the image changes as shown in P21. The image P21 includes text for notifying 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 sale process. )including. When the button b50 is designated in the image P21, the sale process is performed even for a reserved card, whereby the user obtains a point of the sale price corresponding to the card and loses the reserved card.

As shown in the image P21, making the execution procedure of the sale process complicated for the reserved card is an example of restricting that the reserved card is used for processes other than evolutionary synthesis.
Although not shown in FIG. 19, a list of user possessed cards may be displayed in the image P20 in such a manner that a reserved card cannot be selected. That is, in order to more reliably prevent the reserved card from being used for processes other than evolutionary synthesis, execution of the reserved card sale process may be prohibited.

  In the game of the present embodiment, in addition to the sale process described above, the possessed card may be lost by executing the normal synthesis process. In the normal compositing process, the user selects a base card as a card to be grown from his / her possessed cards. In the normal combining process, the reference card combination condition may not be determined for each base card, and the user can appropriately select the reference card from the possessed cards. When the normal synthesis process is executed, the reference card disappears from the user's possessed card instead of the card parameter of the base card changing (for example, the card level and skill level increase). In the case of the normal combining process, similarly to the sale process described above, if the reference card used for the normal combining when executing the normal combining is a reserved card, the execution of the normal combining is restricted.

A method for realizing this modification will be described.
In this modification, 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 card reservation for each evolutionary synthesis, and an example thereof is shown in FIG.
In the reservation data table, information on reserved cards for user evolution synthesis is recorded. Although FIG. 20 illustrates a reservation data table for one user, the reservation data table is provided for each user registered in the game. In FIG. 20, reservation IDs are IDs issued in the order in which evolutionary synthesis reservations are made. The evolution ID corresponds to the evolution ID shown in the evolution synthesis data table, and is an ID that specifies the content of evolution synthesis. Of the reserved card serial numbers, the serial number of the pre-evolution card is a serial number corresponding to the possessed card selected by the user as the base card for evolutionary synthesis. Of the serial number of the reserved card, the columns C1 to C5 of the reference card correspond to the columns C1 to C5 constituting the combination condition of the reference card ID in the evolutionary synthesis data table, and the reference corresponding to each column. If the card is a reserved card, the serial number of the card is recorded. When the reference card corresponding to each column is not reserved, data indicating “no reservation” (for example, NULL) is recorded.
In the example of the reservation data table shown in FIG. 20, an example in the case of the image P4e in FIG. 18 is shown. That is, evolution ID: 0033 corresponds to the evolution of card Q01 → R01, evolution ID: 0044 corresponds to the evolution of card R01 → S01, and evolution ID: 0020 corresponds to the evolution of card S01 → T01. Here, when the button b41 (“Reserve”) is selected in the image P4e of FIG. 18, the CPU 21 of the game server 20 replaces the data indicating “No reservation” in the column of C2 of the evolution ID: 0044. The serial number of the card K14 possessed by the user is written. At this time, the CPU 21 refers to the possessed card data table of the user in order to acquire the serial number of the card K14.

The CPU 21 of the game server 20 determines the state of the user's possession card with reference to the reservation data table and possession card data table when generating the image data that is the basis of the image P4e in FIG. The CPU 21 refers to the reservation data table to determine that the reference card in which the serial number is written is in the “reserved” state, and the serial number is not written in the reservation data table but the user has it. It is determined that the existing card is in an “unreserved” state, and the card that the user does not have is determined to be in an “unheld” state.
Further, the CPU 21 of the game server 20 performs the following process when restricting reserved cards. When the reserved card is selected as a card to be used for processing, the CPU 21 determines whether or not the processing is evolutionary synthesis (that is, target evolutionary synthesis) processing corresponding to the reserved card. Refer to and judge. That is, since the content of evolutionary synthesis is specified by the evolution ID corresponding to the reserved card, it can be determined whether or not the above process is the intended evolutionary synthesis. If it is determined that it is not the target evolutionary synthesis, for example, data of an image for giving a warning to the user (for example, image P21 in FIG. 19) is generated and transmitted to the user terminal 10.

  According to this modification, at least a part or all of the reference card necessary for evolving the card selected as the base card is selected from among the possessed cards of the user in response to a request from the user. It is restricted to be used for processes other than evolutionary synthesis at each stage of the card. Therefore, before the combination condition is satisfied, it is ensured that the user mistakenly uses the reference card necessary for evolving the selected card in the future for processing other than the evolution. Can be prevented.

(3-6) Modification 6
In this modification, registration means 59 is provided. When the registration unit 59 includes a card ID corresponding to the user's possession card among the plurality of card IDs included in each combination condition acquired by the acquisition unit 53 for the card selected as the base card. A function of registering an instruction card selected based on a user operation among the possessed cards as a favorite (bookmark) is provided. That is, in this modification, when a card necessary for the future evolution of the card selected as the base card is included in the user's possessed card, the card can be registered as a favorite.

An example of a method for registering a card as a favorite in this modification will be described with reference to FIG. An image P4f in FIG. 21 is a modification of the display mode of the image P4 in FIG. In the image P4f, the reference card necessary for the evolution of each stage is displayed, and the state of the card is displayed corresponding to the displayed reference card. The state of the card is either “not possessed” indicating that the user does not possess the card, or “possessed” indicating that the user possesses the card.
When one of the possessed cards (K14 in this example) is selected in the image P4f, for example, as shown in the image P15, the selected card is displayed as a favorite registration target. The image P15 includes a button b50 (“favorite registration”) for registering the selected card as a favorite. When the button b50 ("favorite registration") is designated, the selected card (K14) is registered as a user favorite.
Note that the method of identifying and displaying the states of “possessed” and “not possessed” is not limited to the method using a character string as shown in the image P4f, and may be displayed so as to be identified using an image. For example, in the case of a possessed card, a card image corresponding to the possessed card is displayed, and in the case of an unowned card, it is displayed as an image different from the card image corresponding to the unowned card. The different image may be any image that can be seen to be different from the normal card image. For example, the image may be an image obtained by reducing the brightness of the normal card image, an “?” Mark, or the like.
In addition, the favorite may be registered as a user's favorite immediately without displaying the image P15 when the possessed card is selected in the image P4f. Further, in the image P4f, after the user selects a plurality of possession cards, the selected plurality of possession cards may be registered at a time by causing the user to press a confirmation button.
Although not shown, when registered as a favorite, a list of possessed cards of the user registered as a favorite is displayed in response to the user's browsing request. Also, the possessed card registered as a favorite so that the favorite card can be identified in the list of possessed cards displayed when the button b1 (“view the possessed monster”) is designated in the image P1 of FIG. And possession cards that are not registered as favorites may be displayed in an identifiable manner. For example, a possessed card registered as a favorite can be displayed with a mark indicating that it is registered as a favorite so that it can be distinguished from a possessed card that is not registered as a favorite. In addition, the favorite registration may not only add a mark, but also limit the processing that is no longer a possessed card with respect to a possessed card that is registered as a favorite. Thereby, it is possible to prevent the user from mistakenly selling the possessed card registered as a favorite. As in the method described in the sixth modification, a reservation button is provided for a desired card from the list of possessed cards registered as favorites, and reservation can be made by designating the reservation button. May be.
In order to realize this modification, a flag (1: favorite registered, 0: favorite not registered) may be provided in correspondence with the card ID of the possessed card in the possessed card data table (see FIG. 7). When the CPU 21 of the game server 20 receives a request for browsing a card registered as a favorite, the card data table flag “1” is read, and an image including a list of cards is read based on the read card data. Generate data.
According to this modification, when it is confirmed that the card necessary for future evolution of the card selected as the base card can be confirmed, it can be immediately registered as a favorite, so that the user can store it in his / her memory. You will be able to mark your possession cards for future evolution without reliance. In addition, for example, when the user has a large number of cards, the user can quickly check cards important for the user necessary for evolution.

(4) Application to application other than game In the above-described embodiment and modification, the case where the present invention is applied to a game has been described, but it may be applied to another application. For example, when a plurality of types of electronic coupon tickets are distributed each time a product is purchased at a shopping mall on the Internet, the electronic coupon tickets may be used as an example of the object of the present invention. In this case, for example, in order to upgrade the privilege content of the coupon ticket Q as the base coupon ticket (an example of a change process), the user possesses and uses the coupon tickets A to C as the reference coupon tickets corresponding to the coupon ticket Q. It is possible. In this example, it is assumed that the coupon V is changed to a different coupon through a plurality of stages of change processing. At this time, the shopping server specifies the reference coupon ticket necessary for the evolution of each stage of the coupon Q as the base coupon ticket, generates image data for the user to present the reference coupon ticket, and the image data Is transmitted to the user terminal.
The present invention can be appropriately applied to other applications other than the above-described examples.

As mentioned above, although embodiment of this invention and the modification were demonstrated in detail, this invention is not limited to the said embodiment etc. In addition, the embodiment may of course be variously improved and changed without departing from the gist of the present invention. The technical matters described in the above embodiment and each modification may be applied in appropriate combination.
The request receiving method is not limited to the above-described case. For example, the request receiving method may be a method of receiving an instruction input by shaking a user terminal provided with an acceleration sensor or an instruction input (gesture input) by a gesture. In gesture input, by performing a predetermined gesture for a user terminal having an imaging function, the user terminal recognizes an image of the gesture and recognizes an operation input associated with the gesture in advance. Further, in the case of a user terminal capable of executing a voice recognition program, the request receiving method may be a method of receiving an instruction input by a predetermined voice.

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

According to one embodiment of the present invention, a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information in association with a change process that changes the object An information processing apparatus (10 or 20) that can access (25),
First accepting means (51) for accepting designation of a selected object that is an object selected from possessed objects possessed by the user based on a user operation;
In the case where the selected object is an object that can be changed stepwise so as to be sequentially different objects each time the change process is performed, each change condition for performing each of the change processes in a plurality of steps is selected for the selected object. Obtaining means (53) for obtaining from the storage device (25);
Output data (for example, image data) for displaying a plurality of objects specified by a plurality of object identification information included in each change condition acquired by the acquisition means (53) in a display format that can be identified by the user. ) Output means (54),
Is an information processing apparatus.

The “information processing apparatus” may be a stand-alone game machine, a user terminal (for example, a portable terminal or a personal computer), a network server, or the like. The entity of the information processing apparatus can be appropriately defined depending on the game implementation form. For example, when the function of each part of the information processing apparatus is realized by the user operating the game machine or the user terminal, the game machine or the user terminal corresponds to the information processing apparatus of the present invention. Alternatively, when the user terminal as a client has a function of accepting an operation input from the user and a function of displaying an image, and the function of each unit of the information processing apparatus is realized by a server that can substantially communicate with the user terminal. The server corresponds to the information processing apparatus of the present invention.
The “object” may be any display target as long as the user can visually recognize it, and can be set as appropriate according to the processing content of the information processing apparatus of the present invention. For example, when the information processing apparatus of the present invention processes information related to a game, the object may include a character or an item on the game. The character is, for example, a virtual person or creature on the game, a monster, or the like, and includes characters displayed on a card.
“Object identification information” is identification information that enables a user to identify an object, and information associated with the identification information. The identification information that enables the user to identify the object is, for example, an object name or an object image. As information associated with an object name and an object image, an object ID (for example, a card ID when the object is a card) is an example of “object identification information”.
The “storage device” may be a memory device having any configuration, such as a flash memory or an HDD (Hard Disk Drive). Further, the storage device may be built in the information processing device, or may be an external device configured to be accessible from the information processing device in a wired or wireless manner.
“Owning” of an object means that the user can use the object for processing using the object. “Not possessed” of an object means that the user cannot use the object for processing using the object. “Acquisition” of an object means that the object has shifted from an unowned state to an owned state.

  In the information processing apparatus described above, when the selected object selected by the user is an object that can be changed step by step so as to become a different object each time the change process is performed, one of the selected objects is given to the user. A plurality of objects specified by a plurality of object identification information included in a change condition for a multi-stage change process in the future as well as a change condition necessary for the stage change process are presented. As a result, the user can recognize in advance that the plurality of presented objects are necessary for future change processing of the selected object, thereby preventing one of the plurality of presented objects from being accidentally released. Is done.

The output means (54) displays a plurality of objects specified by a plurality of object identification information included in each change condition acquired by the acquisition means (53) separately for each corresponding change condition. The output data may be output.
In this configuration, since a plurality of objects included in the change condition for the first stage change process, the second stage change process,... Are displayed for each change condition, the user changes in the relatively near future. It is possible to distinguish and recognize an object required for processing and an object required in the relatively distant future. Therefore, for example, the user can select to use an object that is required in a relatively distant future for processing other than change processing, for other purposes.

When the object identification information corresponding to the possessed object of the user is included in the plurality of object identification information included in each change condition acquired by the acquisition unit, You may further provide the registration means (59) which registers the possessed object selected based on a user's operation.
In this configuration, the possessed object necessary for the future change process of the selected object can be registered. Therefore, when the user possesses a large number of objects, for example, an object important for the user necessary for the change process It becomes possible to confirm quickly.

A request based on an operation by the user in response to the output data being output by the output means (54), and for restricting processing on at least one of the plurality of objects Request accepting means (51) for accepting the request;
When the request is accepted by the request accepting means (51), the possessed object possessed by the requesting user based on a plurality of object identification information included in the change condition obtained by the obtaining means (53) Limiting means (58) for restricting use of a process different from the change process for an object identified as a restricted object to be restricted from being used for a process different from the change process, May be further provided.
“Restricted to be used for processing different from change processing” is not limited to prohibiting the processing itself other than the change processing of the selected object, and the change processing of the selected object can be executed. The execution procedure may be made difficult, or the change processing execution procedure may be complicated. In the example of the above-described embodiment, the restriction on the use of processing different from the object change processing is realized by reserving the object. For example, in the above-described embodiment, the “reserved card” is restricted from being used for processing different from the evolution reservation for the purpose of the card.
In the above configuration, at least a part or all of the objects necessary for changing the selected object among the objects possessed by the user is used for processing other than the change processing of the selected object in response to a request from the user. Limit what is done. Therefore, before the change condition is satisfied, it is possible to reliably prevent the user from erroneously using an object necessary for changing the selected object in a process other than the process of changing the selected object. be able to.

The output means (54) displays a plurality of objects specified by a plurality of object identification information included in each change condition acquired by the acquisition means (53) separately for each object identification information. The output data may be output.
In this configuration, since a plurality of objects included in each change condition are distinguished and presented to the user for each object identification information, the user can quantitatively recognize how many of which objects are required. Therefore, the user can overview the entire objects necessary for sequentially changing the selected object to different objects, and can easily recognize the number of types of objects to be obtained.

The output means (54) is based on object identification information that is duplicated in at least two stages of change conditions among the plurality of object identification information included in each change condition acquired by the acquisition means (53). The output data may be output such that the specified object is displayed in a display format different from that of the object specified by the object identification information other than the object identification information included redundantly.
In this configuration, the objects of the object identification information that are duplicated among the plurality of object identification information included in the change conditions of the plurality of stages of change processing for the selected object are presented to the user in different display formats. Therefore, the user can overview the entire objects necessary for sequentially changing the selected object to different objects, and can easily recognize particularly many objects to be obtained.

The object identification information is associated with information indicating the object acquisition conditions by the user,
The output means (54), among a plurality of object identification information included in each change condition acquired by the acquisition means (53), an object specified by object identification information satisfying a predetermined condition, The output data may be output such that the acquisition condition is displayed in a display format different from that of the object specified by the object identification information that does not satisfy the predetermined condition.
In this configuration, for example, when the acquisition condition is a condition related to the difficulty level of obtaining the object, the difficulty level of obtaining the object of the plurality of object identification information included in the change condition of the multi-level change process for the selected object is determined. Therefore, the user can determine the level of the change process for the selected object in consideration of the difficulty level of acquisition.

When the selected object is an object that can be changed step by step so as to become a different object each time the change processing is performed, the number of change processings to change the selected object step by step to become a different object sequentially A second accepting means (51) for accepting designation of information related to
When the second receiving unit (51) receives designation of information regarding the number of times of the change process, the acquisition unit (53) performs each change condition for performing the change process of the number of times for the selected object. May be obtained.
In this configuration, according to the number of change processes in a plurality of stages specified by the user, an object necessary for the change process of the selected object for that number of times is presented to the user. Therefore, the user can avoid a situation that is complicated for the user, such as when all of the types and the number of objects required for all the change processes for the selected object are presented to the user. Since the user can specify the number of change processes in a plurality of stages, for example, by specifying a relatively small number of change processes (for example, 2 to 3 times), only objects that are necessary for the selected object in the near future are extracted. It is possible to confirm all the objects necessary for all the change processes for the selected object. That is, a user-desired presentation mode can be realized depending on the user's designation.

Another aspect of the present invention is an information processing system (1) including a user terminal (10) and a server (20) configured to be communicable with the user terminal (10), wherein the user terminal ( 10) and at least one of the server (20) includes: object identification information for identifying an object; and a change condition including a plurality of object identification information for performing a change process for changing the object. In the information processing system that is accessible to the storage device (25) that stores the information in association with each other,
A first accepting means (51) for accepting designation of a selected object that is an object selected from possessed objects possessed by the user based on a user operation;
In the case where the selected object is an object that can be changed stepwise so as to be sequentially different objects each time the change process is performed, each change condition for performing each of the change processes in a plurality of steps is selected for the selected object. Obtaining means (53) for obtaining from the storage device (25);
Output means for outputting output data for displaying a plurality of objects specified by a plurality of object identification information included in each change condition acquired by the acquisition means (53) in a display format that can be identified by the user. (54),
Is an information processing system provided with at least one of the user terminal (10) and the server (20)

Another aspect of the present invention is a memory for storing object identification information for identifying an object and a condition for performing a change process for changing the object, which includes a plurality of object identification information in association with each other. A computer accessible to the device (25),
A first accepting means (51) for accepting designation of a selected object that is an object selected from possessed objects possessed by the user based on a user operation;
In the case where the selected object is an object that can be changed stepwise so as to be sequentially different objects each time the change process is performed, each change condition for performing each of the change processes in a plurality of steps is selected for the selected object. Obtaining means (53) for obtaining from the storage device (25);
Output means for outputting output data for displaying a plurality of objects specified by a plurality of object identification information included in each change condition acquired by the acquisition means (53) in a display format that can be identified by the user. (54),
It is a program to make it function as.

  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 program.

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

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

Claims (6)

An information processing apparatus capable of accessing a storage device that associates and stores object identification information for identifying an object and a change condition that includes a plurality of object identification information that is a condition for performing a change process that changes the object Because
First receiving means for receiving designation of a selected object that is an object selected based on a user operation;
In the case where the selected object is an object that can be changed in stages so as to be sequentially different objects each time the change process is performed, each change condition for performing each change process in a plurality of stages with respect to the selected object, Obtaining means for obtaining from the storage device;
Output means for outputting output data for displaying a plurality of objects specified by a plurality of object identification information included in each change condition acquired by the acquisition means in a display format that can be identified by the user;
With
The information processing apparatus, wherein the output data is data for displaying whether or not each of the plurality of specified objects is a possessed object possessed by the user in a display format that can be identified by the user. The output means displays the output data in such a manner that a plurality of objects specified by a plurality of object identification information included in each change condition acquired by the acquisition means are distinguished and displayed for each corresponding change condition. Output,
The information processing apparatus according to claim 1. When object identification information corresponding to the user's possessed object is included in the plurality of object identification information included in each change condition acquired by the acquisition means, based on the user's operation among the possessed objects A registration means for registering the selected possessed object,
The information processing apparatus according to claim 1 or 2. In response to output of the output data by the output means, a request based on an operation by the user, which is a request for restricting processing on at least one of the plurality of objects is received. Request accepting means;
When the request is accepted by the request accepting unit, the change process among the possessed objects possessed by the requesting user based on a plurality of object identification information included in the change condition acquired by the acquiring unit. A restriction unit that restricts the object specified as a restriction object that should be restricted from being used in a process different from the restriction process to be used in a process different from the change process;
The information processing apparatus according to claim 1. 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 includes object identification information for identifying an object, and the object In the information processing system capable of accessing a storage device that associates and stores a change condition including a plurality of object identification information, which is a condition for performing a change process to be changed,
An information processing system, comprising: each means of the information processing apparatus according to claim 1-at least one of the user terminal and the server.   A computer accessible to a storage device that associates and stores object identification information that identifies an object and a change condition that includes a plurality of object identification information that is a condition for performing a change process that changes the object The program for functioning as each means of the information processing apparatus as described in any one of Claims 1-4.

Images