JP7206560B2 - Game system and game program - Google Patents

Description

The present invention relates to a game system and a game program for providing a game in which game contents such as characters are given to users by lottery.

2. Description of the Related Art Conventionally, there has been known a game in which a user wins a character used in the game through lottery (gacha). In particular, in this lottery (gacha), it is known that a character to be released is set for each scenario (see, for example, Non-Patent Document 1).

Sega Group Co., Ltd., Chain Chronicle 3, distributed on November 24, 2016, Internet <URL: http://chronicle.sega-net.com/>

However, the gacha in the conventional game does not relate to the character according to the game progress history in the scenario, and does not improve the interest of the gacha and motivate the user to request the gacha.

SUMMARY OF THE INVENTION Accordingly, it is an object of the present invention to provide a game system and a game program in which a lottery event for an object such as a character is more interesting than before.

A first invention provides a game system for progressing a game through a computer,
a game control unit that controls a character based on a user's operation and causes the game to progress;
a storage unit storing a lottery target list including information on a plurality of objects corresponding to events executed during the progress of the game;
a communication unit that receives a gacha request signal for making a gacha request based on the user's operation;
a lottery unit that selects the object from the lottery target list when the communication unit receives the gacha request signal;
History information of a character's interference with the object corresponding to an event executed during the progress of the game (hereinafter referred to as an execution event) is stored in the storage unit, and the lottery target list is generated or updated based on the history information. management department and
with
After the game progress is completed, the lottery unit permits the user to make the gacha request to select the object from the lottery target list generated or updated by the management unit based on the history information related to the game progress. do,
It's a game system.

A second invention provides a game system for progressing a game through a computer,
a game control unit that controls a character based on a user's operation and causes the game to progress;
a storage unit storing a lottery target list including information on a plurality of objects corresponding to events executed during the progress of the game;
a communication unit that receives a gacha request signal for making a gacha request based on the user's operation;
a lottery unit that selects the object from the lottery target list when the communication unit receives the gacha request signal;
History information of a character's interference with the object corresponding to an event executed during the progress of the game (hereinafter referred to as an execution event) is stored in the storage unit, and the lottery target list is generated or updated based on the history information. management department and
with
The management unit causes the storage unit to store, as history information, information on a type of action in which the character interferes with the object in the execution event.
It's a game system.

A third invention provides a game system for progressing a game through a computer,
a game control unit that controls a character based on a user's operation and causes the game to progress;
a storage unit storing a lottery target list including information on a plurality of objects corresponding to events executed during the progress of the game;
a communication unit that receives a gacha request signal for making a gacha request based on the user's operation;
a lottery unit that selects the object from the lottery target list when the communication unit receives the gacha request signal;
History information of a character's interference with the object corresponding to an event executed during the progress of the game (hereinafter referred to as an execution event) is stored in the storage unit, and the lottery target list is generated or updated based on the history information. management department and
with
The management unit stores cumulative information about the number of execution events in the storage unit, and updates the lottery target list and stores it in the storage unit when the cumulative information reaches a predetermined number.
It's a game system.

A fourth invention provides a game system for progressing a game through a computer,
a game control unit that controls a character based on a user's operation and causes the game to progress;
a storage unit storing a lottery target list including information on a plurality of objects corresponding to events executed during the progress of the game;
a communication unit that receives a gacha request signal for making a gacha request based on the user's operation;
a lottery unit that selects the object from the lottery target list when the communication unit receives the gacha request signal;
History information of a character's interference with the object corresponding to an event executed during the progress of the game (hereinafter referred to as an execution event) is stored in the storage unit, and the lottery target list is generated or updated based on the history information. management department and
with
at least one parameter is set in the object;
The management unit stores change information of the parameter in the storage unit, and when the change information reaches a predetermined value, updates the lottery target list and stores it in the storage unit.
It's a game system.

Advantageous Effects of Invention According to the present invention, it is possible to provide a game system and a program in which a lottery event for an object such as a character is more interesting than before.

1 is a block diagram showing the hardware configuration and functional configuration of a game system according to this embodiment; FIG. FIG. 10 is a diagram showing an example of a gacha list addition necessity management table T1 according to the present embodiment; FIG. 11 is a diagram showing an example of a gacharist management table T3 in the embodiment; FIG. 10 is a flow chart showing update processing of the gacha list addition necessity management table T1 and the gacha list management table T3 in the present embodiment. It is a flow chart which shows lottery processing in this embodiment.

[Embodiment]
A game system 1 according to an embodiment of the present invention will be described with reference to FIGS. 1 to 4. FIG. The game system 1 of the present invention shown in FIG. 1 executes a game on a game device 3 (terminal device) such as a smart phone, a personal computer, or a home-use game machine.

The game described in this embodiment is a role-playing game that includes a formation part and a battle part. For example, a user obtains an object such as a character through a lottery (gacha), and in an organized part, among the characters associated with the user, a player character controlled based on the user's operation and a non-player character controlled by a computer A unit (party, deck) is created by combining a player character with sub-characters that support the player character (for example, fellow characters that follow and fight together with the character). In each event (chapter, story) in the battle part, the user operates and instructs the created unit to meet various characters in the virtual space, fight, make friends, and so on. However, it is a game that progresses by capturing quests centered on a predetermined story.

