JP7506322B2 - Information processing device, information processing method, and program - Google Patents

Description

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

There is a known game in which a player uses a team of multiple characters, called a deck, to complete events that take place in the game, called quests. For example, Patent Literature 1 discloses a technology that automatically organizes a deck from characters owned by the user.

JP 2017-185268 A

In some games, where players use decks to clear quests, each player sets in advance the characters that can be included in the decks of other players, and when a player performs a quest, the deck is composed of the characters selected by that player and the characters set by the other players.

However, in such games, the characters that each player sets as characters that can be organized into the decks of other players are not set in the decks that the player organizes himself, but are set in the decks that other players organize. Therefore, there is an issue that few players change the characters that they have set once.

The present invention aims to provide a technology that makes it possible to increase the frequency with which characters that are set as characters that can be organized into other players' decks are changed.

An information processing device according to one aspect of the present invention has a storage unit that stores specific characters that can be organized into other players' decks among the characters owned by the player, a display control unit that displays a plurality of character slots that constitute a deck used to play a quest, a screen that accepts the designation of a character to be set in each character slot, and an update unit that updates the specific character stored in the storage unit to the character set in the specific slot when a character owned by the player and other than the specific character is set in a specific slot among the plurality of character slots.

The present invention provides a technology that allows characters that are set as characters that can be organized into other players' decks to be changed more frequently.

FIG. 1 is a diagram illustrating an example of a system configuration of a game system according to an embodiment of the present invention. FIG. 2 is a diagram illustrating an example of the hardware configuration of a game server and a terminal. FIG. 2 is a diagram illustrating an example of a functional block configuration of a game server. A figure showing an example of a player management DB, a deck management DB, and a deck usage history DB. FIG. 2 is a diagram illustrating an example of a functional block configuration of a terminal. 13 is a flowchart illustrating an example of a processing procedure executed by a game server. FIG. 13 is a diagram showing an example of a screen displaying deck history.

The following describes an embodiment of the present invention with reference to the attached drawings. In each drawing, the same reference numerals denote the same or similar configurations.

<System Configuration>
Fig. 1 is a diagram showing an example of a system configuration of a game system 1 according to this embodiment. The game system 1 shown in Fig. 1 includes a game server 10 (game device) and a plurality of terminals 20. The game server 10 and the terminals 20 are connected to each other so as to be able to communicate with each other via a communication network N such as the Internet, an intranet, a wireless LAN, or mobile communication.

The game server 10 is a device that performs some of the functions required for the terminal 20 to provide the game, such as managing various information related to the player and executing some of the game processing. The game server 10 may be composed of one or more information processing devices, or may be composed of a virtual server (such as a cloud server).

The terminal 20 is an information processing device that provides a game to a player, and the player can execute the game according to this embodiment by operating the terminal 20. The terminal 20 is, for example, a computer such as a mobile phone (including a smartphone), a tablet, a personal computer, an arcade game device, or a consumer game device. The terminal 20 notifies the game server 10 of its own position detected using a GPS (Global Positioning System) or the like.

＜Game Overview＞
Next, an overview of the game provided by the game system 1 according to this embodiment will be described. In the game provided by the game system 1 (hereinafter referred to as "this game"), the player can obtain new characters and items by organizing a deck with characters selected from a plurality of characters owned and clearing quests using the organized deck. In addition, the player can challenge quests with higher difficulty by developing a stronger character by synthesizing the plurality of characters obtained, or by strengthening the attributes of the character using an item.

Here, a quest is a term that refers to a mission that can be cleared by meeting certain predetermined conditions. A quest is also called an exploration or a task. A player who participates in a quest can clear the quest by meeting the certain conditions, and when the player clears a quest, the player is given a reward and the story of the game progresses.

The term "deck" also means a group made up of multiple characters. When a player is to perform a quest, he or she selects characters with the appropriate abilities to clear the quest, organizes a deck, and performs the quest. The game server 10 can store multiple decks organized by players, and when performing a quest, the player can select one of the stored decks to perform the quest.

