JP6871715B2 - Event control method and event control program - Google Patents

Description

The present invention relates to an event control method and an event control program.

There is known a technique in which a user independently creates an event in a virtual space of development desired by the user and causes another user's terminal device to execute the event (see, for example, Patent Document 1). In Patent Document 1, the terminal device of the user who created the event feeds back the content of the play performed on the terminal device of another user, and brushes up the content of the event. An example of an event is a fictitious conversation of a historical person.

JP-A-2010-172656 Japanese Unexamined Patent Publication No. 2001-31626

However, in Patent Document 1, the created event is executed independently, and is not executed during the game related to the event. In this case, it is not necessary to make the content of the created event consistent with the story and progress of the game, or conversely change the story of the game according to the event result.

On the other hand, when an event created by the user is executed during the game and affects the game, it is necessary to control so that the content of the game and the result of executing the event do not contradict each other. Therefore, a condition for executing the event at the time of event creation (hereinafter, also referred to as "event condition") is set so that the event is executed when the event condition is satisfied during the game.

However, it is complicated and time-consuming for the user to extract and set all the event conditions necessary so as not to be inconsistent with the story of the game. In addition, when the user manually sets the event conditions, the set event conditions may be incorrect or insufficient. As a result, the event may not be executed during the game.

On the other hand, if an event in which all event conditions necessary to be consistent with the story of the game can be used in other terminal devices, the player of the other terminal device can set the event conditions when creating the event. You can save time and effort. In addition, there are no mistakes or shortages in the set event conditions, and the game can be enjoyed more.

Therefore, on one aspect, the present invention aims to share the created event with other terminal devices when creating an event to be executed during the game.

One idea is an event control method in which a computer executes control processing when creating an event to be executed during a game. When an event result setting condition is accepted and the event result setting condition is accepted, an event occurs. With reference to the storage unit in which the result and the event condition are associated with each other, the condition to be complemented in order to execute the event to obtain the event result is extracted, and the event condition including the condition to be complemented is set. An event control method is provided that makes the data of the event available from another terminal device different from the terminal device that created the event.

According to one aspect, when creating an event to be executed during a game, the created event can be shared with other terminal devices.

The figure which shows an example of the hardware composition of the terminal apparatus which concerns on one Embodiment. The figure which shows an example of the functional structure of the terminal apparatus which concerns on one Embodiment. The figure which shows an example of the event result DB which concerns on one Embodiment. The figure which shows an example of the event condition DB which concerns on one Embodiment. The figure which shows an example of the table which concerns on one Embodiment. A flowchart showing an example of a game execution process according to an embodiment. The flowchart which shows an example of the event control processing which concerns on one Embodiment. The figure which shows an example of the event creation screen which concerns on one Embodiment. The figure which shows an example of the event summary creation screen which concerns on one Embodiment. The figure which shows an example of the event result edit screen which concerns on one Embodiment. The figure which shows an example of the event condition edit screen which concerns on one Embodiment. The figure which shows an example of the event content edit screen which concerns on one Embodiment. The figure which shows an example of the event set edit screen which concerns on one Embodiment. The figure which shows the display example of the execution result of the event which concerns on one Embodiment. The figure which shows the display example of the execution result of the event which concerns on one Embodiment. The figure which shows an example of the event sharing system which concerns on one Embodiment. The flowchart which shows an example of the event sharing process which concerns on one Embodiment.

Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. In the present specification and the drawings, components having substantially the same functional configuration are designated by the same reference numerals to omit duplicate explanations.

[History event]
There are events that run during the game. The player (user) of the game can independently create an event of the development desired by himself / herself. At that time, the player may use the characters appearing in the game or other characters to create an event of the development desired by the player, or create an event by imagining an event that is not told in the story. it can. The created event is executed at the timing when the event conditions are satisfied during the game.

There are multiple types of events, including historical events and requested events. For example, in a game executed based on a historical scenario, a player can create two types of events, a historical event and a requested event, and can set a conversation of a historical person desired by the player in each event. The player can make various settings such as the content of the conversation between the warlords, the conditions under which the historical event occurs, the events after the occurrence, the marriage of the warlords, the change of the monarch, the alliance of powers, the awarding of heirloom, etc. You can create your own historical event.

The historical event is an event that occurs once when the event conditions related to the affiliation of the military commander, the state change of the military commander, the city to which the military commander belongs, the affiliation change of the military commander, etc. are satisfied during the progress of the game. Request events are request (use) type events such as bond formation and gold earning events, and unlike historical events, they do not occur in a single event, so that the request can be satisfied in the game. It occurs in a series of flows such as whether the game is being developed. An example of a requested event is an event that a warlord visits when certain conditions are met.