It should be noted that, in the event that is executed for the first time, the player characters and sub-characters organized into the party are fixed as predetermined characters (initial fixed characters) and cannot be organized. For example, it is necessary to play all 10 types of events 1 to 10 described later with a party of initial fixed characters.

An "event" is, for example, a user operating a party, moving the party in the virtual space, starting from the base castle, going through the forest, entering the village, crossing the mountain, and attacking the enemy's castle. It is one event until you defeat the monster that lives in the castle. Various characters such as enemy characters, villager characters, etc. are arranged in the virtual space in addition to the characters belonging to the party. During this event, the player encounters and fights enemy characters in forests and mountains, and converses with villager characters in villages, based on user's operations. In other words, depending on the user's operation, during the event, there are enemy characters and villager characters that the player never encounters, and there are characters that can or cannot be defeated.

In the organization part, in addition to organization of units, it is possible to combine characters with items (characters), which are so-called training materials, to level up characters, and to set weapons and skills to be possessed. In addition, by clearing quests, users can acquire various characters including characters and sub-characters, training materials and items, as well as experience points and in-game currency according to the conditions for clearing game tasks. You can train characters and create new powerful units to take on highly difficult quests.

<About hardware configuration>
Referring to FIG. 1, the hardware configuration of a server device 2 that implements a game system 1, and the hardware configuration of a plurality of game devices 3 that are communicatively connected to this server device 2 via a communication network 4 such as the Internet line. I will explain the hardware configuration.

A game system 1 is composed of a server device 2 and a plurality of game devices 3 . In this game system 1 , the server device 2 and each game device 3 communicate with each other at predetermined timings, and the game progresses based on the game program and game data distributed from the server device 2 .

The server device 2 stores game programs and game data in the storage unit 21 . Information processing means 201 and management means 202 manage game data of each game device 3 (account). The server device 2 and the game device 3 communicate with each other via the communication network 4 .

The game device 3 receives (downloads) the game program and game data stored in the storage unit 21 of the server device 2 via the game device 3 in order to execute (play) a predetermined game based on the user's operation. and install). The game device 3 also receives (downloads and installs) the update game program and game data.

The game device 3 progresses the game on the game device 3 based on the installed game program and game data. 340 or the like.

Different account information (unique identification information) is given to each game device 3 and each user. An ID (identification code) is assigned to each piece of account information.

The server device 2 manages account information of each user, receives data about the game progress status of each account from the game device 3 , and stores the data in the storage unit 21 .

For example, when the user performs an operation to start a game, each game device 3 communicates with the server device 2 via the communication network 4, and account information is transmitted from the game device 3. . The server device 2 performs predetermined authentication based on the transmitted account information, and transmits to the game device 3 data necessary for the progress of the game (data regarding the progress of the game).

The game device 3 receives data relating to the progress of the game for this account, and progresses the game on the game device 3 . In addition, the game device 3 transmits data regarding the progress of the game to the server device 2 not only at the start of the game but also at a predetermined timing of the progress of the game (at the time of data update such as consumption of items or completion of game tasks).

- Hardware configuration of server device 2 The server device 2 includes a control unit 20 , a storage unit 21 , and a network interface 22 .

Storage unit 21 and network interface 22 are connected to control unit 20 of server device 2 via bus 200 .

The control unit 20 controls operations of the server device 2 .

The storage unit 21 is mainly composed of an HDD (Hard Disk Drive), a RAM (Random Access Memory), and a ROM (Read Only Memory).

The storage unit 21 stores, for example, a game program and data for executing the game (including information on the game progress status of the account), a game program for realizing the game system 1 of the present invention (for executing each event, and so on). modules) and data, an information processing module, a management module, a lottery module, and a transmission module are stored.

The information processing module is a module that receives data and various signals necessary for progressing the game from each game device 3 . Also, the information processing module is a module that uses the account information transmitted from the game device 3 to authenticate the account information. Further, when a predetermined game progress is completed in the game device 3, the information processing module becomes ready to receive a gacha request signal, which will be described later.

The management module is a module for generating and updating management tables such as the gacha list addition necessity management table T1, the user management table T2, and the gacha list management table T3 stored in the storage unit 21. FIG. FIG. 2 shows an example of the gacha list addition necessity management table T1. Further, the gacha list addition necessity management table T1 and the gacha list management table T3 are generated one by one for each user ID and are associated with each other.

Here, in FIG. 2, "event" is information on the type of event to be executed, and "character" is information on the type of character appearing in the event. In the present embodiment, 10 types of events 1 to 10 are set in advance as "events" in the gacharist addition necessity management table T1, and the game device 3 selects an event in order from 1 or an arbitrary event. It is ready to be selected and played. As shown in FIG. 2, the "event" type information includes corresponding characters (for example, characters placed in the virtual space within the game, and which player characters (party) can encounter in the event). a to j are associated with each other in order as the information of characters with a certain character).

