Program, information processing method, and game system

Abstract

To eliminate uneasiness that a user feels in processing for acquiring a required object.SOLUTION: A game system acquires change conditions corresponding to a selected object from a storage device, uses information indicating multiple objects included in the change conditions to output first output data for displaying the multiple objects in a display format identifiable by users each, receives an instruction for designating any of the multiple objects via a user's operation according to output of the first output data, acquires information indicating a designated object when the users do not own the designated object, and outputs second output data for displaying acquisition conditions of the designated object by using information showing the designated object.SELECTED DRAWING: Figure 15

Description

Technical Field

[0004] , , , , , , , , , , ,

[0003] , ,

[0001] The present invention relates to information processing technology for processing information about an object.

Background Art

[0002] In recent years, so-called social games have become popular as applications executed in social networking services (SNS). Among such social games, digital card games using cards are known. Further, a main card and a sub-card are selected by the user from the user's owned cards, and by performing a synthesis process on the main card and the sub-card, the ability parameters of the main card are changed and the sub-card is deleted from the user's owned cards. There is a known game (Patent Documents 1 and 2). <00可见,

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the synthesis process, in order to realize the synthesis process of the base object (corresponding to the main card above), it may be required that the user has a plurality of reference objects (corresponding to the sub-cards above) that satisfy the combination conditions corresponding to the base object. In that case, 未见 ​​The user places all reference objects that satisfy the combination conditions in order to perform the composition process. It is necessary to have it.

[0005] In this case, obtaining a reference object that the user does not possess is inconvenient for that user. It may be possible or difficult. However, the conditions for obtaining the reference object are unknown. The user indicates that the reference object is unavailable or difficult to obtain. It is not possible to recognize this at the point when deciding whether or not to perform the process to obtain the object. In such cases, the user may find it impossible or difficult to actually obtain the reference object. With this anxiety still lingering, I proceeded to execute the process to obtain the reference object in question. ru.

[0006] The present invention has been made in view of the above-mentioned views, and its purpose is to provide at least a plurality of This process changes an object when it meets the change conditions, which include information that identifies the object. Anxiety users feel when obtaining the reference objects necessary for a process. By providing an information processing device, program, and information processing system that resolve the issue ru. [Means for solving the problem]

[0007] One aspect of the present invention is, Object identification information that identifies an object, and a process that changes the said object. A memory that stores change conditions, which include multiple object identification information used in the process, in association with the conditions. In an information processing device that can access the device, Based on user instructions, the selected object is the selected object. Identified by multiple object identifiers included in the change conditions corresponding to the object identifier information. The first method for displaying multiple objects in a format that allows the user to identify each of them. An output means for outputting output data, In response to the output of the first output data by the output means, the user's instructions Based on this, an instruction is received to specify one of the multiple objects. It includes a means for receiving, The output means further outputs the O specified by the instruction received by the receiving means. If the user does not possess the specified object, the specified object Outputs a second output data to display the acquisition conditions for the effect. It is an information processing device.

[0008] Another aspect of the present invention is, Object identification information that identifies an object, and a process that changes the said object. A memory that stores change conditions, which include multiple object identification information used in the process, in association with the conditions. In an information processing device that can access the device, Based on user instructions, the selected object is the selected object. Identified by multiple object identifiers included in the change conditions corresponding to the object identifier information. Multiple objects, and of the multiple objects, objects that the user does not possess. The requirements for obtaining each object, and the output to display them in a format that is recognizable to each user. Data output means It is an information processing device equipped with [a specific feature].

[0009] Another aspect of the present invention is, Object identification information that identifies an object, and a process that changes the said object. A storage that stores, in association with each other, a change condition including a plurality of object identification information used for In an information processing apparatus capable of accessing a storage device, Based on a user's instruction, a plurality of object identification information included in a change condition corresponding to the object identification information of a selected object, which is the selected object, is specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object, which is the selected object, and the plurality of objects are displayed in a display format that can be identified by the user for each output means for outputting first output data; In response to the first output data being output by the output means, based on the user's instruction a reception means for receiving an instruction for designating any one of the plurality of objects; and The information processing apparatus is provided with The output means further outputs second output data for displaying the difficulty of obtaining the designated object when the user has not possessed the designated object, which is the object designated by the instruction received by the reception means. The information processing apparatus is provided with output data for displaying the difficulty of obtaining the designated object when the user has not possessed the designated object, which is the object designated by the instruction received by the reception means. [[ID=..]]an information processing apparatus.

[0010] Another aspect of the present invention is an information processing system including a user terminal and a server configured to be communicable with the user terminal, and having access to a storage device that stores, in association with each other, object identification information for identifying an object and a change condition including a plurality of object identification information used for a process of changing the object. One of the user terminal and the server Based on a user's instruction, a plurality of object identification information included in a change condition corresponding to the object identification information of a selected object, which is the selected object, is specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object, which is the selected object, and the plurality of objects are displayed in a display format that can be identified by the user for each output means for outputting first output data; Based on a user's instruction, a plurality of object identification information included in a change condition corresponding to the object identification information of a selected object, which is the selected object, is specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object, which is the selected object, and the plurality of objects are displayed in a display format that can be identified by the user for each An output means for outputting output data, In response to the output of the first output data by the output means, the user's instructions Based on this, an instruction is received to specify one of the multiple objects. It includes a means for receiving, The output means further outputs the O specified by the instruction received by the receiving means. If the user does not possess the specified object, the specified object Outputs a second output data to display the acquisition conditions for the effect. It is an information processing system.

[0011] Another aspect of the present invention is, Object identification information that identifies an object, and a process that changes the said object. A memory that stores change conditions, which include multiple object identification information used in the process, in association with the conditions. A computer that can access the device, Based on user instructions, the selected object is the selected object. Identified by multiple object identifiers included in the change conditions corresponding to the object identifier information. The first method for displaying multiple objects in a format that allows the user to identify each of them. Means for outputting output data, In response to the output of the first output data, the user's instructions are used to generate the multiple output data. A means of receiving instructions to specify one of a number of objects, The designated object, which is the object specified by the received instructions, If the user does not possess the specified object, the second method will display the acquisition conditions for that object. Means for outputting output data, This is a program designed to function as such.

[0012] Another aspect of the present invention is, Object identification information that identifies an object, and a process that changes the said object. A memory that stores change conditions, which include multiple object identification information used in the process, in association with the conditions. In an information processing device that can access the device, The selected object corresponds to the object identification information of the selected object. Multiple objects identified by multiple object identification information included in the transformation conditions A first output means that outputs first output data for displaying the acquisition conditions, In response to the output of the first output data by the first output means, the user For the first designated object, which is the specified object, the process used A first receiving means for receiving requests to restrict the following, In response to the receipt of the request by the first receiving means, the first designated object A first restricting means that restricts the use of the effect in the aforementioned process, It is an information processing device equipped with [a specific feature].

[0013] Another aspect of the present invention is, The object includes a user terminal and a server configured to communicate with the user terminal. Object identification information that identifies the object, and used in the process of changing the said object Access to a storage device that stores change conditions containing multiple object identification information in association with them. A system capable of processing information, Either the user terminal or the server, The selected object corresponds to the object identification information of the selected object. Multiple objects identified by multiple object identification information included in the transformation conditions A first output means that outputs first output data for displaying the acquisition conditions, In response to the output of the first output data by the first output means, the user For the first designated object, which is the specified object, the process used A first receiving means for receiving requests to restrict the following, In response to the receipt of the request by the first receiving means, the first designated object A first restricting means that restricts the use of the effect in the aforementioned process, It is an information processing system equipped with [the following features].

[0014] Another aspect of the present invention is, Object identification information that identifies an object, and a process that changes the said object. A memory that stores change conditions, which include multiple object identification information used in the process, in association with the conditions. A computer that can access the device, The selected object corresponds to the object identification information of the selected object. Multiple objects identified by multiple object identification information included in the transformation conditions A means for outputting first output data to display the acquisition conditions, In response to the output of the first output data, the object specified by the user In order to restrict the use of the first designated object, which is a predetermined object, for a specific process A means of receiving requests, In response to the acceptance of the aforementioned request, the aforementioned processing shall be applied to the first designated object. A means of restricting its use in reasoning. It is a program that makes it function as such. [Brief explanation of the drawing]

[0015] [Figure 1] A diagram showing the basic configuration of the game system in the first embodiment. [Figure 2]A block diagram showing the configuration of the user terminal in the first embodiment. [Figure 3] A block diagram showing the configuration of the game server in the first embodiment. [Figure 4] A diagram conceptually illustrating the conditions for obtaining the reference card in the first embodiment. [Figure 5] A diagram showing an example of the configuration of the card data table in the first embodiment. [Figure 6] A diagram showing an example of the configuration of the evolutionary synthesis data table in the first embodiment. [Figure 7] A diagram showing an example of the configuration of the quest data table in the first embodiment. [Figure 8] A diagram showing an example of the configuration of the owned card data table in the first embodiment. [Figure 9] A diagram showing an example of the configuration of the reservation data table in the first embodiment. [Figure 10] This figure shows an example of the configuration of the possession history data table in the first embodiment. [Figure 11] A diagram showing an example of the configuration of the card distribution data table in the first embodiment. [Figure 12A] A diagram showing an example of an image displayed on the user terminal when the game of the first embodiment is being played. [Figure 12B] A diagram showing an example of an image displayed on the user terminal when the game of the first embodiment is being played. [Figure 13A] A diagram showing an example of an image displayed on the user terminal when the game of the first embodiment is being played. [Figure 13B] A diagram showing an example of an image displayed on the user terminal when the game of the first embodiment is being played. [Figure 14] A diagram showing an example of an image displayed on the user terminal when the game of the first embodiment is being played. [Figure 15] Functional block diagram of the game server in the first embodiment. [Figure 16A] A sequence chart showing an example of the process for presenting the acquisition conditions of the first embodiment. [Figure 16B] A sequence chart showing an example of the process for presenting the acquisition conditions of the first embodiment. [Figure 17] A sequence chart showing an example of the evolutionary synthesis process of the first embodiment. [Figure 18] A diagram showing an example of an image displayed on the user terminal when the game of the second embodiment is being played. [Figure 19] A sequence chart showing an example of quest processing in the second embodiment. [Figure 20] A diagram showing an example of an image displayed on the user terminal during the execution of the game according to the third embodiment. [Figure 21] A sequence chart showing an example of the reservation process for evolutionary synthesis in the third embodiment. [Figure 22] A diagram showing an example of an image displayed on the user terminal during the execution of the game according to the fourth embodiment. [Figure 23] A sequence chart showing an example of the process for presenting the acquisition conditions of the fourth embodiment. [Figure 24] A diagram conceptually illustrating the reservation registration and favorite registration of reference cards in the fifth embodiment. [Figure 25] This figure shows an example of the configuration of the possessed card data table in the fifth embodiment. [Figure 26] A diagram showing an example of an image displayed on the user terminal during the execution of the game according to the fifth embodiment. [Figure 27A] A diagram showing an example of an image displayed on the user terminal during the execution of the game according to the fifth embodiment. [Figure 27B] A diagram showing an example of an image displayed on the user terminal during the execution of the game according to the fifth embodiment. [Figure 27C] A diagram showing an example of an image displayed on the user terminal during the execution of the game according to the fifth embodiment. [Figure 28] A sequence chart showing an example of the registration process in the fifth embodiment. [Figure 29A] A sequence chart showing an example of the process for presenting the acquisition conditions of the sixth embodiment. [Figure 29B] A sequence chart showing an example of the process for presenting the acquisition conditions of the sixth embodiment. [Modes for carrying out the invention]

[0016] (1) First Embodiment (1-1) Game System Configuration Below, we will describe Game System 1 as one embodiment of an information processing system.

[0017] Figure 1 shows an example of the system configuration of the game system 1 of the embodiment. This game system 1 is used by user terminals 10a, 10b, 10c, ... and the game Includes server 20. Each user terminal 10a, 10b, and 10c communicates to game server 20. Game servers are accessible, for example, through communication networks such as the internet. 20 is an example of an information processing device. Each user terminal 10a, 10b, 10c, ... is operated by an individual user. These are devices such as feature phones, smartphones, tablet devices, and personal computers. A computer, a television receiver with two-way communication capabilities (a so-called multi-functional type) This includes smart TVs, portable game consoles with communication capabilities, and other communication devices. In the explanation, when referring to each user terminal 10a, 10b, 10c, ... in common, This will be referred to as terminal 10.

[0018] Game server 20 is the server that runs the game. Game server 20 has web Image data that can be interpreted by a browser (for example, written in formats such as HTML or XML) This refers to image data. In the embodiments of the present invention, HTML data will be explained as an example. A program capable of creating . is implemented. The user terminal 10 interprets the HTML data provided by the game server 20 and displays it. It is equipped with a web browser, and the user terminal 10 can perform operations on the web page. The request based on the operation is sent to the game server 20 via the network, and the game server 20 The game processes are executed upon receiving the processing result. Communication networks (NW) include the Internet, WAN (Wide Area Network), and LAN (Local Area Network). Information and communication networks consisting of a dedicated line, or a combination thereof. It's work.

[0019] (1-2) User terminal configuration The user terminal 10 will be explained with reference to Figure 2. As shown in Figure 2, the user terminal 10 has a CPU (Central Processing Unit) 11, R OM (Read Only Memory) 12, RAM (Random Access Memory) 13, operation input section 15, table It comprises a display unit 16, a communication interface unit 17, and storage 18, and between each unit A bus 19 is provided for transmitting control signals or data signals.

[0020] The CPU 11 reads programs and data stored in ROM 12, and the user Timing processing of control signals and data signals with each part of the terminal 10, etc., within the user terminal 10 It controls the body's movements. The CPU 11 also processes programs stored in the storage 18. The program reads various data necessary for program execution and loads it into RAM13, and the program It performs various processes such as data input / output processing, calculation processing, and judgment processing associated with execution. RAM13 is The CPU 11 temporarily stores data for calculation processing, judgment processing, etc.

[0021] For example, CPU 11 accesses a web browser stored in storage 18 via RAM 1 Load it into 3 and execute it. Then, the CPU 11 receives input from the user via the operation input unit 15, etc. Based on the specified URL (Uniform Resource Locator), the communication interface unit 17 Through this, data for displaying web pages from game server 20, i.e., HT ML (HyperText Markup Language) documents and objects such as images associated with those documents The data (hereinafter collectively referred to as "HTML data") is transmitted to the communication interface. The data is obtained via the face unit 17, and a web browser is executed to interpret the HTML data. Oh, user terminal 10 has various plugs to extend the browser functionality of the web browser. An implementation of such a plugin is possible. An example of such a plugin is from Adobe Systems in the United States. It is a Flash player by the company. Alternatively, the HTML data in this embodiment can be used as video. It may also be in HTML5 format with audio playback capabilities.

[0022] The web browser communicates with game server 20 via HTTP (HyperText Transfer Protocol). The web browser performs communication based on the user's operation of the operation input unit 15. URL on the page (Uniform Resource Locator) or target of operation (for example, software box) When a button (hereinafter simply referred to as "button") is selected, the webpage will be updated. Therefore, an HTTP request containing the selection result is sent to the game server 20. The browser retrieves HTML data from game server 20 as an HTTP response. The web page is interpreted and displayed on the display unit 16.

[0023] The display unit 16 may be, for example, an LCD (Liquid Crystal Display) or an organic EL (Electroluminescent Display). Fluorescence is a display device such as a display. It consists of thin pixels arranged in a matrix. When an LCD (Liquid Crystal Display) monitor including film transistors is applied, display unit 1 6 drives thin-film transistors to display images from a web page on the screen.

[0024] If the user terminal 10 is a user terminal with a button input method, the operation input unit 15 is, for example, Multiple input buttons such as directional buttons, select buttons, and numeric keypads to accept user input. An interface equipped with buttons, which recognizes the input of each button being pressed (operated) and outputs it to the CPU 11. Includes a circuit. If the user terminal 10 is a user terminal with a touch panel input method, the operation input unit 15 is: It primarily accepts input via a touch panel, where the user touches the display screen with their fingertip or a pen. wear.