Hereinafter, an embodiment of the terminal device 10 having a function of creating a historical event and sharing the created historical event will be described. The terminal device 10 according to the present embodiment may be a game device (including a portable game device) or a personal computer (PC). However, the terminal device according to this embodiment is not limited to this, and includes smartphones, mobile terminals, PDAs (Personal Digital Assistants), mobile phones, portable game devices, HMDs (Head Mount Display), FMDs (Face Mount Display), and the like. It may be a wearable display device.

[Hardware configuration of terminal device]
First, an example of the hardware configuration of the terminal device 10 according to the present embodiment will be described with reference to FIG. The terminal device 10 according to the present embodiment includes a CPU (Central Processing Unit) 21, a ROM (Read Only Memory) 22, a RAM 23, and an HDD (Hard Disk Drive) 24. Further, the terminal device 10 has a graphic card 25, an external I / F26, a communication I / F27, an input I / F28, a display 29, and a speaker 30. Each part is connected to each other by a bus.

The ROM 22 is a non-volatile semiconductor memory capable of holding internal data even when the power is turned off. The RAM 23 is a volatile semiconductor memory that temporarily holds programs and data. Programs and data are stored in the ROM 22 and the RAM 23.

The HDD 24 is a non-volatile storage device that stores programs and data. The HDD 24 may store programs of basic software and application software that control the entire terminal device 10. Various databases may be stored in the HDD 24. In the present embodiment, the HDD 24 stores various programs such as a basic processing program, a game execution processing program, and an event control processing program, and various data.

For example, the CPU 21 reads various programs and various data from the HDD 24 onto the RAM 23 and executes various processes to realize overall control of the terminal device 10 and functions mounted on the terminal device 10.

The external I / F 26 is an interface for connecting the terminal device 10 to the external device. The external device includes a recording medium 26a and the like. As a result, the terminal device 10 can read and write the recording medium 26a via the external I / F 26. Examples of the recording medium 26a include a CD (Compact Disk), a DVD (Digital Versatile Disk), an SD memory card (SD Memory card), a USB memory (Universal Serial Bus memory), and the like.

For example, the terminal device 10 can be equipped with a recording medium 26a in which a game execution processing program, an event control processing program, and the like are stored. These programs are read by the external I / F 26 and read into the RAM 23.

The CPU 21 executes the game execution program and the event control processing program read into the RAM 23, and instructs the graphic card 25 to output an image according to the progress of the game and the historical event. The graphic card 25 performs image processing of the game and image processing of the historical event to be displayed on the screen according to the instruction, and draws the game image and the event image on the display 29. One frame time of the image output from the graphic card 25 is, for example, 1/30 to 1/60 seconds. The graphic card 25 draws one image on a frame-by-frame basis. That is, the image of the frame is drawn 30 to 60 times per second.

Further, the CPU 21 processes the above-mentioned various programs read into the RAM 23, and outputs a predetermined sound from the speaker 30 according to the progress of the game or the historical event.

The communication I / F 27 is an interface for connecting the terminal device 10 to the network. The communication I / F 27 communicates with a terminal device or a server of another player via a communication unit having an antenna.

The input I / F 28 is an interface for connecting to an input device such as a controller 40. The controller 40 has operation buttons and direction keys. The player operates the game using the controller 40. For example, the player can make the player character perform a predetermined operation by operating the operation buttons. In addition, the player can move the player character in a predetermined direction by operating the direction keys. The input I / F 28 stores the input information based on the input operation performed by the player using the controller 40 in the RAM 23. Further, when the player operates the controller 40 to instruct the start of the game, the input I / F 28 starts the game processing by inputting the instruction information.

When the CPU 21 executes various arithmetic processes such as player character operations based on the input information stored in the RAM 23, the input I / F 28 saves the game data stored in the RAM 23 in the memory card 28a according to the instruction from the CPU 21. Let me. Further, the input I / F 28 performs a process of reading the interrupted game data stored in the memory card 28a, transferring the data to the RAM 23, and holding the data in the RAM 23.

[Functional configuration of handheld game consoles]
Next, an example of the functional configuration of the terminal device 10 according to the present embodiment will be described with reference to FIG. The terminal device 10 includes a reception unit 11, a game execution unit 12, a storage unit 13, an event control unit 14, a graphic processing unit 16, a sound processing unit 17, a display unit 18, a sound output unit 19, and a communication unit 20.

The reception unit 11 receives the game operation of the player. For example, the reception unit 11 receives operations of the operation keys and direction keys of the controller 40. At the time of creating a historical event, the reception unit 11 accepts at least one of the event content, the event condition, and the event result. The function of the reception unit 11 is realized by, for example, an input I / F28 or an external I / F26.