When a player performs a quest, a certain parameter that the player possesses, called "stamina," is consumed. The amount of stamina consumed differs for each quest. In addition, the upper limit of stamina is set according to the player's level and experience points, etc. Stamina consumed by playing a quest is automatically restored over time.

Players can establish specific relationships (hereafter referred to as "friend relationships") with other players. Friend relationships can be established when both players approve each other. A list of other players with whom they have friend relationships is displayed on the player's game screen.

A deck is made up of characters selected by the player from among the characters owned by the player himself and characters owned by other players. Each player sets in advance the characters that can be organized into other players' decks (hereinafter referred to as "friend's character" or "specific character"). When a player carries out a quest, the player organizes a deck to be used for the quest and selects one other player from multiple other players listed on the game screen. When a player selects one other player, the friend's character of the selected other player is set in the deck and the quest begins. Note that the multiple other players listed on the game screen are players who are friends with the player, or other players selected arbitrarily by the game server 10.

In addition, as an exception, a player can set their own friend's character in a section where a specific character of another player is set among the characters that make up the deck. Also, when playing a quest, a player can select a deck that they have previously used in that quest, rather than creating a new deck.

The screen where you specify the deck to be used for the quest displays multiple character slots for setting up multiple characters to compose the deck.

The multiple character slots include normal slots in which a character owned by the player can be set, and specific slots in which a character owned by the player or a character owned by another player can be set. In this embodiment, for example, there may be three normal slots and one specific slot, but this is not limited to this.

In this game, if a character owned by the player other than the friend's character is set in a specific slot out of multiple character slots, the player's own friend's character will be updated to the character set in that specific slot. This situation can occur, for example, when a player selects a deck from decks they have used in the past when organizing a deck, and a character other than the character currently set by the player as the friend's character is set in the specific slot of the selected deck.

<Hardware Configuration>
2 is a diagram showing an example of the hardware configuration of the game server 10 and the terminal 20. The game server 10 and the terminal 20 each have a processor 11 such as a CPU (Central Processing Unit), a storage device 12 such as a memory, a HDD (Hard Disk Drive) and/or an SSD (Solid State Drive), a communication IF (Interface) 13 for wired or wireless communication, an input device 14 for accepting input operations, and an output device 15 for outputting information. The input device 14 is, for example, a keyboard, a touch panel, a mouse, and/or a microphone. The output device 15 is, for example, a display and/or a speaker.

<Function block configuration>
(Game Server)
FIG. 3 is a diagram showing an example of a functional block configuration of the game server 10. The game server 10 includes a storage unit 100 and a game control unit 110. The storage unit 100 can be realized by using a storage unit 12 included in the game server 10. The game control unit 110 can be realized by the processor 11 of the game server 10 executing a program stored in the storage unit 12. The program can be stored in a storage medium. The storage medium storing the program may be a non-transitory computer readable medium. The non-transitory storage medium is not particularly limited, and may be, for example, a storage medium such as a USB memory or a CD-ROM.

The memory unit 100 stores a player management DB 100a, a deck management DB 100b, and a used deck management DB 100c.

FIG. 4 shows the player management DB 100a, the deck management DB 100b, and the used deck management DB.
100c. The player management DB 100a manages game data owned by each player. The player management DB 100a also stores friend-used characters that can be organized into the decks of other players among the characters owned by the player. The player management DB 100a stores, in association with each other, for example, an ID (player ID) that uniquely identifies the player, the nickname of the player, the player IDs of other players registered as players in a friend relationship, the current location of the terminal 20 used by the player, the player's experience value, the player's rank and the player's stamina, and an ID (character ID) that uniquely identifies the friend-used character set by the player.

