Computer system and disclosure control system

Abstract

To provide a technology that can appropriately balance a player's personal preference of not wanting replay of a gameplay video or the like to be disclosed and the overall benefit to the player community obtained by disclosing the player's replay.SOLUTION: A server system 1100 allows a player to select their preference regarding the disclosure of replay from among "unrestricted disclosure", "restricted disclosure" and "prohibited disclosure", and sets disclosure restriction setting data 720 in association with the player. When the disclosure restriction setting is "prohibited disclosure," the gameplay video of the replay is, in principle, not disclosed. However, if the gameplay content satisfies disclosure recommendation conditions, then the gameplay video is exceptionally disclosed as it provides extremely great benefit to the overall player community.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] The present invention relates to a computer system or the like that controls the publication of video of game play. [Background technology]

[0002] In recent years, it has become popular to post videos made from gameplay screens, so-called "gameplay videos," to video sharing sites and the like, so that they can be made publicly available to an unspecified number of people via the Internet. There are two types of gameplay videos: one in which the player records the game screen on the game device while playing the game, and then edits the video after playing, and the other in which the game server to which the game device is connected online automatically generates the video (see, for example, Patent Document 1).

[0003] An example of the latter type is a system that collects gameplay reproduction data (data that records gameplay in a manner that allows it to be reproduced; sometimes called replay data or play record data) from a game device, automatically extracts highlight scenes (notable scenes within the gameplay; relatively highly rated scenes suitable for publication) from the gameplay reproduced with that data, generates a gameplay video, and publishes the gameplay video (see, for example, Patent Document 2).

[0004] The published gameplay videos can be a great educational tool for players who enjoy the same game title. The publication of gameplay videos can revitalize the player community, and game titles that have a system for publishing gameplay videos are very attractive to players. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2003-320170 A [Patent Document 2] JP 2006-6853 A Summary of the Invention [Problem to be solved by the invention]

[0006] Among players, there are those who do not want others to see their gameplay videos or do not want them to be made public; they are so-called "non-publicity players." When a player creates and publishes a gameplay video, the player can control whether or not the video is published by their own actions. When the game server generates and publishes the video, the video is published only if the conditions set for each player are met. Players who do not want the video to be published can set the conditions as they wish.

[0007] While such measures are beneficial from the standpoint of the player's personal wishes and in some sense privacy protection, they may not necessarily be beneficial from the standpoint of revitalizing the player community as a whole.

[0008] For example, if a player who refuses to disclose his / her play discovers a new strategy, disclosing it will be useful to many other players. Other players may be inspired by this and come up with yet another new strategy. These will invigorate the entire player community and increase the interest of the game. Similarly, if a player who refuses to disclose his / her play achieves a new record in the time it takes to clear a stage, finds a super rare item that is the subject of rumors, defeats an enemy character that can only be defeated by multiple people, or behaves in a manner that is worthy of praise as a gentleman. In addition, even if the content is not limited to excellent play, but is a typical example of dangerous behavior or behavior that should be avoided, it may be more beneficial for the entire community to disclose it than to respect the player's personal wishes and keep it private.

[0009] The problem that this invention aims to solve is to provide technology that can appropriately balance the personal wishes of a player who does not want to make his or her re-enacted play, such as a gameplay video, public, with the benefits to the entire player community that can be gained by making that player's re-enacted play public. [Means for solving the problem]

[0010] A first invention for solving the above problems is a computer system that controls the publication of a replay of a game play based on play replay data for reproducing a part or all of the game play, the computer system comprising: a first disclosure control means (e.g., the control board 1150 in FIG. 1, the server processing unit 200s in FIG. 8, the first disclosure control unit 220, steps S40, S42, S98, and S100 in FIG. 16) for controlling disclosure of a replay of a game play based on the play replay data of the game play for which a disclosure restriction setting regarding the disclosure of the replay satisfies a given setting condition; a second disclosure control means (e.g., the control board 1150 in FIG. 1, the server processing unit 200s in FIG. 8, the second disclosure control unit 230, steps S50, S62, and S64 to S68 in FIG. 17) for controlling disclosure of a replay of a game play based on the play replay data of the game play, the game play not satisfying the setting conditions for the disclosure restriction setting and satisfying a given disclosure recommendation condition; A computer system comprising:

[0011] The "computer system" referred to here may be composed of a single computer, or may be composed of multiple computers working together.

[0012] According to the first aspect of the present invention, the replay of a gameplay that satisfies the given setting conditions is made public, but the gameplay that does not satisfy the given setting conditions can be made private. On the other hand, even if a gameplay that would normally be private because it does not satisfy the given setting conditions is made private, the replay can be made public as an exception if it satisfies the recommended public conditions. In other words, the recommended public conditions make it possible to appropriately balance the personal wishes of a player who does not want to make public his / her replay of a gameplay video or the like, and the benefits of the entire player community that can be obtained by making public the replay of that player's gameplay.

[0013] A second invention is a computer system of the first invention, in which the public restriction setting is a setting based on a player's operational input, and the second public control means has a display suppression control means (e.g., control board 1150 in FIG. 1, server processing unit 200s in FIG. 8, display suppression control unit 234, step S62 in FIG. 17) for not displaying identification information of a player whose public restriction setting does not satisfy the setting conditions during the re-enacted play.

[0014] According to the second aspect of the present invention, the player himself can set the disclosure restriction setting. Then, even if the replay of the play is made public because the disclosure recommendation condition is satisfied, the computer system can protect the privacy of the player who played the replay so that the player cannot be identified.

[0015] A third invention is a computer system of the first or second invention, wherein the game play is multiplayer game play, the public restriction settings are settings for each player, and the setting conditions are conditions based on the public restriction settings of all participating players.

[0016] According to the third invention, even in a multiplayer game, each player can set a disclosure restriction individually. The computer system can control whether to make the game public or private, or whether to make the game public if the game satisfies the recommended disclosure conditions, based on the disclosure restriction settings of all participating players. For example, if the predetermined condition is that the disclosure restriction settings of all participating players are set to public, then if there is even one participating player who does not wish to make the game public, the system can set the game to "private in principle, but open if the recommended disclosure conditions are met."

[0017] A fourth aspect of the present invention is a game system including: a game play in a multiplayer mode, the public restriction settings are set for each player, and when a participating player with the public restriction settings that does not satisfy the setting conditions is included among the participating players, a public permission operation receiving means (e.g., the control board 1150 in FIG. 1, the server processing unit 200s in FIG. 8, the public permission operation receiving control unit 236 in FIG. 20, step S54 in FIG. 20) for inquiring of the participating player about public permission and receiving a public permission operation; a third disclosure control means (e.g., the control board 1150 in FIG. 1, the server processing unit 200s in FIG. 8, the third disclosure control unit 238 in FIG. 20, step S56 in FIG. 20) for controlling disclosure of a replay of a game play based on the play replay data when the participating players include a participating player with the disclosure restriction setting that does not satisfy the setting condition and the disclosure permission operation receiving means has accepted the disclosure permission operation; The computer system of the first or second invention comprises:

[0018] According to the fourth invention, in a multiplayer game, when a player with a public restriction setting that does not satisfy the set conditions (a player who does not wish to make his / her play public) is participating, the computer system inquires of the player about permission to make the play public, and if the player performs the operation to allow public access, the re-enactment of the play can be made public.

[0019] A fifth invention is a game in which the game play is a multiplayer game play, the public restriction setting is a setting for each player, and the second public control means includes a public permission operation receiving means for, when the game play is a game play that satisfies a given public recommendation condition and the participating players include a participating player with the public restriction setting that does not satisfy the setting condition, inquiring of the participating players about public permission and receiving a public permission operation; A computer system of the first or second invention, comprising: a means for controlling the publication of a re-play based on the play reproduction data of the game play when the publication permission operation receiving means has accepted the re-play (e.g., the control board 1150 of FIG. 1, the server processing unit 200s of FIG. 8, the third publication control unit 238, step S56 of FIG. 20).

[0020] According to the fifth aspect of the present invention, in a multiplayer game, the computer system accepts a public permission operation from a participating player even for a game play that satisfies a public recommendation condition, and publicizes the re-enacted play only if the public permission operation has been performed.

[0021] A sixth invention is a computer system of any of the third to fifth inventions, further comprising a setting content notification control means (e.g., the control board 1150 in Figure 1, the server processing unit 200s in Figure 8, the setting content notification control unit 218 in Figure 18, step S14 in Figure 18) that notifies the participating players of the setting contents based on the public restriction settings of each participating player.

[0022] According to the sixth aspect of the invention, the players participating in a multiplayer game can know each other's disclosure restriction settings. Therefore, even if the replay of the multiplayer game is not made public as expected or is made public, the players can feel more satisfied than if they did not know each other's requests, because they know each other's requests regarding disclosure in advance.

[0023] A seventh invention is a computer system of any of the third to sixth inventions, further comprising a matching means for matching players participating in a game, the matching means preferentially matching players with the disclosure restriction setting who do not satisfy the set conditions (e.g., the control board 1150 in FIG. 1, the server processing unit 200s in FIG. 8, the matching unit 212, step S8 in FIG. 18).

[0024] According to the seventh invention, in multiplayer, the computer system can preferentially match players with public restriction settings who do not meet the set conditions, thereby reducing the possibility of players who meet the set conditions being matched together with players who do not meet the set conditions.

[0025] An eighth invention is a computer system of any of the first to seventh inventions, wherein the second publication control means changes the publication restriction setting for gameplay where the publication restriction setting does not satisfy the setting condition and the gameplay satisfies a given publication recommendation condition to a setting content that satisfies the setting condition (for example, step S67 of Figure 30).

[0026] According to the eighth invention, when the game play of a player who does not wish to make the game public satisfies the recommended public conditions, the contents of the public restriction settings, which were originally selected because the player did not wish to make the game public, can be changed to satisfy the setting conditions (settings that allow the game to be public).

[0027] A ninth invention is a computer system of any of the first to eighth inventions, wherein the public recommendation conditions include at least one of: 1) the gameplay content satisfies a given rarity condition; 2) the results of the game play meet a given excellence condition; and 3) the gameplay content meets a given interest condition.

[0028] According to the ninth invention, the conditions for public recommendation can be any one of: 1) the gameplay content satisfies a given rarity condition; 2) the results of the game play meet a given excellence condition; or 3) the gameplay content meets a given interest condition.

[0029] A tenth invention is a computer system of any of the first to ninth inventions, further comprising a condition change means (e.g., the control board 1150 in FIG. 1, the server processing unit 200s in FIG. 8, the condition change unit 256, and the public recommendation condition change process in FIG. 21) for changing the recommended public conditions based on given desired conditions input by a viewing user.

[0030] A viewing user is a user who views the reproduced play that is made public. According to the tenth aspect of the present invention, the computer system can select a re-play to be made public based on the recommended public conditions that meet the wishes of the viewing user.

[0031] An eleventh invention is a computer system of any of the first to tenth inventions, in which the second disclosure control means shifts a target portion of continuous game play in chronological order, determines whether the disclosure restriction setting for the target portion does not satisfy the setting condition and satisfies the disclosure recommendation condition, and when a positive judgment is made, discloses a re-enactment of at least the target portion (for example, single play processing B in Figures 25 to 26).

