JP7653028B2 - GAME PROGRAM, GAME DEVICE, AND GAME PROCESSING METHOD - Google Patents

Description

The present invention relates to a game program , a game device , and a game processing method .

Some games executed using a computer allow a character to try on equipment before actually wearing it (see, for example, Patent Document 1).

JP 2018-057869 A

The player (player character) does not necessarily own the equipment that he or she tries on. Equipment that the player does not own may be produced or acquired by the player within the game. For this reason, it is convenient for the player if the player can manage a list of equipment (game media) that he or she would like to obtain in the future.

The purpose of this embodiment is to make it easy to create a list of game media.

A first aspect includes a computer comprising:
a display control unit that displays an image of the first game medium and an image of the second game medium designated by the user on the same screen;
a reception unit that receives, from the user, a request to register the second game medium in a first list for registering the second game medium;
and functioning as a registration unit that, in response to the registration request, collectively registers the plurality of second game media displayed on the screen in the first list , and also registers the plurality of second game media displayed on the screen in a second list for registering a set of the plurality of second game media .
It is a game program.

In addition, in the first aspect,
The first list may be a list for registering the second game medium that is desired to be associated with the first game medium,
The second list may be a list for registering a set of favorites of the user.

In addition, in the above aspect,
The first game medium may be a character in a game,
The second game medium may be an item equipped to the character.

In addition, a second aspect is a game device comprising: a storage unit that stores the game program;
A control unit that executes the game program .
It is a game device.

A third aspect of the present invention relates to a display step of displaying an image of the first game medium and an image of the second game medium designated by the user on a display;
a registration step of, when a registration request for the second game media to a first list for registering the second game media is received from the user, registering the plurality of second game media displayed on the display in the first list collectively in response to the registration request, and also registering the plurality of second game media displayed on the display in a second list for registering a set of the plurality of second game media.
A game processing method.

The present invention makes it easy to create a list of game media.

1 is a block diagram showing a configuration of a game device according to an embodiment of the present invention; 13 is an example of a wish list display. 13 is a display example of a fitting screen. 13 is a display example of an item registration screen. 13 is a display example of a registration confirmation screen . 13 is a flowchart showing the process from trying on to wish list registration. 13 is a display example of an overwrite confirmation screen.

[Embodiment]
Hereinafter, a game program and a game device according to an embodiment of this aspect will be described with reference to the drawings.

The game program described in this embodiment is executed on a game device such as a personal computer, PlayStation (registered trademark), Xbox (registered trademark), PlayStation Vita (registered trademark), or Nintendo Switch (registered trademark).

Game Description
The game program described in this embodiment is executed by a game device. In a game based on this game program, a user (player) causes a character (player character) to act in a virtual game space (hereinafter, virtual space) and causes the character to fight against an enemy character (e.g., a monster).

Users can play the game online with other users via a communications network. Users can also play the game individually without using a communications network.

The game progresses as the user completes tasks (quests). The user may use game media while attempting a quest. Game media is electronic data that represents elements related to the game.

The game media includes a character (an example of a first game media), weapons, armor, and tools that the character uses in the virtual space. The game media also includes materials used to construct the weapons, armor, and tools.

In the following, game media other than characters (first game media) may be referred to as items (an example of second game media). In this game program, each item is associated with an ID number.

Each item is associated with an attribute value. In this game program, item management data is implemented so that the attribute value of an item can be obtained based on the ID number.

Examples of the attribute value of a weapon include the attack power and critical hit rate when that weapon is equipped. The meaning of attack power, etc. can be defined in various ways. For example, attack power can be defined as a value that indicates the ability to inflict damage on an opponent. Also, critical hit rate can be defined as the probability of inflicting large damage on an opponent.

Items are grouped based on attribute values, etc. The criteria for grouping can be determined arbitrarily by the game developer. For example, items could be grouped according to the level of users who are recommended to use them.