Also, the "interference flag" in FIG. 2 is history information regarding actions and states of the character (non-player character) corresponding to the executed event. Each character has ability values such as physical strength, attack power, defense power, magic power, skills (such as being able to perform special attacks and being resistant to attacks from enemies), as well as level, rarity, and friendship with the player character. Various parameters (states) such as degree, relationship with the player character are associated with each other. For example, based on the user's operation, when the character meets the player character in the virtual space and becomes an ally, the state (interference flag) is displayed as "1", and the player character increases the physical strength of the character in battle. The state (interference flag) that was set to 0 and defeated (killed) is displayed as "0".

In addition, the "need to add gacha list" in FIG. When the "interference flag" is "1") is displayed as "1", and when the addition is not necessary (not included) (here, when the "interference flag" is "0") is displayed as " 0” is displayed.

Note that the gacharist management table T3 is information of a lottery target list including object information related to a plurality of characters corresponding to events executed during the progress of the game. For example, as shown in FIG. 3(a), an initial gachar list management table T3 generated in advance by executing the management module includes information on 10 characters (initial character list). Since it is in the initial state, the additional character information (additional character list) does not yet include information on characters to be added. Here, the ten initial characters may all be different characters, or may overlap partially or wholly.

In addition, the gacharist management table T3 includes characters whose "gacharist addition necessity" in the gacharist addition necessity management table T1 is "1" (addition required), depending on the result of the executed event and the conditions set in advance. is added and updated, and stored in the storage unit 21 .

Therefore, for example, in the event "1" in the gacharist addition necessity management table T1, if the "gacharist addition necessity" is "1" (addition required), after the currently executed event (game After clearing), the gacharist management table T3 changes from the state of FIG. 3(a) to the state of FIG. (including the image information of the character “a”)), and stored in the storage unit 21 . Note that the update timing of the gacharist management table T3 does not have to be after the completion of the event, and may be updated each time such as at a predetermined timing during the event. At least, it should be updated/confirmed from the start of the event to the execution of Gacha.

Also, for example, if the events in the gacha list addition necessity management table T1 are executed from "1" to "10" and the gacha list addition necessity management table T1 is in the state shown in FIG. After the completion of the event (after clearing the game), the gacharist management table T3 displays the information of the character whose "gacharist addition necessity" is "1" (addition required) as a result of the execution of the management module. are added each time, and finally updated to the state shown in FIG.

Here, each of the character information in the character list in the gacharist management table T3 includes a character image of each character, ability values (not shown, but for example physical strength, attack power, defense power, magic power, etc.), level, Various information such as rarity is associated and stored in the storage unit 21 .

Also, the management module is a module that manages information regarding the progress of the game for each user's account information. The information here is, for example, the data in the gacha list addition necessity management table T1, the user management table T2, and the gacha list management table T3.

Note that the user management table T2 is a data table showing information about each user. Level, event ID/name in which the user is participating, points that the user can use in the game, and information on game media such as player characters, sub-characters, and items associated (owned) by the user in the game including.

The lottery module is a module for selecting a character-related object from the gacha list management table T3.

The transmission module is a module that reads game data to be transmitted from the server device 2 to each game device 3 and transmits information such as the read data to the game device 3 .

Network interface 22 is connected to communication network 4 in order to transmit and receive data between server device 2 and each game device 3 .

- Hardware configuration of the game device 3 The game device 3 includes a liquid crystal screen 330 , a speaker 340 and a touch pad 350 . In this game device 3, a game progresses based on a game program and data read from a storage medium or the like. Also, the game device 3 can perform data communication with the other game device 3 and the server device 2 via a communication network 4 such as the Internet or a short-range wireless communication device.

The game device 3 includes a control section 30 , a storage section 31 , a network interface 32 , a graphics processing section 33 , an audio processing section 34 and an operation section 35 .

Storage unit 31 , network interface 32 , graphics processing unit 33 , audio processing unit 34 , and operation unit 35 are connected to control unit 30 via bus 300 .

The control unit 30 controls operations of the game device 3 .

The storage unit 31 is mainly composed of HDD, RAM and ROM. Storage unit 31 stores, for example, a game program and data for executing a game. The storage unit 31 also stores account information to be transmitted to the other game device 3, information about friends, other account information received from the other game device 3, and the like.

The network interface 32 is connected to the communication network 4 and transmits and receives data between the server device 2 and each game device 3 or between the game devices 3 via Internet communication.

The graphics processing unit 33 draws a game image including the virtual space and each character in a moving image format according to instructions from the control unit 30 . A game image drawn in a moving image format by the graphics processing unit 33 is displayed on the liquid crystal screen 330 as a game screen.

The audio processing unit 34 reproduces and synthesizes digital game sounds according to instructions from the control unit 30 . A speaker 340 is also connected to the audio processing unit 34 . The game sound is output from the speaker 340 to the outside.