[0032] According to the eleventh aspect of the present invention, the computer system can continuously release replays of the game in the order in which the game play progresses.

[0033] A twelfth aspect of the present invention is the computer system according to the eleventh aspect of the present invention, wherein the second publication control means sets the publication of the reenactment play related to the target portion to a time-limited publication or a live streaming publication.

[0034] According to a twelfth aspect of the present invention, the computer system can make the replay publicly available for a limited time or for live streaming.

[0035] A thirteenth invention is a computer system of the eleventh or twelfth invention, further comprising a fourth disclosure control means (e.g., the control board 1150 of FIG. 1, the server processing unit 200s of FIG. 28, the fourth disclosure control unit 239, steps S124 to S132 of FIG. 26) which controls the disclosure of a replay of the consecutive game plays including the target portion based on the play replay data of the game play after the replay of the play relating to the target portion has been disclosed by the second disclosure control means.

[0036] According to the thirteenth aspect of the present invention, the computer system can separately re-publish a plurality of re-plays that have been published in chronological order of game play.

[0037] A fourteenth aspect of the present invention is a publication control system including a player terminal and a server system that is the computer system of any one of the first to thirteenth aspects of the present invention.

[0038] According to the fourteenth aspect of the present invention, it is possible to realize a publication control system that exhibits the same effects as any one of the first to thirteenth aspects of the present invention. [Brief description of the drawings]

[0039] [Figure 1] FIG. 1 is a diagram showing an example of the configuration of a publication control system. [Diagram 2] FIG. 1 is a diagram for explaining a game service. [Diagram 3] Diagram (part 1) to explain the release of gameplay videos. [Figure 4] Diagram (part 2) to explain the publication of gameplay videos. [Diagram 5] FIG. 13 is a diagram showing an example of a setting screen for publication restriction setting data. [Figure 6] FIG. 13 is a diagram showing an example of a game screen in multiplayer mode. [Figure 7] FIG. 13 is a diagram for explaining the publication of gameplay videos in multiplayer mode. [Figure 8] FIG. 2 is a functional block diagram showing an example of the functional configuration of the server system according to the first embodiment. [Figure 9] FIG. 4 is a diagram showing an example of programs and data stored in a server storage unit in the first embodiment. [Figure 10] FIG. 4 is a diagram showing an example of the data structure of highlight scene definition data. [Figure 11] FIG. 13 is a diagram showing an example of the data configuration of recommended disclosure condition definition data. [Figure 12] FIG. 4 is a diagram showing an example of the data structure of play data. [Figure 13] FIG. 13 is a diagram showing an example of the data structure of play reproduction data. [Figure 14] FIG. 4 is a diagram showing an example of the data configuration of precedent record data. [Figure 15] FIG. 4 is a functional block diagram showing an example of the functional configuration of a player terminal in the first implementation process. [Figure 16] 11 is a flowchart for explaining the flow of a single play process. [Figure 17] 11 is a flowchart for explaining the flow of a publication prohibition response process. [Figure 18] 11 is a flowchart for explaining a process flow relating to multiplay. [Figure 19] Flowchart continuing from Figure 18. [Figure 20] 13 is a flowchart for explaining the flow of a publication prohibition process B. [Figure 21] 11 is a flowchart for explaining the flow of a recommended disclosure condition change process. [Figure 22] FIG. 11 is a functional block diagram showing an example of the functional configuration of a player terminal according to a second embodiment. [Figure 23] FIG. 11 is a diagram showing an example of programs and data stored in a terminal storage unit of a player terminal according to the second embodiment. [Figure 24] FIG. 11 is a diagram showing an example of the functional configuration of a server system according to a second embodiment. [Diagram 25] 11 is a flowchart for explaining the flow of single play processing B. [Figure 26] Flowchart continuing from Figure 25. [Figure 27] FIG. 13 is a diagram showing an example of the data structure of a scene cut-out timing list. [Figure 28] FIG. 13 is a diagram showing an example of the functional configuration of a server system according to a third embodiment. [Figure 29] 11 is a flowchart for explaining the flow of a single play process D. [Diagram 30] 13 is a flowchart for explaining the flow of a publication prohibition corresponding process D. [Diagram 31] 11 is a flowchart for explaining the flow of a single play process E. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0040] An example of an embodiment of the present invention will be described below, but it goes without saying that the form to which the present invention can be applied is not limited to the following embodiment.

[0041] [First embodiment] FIG. 1 is a diagram showing an example of the configuration of a system for controlling the publication of videos relating to gameplay. The publication control system 1000 includes a server system 1100 and a player terminal 1500, which are connected via a network 9 so as to be capable of mutual data communication.

[0042] The publication control system 1000 is a computer system that provides (1) a game service that provides online games to users who use player terminals 1500, and (2) a publication service that provides a viewable replay of game play. Of course, the publication control system 1000 may also provide other services in addition.

[0043] The network 9 refers to a communication path that allows data communication. In other words, the network 9 includes a dedicated line (dedicated cable) for direct connection, a LAN (Local Area Network) using Ethernet (registered trademark), etc., as well as a telephone communication network, a cable network, the Internet, and other communication networks, and the communication method may be either wired or wireless.

[0044] The server system 1100 is a computer system having, for example, a main device 1101, a keyboard 1106, a touch panel 1108, and a storage 1140, and a control board 1150 mounted on the main device 1101.

[0045] The control board 1150 is equipped with various microprocessors such as a CPU (Central Processing Unit) 1151, a GPU (Graphics Processing Unit), and a DSP (Digital Signal Processor), various IC memories 1152 such as a VRAM, RAM, and ROM, and a communication device 1153. Note that a part or the whole of the control board 1150 may be realized by an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or an SoC (System on a Chip).

[0046] The server system 1100 realizes a function of providing game services and public services by the control board 1150 performing calculations based on predetermined programs and data, including programs executable by the player terminals 1500 and various data required for the execution of the programs, which are related to the provision of these services.

[0047] Although only one player terminal 1500 is depicted in FIG. 1, in actual system operation, a plurality of player terminals 1500 can access the server system 1100 at the same time.

[0048] Also, although the server system 1100 is depicted as if it were a single server device, it may be realized by a configuration of multiple devices. For example, the server system 1100 may be configured to include multiple blade servers each sharing a function, and connected to each other via an internal bus so that data communication is possible. Furthermore, the installation location of the hardware constituting the server system 1100 does not matter. It may be configured such that multiple independent servers installed at separate locations communicate data via the network 9 to function as the server system 1100 as a whole.

[0049] The server system 1100 is involved in the gameplay video publishing service and performs control to manage the gameplay video publishing site. Of course, the public site may not be managed by the server itself, but may be managed by an external video public management server 1200. The video public management server 1200 is an external server for operating and managing an existing video public site (a website that accepts video submissions from an unspecified number of people via the Internet, etc., and provides the submitted videos to an unspecified number of viewers in a streaming format). In this case, the server system 1100 communicates with the video public management server 1200 and automatically submits gameplay videos to make them public.

[0050] The player terminal 1500 is a computer system used by a user who has completed a registration procedure to utilize the disclosure control system 1000 of this embodiment, and is an electronic device that can access the server system 1100 via the network 9. Specifically, the player terminal 1500 is a device for playing games, and also a device for accessing a video publishing site and viewing published gameplay videos.

[0051] The player terminal 1500 in this embodiment is a device called a smartphone, but may be a computer such as a wearable computer, such as a smart watch or smart glasses, a portable game device, a tablet computer, or a personal computer. When multiple electronic devices are communicatively connected to each other to perform one function, such as a combination of a smartphone and a smart watch communicatively connected to the smartphone, these multiple electronic devices can be regarded as one player terminal 1500.

[0052] The player terminal 1500 includes operation keys 1502, a touch panel 1506 that functions as an image display device and a contact position input device, and a control board 1550. The control board 1550 is equipped with (1) a CPU 1551 and various microprocessors such as a GPU and a DSP, (2) various IC memories 1552 such as a VRAM, a RAM and a ROM, (3) a wireless communication module 1553 for wirelessly communicating with a mobile phone base station or a wireless LAN base station connected to the network 9, and (4) an interface circuit 1557 including a driver circuit for the touch panel 1506 and a circuit for receiving signals from the operation keys 1502.

[0053] These elements mounted on the control board 1550 are electrically connected via a bus circuit or the like, and are connected so as to enable reading and writing of data and sending and receiving of signals. Note that a part or all of the control board 1550 may be configured with an ASIC, FPGA, or SoC. The control board 1550 stores programs and various data for realizing the functions as a player terminal in an IC memory 1552.

[0054] In this embodiment, the player terminal 1500 is configured to download programs and various setting data from the server system 1100, but by incorporating a disk media reader or a memory card reader, it may also be configured to read data from storage media such as disk media or memory cards obtained separately.

[0055] FIG. 2 is a diagram for explaining the game service. The game that the player 2 plays on the player terminal 1500 is an online game executed in a client-server system in which the server system 1100 serves as the game server.

[0056] Information related to the game progress and information related to the display of the game screen W2 are generated by the server system 1100 and provided to the player terminal 1500 as appropriate. The player terminal 1500 functions as a terminal for operation input and game screen display. That is, the player terminal 1500 displays the game screen based on the information provided by the server system 1100, and transmits operation input information to the server system 1100 one by one. The server system 1100 progresses the game based on the operation input information transmitted from the player terminal 1500.

[0057] The server system 1100 controls the game progress and creates and stores play data 700. The play data 700 is created for each game play, and is various data for controlling the game progress, describing the latest game situation at that time, and is constantly updated during play. Of course, the play data 700 also includes the player accounts participating in the game play.

[0058] The server system 1100 creates and stores play replay data 750 based on this play data 700. The play replay data 750 is a data group that stores various data constituting the play data 700 in chronological order. Therefore, the original game play can be reproduced by reading out the data stored in the play replay data 750 in chronological order. In that sense, the play replay data 750 may be called "replay data."

[0059] 3 and 4 are diagrams for explaining the publication of gameplay videos. The server system 1100 creates and stores the publication restriction setting data 720 for each player 2. The publication restriction setting data 720 is information that specifies what kind of restriction the associated player 2 places on the publication of his / her gameplay video. Before playing the game, the player 2 selects and sets the type of restriction to be applied on a predetermined setting screen. The publication restriction setting data 720 includes an applicable user account 721, a setting date and time 723, a restriction type setting 725, and a restriction detail setting 726 (see FIG. 12).

[0060] FIG. 5 is a diagram showing an example of a setting screen W5 for setting the publication restriction setting data 720. As shown in FIG. The setting screen W5 is displayed before the game starts (for example, it is displayed before the game starts together with the selection of the player character, or it is displayed before resuming the game when resuming it from saved data), and the setting results are recorded as the public restriction setting data 720.