The user can obtain items as the game progresses. In this game, "obtaining" an item means that the user can use, sell, discard, or otherwise dispose of the item (in other words, own the item). "Discarding" means that the association (described below) is released. "Selling" means that the association is released and a benefit (such as in-game currency) associated with the release of the association is given to the user. Note that items may be sold outside the game in addition to being sold within the game.

In the following, when a user owns an item, it may be expressed as there being an "association" between the character and the item. In this game program, when a user obtains an item, information about the association with the player character is set (recorded). An item may be associated with a non-player character.

The game program may be implemented so that the user directly owns the game media, without going through a character. In this case, for example, information identifying the user (such as a user ID) may be associated with the ID number of the item.

In this game, users can obtain items by completing quests (tasks such as combat and gathering). In this game, users can also obtain items with in-game currency. The game may be configured to allow users to obtain items through a lottery. The game may also be configured to allow users to obtain items by paying in the real world.

In this game, users can combine (synthesize) items (materials, weapons, armor, etc.) to create new items (weapons, armor, etc.) or modify (strengthen) existing items (hereinafter these actions will be referred to as production, etc.). The combinations of items required for production, etc. (hereinafter also referred to as recipes) are predetermined. In this game, facilities (processing shops) for carrying out production, etc. are set up within the virtual space.

This game has a mode in which you can have your character try on items such as weapons, armor, and tools. "Trying on" means checking how the item looks when worn by the character. Items that can be tried on are items that the character owns, and items that the character is thinking of acquiring.

When trying on an item, this game program displays various information on the screen (display 61, described below) along with an image of the character wearing the item. This allows the user to check the character's appearance before actually equipping the item. The user can also check changes to various parameters, such as the character's strength and defensive power, before actually equipping the item.

Users can register in a list (hereafter referred to as a wishlist) the game media they wish to associate with their characters. Note that characters here include both player characters and non-player characters.

The wishlist is implemented as list-format data. In other words, the wishlist has multiple fields for registering information. Each field is assigned a number. Each field in the wishlist registers a pair of an item's ID number and the date and time it was registered.

The maximum number of registrations (slots) for wishlists is set. As an example, the maximum number of registrations is set to six. Of course, the maximum number is not limited to six.

<Configuration of the Game Device>
1 is a block diagram showing the configuration of a game device 5 according to this embodiment. The game device 5 executes a game based on a user's operation. The game device 5 has a display 61, a speaker 62, and a controller 63 either externally connected or built-in.

In the game device 5, the game progresses based on the installed game program and game data. Note that game devices 5 can also communicate data with each other using a communication network (not shown) or a short-range wireless communication device (not shown).

The game device 5 has a network interface 51, a graphics processing unit 52, an audio processing unit 53, an operation unit 54, a memory unit 55, and a control unit 56. The network interface 51, the graphics processing unit 52, the audio processing unit 53, the operation unit 54, and the memory unit 55 are electrically connected to the control unit 56 via a bus 59.

The network interface 51 is communicatively connected to the communication network to transmit and receive various data between, for example, the game device 5 and an external server device (not shown).

The graphics processing unit 52 renders game images including the player character and various objects related to the virtual space in a moving image format according to the game image information output from the control unit 56. The graphics processing unit 52 is connected to the display 61. The game images are displayed on the display 61 as a game screen.

The audio processing unit 53 plays and synthesizes digital game sounds according to instructions from the control unit 56. The audio processing unit 53 is connected to a speaker 62. The played and synthesized game sounds are output from the speaker 62.

The operation unit 54 is connected to the controller 63, and transmits and receives data related to operation inputs between the controller 63. For example, the user inputs operation signals to the game device 5 by operating an operator (not shown) such as a button provided on the controller 63.

The storage unit 55 is composed of a HDD, RAM, ROM, etc. The storage unit 55 can store game programs and game data. The storage unit 55 also stores other account information received from other game devices 5, etc.