The game execution unit 12 executes the game processing according to the game execution processing program. The game executed in the present embodiment may be a game played independently or a communication game played jointly with another player connected via a network.

The storage unit 13 stores the event result DB 131, the event condition DB 132, and the event registration DB 134. FIG. 3 shows an example of the event result DB 131 according to one embodiment. The event result DB 131 stores an item of "event result" that can be set by the player when the event is created.

For each event result name shown in FIG. 3, the details of the setting contents indicated by the result name are saved. For example, when the event result is "1. Change of monarch", "[designated monarch] retires and [designated monarch] of the same power becomes a monarch" is stored as an example of the details of the setting contents. In [], the player can dynamically set an arbitrary designated monarch for each event condition.

Further, for example, when the event result is "2. Taishou setting", "changing the Taishou of [designated city] to [designated military commander]" is stored as an example of the details of the setting contents. Further, for example, when the event result is "3. Death of a military commander", "[Designated military commander] will die" is stored as an example of details of the setting contents. In [], the player specifies an arbitrary designated military commander, designated city, designated power, etc. for each event condition, and is dynamically changed according to this designation.

FIG. 4 shows an example of the event condition DB 132 according to the embodiment. The event condition DB 132 stores an item of "event condition" that can be set by the player when creating a historical event. For each condition name shown in FIG. 4, the details of the setting contents indicated by the condition are saved.

For example, when the event condition is "1. Occurrence date", "[designated] year [designated] month [before / after / match]" is stored as an example of the details of the setting contents. In [Specify], the number of years and months specified by the player are input. When options are displayed, such as [Previous / Later / Match], the player selects either Previous, Later, or Match.

Further, for example, when the event condition is "2. Status of military commander", "[designated military commander] is [designated status]" is stored as an example of the details of the setting contents. Further, for example, when the event condition is "3. The power to which the military commander belongs", "[designated military commander] belongs to the [designated power]" is stored as an example of the details of the setting contents.

Based on the event result DB 131 and the event condition DB 132, the event conditions necessary for obtaining a predetermined event result can be obtained by a predetermined calculation formula. FIG. 5 shows an example of the table 133 in which the event result and the event condition are linked. Each item of the event result name 133a, the event condition name 133b, and the detailed condition 133c is stored in the table 133. In table 133, each event result name 133a is associated with an event condition name 133b indicating an essential condition for obtaining an event result of the setting content indicated by the result name.

For example, in FIG. 5, when "3. Death of a military commander" is set in the event result, the event condition name corresponding to the event result name 133a "3. Death of a military commander" is used as an event condition for obtaining this event result. 133b Each condition of "14. State of military commander", "2. Status of military commander", and "15. Player military commander" is set. Then, these three event conditions are indispensable conditions to be complemented in order to obtain the event result of the death of the designated military commander.

When the event condition name 133b is "14. State of military commander", "[designated military commander] is not in the field" is a condition as an example of the details of the setting contents. When the event condition name 133b is "2. Status of military commander", "[designated military commander] is not a monarch" is a condition as an example of the details of the setting contents. When the event condition name 133b is "20. Player military commander", "the player military commander is not [designated military commander]" is a condition as an example of the details of the setting contents. It should be noted that the table 133 does not necessarily have to be created, and the event conditions to be complemented corresponding to the settings may be automatically calculated at any time according to the setting of at least one of the event result and the event condition by the player. .. However, in the following, for convenience, it will be described with reference to Table 133.

Returning to FIG. 2, the event registration DB 134 registers the historical event created by the player. The storage unit 13 registers the created historical event in the event set. An event set is a group of historical events that you want to generate, and the created historical event belongs to one of the event sets. A plurality of event sets may be registered in the event registration DB 134. Historical events registered in the event set are executed in the specified order. The event registration DB 134 may register a request event created by the player.

Further, the storage unit 13 installs and stores the game execution processing program 135 and the event control processing program 136. The game execution processing program 135 is a program for causing the CPU 21 to execute the game execution processing. The event control processing program 136 is a program for causing the CPU 21 to execute the event control processing. The function of the storage unit 13 is realized by, for example, a server on the cloud connected to the terminal device 10 via the ROM 22, RAM 23, HDD 24, or network shown in FIG.

The event control unit 14 has an event editing unit 4 that edits historical events, an event registration unit 5 that registers historical events, and an event execution unit 6 that controls execution of historical events during the game.