[0061] The setting screen W5 has a restriction type setting section 10. In the restriction type setting section 10, a choice of restriction types is presented, and the player 2 selects one of the settings. The types of restrictions can be set as appropriate, but in this embodiment, "unlimited release", "restricted release", and "restricted release" are prepared.

[0062] "Unrestricted release" is selected if you wish to make the data available without any restrictions. "Limited release" is intermediate between unlimited release and no release, and is selected when release is permitted according to specified restrictions. In addition, a restriction detail display section 12 is displayed in association with the limited release option. The restriction detail display section 12 displays detailed restriction content, with check boxes provided for each type. Player 2 sets the desired restriction in detail by checking the check box for the desired restriction content. The set restriction is stored as a restriction detail setting. The details of the restriction can be set as appropriate. For example, "hide account," "replace player voice with alternative voice," "keep text chat private," "display distinctive parts of player character with mosaic," etc.

[0063] "No disclosure" is selected when disclosure is not desired. However, the "no disclosure" in this embodiment indicates a general rule, and if the play content meets the "recommended disclosure conditions" described below, it will be exceptionally made public after a certain disclosure restriction is applied, even if the content is set to "no disclosure."

[0064] In relation to this, the setting screen W5 displays a notice display 14 regarding the setting of prohibiting disclosure, an approval operation section 16 for inputting an operation to approve playing after understanding the notice, and a denial operation section 17 for inputting an operation to focus on the game play because the notice cannot be approved.

[0065] The player 2 sets the content of the restriction that he / she desires on the setting screen W5, and starts playing the game by operating the application start operation icon 18. Alternatively, the player 2 starts playing the game via a pre-game preparation screen.

[0066] In the example of Fig. 3, the disclosure restriction setting data 720 of the player 2a is set to "unlimited disclosure". In other words, the gameplay video of the player 2a is disclosed without any particular restrictions. When the setting of the disclosure restriction setting data 720 is "unlimited disclosure" or "restricted disclosure", the server system 1100 changes the play-play reenactment data 750 of the player 2a associated with the disclosure restriction setting data 720 so as to apply the restriction contents indicated by the setting of the disclosure restriction setting data 720 to the play-play reenactment data 750 of the player 2a.

[0067] The application of the restriction contents can be realized by deleting information related to the restricted object from the play-play replay data 750. Alternatively, the application can be realized by adding data to the play-play replay data 750 to designate the restricted object as hidden when creating the play video. Alternatively, the application can be realized by replacing the restricted object with alternative data.

[0068] The server system 1100 then creates a gameplay video that recreates the play based on the restricted play-recreation data 750, transmits it to the video publication management server 1200 via a prescribed procedure, and controls the publication on the publication site W3 (video sharing site).

[0069] In this embodiment, when the public site W3 is used only by the player 2, the server system 1100 creates only thumbnail images to be displayed on the public site W3 from the play-play replay data 750. Then, a play video may be generated and distributed to the player terminal 1500 of the player 2 who has made a viewing request. Of course, video data may be created in advance from the play-play replay data 750 and distributed and made public.

[0070] 4, the disclosure restriction setting data 720 of the player 2b is set to "publication prohibited." When the disclosure restriction setting data 720 is set to "publication prohibited," the server system 1100 basically keeps the play-play replay data 750 of the player 2b associated with the disclosure restriction setting data 720 private. However, when it is determined that a given disclosure recommendation condition is met, the server system 1100 creates and publishes a play-play video while deleting from the play-play replay data 750 any personally identifiable elements (information or indications that may be a hint for identifying the player) that are elements that can identify an individual.

[0071] The "conditions for recommending disclosure" referred to here are conditions that determine that the benefits to the entire player community gained by disclosing the gameplay video of that player outweigh the benefits of fulfilling the personal wishes of Player 2b (player who refuses disclosure) who does not want his / her gameplay video to be made public.

[0072] The "recommended conditions for publishing" indicate that the content of the gameplay video is at least one of the following: particularly rare, particularly excellent, and particularly interesting. Specifically, this applies to the case where a player has devised a new strategy to beat a stage boss in a certain game stage. If the video is published, it will help many other players to clear the game. Other players may be inspired and continue playing the game to come up with yet another new strategy. In the process, they will have a lot of fun talking with friends about the game. Other examples of this would be setting a new record, such as clearing the game in the shortest time or making consecutive combos, finding a super rare item, or behaving in a manner that is gentlemanly and commendable.

[0073] Of course, the conditions for recommending public release are not limited to rare plays, excellent plays, and interesting plays, and can include any play that is beneficial to the player community. For example, the content of the play video may include actions that should be avoided, such as violations of manners, public order, and morals. In this case, publishing a replay has a punitive meaning. Accidental rare scenes can also be included in the conditions for recommending public release as a type of interesting play.

[0074] The disclosure recommendation conditions can be determined from various data included in the play-replay data 750. The play-replay data 750 includes player information 762, operation input time-series data 782, and progress time-series data 790.

[0075] The operation input time-series data 782 is prepared for each player participating in the game play. One operation input time-series data 782 stores information on the operation input by the player (for example, various information describing the input, such as the type, position, direction, amount of operation, force of operation, and input time) in association with input time information (for example, date and time, elapsed time from the start of game play, number of frames drawn on the game screen, etc.).

[0076] The progress time series data 790 stores information indicating game progress information at each point in time (e.g., the stage number being played, the battle round, the win / loss results for each round, the position coordinates for each player character, the position and posture of the player character, a list of parameter values ​​indicating the state of the player character, etc.) in correspondence with time information.

[0077] An NPC (a character automatically controlled by a computer: a non-player character) is also a type of object. Therefore, when an NPC appears in a game, the progress status time-series data 790 can include object control time-series data 792 that stores control information related to the NPC in chronological order.

[0078] For example, to determine that "the completion of a 'combo' by a succession of specific techniques" is an excellent scene (highlight scene), the following conditions are defined as the conditions for determining whether or not to make the scene publicly recommended: (1) the operation input time series data 782 contains data indicating the operation input of successive specific attack techniques, and (2) the progress status time series data 790 contains data indicating that appropriate damage has been inflicted on the opponent character.

[0079] In order to determine that a "new record for the number of combos" is an excellent scene, the server system 1100 will separately record and manage the recorded values ​​for each type of excellent scene in the game (e.g., the number of combos, the time required to clear a stage, the number of consecutive enemies defeated, the most number of items acquired, etc.). The condition for recommending the scene for publication will be that the number of combos has reached a new record.

[0080] In addition, in order to determine that “defeating a boss character using only magic attacks” is an excellent scene, the following conditions are defined as the conditions for determining whether or not the scene is recommended for disclosure: (1) the operation input time series data 782 indicates that the operation input is a magic attack, and (2) the progress status time series data 790 indicates that the boss character is being defeated.

[0081] In order to determine that a "new strategy for defeating a boss character" is an excellent scene, the server system 1100 classifies and records attack patterns using the type and number of attack operations required to defeat the boss in the game, the movement of the player character, etc. The recommended disclosure condition is that the progress status time-series data 790 indicates that the boss character has been successfully defeated, and the attack pattern indicated by the operation input time-series data 782 has not been previously recorded.

[0082] For example, in a strategy game in which one player 2 controls multiple pieces (player characters) to play against each other, in order to determine a "conquest using a new tactic" as an excellent scene, the server system 1100 records the type, placement, movement, recovery, addition, etc. of the pieces used for each game stage, and classifies and records the tactical patterns based on a given classification criterion. The disclosure recommendation condition is that the progress status time-series data 790 indicates that the stage has been cleared, and that the corresponding tactical pattern has not been recorded.

[0083] Of course, the recommended disclosure conditions can be set to other contents depending on the game contents. The recommended disclosure conditions may be determined not based on whether or not a specific scene content is met as described above, but based on the total evaluation points exceeding a reference value. For example, the evaluation points may be determined by adding points for each excellent scene as described above, adding points based on the playing performance, or adding negative points for each action to be avoided.

[0084] FIG. 6 is a diagram showing an example of a game screen W6 in multiplayer mode. In the case of a multiplayer game in which multiple players participate, players with different settings of the disclosure restriction setting data 720 may play together depending on the result of matching. In the example of FIG. 6, three players form a team, and each player operates a player character 4 (4a, 4b, 4c) to fight against an enemy character 6 (6a, 6b; NPC). The setting of the disclosure restriction setting data 720 of the first player 2c is "unlimited disclosure", the setting of the second player 2d is "limited disclosure", and the setting of the third player 2e is "no disclosure". On the multiplayer game screen W6, the settings of the disclosure restriction setting data 720 of each player can be known to each other by the disclosure restriction notification 20 (20a, 20b, 20c).

[0085] In addition, with regard to a multiplayer gameplay video, if the setting of the publication restriction setting data 720 of even one of the players 2 (involved players) who was primarily involved in creating the content of the gameplay video to be made public is set to "publication prohibited," the server system 1100 will generally make the video private, but will make it public as an exception if the recommended publication conditions are met.

[0086] The definition of "involved player" can be set as appropriate, but basically, if all participating players form a team to play cooperatively in a game, all members of that team are involved players. If it is a team battle, all team members involved in the battle scene are involved players. However, in large-scale multiplayer games (such as MMORPGs), the play of other players may be reflected in the background of the play that is made public, but those other players are not included in the involved players.

[0087] Furthermore, when a specific disclosure request operation is input by the first player 2c who has set it to "unlimited disclosure" or the second player 2d who has set it to "limited disclosure", the scenes immediately preceding the timing of the disclosure request operation (for example, a scene in which a boss character is defeated, or a cooperative play goes well) will exceptionally be made public if the third player 2e who has set it to "publication prohibited" inputs a disclosure permission operation. In other words, the recommended condition for multiplayer disclosure is that "a specific disclosure request operation has been input by the player 2 (first player 2c) who has set it to "unlimited disclosure" or the player 2 (second player 2d) who has set it to "limited disclosure".

[0088] Incidentally, on the multiplayer game screen W6, a request operation detection notification 23 is displayed to notify the user that a request for disclosure has been made, so that the third player 2e, who has set "prohibit disclosure," can also see that the members strongly desire for the video of the game that just finished to be made public.

[0089] FIG. 7 is a diagram for explaining the disclosure of gameplay videos in multiplayer mode. Operation input information and progress control information for each player are stored in the multiplay play data 700. The server system 1100 creates and records play replay data 750 from the play data 700, in the same way as in single play.

[0090] The server system 1100 keeps the play-play replay data 750 private unless certain "disclosure requirements" are met, and if the requirements are met, creates and publishes a play-play video after deleting information that can be used to identify the player from the play-play replay data 750.

[0091] The "publication requirement" in multiplayer is that a public disclosure request operation is detected by a participating player who has the public disclosure restriction setting data 720 set to "unlimited public disclosure" or "limited public disclosure," and a public disclosure permission operation is detected by a participating player who has the public disclosure restriction setting data 720 set to "prohibited public disclosure."