The operation unit 35 is connected to a touch pad 350 attached (built-in) to the game apparatus 3, and can transmit and receive data regarding operation input. The user inputs operation signals to the game device 3 by operating operators (not shown) such as buttons provided on the touch pad 350 .

<About the functional configuration of each control unit>
Functional configurations of the control unit 20 of the server device 2 and the control unit 30 of the game device 3 that implement the game system 1 will be described with reference to FIG.

- Functional configuration of the control unit 20 of the server device 2 The control unit 20 of the server device 2 functions as information processing means 201, management means 202, lottery means 203, and transmission means 204 by executing a predetermined game program. do.

The information processing means 201 receives data necessary for progressing the game from each game device 3 . Also, the information processing means 201 authenticates the account information using the account information transmitted from the game device 3 .

The information that the information processing means 201 receives from each game device 3 includes, for example, account information of the user or the game device 3, various signals, and information on the progress of the game. Each information transmitted from each game device 3 is transmitted to each means via the information processing means 201, but the description of this point may be omitted below for convenience of explanation. Further, when the game device 3 completes a predetermined game progress (for example, an event currently being executed is completed), the information processing means 201 becomes ready to receive a gacha request signal, which will be described later.

The management means 202 determines whether or not various information relating to the progress of the game has been received from the game device 3 via the information processing means 201. update the management tables such as the gacha list addition necessity management table T1, the user management table T2, and the gacha list management table T3 stored in (overwrite storage in the storage unit 21).

For example, the management means 202 receives character information corresponding to the event information executed during the progress of the game received by the information processing means 201, the state of interference between this character and the player character (meeting, talking, fighting, defeating, etc.). etc.) and information on necessity of addition to the gacha list (gacha list management table T3) are associated, and various information in the gacha list addition necessity management table T1 is updated and stored in the storage unit 21. Let

Also, for example, the management means 202 determines whether or not the game has been cleared (whether the event currently being executed has been completed), and after the game is cleared (after the event has been completed), the gacharist addition necessity management is performed. Based on the table T1, the information of the lottery target list in the gacha list management table T3 is updated and stored in the storage unit 21.例文帳に追加That is, the management means 202 makes the information of the gacharist management table T3 include the information of the characters involved in the player character during the event, based on the result of the executed event and the conditions set in advance. process.

Here, examples of the "result of the executed event" include, for example, encountering the player character in the virtual space by the executed event, and in a battle (battle) with the encountered character, the result of the battle (opponent character is defeated (killed)), a parameter associated with the character such as friendliness is made equal to or greater than a predetermined value, or the character is made an ally.

Also, sub-characters are subject to the judgment as to whether or not they need to be added to the gacharist management table T3 (gacharist), and the sub-characters are managed as companions with the player character from the beginning and are set in the party. From this state, if you survive until the end of the event, or if parameters such as friendship are kept above a predetermined value, the state of the interference flag (need to add gacharist) in FIG. 3 can be set to "1". can. As a result, the sub-character that survived until the end (game clear) can be acquired by Gacha, and the acquired character can be used as a player character.

In addition, the management unit 202 manages information regarding the progress of the game for each account information.

In addition, after the information processing means 201 receives the account information and various signals from each game device 3, the management means 202 reads the game data based on the account information and various signals from the storage section 21, and the information processing means 201 , or to the game device 3 via the transmission means 204 .

Also, the management means 202 determines whether or not a gacha request signal has been received from the game device 3 via the information processing means 201 . When the information processing means 201 determines that the gacha request signal has been received from the game device 3, and when a character is selected from the gacha list management table T3 by lottery by the lottery means 203, the management means 202 applies the information of the character. It is updated in association with the user management table T2 of the user to be updated and stored in the storage unit 21 .

The characters (newly added characters) newly stored in the user management table T2 are used when the user re-executes the game progress (battle part) of the game completed (cleared game) by the corresponding user. In the organization part as a preparation stage for the battle part, newly added characters as player characters and sub-characters are organized into units and are ready for use. For example, in a game that has been cleared, the newly added character can be used as a player character or companion (sub-character) in place of the initial fixed character, and the game can be played again in a state in which combat units can be created.

When the information processing means 201 receives a gacha request signal from the game device 3 after the end of the event, the lottery means 203 selects objects related to a predetermined number of characters from the gacha list management table T3 stored in the storage unit 21. draw a lottery for The lottery result information is transmitted from the lottery means 203 to the management means 202, the game device 3, and the like.

The transmission means 204 transmits various data in the server device 2 to the game device 3 as necessary.

- Functional configuration of the control unit 30 of the game device 3 The control unit 30 of the game device 3 executes a game program downloaded (installed) in the storage medium inserted in the game device 3 or in the storage unit 31 of the game device 3 . By doing so, it functions as game control means 301 and communication means 302 .

The game control means 301 reads the game data received from the server device 2 and the game data (data such as objects and textures) stored in the storage unit 31, and creates a two-dimensional or three-dimensional virtual game space (for performing events). (including game space, etc.). Furthermore, the game control means 301 generates a virtual space and arranges non-player characters such as characters (player characters), sub-characters and enemy characters in the virtual space.