The event editing unit 4 edits the event conditions, the event contents, and the event results according to the instructions of the player. The event editorial unit 4 may edit at least one of the event condition, the event content, and the event result. The event editorial unit 4 extracts event conditions to be complemented in order to obtain the event result according to the set event result. For example, when the player sets the event result, the event editing unit 4 automatically extracts and automatically sets the event conditions essential for obtaining the set event result by referring to the table 133 of the storage unit 13.

The event editorial unit 4 dynamically sets the conditions specified by the player in the arguments of the automatically extracted event conditions and the conditions (designated military commander, etc.) that can be arbitrarily specified among the event conditions set by the player. For example, the event editorial unit 4 sets a part of the event condition by setting the name of the "military commander" specified by the player in the argument of the condition of the "designated military commander" that can be arbitrarily specified in the event condition set by the player. It can be changed dynamically. The event editing unit 4 displays the automatically extracted event conditions and the event conditions set by the player on the display unit 18. As a result, the player can check not only the event conditions set by the player but also the automatically extracted event conditions.

The event registration unit 5 registers the created historical event in the event registration DB 134. When the event conditions set during the game are satisfied, the event execution unit 6 executes the historical events belonging to the validly set event set among the historical events registered in the event registration DB 134 in order.

The event control unit 14 makes the created historical event data available from another terminal device different from the terminal device that created the historical event.

With such a functional configuration, as a result of the event execution unit 6 executing the historical event according to the content of the historical event, the player can view the historical event of the set content and obtain the set event result. The functions of the game execution unit 12 and the event control unit 14 are realized, for example, by processing the game execution processing program 135 and the event control processing program 136 to execute the CPU 21.

The graphic processing unit 16 is connected to the display unit 18, and when a drawing command is output from the game execution unit 12 and the event execution unit 6, a video signal is output to the display unit 18. As a result, the display unit 18 displays the image of the game and the image of the historical event as the game progresses. The function of the graphic processing unit 16 is realized by, for example, a graphic card 25. The function of the display unit 18 is realized by, for example, the display 29.

The sound processing unit 17 is connected to the sound output unit 19, and when a sound output instruction command is output from the game execution unit 12 and the event execution unit 6, a sound signal is output to the sound output unit 19. As a result, the sound output unit 19 outputs sounds and sounds according to the progress of the game and the execution of the historical event. The function of the sound output unit 19 is realized by, for example, the speaker 30.

The communication unit 20 communicates with a server or a terminal device of another player. The function of the communication unit 20 is realized by, for example, the communication I / F 27. For example, when the event result DB 131, the event condition DB 132, the table 133, and the event registration DB 134 are stored in the storage device on the cloud, the communication unit 20 receives necessary information from the storage device on the cloud.

Note that FIG. 2 draws a block diagram focusing on functions, and the processor that executes the software of each part shown by these functional blocks is hardware.

[Game execution process]
Next, an example of the game execution process according to the present embodiment will be described with reference to FIG. FIG. 6 is a flowchart showing an example of the game execution process according to the embodiment. This process is mainly executed by the game execution unit 12 and the event execution unit 6. Here, the game execution unit 12 executes a predetermined game, and the event execution unit 6 executes a predetermined historical event. Although a historical event will be described below as an example, the event controlled by the event control process according to the present embodiment is not limited to the historical event and may be a request event.

When this process is started, the game execution unit 12 executes the designated game (step S10). Next, the event execution unit 6 determines whether or not to reflect the historical event (step S12). The event execution unit 6 is an event set that is effectively set, and if the event conditions are satisfied during the game, the event execution unit 6 proceeds to step S14. If the event execution unit 6 determines that the set event condition is not satisfied, the event execution unit 6 proceeds to step S18, and if it determines that the set event condition is satisfied, the event execution unit 6 proceeds to step S14. That is, when the historical event is reflected in step S12 of FIG. 6, the game execution unit 12 does not satisfy the event conditions automatically extracted by setting the event results and the manually set event conditions in the game. If you do not run historical events.

In step S14, the event execution unit 6 sequentially executes the historical events included in the validly set event set among the event sets registered in the event registration DB 134. Next, the game execution unit 12 changes the story of the game according to the execution result of the historical event (step S16). For example, when a military commander designated by a player dies in a historical event, the game execution unit 12 changes the game to a story in which the military commander does not appear alive.

In step S18, the game execution unit 12 determines whether or not to end the game. When the game execution unit 12 determines that the game is finished, the game execution unit 12 ends this process. On the other hand, if the game execution unit 12 determines that the game is not finished, the game returns to step S10 and restarts the game. The processes of steps S10 to S18 are repeated until the game execution unit 12 ends the game in step S18.