[0092] Of course, the disclosure requirements are not limited to this and can be set appropriately. For example, in this embodiment, if even one of the players 2 who have set "unlimited disclosure" or "limited disclosure" among the participating players requests disclosure, the disclosure is made, but the disclosure requirements may be made stricter so that disclosure is not possible unless all of the players 2 who have set "unlimited disclosure" or "limited disclosure" request disclosure. Conversely, the disclosure requirements may be relaxed by excluding from the configuration of the disclosure requirements the disclosure permission operation by the player 2 who has set "disclosure prohibited." A limit may be placed on the number of times a disclosure request operation can be made.

[0093] In this way, whether in single-player or multiplayer mode, the server system 1100 will generally keep gameplay videos of player 2 who wishes to keep them "private" to the public, but will make exceptions and make them public if the gameplay content is deemed beneficial to the entire player community, thereby revitalizing the player community.

[0094] FIG. 8 is a functional block diagram showing an example of the functional configuration of the server system 1100. The server system 1100 includes an operation input unit 100s, a server processing unit 200s, a sound output unit 390s, an image display unit 392s, a communication unit 394s, and a server storage unit 500s.

[0095] The operation input unit 100s is a means for inputting various operations for managing the server, and corresponds to the keyboard 1106 in FIG.

[0096] The server processing unit 200s is realized by electronic components such as processors serving as arithmetic circuits, such as a CPU, GPU, ASIC, FPGA, etc., as well as IC memories, and controls input and output of data between each functional unit including the operation input unit 100s and the server storage unit 500s. Then, it executes various types of arithmetic processing based on predetermined programs and data, operation input signals from the operation input unit 100s, data received from the player terminals 1500, etc., to comprehensively control the operation of the server system 1100.

[0097] The server processing unit 200s includes a user management unit 202, a game management unit 210, a first publication control unit 220, a second publication control unit 230, a condition change unit 256, a publication site management unit 270, a timing unit 280s, a sound generation unit 290s, an image generation unit 292s, and a communication control unit 294s. Of course, other functional units may also be included as appropriate.

[0098] The user management unit 202 performs processing related to user registration procedures and storage management of various information linked to user accounts. Specifically, the user management unit 202 performs (1) providing unique user accounts to registered users, (2) registration information management for registering and managing personal information for each user account, (3) play history management for managing login and logout history, (4) save data management for managing various save data related to game play including identification information of characters used in the game, (5) management of game-related items owned by the user, etc. Of course, management functions for other data linked to accounts other than these may also be included as appropriate.

[0099] The game management unit 210 executes various controls relating to the online game. The game management unit 210 includes a publication restriction setting unit 211 , a matching unit 212 , a play data storage control unit 214 , a play reproduction data storage control unit 216 , and a setting content notification control unit 218 .

[0100] The public restriction setting unit 211 performs processing related to the creation and recording management of the public restriction setting data 720. Specifically, at a predetermined timing, the setting screen W5 is displayed on the player terminal 1500 of each player 2, and in response to the setting operation input on that screen, the public restriction setting data 720 of that player is generated and stored.

[0101] When a game is executed in multiplay, the matching unit 212 matches players participating in the game. Specifically, the matching unit 212 preferentially matches players whose publication restriction setting data 720 is set to "publication prohibited" (players whose publication restriction setting does not satisfy the setting conditions).

[0102] The play data storage control unit 214 generates and stores play data 700 (see FIG. 3 and FIG. 4).

[0103] The play-replay data storage control unit 216 generates and stores play-replay data 750 that is the basis for replaying a play (see FIGS. 3 and 4).

[0104] When a game is executed in multiplayer, the setting content notification control unit 218 notifies participating players of the setting content based on the disclosure restriction settings of each participating player.

[0105] The first publication control unit 220 controls publication of a replay of a game play based on the play-play replay data 750 for that game play, for which the publication restriction setting for publishing the replay satisfies a given setting condition. Specifically, the first publication control unit 220 determines that the given setting condition is satisfied when the publication restriction setting data 720 has the publication restriction setting set to "unlimited publication" or "limited publication." Then, the first publication control unit 220 generates a play video from the play-play replay data 750, and sets it as a target for publication by the publication site management unit 270. Alternatively, the first publication control unit 220 uploads the play video to an external video publication management server 1200 (see FIG. 1) for publication.

[0106] The second publication control unit 230 performs control to publish a re-enactment of a gameplay based on the play re-enactment data 750 of the gameplay, for the gameplay whose publication restriction setting does not satisfy the set conditions and which satisfies a given publication recommendation condition.

[0107] Specifically, the second disclosure control unit 230 has a disclosure recommendation condition determination unit 232 , a display suppression control unit 234 , a disclosure permission operation reception control unit 236 , and a third disclosure control unit 238 .

[0108] When the public restriction setting in the public restriction setting data 720 of player 2 is set to “unlimited public” or “limited public”, i.e., when the public restriction setting does not satisfy a given setting condition, the public recommendation condition determination unit 232 determines whether the content of the re-enacted play based on the play re-enactment data 750 satisfies the public recommendation condition.

[0109] The display suppression control unit 234 performs control so as not to display the identification information of a player with a disclosure restriction setting that does not satisfy the set conditions during the replay of the play. Specifically, the identification information of the player is deleted from the play replay data 750 or replaced with dummy data. Alternatively, when generating a play video from the play replay data 750, the identification information is hidden or replaced with dummy data.

[0110] The public permission operation reception control unit 236 performs control to inquire of the participating players for public permission and to accept the public permission operation when (1) the game play is a game play that satisfies a given public recommendation condition, and (2) the participating players include a participating player with a public restriction setting that does not satisfy the set condition. Specifically, the control unit 236 performs control to accept a public request operation from the player terminal 1500 of the participating player with a public restriction setting ("unlimited public" or "limited public") that satisfies the set condition (see FIG. 7). The control unit 236 also performs control to accept a selection of whether or not to permit public disclosure in response to the public disclosure request from the player terminal 1500 of the participating player with a public restriction setting ("public disclosure prohibited") that does not satisfy the set condition. The public permission operation reception control unit 236 may perform control to inquire of the participating players for public permission and to accept the public permission operation when the participating players include a participating player with a public restriction setting that does not satisfy the set condition, regardless of whether or not the public recommendation condition is satisfied, or regardless of the presence or absence of a public disclosure request.

[0111] When the disclosure permission operation reception control unit 236 has received the request, the third disclosure control unit 238 performs control for disclosing a re-play based on the play re-play data 750 of the game play.

[0112] The condition changing section 256 changes the recommended disclosure conditions based on the given desired conditions input by the viewing user.

[0113] The public site management unit 270 controls the operation and management of a website that publishes replays or an equivalent electronic bulletin board.

[0114] The timekeeping unit 280s uses a system clock to keep track of the current date and time, time limit, and the like.

[0115] The sound generation unit 290s is realized by executing an IC or software that generates or decodes audio data, and generates or decodes audio data such as operation sounds, sound effects, and BGM related to system management, games, etc. of the server system 1100. Then, audio signals related to system management are output to the sound output unit 390s.

[0116] 1, the sound output unit 390s corresponds to a speaker (not shown) provided in the main device or the touch panel 1108.

[0117] The image generation unit 292s generates images, synthesizes images, and outputs image signals for displaying them on the image display unit 392s. This corresponds to a part of the function of generating images such as screens related to system management of the server system 1100, game screens, and various setting screens (or data for displaying them on the player terminal 1500).

[0118] The image display unit 392s is realized by a device that displays an image, such as a flat panel display, a head mounted display, a projector, etc. In the example of FIG.

[0119] The communication control unit 294s executes data processing related to data communication, and realizes data exchange with an external device via the communication unit 394s.

[0120] The communication unit 394s realizes communication by connecting to the network 9. For example, it is realized by a wireless communication device, a modem, a TA (terminal adapter), a jack for a wired communication cable, a control circuit, etc. In the example of FIG. 1, it corresponds to the communication device 1153.

[0121] The server storage unit 500s stores programs and various data for implementing various functions for the server processing unit 200s to comprehensively control the server system 1100. It is also used as a working area for the server processing unit 200s, and temporarily stores the results of calculations executed by the server processing unit 200s according to various programs. This function is implemented by, for example, IC memory such as RAM or ROM, magnetic disks such as hard disks, optical disks such as CD-ROMs or DVDs, online storage, etc. In the example of FIG. 1, this corresponds to storage media such as IC memory 1152 and hard disks mounted on the main unit, and storage 1140.

[0122] 9 is a diagram showing examples of programs and data stored in the server storage unit 500s. The server storage unit 500s in this embodiment stores a server program 501, a distribution client program 503, game initial setting data 510, highlight scene definition data 520, and recommended disclosure condition definition data 540.

[0123] The server storage unit 500s also stores, as sequentially generated and managed data, user management data 600, play data 700, play replay data 750, previous example record data 800, play replay data by scene 820, play video data 840 of the replay, public site data 842 for operating and managing a website that publishes play videos of the replays, additional publication recommended condition candidate data 844, activation information 846, and current date and time 900. The server storage unit 500s also stores other programs and data (e.g., timers, counters, various flags, etc.) as appropriate.

[0124] The server program 501 is a program that is read and executed by the server processing unit 200s to realize the functions of the user management unit 202, the game management unit 210, the first public control unit 220, the second public control unit 230, the condition change unit 256, and the public site management unit 270. The delivery client program 503 is an original client program provided to the player terminal 1500 . The game initial setting data 510 includes various initial setting data necessary for controlling the execution of the game.

[0125] FIG. 10 is a diagram showing an example of the data structure of the highlight scene definition data 520. As shown in FIG. The highlight scene definition data 520 defines the criteria for selecting scenes worthy of being made public from all game plays accumulated as the play replay data 750, and is created for each scene content.

[0126] One piece of highlight scene definition data 520 includes a unique scene ID 521, search tag setting data 523, and judgment requirement data 530 for judging a relevant scene. Of course, data other than these may also be included as appropriate.

[0127] The search tag setting data 523 is a group of search keywords that are set as metadata of a gameplay video when the gameplay video is made public.

[0128] The judgment requirement data 530 is written as AND or OR of the sub-conditions. The type and contents of the sub-conditions can be set appropriately according to the game content. For example, the sub-conditions may include a progress condition 532, an operation input condition 534, a play result condition 536, and a recording condition 538.

[0129] The progress condition 532 is a sub-condition related to the game progress. For example, it can be described using the game stage ID during play, position information in the game field, the number of surviving members of a team consisting of multiple people, a star chart showing whether each mission has been cleared, the elapsed time range from the start of play, etc. In short, it is a condition on what kind of game progress has occurred.

[0130] The operation input condition 534 is a sub-condition related to the operation input. For example, it can be described using data of an operation input pattern in which the type of operation input is described in chronological order, a time difference or a threshold value of the number of operation inputs, etc. In short, it is a condition on what kind of operation input was performed.

[0131] The play performance condition 536 is a sub-condition on the play performance. For example, it can be described using a stage clear, a rare item acquisition, a boss character defeat, a hidden stage opening, an acquired score, a distance traveled, etc. In short, it is a condition on what kind of play performance it is.

[0132] The record condition 538 can be described using the presence or absence of a record as an excellent record in the game, the difference from the record, and the like.