The control unit 56 is composed of a microcomputer including a CPU and a semiconductor memory. The control unit 56 controls the operation of the game device 5. For example, the control unit 56 executes a game program to operate the graphics processing unit 52, the audio processing unit 53, etc.

The audio processing unit 53 plays game audio by executing specific software (e.g., a game program or an associated program).

<Functional configuration of the control section>
By executing the game program, the control unit 56 functions as a game progression unit 561, a reception unit 562, a management unit 563, a display control unit 564, and a registration unit 565.

The game progression unit 561 progresses the game in response to the operation signal input from the operation unit 54. At that time, the game progression unit 561 moves the player character in the virtual space in response to the operation signal. The game progression unit 561 also moves the non-player characters in the virtual space. The movements of the non-player characters are determined, for example, by AI (Artificial Intelligence).

The reception unit 562 receives various commands related to the wish list from the user via the operation unit 54. For example, the reception unit 562 receives a request from the user to register an item to the wish list.

The management unit 563 manages the association between characters and items. Characters here include both player characters and non-player characters. Non-player characters to which items (e.g. weapons, armor, etc.) are associated include, for example, characters that act as companions to player characters. The management unit 563 also manages information on the association between characters and users (information indicating which character the user is using).

The management unit 563 holds a list of pairs of item ID numbers and the identification information of the characters associated with those items. This list is implemented so that the items (ID numbers) owned by a character can be searched for using the character's identification information as a key.

The display control unit 564 controls the display of the wish list and the display of the character's fitting state. Specifically, the display control unit 564 generates image data required for display, or specifies existing image data, and issues specific instructions to the graphics processing unit 52.

- Wishlist display control -
The user can display the wish list on the screen (display 61) by sending a predetermined command (list display command) to the reception unit 562 via the operation unit 54. The display control unit 564 controls the display of the wish list.

Figure 2 is an example display (screen) of a wish list W. This screen (hereinafter, list confirmation screen SW) allows the user to confirm the contents of the wish list W. For example, the display control unit 564 causes the list confirmation screen SW to display a list of the names of currently registered items. In the example of Figure 2, the names of the items are Dual Swords A, Torso Equipment A, etc. The display control unit 564 may also cause the list confirmation screen SW to display the date and time when each item was registered to the wish list W.

In this game program, when the user clicks (selects) the name of an item on the list confirmation screen SW, information about the attribute values of that item is displayed. Figure 2 shows a state in which the user has selected Dual Swords A (weapon). In the example of Figure 2, the attack power, critical rate, etc. of the selected weapon (item) are displayed as attribute values.

The list confirmation screen displays a list of items (materials) required for the production, etc. of an item (weapon) selected by the user as attribute values of that item. The list of materials also displays the number of each material required and the number currently owned. In FIG. 2, for example, the number required of material b is 5, and the number owned is 2. This game program has a function of notifying the user when the materials (game media) for a weapon or other item registered on wish list W are collected. In addition, this game program has a function of automatically deleting the registration of an item registered on the wish list from the wish list once the item has been produced, etc.

- Display control for fitting -
The user can display an image of a character trying on an item (hereinafter, a fitting screen ST) by sending a predetermined command (hereinafter, a fitting screen display command) to the reception unit 562 via the operation unit 54. When the try-on screen display command is sent from the reception unit 562, the display control unit 564 instructs the graphics processing unit 52 to display the try-on screen ST.

In this game program, the ability to try on items is achieved by displaying an image of the character and an image of an item (weapon, armor, etc.) specified by the user on the same screen (or, more precisely, in the same area of the screen).

Figure 3 is a display example of the try-on screen ST. The try-on screen ST has an area CA for displaying characters. In the example of Figure 3, the player character PC is displayed in area CA. If the subject to be tried on with the item is a non-player character NPC, the non-player character NPC is displayed in area CA.