The deck management DB 100b manages the characters that organize each deck. For example, an ID (player ID) that uniquely identifies a player, an ID (deck ID) that uniquely identifies each player's deck, and an ID (character ID) that uniquely identifies the characters that organize each deck are stored in the deck management DB 100b in association with each other. In the example of FIG. 4, the fourth character (C003) is set as the "character ID" of the deck with the deck ID D001. This means that, in the deck, the player's own friend's character is exceptionally set in the portion where the specific character of another player is set.

The deck history DB 100c (deck history information) records a history (deck history) indicating which deck each player used when performing each quest in the past. In the deck history DB 100c, for example, an ID (player ID) that uniquely identifies a player, an ID (quest ID) that uniquely identifies a quest, and a history of multiple characters (character IDs) that constitute one or more decks used when performing a quest are stored in association with each other. The deck used (last time) stores the characters of the deck used when the previous quest was performed. The deck used (second time) stores the characters of the deck used when the quest was performed two times ago. Here, in the deck used (last time) and the deck used (second time), there are decks with three characters and decks with four characters. A deck with three characters indicates that a character owned by another player was set in the specific slot, and a deck with four characters indicates that a character owned by the player himself was set in the specific slot. That is, the deck usage history DB 100c includes information about specific slots of decks. The deck usage history DB 100c may also record historical information about decks that have been used by players to play quests and that have successfully cleared the quests.

Returning to FIG. 3, the explanation will continue. The game control unit 110 provides various functions necessary to execute the game. The game control unit 110 includes a reception unit 111, an execution unit 112, a display control unit 113, and an update unit 114.

The reception unit 111 receives from the player the selection of the quest to be performed, the selection of the deck to be used for the quest, etc.

The execution unit 112 executes the quest accepted by the acceptance unit 111.

The display control unit 113 displays various game screens related to the game on the screen of the terminal 20. It also displays a number of character frames that make up the deck used to play quests, and a screen that accepts the specification of characters to be set in each character frame.

When a character owned by the player and other than a friend's character is set in a specific slot among multiple character slots, the update unit 114 updates the friend's character stored in the player management DB 100a of the storage unit 100 to the character set in the specific slot.

(Terminal)
FIG. 4 is a diagram showing an example of a functional block configuration of the terminal 20. The terminal 20 includes a storage unit 200, a communication unit 201, a UI (User Interface) unit 202, and a game control unit 203. The storage unit 200 can be realized by using the storage unit 12 provided in the terminal 20. The communication unit 201, the UI unit 202, and the game control unit 203 can be realized by the processor 11 of the terminal 20 executing a program stored in the storage unit 12. The program can be stored in a storage medium. The storage medium storing the program may be a computer-readable non-transient storage medium. The non-transient storage medium is not particularly limited, and may be, for example, a storage medium such as a USB memory or a CD-ROM.

The storage unit 200 stores game data necessary for the game control unit 203 to execute the game. The game data includes character image data, game scenarios, etc.

The communication unit 201 has the function of performing various communications with the game server 10 using the communication IF 13.

The UI unit 202 has a function to receive various inputs from the player and to display various game screens on the display. The UI unit 202 also displays the game screens according to instructions from the game server 10.

The game control unit 203 provides various functions necessary to execute the game by cooperating with the game server 10. For example, the game control unit 203 provides a function to obtain various information (icon image data, text data, etc.) for drawing on the game screen from the game server 10.

Regarding the functional block configuration described above, all or part of the reception unit 111, execution unit 112, display control unit 113, and granting unit 114 included in the game server 10 may be configured to be provided in the game control unit 203 of the terminal 20.

<Processing Procedure>
Next, the processing procedure performed by the game server 10 when changing the character used by a friend will be described.

Figure 6 is a flowchart showing an example of a processing procedure performed by the game server. First, the reception unit 111 receives from the player a selection of a quest to be performed (S10). Next, the reception unit 111 receives from the player a selection of a deck to be used in the quest (S11).

Here, the display control unit 113 may obtain from the deck usage history DB 100c the history of decks previously used in the quest selected in the processing procedure of step S10, and display the obtained deck history on the game screen.