In addition, the game control means 301 responds to an operation signal to the touch pad 350 connected to the own game device 3 and the progress of the game to participate in an event, act of the own player character in the virtual space, sub-character and actions of non-player characters such as enemy characters.

The game control means 301 generates information for displaying these virtual space and characters as a game screen on the liquid crystal screen 330 . The graphics processing unit 33 draws a game image according to these pieces of information.

The game control means 301 receives information for displaying on the liquid crystal screen 330 a user interface (not shown) such as button icons for transmitting various requests such as gacha request signals to the server device 2 as necessary. Generate. The graphics processing unit 33 draws a user interface image (not shown) according to these pieces of information.

For example, when the lottery event starts after the gacha request signal is transmitted, the game control means 301 generates an acquisition request for information necessary for drawing the game screen in the initial state of the lottery event, to transmit this acquisition request to the server device 2. After receiving the necessary information from the server device 2 via the communication means 302, the game control means 301 draws the game screen in the initial state of the lottery event based on this necessary information, and displays it on the liquid crystal screen 330. display.

Further, after the start of the lottery event, the game control means 301 generates an acquisition request for information necessary for drawing the lottery result on the game screen, and transmits this acquisition request to the server device 2 via the communication means 302. . The game control means 301 receives necessary information from the server device 2 via the communication means 302 (information such as the character selected in the lottery, name, ability, etc.), and then determines the result of the lottery based on this necessary information. The game screen (not shown) is drawn and displayed on the liquid crystal screen 330 .

<Regarding management table update processing and lottery processing>
Hereinafter, update processing of the gacharist addition necessity management table T1 and gacharist management table T3 and lottery processing in the game system 1 of the present invention will be described with reference to FIGS.

FIG. 4 is a flow chart showing update processing of the gacharist addition necessity management table T1 and the gacharist management table T3 in the game system 1 of the present invention. FIG. 5 is a flowchart showing lottery processing. Using this flowchart, a case will be described in which the server device 2 executes update processing of the gacha list addition necessity management table T1 and the gacha list management table T3, and lottery processing based on the user's operation on the game device 3. do. Here, a case where event "1" shown in FIG. 2 is executed in a game played by a certain user will be described as an example. Further, the "interference flag" and the "necessity of addition to the gacha list" of the gacha list addition necessity management table T1 are set to "0" in the initial state.

First, when the game is started on the game device 3 based on the user's operation (step S1), the management means 202 determines whether or not the character "a" appearing in the event "1" interferes with the player character. (Step S2). Whether or not there has been interference is determined by, for example, the management means sending information indicating that the character "a" who appears during the execution of the event "1" and the player character have met and made the character "a" a companion. 202 has received or not.

When the management means 202 determines that the character "a" and the player character have interfered (step S2: YES), the management means 202 selects the event "1" in the gacharist addition necessity management table T1 of FIG. The "interference flag" and the "gacharist addition necessity" are updated from "0" to "1" and stored in the storage unit 21 (step S3). Then, step S4, which will be described later, is executed. Moreover, when the management means 202 determines that the character "a" and the player character did not interfere (step S2: NO), step S4, which will be described later, is also executed.

In step S4, the management means 202 determines whether or not the game has been cleared (whether the event currently being executed has been completed) based on the various information regarding the progress of the game received from the game device 3 via the information processing means 201 . If the management means 202 determines that the game has not been cleared (step S4: NO), the process returns to step S2.

On the other hand, if the management means 202 determines that the game has been cleared (step S4: YES), the management means 202 performs a Then, the gacha list management table T3 is updated and stored in the storage unit 21 (step S5). For example, the management means 202 changes from the state of FIG. 3A to the state of FIG. state and store it in the storage unit 21 .

Next, the management means 202 permits reception of a gacha request signal from the game device 3 (step S6). Then, the update processing of the management table ends.

Here, when reception of the gacha request signal transmitted from the game device 3 is permitted by the management means 202, the lottery processing of FIG. 5 becomes possible. The lottery process will be described below.

When management means 202 receives a gacha request signal from game device 3 via information processing means 201 (step S10), lottery means 203 performs gacha (lottery) based on updated gacha list management table T3. (step S11). That is, the lottery means 203 randomly selects a predetermined number (for example, three) of characters (objects) from the initial characters "A" to "J" and the additional character "a" shown in FIG. do.

Subsequently, the transmitting means 204 stores the lottery result information (information including the image information of the selected character) in the storage unit 21 and transmits it to the game device 3 (step S12). Then, the lottery process of the present invention ends.

When the game device 3 receives the lottery result information in step S12, for example, the game control means 301 of the game device 3 performs the following process. That is, the game control means 301 generates an acquisition request for information (name information of the selected character, ability information, etc.) necessary for indicating the result of the lottery, and sends the acquisition request to the server device 2 via the communication means 302. Submit your request. Subsequently, the game control means 301 receives information necessary for indicating the result of the lottery from the server device 2 via the communication means 302, and based on this information, the lottery result screen (for example, the given character , ability values, etc.) are drawn and displayed on the liquid crystal screen 330 .