The user can rotate the image of the character trying on the clothes 360 degrees by sending a specific command to the reception unit 562 via the operation unit 54. This allows the user to check the character's appearance from various angles.

The fitting screen ST also has an icon area IA in which multiple icons IC are displayed. The icon area IA is displayed in response to an instruction from the display control unit 564 to the graphics processing unit 52. Each icon IC represents an item (weapon, armor, etc.) that is a candidate for production, etc.

When the user clicks on an icon IC via the operation unit 54, the reception unit 562 determines that the user has selected the item OBJ corresponding to that icon IC as the item to be tried on. In other words, by selecting an icon IC, the user can indicate to the reception unit 562 the item OBJ that the user wants the character PC or NPC to try on. Note that the game program indicates to the user that the icon IC is selected by adding a star next to the icon IC (see FIG. 3).

The reception unit 562 sends the ID number of the item OBJ selected by the user and a command to update the try-on screen ST to the display control unit 564. For example, assume that the user selects new armor as the item OBJ to try on. The display control unit 564 then displays in the area CA the character PC and NPC wearing the armor selected by the user.

The display control unit 564 displays items OBJ worn by the character PC/NPC, such as armor, superimposed on the character PC/NPC (worn in FIG. 3). Depending on the item OBJ, the display control unit 564 may display it at a position away from the character PC/NPC (out of contact). For example, the display control unit 564 displays an item to be placed near the head of the character PC/NPC as if it is floating above the character's head.

The fitting screen ST displays a list of the names of the items being tried on. When a displayed name is clicked, the display control unit 564 also displays the attribute values of that item. This allows the user to check the change in the character's strength before and after putting on the item.

The display control unit 564 also displays a button B0 ("Add to list" button) on the fitting screen ST. The Add to list button B0 is a button for displaying the item registration screen SR (described below). When the Add to list button B0 is clicked, the reception unit 562 sends a display command for the item registration screen SR to the display control unit 564.

Then, the display control unit 564 causes the display 61 to display the item registration screen SR by sending a predetermined command to the graphics processing unit 52. Note that if all of the items OBJ being tried on have already been registered in the wish list W, the display control unit 564 causes the Register to List button B0 to be displayed in a grayed-out state (unclickable).

Figure 4 is a display example of the item registration screen SR. The item registration screen SR is a user interface for registering items to the wish list W. The user can input a command (registration request) to register the item OBJ to the wish list W to the reception unit 562 by operating button B1 (the "Start registration" button) on the item registration screen SR. The reception unit 562 transfers the registration request to the registration unit 565.

The registration unit 565 has a function of registering the item OBJ being tried on in the wish list W. The registration unit 565 realizes registration by writing the ID number of the item OBJ, etc. in the wish list W. The registration unit 565 activates this function when a registration request is transferred from the reception unit 562.

In this game program, the following requirements must be met in order to register an item OBJ to the wish list W.

(1) The item OBJ is displayed on the screen (area CA). (2) The item OBJ is not associated with a character PC or an NPC. (3) The item OBJ does not overlap with any already registered item OBJ. Note that the registration unit 565 does not take into consideration the group to which the item OBJ belongs as a requirement for registration.

In other words, the registration unit 565 allows for differences in the groups of the item OBJs requested to be registered (the items being displayed) when registering the item OBJ. Furthermore, the registration unit 565 allows for differences in the group to which the item OBJ requested to be registered belongs and the group to which an already registered item OBJ belongs when registering the item OBJ. This allows the user to select equipment without being bound by groups.

If the item OBJ being tried on meets the registration requirements, the registration unit 565 causes a screen (registration confirmation screen SC1) to be displayed on the screen via the display control unit 564 to confirm the user's intention to register (see FIG. 5). If the user clicks button B2 (the "Yes" button) to approve the registration, a registration request is sent to the reception unit 562. This causes the registration unit 565 to start a series of registration tasks (described below).