[0133] By setting the sub-conditions appropriately, it is possible to define the play content as "the first player (no corresponding record) to defeat the boss character in the Nth stage using only magic attacks" as a judgment requirement. Also, it is possible to set the play content as "(Progress condition = unlimited), M times (M is an integer of 5 or more) of operation input, all attacks hit (combo achieved), new record achieved" as a judgment requirement. Note that the content defined by the sub-conditions can be unlimited or not defined in practice.

[0134] FIG. 11 is a diagram showing an example of the data configuration of the recommended disclosure condition definition data 540. As shown in FIG. The recommended public condition definition data 540 is created for each recommended public condition. One recommended public condition definition data 540 includes a unique condition ID 541, search tag setting data 543, a condition description 545, and condition detail data 550 that describes the details of the condition. Of course, data other than these may also be included as appropriate.

[0135] The condition description 545 is text data that explains the contents of the condition, and the contents are presented to the player 2 when the presentation operation icon 15 for recommended public conditions is operated on the public restriction setting screen W5 (see Figure 6).

[0136] The condition detail data 550 is a data group that defines the contents of the disclosure recommendation conditions, and the contents of the disclosure recommendation conditions are described with AND or OR of sub-conditions. The condition detail data 550 describes rare conditions, excellent conditions, and interest conditions that must be met to be judged worthy of disclosure recommendation. The type and contents of the sub-conditions can be set appropriately according to the game contents. For example, a progress condition 552, an operation input condition 554, a play result condition 556, and a recording condition 558 can be used as sub-conditions.

[0137] The progress condition 552 is a sub-condition related to the game progress. For example, it can be described using the game stage ID during play, position information in the game field, the number of surviving members of a team consisting of multiple people, a star chart showing whether each mission has been cleared, the elapsed time range from the start of play, etc. In short, it is a condition on what kind of game progress has occurred.

[0138] The operation input condition 554 is a sub-condition related to the operation input. For example, it can be described using data of an operation input pattern in which the type of operation input is described in chronological order, a time difference or a threshold value for the number of operation inputs, etc. In short, it is a condition on what kind of operation input was performed.

[0139] The play performance condition 556 is a sub-condition about the play performance. For example, it can be described using a stage clear, a rare item acquisition, a boss character defeat, a hidden stage opening, an acquired score, a distance traveled, etc. In short, it is a condition about what kind of play performance it is.

[0140] The record condition 558 can be described using the presence or absence of a record as an excellent record in the game, the difference from the record, and the like.

[0141] The public recommendation condition definition data 540 is set to include at least one of the following by appropriately setting sub-conditions: (1) the play content satisfies a given rarity condition; (2) the results of the game play satisfy a given excellence condition; and (3) the play content satisfies a given interest content condition.

[0142] For example, if the recommended conditions for publication are play content in which a boss character thought to be impossible to beat without magic is defeated, i.e. rare, excellent, and intriguing play content that makes the player think, "I can't believe that's possible," the condition details data 550 can be set to "Progress condition = Nth stage, Operation input condition = no magic attack, Play performance condition = boss character defeated, Record condition = not set." Since "Record condition = not set," the corresponding play will be made public every time it occurs. If "Record condition = unprecedented" is set, the corresponding play will be made public only when it occurs for the first time.

[0143] In addition, if the condition for recommending publication is rare and excellent play content that updates the number of consecutive combos, regardless of progress, then condition detail data 550 can be set as "progress condition = not set, operation input condition = M operation inputs (M is an integer equal to or greater than 5 and is the record value of the number of consecutive combos), play performance condition = all consecutive attack hits (combo achieved), record condition = unprecedented."

[0144] Comparing the recommended public condition definition data 540 and the highlight scene definition data 520, they are very similar, but the play content defined by the recommended public condition definition data 540 is particularly rare, particularly excellent, record-worthy, and particularly interesting among the play contents defined as highlight scenes in the highlight scene definition data 520. In other words, it would be a shame to keep the replays secret, and they are beneficial to the entire player community.

[0145] In this sense, the recommended disclosure condition definition data 540 may be realized as a list of scene IDs 521 of scenes that are defined in the highlight scene definition data 520 and that are considered to satisfy the recommended disclosure conditions.

[0146] Returning to Fig. 9, the user management data 600 is prepared for each user who has completed a predetermined user registration procedure, that is, for each user who can become a player. One piece of user management data 600 includes a unique user account and game save data. Of course, other data may also be included as appropriate.

[0147] FIG. 12 is a diagram showing an example of the data structure of the play data 700. The play data 700 is created for each game play, and various data describing the latest progress status and latest play results in the game play are stored. Specifically, the play data 700 includes a unique play ID 701, a play date and time 702, a player account list 703, a player-specific data set 710, progress status data 740, and disclosure request history data 744. Of course, data other than these may also be included as appropriate.

[0148] The player account list 703 includes matching data 704 .

[0149] The player-specific data set 710 is prepared for each player, and includes player information 712 of the player to which the data set is applied, disclosure restriction setting data 720, player character setting data 730 for each character operated by the player, operation input data 732, play performance data 734 indicating the play performance of the player personally and the team to which the player belongs, and chat data 736. The chat that is the source of the chat data 736 may be a text chat or a voice chat. Of course, data other than these may be included as appropriate. For example, in a game that employs a first-person perspective, data on viewpoint operation may also be included. Depending on the game content, one or more of these may be omitted as appropriate.

[0150] The progress status data 740 describes the latest game progress status. For example, it includes the time elapsed since the start of play, the game stage being played, the number of wins and losses in the case of a match, etc. The progress status data 740 also includes object control data 742 for each object that appears in the game, such as the player character, NPCs, and background objects.

[0151] The public request history data 744 is data created during multiplay, and is created each time a public request operation (see Figs. 7 and 8) is detected. One public request history data 744 stores the requester account and the request timing (e.g., the game stage ID being played, the elapsed time, etc.) in association with each other. In other words, the public request history data 744 indicates when and who made the public request.

[0152] FIG. 13 is a diagram showing an example of the data structure of the play replay data 750. As shown in FIG. The play-replay data 750 is prepared for each game play, that is, for each game play data 700. The play-replay data 750 is basically composed of a data group in which various data included in the game play data 700 is copied from the game play data 700 and accumulated in chronological order.

[0153] Specifically, the play reproduction data 750 includes an origin play ID 751 indicating the original game play, a play date and time 752, a player account list 753 (including matching data 754), a player-specific data set 760, progress time series data 790, and disclosure request history data 794.

[0154] The player-specific data set 760 includes player information 762 , disclosure restriction setting data 770 , player character setting time series data 780 , operation input time series data 782 , play result time series data 784 , and chat time series data 786 .

[0155] The publication restriction setting data 770 includes an applicable user account 711 , a setting date and time 773 , a restriction type setting 775 , and a restriction detail setting 776 .

[0156] FIG. 14 is a diagram showing an example of the data structure of the precedent record data 800. As shown in FIG. The precedent record data 800 is a record of events that have occurred in the game, and is created for each relevant event. The precedent record data 800 is referenced when it is necessary to compare with past cases of the game, such as when the disclosure recommendation condition includes "achieving a new record."

[0157] The precedent record data 800 stores, for example, a unique precedent ID 801, situation detail data 802 indicating the situation in which the case occurred, a record subject 810 indicating what the record is about, and record content 812.

[0158] The detailed situation data 802 corresponds to the description method of the detailed condition data 550 of the recommended disclosure condition definition data 540 (see FIG. 11). That is, the detailed situation data 802 includes, as sub-conditions to be described, a progress status condition 803, an operation input condition 804, and a play result condition 805. Of course, other sub-conditions can be included as appropriate, and any of the sub-conditions describing the detailed situation data 802 can be set to essentially correspond to "no condition."

[0159] The record target 810 indicates which data included in the play replay data 750 (see FIG. 13) is being recorded. For example, it can be the time required, the number of combos, the combo pattern (continuous operation input data from the start of an attack technique to its end), etc.

[0160] The recorded contents 812 are records of when the record object 810 occurred. If the record object 810 indicates a "combo pattern", the types of multiple consecutive operation inputs when the combo was achieved are stored from the operation input time series data 782.

[0161] For example, in the case of recording "the time required for the Xth stage to be cleared by defeating the boss" in the precedent record data 800, the situation detail data 802 describes the progress status condition 803 as "Xth stage", the operation input condition 804 as "no condition", and the play result condition 805 as "defeat the boss character (= stage cleared)". The record object 810 is "the time required (the time elapsed from the appearance of the boss character until the boss character becomes unable to act)".

[0162] 9, the scene-specific play-reproduction data 820 is a data group for reproducing a highlight scene indicated by the highlight scene definition data 520 and a scene that matches the recommended public condition definition data 540. The scene-specific play-reproduction data 820 stores, for example, a scene ID indicating the matching highlight scene definition data 520, scene range information indicating which range of play time the scene corresponds to (for example, a time code range), and partial data of the play-reproduction data 750.

[0163] In addition, when referring to the play-play replay data 750, highlight scenes indicated by the highlight scene definition data 520 and scenes that conform to the recommended disclosure condition definition data 540 are determined, and play-play video data 840 is generated from the corresponding data each time, the scene-specific play-play replay data 820 can be omitted.

[0164] However, in a configuration in which the method of making the re-enacted play public is not to provide play-play video data 840 and play it back, but to provide the original data of the re-enacted play itself to the player terminal 1500 and have the play indicated by the data be reproduced and displayed on the player terminal 1500, the distribution of the scene-specific play re-enactment data 820 itself makes the re-enacted play public.

[0165] The additional recommended public condition candidate data 844 is data prepared for each additional recommended public condition that can be added at the request of a viewing user (a user of the public site). The additional recommended public condition announcement 844 stores a unique additional condition ID, a description of the condition (e.g., a text sentence), and the additional recommended public condition definition data (same content as the recommended public condition definition data 540) in association with each other.

[0166] The validation information 846 is created for each candidate data requested to be added when the additional disclosure recommended condition candidate data 844 is presented to the viewing user. The validation information 846 includes an additional condition ID and a requested date and time list. The requested date and time list is a list of dates and times requested to be added by the viewing user.

[0167] 15 is a functional block diagram showing an example of the functional configuration of a player terminal 1500. The player terminal 1500 includes an operation input unit 100, a terminal processing unit 200, a sound output unit 390, an image display unit 392, a communication unit 394, and a terminal storage unit 500.

[0168] The operation input unit 100 outputs an operation input signal corresponding to various operation inputs made by a user to the device processing unit 200. For example, it can be realized by a push switch, a joystick, a touch pad, a track ball, an acceleration sensor, a gyro, a CCD module, etc. The operation keys 1502 and the touch panel 1506 in FIG. 1 correspond to this.

[0169] The terminal processing unit 200 is realized by electronic components such as a microprocessor such as a CPU or GPU, and an IC memory, and controls input and output of data between each functional unit including the operation input unit 100 and the terminal storage unit 500. It executes various arithmetic processes based on predetermined programs and data, operation input signals from the operation input unit 100, and various data received from the server system 1100, to control the operation of the player terminal 1500. This corresponds to the control board 1550 in FIG. 1.