To summarize the above, the game system 1 of this embodiment is
In a game system that progresses through a computer (server device 2, game device 3),
a game control unit that controls a character based on a user's operation and causes the game to progress;
a storage unit 21 storing a lottery target list (gacha list management table T3) containing information on a plurality of objects corresponding to events executed during the progress of the game;
a communication unit (information processing unit 201) that receives a gacha request signal for making a gacha request based on the user's operation;
a lottery unit 203 that selects the object from the lottery target list (gacha list management table T3) when the communication unit (information processing unit 201) receives the gacha request signal;
History information of the player character's interference with the object corresponding to the event executed during the progress of the game (hereinafter, execution event) is stored in the storage unit, and based on the history information, the lottery target list (gacha list management) is stored. a management unit 202 that generates or updates the table T3);
is provided.

[The invention's effect]
According to the game system 1 of the present embodiment, it is possible to improve the interest of the character lottery event more than before.

[Other embodiments]
The control means and processing procedures described in the above embodiments are examples, and the embodiments of the present invention are not limited to these. The processing procedure and the like can be appropriately changed in design without changing the gist of the present invention.

In the above-described embodiment, when the "interference flag" in the gacharist addition necessity management table T1 is set to "1", it is only when the player is made a friend. It may also include the case of meeting and just talking.

Further, in the above-described embodiment, when the "interference flag" in the gacha list addition necessity management table T1 is set to "1" (in a state of becoming a friend), the "gacha list addition necessity" is set to "1" (addition necessity state), on the contrary, it may be set to "0" (not added state) so that information is not added to the gacharist management table T3. At this time, the "interference flag" in the gacharist addition necessity management table T1 is set to "0" (the character is defeated), and the "gacharist addition necessity" is set to "1" (addition possible state). may

In the above-described embodiment, as the interference state information (history information) for which the "interference flag" is to be updated, the state in which the character meets the player character in the virtual space and becomes friends with the player character based on the user's operation. , the state in which the player character is defeated (death) by reducing the physical strength of the character to 0 in the battle has been described as an example, but the present invention is not limited to this, and may be another state. For example, it may be that the player character meets the character itself, that the player character has a conversation (execution of a conversation event), that a battle (execution of a battle event) occurs, or that an item owned by the player character is granted (execution of an item granting event). It may also include the player character's interference with various events that occur in the game, such as the player character receiving an item from the character (execution of an item giving event). Also, a plurality of these interference states (executed events) may be combined. For example, the condition for updating the "interference flag" may be that a predetermined character is defeated and that character becomes a friend of the player character.

Further, in the above-described embodiment, the "interference flag" in the gacharist addition necessity management table T1 is used as an example of the action type of the character (non-player character). may For example, the number of times a player character interacts with a character (non-player character) during an event may be counted, and the flag may be set to "1" when the number exceeds a predetermined number. Also, the flag is set to "1" even if the player character and the character have just talked to each other once, or if the player character and the character have just met without speaking (such as just being displayed on the game screen that the user is playing). ” may be used.

Further, in the above-described embodiment, the history information of the character corresponding to the event executed during the progress of the game is used to update the gacharist management table T3 that includes the character and draw the lottery. Using history information of characters corresponding to events that have not been executed in the course of the game (for example, characters that have not been met in the game or characters that have not yet appeared in the game), gacharist management that includes the characters Gacha (lottery) may be performed by updating to table T3.

Further, the accumulated information of the number of times the event has been executed is stored in the storage unit, and when the accumulated information reaches a predetermined number, for example, the information of the characters made friends is added to update the gacha list management table T3. may be stored in the storage unit, and gacha (lottery) may be performed based on this updated gacha list management table T3.

Further, the lottery means updates the gacharist management table T3 so that the character information included in advance in the gacharist management table T3 is updated to exclude the information about the character who became a partner in the event (information about the character related to the history information). A gacha (lottery) may be held based on the table T3.

Further, if there is an event with the "interference flag" set to "0" among the executed events, the lottery means selects characters preliminarily included in the gacharist management table T3 (for example, 100 characters in the initial state). ), the gacha (lottery) may be performed based on the gacha list management table T3 updated to exclude (do not include) characters related to the event.

A character type may be set for the character in addition to parameters such as ability values and rarity. The character type distinguishes between a character that can be used as a player character controlled by a user's operation and a character that can be used as a sub-character (non-player character) controlled by a computer. When the user organizes the unit in the organization part, the player character and the sub-character may be selected based on this type. Further, among the characters that can be formed into a unit, a plurality (or all) of them may be used as player characters, or a plurality (or all of them) may be used as sub-characters. Further, the character type of the character to be added to the gacharist management table T3 may change depending on how the character interacts with the character during the progress of the game.