[Event control processing]
Next, an example of the event control process according to the present embodiment will be described with reference to FIGS. 7 to 12. FIG. 7 is a flowchart showing an example of the event control process according to the embodiment. 8 to 13 are examples of an event creation screen or an event registration screen. This process is mainly executed by the event control unit 14.

When this process is started, the event control unit 14 determines whether or not there is a request to create a historical event (step S20). The screen of FIG. 8A shows a state in which "Create historical event" is selected by the player in the start menu. When "Create historical event" is selected, the display unit 18 transitions to the "Create historical event" screen of FIG. 8B.

On the "Create / Change Historical Event" screen of FIG. 8B, "Create / Change (of Historical Event)" is selected by the player. When "Create / Change" is selected, the display unit 18 transitions to the "Create / Change" screen of FIG. 8C.

On the "Create / Change" screen of FIG. 8C, "Create new" is selected by the player. When "new creation" is selected, in step S20 of FIG. 7, the event control unit 14 determines that there is a new creation request for the historical event, and displays the historical event editing screen (step S22). The screen of FIG. 9A shows an example of the “historic event edit” screen displayed in step S22.

Returning to FIG. 7, the event control unit 14 then determines whether or not to set the outline of the historical event (step S24). As shown in the screen of FIG. 9A, when the player selects the “summary” button, in step S24 of FIG. 7, the event control unit 14 determines that the summary of the historical event is set, and the display unit 18 determines that the summary of the historical event is set. The transition to the "event summary" screen of FIG. 9B. Then, the event control unit 14 sets an outline of the historical event input by the player on the “event outline” screen of FIG. 9B (step S26). On the "event summary" screen of FIG. 9B, basic information of the historical event to be created, such as the name and summary of the historical event, can be input. The event format includes a "historical event" and a "requested event", and in the present embodiment, the historical event is selected.

On the other hand, when the player does not select the "summary" button, in step S24 of FIG. 7, the event control unit 14 determines that the summary of the historical event is not set, and proceeds to step S28. In the present embodiment, the processing of step S24 and step S28 is determined step by step, but the present invention is not limited to this, and according to the pressing of the four buttons of the outline, result, condition, and content of FIG. 9A. , Any of these steps can be performed.

Next, in step S28, the event control unit 14 determines whether to set the result (event result), the condition (event condition), or the content (event content) of the historical event. The “History event edit” screen of FIG. 10A shows a state in which the “Result” button is selected by the player. In this case, the display unit 18 transitions to the “result edit” screen of FIG. 10 (b).

Returning to FIG. 7, next, in step S30, the event control unit 14 causes the player to set the event result desired by the player on the “result edit” screen of FIG. 10 (b). The event result is set by the player selecting from the list of event results stored in the event result DB 131.

FIG. 10 (c) is a screen showing an example of the result of setting the result on the “result edit” screen of FIG. 10 (b). In this example, the set event result is "3. Death of a military commander", and the details of the result are "[Designated military commander] dies". The designated military commander is not limited to a historical person, but can specify a virtual person. The event control unit 14 may define a supplementary explanation of the “result” in advance and display it to the player. This makes it easier for players to create historical events.

Returning to FIG. 7, next, in step S32, the event control unit 14 extracts the event conditions to be complemented in order to obtain the set event result. The event control unit 14 refers to the table 133 and extracts the event conditions corresponding to the set event results.

The event control unit 14 refers to the table 133 of FIG. 5, and corresponds to the event result name 133a "3. Death of the military commander", and the event condition names 133b "14. State of the military commander", "2. Status of the military commander" and Extract the event conditions for "15. Player Warlords". As a result, the following three event conditions are automatically extracted.
(Condition 1) [Designated military commander] is not in the field.

At this time, the display unit 18 can display a detailed description of the condition 1. For example, the display unit 18 automatically sets this event condition because "condition 1 cannot be entered or engaged in a battle" if it is "dead". May be displayed.
(Condition 2) [Designated warlord] is not a monarch.

For example, the display unit 18 states, "Since the" monarch "in condition 2 is the head of the power and cannot be a monarch if he is dead, this event condition is automatically set. May be displayed.
(Condition 3) The player military commander is not a [designated military commander].

For example, the display unit 18 displays, "In condition 3, this event condition is automatically set because it is not allowed as a rule of the game that the player warlord makes his / her death an event result." May be good. The name of the military commander used by the player in the game is displayed on the player military commander.

Returning to FIG. 7, next, in step S34, the display unit 18 displays the event conditions extracted by the event control unit 14 on the screen. FIG. 11B shows an example in which the automatically extracted event conditions are displayed on the screen. As a result, the player can grasp the event conditions of the automatically set historical event.