[0170] The device processing unit 200 in this embodiment has a player device calculation unit 260 , a video viewing control unit 264 , a timing unit 280 , a sound generation unit 290 , an image generation unit 292 , and a communication control unit 294 .

[0171] The player terminal calculation unit 260 performs control to realize the function of the player terminal 1500 as a client device that communicates with the server system 1100. Specifically, the player terminal calculation unit 260 includes an operation signal transmission control unit 261 and an image display control unit 262.

[0172] The operation signal transmission control unit 261 executes processing for transmitting various data and requests to the server system 1100 in response to operations performed on the operation input unit 100 .

[0173] The image display control unit 262 performs control for displaying a game screen, various operation screens, and the like, based on various data received from the server system 1100 .

[0174] The video viewing control unit 264 performs control for accessing a public site and viewing / viewing a video, that is, control for realizing a function as a so-called web browser.

[0175] The timekeeping unit 280 uses a system clock to keep track of the current date and time, time limit, and the like.

[0176] The sound generation unit 290 is realized, for example, by a digital signal processor (DSP), a processor such as a voice synthesis IC, or an audio codec capable of playing audio files, and generates sound signals for music, sound effects, and various operation sounds, and outputs them to the sound output unit 390.

[0177] The sound output unit 390 is realized by a device that outputs (emits) sound based on the sound signal input from the sound generation unit 290. A speaker corresponds to this.

[0178] The image generation unit 292 generates images, synthesizes images, and outputs image signals for displaying them on the image display unit 392. In the example of Fig. 1, this corresponds to a GPU (Graphics Processing Unit) and a graphics controller mounted on the control board 1550.

[0179] The image display unit 392 is realized by a device that displays images, such as a flat panel display, a head mounted display, a projector, etc. In the example of FIG.

[0180] The communication control unit 294 executes data processing related to data communication, and realizes data exchange with external devices via the communication unit 394.

[0181] The communication unit 394 realizes communication by connecting to the network 9. For example, it is realized by a wireless communication device, a modem, a TA (terminal adapter), a jack for a wired communication cable, a control circuit, etc. In the example of FIG. 1, the wireless communication module 1553 corresponds to this.

[0182] In this embodiment, the images of the game screen and various other screens are generated by the server system 1100, but it is also possible to generate them by the player terminal 1500. In this case, the image display control unit 262 controls, for example, objects arranged in a virtual three-dimensional space for generating 3DCG, and the image generation unit 292 renders the 3DCG and executes various controls for generating the game screen.

[0183] The terminal storage unit 500 stores programs for causing the terminal processing unit 200 to realize given functions, various data, and the like. It is also used as a working area for the terminal processing unit 200, and temporarily stores the results of calculations executed by the terminal processing unit 200 according to various programs, input data input from the operation input unit 100, and the like. These functions are realized by, for example, IC memories such as RAM and ROM, magnetic disks such as hard disks, and optical disks such as CD-ROMs and DVDs. In the example of FIG. 1, this corresponds to the IC memory 1552 mounted on the control board 1550. A configuration using online storage is also possible.

[0184] Specifically, the terminal storage unit 500 records a client program 502 for causing the terminal processing unit 200 to function as the player terminal calculation unit 260, a web browser program 504 for causing the terminal processing unit 200 to function as the video viewing control unit 264, operation input data 690, and a current date and time 900. Of course, data other than these can also be stored as appropriate.

[0185] The web browser program 504 may be included in the client program 502. In this case, the video viewing control unit 264 is realized by executing the client program 502, and functions as a part of the player terminal calculation unit 260.

[0186] Next, the operation of disclosure control system 1000 will be described. 16 is a flow chart for explaining the flow of single-play processing. It is assumed that the player has completed user registration and login procedures.

[0187] Before the start of game play, the server system 1100 executes a setting process for the publication restriction setting data 720 (step S2). The server system 1100 displays a setting screen W5 (see FIG. 5) on the player terminal 1500, and sets this according to setting operation input by the player 2.

[0188] Next, the server system 1100 performs various initializations and starts game progress control (step S10). If there is game save data, it may be read and the game may be resumed from a save point. When game progress control is started, the server system 1100 starts storing data necessary for progress control in the play data 700 and rewriting it as play replay data 750.

[0189] When the game ends (step S20), the server system 1100 compares the play replay data 750 with the highlight scene definition data 520 to extract highlight scenes worthy of disclosure from the entire game play (step S22). Accordingly, the scene-specific play replay data 820 is created.

[0190] Next, the server system 1100 executes a loop A for each highlight scene (steps S30 to S102). In loop A, the server system 1100 judges whether the publication restriction setting data 720 of the player 2 satisfies a predetermined setting condition (step S32). If it is set to "unlimited publication" or "limited publication", the judgment is affirmative, and if it is set to "publication prohibited", the judgment is negative.

[0191] Then, if it is set to "unlimited release" (YES "unlimited release" in step S40), the server system 1100 generates gameplay video data 840 based on the scene-specific play reproduction data 820 (the data as created in step S22) (step S98), performs the release process (step S100), and ends loop A (step S102).

[0192] In the publishing process, the generated play video data 840 is registered as a publication target in the publishing site data 842. At that time, a search tag is set according to the search tag setting data 523 (see FIG. 10) of the highlight scene definition data 520 corresponding to the scene ID included in the scene-specific play reproduction data 820.

[0193] When using an external video publishing service, the server system 1100 realizes the publishing process by accessing the video publishing management server 1200 (see FIG. 1) and executing an automatic posting procedure using an API (Application Programming Interface) published for that server.

[0194] If it is set to "Released with Restrictions" (YES "Released with Restrictions" in step S40), the server system 1100 changes the scene-specific play-reproduction data 820 so as to apply the selected restricted detailed settings (step S42). Then, the gameplay video data 840 is generated (step S98), a publishing process is performed (step S100), and loop A ends (step S102). Note that the restricted detailed settings may be applied when the gameplay video data 840 is generated, without changing the scene-specific play-reproduction data 820.

[0195] If it is set to "publication prohibited" (NO "publication prohibited" in step S40), the server system 1100 executes a process to deal with the public disclosure prohibition (step S44).

[0196] FIG. 17 is a flowchart for explaining the flow of the publication prohibition handling process. In the disclosure prohibition response processing, the server system 1100 first compares the scene-specific play reproduction data 820 with the recommended disclosure condition definition data 540 and the candidate data having activation information 846 among the recommended additional disclosure condition candidate data 844 (however, this is limited to those whose dates and times in the requested date and time list are after the set date and time 773 (see FIG. 13) in the disclosure restriction setting data 770 of player 2) to determine whether they are satisfied (step S50).

[0197] If the conditions for recommending disclosure are met (YES in step S50), the server system 1100 modifies the scene-specific play-replay data 820 so as to delete any information or indications (collectively referred to as "personal identification elements") that may be a clue to identifying the individual player from the scene-specific play-replay data 820 (step S62).

[0198] "Individual identifiable elements" are, for example, unique shape parts (e.g., horns added arbitrarily) customized and given when setting up a player account and a player character, and unique texture patterns (e.g., adding an emblem created by an individual). This can also include limited skins and rare equipment applied to a player character, which may be able to identify an individual depending on the combination of them.

[0199] Then, the server system 1100 generates the gameplay video data 840 (step S64), processes it for publication (step S66), provides a specified publication benefit (for example, granting an item, granting a lottery ticket for an item, etc.) (step S68), and ends the publication prohibition processing.

[0200] If the disclosure recommendation conditions are not met (NO in step S50), the server system 1100 discards the scene-by-scene play replay data 820 of the scene being processed in loop A, making it private (step S69), and ends the disclosure prohibition processing.

[0201] When the disclosure prohibition process is completed, the process returns to FIG. 16 and loop A ends (step S102).

[0202] 18 and 19 are flowcharts for explaining the flow of processing relating to multiplay. The server system 1100 accepts participation (step S4), displays the setting screen W5 on each player terminal 1500 for each participating player, and creates each publication restriction setting data 720 (see FIG. 12) in accordance with the setting operation input (step S6).

[0203] Next, the server system 1100 performs a matching process (step S8). At this time, participating players who have set the public restriction setting to "publication prohibited" are matched with each other preferentially. For example, they may be placed on the same team or participate in the same play. Of course, since it is not always possible to match players with "publication prohibited" settings with each other, it is advisable to set a timeout appropriately and match players with "publication prohibited" settings with players with "unlimited public" settings and / or "limited public" settings. It is when these settings are mixed that the effect of this embodiment is most effectively exhibited.

[0204] After completing the matching, the server system 1100 starts controlling the progress of the game (step S10). Then, it is determined whether or not there is a player among the participating players (in a team battle, or in the same team or party in a RPG in which parties are organized) whose disclosure restriction setting data 720 is set to "disclosure prohibited" (step S12).

[0205] If there is a player with "publication prohibited" (YES in step S12), the server system 1100 determines that the predetermined setting conditions are not met, starts control to display a setting notification of the public restriction setting data in the game screen as a public restriction notification 20 (see FIG. 6) (step S12), and further starts accepting a public request operation (step S14). The acceptance targets may be limited to participating players whose public restriction setting data 720 is set to "unlimited public" and "limited public", or may be all players.

[0206] When the game ends (step S20), the server system 1100 selects highlight scenes (step S22) and executes loop B for each of the highlight scenes (steps S30 to S104).

[0207] In loop B, the server system 1100 first extracts the players who are operating the player characters shown on the game screen of the reproduced play of the scene (step S32), and executes loop C for each of the extracted players (steps S34 to S78).

[0208] In loop C, the server system 1100 determines whether the publication restriction setting of the player being processed satisfies specified setting conditions, and if it is set to "unlimited publication" or "limited publication", it makes a positive judgment (YES in step S40) and ends loop C (step S78).

[0209] When loop C is completed for all the extracted players 2, the server system 1100 executes the generation (step S98) and publication process (step S100) of the play video data 840, and ends loop B (step S104).

[0210] If there is no player 2 with "publication prohibited" among the participating players, or if there is no player 2 with "publication prohibited" among the extracted players 2, the gameplay video of the scene to be processed in loop B will be made public. It can also be said that the scene will be made public if the setting condition that the public restriction setting of all participating players is "unlimited public" or "limited public" is met.

[0211] However, if there is a player 2 with "publication prohibited" among the extracted players 2 (NO in step S40), the setting of "publication prohibited" is deemed to not satisfy the specified condition, and the server system 1100 executes public-publication prohibition response process B (step S46).

[0212] FIG. 20 is a flowchart for explaining the flow of the publication prohibition handling process B. The disclosure prohibition response process B basically has the same flow as the disclosure prohibition response process (see Figure 17), but differs in that even if the content of the scene being processed by loop B does not satisfy the disclosure recommendation conditions, it may be made public at the request of other players playing together.