Figure 7 shows an example of a screen that displays deck history. In Figure 7(a), the decks used the previous time a quest was performed are displayed in frames F11 to F14. The current deck is displayed in frames F21 to F24. Frames F11 to F13 and frames F21 to F23 are normal frames, and F14 and F24 are special frames. Similarly, in Figure 7(b), the decks used the previous time a quest was performed are displayed in frames F31 to F34. The current deck is displayed in frames F41 to F44. Frames F31 to F33 and frames F41 to F43 are normal frames, and F34 and F44 are special frames. Note that the display example in Figure 7 is merely an example, and a deck used before the deck used the previous time a quest was performed (such as the time before last) may also be displayed.

Here, the display mode of the specific slots of the deck used when the previous quest was executed may be changed depending on whether the character is available for use in the quest. In other words, the display control unit 113 may display the character (specific character) set in the specific slot of the deck used in the past in a different manner depending on whether the character is available for use by the player. A state in which the player cannot use a character set in a specific slot may include, for example, a case in which the player does not currently own the character due to selling or combining the character, or a case in which the player currently owns the character but is rented to another player or is in a training state and cannot use the character himself. A state in which the player can use a character set in a specific slot may be, for example, a case in which the player currently owns the character, is not rented to another player, and is not in a training state.

Changing the display mode may mean, for example, changing the display mode so that when the player is unable to use the character set in the specific slot, the specific slot is displayed in a grayed-out state (frame F34 in FIG. 7(b)), and when the player is able to use the character set in the specific slot, an icon of the character or the like is displayed in the specific slot (frame F14 in FIG. 7(a)). Note that if another player's character was set in the specific slot of the deck used the previous time the quest was performed, the specific slot may also be displayed in a grayed-out state, or may be displayed in a mode other than grayed-out (for example, blanked out).

When button B10 or button B20 is pressed, the characters set in the deck used the previous time the quest was performed will be reflected in the current deck.

Returning to FIG. 6, the explanation will be continued. Next, the update unit 114 judges whether a character owned by the player and different from the current friend-used character is set in the specific slot of the current deck (S12). If a character different from the current friend-used character is set in the specific slot (S12-YES), the update unit 114 updates the friend-used character stored in the player management DB 100a of the storage unit 100 to the character set in the specific slot (S13). On the other hand, if a character different from the current friend-used character is not set in the specific slot, that is, if the same character as the current friend-used character is set in the specific slot or a character owned by another player is set in the specific slot (S12-NO), the friend-used character stored in the player management DB 100a of the storage unit 100 is not updated, and the processing proceeds to step S14.

Then, the execution unit 112 starts executing the quest (S14). Then, after starting execution of the quest, the game control unit 110 stores information about the deck used by the player in the quest in the deck usage history DB 100c.

<Modification>
In the present game, the quests may include a quest that satisfies a first condition and a quest that satisfies a second condition. Here, the quest that satisfies the first condition and the quest that satisfies the second condition may differ in at least one usable character. For example, a constraint condition (first attribute condition) on the attributes of a character usable in a quest that satisfies the first condition may differ from a constraint condition (second attribute condition) on the attributes of a character usable in a quest that satisfies the second condition. Specifically, the first attribute condition is a condition that allows a character of any rarity to be used, and the second attribute condition is a condition that allows a character of a rarity below a predetermined rank (for example, below the highest rank) to be used. Also, for example, the quest that satisfies the first condition may be a quest that does not impose constraints on usable characters, and the quest that satisfies the second condition may be a quest that imposes constraints on usable characters.

Furthermore, the friend's character may be set to a friend's character that can be organized by other players in a quest that satisfies a first condition (hereinafter referred to as a "first friend's character"), and a friend's character that can be organized by other players in a quest that satisfies a second condition (hereinafter referred to as a "second friend's character").