When there are multiple items OBJ to be registered in the wish list W, the registration unit 565 registers the multiple registration targets in the wish list W all at once. "Registering all at once" means that the user interface is configured so that the user can register all registration targets in the wish list W without sending a registration instruction for each individual item to be registered. In this game program, the user interface is configured so that a single instruction from the user (clicking a single button) starts the registration process for all registration targets.

In this game program, items that are registered in bulk may have the same attributes, such as skills (same group), or they may have different attributes (different groups). In other words, in this game program, items can be registered in bulk regardless of their grouping.

Note that "skills" include effects that are activated in the game space to help the user progress through the game (for example, making it easier to complete tasks). These effects are exerted on the character PC or NPC, as well as on friendly characters, enemy characters, etc., when the character PC or NPC actually possesses (for example, equips) an item.

When registering, the registration unit 565 first writes the information into an empty slot in the wish list W. However, when the user requests registration, the maximum number of registrations may have already been reached. In this case, if it is necessary to register a new item, the registration unit 565 overwrites the necessary amount of information corresponding to any of the registered items in the wish list W.

When overwriting, the registration unit 565 overwrites items in order of the time they were registered in the wish list W. However, the registration unit 565 performs the overwrite only when approval of the overwrite is obtained from the user.

When the registration unit 565 checks whether the user has approved the overwrite, it instructs the graphic processing unit 52 to display an overwrite confirmation screen SC2 (see FIG. 7). On the overwrite confirmation screen SC2, a message M asking whether the user wants to overwrite, a button B3 (a "Yes" button) for approving the overwrite, and a button B4 (a "No" button) for rejecting the overwrite are displayed so that each of them can be selected.

In addition, by displaying the registration date and time of each item OBJ on the item registration screen SR, the user can use the registration date and time as a factor in deciding whether or not to overwrite. By using the registration date and time as a factor in deciding whether or not to overwrite, for example, the user can more easily avoid unintentional overwriting.

<Example of operation>
Suppose that during the game, the player character PC enters the processing shop through the user's operation. Here, suppose that the user operates the controller 63 to send a try-on screen display command to the reception unit 562. The reception unit 562 transfers the try-on screen display command to the display control unit 564. Then, the try-on screen ST is displayed, etc.

Figure 6 is a flowchart showing the process from trying on to registering the item in the wish list. When the display control unit 564 receives a command to display the try-on screen, it displays the character PC and NPC in their current state (step S01, see Figure 3). In Figure 3, the player character PC is displayed. Furthermore, the display control unit 564 displays options for production, etc. (icon area IA) (step S01).

When the user clicks on an icon IC in the icon area IA, the reception unit 562 sends an update command to the try-on screen ST to the display control unit 564 along with the ID number of the item OBJ corresponding to that icon IC (step S02). This causes the display control unit 564 to display the character in area CA with the item OBJ selected by the user being tried on (step S02).

The reception unit 562 checks whether or not there is a registration request (step S03). If there is a registration request, the registration unit 565 checks with the user whether or not it is really ok to register (see FIG. 5). If the user approves the registration (Yes in step S03), the registration unit 565 checks whether or not any of the items being tried on have already been registered (step S04).

If, as a result of the check, all of the items being tried on are unregistered (No in step S04), the registration unit 565 compares the number of items being tried on (number of items being tried on) with the number of available slots on the wish list W (step S05). If the number of items being tried on is equal to or less than the number of available slots (Yes in step S05), the registration unit 565 registers all of the items being tried on in the wish list W at once (step S06).

If the number of items being tried on is greater than the number of available slots (No in step S05), it is decided that if there are available slots, up to the number of items being tried on will be registered (step S07). The display control unit 564 displays an overwrite confirmation screen SC2 (step S08). Figure 7 shows an example of the overwrite confirmation screen SC2.