Returning to FIG. 7, the event control unit 14 then determines whether or not to end the creation of the historical event (step S36). When the event control unit 14 determines that the creation of the historical event is completed according to the instruction of the player, the event control unit 14 proceeds to step S42. On the other hand, when the event control unit 14 determines that the creation of the historical event is not completed, the event control unit 14 returns to step S28.

A case where the player selects the “condition” button shown in FIG. 11A in step S28 will be described. In this case, the display unit 18 transitions to the “condition edit” screen shown in FIG. 11 (b). On the screen of FIG. 11B, the event conditions of the historical event automatically extracted according to the setting of the event result are set. The event conditions set at this point are the minimum required conditions automatically extracted in order to obtain the set event results.

The event control unit 14 causes the player to set event conditions on the “condition edit” screen (step S38). The event condition is set by the player selecting from the list of event conditions stored in the event condition DB 132.

FIG. 11C shows an example of a screen in which event conditions are set. The conditions 1 to 3 on the "condition edit" screen of FIG. 11 (c) are event conditions automatically extracted according to the event result set on the "result edit" screen, and the conditions 4 and 5 are the player. Is the event condition set by.

In the present embodiment, the player sets arbitrary 4 and 5 conditions, but the player does not necessarily have to set the event conditions manually. That is, only the event conditions extracted according to the event results set on the "result edit" screen may be automatically set as the set event conditions. By setting the event result before the event condition, the event condition required to obtain the event result is automatically set, so that the complexity of setting the event condition by the player can be reduced and the historical event is created. You can save time. In addition, it is possible to prevent errors or shortages in the set event conditions.

Returning to FIG. 7, the event control unit 14 then determines whether or not to end the creation of the historical event (step S36). When the event control unit 14 determines that the creation of the historical event is completed, the event control unit 14 proceeds to step S42. On the other hand, when the event control unit 14 determines that the creation of the historical event is not completed, the event control unit 14 returns to step S28.

A case where the player selects the “content” button as shown in FIG. 12A in step S28 will be described. In this case, the display unit 18 transitions to the screen shown in FIG. 12 (b). When the player selects the "add" button, the display unit 18 shifts to the screen shown in FIG. 12 (c), and the event control unit 14 can edit the contents of the historical event. In the contents of the historical event, it is possible to set the conversation of the designated military commander, the background display, the BGM, the narracion, the image to be displayed at the event, and the like.

Returning to FIG. 7, after the processes of steps S28 to S40 are repeated, if it is determined in step S36 that the event control unit 14 ends the creation of the historical event according to the instruction of the player, the process proceeds to step S42. In step S42, the storage unit 13 registers the historical event in the event registration DB 134 and sets the validity or invalidity of the event set. That is, the event control unit 14 groups the historical events to be registered by registering them in one of the event sets, and on the "event set edit" screen shown in FIG. 13, "valid" or "invalid" for each event set. To set. Only the event sets that are enabled will be available in the game.

Returning to FIG. 7, the event control unit 14 then determines whether or not the “reflect during game” button has been pressed (step S44). When the "Reflect in game" button is pressed by the player, the event control unit 14 reflects the historical event belonging to the effectively set event set in the game (step S46), and ends this process. On the other hand, if the player does not press the "Reflect during game" button, this process ends as it is. As a result, the activated historical event is executed at the timing during the game when the event conditions are satisfied.

For example, when the five event conditions shown in FIG. 11C are met during the game, the created specific historical event is started. At this time, the screen of the historical event shown in FIG. 14 suddenly occurs from the normal screen during the game, and the conversation as set in the content of the historical event starts. Further, on the screen during the historical event shown in FIG. 15, as shown in FIG. 15A, a narracion of what kind of historical event has occurred is displayed. Next, in FIG. 15 (b), a screen showing an image and narracion at the end of the historical event is displayed, and finally, as shown in FIG. 15 (c), a screen of the set event result is displayed. When the event screen is closed, the screen switches to the game screen and the game is restarted. So far, we have explained how to create historical events, register historical events, and execute historical events.

It is often difficult for the player to manually extract and set all event conditions that do not conflict with the story of the game when creating a historical event. Further, the setting of the event condition itself is complicated, and if the player manually sets the event condition, the set condition may be erroneous or insufficient.

On the other hand, according to the event control method according to the present embodiment, event conditions according to the event result can be automatically extracted and set. This eliminates the need for the player to manually set all the required event conditions, and can reduce the complexity of creating historical events. Further, when the user manually sets the event condition, it is possible to suppress the occurrence of an error or shortage in the set event condition. This simplifies the process of creating a historical event, and the player can more easily create a historical event.