[0025] Storage 18 can be, for example, flash memory or HDD (Hard Disk Drive). It is a memory device composed of the following components.

[0026] (1-3) Game Server Configuration The configuration of the game server 20 will be explained with reference to Figure 3. As shown in Figure 3, the game server 20 includes a CPU 21, ROM 22, RAM 23, and communication It includes an interface unit 24 and a storage unit 25, and controls the signals between each unit. A bus 26 for transmitting data signals is provided. The game server 20 is, In terms of hardware, it can have the same configuration as a general-purpose network server.

[0027] The CPU 21 reads the programs and data stored in the ROM 22 and plays the game. Timing processing of control signals and data signals with various parts within Server 20, etc. It controls the overall operation. The CPU 21 also controls the program stored in storage 25. The program reads various data necessary for program execution and loads it into RAM23. This process handles various operations such as data input / output processing, calculation processing, and judgment processing associated with the execution of the program. RAM2 3 temporarily stores data for calculation processing, judgment processing, etc., by the CPU 21.

[0028] For example, storage 25 contains the web browser of the client user terminal 10 and A program that provides web services by communicating according to HTTP is stored between them. The CPU 21 loads the program stored in the storage 25 into the RAM 23. Then, the program is executed. As the program is executed, the CPU21 uses a communication interface. The system obtains an HTTP request from the user terminal 10 via the system 24, and the HTTP request The system executes processing according to the order and generates HTML data (image data described later) containing the execution result. For example, the following is returned to user terminal 10 as an HTTP response.

[0029] Storage 25 is, for example, flash memory or HDD (Hard Disk Drive) This is an information recording device configured as follows, and in addition to the program described above, it includes a data table group 70. Store. Data table group 70 (described later) includes card data table, evolution synthesis data. Table, Quest Data Table, Owned Card Data Table, Reservation Data Table This includes the ownership history data table and the card distribution data table. The `L` variable is accessed from CPU 21 as needed for reading and writing data.

[0030] (1-4) Presentation of the conditions for obtaining the game cards of this embodiment The game played in the game system 1 of this embodiment involves the user interacting with objects. This is a game that is played using cards. In this game, for example, the user plays Explore areas on the map to acquire cards and items, or acquire cards that the user possesses. This is a game in which you use to compete against other users or NPCs (Non-Player Characters). In the game of this embodiment, the card evolution synthesis process (hereinafter referred to as "evolution synthesis" as appropriate) This refers to the process of evolving a card owned by a user when certain conditions are met. In this embodiment, card evolution and synthesis involves changing the card ID, as will be described later. The process involves modifying at least a portion of the card data corresponding to the card (described later). Processing is also acceptable. In that case, there are no particular restrictions on what is being changed in the card data, but for example, These are card parameters such as card name, card image, and rarity. Card evolution and synthesis are performed by This is an example of a process that changes an object. To perform evolution synthesis, the user must use the cards they possess (hereinafter referred to as "possessed cards" as appropriate). From among them, choose the card you want to evolve (that is, the card data change process). Select a base card (the card to be used as the symbol). This is an example of a selected object. In evolution synthesis, each base card requires multiple components to evolve that base card. The combination conditions for the cards (referred to as "reference cards") are predetermined. Evolution synthesis is performed. When this happens, the reference card used in the evolution synthesis disappears from the user's card collection. In the game of this embodiment, the card selected by the user as the base card corresponds to The user must possess all of the multiple reference cards that constitute the combination conditions for selection. These are the conditions for evolving a card (an example of a change condition).

[0031] In the game of this embodiment, the process of a user losing their own cards is, for example, Normally, synthesis and sales processes are provided. To perform a normal synthesis process, the user must From your collection of cards, select a base card that you want to enhance. (Normal synthesis process) Then, the conditions for performing a process that changes a card (for example, an evolution / combination process) are defined. The conditions for change are not determined for each base card, and users can refer to their owned cards as needed. You can choose from the following. When the normal synthesis process is performed, the card parts of the base card Instead of the meter changing (for example, increasing card level or skill level), refer The card will disappear from the user's card collection. In the sale process, selected cards from the user's possessions (for example, cards the user no longer needs) A card (or similar card) is sold for a price corresponding to that card (for example, in-game points). Instead of the seller gaining anything, the sold card disappears from the user's card collection.

[0032] In the game of this embodiment, the user wants to evolve a desired card through evolution synthesis. The user possesses some or all of the reference cards necessary to evolve that card. Let's consider the case where this is not done. In this case, a new card is needed to satisfy the conditions for the combination of reference cards. The desired card evolution synthesis continues until the user obtains the card (i.e., the remaining reference card). It needs to wait to execute. However, the user will need to obtain the remaining reference cards. If you forget the conditions for obtaining the card (hereinafter referred to as "acquisition conditions"), it will be difficult to obtain the reference card in question. It becomes difficult. In particular, the more cards you acquire, the more likely you are to forget the acquisition conditions for each card. The likelihood of this happening increases. Therefore, in this embodiment, multiple reference cards necessary to evolve the base card Among these, the conditions for obtaining reference cards that the user does not possess (unowned cards or unknown cards) This will allow you to display the items. Note that "unowned cards" are cards that have been owned by the user. Furthermore, it is a card that the user does not possess at the time the base card is selected. On the other hand, An unknown card is a card that has never been owned by a user.

[0033] The conditions for obtaining the reference card will be explained in detail with reference to Figure 4. This diagram conceptually explains the conditions for obtaining the special cards. In Figure 4, consider the case where a user wants to evolve card Q, which is one of their owned cards. Here, in order to evolve card Q, we use multiple reference cards such as cards A, B, and C. This assumes a scenario where the following combination is required. The user does not currently possess card B. Furthermore, evolution synthesis cannot be performed on card Q. Also, the user cannot enter card B. Since I've forgotten the conditions, it's also difficult to obtain card B. In that case, the actual implementation... In this situation, the user is required to present the conditions for obtaining card B so that they can easily obtain card B. Accordingly, the conditions for obtaining card B are presented to the user. As a result, the user obtains card B. It is easily available.

[0034] (1-5) Data table structure Next, the card data table stored in the storage 25 of the game server 20, evolution combination Completion data table, quest data table, owned card data table, reservation data table Regarding the table, possession history data table, and card distribution data table, see Figure 5~ Refer to section 11 for further explanation.

[0035] (i) Card data table The card data table records the data of the cards used in the game of this embodiment. Figure 5 shows an example of the card data table structure. In the example shown in Figure 5, the card ID Each entry includes the card name, card image, and card parameter data. Card ID is identification information that identifies a card, which is an example of an object. The letter D is uniquely assigned to each card. The card ID allows you to select one card from among multiple cards. The card is identified. In other words, the card ID is an object identifier that identifies the object. This is an example of information. The card name is a string of characters that indicates the name of the character displayed on the card. The card image is This is the image of the character displayed on the card. Card parameters include rarity and attribute. It consists of data such as cost, skill, selling price, attack power, defense power, and limited flags. It is being done. Rarity is an indicator of a card's scarcity value, and in the example shown in Figure 5, the order is R1 to R5. It has a high rarity rating. The attributes are the attributes of the characters displayed on the card, and in the example shown in Figure 5, N1 to N3. It is one of the two. The cost is a value referenced when adding a card to a user's card team. For example... When playing a card team match, the total cost of the cards included in the card team The sum is limited to a predetermined value or less. Skills are information that indicates an advantageous effect when playing the game using cards. In the example shown in Figure 4, each card is assigned skills with various effects, from SK1 to SK12. It is not necessary for all cards to possess skills. The selling price is the amount a user receives when they sell a card they own. This is a key point on the map. Attack power and defense power are parameters that are referenced when using cards in battle. The limited flag indicates whether or not the card was issued for a limited time. See Figure 4. In the example shown, a card with the limited flag set to "1" is a card issued for a limited time only. This means that cards with a limited flag of "0" are not limited-time cards. ru.

[0036] (ii) Evolutionary Synthesis Data Table The evolution synthesis data table records the conditions for the evolution synthesis of the game cards in this embodiment. Figure 6 shows an example of the structure of the evolutionary synthesis data table. In the example shown in Figure 6, evolutionary synthesis For each evolution ID used to identify the contents, the pre-evolution card ID (i.e., the pre-evolution base card) Card ID of the card that will become the base card, evolved card ID (evolved card of the base card) The card ID of the reference card, which is required to perform evolution synthesis, and the change in the card ID of the reference card. The number of reference cards (the five reference cards in columns C1 to C5) is recorded. For example, Evolution ID: 000 Under the conditions indicated in 2, the user selects the card with card ID:0072 from among the cards they possess as the base. Select as a card, and the card ID: 0025,0060,00 is among the user's owned cards. If there is a combination of 70 three cards, you can perform evolution synthesis to create a new card. You can evolve the card with card ID:0072 into the card with card ID:9072. . Here, as an example of a process that changes an object, we will show an example of an object called Ka This section explains the process of card evolution and synthesis. As mentioned above, card ID is object identification. This is an example of alternative information. In other words, Figure 6 shows multiple methods used in the process of changing an object. This indicates that the object identification information is included in the change condition. Furthermore, in columns C1 to C5, which show the combination of card IDs of the reference card, at least one of them must be present. Sometimes the same card ID is recorded in two fields. For example, if you advance the base card... When using a combination of reference cards for chemical synthesis, if the combination includes two or more identical reference cards... It is also acceptable. The combination condition for reference cards to evolve a base card is that the same card I If a predetermined number of reference cards designated as D are included, the data format will be as shown in Figure 6. The data format may also consist of the card ID of the reference card and the number of cards, rather than being an expression.