If the user does not approve the overwrite, the registration unit 565 cancels the registration process (No in step S09, step S10). After the cancellation, the registration unit 565 switches the item registration screen SR to, for example, a fitting screen ST via the display control unit 564.

If the user approves the overwriting, the registration unit 565 registers the items in the vacant slots and overwrites the occupied slots (Yes in step S09, step S11). In other words, the items OBJ that have been tried on are registered in the wish list W all at once. Once the registration and overwriting are complete, the registration unit 565 switches the item registration screen SR to, for example, a try-on screen ST via the display control unit 564.

Some of the items being tried on may already be registered on the wish list W (see Yes in step S04). In this case, the registration unit 565 extracts items that are not registered on the wish list W from the items being tried on (step S12). The registration unit 565 compares the number of extracted items (extracted number) with the number of available slots on the wish list W (step S13).

If the number of extracted items is greater than the number of available slots on the wish list W (No in step S13), the registration unit 565 performs the process of step S07. On the other hand, if the number of extracted items is equal to or less than the number of available slots on the wish list W, the registration unit 565 registers all of the extracted items on the wish list W (step S14). Once registration is complete, the registration unit 565 switches the item registration screen SR to, for example, a fitting screen ST via the display control unit 564.

In summary, this aspect is a game program that causes a computer (control unit 56) to function as a management unit 563 that manages the association between a first game medium (character) and a second game medium (item), a display control unit 564 that displays an image of the first game medium and an image of the second game medium specified by the user on the same screen, a reception unit 562 that receives from the user a request to register the second game medium in a list (wish list W) in which the second game medium is registered, and a registration unit 565 that registers the second game medium displayed on the screen and not associated with the second game medium in the list in response to the registration request, and when there are multiple second game media to be registered in the list, the registration unit 565 registers the multiple registration targets in the list collectively.

Effects of this embodiment
As described above, according to this embodiment, the user can collectively register items that he or she wishes to obtain in the wish list W. That is, this embodiment makes it easy to create a list of game media.

The game program also requests the user's approval when overwriting the wish list. Therefore, in this embodiment, the risk of inadvertently rewriting the wish list can be reduced.

[Other embodiments]
In the above embodiment, an item may be applied instead of a character (first game medium). As a specific embodiment, for example, a game in which an ordinary weapon (first game medium) is equipped with various parts (second game medium) to modify it into a high-level weapon is assumed.

Wishlist W may be implemented so that a set of weapons, armor, etc. equipped by a character can be registered in one slot. In this case, the user may be able to set a general name for the set of registered items.

When generating items, it is possible to produce an entire set of weapons, armor, etc. all at once, or to produce a part of the set at a time. For user convenience, generated items can be automatically deleted from the wish list W.

The game program may implement a list (hereafter referred to as a set list) that registers a character's complete set of equipment from head to toe (hereafter referred to as a favorite set) in response to a user's instruction. The set list is a list separate from the wish list. The game program may be implemented so that when the user selects a favorite set from the set list, the character can be equipped with all the equipment included in that favorite set at once.

Registering items to a set list may be linked to bulk registration to a wish list W. For example, the game program may be implemented so that when all equipment collectively registered to the wish list W is produced, it is registered as a favorite set to the set list. This saves the user the trouble of having to register the entire set of equipment collectively registered to the wish list W to the set list again.

The registration unit 565 may be implemented to overwrite the wishlist W in the order of the slots (lowest slot number first) if there are no free slots in the wishlist W. Even in this case, it is advisable to provide a user interface that asks the user whether or not to overwrite.

The game program may be implemented to display a specific message when all items being tried on are already registered on the wish list W. An example of a message that could be displayed is "All items are already registered, so duplicate registrations are not permitted."

For items that are desired to be registered in bulk but have already been registered, the registration date and time recorded in the wish list W may be updated in response to a registration request from the user. This allows the user to use the registration date and time as a useful criterion for determining whether or not to overwrite. As a result, the user can more easily avoid unintended overwriting.