In this case, the memory unit 100 may store the first friend's used character and the second friend's used character in the player management DB 100a as the friend's used character.

The characters that can be set as the "First Friend's Character" may be limited to certain characters that are relatively weak. This is because when playing an easy-to-clear quest, if a strong Friend's Character is set in a specific slot in the deck, it becomes possible to incorporate a very powerful character into the deck, which upsets the game balance.

When a deck is organized for use in a quest that satisfies the first condition, the update unit 114 may update the first friend's character stored in the storage unit 100 to the character set in the specific slot when a character owned by the player that can be used in a quest that satisfies the first condition (more specifically, a character that satisfies the first attribute condition) other than the first friend's character stored in the storage unit 100 is set in the specific slot. When a deck is organized for use in a quest that satisfies the second condition, the update unit 114 may update the second friend's character stored in the storage unit 100 to the character set in the specific slot when a character owned by the player that can be used in a quest that satisfies the second condition (more specifically, a character that satisfies the second attribute condition) other than the second friend's character stored in the storage unit 100 is set in the specific slot.

For example, assume that character A is set as the first friend's character in player management DB 100a, and character B is set as the second friend's character.

Now, when organizing a deck to be used for a quest that satisfies the first condition, let us say that character D, a character owned by the player that can be used for the quest that satisfies the first condition, is set in the specific slot. In this case, the update unit 114 updates the first friend's character set in the player management DB 100a to character D. On the other hand, the update unit 114 does not update the second friend's character.

Similarly, when organizing a deck to be used for a quest that satisfies the second condition, assume that character E, a character owned by the player that can be used for the quest that satisfies the second condition, is set in the specific slot. In this case, the update unit 114 updates the second friend's character set in the player management DB 100a to character E. On the other hand, the update unit 114 does not update the first friend's character.

The above-described embodiments are intended to facilitate understanding of the present invention, and are not intended to limit the present invention. The flow charts, sequences, elements included in the embodiments, and their arrangements, materials, conditions, shapes, sizes, etc., described in the embodiments are not limited to those exemplified, and may be modified as appropriate. In addition, configurations shown in different embodiments may be partially substituted or combined.

<Additional Notes>
<Appendix 1>
A storage unit that stores, among characters owned by a player, specific characters that can be organized into the decks of other players;
a display control unit that displays a screen for receiving a plurality of character frames constituting a deck used in playing a quest and a character to be set in each character frame;
an update unit that updates the specific character stored in the storage unit to the character set in the specific character slot when a character owned by the player and other than the specific character is set in a specific slot among the plurality of character slots;
An information processing device having the above configuration.

Additional Note 1 makes it possible to increase the frequency with which characters that are set as characters that can be organized into other players' decks are changed.

<Appendix 2>
the plurality of character frames include a normal frame in which a character owned by a player can be set, and the specific frame in which a character owned by the player or a character owned by another player can be set;
The information processing device according to claim 1 .

Additional Note 2 makes it possible for players to increase the frequency with which they change the characters they have set as characters that can be organized into other players' decks.

<Appendix 3>
when a character owned by another player is set in the specific character slot, the update unit does not update the specific character stored in the storage unit.
3. The information processing device according to claim 1 or 2.

Additional Note 3 makes it possible to prevent characters that a player has set as a character that can be organized into another player's deck from being erroneously updated.

<Appendix 4>
the storage unit stores deck history information that stores a history of decks used for each quest;
the display control unit causes the screen to display a history of decks that have been used in the quest in the past;
The information processing device according to claim 1 , wherein the deck history includes information on the specific slot of the deck.

According to Appendix 4, players will be able to see what decks they used when completing quests in the past.

<Appendix 5>
the display control unit displays a specific character set in the specific slot of a deck used in the past in a different manner depending on whether the specific character is currently available to the player;
The information processing device according to claim 4.

According to Appendix 5, players can easily determine whether or not they currently own a character that was previously set in a specific slot as a character that can be organized into another player's deck.