Also, depending on how a character is defeated in battle (defeated with one blow, defeated with several or more attacks, etc.), the character's ability (attack power, defense power, skill, etc.) to be added to the gacharist management table T3 is determined. It is set in advance so that the information changes, and when it is defeated in battle during the event, parameters such as ability values are determined according to the way the character is defeated, and the character with the determined parameters is determined. Information may be added to the gacha list management table T3. As for the character image, the image (appearance) of the character added to the gacharist management table T3 may be changed depending on whether the character has a scar on the face, a cut tail, or how the character is defeated in battle. Note that these images are stored in advance, and an image that satisfies conditions such as how to tilt is selected.

For example, when a character is defeated with its physical strength set to 0, the "physical strength", which is one of the character's parameters, is set to a state lower than the initial value set for this character. Added. Attacks of the player character have attributes such as fire, water, and thunder. is set in the "skill", which is one of the character's parameters, a skill that is resistant to attacks of a specific attribute (attacks of a specific attribute are difficult to work), and in the gacharist management table T3 may be added.

In addition, depending on how the character treats allies in battle (inviting them to join after weakening them, persuading them to become friends before attacking, etc.), the ability of the character to be added to the gacharist management table T3 (attack strength, defensive power, special skills, etc.) change in advance, and when the battle during the event is completed, the character with the ability according to the way he treats his friends. Information may be added to the gacha list management table T3.

For example, if you have a lot of conversations with a character you made friends with and your friendship level is high, one of the character's parameters, "friendship level," will be set to a value higher than the initial value set for this character, and you will be able to play the gacha. It may be added to the list management table T3. Characters with a high degree of friendship can follow instructions from the player character (user) more easily, and if the player character and characters with a high degree of friendship are organized into a unit at the same time, special skills can be used, and parameters can change. There are advantages to

Further, in the above-described embodiment, if a character to be added to the gacharist management table T3 as a companion is accidentally defeated in battle, the user can perform a predetermined operation to restore the facility set during the game (for example, (church, hospital, etc.), the defeated character may be revived, and the information of the character may be added to the gacharist management table T3. In addition, resurrection (rewriting of the interference flag) may require consumption of resurrection items such as billing, in-game currency, and tickets.

Further, if the game is cleared once with the player character and the sub-character, and if the friendly relationship between the player character and the sub-character reaches a predetermined level or more, the sub-character at this time is updated to the strong character information, It may be added to the gacha list management table T3.

Further, in the above embodiment, in the first event to be executed, it was necessary to play all of the 10 types of events 1 to 10 with the initial fixed character party, but this is not the only option. For example, it may be necessary to play with an initial fixed character in the first event (eg event 1). In this case, for example, after clearing Event 1, the new character acquired in the subsequent gacha can be added to the combat unit, and the unit can be played in the next play (play in another stage such as stage 2). You may do so.

In addition, it may be necessary to play with an initial fixed character in some preset events (eg, events 1, 3, and 5). In this case, for example, after clearing all events 1, 3, and 5, add the new character acquired in the subsequent gacha to the battle unit, and use that unit for the next play (play in another stage such as stage 2). ), you may be able to play.

In addition, the management means may or may not add character information to the gacharist management table T3 depending on the type of history information of actions between the player character and the character. For example, if the player character talks to the character that the player character has met, it is added to the gacharist management table T3, and if it does not talk, it is not added to the gacharist management table T3 (if it is included in the gacharist management table T3 in the initial state). are excluded), etc.

In the above embodiment, an object that appears and is arranged in the virtual space is described as a character, but the object is not limited to this. The objects may be characters (player characters and non-player characters), equipment items such as weapons, protective gear, and costumes equipped by the characters, recovery items that can be used by the characters, attack power-up items, and the like. That is, the objects added to the gacharist management table T3 are not limited to characters, and may be accessories, items, and the like.

If the object is an item, the interference state information (history information) for which the "interference flag" is updated is based on the user's operation, indicating that the player character possessed the item placed in the virtual space ( associated with the player character, such as picking it up, purchasing it, or giving it to the player character); displayed on the display unit). Also, a plurality of these interference states (executed events) may be combined. For example, the condition for updating the "interference flag" may be that a predetermined item is purchased and set (equipped) by the player character.

Furthermore, even if the object selected by gacha (lottery) is a character, the object that the character (player character or non-player character) interferes with in the progress of the game (execution event) need not be a "character". , "items". That is, when an item such as Weapon A is obtained in the progress of the game, the "interference flag" may be updated, and the character a corresponding to the Weapon A may be added to the Gacharist. Conversely, even if the object selected by gacha (lottery) is an item, the object that the character (player character or non-player character) interferes with in the progress of the game (execution event) does not need to be an "item". It may be a "character" instead of a character. That is, when a character such as character b is made a friend in the progress of the game, the "interference flag" may be updated, and the weapon B corresponding to the character b may be added to the Gacharist.

The management means may or may not add item information to the gacharist management table T3 depending on the type of history information of actions between the player character and the item. For example, items (weapons, etc.) acquired by the player character in the progress of the game are added to the gacharist management table T3. excluded), etc.