The game program may be implemented so that the user can select which wishlist W slot (item) to overwrite.

The game program may be implemented so that the user can choose whether to "display" or "not display" the overwrite confirmation screen SC2.

The grouping criteria are examples only. As another example, weapons and armor that are likely to exert a particular ability (game skill) could be classified into the same group. Items could also be classified into groups based on design taste.

The game program can be implemented so that items (materials) required to create weapons and armor can be obtained from defeated enemies, as rewards when clearing quests, or by picking them up in the field. The game program can also determine in advance as game settings the items (materials) that are key to production, etc. (for example, main items). In this case, the acquired items (materials) can be grouped according to the attributes of the key items among the acquired items (materials).

The game program may be implemented so that new recipes are made available to the user as quests are cleared. In this case, it is conceivable that items would be grouped each time a recipe is made available (i.e., each time a quest is cleared).

When registering items OBJ in bulk to a wishlist W, a requirement may be that the group to which the item (second game medium) requested to be registered belongs is the same as the group to which the already registered item (second game medium) belongs. This allows the user to collect items that are standardized according to a predetermined standard.

The user may be able to set priorities for production, etc., for items registered collectively on the wish list W. Furthermore, the game program may be implemented so that acquired items (materials) are allocated to items to be produced (subtracted from the required number for the items to be produced) according to the priorities.

In production, etc., the same item (material) may be needed for multiple items. For example, two pieces of material A are needed to make a helmet, and three pieces are needed to make the arms. In such a case, by assigning items (materials) according to priority, the items (materials) needed for production, etc. will be gathered in order of priority, starting with the items with the highest priority.

If the game program is implemented to notify the user when all the items necessary for production, etc. are gathered, the user will be notified when items become available for production, etc., starting with the highest priority items. This makes it possible for the game program to respond to user requests such as "My headgear is weak right now, so I would like to make that first if possible."

Games to which the above-described embodiment can be applied are not limited to action games. For example, the embodiment can be applied to various types of games, such as role-playing games, shooting games, simulation games, board games, puzzle games, and development games.

The game media described in the embodiments are examples. Game media also include cards, avatars, in-game points, tickets, etc.

The game program may also be implemented as a game program for a so-called online game. When the game program is for an online game, the processing that was performed by the control unit 56 may instead be performed on the server side, or may be shared between the server side and the client (game device 5) side.

Even when these other embodiments are adopted, the effects of the present embodiment are exhibited. In addition, this embodiment can be combined with other embodiments, and other embodiments can be combined with each other as appropriate.

5 Game device 55 Storage unit 56 Control unit (computer)
562 Reception unit 563 Management unit 564 Display control unit 565 Registration unit NPC Non-player character (first game medium)
OBJ Items (second game media)
PC player character (first game medium)
W Wish List (List)

Claims (3)

Computer,
a display control unit that displays an image of the first game medium and an image of the second game medium designated by the user on the same screen;
a reception unit that receives, from the user, a request to register the second game medium in a first list for registering the second game medium;
functioning as a registration unit that, in response to the registration request, collectively registers the plurality of second game media displayed on the screen in the first list, and also registers the plurality of second game media displayed on the screen in a second list for registering a set of the plurality of second game media ;
The first list is a list for registering the second game medium that is desired to be associated with the first game medium.
Game program. A storage unit that stores the game program of claim 1 ;
A game device comprising a control unit that executes the game program. a display step of displaying on a display an image of the first game medium and an image of the second game medium designated by the user;
a registration step of, when a registration request for the second game media to a first list for registering the second game media is received from the user, registering the plurality of second game media displayed on the display in the first list collectively in response to the registration request, and also registering the plurality of second game media displayed on the display in a second list for registering a set of the plurality of second game media ;
The first list is a list for registering the second game medium that is desired to be associated with the first game medium.
Game processing method.

Images