[0037] (iii) Quest Data Table The quest data table contains one of the events that take place in the game of this embodiment. Quest data is recorded. Quests are undertaken to obtain cards and items. The goal is for the user to explore areas within the game and complete the specified quest conditions. This is an event. Figure 7 shows an example of the structure of the quest data table. In the example shown in Figure 7, Information about the area name, stamina cost, and obtainable cards for each Est ID (card ID and Information on obtainable items (item ID and acquisition rate), boss ID This includes quest UI data. The area name is a string of characters that indicates the name of the area used in the quest. Stamina consumed is a value referenced when undertaking a quest. The user's stamina value, one of their parameters, must be greater than or equal to the stamina consumed. When a strike is performed, the user's stamina value is consumed by the amount of stamina consumed. Information about available cards (Available Card Data 1, 2…) includes the card ID and input It is composed of a rate. The card ID is a card that can be obtained when the quest conditions are met. This is the identification information for the card. The acquisition rate is the probability of obtaining the card when the quest conditions are met. This is a numerical value that indicates [something]. Information about obtainable items (Obtainable Item Data 1...) includes the Item ID and It is composed of acquisition rates. The item ID is obtained when the quest conditions are met. This is item identification information. The acquisition rate indicates the chance of obtaining the item when the quest conditions are met. This is a numerical value that indicates the probability of success. The boss ID is the identifier of the NPC (for example, the boss character) you will be fighting in the quest. This is a report. The quest conditions are fulfilled, for example, by defeating a boss character. It can be done. Quest UI data is user interface data used in quests (for example) (Image data used in quests.)

[0038] (iv) Owned Card Data Table The owned card data table records information about the user's owned cards. (See Figure 8) An example of the configuration of the owned card data table is shown. Figure 8 shows the owned card data table for one user. Using Bull as an example, the owned card data table includes all users registered in the game. It is provided in response to this. The card data table shown in Figure 8 includes the serial number and card information for each card ID. Level, skill level, and reservation ID data are all recorded and associated with each other. The serial number is a unique number determined when the card is issued to the user. A different serial number will be assigned to each card with a different card ID. In that case, you may change the serial number of the card before and after evolution, or you may not change it. That's fine. Card level is a parameter that indicates the level of development of a card, for example, when performing the normal synthesis described above. It increases by performing the action. The value of the card level at the time the user acquires the card (initial The initial value is 1, and the user can usually grow the card by performing synthesis, etc. You can increase the level. Skill level is a parameter that indicates the level of development of a card, and in particular, the skills that the card possesses This parameter indicates the skill level at the point when the user acquires a card with the skill. The skill level value (initial value) is 1, and for example, a card that meets a certain condition is a reference card. By performing a normal synthesis, you can increase the skill level of the card. As the skill level of a skill increases, the effects produced by that skill become greater. The reservation ID is identification information used to identify the reservation details for evolution synthesis. Reserved car The cards held by users marked as "Do" are associated with a reservation ID. For example, in Figure 8 In the example shown, there are five cards with IDs: 0591, 0010 (2 cards), 0033, and 2005. This indicates that the card is reserved. It is recorded in the owned card data table. The reservation ID corresponds to the reservation ID recorded in the reservation data table described later.

[0039] (v) Reservation data table The reservation data table records information about cards reserved by the user for evolution synthesis. Figure 9 shows an example of the configuration of the reservation data table. Figure 9 shows the reservation data table for one user. Using Bull as an example, the reservation data table corresponds to all users registered in the game. It is established in this way. In Figure 9, the reservation ID is an ID issued in the order in which the evolutionary synthesis reservation is made. Figure 9 In the example shown, the numbers are recorded in ascending order, such as 01, 02, ... The evolution ID is This corresponds to the evolution ID shown in the synthesis data table, and is an ID that identifies the content of the evolutionary synthesis. That is the case. Of the serial numbers on reserved cards, the serial numbers on pre-evolution cards are the base for evolution synthesis. This is the serial number of the card the user has selected as their card. Reserved card The serial numbers on the card, specifically columns C1 to C5 on the reference card, correspond to the evolution synthesis data. This corresponds to the C1-C5 fields that make up the combination of reference card IDs on the table. If the reserved reference card is a card you possess, the card ID corresponding to that reference card will be... The serial number of your owned card data will be recorded in the field. If the reserved reference card is not owned... If it is a card, enter a temporary serial number (for example) in the field corresponding to the card ID of the reference card. "00000000") is recorded, and the reference card becomes a card in possession (that is, The card data possessed is identified by the card ID and serial number of the reference card. After it is added, the temporary serial number is overwritten with the serial number of the reference card in question. The field corresponding to the card ID of a reference card that is not reserved will contain data indicating "Not reserved". (For example, NULL) is recorded. The following explanation will describe the case where a reservation data table is set up, but the reservation data table It is not essential to have a separate table. As a method for managing reservations for evolution synthesis, The data that should be recorded in the reservation data table may be recorded in the owned card data table instead. In that case, the card ID of the reserved card will be in the owned card data table. Attach the reservation ID, evolution ID, or one of the strings C1-C5 (evolution synthesis data table). Any string corresponding to cells C1 through C5 will be recorded.

[0040] (vi) Possession history data table The possession history data table records information about the cards that the user has owned. Figure 10 shows an example of the configuration of the possession history data table. Figure 10 shows the possessions of one user. The history data table is shown as an example, but the possession history data table is registered in the game. It will be provided to all users. The possession history table shown in Figure 10 records the number of times each card ID has been acquired. It is. The number of times obtained is a value that indicates the number of times the user has obtained the card in the game. Cards with 0 moves are unknown cards.

[0041] (vii) Card Distribution Data Table The card distribution data table stores information about the cards circulating within the game. Figure 11 shows an example of the card distribution data table configuration. In the example shown in Figure 11, The card distribution data table records the number of cards in circulation and the average transaction price for each card ID. Yes, they are. The number of cards in circulation is the number of cards that users have set as the subject of trading (e.g., buying and selling) within the game. This value indicates the total number of cards. A higher number in circulation means that the card is easier to obtain. ru. The average transaction price is the average price at which users trade cards with each other. The higher the rank, the more difficult it is to obtain the card.

[0042] The following explanation covers the card data table, quest data table, and owned card data. In the table, possession history data table, and card distribution data table, the card Information associated with the ID (e.g., card name, card image, card parameters, quest) Quest ID, Area Name, Stamina Cost, Acquisition Rate, Boss ID, Quest UI Data, Serial Number, (Card level, skill level, reservation ID, number of times obtained, circulation number, and average transaction price) Collectively, this will be referred to as "card data" as appropriate. Card data is a piece of information that identifies an object. This is an example.

[0043] (1-6) Specific examples of the process of presenting acquisition conditions and the process of evolution and synthesis The following are specific examples of the process for presenting the acquisition conditions and the evolution / synthesis process for the game cards of this embodiment. This will be explained with reference to Figures 12A, 12B, 13A, 13B, and 14. To clarify, Figures 12A, 12B, 13A, 13B, and 14 are shown in this implementation. This shows an example of a screen displayed on user terminal 10 while processing a game of this type. This is a diagram.

[0044] (1-6-1) Processing of presenting acquisition conditions (1-6-1-1) Processing to show the conditions for obtaining unowned cards (Figures 12A and 12B) Figures 12A and 12B show the conditions for obtaining cards that you do not yet possess. This shows a series of changes in the display screen during processing. In Figure 12A, image P1 is the image of this embodiment. In this game, users have access to monster cards (hereinafter simply referred to as "cards") This is an image of the process when a request for processing is made. Image P1 shows a button as the target of user interaction. b1 ("View owned monsters"), button b2 ("Team formation"), button b3 ("Continue") Buttons for "Normal Synthesis", button b4 ("Evolution Synthesis"), and button b5 ("Sell") are provided. Button b1 is the button that is operated when the user requests to view the cards they possess. Yes. Button b2 allows the user to choose a card from their own collection to play against other users or NPCs. This is a button that is operated when selecting the card to be used. Button b3 is for the user When you request the normal synthesis process for the card you have selected as the base card from your possessions, This is a button that is operated. Button b4 is the base card that the user selects from their owned cards. This is the button that is operated when requesting the evolution and synthesis process of the selected card. b5 is the process when the user requests a sale for a card selected from their owned cards. It is a button that is operated at that time.

[0045] When button b4 ("Evolution Synthesis") is operated in image P1, the image shown in P2 will appear. The result changes. In image P2, the user selects one of the cards from their possessions to use as the base card. Multiple cards you own will be displayed in a list for selection. Note that they can evolve. For cards that cannot be used (in the example shown, cards TOM, TED, DSG), the base car The image is structured in such a way that it cannot be selected as a user. In other words, in image P2, the user A display that allows the user to distinguish between cards that can evolve and those that cannot. This is shown in format. It provides a user-friendly display that distinguishes between cards that can evolve and those that cannot. The method of showing the format is not limited to the example shown in image P2 of Figure 12A. The list of owned cards is each It may also be a list of card names, in which case the cards that can evolve and the evolving cards Cards that cannot be modified may be distinguished from those that cannot be modified by the brightness, size, etc. of the text. In image P2, for example, card KLM is selected as one of the cards that can evolve. Then, the image changes as shown in P3. Image P3 shows the evolution synthesis of the selected card. Button b6 ("Select") confirms it as a card, and then return to image P2 and select This includes button b7 ("Back") for selecting the card as the base card. When button b6 is operated in image P3, card K is selected as the base card. If the reference card requirements for LM to evolve are not met, it will be shown on page 4. The sea urchin image has been updated. Image P4 shows the evolution of card KLM, which was selected as the base card. An image to request the acquisition conditions for any unowned reference cards needed to do so. That is. Furthermore, when the user selects button b6 in image P3, the base card and The selected card KLM meets the requirements for the reference card needed to evolve. In the event of a match, an image (not shown) will appear requesting the execution of the evolution synthesis of card KLM. .

[0046] Image P4 shows the pre-evolution card (in this case, the base card, card KLM) and the evolved card. Display area 101 showing a card (e.g., card QRS), reference card required for evolution synthesis and a display area 102 that shows its status (possessed, not possessed, reserved, or unknown), Button b8 ("Show acquisition conditions") is used to request the acquisition conditions for the reference card. It is included. In image P4, the reference card that should display the acquisition conditions (here, display area 1) When a card (DSG) indicating "Not Owned" is selected in 02, and button b8 is operated Then, as shown in Figure 12B, the acquisition conditions for the reference card selected by the user are indicated. Image P5 is displayed. The reference card selected by the user is referred to as "Reference specified by the user". It is also called a "card". Furthermore, a reference card is an example of an object, so "by the user" The "specified reference card" is an object specified by the user. This is an example of a "project."

[0047] Image P5 in Figure 12B shows the reference card selected by the user (here, card D). SG), as well as the card image, card name, and rarity of the reference card. It includes a display area 103 and a display area 104 that shows the acquisition conditions for the reference card. Area 104 contains information on the difficulty of obtaining the item 104a (here, the number of times it can be obtained, the number in circulation, and Information regarding the average transaction price, and the source of acquisition (here, the area of ​​availability). ) is shown.

[0048] (1-6-1-2) Processing of presenting the conditions for obtaining unknown cards (Figures 13A and 13B) Figures 13A and 13B show the conditions for obtaining the unknown card. This shows a series of changes in the display screen. Images P1 to P3 in Figure 13A correspond to Figure 12 This is similar to images P1-P3 in A. Image P4 in Figure 13A shows an unknown card in the display area 102, which is different from Figure 1. Image 2A is different from P4. An unknown card is a card that the user has never owned. Never (for example, the value of "Number of times obtained" in the possession history data table is 0) ) This is a card. In image P4, the reference card that should display the acquisition conditions (here, display A card indicating the state "unknown" in area 102 is selected, and button b8 is operated. As shown in Figure 13B, this indicates the acquisition conditions for the reference card selected by the user. Image P5 is displayed.

[0049] Image P5 in Figure 13B shows the reference card selected by the user in the display area 103. An image is shown indicating that the card is unknown to the user, and display area 10 4. Information regarding the difficulty of obtaining the reference card in question 104b (here, Only the number of transactions and the number of transactions in circulation are shown (i.e., the acquisition process in image P5 of Figure 12B). It differs from image P5 in Figure 12B in that road information 104a is masked. .

[0050] (1-6-2) Evolutionary synthesis process (Figure 14) Figure 14 shows a series of display screen changes when performing an evolutionary synthesis process based on user input. This shows the transformation. In Figure 14, image P10 shows a new card being added while the user is playing the game. This is an example of an image that appears when you obtain a DSG. By obtaining this new DSG card, the pre-ordered evolution synthesis conditions have been met. If this occurs, the condition for the change will be met by obtaining a new card. It is preferable to notify the user when this happens. More preferably, as shown on P11. It is preferable to display an image for performing evolutionary synthesis. Image P11 shows the pre-evolution card (Card KLM) and the post-evolution card (Card QRS). Display area 101, a table showing the reference cards required for evolution synthesis and their status (in this case, possession). Display area 102, and button b2 for receiving a request to perform evolutionary synthesis or not. 0 ("Yes") and button b21 ("No") are displayed. When button b20 is operated in image P11, the image changes as shown in P12. In the example shown in image P12, the card image, card name, and parameters of the evolved card are shown. At the very least, some of it will be displayed.

[0051] (1-7) Overview of the functions of the information processing device Next, the functions that the game server 20 has in order to realize the game of this embodiment described above are Let me explain. Figure 15 shows the functions that play a major role in the game server 20 of this embodiment. This is a functional block diagram for explanation. In Figure 15, the data table group 70 is as described above. As shown above, card data table, evolution synthesis data table, quest data table , owned card data table, reservation data table, ownership history data table, and, Includes a card distribution data table. Note that the means included in the functional block diagram shown in Figure 15 are... Not all of these elements are essential to the present invention.

[0052] The reception means 51 receives various requests from the user based on information about the user's operation input. It has a function to accept requests. In the game of this embodiment, a request from the user would be, for example, Then, requests for processing the conditions for obtaining cards, requests for evolution and synthesis processing, requests for quest processing, Requests for scheduling chemical synthesis, requests for executing evolutionary synthesis, requests for viewing the user's owned cards, This includes requests for the sale of cards owned by the user. The request for processing to present the acquisition conditions is made in response to the output of image data by the output means 56. This is a request to reveal the conditions for obtaining the reference cards necessary for the evolution synthesis of the base card. A request for the reservation processing of evolutionary synthesis is made in response to the output of image data by the output means 56. In evolution synthesis, the base card and multiple reference cards corresponding to the base card. At least one of these cards must be reserved for evolution synthesis, and the user must possess that card. Among the processes that are executed on the condition that the card disappears, processes other than the evolution synthesis in question ( For example, it can be used in the process of selling the card or transferring the card to another user. This is a request that restricts what can be there. The request for the reservation process of evolution synthesis is subject to reservation. The card ID of the reference card is included. In order to implement the functions of the reception means 51, the game server 20 has a communication interface unit 2 The user can operate buttons on a web page, which is an image, via 4 from the user terminal 10. The game server 20 receives a request corresponding to the input. The CPU 21 of the game server 20 receives the request. Based on the information received, the content of the request is determined and the request is processed. In the processing of the request, This is recorded in RAM13. The CPU21 then sequentially executes the processing according to the received requests. do.

[0053] The game processing means 52 is based on the requests and instructions from the user received by the reception means 51. Therefore, it is equipped with a function to perform various game processes other than evolution and synthesis. The processing of the user may be provided as appropriate, for example, processing of matches between users, and processing of matches between users and NPCs. Battle processing, user-submitted quest processing, normal synthesis processing of user-owned cards, user's This is the process of selling your cards. I won't go into detail about the battle processing, but for example, the user's total cost is limited to a predetermined upper limit. Form teams from multiple cards you already possess so that the total value is less than or equal to the value, and then, depending on the team, You will play against other users or NPCs. The battle results will be based on the attack power and defense of each card that makes up your team. It is determined by parameters such as strength and skill.

[0054] The function of the game processing means 52 when executing quest processing is implemented as follows: The CPU 21 of game server 20 receives a request for quest processing, including the quest ID. When attached, the quest data associated with the quest ID will be retrieved from the quest data table. Data (Area name, stamina consumed, acquired card data (card ID and acquisition rate), acquired item) Read the data (item ID and acquisition rate, boss ID, and quest UI data). It is extracted and loaded into RAM23. Next, CPU21 uses the quest UI data to The game displays the execution screen for Est and progresses the quest according to the user's actions. When the quest progresses to a certain level, CPU21 will execute the boss key associated with the boss ID. A match is held between the character and the user. If the user fulfills the victory conditions in that match, CPU21 assigns cards according to the "acquisition rate" value associated with the quest ID. The process is executed. In the process of assigning cards, CPU21 is associated with the quest ID. The acquired card ID is written to the owned card data table, and the owned history data table is also written to the owned card data table. The value of "Number of Acquisitions" associated with the card ID in the program is increased. Furthermore, if the user meets the victory conditions in the match, the system will also award them items. This process is executed in the same way as the process of granting a card.

[0055] The function of the game processing means 52 when performing the normal synthesis process of the user's owned cards is as follows: This is achieved as follows: The CPU 21 of the game server 20 is the base card and When a request to perform a normal synthesis is received, including the user's selection results regarding the light card, the owned cards Read the card data of the base card and reference card from the card data table and RA It deploys to M23. Next, CPU21 checks the parameters of the base card and reference card. Based on this, the parameters of the base card (for example, card level or skill level) are changed. The parameters of the modified base card are written to the owned card data table, and Delete the card data of the owned card that was used as a reference card from the owned card data table. Oh, the base card's card level and skill level always increase each time you perform a normal synthesis. This is not always the case. For example, each time you perform a normal synthesis, the training parameters associated with the card are processed. Increase the value of the "Ta" parameter, and when the value of that training parameter reaches a predetermined value, the card level increases by one. You may also increase the value of the training parameter and reset it to zero.

[0056] The functions of the game processing means 52 when executing the process of selling a user's owned cards are as follows: This is how it is achieved. The CPU 21 of the game server 20 receives the request for sale processing, Once the selection of cards to be sold is received, the system will search the owned card data table for the cards to be sold. The card data is deleted. Then CPU21 sells it from the card data table. The system reads the selling price (points) of the target card and assigns the read points to the user. The process of assigning points is performed. For example, the process of assigning points to users is performed using the user database. This process updates the value of the user's points, which is recorded in (not shown).

[0057] The card data modification means 54 is when all of the multiple reference cards that satisfy the modification conditions are located at the user's location. If included in your hand, perform an evolution synthesis that modifies the base card's card data. It has a function. In this embodiment, in order to realize the function of the card data modification means 54, the game server When CPU 21 of unit B20 receives a request to execute evolution synthesis, it checks the owned card data table. In this process, the card data of the pre-evolution card (i.e., the base card for evolution synthesis) is deleted. The card data for the evolved card is newly written. This will update the user's card collection. The card will evolve. Note that, as shown in the evolution synthesis data table, pre-evolution Since the card ID is different for the evolved form, the card name, card image, and card parameters are different. At least one of the "Ta"s will be changed through evolutionary synthesis.

[0058] The acquisition means 55 is a base card (an example of a selected object) selected by the user. The combination conditions for the corresponding reference cards (an example of a change condition) are multiple reference card IDs, It has a function to obtain data from the evolutionary synthesis data table. In addition, the acquisition means 55 is user-defined The selected reference card is not a card you own (for example, a card you do not own or an unknown card). If this is the case, the card data of the reference card will be stored in the quest data table and possession history. It includes the ability to retrieve data from data tables and card distribution data tables. Acquisition method 55, when reserving a card for evolution synthesis, allows the user to input an operation. Based on this, the serial number of one of the cards owned by the user (object) It has a function to obtain an example of the information to be displayed. When acquisition means 55 acquires multiple reference card IDs which are the combination conditions for reference cards, The CPU 21 of the game server 20 retrieves the base card selection result from the user terminal 10. Depending on the result, refer to the evolution synthesis data table and select the combination rule corresponding to the base card. Read the multiple reference card IDs that make up the item. When acquisition means 55 acquires card data of a reference card selected by the user, The CPU 21 of the game server 20 retrieved the selection result of the reference card from the user terminal 10. Accordingly, the quest data table, possession history data table, and card distribution Refer to the data table and read the card data for the referenced card. When acquisition means 55 acquires the serial number of the card, the CPU 21 of the game server 20 When a request for a reservation process for evolution synthesis is received from the user terminal 10, the target of evolution synthesis will be... From among the base card and multiple reference cards corresponding to the base card, reserve Identify any cards you still possess by referring to the owned card data table, and then identify the identified cards. Read the serial number.

[0059] The output means 56 outputs a plurality of reference cars included in the change conditions acquired by the acquisition means 55. Using the card data, the multiple reference cards are displayed in a way that allows the user to identify each one. A function to output the first output data (for example, image data) to be displayed in an equation (hereinafter referred to as "the first"). It has a "1 output function." In this embodiment, in order to realize the first output function of the output means 56, the game server 2 CPU21 of 0 is, for example, the base card selected by the user. The combination of multiple reference card IDs required to evolve a card is called the evolution synthesis data. Read from the table, for each reference card, owned card data table, reserved data table Based on the information stored in the table and the possession history data table, the card status ( Identify one of the following states: "Reserved," "Owned," "Not Owned," or "Unknown." Furthermore, the CPU21 displays the status of each reference card in a user-identifiable format. Generates the first output data. For example, in the reservation data table in Figure 9, the evolution ID corresponding to the base card corresponds Enter the serial number or temporary serial number included in your card data in the C1-C5 fields. If a card number is recorded, it will be identified by the card ID corresponding to the relevant field. The status of the reference card is identified as "reserved". For example, for cards whose status is anything other than "Reserved," see the evolution synthesis data table in Figure 6. In Bull, the cards in the C1-C5 columns are associated with the evolution ID corresponding to the base card. If the card ID is included in the "Card ID" column of the owned card data table in Figure 8, The status of the reference card identified by the card ID is identified as "possessed". For example, for cards whose status is anything other than "Reserved" and "Owned," see Figure 10. In the card history data table, the "Number of Acquisitions" column corresponding to the card ID is not 0. In that case, the status of the reference card identified by the card ID will be identified as "not owned". Furthermore, if the "Number of times obtained" column corresponding to the card ID is 0, the card ID The state of the reference card identified by this is identified as "unknown". The first output data shows the status of the identified reference card.

[0060] Furthermore, the output means 56 outputs a reference card ID corresponding to the reference card ID acquired by the acquisition means 55. Second output data to show the conditions for obtaining the reference card (a card not yet possessed or the unknown card in question) It is equipped with a function to output data (for example, image data) (hereinafter referred to as the "second output function"). . In this embodiment, in order to realize the second output function of the output means 56, the game server 2 CPU 21 of type 0, for example, when the reference card ID is obtained by acquisition means 55, Based on the obtained reference card ID, the quest data table, possession history data table, And, refer to the card distribution data table and the reference card corresponding to the reference card ID. Identify the conditions for obtaining the item and generate a second output data file to present those conditions. For example, in the quest data table in Figure 7, the "Card ID" of "Acquired Cards" The information in the "Area Name" field corresponds to the quest ID containing the reference card ID obtained in the field. The information is identified as an area where it is available. In the possession history table in Figure 10, the "Number of Acquisitions" corresponding to the acquired reference card ID is displayed. The value in the " " column is identified as the number of times it has been obtained. In the card circulation data table of FIG. 11, the values in the columns of " Number of Circulations" and "Average Transaction Price" corresponding to the acquired reference card ID are respectively specified as the number of circulations and the average transaction price and specified. In the second output data, at least one of the specified available area, number of acquisitions, number of circulations, and average transaction price is shown.

[0061] In response to receiving a request for reservation processing of evolutionary synthesis, the recording means 57 stores the serial number acquired by the acquisition means 55 in the reservation data table in the storage 25 as a reserved card and has a function of recording it. In the example of this embodiment, the reservation target card is a card whose use for processing other than the evolutionary synthesis of the selected base card is restricted.

[0062] To realize the function of the recording means 57, when the CPU 21 of the game server 20 receives a request for reservation processing of evolutionary synthesis, it accesses the reservation data table and writes the serial number of the reservation target card. More specifically, when the serial number of the card selected as the base card among the reservation target cards is not recorded in the reservation data table, a new reservation ID is issued. The CPU 21 writes the serial number of the card selected as the base card in the column of "Pre-evolution Card" in association with the issued reservation ID. Furthermore, it specifies the column of "Reference Card ID" (any one of the columns C1 to C5) that is the same as the card ID corresponding to the serial number of the reference card among the reservation target cards, and writes the serial number of the reference card among the reservation target cards in the specified column. On the other hand, when the reservation ID has already been issued, the serial number is in the column of "Pre-evolution Card" already written. ​​​​​​Since it has already been recorded, CPU21 is the serial number of the reference card among the reserved cards. Only the issue number will be written.

[0063] Restriction means 58 is that a card recorded as a reserved card in the reservation data table is It has a function to restrict its use to processes other than the intended evolutionary synthesis. "Used for processes other than evolutionary synthesis" means that the intended evolutionary synthesis is reserved. Cards recorded as cards may undergo evolution synthesis or normal synthesis other than the intended evolution synthesis. This also includes cases where it is used in that way. Various methods can be considered for the restriction by the restriction means 58. For example, the car to be restricted Methods to prohibit processes other than the evolution synthesis intended by the user, and cards that are subject to restrictions. When selected for a process other than the intended evolutionary synthesis, the user is informed of the process. This includes methods for performing actions to confirm the continuation of the process. Regarding reserved cards, "restricting their use in processing" means that reserved cards This is not limited to prohibiting any process other than the intended evolutionary synthesis using the reserved car While it is possible to perform processes other than the intended evolutionary synthesis using the "do" method, the procedure for executing those processes is... This may involve making it difficult to do so, or complicating the processing procedure. Reserved Card Regarding "processing other than evolution synthesis," reserved cards disappear from the user's card collection. A process that is executed on the condition that a reserved card is changed to a card that is not owned. It is particularly preferable that the process be restricted if it is a process that is executed as a condition.

[0064] For example, the CPU 21 of the game server 20 is responsible for any of the various processes of the game in this embodiment. If a request to execute that process is received, the user's cards will be selected as the cards to be processed. When selected, the card data table is referenced, and the card of the selected card is determined. Determine whether a reservation ID is associated with the ID. CPU21 selects The card ID of the selected card is associated with the reservation ID, and the processing related to the execution request is the reservation ID If it is not an evolutionary synthesis process corresponding to the selected process, the process may be prohibited, or the selected process may be prohibited. The user may be notified that the card is a reserved card. Alternatively, the selected card The system will inform the user that the card is already reserved and ask whether they wish to proceed with the transaction. You may confirm with the user. The reservation data table contains the evolution ID and the serial number of the reserved card. Because the number is associated, CPU 21 of game server 20 corresponds to the reserved card. Furthermore, it is necessary to identify the target evolutionary synthesis (i.e., the evolutionary synthesis corresponding to a specific evolutionary ID). This is possible. Therefore, the process that the user attempts to perform using a specific card they possess is the objective. It is possible to determine whether or not this is an evolutionary synthesis process.

[0065] Although it is not essential to provide recording means 57 and limiting means 58, recording means 57 and By providing the restriction means 58, for example, one of the multiple reference cards required for evolution synthesis Reserve the reference cards for the section before performing evolution synthesis, and continue evolution synthesis until you obtain the remaining reference cards. A user waiting for a process to start accidentally uses their cards for a process other than evolution / fusion. This can prevent that.

[0066] (1-8) Processing flow of the game of this embodiment Next, an example of the game processing flow of this embodiment is shown in Figures 16A, 16B, and , it will be described with reference to the sequence chart of FIG. 17. FIGS. 16A and 16B are sequence charts showing the presentation process of acquisition conditions. FIG. 17 is a sequence chart showing the evolution synthesis process. In each figure, the reference numerals of each image are attached to the steps where each of the images P1 to P5 and P10 to P12 shown in FIGS. 12A, 12B, 13A, 13B, and 14 are displayed. are attached.

[0067] (1-8-1) Presentation process of acquisition conditions (FIGS. 16A to 16B) In the presentation process of acquisition conditions described below, as an example, when the user has a base card and a part of a plurality of reference cards for evolving and synthesizing the base card, it is assumed that a request is made to present the acquisition conditions for the unowned or unknown reference cards.

[0068] In FIG. 16A, when the user operates a predetermined button (for example, the button b4 of the image P1 in FIG. 1 [[ID=​​​​​​​​​​​​​​​​​​​​​Identify card candidates and generate image data containing the card data of the base card candidate (S 16) The image data is sent to the user terminal 10 (S18). The image data generated in S16 is shown in image P2 in Figure 12A or Figure 13A. As shown, images of cards that can evolve and cards that cannot evolve from the user's possessions. It is preferable that the output be generated in such a way that it has a different display mode than the output shown.

[0069] When the CPU 11 of the user terminal 10 receives the image data transmitted in S18, The image is displayed on the display unit 16 based on the image data (S20). The image displayed in S20 As illustrated in image P2 of Figure 12A or Figure 13A, there are multiple candidates for the base card. The image contains a number of cards, and by manipulating the image of each card, the serial number of each card can be determined. It is configured to allow selection. Multiple base card candidates displayed in S20 When the user selects any of the cards as the base card, CPU11 receives the selection result (serial number) of the base card (S22), and the selected The selection result is sent to game server 20 (S24).

[0070] The CPU 21 of game server 20 receives the selection result (serial number) sent in S24. When attached, it refers to the evolution synthesis data table and the base card selected by the user. Multiple pre-evolution card IDs that match the card ID associated with the serial number. The reference card ID (card IDs in columns C1 to C5) is read (S26). Then the CPU 21 refers to the owned card data table and the reservation data table and reads in S26 The status of the card corresponding to each reference card ID displayed (not owned, owned, reserved, and unknown) Identify one of the following and generate image data based on the identification result (S28).

[0071] In S28, the CPU 21 of game server 20 performs the following for each reference card ID Identify the status of the corresponding card. CPU21 is recorded in the "Serial number of reserved card" column of the reservation data table. The serial number is read, and the card data table is referenced, and the serial number Identify the card ID associated with the number. Identify the reference card ID read in S26. If the card ID matches, or if the serial number is a temporary serial number In this case, the status of the card identified by the card ID will be identified as "reserved". CPU21 will check the owned cards for reference cards other than those identified as "reserved". The reference card ID of the reference card in question is among the card IDs recorded in the data table. If included, the status of the card identified by the reference card ID is "possessed". Identify it as such. CPU21 collects ownership history data for cards other than those marked as "reserved" and "owned". If the value associated with the reference card ID in the "Number of times obtained" column of Bull is not 0, then the reference card The status of the card identified by the card ID is identified as "not owned," and the ownership history data is... If the value associated with the reference card ID in the "Number of times obtained" column of the table is 0, then the reference The card status, as identified by the card ID, is classified as "unknown".

[0072] In S28, CPU 21 of game server 20 read all reference cards read in S26. If the status of the card is "Owned" or "Reserved," perform the evolution synthesis of card KLM. It generates image data for the user to indicate whether or not to proceed. CPU21 reads in S26. If the status of at least one of the reference cards you played is "Not Owned" or "Unknown" This is an image data to show the acquisition conditions for reference cards that are in the "not owned" or "unknown" state. Generates a file. Here, the image data that will become the source of image P4 in Figure 12A or Figure 13A is generated. Let's assume that this has been achieved.

[0073] Next, the CPU 21 of the game server 20 sends the image data generated in S28 to the user terminal 1 Send to 0 (S30). The CPU 11 of the user terminal 10 processes the image data sent in S30. When a data entry is received, an image based on that data is displayed on the display unit 16 (S32).

[0074] The image displayed in S32 is as shown in image P4 in Figure 12A or Figure 13A, S2 The user needs to select multiple reference cards to evolve and synthesize the base card chosen in step 2. It is displayed so that it can be identified. Image P4 in Figure 12A or Figure 13A is the respective reference case. The status of the card is displayed in correspondence with the reference card, and also for cards you do not own or unknown cards. The system is configured to accept requests for processing to present the conditions for obtaining the product. Here, Figure 12A or Figure After image P4 of 13A is displayed, an operation is performed to request the presentation of acquisition conditions (for example) If the user performs the operation of button b8 in image P4 of Figure 12A or Figure 13A, The CPU 11 of the user terminal 10 then obtains the following based on the user's instructions corresponding to that operation. The system receives a request for processing to present conditions (S34) and sends the request to the game server 20. S36). In S36, the request sent from user terminal 10 to game server 20 includes the user Unowned or unknown cards selected by (i.e., when presenting acquisition conditions) This includes the card ID of the card (for which the acquisition conditions should be presented). As mentioned above, the reference card selected by the user is specified by the user. This is an example of a specified object that is a subject. In other words, the processing in S34 and S36 is Based on user instructions, the system will specify one of several objects. This is an example of a process for receiving a request.

[0075] The CPU 21 of game server 20 receives the request for processing the acquisition conditions sent in S36. When you do this, the card data table, quest data table, and card distribution data will be available. Retrieve the card data of the reference card selected by the user from the table (S3 8) The card name, card image, and rarity are obtained from the card data table. The quest ID and the name of the area where the item can be obtained are retrieved from the quest data table. The number of times it has been acquired is obtained from the ownership history table. The number in circulation and the average transaction price are as follows: This data is obtained from the card distribution data table.

[0076] If the status of the card identified in S28 is "unknown" (S40: YES), then S4 Proceed to step 2, and if the status of the card identified in S28 is not "unknown" (S40: NO) Proceed to S44. Here, as an example of a case where the state of the card is not "unknown" (i.e., an unknown card), This section explains an example of a card whose status is "Not Owned" (i.e., a card that is not owned). Both "Unknown" and "Not Owned" mean that the user does not possess the card (i.e., the card They share the common characteristic of indicating a state where the card ID is not included in the owned card data table.

[0077] In S42, the CPU 21 of game server 20 uses the card data obtained in S38. Among the information about the cards shown, information about the difficulty of obtaining them (here, the number of times they can be obtained, Information other than the number of cards in circulation and the average trading price (here, card name, card image, rarity) Apply a mask to the image so that the "T" and "Availability Area" are not displayed. do. In this embodiment, information other than the information regarding the difficulty of obtaining the unknown card is displayed. The purpose of preventing this is to maintain the sense of anticipation for the game (especially obtaining unknown cards). The goal is to provide something to the user and to enhance the enjoyment of the game.

[0078] In S44, CPU21, based on the card data of the reference card obtained in S38, The conditions for obtaining the reference card in question (however, if it is determined to be "unknown" in S40) Image data (Figure 12B or Figure 1) to present to the user information regarding the difficulty of obtaining the item. The image data (which will be the basis for image P5 of 3B) is generated and sent to the user terminal 10. I believe (S46).

[0079] When the CPU 11 of the user terminal 10 receives the image data transmitted in S46, The image based on the image data is displayed on the display unit 16 (S48). If it is determined in S40 that it is not "unknown" (for example, "not possessed"), then Figure 12B As shown in image P5, the card image, card name, rarity, number of times obtained, circulation, and average price are listed. The discounted price and availability area will be displayed. On the other hand, if it is determined to be "unknown" in S40, as shown in image P5 of Figure 13B, The number of times it has been obtained, the number in circulation, and the average transaction price are displayed, but the card image, card name, and rarity are not shown. Availability and available areas are not displayed. In other words, the information displayed as the acquisition conditions for unknown cards is the acquisition conditions for cards you do not yet own. The information displayed is limited. In other words, S48 is limited to the user. If it is an unknown object that has never been possessed before, the specified object Compared to when the item is not owned, the information displayed as an acquisition condition is limited. This is an example of such a process.

[0080] As described above, in this embodiment, the user possesses the reference card selected by the user. If not (if the reference card is an unknown card or a card not owned), the reference card An example was given showing the conditions for obtaining a certain object. This is a specified object. If the user does not possess the object, the process will display the acquisition conditions for the specified object. This is just one example.

[0081] (1-8-2) Evolutionary synthesis process (Figure 17) For example, a newly acquired card by the user can change the reference card in evolution synthesis. If the conditions are met, the evolution and synthesis process becomes possible. In Figure 17, a predetermined button (for example, Figure 14) is displayed on the image on the user terminal 10. By operating button b20 in image P11, the user can access the CP of user terminal 10. U11 receives the request to execute evolution synthesis (S150) and sends the request to game server 20. Send (S152).

[0082] When the CPU 21 of game server 20 receives the request sent in S152, it will have the necessary data. In the card data table, the pre-evolution card (i.e., the base card for evolution synthesis) Delete the old data (S154) and write new card data for the evolved card (S15 6). Next, the CPU 21 of game server 20, in the owned card data table, The card data of the reference card used for the creation is erased (S158).

[0083] Next, the CPU 21 of game server 20 processes the image data containing the card data of the evolved card. (Image data that will be the basis for image P12 in Figure 14) is generated (S160), and the said image data Send to user terminal 10 (S162). The CPU 11 of user terminal 10 sends in S162 Upon receiving transmitted image data, the image based on that image data (for example, the image in Figure 14) The image P12) is displayed on the display unit 16 (S164).

[0084] As explained above, in the game system of this embodiment, the process of changing objects is One example of this is the evolution synthesis of a card, which requires the base card to be the target of the evolution synthesis. The requirement is that the user possesses the card and all of its corresponding reference cards. Therefore, for example, if you do not possess some of the reference cards among those multiple reference cards In this case, evolution synthesis of the base card cannot be performed. It may be impossible or difficult for the user to obtain reference cards that they do not already own. However, users who are unaware of the acquisition conditions for the reference card will be unable to obtain it. Or, the difficulty of obtaining the reference card (for example, the quest process) ) cannot be recognized at the time of deciding whether or not to perform. In such cases, the user actually They remain concerned that obtaining the reference object may be impossible or difficult. The process to obtain the reference card will be executed. The game server 20 of this embodiment, in response to a user's request, will provide a game that the user does not own. The acquisition conditions for the reference card are presented. Therefore, the base card that will be used for evolution synthesis is... Among the multiple corresponding reference cards, there are reference cards that are impossible or difficult for the user to obtain. Even if such a reference card exists, the user will be aware that obtaining it is impossible or difficult. After that, you can decide whether or not to perform the process to obtain the reference card in question. As a result, it can give users who perform the process of obtaining the reference card a sense of security. ru.

[0085] Furthermore, the conditions for obtaining unowned cards include, at the very least, the acquisition method and the difficulty of obtaining them. It is preferable that one is presented. In this case, the user will be able to obtain the card they do not yet possess. This can give users a sense of security when they perform a task (for example, a quest).

[0086] Furthermore, while the difficulty of obtaining unknown cards is displayed, the method of obtaining them is not provided. (That is, the information displayed as the conditions for obtaining an unknown card is the acquisition of a card you do not yet possess) It is preferable that the information displayed as a condition is more restrictive. In this case, the difficulty of the game While maintaining an appropriate level of difficulty, the process for obtaining the unknown card (for example, quest) This can give users who perform the process (such as stopping the process) a sense of security.

[0087] (1-9) Modified examples of this embodiment The following describes variations of this embodiment. Note that the following variations can be combined as appropriate. be.

[0088] (1-9-1) First variation In image P4 of Figure 12A or Figure 13A, only the card image of the reference card is shown, respectively. The displayed format is shown, but the display format of this embodiment is not limited to this. For example, instead of a display format that only shows the card image, a display format that only shows the card name. It can be a formula, or it can be a display format that shows a combination of card image and card name. stomach. In other words, the display format of this embodiment displays the reference cards in a way that allows the user to identify each one. Any format is acceptable.

[0089] (1-9-2) Second variation In the above embodiment, in S42 of Figure 16B, the card data acquired in S38 is To prevent information other than information regarding the difficulty of obtaining the item from being displayed, the image is marked with a marker. We have explained an example of applying screen processing, but how to prevent that information from being displayed Reason is not limited to this. For example, instead of applying a mask, remove information other than information about the difficulty of obtaining the item. Alternatively, the information may be replaced with a predetermined symbol.

[0090] (1-9-3) Third variation In the above embodiment, at S42 in Figure 16B, the card name, card image, and rarity are... And, although we have described an example of how to prevent the availability area from being displayed, this embodiment This is not the only example. For example, the card image and availability area may be hidden, and only the card name and rarity may be displayed. You may choose to display it. Furthermore, users may be allowed to arbitrarily configure which information is hidden from display.

[0091] (1-9-4) Fourth variation In the above embodiment, in S42 of Figure 16B, the card data acquired in S38 is used Of the information displayed for the card, information other than the difficulty of obtaining it is shown. I have explained an example of how to avoid this, but S42 is optional. If S42 is omitted, the card data obtained in S38 (i.e., the acquisition conditions are presented) All information (regarding the reference card) is displayed, so the user is informed about the reference card. It can create a sense of anticipation that there is a possibility of obtaining the item.

[0092] (1-9-5) Fifth variation Reference cards that the user has owned in the past but does not currently own. If a card that you do not yet possess is selected as a card for which acquisition conditions should be presented, then the acquisition of that card Display at least one piece of information regarding the area where the item can be obtained and the difficulty of obtaining it as an acquisition condition. It is desirable. This means that the specified object has been owned by the user in the past, and the user is currently... If the object is not currently owned, the acquisition condition is: An example of a process that displays at least one of the acquisition methods and difficulty levels of a specified object. be. According to this modified example, users can easily find out how difficult it is to obtain the card in question.

[0093] (1-9-6) Sixth variation In the above embodiment, an example was shown of displaying the conditions for obtaining unowned cards, but unowned cards You may also display the acquisition conditions for cards other than those mentioned above. For example, the acquisition conditions for the cards you own may be displayed. For example, if you own many cards. Sometimes, users forget the conditions for obtaining a certain card they possess. In this case, the card in question By displaying the acquisition conditions for the card, users can re-evaluate the difficulty of obtaining the card they possess. Yes. If a user perceives that the card they possess is difficult to obtain, they may cancel the card they possess. The purpose of the card (for example, which base card's evolution synthesis process it will be used as a reference card for) This can give the user an opportunity to think carefully about the possessions. If it is perceived that the difficulty of obtaining a card is low, it may encourage players to use the card they possess more freely. It can give a gift.

[0094] (1-9-7) Seventh variation In the above embodiment, if all reference cards corresponding to the base card are possessed I have explained an example of how the change conditions are met, but in addition to possessing all of the relevant reference cards... Furthermore, the change condition may be satisfied if the specified additional conditions are met. For example, an additional condition is that the card level of all referenced cards has reached the maximum level. It may be valid if the user possesses a predetermined amount of in-game points. You may do so.

[0095] (2) Second embodiment In the first embodiment, the case in which an image showing the conditions for obtaining an unowned card is displayed will be described. However, in the second embodiment, in addition to the acquisition conditions, the acquisition route for unowned cards is also specified for the user. This section describes an example of displaying an image that includes an object to be manipulated in order to guide the user. Descriptions similar to those of the first embodiment will be omitted as appropriate.

[0096] (2-1) Specific examples of processing for presenting acquisition conditions and processing quests Below, Figure 18 shows a specific example of the process for presenting the conditions for obtaining game cards in this embodiment. I will explain this while referring to it. Figure 18 shows the user when the game processing of this embodiment is being executed. This figure shows an example of a screen displayed on device 10.

[0097] (2-1-1) Processing of presenting acquisition conditions (Figure 18) In image P4 of Figure 12A of the first embodiment, a reference card (this) should display the acquisition conditions. In this case, a card DSG) that shows the status as "not owned" in display area 102 is selected, and When button b8 is operated, the reference car selected by the user is selected, as shown in Figure 18. Image P5, showing the conditions for obtaining the item, is displayed.

[0098] Image P5 in Figure 18 shows, in addition to display areas 103 and 104, button b9 ("Available"). This differs from the first embodiment (image P5 in Figure 12B) in that it includes the phrase "Go to the area." Button b9 is used when the user requests a quest to obtain cards they do not yet own. It is a button that is made. Button b9 is an example of an action that guides the user to the acquisition route.

[0099] (2-1-2) Quest Processing (Figure 18) When button b9 ("Go to Availability Area") is pressed in image P5, the following is shown in P6. The image changes accordingly. Image P6 shows the quest execution screen. The user, By performing the specified operation at statue P6, the area used in the quest (here, Eri) A1) can be explored. When the quest conditions are met, the user will receive the quest day. Based on the probability corresponding to the "acquisition rate" value in the table, you can obtain cards you do not yet own. Cut.

[0100] (2-2) Processing flow of the game in this embodiment Next, an example of the game processing flow in this embodiment is shown in the sequence chart in Figure 19. See the explanation below. Figure 19 is a sequence chart showing the quest processing. Note that in Figure 19, The steps in which each of the images P5 to P6 shown in 18 are displayed are indicated by the corresponding image codes.

[0101] (2-2-1) Processing of presenting acquisition conditions In this embodiment, at S44 (Figure 16A), the CPU 21 of the game server 20 is at S38. In addition to the card data of the acquired reference card, the acquisition method of the said reference card (in this case, Image data (Figure 18) for presenting an object to be operated on in order to guide the user to the accessible area. This differs from the first embodiment in that it generates the image data that will be the basis for image P5.

[0102] (2-2-2) Quest Processing (Figure 19) In Figure 19, a predetermined button (for example, Figure 18) is pressed on the image displayed on the user terminal 10. When button b9) in image P5 is operated, the CPU 11 of the user terminal 10 processes the quest. The request is received (S70), and the request is sent to the game server 20 (S72).

[0103] When CPU 21 of game server 20 receives the request sent in S72, it will initiate the quest. From the data table, quest data associated with the quest ID obtained in S38 ( Area name, stamina consumed, acquired card data (card ID and acquisition rate), acquired item date Based on (item ID and acquisition rate, boss ID, and quest UI data) , generate image data for quest processing (image data that will become the basis for image P6 in Figure 18) (S7 4) The image data is sent to the user terminal 10 (S76).

[0104] When the CPU 11 of the user terminal 10 receives the image data transmitted via S76, The image based on the image data (for example, image P6 in Figure 18) is displayed on the display unit 16 (S78). ).

[0105] Subsequently, the CPU 11 of the user terminal 10 sends instructions to the game server 2 in response to the user's actions. Send to 0. The CPU 21 of game server 20 will process the quest based on the instructions sent. The quest progresses. Once the quest reaches a certain level, CPU21 will assign a corresponding boss ID. The game then proceeds to a battle between the defeated boss character and the user. The user wins the battle. If the conditions are met, CPU21 will determine the acquisition rate according to the value of the "acquisition rate" associated with the quest ID. The process of assigning cards is executed. In the process of assigning cards, CPU21 is responsible for Quest I The card ID associated with D is written to the owned card data table, and the owned record In the history data table, increase the value of "Number of Acquisitions" associated with the card ID. This allows the user to select the car in image P4 of Figure 12A of the first embodiment. You can obtain the card (a reference card that should display the acquisition conditions).

[0106] As explained above, the game server 20 of this embodiment is a reference that the user does not possess. Along with the conditions for obtaining the card, this is an action that guides the user to the acquisition method of the reference card in question. By presenting this, the user can obtain the object simply by manipulating the target of the above operation. This allows you to request the execution of a specific process, improving usability when requesting the execution of that process. It is possible.

[0107] (3) Third Embodiment In the second embodiment, the operation target includes a way to guide the user to a path for obtaining cards they do not yet possess. We have explained the case of displaying an image, but in the third embodiment, the acquisition process of an unowned card In addition to the actions taken to guide the user along a path, the system also guides the user to the methods for obtaining cards they do not yet possess. Furthermore, the user will execute the evolution synthesis reservation process after obtaining the unowned card. This section describes an example of displaying an image that includes the target of the operation. Explanations similar to those for "state" will be omitted as appropriate.

[0108] (3-1) Specific examples of processing for presenting acquisition conditions, processing quests, and processing for reserving evolution synthesis The following describes the process of presenting the conditions for obtaining game cards in this embodiment, the quest process, and the progression. A specific example of the reservation process for chemical synthesis will be explained with reference to Figure 20. Figure 20 shows the actual implementation. This shows an example of a screen displayed on user terminal 10 while processing a game of this type. This is a diagram.

[0109] (3-1-1) Processing of presenting acquisition conditions (Figure 20) In image P4 of Figure 12A of the first embodiment, a reference card (this) should display the acquisition conditions. In this case, a card DSG) that shows the status as "not owned" in display area 102 is selected, and When button b8 is operated, the reference car selected by the user is selected, as shown in Figure 20. Image P5, showing the conditions for obtaining the item, is displayed. Image P5 in Figure 20 shows, in addition to display areas 103 and 104, button b10 ("Reserve") Button b11 ("Not available / Go to available area") and button b11 ("Reserve / Go to available area") It differs from the first embodiment (image P5 in Figure 12B) in that it includes ''). Button b 10 is operated when the user requests a quest to obtain cards they do not yet own. This is a button. Button b11 processes both the quest and the evolution synthesis reservation process. This is a button that is operated when a request is made.

[0110] (3-1-2) Quest Processing (Figure 20) In image P5, button b10 ("Do not reserve / Go to available area") is operated. Then, the image changes as shown in P6. Image P6 is the second embodiment (Image P6 in Figure 18). It is the same as ).

[0111] (3-1-3) Reservation processing for evolution synthesis (Figure 20) In image P5, button b11 ("Reserve / Go to Available Area") is operated. Along with the quest processing, reservation processing is performed for the reference cards that the user possesses. Then, image P7 will be displayed, indicating that the reservation process is complete.

[0112] (3-2) Processing flow of the game according to this embodiment (Figure 21) Next, an example of the processing flow of the game in this embodiment is shown in the sequence chart in Figure 21. This will be explained by referring to [reference]. Note that the process of presenting the acquisition conditions and the quest process in this embodiment are [reference]. The procedure is carried out in the same manner as in the second embodiment. Figure 21 is a sequence chart showing the reserved processing for evolutionary synthesis. The images P5 to P7 shown in Figure 20 are labeled with their respective symbols at each step in the process. .

[0113] In the reservation process described below, as an example, a user will perform an evolution synthesis on a base card. Of the multiple reference cards for this purpose, the reference cards you do not yet possess are used for the evolution synthesis of the base card. Let's assume you're making a reservation.

[0114] In Figure 21, a predetermined button (for example, Figure 20) is displayed on the image on the user terminal 10. By the user operating button b11) in image P5, the CPU of user terminal 10 11 accepts the request for the reservation processing of evolution synthesis (S50), and sends the request to the game server 20 Send to (S52). The request includes the unowned reference shown in display area 103 of Figure 20. It includes a card ID that identifies the card. Furthermore, S52, based on user actions, selects an object for the specified object. We accept requests to restrict its use to processes other than those that modify the object. This is an example of a process.

[0115] When the CPU 21 of game server 20 receives a request for reservation processing of evolution synthesis, the reservation data Access the data table and obtain the serial number of the base card obtained in S24 (Figure 16A). Has a corresponding reservation ID already been issued (i.e., the same serial number in the "Pre-evolution card" column)? Determine whether or not the serial number is recorded (S54). If a reservation ID has already been issued (S54:YES), proceed to S58, and the reservation ID will be issued. If the entry has not been completed (S54:NO), proceed to S58 after issuing a reservation ID (S56). Proceed. In S58, CPU21 associates the reservation ID with the reservation data table and Write the serial number. At this time, CPU21 will issue a new reservation ID. For the pre-evolution card, write the serial number of the base card among the cards you are reserving in the "Pre-evolution card" column. Furthermore, among the C1-C5 columns corresponding to that reservation ID, the card that is not the reservation target card In the field corresponding to the card ID, enter data indicating that it is not a card eligible for reservation (for example, N Write the ULL.

[0116] Next, the CPU 21 of the game server 20 checks the owned card data table for reserved matches In the "Reservation ID" field corresponding to the card ID of the Elephant Card, enter the reservation that was to be written to by S58. Write the ID (S60). Note that S60 is a process that changes the selected object for the specified object. This is an example of a process that restricts its use in processing.

[0117] Next, CPU21 generates image data indicating that the reservation is complete (S62), The image data is sent to the user terminal 10 (S64). The CPU 11 of the user terminal 10 is S When image data transmitted via 66 is obtained, an image (for example, a figure) is created based on that image data. Image 20 (P7) is displayed on the display unit 16 (S66).

[0118] After that, when the user obtains the reserved card (i.e., the user's card date) (When the card ID and serial number of the reserved card are recorded in the system, CP U21 uses the temporary serial number written to the reservation data table in S58, and the owned card data Replace it with the serial number included in the data.

[0119] In Figure 21, a predetermined button (for example,) is displayed on the image on the user terminal 10. When button b10) in image P5 of Figure 20 is operated, a quest process similar to that of the second embodiment occurs. (Figure 19) is performed.

[0120] As explained above, the game server 20 of this embodiment is a reference that the user does not possess. Along with the conditions for obtaining the card, the system guides the user to the acquisition route of the reference card, and also refers to the reference By presenting the target of the operation to request the process of reserving the card, the reserved card is the target. This makes it possible to restrict its use to processes other than evolutionary synthesis. Therefore, the user's possession During the waiting period until the remaining reference cards that the user has not yet obtained, This prevents cards from being accidentally used for processes other than their intended evolution / synthesis.

[0121] (4) Fourth Embodiment In the above embodiment, the user has a button to request that the conditions for obtaining the reference card be presented. We have explained the case in which an image showing the acquisition conditions is displayed when the operation is performed, but the fourth implementation In this form, there is a button to confirm the selected card as the base card for evolution synthesis. Reference card to satisfy the evolution synthesis change conditions of the base card when the -za is manipulated. An example of displaying an image showing the conditions for obtaining the product will be described below. Note that the above embodiment and Similar explanations will be omitted as appropriate.

[0122] (4-1) Specific examples of the process of presenting acquisition conditions Below, Figure 22 shows a specific example of the process for presenting the conditions for obtaining game cards in this embodiment. I will explain this while referring to it. Figure 22 shows the user when the game processing of this embodiment is being executed. This figure shows an example of a screen displayed on device 10.

[0123] • Processing of presenting acquisition conditions (Figure 22) Figure 22 shows a series of displays for the process of presenting the acquisition conditions for cards that are not yet owned. This shows the changes in the screen. Images P1 to P3 in Figure 22 are from Figure 12 of the first embodiment, respectively. This is similar to images P1-P3 in A.

[0124] When button b6 is operated in image P3, card K is selected as the base card. If the reference card requirements for LM to evolve are not met, it will be shown on page 4. The sea urchin image has been updated. Image P4 shows the evolution of card KLM, which was selected as the base card. This document presents the acquisition conditions for reference cards that the user does not possess, which are necessary for achieving the objective. This is an image for that purpose. Note that when the user selects button b6 in image P3, The card KLM, selected as a Scard, must meet the requirements for a reference card to evolve. If so, the user will be instructed whether or not to perform the evolution synthesis of card KLM. An image (not shown) is displayed.

[0125] Image P4 in Figure 22 shows the reference cards and other necessary cards for evolution synthesis in display area 102. In addition to the status (owned, not owned, reserved, or unknown), please also indicate whether you have an unowned or unknown card. The conditions for obtaining the code are shown in the first to third embodiments (Figures 12A, 13A, and...). This differs from the image P4 in Figure 21A. Display area 102 shows, as an example, the acquisition of unowned cards. Information indicating the route (in this case, the area name "Area 1") is displayed.

[0126] (4-2) Processing flow of the game according to this embodiment (Figure 23) Next, an example of the processing flow of the game in this embodiment is shown in the sequence chart in Figure 23. This will be explained by referring to [reference]. Figure 23 is a sequence chart showing the process of presenting the acquisition conditions. Note that in Figure 23, each step in which images P1 to P4 shown in Figure 22 are displayed is shown The images are labeled with symbols. Also, in Figure 23, the same processing as in Figures 16A and 16B is performed. Therefore, the same code has been assigned to them.

[0127] In the process of presenting the acquisition conditions described below, as an example, the user will have a base card and the If you possess some of the reference cards necessary to evolve the base card, This assumes a scenario where the player is asked to provide information on how to obtain reference cards they do not yet possess.

[0128] After S26 (Figure 16A) of the first embodiment is executed, the CPU 21 of the game server 20 Based on the multiple reference card IDs read in S26, the card data table, quest From the stock data table and the card distribution data table, the card data of the reference card T (Card name, card image, rarity, quest ID, area name of the area where it can be obtained, entry Get the number of transactions, circulation, and average transaction price (S38). Card name, card image. The rarity is obtained from the card data table. Quest ID and acquisition The area name of the possible area is obtained from the quest data table. The number of times it can be obtained is determined by the number of items you possess. The data is obtained from the historical table. The circulation quantity and average transaction price are obtained from the card circulation data table. It will be acquired.

[0129] Next, the CPU 21 of the game server 20 performs S40 to S42, respectively, the first implementation. After executing in the same manner as in steps S40-S42 (Figure 16B), the reference card obtained in S38 Image data to present to the user the conditions for obtaining the reference card based on the card data. A (image data that will be the basis for image P4 in Figure 22) is generated (S44), and the said image data is used Send to terminal 10 (S46).

[0130] When the CPU 11 of the user terminal 10 receives the image data transmitted in S46, Based on the image data, the image (for example, image P4 in Figure 22) is displayed on the display unit 16 (S4 8).

[0131] As explained above, the game server 20 of this embodiment is not owned by the user, The acquisition conditions for the reference cards necessary for the desired evolution synthesis are set for the base that will be used in the evolution synthesis. By presenting the necessary cards in response to the user's selection, the cards required for the evolution and synthesis of the base card are available. This improves the usability of the operation that displays the acquisition conditions for reference cards.

[0132] (5) Fifth embodiment In the above embodiment, an example is described in which a screen is displayed that shows the conditions for obtaining cards that are not yet owned. As revealed, in this embodiment, a screen is displayed that shows the conditions for obtaining the cards that the user possesses, and On the screen, a card specified by the user disappears when it is used for some process. Examples of processes to prevent this will be explained.

[0133] (5-1) Reserved registration and favorite registration of game cards in this embodiment (Figure 24) In the game of this embodiment, the user evolves a desired base card through evolution synthesis. Some or all of the reference cards required to evolve the base card in question. Let's consider the case where the user does not possess the card. In this case, the conditions for the combination of reference cards must be met. Until the user can obtain the new card (i.e., the remaining reference card), the base card will remain active. You need to wait for the evolution synthesis of the card to be performed. However, the user needs to wait for the remaining reference cards Before obtaining the card, use the reference card you possess for a purpose other than the evolution of the base card. Using it would cause it to disappear, and it would also make it difficult to meet the acquisition conditions for the reference card. In some cases, it becomes difficult to evolve the base card in question. For example, when performing evolution synthesis... In cases where the user accidentally loses the reference card (for example, by selling it) before the process is complete. In cases where the probability of obtaining the reference card is low, or if the probability of obtaining the reference card is low If the time available is limited, it can be difficult for users to upgrade their desired base card. Yes. Therefore, in this embodiment, the reference card necessary to evolve the desired base card This ensures that data is not lost unintentionally by the user.

[0134] For details on reserving and adding reference cards to your favorites, please refer to Figure 24. Figure 24 conceptually illustrates the reservation and favorite registration of reference cards. This is a diagram. In Figure 24, consider the case where a user wants to evolve their own card, card Q. Here, in order to evolve card Q, we use multiple reference cards such as cards A, B, and C. This assumes a scenario where the following combination is required. The user does not currently possess card B. Furthermore, evolution synthesis cannot be performed on card Q. Also, the conditions for obtaining card A are not met. If it is difficult to do so, the user may use card A for purposes other than evolving card Q. If you remove it from your card collection, it will become difficult to evolve card Q. Therefore, in this embodiment, the user does not unintentionally remove card A from their possession. To prevent this from happening, the conditions for obtaining Card A will be presented, and then, regarding Card A, We accept reservations and additions to your favorites. Reservation registration is a process that is performed on the condition that card A is removed from your owned cards. Among the principles, the card Q selected as the base card is used for processes other than evolution synthesis. It is about creating a restrictive state. Adding a card to your favorites is an action that is performed on the condition that card A is removed from your owned cards. It is restricted to use in the process of being used (including the evolution synthesis of card Q, which was selected as the base card). The goal is to create a limiting state. Note that reservation registration and favorite registration are objects specified by the user. This is an example of a process that restricts the use of a specified object for a particular operation. "The prescribed process" is a condition that removes the specified object from the owned objects. This is a process that is executed as an object owned by the user. The specified object within the project is restricted by reservation and favorites registration. It becomes the target object.

[0135] Thus, after presenting the conditions for obtaining Card A, we will proceed with the reservation registration or By accepting favorite registrations, users can obtain card A from the presented acquisition conditions. Immediately after recognizing that it is a difficult card to obtain, the process of removing card A from the player's possession is used. It becomes possible to make requests to restrict the amount of time one can stay. Therefore, the card This can reliably prevent loss that goes against A's intentions.

[0136] (5-2) Data Table Structure Next, regarding the owned card data table stored in the storage 25 of the game server 20... Next, we will explain this step by step, referring to Figure 25.

[0137] The owned card data table records information about the cards a user owns. Figure 25 shows an example of the configuration of the owned card data table. Figure 25 shows an example of the owned card data table for one user, but an owned card data table is created for all users registered in the game. The card ownership data table in Figure 25 differs from the card ownership data table in Figure 8 in that each card ID is associated with and recorded with data on the registration type. The registration information is data that shows the combination of the type of registration performed on the owned card data (reserved registration or favorite registration) and the type of screen on which the registration request was made (the screen that presents the acquisition conditions (hereinafter referred to as the "acquisition conditions presentation screen") or the "reference card list screen required for evolution synthesis for each base card")). In the example in Figure 25, "1" is recorded in the registration information for cards that were reserved registration via the acquisition conditions presentation screen, and "2" is recorded in the registration information for cards that were favorite registration via the acquisition conditions presentation screen. Card 1 For cards that have been added to favorites via the list screen, "4" will be recorded in the registration information, while for cards that have not been added to favorites or reserved, "N / A" will be recorded.

[0138] (5-3) Specific examples of the display processing of the game in this embodiment (5-3-1) A specific example of the display process for the game acquisition conditions screen of this embodiment (Figure 26) In image P4 of Figure 12A of the first embodiment, a reference card on which the acquisition conditions should be displayed is selected. When selected and button b8 is operated, the user selects as shown in Figure 26. Image P5, which corresponds to the screen showing the acquisition conditions for the referenced card, is displayed.

[0139] Image P5 in Figure 26 shows buttons b12 ("Register Reservation") and b13 ("Add to Favorites"). This differs from the first embodiment (image P5 in Figure 12B) in that it includes "registration". Button b12 ("Reservation Registration") is used when a user requests reservation registration for their owned cards. It is a button that is made. Button b13 ("Add to Favorites") requests the user to add a card they own to their favorites. This is the button that is operated when doing something.

[0140] When button b12 ("Register Reservation") is operated in image P5, as shown in P21. The image changes. Image P21 shows the result of the reservation registration process. When button b13 ("Add to Favorites") is pressed in image P5, the following will occur as shown on P22. The image changes as shown. Image P22 shows the result of the favorites registration process.

[0141] (5-3-2) Specific example of the display process for the game change condition list screen of this embodiment (Figure 27A (Figure 27C) In image P1 of Figure 12A of the first embodiment, button b4 ("Evolution Synthesis") is operated. As shown in Figure 27A, image P23a corresponds to the change condition list screen of this embodiment. This is displayed. Image P23a is also called the change condition list screen.

[0142] Image P23a includes the display area 105, button b12 ("Register Reservation"), and button b13 ("Add to Favorites"). Buttons b12 ("Register Reservation") and b13 ("Add to Favorites") are the same as those in Image P5 of Figure 26. Display area 105 displays the card images and card names of the base card and reference card for each combination of base card and reference card. In other words, display area 105 displays the reference cards for each base card. In the example in Figure 27A, the reference cards required for the evolution synthesis of card KLM are cards VIC, DSG, and MIT, and the reference cards required for the evolution synthesis of card SAM are cards MIT, KAY, and TED. In display area 105, reference cards are displayed in a way that distinguishes between owned and unowned cards. In the example in Figure 27A, cards VIC, DSG, MIT, and KAY are shown with solid lines to indicate owned cards, while card TED is shown with a dashed line to indicate unowned cards. Furthermore, in the display area 105, the mark m1 is displayed on the card image of the card that was registered via the acquisition conditions display screen. Mark m1 is a mark (also called a "symbol" or "mark") that is displayed on the card image of a card that is restricted from being used in any process other than the evolution and synthesis of a base card, among the processes that are executed on the condition that the card is removed from the owned cards. In the example in Figure 27A, the mark m1 is displayed on the card image of card KLM and on the card image of card DSG. In other words, Figure 27A shows that card DSG is in a state where it is restricted from being used in any process other than the evolution and synthesis of card KLM, among the processes that are executed on the condition that card DSG is removed from the owned cards. In addition, the display area 105 contains: Presentation of acquisition conditionsThe mark m2 is displayed on the card image of a card that has been registered as a favorite via the screen. The mark m2 is a mark displayed on the card image of a card that is restricted from being used in processes that are performed on the condition that the card is removed from the owned cards (including the evolution and synthesis of base cards). In the example in Figure 27A, the mark m2 is displayed on the card image of card KAY. In other words, Figure 27A indicates that card KAY is restricted from being used in all processes that are performed on the condition that card KAY is removed from the owned cards (for example, the evolution and synthesis process of card SAM, and the selling process of card KAY). The user can select a card image to select the card corresponding to that image. In the example in Figure 27A, if card image b14 is selected, card MIT will be selected as the reference card required for the evolution synthesis of card KLM, and if card image b15 is selected, card MIT will be selected as the reference card required for the evolution synthesis of card SAM. When a user selects a card, they can request to reserve or add the selected card to their favorites by operating button b12 ("Reserve Registration") or button b13 ("Add to Favorites"). In the example in Figure 27A, when the user selects card image b14 and operates button b12 ("Reserve Registration") or button b13 ("Add to Favorites"), they are requested to reserve or add the card MIT, which is a reference card required for the evolution synthesis of card KLM, to their favorites.

[0143] In image P23a, the user selects card image b14 and then clicks button b12 ("Pre- When you perform the operation "Register," the image changes to P23b. In image P23b, mark m3 is The card image of card MIT is displayed on the card as a reference card necessary for the evolution synthesis of card KLM. In this respect, it differs from image P23a. Mark m3 is accessed via the change condition list screen. This mark indicates the reference card that was the subject of the reservation registration. On the card image of card MIT, which is a reference card required for the evolution synthesis of card SAM, Then, the Mark M4 is displayed. The Mark M4 is an evolved version of other base cards (Card KLM). This mark indicates that the card has been reserved and registered as a reference card necessary for completion. In the example in Figure 27B, card MIT is used as a reference card necessary for the evolution synthesis of card KLM. The card image displays the mark m3, and the reference required for the evolution synthesis of card SAM is also displayed. The mark m4 is displayed on the card image of the card MIT. The card MIT is executed on the condition that the card MIT is removed from the cards held. Of the processes that can be performed, their use is restricted to processes other than the evolution and synthesis of card KLM. Card MIT can be used in the evolution synthesis process of Card KLM, but Card SA It will no longer be possible to use M for evolution synthesis or selling.

[0144] In image P23a, the user selects card image b14 and then clicks button b13 ("O When you perform the "Add to Favorites" operation, the image changes to P23c. Image P23c is Mark m5 It differs from image P23a in that it is displayed on the card image of card MIT. Mark m5 is a reference that was registered as a favorite via the change condition list screen. This is a mark indicating a code. In the example in Figure 27B, card MIT is used as a reference card necessary for the evolution synthesis of card KLM. The card image, and the card MI as a reference card required for the evolution synthesis of card SAM. The mark m5 is displayed on the card image of T. In this case, for card MIT, This is used for all processes that are executed on the condition that the card MIT is removed from the owned cards. And are restricted. In other words, card MIT is limited to the evolution synthesis process of card KLM, card SA It will no longer be possible to use M in either the evolution / synthesis process or the sale process.

[0145] In images P23a to P23c, marks m1 to m5 have mutually recognizable shapes and patterns. It is displayed by a line, or a combination thereof. This allows the user to see the availability conditions. The reference card that was the subject of the reservation registration made via the screen, via the screen showing the acquisition conditions The reference cards that were registered as favorites were accessed via the change condition list screen. The reference card that was the target of the reservation registration, and the change conditions list screen This makes it easier to identify reference cards that have been added to favorites. Specifically, for marks m1 to m5, the type of registration (reserved registration or favorite registration) The registration is identified by the shape of the mark, and the screen on which the registration request was made (the screen showing the acquisition conditions) The surface (or the change condition list screen) is identified by a pattern of marks.

[0146] (5-4) Processing flow of the registration process in this embodiment (Figure 28) Next, an example of the processing flow of the game in this embodiment is shown in the sequence chart in Figure 28. Refer to the explanation. Figure 28 is a sequence chart showing the registration process. Note that in Figure 28, images P5, P21, and P22 shown in Figure 26 are displayed. Each step is labeled with a symbol for the image. Also, in Figure 28, the same procedure as in Figure 16B is used. The same symbols are used for the reasoning.

[0147] In the registration process described below, the specified object is an object specified by the user. As an example of a process to restrict an object from being used for a predetermined process, This scenario assumes a request for either registering an account or adding an item to favorites.

[0148] After step S48 (Figure 16B) of the first embodiment is executed, the CPU 21 of the game server 20 This refers to button b12 ("Register Reservation") or button b13 displayed on image P5 in Figure 26. Based on the user's actions regarding ("Add to Favorites"), the request for processing of the reservation registration or The system receives a request to process the addition to favorites (S170) and sends the request to the game server 20. To believe (S171). Note that image P5 in Figure 26 is the selected object, the selected object. Identified by multiple object identifiers included in the change conditions corresponding to the effect identifier. This is an example of output data used to display the acquisition conditions for multiple objects. The request for processing the reservation registration requires the user ID, the serial number of the base card, and the reference card. The serial number of the device and the type of image displayed when the reservation registration process was requested. Information that identifies (for example, image P5 in Figure 26 or image P23a in Figure 27A) (i.e., Information identifying the type of screen used to process the reservation registration request, and the reservation registration This includes information that identifies it as a request for processing. To request the addition of an item to your favorites, you will need your user ID, the serial number of the reference card, and your favorites. The type of image displayed when the registration process was initiated (for example, Figure 26) Information identifying image P5 or image P23a in Figure 27A (i.e., the location of the favorite registration) Information identifying the type of screen used to make the request, and the process of adding to favorites. This includes information that identifies it as a request. Requests for processing reservation registrations and requests for processing favorite registrations are specified by the user. To restrict the use of a specified object, which is an object, for a predetermined process. This is an example of a requirement for doing so.

[0149] When the CPU 21 of the game server 20 receives a request from the user terminal 10, it processes the request The process of registering (reserved registration or favorite registration) is executed accordingly (S172). Furthermore, the processing in S172 is intended to be used for a predetermined process on the specified object. This is an example of a restricted process.

[0150] If the request received in S170 is a request for processing a reservation registration, CPU21 will For the possessed card data identified by the serial number of the reference card included in the request This indicates that the card is eligible for reservation registration made via the acquisition conditions display screen. The registration information (registration information "1" in Figure 25) is recorded. The CPU 21 also records the information included in the request. For reservation data identified by the serial number of the base card, C1~C5 In the field corresponding to the card ID of the reference card, record the serial number of the reference card. This will result in the serial number of the reference card that is subject to reservation registration being used for the reservation. Identified by serial numbers other than the serial number of the base card being registered. Approximately record in the data (that is, the reference card, other base cards other than the base card) (to reserve for evolution synthesis), and to delete from owned card data (that is, (and remove the referenced card from your possession (for example, by performing a sell operation)). This is restricted. On the other hand, if the request received in S170 is a request for processing to add to favorites, CP U21 is a possessed card identified by the serial number of the reference card included in the request. Cars that are eligible for favorite registration via the acquisition conditions display screen for the data. The registration information indicating that it is a do (registration information "2" in Figure 25) is recorded. Enter the reference card and, regarding the serial number of the card to be registered, add it to the reservation data table. Record the serial number and delete it from your card data (that is, The ability to remove the referenced card from your possession is restricted.

[0151] Next, the CPU 21 sends the result of the registration process to the user terminal 10 (S173 ).

[0152] The CPU 11 of the user terminal 10 receives the result of the registration process from the game server 20. When this is done, a screen based on the execution result is displayed (S174). As a result, user terminal 1 The display unit 16 for 0 shows either image P21 or P22 from Figure 26. Note that S174 is an object that is subject to restrictions due to reservation registration, and favorites A table that allows users to identify objects that are subject to restrictions due to registration. This is an example of a process that outputs data to be displayed in an index format.

[0153] By using the registration information in Figure 25, as shown in Figures 27A to 27C, marks m1 to m Using 5, determine the type of registration and the type of screen that was displayed when the registration request was made. This can be displayed in a way that allows the user to identify it. For example, the image in Figure 12A can be displayed to the user. When button b4 ("Evolution Synthesis") on P1 is operated, the display unit 16 will show the following in S172 When the registration process is executed, image P23b in Figure 27B is displayed, and in S172 If the process of adding to favorites is executed, image P23c in Figure 27C will be displayed.

[0154] As described above, the game server 20 of this embodiment, on the acquisition conditions presentation screen, The reference card you possess can be used for processes other than the evolution and synthesis of the base card. Requests to process reservation registrations to restrict access, or to remove them from owned cards. Restricted to being used in processes that are executed as such (including the evolution and synthesis process of base cards). Accepts requests to add items to favorites. This means that the user will be able to obtain the reference card they possess on the acquisition conditions screen. Immediately upon recognizing the difficulty, ensure that the reference card does not disappear unintentionally. You will be able to do that. In particular, the base card and the reference card used in the evolution synthesis of that base card The more reference cards a user possesses, the more they will need to consider which reference cards to use with which base cards. It becomes difficult to manage whether or not to use it for evolution synthesis. As a result, users may make operational errors or Forgetting the purpose of a reference card could lead to the card being lost unintentionally. This occurs. In contrast, in this embodiment, the reference car that is difficult for the user to obtain from the acquisition conditions display screen is... Immediately upon recognizing that it is a card, the card in question is made to disappear. It is possible to make a request to restrict its use to processes that are executed under certain conditions. Therefore, it is possible to reliably prevent the loss of the reference card against the user's intentions. ru.

[0155] Furthermore, in this embodiment, the user can register two types of information (reservation registration and favorites registration). Requests can be made. Therefore, users can choose which registration to use depending on their purpose. You can choose the range of restrictions to apply to the reference card. Users who wish to use a card in the evolution synthesis of a specific base card must submit a reservation request. This eliminates the reference card by performing any process other than evolution synthesis on a specific base card. Losses can be prevented. Also, without deciding the base card to evolve using a reference card, Users who wish to prevent the loss of the reference card can request to add it to their favorites. This ensures that the loss of the reference card is not reliably prevented. Therefore, the user can use the reference card This will allow for more flexible management of the code's usage.

[0156] Furthermore, the game server 20 of this embodiment displays the change condition list screen. The reference card that was the subject of the reservation registration made via the face-to-face process, and the acquisition conditions display screen The reference cards that were added to favorites are displayed in an identifiable manner. Furthermore, the game server 20 of this embodiment is used to register the base cards that are subject to reservation registration. The combination of reference cards is displayed in an identifiable manner. Furthermore, the game server 20 of this embodiment has a reference card that is the subject of reservation registration, and The reference card that was added to your favorites will be displayed in an identifiable manner. This allows users to determine the uses of their cards (specifically, the evolution of certain base cards). Visually understand whether it will be used for production or kept for an undecided purpose. You will be able to do it.

[0157] (5-5) Modified form of this embodiment The following describes some variations of this embodiment. Note that the following variations can be combined as appropriate. That is the case. (5-5-1) First variation In this embodiment, the reference card to be registered (reserved registration or favorite registration) The case where the card is in possession was explained. However, this embodiment is a reference that is subject to registration. The card used for the card selection does not have to be one you already possess. For example, the change condition list screen accepts requests for reservation registration or requests for favorite registration. Configure to enable this. When the request is received via the change condition list screen, the request The user has obtained the card in question (i.e., the card ID and serial number of the card). After the card number is recorded in the card data table, the reservation registration for that card is made. Perform the following actions: either add to your favorites, or add to your favorites.

[0158] (5-5-2) Second variation In this embodiment, an example of displaying marks m1 to m5 on the change condition list screen was described, but Marks m1 to m5 may be displayed on screens other than the conversion conditions list screen.

[0159] As an example, a screen showing the acquisition conditions (for example, image P showing the result of the reservation registration process) 21, or mark m1~ in image P22) which shows the result of the favorite registration process. You may display m5.

[0160] As another example, on the screen that displays a list of owned cards (hereinafter referred to as the "owned card list screen") Marks m1 to m5 may be displayed. Specifically, in image P1, button b1 ("View owned monsters") is operated. Then, the list of owned cards screen is displayed. The list of owned cards screen is shown in Figures 27A to 27C. As shown in the change conditions list screen, information about owned cards (for example, card image and card The names are displayed in a list. Of the cards you own, those that are eligible for reservation registration or favorite registration are displayed. The card image of the card will display one of the marks m1 to m5.

[0161] (5-5-3) Third variation In this embodiment, a request for reservation registration or favorite registration is made for the selected card. We have explained examples of how to accept such requests, but how to accept requests to deregister the card in question. That's good too.

[0162] For example, a card image showing one of the marks m1 to m5 in Figures 27A to 27C If an image is selected by the user, the card corresponding to the selected card image (i.e., (For cards that are in a reserved or favorited state) We accept requests to cancel registration. Specifically, in Figure 27A, mark m1 is displayed. If the card image is selected, the reserved DSG card will be selected. And, a button is displayed that is specified when requesting to unsubscribe. At this time, When the user presses this button, the reservation registration made to the card DSG is canceled. It is removed, and the mark m1 that was displayed on the card image disappears. As a result, the card DS G is in a state where no registration has been made (i.e., it is in a state where it can be used for all processes). )

[0163] According to this modified example, the items that are added to favorites when the purpose has not yet been decided are the items that will be added to favorites. For a given card, you can unregister it as a favorite and then register it as a reservation. Also, when its use is determined to be for evolution synthesis of a specific base card, it is performed. For reference cards that are the subject of a reservation registration, cancel the reservation registration and add them to your favorites. Registration can be performed. Therefore, the user can specify the purpose of the reference card and the reference card This will allow for more flexible management of the scope of restrictions imposed.

[0164] (5-5-4) Fourth variation In this embodiment, as shown in Figures 26 and 27A to 27C, button b12 ( An example of displaying "Reservation Registration" and button b13 ("Add to Favorites") side by side. As explained, you may display only one of these two buttons.

[0165] (5-5-5) Fifth variation In this embodiment, reservations are registered via a screen displaying acquisition conditions, as shown in image P5 of Figure 26. Alternatively, an example of a request to add an item to favorites has been described, as shown in Figure 27, image P2. The request may also be made via a change condition list screen as shown in 3a. The following are change conditions. An example of the registration process when the request is made via the item list screen is explained with reference to Figure 28. I will reveal it.

[0166] Specifically, when card image b14 in image P23a is selected, button b12 ("Pre User action is performed on button b13 ("Add to Favorites") or button b13 ("Add to Favorites"). Based on the operation, the CPU 11 of the user terminal 10 requests or processes the reservation registration. The system receives a request to process the addition to favorites (S170) and sends the request to the game server 20. To believe (S171).

[0167] When the CPU 21 of the game server 20 receives a request from the user terminal 10, it processes the request The process of registration (reservation registration or favorite registration) is executed accordingly (S172), and registration The result of the processing is sent to the user terminal 10 (S173).

[0168] The CPU 11 of the user terminal 10 receives the result of the registration process from the game server 20. When this is done, a screen based on the execution result is displayed (S174). As a result, user terminal 1 The display unit 16 of 0 will show either image P23b from Figure 27B or image P23c from Figure 27C. .

[0169] As described above, the registration process in this modified example involves four types of registration (via the acquisition conditions display screen). Reservations made via reservation registration, favorites registration via the acquisition conditions display screen, and changes in conditions. Reservations made via the list screen, and changes made via the list screen This includes the process of adding items to favorites. Each screen is designed to allow the user to identify the four types of registrations. Information about the card is displayed in a specific format.

[0170] (6) Sixth Embodiment In the above embodiment, communication between the user terminal 10 and the game server 20 is conducted according to HTTP. A communication is performed, and the user terminal 10 interprets the HTML document obtained from the game server 20. When the present invention is realized by a so-called browser format that displays game images, As explained above, this is not limited to this case. The game programme downloaded by user terminal 10 By executing the program, user terminal 10 proactively executes the game processing, and user terminal 1 This is a so-called native application that suppresses the sending and receiving process between 0 and the game server 20. It may also be implemented in a native application format. In native application format, a web browser Without using the CPU 11 of the user terminal 10, the display unit 16 generates the image data. Display the image. In this embodiment, the game of the above embodiment is provided in native application format. An example of how this can be implemented will be described. Note that the hardware configuration of this embodiment is as follows: The same configuration as in the embodiment may be used. In the native application format of this embodiment, the processing Most of the process is expected to be performed on the user terminal 10, but the game processes not described below will be handled on the user terminal 10. Part of the logic (for example, the lottery process that assigns to users by lottery, or the game operator giving to users The process of awarding cards (and other gift processing) will be handled on game server 20. The game server 20 may be configured to send the processing results to the user terminal 10.

[0171] In this embodiment, the user terminal 10, based on a predetermined operation by the user, interacts with the game operator. The game program is received from the server, and the received game program is stored in storage 18. It is stored. When the game is launched by the user terminal 10, the user terminal 10 and the game server Communication is established with server 20 and the login process is performed, and the user is sent from game server 20 Data table group to terminal 10 (card data table, evolution synthesis data table, owned cards) (Card data table, possession history data table, and card distribution data table) The data tables sent to the user terminal 10 are stored on the user terminal 10. It is kept within storage 18. In this case, the data tables in storage 18 are logged in. It is updated each time. In order to prevent the owned card data table from being tampered with on the user terminal 10, Each time a predetermined process is completed by the user terminal 10, or when logging out of the game At this point, the card data table held by the user terminal 10 is sent to the game server 20. Game server 20 receives the owned card data table and the owned cards in storage 25. After comparing it with the card data table and confirming that the data has not been tampered with, Based on the received owned card data table, the owned card data table in storage 25 Update the table.

[0172] Figures 29A and 29B are sequence charts illustrating the process of presenting the acquisition conditions in this embodiment. In Figures 29A and 29B, the same treatment as in Figures 16A and 16B is used. The same symbols are used for the reasoning. In the evolutionary synthesis reservation process of this embodiment (Figures 29A and 29B), for example, when logging in... The game server 20 then sends the data table group (car) from storage 25 to the user terminal 10. Data table, evolution / synthesis data table, owned card data table, ownership history data The user terminal 10 transmits the data table and the card distribution data table (S8). The CPU 11 stores the received data table group in the storage 18 and performs operations Based on the operation input from the input unit 15, the RAM 13 and the display unit 16, etc. cooperate in S14 Execute the process in S48. Although not shown in the figures, in this embodiment, evolution synthesis processing, quest processing, and evolution synthesis Similarly, the reservation process for completion is also performed proactively by the user terminal 10. In this embodiment, the card data table, the evolution synthesis data table, and the quest data table are all included. Table, owned card data table, owned history data table, and card circulation data The data table is maintained on the game server 20, and the reservation data table is on the user terminal 10 While we have explained the cases in which it is retained, this is not the only case. Native app In a game using a communication format, the responsibility for maintaining each data table should be configured as appropriate. This is possible and is held in at least one of the user terminal 10 and the game server 20. It is sufficient to allow it to be stored, and it is not limited to a specific storage method. If any of the data tables are maintained, they will be stored on the game server 20 when the game is running. The data table to be held is sent to the user terminal 10, and the game performed on the user terminal 10 It is used for processing.

[0173] (7) Modifications common to all embodiments (7-1) Variations of application to non-game applications The embodiments and modifications described above illustrate how the present invention can be applied to games. However, it can also be applied to other applications, such as online shopping. If a mall distributes multiple types of electronic coupons each time you purchase an item, A coupon may be used as an example of an object of the present invention. In this case, for example, a base object Upgrade the benefits of coupon Q as a kuto (process of changing the object) For example, coupon A is used as a reference object corresponding to coupon Q. It is conceivable that the user possesses and uses C. In this example, coupon Q is uploaded. For the purpose of upgrading, the user possesses one of the necessary coupons A to C. The conditions for obtaining coupons that have not yet been used (for example, coupon B) will be presented. This can be applied to other applications besides those exemplified above, as appropriate.

[0174] (7-2) Modifications of the method of operation input In the embodiment described above, a predetermined operation input to the user terminal is performed on the user terminal. Input of presses of designated instruction buttons, and display screens for user terminals equipped with touch panel functionality. While the above refers to touch input, the input method is not limited to this. Other input methods include acceleration. Operation input by shaking a user terminal equipped with a degree sensor, or operation by gesture. It may also be input (gesture input). Gesture input allows the user to have an imaging function. By performing a predetermined gesture on the terminal, the user terminal recognizes that gesture as an image. It recognizes pre-assigned gestures and inputs. It also executes a voice recognition program. Where possible, user input may be performed by voice input.

[0175] (7-3) Variations of handling user IDs In the above embodiment, the user terminal 10 sends a request to the game server 20 The ID is included (that is, the game server 20 receives the necessary information sent from the user terminal 10). The explanation was based on the premise that the user who made the processing request can be identified, but This is not the only way in which the server 20 can identify the user who made the processing request. For example, a session based on the user ID between user terminal 10 and game server 20 If established, game server 20 will use that user ID to determine the subsequent sessions. The user making the processing request may be identified. In this case, the user terminal 10 will access the game server. The request sent to 20 does not need to include the user ID (i.e., the user terminal 10 does not need to include the user ID). (You do not need to send the user ID to server 20.)

[0176] (7-4) Modifications concerning the object of operation In the embodiment described above, a button displayed on the image is used as an example of an object that can be operated by the user. As shown above, any format is acceptable as long as it is a format that can be manipulated by the user.

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

[0178] One aspect of the present invention is, Object identification information that identifies an object, and a process that changes the said object. A memory that stores change conditions, which include multiple object identification information used in the process, in association with the conditions. In an information processing device that can access the device, Based on user instructions, the selected object is the selected object. Identified by multiple object identifiers included in the change conditions corresponding to the object identifier information. The first method for displaying multiple objects in a format that allows the user to identify each of them. Output means (56) for outputting output data, In response to the output of the first output data by the output means (56), the user Instructions to specify one of the multiple objects based on the instructions. A means (51) for receiving, The output means (56) further receives instructions received by the receiving means (51). If the specified object is not possessed by the user , outputs second output data to display the acquisition conditions for the specified object. Information processing device.

[0179] An "information processing device" is a standalone game console or user terminal (for example, a portable This could be a mobile terminal, a personal computer, or a server on a network. Depending on the implementation form of the system, the actual entity of the information processing device can be defined as appropriate. For example, When the functions of each part of the information processing device are realized by the user operating the game console or user terminal. In this case, a game console or user terminal corresponds to the information processing device of the present invention. Alternatively, a client The user terminal, which is the base, has the function of receiving user input and displaying images, and information processing When the functions of each part of the device are essentially implemented by a server that can communicate with the user terminal, The server corresponds to the information processing device of the present invention. "Storage device" refers to any type of memory, such as flash memory or HDD (Hard Disk Drive). It may also be a memory device. Furthermore, the memory device is a device built into the information processing device. Alternatively, an external device configured to be accessible via wired or wireless connection from the information processing device may be used. A device is also acceptable. "Acquisition conditions" refer to subjective conditions (for example, conditions related to the user who possesses the object). Information), timing conditions (e.g., the period during which the object is available), content conditions (e.g., The average transaction price, the second object required to obtain the first object (e.g., a card) For example, items, or combinations thereof, location conditions (for example, areas where they can be obtained) ), or a combination thereof.

[0180] In the above information processing device, the execution of a process that changes the selected object is at least This is performed based on change conditions that include information indicating multiple objects, and user possession information. Therefore, for example, if the change conditions are not met, the process of changing the selected object will not be performed. The execution of the logic cannot be performed. In this case, the specified object is not possessed by the user. It may be impossible or difficult for the user to obtain the item. However, the specified item Users who are unaware of the acquisition conditions for a particular object may find it impossible or difficult to obtain the specified object. To perform a certain action, execute a process (for example, a quest process) to obtain a specified object. It is not possible to recognize this at the time of deciding whether or not to do so. In such cases, the user is actually referring to the old With the anxiety that obtaining the object might be impossible or difficult, the designated object The process to obtain the item will be executed. The above information processing device, in response to a user request, displays reference objects that the user does not possess. The acquisition conditions for the object are presented. Therefore, multiple reference carts corresponding to the selected object are shown. Even if there are specified objects in the code that are impossible or difficult for the user to obtain, The user acknowledges that obtaining the specified object is impossible or difficult, and then proceeds to make a request. You can decide whether or not to perform the process to obtain a specific object. As a result, the specified object This can give users a sense of security when they perform the process of obtaining the object.

[0181] The receiving means (51) further receives the second output data via the output means (56). Depending on the output, and based on the user's operation, the specified object is treated accordingly. This restricts its use to processes other than those that modify the selected object. We accept requests for this purpose. In response to the acceptance of the request by the acceptance means (51), the designated object The process is to be used for processes other than the process of changing the selected object. Further restrictive means (58) may be provided. "This restricts its use to processes other than those that modify selected objects." This is not limited to prohibiting any processing other than processing that changes the selected object, The process of changing the selected object is executable, but the requirements for requesting the execution of that process are... This could involve increasing the number of items or making the operations required to request the execution of the process more complicated. This allows for processes other than changing the selected object in response to user requests. The use of the specified object in the process is restricted. Therefore, before the change condition is met... If the user accidentally performs an action other than changing the selected object, the specified object This prevents accidental use.

[0182] The aforementioned acquisition conditions may also refer to the acquisition method of the specified object. "Acquisition method" could be, for example, the area where the specified object can be obtained, or It may be an area where objects can be traded between players (for example, an in-game shop). . Furthermore, "acquisition method" is a combination of temporal and spatial conditions (for example, a specified object). Information indicating whether or not it was issued for a limited time (for example, a limited flag), The availability period for the area where the item can be obtained (for example, the days of the week when the limited-time quest is available), or (or a combination thereof) This gives users peace of mind when performing the process to obtain the specified object. This is possible, especially when the "acquisition method" is a combination of temporal and spatial conditions. When a user requests the execution of an operation that changes the selected object, the specified object Information is provided to help determine more accurately whether or not it is impossible or difficult to obtain the product. Therefore, it is particularly beneficial.

[0183] The second output data may include the object of operation for guiding the user to the acquisition route. stomach. This improves the operability when requesting the execution of a process to obtain a specified object. It can improve.

[0184] The second output data indicates that the specified object was possessed by the user. Yes, and when information indicating the specified object is obtained by the acquisition means (55) If the object is not owned by the user at that point, the specified object This may include at least one of the methods and difficulty of obtaining the ject. This gives users peace of mind when performing the process of obtaining objects they do not yet possess. It can be given.

[0185] The information displayed as the acquisition conditions is that the specified object is possessed by the user. If it is an unknown object that has never been done before, the specified object is the unowned object It may be more restricted than when it is an object. This allows you to acquire unknown objects while maintaining an appropriate level of difficulty in the game. This can give users who perform the necessary actions a sense of security.

[0186] Another aspect of the present invention is, The object includes a user terminal and a server configured to communicate with the user terminal. Object identification information that identifies the object, and used in the process of changing the said object Access to a storage device that stores change conditions containing multiple object identification information in association with them. A system capable of processing information, Either the user terminal or the server, Based on user instructions, the selected object is the selected object. Identified by multiple object identifiers included in the change conditions corresponding to the object identifier information. The first method for displaying multiple objects in a format that allows the user to identify each of them. Output means (56) for outputting output data, In response to the output of the first output data by the output means (56), the user Instructions to specify one of the multiple objects based on the instructions. A means (51) for receiving, The output means (56) further receives instructions received by the receiving means (51). If the specified object is not possessed by the user , outputs second output data to display the acquisition conditions for the specified object. It is an information processing system.

[0187] Another aspect of the present invention is, Object identification information that identifies an object, and a process that changes the said object. A memory that stores change conditions, which include multiple object identification information used in the process, in association with the conditions. A computer that can access the device, Based on user instructions, the selected object is the selected object. Identified by multiple object identifiers included in the change conditions corresponding to the object identifier information. The first method for displaying multiple objects in a format that allows the user to identify each of them. Means for outputting output data (56), In response to the output of the first output data, the user's instructions are used to generate the multiple output data. Means for receiving instructions to specify one of a number of objects (51), The designated object, which is the object specified by the received instructions, If the user does not possess the specified object, the second method will display the acquisition conditions for that object. Means for outputting output data (56), This is a program designed to function as such.

[0188] Another aspect of the present invention is, Object identification information that identifies an object, and a process that changes the said object. A memory that stores change conditions, which include multiple object identification information used in the process, in association with the conditions. In an information processing device that can access the device, The selected object corresponds to the object identification information of the selected object. Multiple objects identified by multiple object identification information included in the transformation conditions A first output means that outputs first output data for displaying the acquisition conditions, In response to the output of the first output data by the first output means, the user For the first designated object, which is the specified object, the process used A first receiving means for receiving requests to restrict the following, In response to the receipt of the request by the first receiving means, the first designated object A first restricting means that restricts the use of the effect in the aforementioned process, It is an information processing device equipped with [a specific feature].

[0189] As a result, users may find it difficult to obtain the reference card on the screen that displays the acquisition conditions. Immediately after recognizing a certain condition, it becomes possible to prevent the reference card from disappearing. Therefore, it is possible to reliably prevent the unintended disappearance of the referenced card.

[0190] Furthermore, in order to display multiple objects in a format that allows the user to identify each one: A second output means for outputting second output data, In response to the output of the second output data by the second output means, the plurality of For the second designated object, which is the object specified by the user among the objects of the project: a second receiving means that receives requests to restrict its use for a predetermined process, In response to the receipt of the request by the second receiving means, the second designated object The system further comprises a second restricting means that restricts the use of the ect in the aforementioned process, At least one of the first output data and the second output data is the first limiting means Objects that are subject to the restrictions by the first means and objects that are subject to the restrictions by the second means A system for displaying objects in a format that allows the user to identify each one. It's also fine to use it.

[0191] Furthermore, the objects subject to the above restriction are the objects owned by the user. It is a specified object from among the possessed objects, The predetermined process removes the specified object from the possessed objects. This may be a process that is executed on the condition that a certain condition is met.

[0192] "On the condition that the specified object is removed from the possessed objects" The "process that is executed" means that when the process is executed, the specified object possesses It disappears from the object (i.e., the specified object becomes an unowned object). , that is the process.

[0193] Furthermore, requests received by the first receiving means or by the second receiving means At least one of the accepted requests is to the object subject to the aforementioned restriction. In contrast, it is used in processes that are executed on the condition that the object is removed from the possession of the object. A first requirement to restrict the acquisition of the object, and a condition to remove the object from possession. Used for processes other than those that change the selected object among the processes executed as an item. It may also include a second requirement to restrict what can be done.

[0194] "Processes that change the selected object" and "Processes that change the selected object" "External processing" is performed on the condition that the object is removed from the possession list. This is one form of "processing". "First Request" refers to the condition that the first designated object be removed from the possessed objects. This is a request for restrictions on all processes that are executed as a result. "Second request" is a clause that removes the first designated object from the possessed objects. Of the processes executed as a result, all processes other than those that change the selected object are included. The key to the restriction (in other words, allowing only operations that modify the selected object) It is a request.

[0195] Furthermore, the second output data includes the object that is the subject of the first request, and the The objects targeted by the second request are displayed in a format that is identifiable to the user. It may also be data intended for display.

[0196] "The object that is the subject of the first request" means that the object has disappeared from the possessed object. An object whose use is restricted for all processes that are executed on the condition that it be executed. (In other words, it is an object that is in a state where it cannot be removed from the possessed objects.) "The object that is the subject of the second request" refers to changing the selected object. Its use is restricted to processes other than those that change the selected object (i.e., it does not change the selected object). This is an object whose use is permitted only for the purpose of processing.

[0197] Another aspect of the present invention is, The object includes a user terminal and a server configured to communicate with the user terminal. Object identification information that identifies the object, and used in the process of changing the said object Access to a storage device that stores change conditions containing multiple object identification information in association with them. A system capable of processing information, Either the user terminal or the server, The selected object corresponds to the object identification information of the selected object. Multiple objects identified by multiple object identification information included in the transformation conditions A first output means that outputs first output data for displaying the acquisition conditions, In response to the output of the first output data by the first output means, the user For the first designated object, which is the specified object, the process used A first receiving means for receiving requests to restrict the following, In response to the receipt of the request by the first receiving means, the first designated object A first restricting means that restricts the use of the effect in the aforementioned process, It is an information processing system equipped with [the following features].

[0198] Another aspect of the present invention is, Object identification information that identifies an object, and a process that changes the said object. A memory that stores change conditions, which include multiple object identification information used in the process, in association with the conditions. A computer that can access the device, The selected object corresponds to the object identification information of the selected object. Multiple objects identified by multiple object identification information included in the transformation conditions A means for outputting first output data to display the acquisition conditions, In response to the output of the first output data, the object specified by the user In order to restrict the use of the first designated object, which is a predetermined object, for a specific process A means of receiving requests, In response to the acceptance of the aforementioned request, the aforementioned processing shall be applied to the first designated object. A means of restricting its use in reasoning. It is a program that makes it function as such.

[0199] In addition, to facilitate understanding of the present invention, reference numerals shown in the drawings are enclosed in parentheses as appropriate. As described above, this means that the information processing device, etc. according to the present invention is limited to the illustrated form. It's not that. [Explanation of symbols]

[0200] 1…Game System 10…User terminal 11…CPU 12…ROM 13…RAM 15... Operation input section 16…Display section 17…Communication Interface Section 18…Storage 19... Bus 20…Game Server 21…CPU 22…ROM 23…RAM 24...Communication Interface Section 25…Storage 26... Bus 51…Method of Reception 52...Game processing means 54...Methods for changing card data 55…Acquisition means 56…Output means 57…Means of recording 58…Restrictive measures 70...Data table group

Claims

1. A game program for operating the processor of a game device that plays a game via a game server, which includes using a base object and performing a process to change the said base object, An output means that displays a list image for the user to select a base object from among the base objects the user possesses, and that identifies whether or not a changeable process is possible for each base object. An acquisition means for acquiring information on a reference object that is consumed in exchange for executing a process that changes the selected base object, which is associated with the selected base object selected from the base objects displayed in the aforementioned list image, The output means outputs a presentation image including an image of the reference object acquired by the acquisition means, and the receiving means accepts the reference object specified based on the user's operation on the presentation image output by the output means as a specified object. Equipped with, The output means controls the display of an operation target that guides the user to a location where the specified object can be obtained, and restricts the use of the specified object for any process other than the process of changing the selected base object. The control for displaying the target of operation is a control for displaying only the target of operation that is operable in order to guide the user to a location where the specified object is set to be available. The control by the output means is performed when the receiving means receives a reference object specified based on the user's operation on the presented image as a specified object. The aforementioned reference object can be obtained at a location where the reference object is available, by fulfilling at least the quest conditions. The aforementioned image includes information about the base object after the process of changing the selected base object has been executed. A program characterized by the following features.

2. An information processing method in a game device that plays a game via a game server, which includes using a base object and performing a process to change the base object, A list of images is displayed for the user to select a base object from among the base objects they possess, and it is possible to identify whether or not a changeable process is possible for each base object. Obtain information on the reference object that is consumed in exchange for executing a process that changes the selected base object, which is associated with the selected base object selected from the base objects displayed in the aforementioned list image. Output a presentation image containing the image of the acquired reference object, and accept the specified reference object as the specified object based on the user's operation on the output presentation image. Control is provided to display an operation target for guiding the user to a location where the specified object can be obtained, and for restricting the use of the specified object in any process other than the process of changing the selected base object. The control for displaying the target of operation is a control for displaying only the target of operation that is operable in order to guide the user to a location where the specified object is set to be available. The control for displaying the object to be operated on is performed by accepting a reference object specified based on the user's operation on the presented image as the specified object. The aforementioned reference object can be obtained at a location where the reference object is available, by fulfilling at least the quest conditions. The aforementioned image includes information about the base object after the process of changing the selected base object has been executed. An information processing method characterized by the following features.

3. A game system that uses a base object and performs a game that modifies the base object, via a game server, An output means that displays a list image for the user to select a base object from among the base objects the user possesses, and that identifies whether or not a changeable process is possible for each base object. An acquisition means for acquiring information on a reference object that is consumed in exchange for executing a process that changes the selected base object, which is associated with the selected base object selected from the base objects displayed in the aforementioned list image, The output means outputs a presentation image including an image of the reference object acquired by the acquisition means, and the receiving means accepts the reference object specified based on the user's operation on the presentation image output by the output means as a specified object. Equipped with, The output means controls the display of an operation target that guides the user to a location where the specified object can be obtained, and restricts the use of the specified object for any process other than the process of changing the selected base object. The control for displaying the target of operation is a control for displaying only the target of operation that is operable in order to guide the user to a location where the specified object is set to be available. The control by the output means is performed when the receiving means receives a reference object specified based on the user's operation on the presented image as a specified object. The aforementioned reference object can be obtained at a location where the reference object is available, by fulfilling at least the quest conditions. The aforementioned image includes information about the base object after the process of changing the selected base object has been executed. A game system characterized by the following features.

Images