In addition, by executing the created historical event during the game, the player can appreciate the contents of the historical event he / she desires. In addition, depending on the result of the executed event, it is possible to take over the predetermined values (level, friendship, etc.) obtained during the historical event when returning to the story of the game after the historical event ends.

For example, when it is likely to proceed to an undesired story at a branch point of a story in a game (a point at which a predetermined value determines which of a plurality of branch stories to advance), a desired predetermined value is given. You may create a historical event that allows you to do so. This makes it possible to play the created historical event and then return to the story of the game to proceed to the "desired story" of the multiple branch stories.

In this way, when returning to the story of the game after the end of the history event, the story of the game is changed or ended, the ability value of the character is changed, the heirloom is given, etc., reflecting the contents and results of the history event. You can increase or decrease the items.

In the present embodiment, the automatic extraction of the event condition is executed when the event result is set, but the present invention is not limited to this. For example, when at least one of the event result and the event condition is set, the event condition is automatically extracted. This makes it possible to complement the required event conditions. That is, (1) when the player sets the event result, the event condition corresponding to the set event result can be automatically extracted. Further, (2) when the player sets the event result and the event condition, the event condition corresponding to the set event result and the event condition can be automatically extracted. Further, (3) when the player sets the event condition, the event condition corresponding to the set event condition can be automatically extracted.

Further, when the event control unit 14 sets a plurality of event results, the game execution unit 12 may not reflect the later event results in the game due to the event results reflected in the game first. For example, if the game execution unit 12 kills a military commander by "death of a military commander" and then tries to exile the same military commander by "expulsion of a military commander", the military commander has already died, so "expulsion of the military commander" The event result is not reflected during the game.

In addition, at historical events, conditions can be specified by defining. For example, in addition to the method of setting the military commander name, the designated military commander can automatically call the military commander name whose name has not been determined, such as the military commander with the highest intelligence, in the message. In this case, the military commander to be called changes depending on the progress of the game, which can enhance the unexpectedness in the game.

Also, if a historical event occurs during a request event and, as a result, the mission of the request event cannot be completed, the request event disappears. For example, if a historical event is executed during a request event, and as a result, the target military commander of the request event dies, or if the request event cannot be continuously executed, the request event disappears.

[Sharing historical events and requested events]
Next, sharing of historical events and requested events (hereinafter, also simply referred to as “events”) will be described. The created and registered event data can be shared with other players. As a result, it is possible to have another player play a history event or a request event created by another player on the terminal device of another player, or to play a history event or a request event created by another player on the terminal device of the own player. it can.

When sharing an event, the event control unit 14 selects an event to be shared according to a player's instruction. As shown in FIG. 16, a plurality of terminal devices 10a to 10c are connected to the server 50 via the network 60, and events are shared between the terminal devices 10a to 10c. In the present embodiment, three terminal devices 10a to 10c are shown as an example of the terminal devices that share the event, but the number of terminal devices that share the event is not limited to this.

The server 50 has a communication unit 51, a control unit 52, and a storage unit 53. At least one of the terminal devices 10a to 10c uploads a self-made event determined to be shared to the server 50, and the communication unit 51 receives the uploaded event data.

The control unit 52 stores the received event data in the storage unit 53. The shareable event is stored in the storage unit 53 of the server 50 as the shared list 54. In the shared list 54, items such as an outline of each event belonging to each event set, event conditions, and the number of downloads (DL number) are displayed. The outline of each event and the event conditions are data set by the event creator at the time of event creation. The number of downloads is the number of downloads of the event to a terminal device of another player different from the terminal device of the player who created the event.

Each item of the shared list 54 is displayed on the terminal devices 10a to 10c and can be viewed by each player. Each player confirms the outline and event conditions of each event set at the time of event creation, selects an event to be executed, and the selected event is downloaded from the server 50 to the terminal device of another player.

In addition, when the number of downloads to the terminal device of another player is counted up and a predetermined number of downloads are made, a service of providing a trophy, a coupon, etc. to the terminal device of the player who created the event from the server 50 is provided. You may go.

From the number downloaded to the terminal device of the other player, the other player can know the usage degree by the other terminal device for the shareable event displayed in the sharing list 54. This allows other players to consider the popularity of the event when selecting the event.

When the terminal devices 10a to 10c of each player create an original military commander and register the military commander, the registered military commander made by himself / herself can be uploaded to the server 50 and shared with other players as in the event.

The original registered military commander is an example of an original object created by one player's terminal device, and the original object is not limited to this. Each terminal device may create an original character, an original item, or the like as an original object. By registering the created original object data in the shared folder, it can be made available from other terminal devices in the same way as event registration.