[0213] That is, if the disclosure recommendation condition is not satisfied (NO in step S50), the server system 1100 judges whether or not there is a disclosure request operation for the scene (step S52). Specifically, the disclosure request history data 794 (see FIG. 13) including the request timing is searched for within a predetermined time from the end of the range of the scene range information (see FIG. 9) included in the scene-specific play reproduction data 820, and if there is the corresponding data, it is judged that there is a disclosure request operation.

[0214] If a disclosure request operation has been performed (YES in step S52), the server system 1100 requests permission to disclose the scene on the player terminal 1500 of the player 2 that has "prohibited disclosure" (step S54). For example, several images of the scene are displayed together with operation input icons for permitting / denying disclosure permission, prompting the user to select one of them.

[0215] If there is an operation input permitting disclosure by the player 2 with "disclosure prohibited", it is deemed that the disclosure permission operation has been accepted (YES in step S56). Then, the server system 1100 deletes the individual identifying element (step S62), generates a play video (step S64), performs a disclosure process (step S66), and grants a bonus (step S68), and ends the disclosure prohibition response process B.

[0216] If there is an input operation not allowing disclosure by player 2 of "Publication Prohibited", it is deemed that the disclosure permission operation has not been accepted (NO in step S56), and the server system 1100 discards the scene-specific play reproduction data 820 for the scene (step S69), and ends the disclosure prohibition response process B.

[0217] Also, if there has been no disclosure request operation in the first place (NO in step S52), the server system 1100 discards the scene-by-scene play reproduction data 820 of the scene (step S69), and ends the disclosure prohibition processing B.

[0218] When the server system 1100 ends the publication prohibition handling process B, even if the loop C has not been executed for all the extracted players 2, the server system 1100 ends the loop B (step S104). In other words, depending on the processing in the publication prohibition handling process B, the gameplay video of the scene subject to the loop B processing may or may not be made public.

[0219] It should be noted that the disclosure prohibition process B may be configured to omit step S50. It is also possible to leave step S50 as it is and omit step S52. In this case, even if the participating player does not make a disclosure request, the server system 1100 will automatically request disclosure permission from the prohibited player 2 when a play that meets the disclosure recommendation conditions is made.

[0220] FIG. 21 is a flowchart for explaining the flow of the recommended disclosure condition change process. When a predetermined operation of a disclosure recommended condition change request is inputted at the player terminal 1500 accessing the disclosure site (YES in step S110), the server system 1100 presents additional disclosure recommended condition candidates at the player terminal 1500 and accepts their selection operation (step S112). For example, at the player terminal 1500, an explanation of the conditions of the additional disclosure recommended condition candidate data 844 is presented and a selection operation icon corresponding to each of them is displayed. The viewing user operates the selection operation icon corresponding to the content he / she desires to request addition.

[0221] The server system 1100 acquires operation input information for the desired operation icon from the player terminal 1500, creates or updates activation information 846 for the additional disclosure recommended condition candidate data 844 of the selected description, and activates it (step S114), thereby completing the disclosure recommended condition change process.

[0222] As described above, according to this embodiment, player 2 can set various restrictions on the publication of his / her own replays, such as unlimited, limited restrictions, no publication, etc. In principle, the replays of player 2 who has selected "no publication" as his / her own publication restriction setting will be kept private, but in exceptional cases, when the recommended publication conditions prepared by the management are met, the replays will be published while minimizing the possibility of identifying the individual.

[0223] The conditions for recommending a game to be made public are limited to the fact that the gameplay is rare, excellent, or intriguing.

[0224] This makes it possible to appropriately balance the benefits to the entire player community that can be gained by making a replay of that player public, while respecting the personal wishes of the player who does not want to make his or her replay public.

[0225] Second Embodiment Next, a second embodiment will be described. In the first embodiment, the server system 1100 realizes all of the following: user management, game progress management, publication control, and public site management, but in the second embodiment, the player terminal 1500 is responsible for user management, game management, and publication control, and the server system 1100 is responsible for managing information related to the entire game and public site management. In the following, differences from the first embodiment will be mainly described, and components similar to those in the first embodiment will be given the same reference numerals as in the first embodiment, and duplicated explanations will be omitted.

[0226] 22 is a functional block diagram showing an example of the functional configuration of the player terminal 1500B. The player terminal 1500B has a user management unit 202, a game management unit 210 (excluding the matching unit 212), a first public control unit 220, and a second public control unit 230, instead of the player terminal calculation unit 260 of the first embodiment.

[0227] FIG. 23 is a diagram showing examples of programs and data stored in the terminal storage unit 500 of the player terminal 1500B. The terminal storage unit 500 of the player terminal 1500B stores a game program 506, game initial setting data 510, highlight scene definition data 520, recommended public condition definition data 540, user management data 600, play data 700, play replay data 750, previous record data 800, play replay data by scene 820, play video data 840, and a current date and time 900. Of course, data other than these can also be stored as appropriate.

[0228] The game program 506 is stored in place of the client program 502. By executing this program, the device processing unit 200 can implement a user management unit 202, a game management unit 210, a first public control unit 220, and a second public control unit 230.

[0229] The game initial setting data 510, the highlight scene definition data 520, the recommended disclosure condition definition data 540, and the precedent record data 800 are original data managed by the server system 1100B, and are updated each time before the start of a game.

[0230] FIG. 24 is a diagram showing an example of the functional configuration of the server system 1100B. The server system 1100B includes a matching unit 212, a play reproduction data acquisition control unit 250, a precedent data management unit 252, a data providing unit 254, a condition changing unit 256, and a public site management unit 270.

[0231] The play-reproduced data acquisition control unit 250 performs control to acquire play-reproduced data 750 from the player terminal 1500 .

[0232] The previous example data management unit 252 updates the previous example record data 800 based on the acquired play replay data 750.

[0233] The data providing unit 254 controls the provision of various data to the player terminal 1500, such as the highlight scene definition data 520, the recommended public condition definition data 540, the previous record data 800, the additional recommended public condition candidate data 844, and the validation information 846.

[0234] The server memory unit 500s of the server system 1100B stores a game program 501B, a game program for distribution 505, original game initial setting data 510, original highlight scene definition data 520, original public recommended condition definition data 540, acquired play reproduction data 750, original precedent record data 800, public site data 842, original additional public recommended condition candidate data 844, original activation information 846, and the current date and time 900.

[0235] The single play process (see Figs. 16-17) and the multiplay process (see Figs. 18-20) are executed by the player terminal 1500B. The execution subject of the single play process in the first embodiment should be read as the player terminal 1500B.

[0236] However, before starting the game progress control, the server system 1100B is accessed as necessary to acquire the latest game initial setting data 510, highlight scene definition data 520, recommended disclosure condition definition data 540, and precedent record data 800, and a step of updating these data stored in the terminal storage unit 500 is executed. Also, a step of transmitting play replay data 750 to the server system 1100B when the game ends is executed.

[0237] The recommended disclosure condition change process (see FIG. 21) is executed by the server system 1100B, as in the first embodiment.

[0238] This embodiment can also achieve the same effects as the first embodiment.

[0239] The functional units related to user management, game management, and publication control may be divided in an intermediate manner between the first and second embodiments. For example, the player terminal 1500 may be responsible for user management and game management, and the server system 1100 may be responsible for publication control and publication site management. In this case, the player terminal 1500 transmits the update contents to the server system 1100 every time it updates the play data 700, and the server system 1100B receives the update and stores the play reproduction data 750.

[0240] Third Embodiment Next, a third embodiment will be described. This embodiment is basically based on the first embodiment, but differs in that it is possible to publish gameplay videos in parallel while playing the game. Here, the same components as in the first embodiment are given the same reference numerals, and the differences from the first embodiment will be mainly described.

[0241] When executing single play, the server system 1100 of this embodiment can execute single play processing B shown in FIG. 25 to FIG. The single-play process B basically has the same steps and flow as the single-play process (see FIG. 16), but there are some differences. Specifically, before starting game progress control, the server system 1100 creates an initialized scene cut-out timing list 850 in the server storage unit 500s (step S3).

[0242] FIG. 27 is a diagram showing an example of the data configuration of a scene cut-out timing list 850. The scene cut-out timing list 850 indicates the timing at which a game play is divided into scenes when the game play is divided into scenes in order from the beginning. Specifically, the list includes a cut-out source play ID 851 and a cut-out timing 853 associated with a scene ID 852. The cut-out timing 853 stores a range of elapsed time from the start of play, or a range of frame numbers. For example, when the game play is divided into scenes every predetermined time (for example, every 2 minutes) from the start of the game, the cut-out timing 853 stores the elapsed time every 2 minutes in chronological order. The cut-out timing 853 of the initialized scene cut-out timing list 850 is in an undetermined state (no data).

[0243] Returning to FIG. 25, when the server system 1100 starts controlling the game progress (step S10), it starts cutting out scenes at a predetermined cycle after a predetermined time has elapsed since the start of play (step S11). Accordingly, the scene-by-scene play reproduction data 820 is generated. Then, the server system 1100 executes loop A for each cut-out scene (steps S30 to S120) until the game ends (NO in step S105). In this case, the disclosure process (step S100) may be in the form of a live distribution.

[0244] When the game ends (YES in step S120), the process moves to Fig. 26, and the server system 1100 stops publishing the gameplay video published for this gameplay at a predetermined publishing time limit (for example, immediately after, several minutes later, or at most several hours), making it a practically time-limited publication (step S122). If the publishing process (step S100) is realized in a live distribution format, this step can be omitted.

[0245] Next, the server system 1100 integrates the scene-by-scene play reproduction data 820 obtained in the current game play (step S124), and then determines whether the disclosure restriction setting of the player 2 satisfies a predetermined setting condition (step S126).

[0246] If the publication restriction setting is "unlimited publication" or "limited publication", a positive judgment is made (step S126), and the server system 1100 creates a single piece of gameplay video data 840 based on the integrated scene-specific play reproduction data 820 (step S130), and performs the publication process in the same manner as in step S100 (step S132).

[0247] On the other hand, if the publication restriction setting is "publication prohibited", a negative determination is made (NO in step S126), and the server system 1100 determines whether the play content of the integrated scene-specific play reproduction data 820 satisfies a predetermined republication recommendation condition (step S128).

[0248] The definition data of the re-release recommendation conditions is prepared separately by the operator of the release control system 1000. The contents of the definition data of the re-release recommendation conditions are the same as those of the release recommendation condition definition data 540, or the standards for rarity, excellence, and interest of the play content are set higher.

[0249] If it is determined that the re-release recommendation conditions are met (YES in step S128), the server system 1100 creates the gameplay video data 840 (step S130) and performs the publishing process (step S132). However, if the re-release recommendation conditions are not met (NO in step S128), the server system 1100 discards the integrated scene-specific gameplay replay data 820 and makes it unpublished.

[0250] In this configuration, as gameplay progresses, scenes are cut out in order from the beginning. If the game is played by Player 2 who has set the release restriction setting to "unlimited release" or "restricted release," the scenes will be released in the order they were cut out. In other words, if you watch the scenes consecutively in the order they were released, it will essentially be a live broadcast.