<Appendix 6>
the storage unit stores, as the specific characters, a first specific character that can be organized by another player in a quest that satisfies a first condition, and a second specific character that can be organized by another player in a quest that satisfies a second condition;
The update unit is
When organizing a deck to be used for a quest that satisfies the first condition, when a character owned by the player and other than the first specific character is set in the specific slot, the first specific character stored in the storage unit is updated to the character set in the specific slot;
When organizing a deck to be used for a quest that satisfies the second condition, when a character owned by the player and other than the second specific character is set in the specific slot, the second specific character stored in the storage unit is updated to the character set in the specific slot.
The information processing device according to any one of claims 1 to 5.

According to Appendix 6, it will be possible to set and update two types of characters that can be organized into other players' decks.

<Appendix 7>
An information processing method performed by an information processing device,
storing in a storage unit, among characters owned by the player, specific characters that can be organized into decks of other players;
displaying a screen for receiving designation of a plurality of character slots constituting a deck used in playing a quest and characters to be set in each of the character slots;
when a character owned by the player and other than the specific character is set in a specific slot among the plurality of character slots, updating the specific character stored in the storage unit to the character set in the specific slot;
An information processing method comprising:

According to Supplementary Note 7, it is possible to increase the frequency with which characters set as characters that can be organized into other players' decks are changed.

<Appendix 8>
On the computer,
storing in a storage unit, among characters owned by the player, specific characters that can be organized into decks of other players;
displaying a screen for receiving designation of a plurality of character slots constituting a deck used in playing a quest and characters to be set in each of the character slots;
when a character owned by the player and other than the specific character is set in a specific slot among the plurality of character slots, updating the specific character stored in the storage unit to the character set in the specific slot;
A program for executing the above.

Additional Note 8 makes it possible to increase the frequency with which characters that are set as characters that can be organized into other players' decks are changed.

1...game system, 10...game server, 11...processor, 12...storage device, 13...communication IF, 14...input device, 15...output device, 20...terminal, 100...storage unit, 110...game control unit, 111...reception unit 111...execution unit, 113...display control unit, 114...update unit, 200...storage unit, 201...communication unit, 202...UI unit, 203...game control unit

Claims (4)

A processor is provided.
The processor,
Setting a specific character that is available to other players among the characters owned by the player;
Setting a plurality of characters in a display area for constructing a deck to be used in playing the game;
A character owned by the player or a character owned by another player can be set in a specific area of the display area;
When a first character owned by the player and different from the specific character is set in the specific area, the specific character is updated to the first character ;
When a character owned by the other player is set in the specific area, the specific character is not updated.
Information processing device. The processor sets a specific character that is available to other players among the characters owned by the player;
The processor sets a plurality of characters in a display area for constituting a deck to be used in playing the game;
A character owned by the player or a character owned by another player can be set in a specific area of the display area;
when a first character owned by the player and different from the specific character is set in the specific area, the processor updates the specific character to the first character ;
when a character owned by the other player is set in the specific area, the processor does not update the specific character;
Information processing methods. causing the processor to set a specific character that is to be made available to other players among characters possessed by the player;
causing the processor to set a plurality of characters in a display area for constructing a deck for use in playing the game;
A character owned by the player or a character owned by another player can be set in a specific area of the display area;
when a first character owned by the player and different from the specific character is set in the specific area, update the specific character to the first character ;
when a character owned by the other player is set in the specific area, the processor does not update the specific character;
A program that executes a process. A server and a terminal are provided,
The server,
Setting a specific character that is available to other players among the characters owned by the player;
setting a plurality of characters in a display area displayed on said terminal to construct a deck for use in playing the game;
A character owned by the player or a character owned by another player can be set in a specific area of the display area;
When a first character owned by the player and different from the specific character is set in the specific area, the specific character is updated to the first character;
When a character owned by the other player is set in the specific area, the specific character is not updated.
system.

Images