Parameters such as offensive power, defensive power, skill, and rarity may be set for the item as well as for the character. In addition, the parameters of these items may change depending on the state of use (state) during the progress of the game. For example, if the item is a weapon, the attack power or the like may be changed according to the frequency of use of the weapon during game progress.

Also, parameters for objects such as characters or items may be cumulatively changed by executing an event multiple times.

The game described in the above embodiment is a role-playing game that includes a formation part and a battle part, but the genre of the game is not limited to this. For example, it can be applied to any game genre, whether cooperative or competitive.

Also, in the above-described embodiment, the characters that can be organized into units in the organization part are sub-characters (sub-objects), but the present invention is not limited to this. For example, all characters that can be organized into units in an organized part may be player characters (player objects), and some of these player characters may be NPCs (sub-characters (sub-objects)).

Also, if there is a character that can be obtained by executing the gacha, it is used as a player character (player object) or as a sub character (sub object) in the unit formation in the formation part, based on the user's operation. can be selected by

Further, when a character (object) is obtained by executing the gacha (a character (object) is additionally registered in the gacha list management table T3), the character (object) type is as follows. Whether to be additionally registered as a player character (player object) or to be additionally registered as a sub-character (sub-object) may be selected by lottery. At this time, information on the type of the selected character (object) is associated with each information on the corresponding character (object) in the gacharist management table T3.

In the above embodiment, an example using a mobile terminal device as a game device is described, but the present invention is not limited to this. For example, the present invention can be implemented using arcade game cabinets provided at game arcades. Also, the present invention can be realized by using a home-use game device as the game device. Also, a system may be constructed in which each function according to the present invention is appropriately allocated to the game device and the server device. For example, the game control section may be configured in the server device, or the storage section may be configured in the game device.

Even when these other embodiments are employed, the effects of the present invention are exhibited. Further, it is also possible to appropriately combine this embodiment with other embodiments, and other embodiments with each other.

1 game system 2 server device (computer)
201 information processing means (information processing unit)
202 Management Means (Management Department)
203 lottery means (lottery section)
204 transmission means (transmission unit)
3 game device (computer)
301 game control means 302 communication means 4 communication network (network)

Claims (4)

In a game system that progresses a game through a computer,
a game control unit that controls a character based on a user's operation and causes the game to progress;
a storage unit storing a lottery target list including information on a plurality of objects corresponding to events executed during the progress of the game;
a communication unit that receives a gacha request signal for making a gacha request based on the user's operation;
a lottery unit that selects the object from the lottery target list when the communication unit receives the gacha request signal;
History information of a character's interference with the object corresponding to an event executed during the progress of the game (hereinafter referred to as an execution event) is stored in the storage unit, and the lottery target list is generated or updated based on the history information. management department and
with
After the game progress is completed, the lottery unit permits the user to make the gacha request to select the object from the lottery target list generated or updated by the management unit based on the history information related to the game progress. do,
game system. In a game system that progresses a game through a computer,
a game control unit that controls a character based on a user's operation and causes the game to progress;
a storage unit storing a lottery target list including information on a plurality of objects corresponding to events executed during the progress of the game;
a communication unit that receives a gacha request signal for making a gacha request based on the user's operation;
a lottery unit that selects the object from the lottery target list when the communication unit receives the gacha request signal;
History information of a character's interference with the object corresponding to an event executed during the progress of the game (hereinafter referred to as an execution event) is stored in the storage unit, and the lottery target list is generated or updated based on the history information. management department and
with
The management unit causes the storage unit to store, as history information, information on a type of action in which the character interferes with the object in the execution event.
game system. In a game system that progresses a game through a computer,
a game control unit that controls a character based on a user's operation and causes the game to progress;
a storage unit storing a lottery target list including information on a plurality of objects corresponding to events executed during the progress of the game;
a communication unit that receives a gacha request signal for making a gacha request based on the user's operation;
a lottery unit that selects the object from the lottery target list when the communication unit receives the gacha request signal;
History information of a character's interference with the object corresponding to an event executed during the progress of the game (hereinafter referred to as an execution event) is stored in the storage unit, and the lottery target list is generated or updated based on the history information. management department and
with
The management unit stores cumulative information about the number of execution events in the storage unit, and updates the lottery target list and stores it in the storage unit when the cumulative information reaches a predetermined number.
game system. In a game system that progresses a game through a computer,
a game control unit that controls a character based on a user's operation and causes the game to progress;
a storage unit storing a lottery target list including information on a plurality of objects corresponding to events executed during the progress of the game;
a communication unit that receives a gacha request signal for making a gacha request based on the user's operation;
a lottery unit that selects the object from the lottery target list when the communication unit receives the gacha request signal;
History information of a character's interference with the object corresponding to an event executed during the progress of the game (hereinafter referred to as an execution event) is stored in the storage unit, and the lottery target list is generated or updated based on the history information. management department and
with
at least one parameter is set in the object;
The management unit stores change information of the parameter in the storage unit, and when the change information reaches a predetermined value, updates the lottery target list and stores it in the storage unit.
game system.

Images