In that case, by setting the shared original registered military commander to the designated military commander appearing in the event executed on the terminal device of the other player, the event listed in the shared list 54 on the terminal device of the other player can be set. When doing either, the warlords appearing in the event can be dynamically changed to the original registered warlords created on either terminal device. In this way, the event created by one player's terminal device and the original object can be combined or shared by another player's terminal device alone.

[Event sharing process]
Finally, the event sharing process will be described with reference to FIG. FIG. 17 is a flowchart showing an example of the event sharing process according to the present embodiment. This process is executed by the server 50.

When this process is started, the communication unit 51 of the server 50 determines whether or not there is a request for uploading an event from any of the terminal devices (step S50). If there is no request for uploading the event, the process proceeds to step S56.

On the other hand, when there is a request for uploading an event, the communication unit 51 accepts the upload of the requested event (step S52). The control unit 52 adds the uploaded event to the shared list 54 and displays the list (step S54).

In step S56, the communication unit 51 determines whether or not there is a request to download the event from any of the terminal devices. If there is no request to download the event, this process ends. On the other hand, when there is a request to download the event, the communication unit 51 downloads the requested event (step S58), and the control unit 52 counts up the number of downloads of the event requested to be downloaded. End the process.

As described above, according to the event control method according to the present embodiment, event creation, event registration, event execution, and event data can be shared with other players. As a result, the event created by the terminal device of one player can be executed by the terminal device of the other player, and the result of the event execution can be reflected in the game executed by the terminal device of the other player. Further, the event created by the terminal device of the other player can be executed by the terminal device of the own player, and the result of the event execution can be reflected in the game executed by the terminal device of the own player.

In addition, each terminal device can set a sharing condition when sharing an event with another terminal device. According to this, the events listed in the sharing list 54 can be downloaded by another terminal device only when the sharing condition is satisfied. As a result, a predetermined limit (filtering) can be set for event sharing.

Although the event control method and the event control program have been described above by the above-described embodiment, the event control method and the event control program according to the present invention are not limited to the above-described embodiment, and various modifications are made within the scope of the present invention. And improvements are possible. Further, when a plurality of the above-described embodiments and modifications exist, they can be combined within a consistent range.

For example, in the event control method according to the above embodiment, a historical event applied to a historical simulation game is given as an example, but the game to which the event control method according to the present invention is applied is not limited to this. For example, it can be applied to a square type simulation RPG game. In this case, even when the player sets a conversation event or other event that occurs when there are A character and B character in the adjacent squares, the event is created by using the event control method according to the present invention. Event registration, event execution, and event data can be shared with other players.

4 Event editorial unit 5 Event registration unit 6 Event execution unit 10 Terminal device 11 Reception unit 12 Game execution unit 13 Storage unit 14 Event control unit 16 Graphic processing unit 17 Sound processing unit 18 Display unit 19 Sound output unit 20 Communication unit 21 CPU
22 ROM
23 RAM
24 HDD
25 Graphic card 26 External I / F
26a Recording medium 27 Communication I / F
28 Input I / F
28a Memory card 29 Display 30 Speaker 40 Controller 50 Server 51 Communication unit 52 Control unit 53 Storage unit 54 Shared list 131 Event result DB
132 Event condition DB
133 Table 134 Event registration DB
135 Game execution processing program 136 Event control processing program

Claims (6)

An event control method in which a computer executes control processing when creating an event to be executed during a game.
Accepts event result setting conditions and accepts
When the setting condition of the event result is received, the storage unit in which the event result and the event condition are associated is referred to, and the condition to be complemented in order to execute the event for obtaining the event result is extracted .
Makes the data of the event for which the event condition including the condition to be complemented is set available from another terminal device different from the terminal device that created the event.
Event control method. A list of the events made available from the other terminal device is displayed so that the event can be viewed from the other terminal device.
The event control method according to claim 1. Display the summary of the event set when creating the event in the list of the events.
The event control method according to claim 1 or 2. The usage rate of the event made available by the other terminal device is displayed in the list of the event.
The event control method according to any one of claims 1 to 3. When the original object is created, the data of the created original object is made available to other terminal devices.
The event is executed on the other terminal device using the data of the original object.
The event control method according to any one of claims 1 to 4. An event control program that allows a computer to execute control processing when creating an event to be executed during a game.
Accepts event result setting conditions and accepts
When the setting condition of the event result is received, the storage unit in which the event result and the event condition are associated is referred to, and the condition to be complemented in order to execute the event for obtaining the event result is extracted .
Makes the data of the event for which the event condition including the condition to be complemented is set available from another terminal device different from the terminal device that created the event.
Event control program.

Images