[0251] However, in the case of a play by player 2 with the publication restriction setting set to "publication prohibited", the scenes are processed in the publication prohibition corresponding process in the order in which they were extracted, and only the scenes that satisfy the publication recommendation conditions are published in sequence. In this case, if the publication recommendation conditions are not satisfied, the scene will not be published. Thus, the scenes published will be intermittent, but the time during which new scenes are not published is balanced by, for example, consuming the time difference between the start of game progress control and the start of scene extraction in step S11. As a result, scenes that satisfy the publication recommendation conditions are published one after the other in a continuous manner. In other words, a pseudo live distribution is realized.

[0252] To sum up, according to this configuration, the server system 1100 shifts a target portion of a continuous game play in chronological order, determines whether the publication restriction setting for the target portion does not satisfy the setting condition and satisfies the publication recommendation condition, and when a positive determination is made, can publish at least the replay of the target portion. The publication of the replay of the target portion becomes a pseudo live distribution with a time limit, or a live distribution publication.

[0253] Then, as shown in FIG. 28, the second disclosure control unit 230 of the server system 1100 has a fourth disclosure control unit 239 that controls the disclosure of re-enactments of consecutive game plays including the target portion, based on the play re-enactment data of the game play, after the re-enactment of the game play relating to the target portion has been made public.

[0254] This embodiment can also be realized based on the second embodiment. The present invention is not limited to single-player mode, but can also be applied to multiplayer mode.

[0255] [Modifications] Although the embodiment to which the present invention is applied has been described above, the forms to which the present invention can be applied are not limited to the above-described forms, and constituent elements can be added, omitted, or modified as appropriate.

[0256] (Variation 1) For example, in the first embodiment, an example was given in which the publication control system 1000 was realized in a client-server type computer system, but the server system 1100 may be omitted and the system may be realized in a computer system in which multiple player terminals 1500 are connected in a peer-to-peer manner. In that case, one of the player terminals 1500 is made to function as the server system 1100 of the first embodiment.

[0257] (Variation 2) It is also possible to provide individual disclosure restriction settings that are applied individually to each of the scene-specific play-reproduction data 820, and to configure the settings to be changed as appropriate. Specifically, a single play process D can be executed based on any one of the first to third embodiments.

[0258] FIG. 29 is a flowchart for explaining the flow of the single play process D. The single play process D basically has the same flow as the single play process (see FIG. 16), but creates and initializes individual application publication restriction setting data that is individually applied to the scene-specific play reproduction data 820 created in conjunction with the selection of the highlight scene (step S26). Specifically, the contents of the publication restriction setting data 720 are copied as is to the player 2.

[0259] Also, in loop A, instead of step S40, the individual application publication restriction setting data of the scene-specific play reproduction data 820 of the scene to be processed is referenced to determine whether a predetermined setting condition is satisfied (step S41).

[0260] If the setting of the publication restriction setting data 720 is set to "publication prohibited" (NO in step S41), it is determined that the predetermined setting condition is not satisfied, and the server system 1100 executes the publication prohibition corresponding process D (step S45).

[0261] FIG. 30 is a flowchart for explaining the flow of the publication prohibition handling process D. This process basically has the same flow as the disclosure prohibition response process (see Figure 17), but the disclosure process in step S66 is omitted, and instead the disclosure restriction setting of the individually applied disclosure restriction setting data for the scene being processed in loop A is changed from "disclosure prohibition" to "restricted disclosure" or "unrestricted disclosure" with the deletion of personally identifiable elements as a restriction detail setting (step S67).

[0262] When publication prohibition response process D is completed, the process returns to before step S41, and the server system 1100 repeats loop A again for the same highlight scene. In the second loop A, the individual application publication restriction setting data of the scene that satisfies the publication recommendation condition has been changed to something other than "publication prohibited", so that the scene is subjected to publication processing for the second time.

[0263] (Variation 3) In the above embodiment, the disclosure restriction settings are set for each player, but in the case of a multiplayer game, particularly in a team-based multiplayer game, disclosure restriction settings can be set for each team. In that case, the disclosure restriction settings may be set by the team representative by calling up the setting screen W5 after a discussion between team members via chat or the like.

[0264] (Variation 4) The content of the restriction detailed setting 776 is not limited to the example of the above embodiment. The restriction detailed setting 776 may include a description (condition description type) of the restriction detailed setting 776 as a condition for determining whether or not to permit disclosure, such as "inclusion in the image is permitted, but not large in the image" or "viewpoint of one's own camera is not permitted."

[0265] To describe this modified example in detail based on the first embodiment, as shown in FIG. 31, following step S40, the server system 1100 determines whether the restriction detail setting 776 to be applied includes a condition description type (a specific type of restriction detail) (step S47).

[0266] If it is not included (NO in step S47), the process proceeds to step S42. If it does (YES in step S47), the server system 1100 determines whether the conditions for allowing disclosure described in the restriction detailed settings 776 are met (step S48), and if they are met (YES in step S48), proceeds to step S42, and if they are not met (NO in step S48), proceeds to step S44.

[0267] If the detailed restriction setting 776 is set to "appearance is permitted, but not large," the server system 1100 calculates the size of the player character operated by the player 2 in the highlight scene screen and compares it with a predetermined appearance size standard that represents the "large appearance" condition in step S48. Alternatively, the server system 1100 compares the area ratio of the player character to the game screen with a predetermined appearance screen ratio standard that represents the "large appearance" condition to make a judgment. If the detailed restriction setting 776 does not fall under "large appearance" (YES in step S48), the server system 1100 applies other detailed restriction settings 776 and makes the content public. If the detailed restriction setting 776 falls under "large appearance" (NO in step S48), the server system 1100 proceeds to step S44.

[0268] If "own camera viewpoint not permitted" is set as the restriction detailed setting 776, the server system 1100 determines in step S48 whether the viewpoint of the highlight scene to be processed in loop A is the camera viewpoint of player 2 (first person viewpoint or third person viewpoint of player 2). If the answer is yes (YES in step S48), proceed to step S42, and if the answer is no (NO in step S48), proceed to step S44.

[0269] This modification can be applied to embodiments other than the first embodiment as well as other modifications in the same manner.

[0270] Furthermore, when this modified example is applied, it is preferable to change the contents of the public privilege (step S68; see FIG. 17 for example) according to the type of original public restriction setting of player 2. For example, it is preferable to set the contents of the public privilege for player 2 who had set it to "publication prohibited" to have a higher privilege value than the public privilege for player 2 who had set it to "publication with restrictions." By making a difference in the public privilege, it is possible to give a sense of satisfaction to player 2 who had set it to "publication prohibited."

[0271] (Variation 5) Furthermore, the disclosure recommendation conditions may include content that requires voice recognition or image recognition, provided that the first disclosure control unit 220 and the second disclosure control unit 230 include a function unit that performs voice recognition or image recognition, as appropriate.

[0272] For example, a configuration is possible in which a keyword contained in the chat is set as the disclosure recommendation condition. In this case, in step S50 (see, for example, FIG. 17), if the chat is a text chat, a keyword search is performed from the text, or if the chat is a voice chat, voice recognition is performed to determine whether the voice contains a keyword, and if the keyword is included, it is determined that the disclosure recommendation condition is met. Similarly, if it is desired that the disclosure recommendation condition be set when something specific is shown in the highlight scene, dictionary data for image recognition is prepared in association with the disclosure recommendation condition. In this case, in step S50, image recognition processing is performed on the highlight scene to determine whether something specific that is set as the disclosure recommendation condition is shown. [Explanation of symbols]

[0273] 2. Player 20...Notice of publication restrictions 200s…Server processing section 210…Game Management Department 211…Publication restriction setting section 212…Matching section 214...play data storage control unit 216...play reproduction data storage control unit 218...Settings notification control unit 220...First public control section 230...Second Public Control Section 232…Disclosure recommendation condition determination section 234...display suppression control unit 236...Disclosure permission operation reception control unit 238…Third Public Control Section 239…4th Public Control Section 256…Condition change section 540…Recommended disclosure condition definition data 700...Play data 750…Play replay data 754…Matching data 770...Publication restriction setting data 800…Precedent record data 820... Scene-specific play reproduction data 840...Play video data 842... Public site data 844…Additional recommended conditions for disclosure 850…Scene extraction timing list 1000…Public Control System 1100, 1100B...Server system 1150…Control board 1500, 1500B...Player terminal

Claims

1. A computer system that controls the publication of a replay of a game play that reproduces a part or all of the game play based on play reproduction data for reproducing the game play, comprising: a first disclosure control means for controlling disclosure of a replay of a game play based on the play replay data of the game play, for which a disclosure restriction setting regarding the presence or absence of a disclosure restriction for the replay set by a player satisfies a given setting condition; a second disclosure control means for controlling automatic disclosure of a replay of a game play based on the play replay data of the game play, the replay being a game play that does not satisfy the disclosure restriction setting condition and that satisfies a given disclosure recommendation condition, regardless of the disclosure restriction setting; A computer system comprising:

2. the second disclosure control means includes a display suppression control means for suppressing display of identification information of the player who has set the disclosure restriction setting that does not satisfy the setting condition during the replay; 2. The computer system of claim 1.

3. the game play is a multiplayer game play, The publication restriction setting is a setting for each player, The set conditions are based on the disclosure restriction settings of all participating players.

3. A computer system according to claim 1 or 2.

4. The disclosure recommendation conditions include at least one of the following: 1) the gameplay content satisfies a given rarity condition; 2) the gameplay result satisfies a given excellence condition; and 3) the gameplay content satisfies a given interest condition. A computer system according to any one of claims 1 to 3.

5. a condition changing means for changing the disclosure recommendation conditions based on a given desired condition input by a viewing user; The computer system according to any one of claims 1 to 4, further comprising:

6. the second disclosure control means, while shifting a target portion of the continuous game play in a chronological order, determines whether or not the disclosure restriction setting for the target portion does not satisfy the setting condition and satisfies the disclosure recommendation condition, and when a positive determination is made, discloses a re-enactment of at least the target portion; A computer system according to any one of claims 1 to 5.

7. The second publication control means sets the publication of the re-enactment play related to the target portion to a time-limited publication or a live distribution publication.

7. The computer system of claim 6.

8. a fourth disclosure control means for controlling disclosure of a replay of the continuous game play including the target portion based on the play replay data of the game play after the replay of the play related to the target portion is disclosed by the second disclosure control means; 8. The computer system of claim 6 or 7, further comprising:

9. A computer system that controls the publication of a replay of a game play that reproduces a part or all of the game play based on play reproduction data for reproducing the game play, comprising: a first disclosure control means for controlling disclosure of a replay of a game play based on the play replay data of the game play, for which a disclosure restriction setting regarding the presence or absence of a disclosure restriction for the replay set by a player satisfies a given setting condition; a second disclosure control means for controlling disclosure of a replay of a game play based on the play replay data of the game play, the game play not satisfying the setting condition of the disclosure restriction setting and satisfying a punitive disclosure condition indicating that the game play is an action to be avoided; A computer system comprising:

10. A player terminal; A server system which is a computer system according to any one of claims 1 to 9; A disclosure control system comprising:

Images