Computer system and public 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 make videos using gameplay screens, so-called "gameplay videos," available to an unspecified number of people via the Internet by posting them on video sharing sites, etc. Gameplay videos are classified into two types: one in which the player records the game screen on the game device while playing and then edits the video after playing, and one in which the video is automatically generated by a game server to which the game device is connected online (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 way 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 using that data, generates a gameplay video, and publishes that gameplay video (see, for example, Patent Document 2).

[0004] Published gameplay videos can also be a great learning tool for players who enjoy the same game title. Publishing gameplay videos can revitalize player communities, and game titles that have a system for publishing gameplay videos become very attractive to players. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Laid-Open No. 2003-320170 [Patent Document 2] Japanese Patent Application Laid-Open No. 2006-6853 Summary of the Invention [Problem to be solved by the invention]

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

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

[0008] For example, if a player who refuses to disclose develops a new strategy, disclosing it will be useful to many other players. Other players may be inspired by it and develop even more new strategies. These will invigorate the entire player community and increase the enjoyment of the game. Similarly, if a player who refuses to disclose achieves a new record for the time it takes to clear a stage, discovers an incredibly rare item that is the stuff of rumors, defeats an enemy character that requires multiple players by himself, or behaves in a manner that is worthy of praise and gentlemanly conduct, it may be that the community as a whole benefits more from disclosing the game than from respecting the player's personal wishes and keeping 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 public their replays, such as gameplay videos, and the benefits to the entire player community that can be gained by making public the replays of that player. [Means for solving the problem]

[0010] A first invention for solving the above-mentioned problems is a computer system that controls the publication of a replay of a game play that is reproduced 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 of FIG. 1, the server processing unit 200s of FIG. 8, the first disclosure control unit 220, steps S40, S42, S98, and S100 of 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 disclosure of the replay satisfies a given setting condition; a second disclosure control means (e.g., the control board 1150 of FIG. 1, the server processing unit 200s of FIG. 8, the second disclosure control unit 230, steps S50, S62, and S64 to S68 of FIG. 17) that controls disclosure of a replay of a game play based on the play replay data of the game play, for the game play for which the disclosure restriction setting does not satisfy the setting conditions and which satisfies 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, replays of gameplays that satisfy the given conditions for public release are made public, but gameplays that do not satisfy the given conditions can be kept private. On the other hand, even if a gameplay that would normally be private because it does not satisfy the given conditions can be made public as an exception if it satisfies the recommended public release conditions. In other words, the recommended public release conditions make it possible to appropriately balance the personal wishes of a player who does not want to make public their gameplay replays, such as gameplay videos, and the benefits to the entire player community that can be gained by making public the replays of that player.

[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 Figure 1, server processing unit 200s in Figure 8, display suppression control unit 234 in Figure 17, step S62 in Figure 17) that does not display identification information of a player with the public restriction setting that does not satisfy the setting conditions during the re-enactment play.

[0014] According to the second aspect of the present invention, the player can set the disclosure restriction setting by himself / herself. Then, even if the replay 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 gameplay is multiplayer gameplay, the public restriction settings are set for each player, and the setting conditions are conditions based on the public restriction settings of all participating players.

[0016] According to the third aspect of the present invention, even in a multiplayer game, each player can individually set a disclosure restriction. Based on the disclosure restriction settings of all participating players, the computer system can control whether to make the game public, private, or public if the game is originally private but meets the recommended disclosure conditions. For example, if the predetermined condition is that all participating players' disclosure restriction settings are set to public, 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 public if the recommended disclosure conditions are met."

[0017] A fourth aspect of the present invention is a game system including: a game play in which the game is played by multiplayer, the public restriction setting is a setting for each player, and when the participating players include a participating player with the public restriction setting that does not satisfy the setting conditions, a public permission operation accepting means (for example, the control board 1150 of FIG. 1, the server processing unit 200s of FIG. 8, the public permission operation accepting control unit 236, step S54 of FIG. 20) that inquires of the participating players about public permission and accepts a public permission operation; a third disclosure control means (e.g., the control board 1150 of FIG. 1, the server processing unit 200s of FIG. 8, the third disclosure control unit 238, step S56 of 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 conditions and the disclosure permission operation receiving means has accepted the 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 the game public) is participating, the computer system inquires of the player about permission to make the game public, and if the player operates to allow the game to be public, the replay can be made public.

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

[0020] According to the fifth aspect of the present invention, in a multiplayer game, even if the game play satisfies the disclosure recommendation conditions, the computer system accepts a disclosure permission operation from a participating player, and discloses the replay of the play only if the disclosure 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 content based on the public restriction setting of each participating player.

[0022] According to the sixth aspect of the present invention, the participating players in a multiplayer game can know the details of each other's disclosure restriction settings, so even if the replay of the multiplayer game is not made public as expected or is made public, they 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, which preferentially matches players with the disclosure restriction setting who do not satisfy the set conditions (e.g., the control board 1150 in Figure 1, the server processing unit 200s in Figure 8, the matching unit 212, step S8 in Figure 18).

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

[0025] An eighth invention is a computer system of any of the first to seventh inventions, wherein the second disclosure control means changes the disclosure restriction setting for gameplay whose disclosure restriction setting does not satisfy the setting conditions and which satisfies given disclosure recommendation conditions to a setting that satisfies the setting conditions (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 public recommendation conditions, the settings 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 one of the first to eighth inventions, in which the public recommendation conditions include at least one of the following: 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 condition.

[0028] According to the ninth invention, the public recommendation conditions can be any of 1) the play content meeting a given rarity condition, 2) the results of the game play meeting a given excellence condition, or 3) the play content meeting a given interest condition.

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

[0030] A viewing user is a user who views the reenacted play that is made public. According to the tenth aspect of the present invention, the computer system can select a replay to be made public based on the recommended conditions for public disclosure 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 a continuous game play in chronological order, determines whether the disclosure restriction setting for that target portion does not satisfy the setting condition and satisfies the disclosure recommendation condition, and if a positive judgment is made, discloses a re-enactment of at least that target portion (for example, single play processing B in Figures 25 to 26).

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

[0033] A twelfth invention is the computer system of the eleventh invention, wherein the second publication control means publishes the replay related to the target portion as a time-limited publication or as a live streaming publication.

[0034] According to the 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 Figure 1, the server processing unit 200s of Figure 28, the fourth disclosure control unit 239, steps S124 to S132 of Figure 26) that 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 related 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 a computer system according to 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 disclosure control system that exhibits the same effects as any one of the first to thirteenth aspects of the present invention. [Brief explanation of the drawings]

[0039] [Figure 1] FIG. 1 is a diagram showing an example of the configuration of a publication control system. [Figure 2] FIG. 1 is a diagram illustrating a game service. [Figure 3] Diagram (part 1) to explain the release of gameplay videos. [Figure 4] Diagram (part 2) to explain the release of gameplay videos. [Figure 5] FIG. 10 is a diagram showing an example of a setting screen for publication restriction setting data. [Figure 6] FIG. 10 is a diagram showing an example of a game screen in multiplayer mode. [Figure 7] FIG. 10 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. 3 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. 10 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. 10 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. 2 is a functional block diagram showing an example of the functional configuration of a player terminal in the first implementation process. [Figure 16] 10 is a flowchart illustrating the flow of a single-play process. [Figure 17] 10 is a flowchart illustrating a process for dealing with publication prohibition. [Figure 18] 10 is a flowchart illustrating the flow of processing related to multiplay. [Figure 19] Flowchart continued from Figure 18. [Figure 20] 10 is a flowchart for explaining the flow of a publication prohibition response process B. [Figure 21] 10 is a flowchart illustrating the flow of a recommended disclosure condition change process. [Figure 22] FIG. 10 is a functional block diagram showing an example of the functional configuration of a player terminal according to a second embodiment. [Figure 23] FIG. 10 is a diagram showing examples of programs and data stored in a terminal storage unit of a player terminal according to the second embodiment. [Figure 24] FIG. 10 is a diagram showing an example of the functional configuration of a server system according to a second embodiment. [Figure 25] 10 is a flowchart for explaining the flow of single-play processing B. [Figure 26] Flowchart continued from Figure 25. [Figure 27] FIG. 10 is a diagram showing an example of the data structure of a scene cutout timing list. [Figure 28] FIG. 11 is a diagram showing an example of the functional configuration of a server system according to a third embodiment. [Figure 29] 10 is a flowchart for explaining the flow of single play processing D. [Figure 30] 10 is a flowchart for explaining the flow of a publication prohibition response process D. [Figure 31] 10 is a flowchart for explaining the flow of single play processing E. DETAILED DESCRIPTION OF THE INVENTION

[0040] An example of an embodiment of the present invention will be described below, but it goes without saying that the forms to which the present invention can be applied are 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 related 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 that data communication between them is possible.

[0042] The publication control system 1000 is a computer system that provides (1) a game service that provides online games to users of the player terminals 1500, and (2) a publication service that provides viewable replays 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. That is, 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 communication network such as a telephone communication network, a cable network, or the Internet, and the communication method may be either wired or wireless.

[0044] The server system 1100 is a computer system that includes, for example, a main device 1101, a keyboard 1106, a touch panel 1108, and a storage 1140, and in which a control board 1150 is 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 part or all 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 the function of providing game services and public services by the control board 1150 performing calculations based on predetermined programs and data, including the provision of 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 shown in FIG. 1, in actual system operation, multiple player terminals 1500 can access the server system 1100 at the same time.

[0048] Furthermore, although the server system 1100 is depicted as if it were a single server device, it may be configured to be realized by a plurality of devices. For example, the server system 1100 may be configured to include a plurality of blade servers that share various functions and are connected to each other via an internal bus so that they can communicate data with each other. Furthermore, the location of the hardware that constitutes the server system 1100 does not matter. It may also be configured so that a plurality of independent servers installed in remote locations communicate data via the network 9, and function as the server system 1100 as a whole.

[0049] The server system 1100 is involved in the gameplay video publishing service and controls the management of the gameplay video publishing site. Of course, the public site may not be managed by the server system 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, thereby making the gameplay videos public.

[0050] The player terminal 1500 is a computer system that a user who has completed a registration procedure uses to use the publication 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 known as a smartphone, but may also be a computer such as a wearable computer such as a smartwatch or smart glasses, a portable game device, a tablet computer, or a personal computer. When multiple electronic devices are communicatively connected to perform a single function, such as a combination of a smartphone and a smartwatch communicatively connected to the smartphone, these multiple electronic devices can be considered as a single 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) various microprocessors such as a CPU 1551, 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 wireless communication with a mobile phone base station or a wireless LAN base station connected to the network 9, and (4) an interface circuit 1557 that includes 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 be able to read and write data and send and receive signals. Note that part or all of the control board 1550 may be configured using an ASIC, FPGA, or SoC. The control board 1550 stores programs and various data for realizing the functions of 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 it may also be configured to read data from separately obtained storage media such as disk media or memory cards by incorporating a disk media reader or memory card reader.

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

[0056] Information related to the progress of the game and information related to the display of the game screen W2 is 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 also creates and stores play data 700. The play data 700 is created for each game play and is a variety of data for controlling the game progress. It describes 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 that game play.

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

[0059] 3 and 4 are diagrams for explaining the publication of gameplay videos. The server system 1100 creates and stores publication restriction setting data 720 for each player 2. The publication restriction setting data 720 is information specifying what restrictions the associated player 2 will impose on the publication of their own 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 along with the selection of the player character, or it is displayed before restarting the game when restarting 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. The restriction type setting section 10 presents options for restriction types, and the player 2 selects one of the settings. The restriction types can be set as appropriate, but in this embodiment, "unlimited release," "restricted release," and "restricted release" are provided.

[0062] "Unrestricted disclosure" is selected if you wish to make the data available without any restrictions. "Restricted release" is between unlimited release and no release, and is selected when release is permitted according to specified restrictions. A restriction detail display section 12 is then displayed in association with the restricted release option. The restriction detail display section 12 displays detailed restriction details, with check boxes provided for each type. Player 2 sets the desired restrictions in detail by checking the check boxes for the desired restriction details. The set restrictions are stored as detailed restriction settings. The details of the restrictions can be set as appropriate. For example, "hide the account," "replace the player's voice with an alternative voice," "keep text chat private," "display the player's character's distinctive features with a mosaic," etc.

[0063] "No disclosure" is selected when no disclosure is desired. However, in this embodiment, "no disclosure" indicates a general rule, and if the play content meets the "recommended disclosure conditions" described below, it will be exceptionally made public after a predetermined 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 watch the game play because the notice cannot be approved.

[0065] Player 2 sets the restrictions he or she desires on the setting screen W5, and starts playing the game by operating the application start operation icon 18. Alternatively, he or she can start playing the game by going through a pre-game preparation screen.

[0066] 3, the disclosure restriction setting data 720 for player 2a is set to "unlimited disclosure." That is, the gameplay video of player 2a is disclosed without any particular restrictions. When the disclosure restriction setting data 720 is set to "unlimited disclosure" or "restricted disclosure," the server system 1100 modifies the play-play replay data 750 for player 2a associated with the disclosure restriction setting data 720 so as to apply the restrictions indicated by the setting in the disclosure restriction setting data 720 to the play-play replay data 750 for player 2a.

[0067] The application of the restriction content can be achieved by deleting information related to the restricted object from the play-play replay data 750. Alternatively, the application can be achieved by adding data to the play-play replay data 750 that specifies that the restricted object should be hidden when creating a gameplay video. Alternatively, the application can be achieved 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 predetermined 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 player 2, the server system 1100 only creates in advance from the play-play reenactment data 750 thumbnail images to be displayed on the public site W3. Then, a gameplay video may be generated and distributed to the player terminal 1500 of player 2 who has made a viewing request. Of course, video data may be created in advance from the play-play reenactment data 750 and distributed and made public.

[0070] 4, the disclosure restriction setting data 720 for player 2b is set to "disclosure prohibited." When the disclosure restriction setting data 720 is set to "disclosure prohibited," the server system 1100 basically keeps the gameplay replay data 750 for player 2b associated with the disclosure restriction setting data 720 private. However, if it is determined that a given disclosure recommendation condition is met, the server system 1100 creates and publishes a gameplay video while deleting from the gameplay replay data 750 any personally identifiable elements (information or displays that could provide a clue to identifying the player).

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

[0072] The "Recommended Conditions for Publishing" indicate that the content of a gameplay video falls into at least one of the following categories: particularly rare, particularly excellent, and particularly intriguing. Specifically, this applies if a player has devised a new strategy to beat a stage boss in a game. Publishing the video will help many other players complete the game. Other players may be inspired and continue to work on the video to devise even new strategies. In the process, they will likely have a lot of fun talking about the game with their friends. Similar examples include setting a new record, such as the shortest time to complete a game or consecutive combos, finding a super rare item, or demonstrating exemplary gentlemanly behavior that deserves praise.

[0073] Of course, the conditions for recommending a game to be published are not limited to rare plays, excellent plays, or interesting plays, and can include any play that is beneficial to the player community. For example, it can also include behavior that should be avoided in gameplay videos, such as violations of etiquette, public order, or ethics. In this case, publishing a reenactment of a gameplay has punitive implications. Accidental and rare scenes can also be included in the conditions for recommending a game to be published as a type of interesting play.

[0074] The disclosure recommendation conditions can be determined from various data included in the play-play reenactment data 750. The play-play reenactment data 750 includes player information 762, operation input time-series data 782, and progress status 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, operation force, and input time) in association with input time information (for example, date and time, elapsed time from the start of game play, number of rendering frames of the game screen, etc.).

[0076] The progress status time series data 790 stores information indicating the game progress information at each moment (for example, 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 association with time information.

[0077] NPCs (Non Player Characters) are also a type of object. Therefore, when an NPC appears in the 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 "a combo is formed by successive specific techniques" is an excellent scene (highlight scene), the conditions for determining whether or not a scene is recommended for publication are defined as follows: (1) the operation input time series data 782 contains data indicating operation input of successive specific attack techniques, and (2) the progress status time series data 790 contains data indicating that a corresponding amount of damage has been inflicted on the opponent character.

[0079] In addition, in order to determine that "a new record for the number of combos is achieved" is an excellent scene, the server system 1100 will separately record and manage the recorded values ​​of the types of excellent scenes in the game (for example, 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 a 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 publication: (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 addition, in order to determine whether a "new strategy for defeating a boss character" is a good 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. as record items. 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 recorded in the past.

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

[0083] Of course, the disclosure recommendation conditions can be set to other conditions depending on the game content. Furthermore, the disclosure recommendation conditions may be determined not by determining whether a specific scene content is met as described above, but by 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, by adding points based on the game performance, or by adding negative points for each action that should be avoided.

[0084] FIG. 6 is a diagram showing an example of a game screen W6 in multiplayer mode. In a multiplayer game involving multiple players, depending on the matching results, players with different settings for the disclosure restriction setting data 720 may play against each other. In the example of FIG. 6, three players form a team, each controlling a player character 4 (4a, 4b, 4c) to fight against an enemy character 6 (6a, 6b; NPC). The disclosure restriction setting data 720 of the first player 2c is set to "unlimited disclosure," the second player 2d is set to "restricted disclosure," and the third player 2e is set to "no disclosure." On the multiplayer game screen W6, the settings of each player's disclosure restriction setting data 720 can be known to each other through disclosure restriction notifications 20 (20a, 20b, 20c).

[0085] In addition, for multiplayer gameplay videos, if the setting of the disclosure restriction setting data 720 for even one of the players 2 (participating players) who were primarily involved in creating the content of the gameplay video to be made public is "no disclosure allowed," the server system 1100 will generally keep the video private, but will make it public as an exception if the disclosure recommendation conditions are met.

[0086] The definition of "participating player" can be set as appropriate, but basically, in a game in which all participating players form a team and play cooperatively, all members of that team are participating players. In a team battle, all team members involved in the battle scene are participating players. However, in a massively multiplayer game (such as an MMORPG), the play of other players may be reflected in the background of the play being made public, but these other players are not included in the participating players.

[0087] Furthermore, when a predetermined disclosure request operation is input by a first player 2c who has set "unlimited disclosure" or a second player 2d who has set "limited disclosure," an exceptional case occurs in which a scene 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) is made public if a third player 2e who has set "no disclosure" inputs an operation to allow disclosure. In other words, the recommended disclosure condition for multiplayer is that a predetermined disclosure request operation is input by a player 2 (first player 2c) who has set "unlimited disclosure" or a player 2 (second player 2d) who has set "limited disclosure."

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

[0089] FIG. 7 is a diagram illustrating the publication of gameplay videos in multiplayer mode. The multiplayer play data 700 stores each player's operation input information and progress control information. The server system 1100 creates and records play replay data 750 from the play data 700, just as in single play.

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

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

[0092] Of course, the disclosure requirements are not limited to this and can be set as appropriate. 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 content will be disclosed. However, 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 disclosure requirements disclosure permission operations by players 2 who have set "disclosure prohibited." A limit may be placed on the number of disclosure request operations.

[0093] In this way, whether it is single-player or multiplayer, the server system 1100 will generally keep gameplay videos of player 2 who wishes to keep them "private," private. However, if the gameplay content is deemed beneficial to the entire player community, the video will be made public as an exception, 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 a processor serving as an arithmetic circuit, such as a CPU, GPU, ASIC, or FPGA, as well as IC memory, and controls input and output of data between the server processing unit 200s and each functional unit, including the operation input unit 100s and the server storage unit 500s. The server processing unit 200s performs 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., and comprehensively controls 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 stores and manages various information linked to user accounts. Specifically, the user management unit 202 performs the following functions: (1) assigning 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 for characters used in the game, and (5) management of game-related items owned by the user. Of course, the unit may also include a function for managing other data linked to accounts as appropriate.

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

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

[0101] When a game is played 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 with publication restriction settings that do not satisfy the setting conditions).

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

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

[0104] When a game is played 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] For gameplays for which the publication restriction settings for publishing the replays satisfy given conditions, the first publication control unit 220 controls the publication of the replays based on the gameplay replay data 750 of the gameplay. Specifically, the first publication control unit 220 determines that the given conditions are satisfied when the publication restriction settings in the publication restriction setting data 720 are set to "unlimited publication" or "limited publication." The first publication control unit 220 then generates a gameplay video from the play-through 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 video to an external video publication management server 1200 (see FIG. 1) for publication.

[0106] The second disclosure control unit 230 controls the disclosure of a replay of a gameplay based on the play replay data 750 for the gameplay whose disclosure restriction setting does not satisfy the set conditions and which satisfies given disclosure recommendation conditions.

[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] If the public restriction setting in the public restriction setting data 720 of player 2 is set to "unlimited public" or "limited public", that is, if the public restriction setting does not satisfy the given setting conditions, the public recommendation condition determination unit 232 determines whether the content of the replay based on the play reproduction data 750 satisfies the public recommendation conditions.

[0109] The display suppression control unit 234 controls the display of identification information of players with disclosure restriction settings that do not satisfy the set conditions during replay play. Specifically, the display suppression control unit 234 deletes the identification information of the player from the play replay data 750 or replaces it with dummy data. Alternatively, when generating a play video from the play replay data 750, the display suppression control unit 234 hides the identification information or replaces it with dummy data.

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

[0111] When the disclosure permission operation reception control unit 236 has received the request, the third disclosure control unit 238 controls the disclosure of a replay of the game play based on the play replay data 750 of the game play.

[0112] The condition change unit 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, the 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 background music related to system management, games, etc. of the server system 1100. The 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 includes some of the functions for 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 images, 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 external devices via the communication unit 394s.

[0120] The communication unit 394s connects to the network 9 and realizes communication. 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, this corresponds to the communication device 1153.

[0121] The server storage unit 500s stores programs and various data for implementing various functions that allow the server processing unit 200s to comprehensively control the server system 1100. It is also used as a work area for the server processing unit 200s, and temporarily stores the results of calculations executed by the server processing unit 200s in accordance with the various programs. This function is realized 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 installed in 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 disclosure recommendation condition definition data 540.

[0123] The server storage unit 500s also stores, as sequentially generated and managed data, user management data 600, gameplay data 700, gameplay replay data 750, previous example record data 800, scene-specific gameplay replay data 820, gameplay video data 840 of the replay, public site data 842 for operating and managing a website on which the gameplay videos of the replays are published, 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, game management unit 210, first public control unit 220, second public control unit 230, condition change unit 256, and 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 is data that defines the criteria for selecting scenes worthy of being made public from all game plays accumulated as 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 determination requirement data 530 for determining a relevant scene. Of course, other data 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 using AND or OR of sub-conditions. The type and content of the sub-conditions can be set appropriately depending on 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 range of elapsed time since the start of play, etc. Simply put, it is a condition regarding the game progress status.

[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 types of operation input are described in chronological order, or a threshold value for the time difference or number of operation inputs. In short, it is a condition on what kind of operation input was performed.

[0131] The play performance condition 536 is a sub-condition about the play performance. For example, it can be described using a stage clear, a rare item acquired, a boss character defeated, a hidden stage unlocked, an acquired score, a distance traveled, etc. In short, it is a condition about what kind of play performance there 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, you can 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, you can set the play content as "(Progress condition = unlimited), M times (M is an integer greater than or equal to 5), all attacks hit (combo achieved), new record achieved" as a judgment requirement. Note that the content defined by the sub-conditions can also be undefined or unlimited.

[0134] FIG. 11 is a diagram showing an example of the data structure of the recommended disclosure condition definition data 540. As shown in FIG. Recommended disclosure condition definition data 540 is created for each recommended disclosure condition. One recommended disclosure 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 content of the condition, and when the presentation operation icon 15 for recommended public conditions is operated on the public restriction setting screen W5 (see Figure 6), the content is presented to the player 2.

[0136] The detailed condition data 550 is a data group that defines the content of the disclosure recommendation condition, and the content of the disclosure recommendation condition is described using AND or OR of sub-conditions. The detailed condition data 550 describes the rare condition, excellent condition, and interest condition that must be met to determine that a game is worthy of disclosure recommendation. The type and content of the sub-condition can be set appropriately depending on the game content. 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 range of elapsed time since the start of play, etc. Simply put, it is a condition regarding the game progress status.

[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 types of operation input are described in chronological order, or a threshold value for the time difference or number of operation inputs. 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 obtained, a boss character defeated, a hidden stage unlocked, a score obtained, a distance traveled, etc. In short, it is a condition about what kind of play performance there 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] By appropriately setting sub-conditions, the disclosure recommendation condition definition data 540 is set to include at least one of the following: (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 disclosure condition is a play that defeats a boss character that is thought to be impossible to defeat without magic, i.e., a rare, excellent, and intriguing play that makes you think, "Who could possibly do that?", the detailed condition data 550 can be set to "Progress condition = Nth stage, Operation input condition = No magic attack, Play performance condition = Defeated boss character, Record condition = Not set." Since the "Record condition = Not set," the corresponding play will be made public every time it occurs. If the "Record condition = Unprecedented" setting is used, the corresponding play will only be made public the first time it occurs.

[0143] Furthermore, if the recommended conditions for publication are rare and excellent play content that updates the number of consecutive combos, regardless of progress, then the detailed condition data 550 can be set as follows: "Progress condition = no setting, operation input condition = operation input M times (M is an integer greater than or equal to 5 and is the record value for the number of consecutive combos), play performance condition = all consecutive attack hits (combo achieved), record condition = unprecedented."

[0144] Comparing the recommended disclosure condition definition data 540 and the highlight scene definition data 520, they are very similar, but the play content defined by the recommended disclosure condition definition data 540 is particularly rare, particularly excellent, record-worthy, and particularly interesting among the play content 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 are considered to satisfy the recommended disclosure conditions.

[0146] 9, user management data 600 is prepared for each user who has completed a predetermined user registration procedure, i.e., 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 stores various data describing the latest progress status and latest play results of that game play. 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 for the player to which the data set applies, 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 of the player's team, and chat data 736. The chat that forms the basis of the chat data 736 may be text chat or voice chat. Of course, data other than these may also be included as appropriate. For example, in a game that uses a first-person perspective, viewpoint operation data may also be included. Depending on the content of the game, 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 currently being played, and in the case of a battle, the number of wins and losses. The progress status data 740 also includes object control data 742 for each object that appears in the game, such as the player character, NPC, and background object.

[0151] The disclosure request history data 744 is data created during multiplayer play, and is created each time a disclosure request operation (see FIGS. 7 and 8) is detected. One disclosure 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 disclosure request history data 744 indicates when and who made the disclosure request.

[0152] FIG. 13 is a diagram showing an example of the data structure of the play reproduction data 750. The play-play replay data 750 is prepared for each game play, that is, for each play data 700. The play-play replay data 750 is basically composed of a group of data in which various data included in the play data 700 is copied from the 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 previous record data 800 is a record of events that occurred in the game, and is created for each relevant event. The previous 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 recording subject 810 indicating what the record is about, and recording 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 may also be included as appropriate, and any of the sub-conditions describing the detailed situation data 802 may be set to essentially correspond to "no condition."

[0159] Recording target 810 indicates which data included in play replay data 750 (see FIG. 13) is being recorded. For example, it can be the required time, the number of combos, or the combo pattern (continuous operational input data from the start of an attack technique until it ends).

[0160] The recorded content 812 is a record of when the recording target 810 occurred. If the recording target 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 case of recording "the time required for the Xth stage to be cleared by defeating the boss" in the precedent record data 800, the detailed situation 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 clear)". 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 replay data 820 is a data group for replaying highlight scenes indicated by the highlight scene definition data 520 and scenes that conform to the recommended disclosure condition definition data 540. The scene-specific play replay data 820 stores, for example, a scene ID indicating the conforming 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 replay data 750.

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

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

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

[0166] The validation information 846 is created for each candidate data requested for addition 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 when the viewing user requested addition.

[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 device 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 operation input signals corresponding to various operation inputs made by the user to the device processing unit 200. For example, this can be realized by a push switch, a joystick, a touchpad, a trackball, an acceleration sensor, a gyro, a CCD module, etc. The operation keys 1502 and the touch panel 1506 in FIG. 1 correspond to these.

[0169] The device processing unit 200 is realized by electronic components such as a microprocessor such as a CPU or GPU, and an IC memory, and controls the input and output of data between the device and each functional unit including the operation input unit 100 and the device storage unit 500. The device processing unit 200 controls the operation of the player terminal 1500 by executing 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. This corresponds to the control board 1550 in FIG. 1.

[0170] The device processing unit 200 in this embodiment includes 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 controls the player terminal 1500 to function 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 game screens, 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 and browsing 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 by, for example, 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, combines 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. 1, this corresponds to the touch panel 1506.

[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 connects to the network 9 to realize communication. 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, this corresponds to the wireless communication module 1553.

[0182] In this embodiment, the server system 1100 is configured to generate images of the game screen and various other screens, but it is also possible to generate them in the player terminal 1500. In this case, the image display control unit 262 controls, for example, objects placed 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 device storage unit 500 stores programs for causing the device processing unit 200 to realize given functions, various data, etc. It is also used as a work area for the device processing unit 200, and temporarily stores the results of calculations executed by the device processing unit 200 in accordance with various programs, input data input from the operation input unit 100, etc. These functions are realized by, for example, IC memory such as RAM or ROM, magnetic disks such as hard disks, optical disks such as CD-ROMs or DVDs, etc. 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 device 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 configured to 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 the publication control system 1000 will be described. 16 is a flowchart 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 disclosure 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 in accordance with setting operation input by the player 2.

[0188] Next, the server system 1100 performs various initializations and starts game progress control (step S10). If game save data is available, it may be loaded and the game may be restarted from a save point. Once game progress control is started, the server system 1100 starts accumulating data necessary for progress control as play replay data 750 while saving and rewriting the data in the play data 700.

[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, 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 determines whether the publication restriction setting data 720 of player 2 satisfies a predetermined setting condition (step S32). If it is set to "unlimited publication" or "restricted publication", the determination is affirmative, and if it is set to "publication prohibited", the determination is negative.

[0191] 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 this time, a search tag is set in accordance with 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 performs the publishing process by accessing the video publishing management server 1200 (see Figure 1) and executing an automatic posting procedure using an API (Application Programming Interface) made public for that server.

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

[0195] If "publication prohibited" is set (NO "publication prohibited" in step S40), the server system 1100 executes a process for dealing with the publicity 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 with activation information 846 from the recommended additional disclosure condition candidate data 844 (however, this is limited to those in which the date and time in the desired date and time list is after the set date and time 773 (see Figure 13) in the disclosure restriction setting data 770 of player 2), and determines whether they are satisfied (step S50).

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

[0198] "Personal identification elements" include, for example, a player account, a unique shape part (e.g., an arbitrarily added horn) customized and assigned when setting up a player character, or a unique texture pattern (e.g., adding a personally created emblem). This can also include limited skins or rare equipment applied to a player character, which may be combined to identify an individual.

[0199] Then, the server system 1100 generates gameplay video data 840 (step S64), performs a publishing process (step S66), provides a predetermined publishing benefit (for example, granting some kind of item, granting an item lottery ticket, etc.) (step S68), and ends the publishing prohibition response process.

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

[0201] Once the disclosure prohibition handling process is complete, 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 public restriction setting data 720 (see Figure 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 their disclosure restriction setting to "publication prohibited" are matched with one another with priority. 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 as appropriate and mix players with "publication prohibited" settings and players with "unlimited publicity" and / or "limited publicity" settings when matching them. It is when such a mix of players is achieved that the effects of this embodiment are most effectively exhibited.

[0204] After completing the matching, the server system 1100 starts controlling the game progress (step S10), and then determines whether any of the participating players (in a team battle or in a party-organized RPG, within the same team or party) have the disclosure restriction setting data 720 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, and starts control to display a setting notification of the public restriction setting data on the game screen as a public restriction notification 20 (see FIG. 6) (step S12), and further starts accepting public request operations (step S14). The acceptance targets may be limited to participating players whose public restriction setting data 720 is set to "unlimited public" or "limited public," or may be all players.

[0206] When the game is over (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 operate the player characters shown on the game screen of the replay of the scene (step S32), and executes loop C for each extracted player (steps S34 to S78).

[0208] In loop C, the server system 1100 determines whether the publication restriction setting of the player being processed satisfies the 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 are no players 2 with "publication prohibited" among the participating players, or if there are no players 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. In other words, it will be made public if the setting condition that the public restriction settings of all participating players are "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 server system 1100 determines that the setting of "publication prohibited" does not satisfy the predetermined condition, and executes publicity 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 conditions are not satisfied (NO in step S50), the server system 1100 determines whether or not a disclosure request operation has been made for the scene (step S52). Specifically, the server system 1100 searches for disclosure request history data 794 (see FIG. 13) containing request timing 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 any corresponding data, it determines that a disclosure request operation has been made.

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

[0215] If there is an operation input permitting disclosure by 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 gameplay video (step S64), performs disclosure processing (step S66), and grants a bonus (step S68), and ends disclosure prohibition response processing B.

[0216] If there is an operation input by player 2 that does not allow disclosure to "publication prohibited," the operation to allow disclosure is deemed not to have 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 terminates the disclosure prohibition response process B.

[0217] Furthermore, if there has been no disclosure request operation to begin with (NO in step S52), the server system 1100 also discards the scene-specific play reproduction data 820 of the scene (step S69), and ends disclosure prohibition handling process B.

[0218] When the server system 1100 ends the publication prohibition handling process B, it ends the loop B (step S104) even if the loop C has not been executed for all of the extracted players 2. In other words, depending on the processing in the publication prohibition handling process B, the gameplay video of the scene that is the subject of 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 request disclosure, the server system 1100 will automatically request disclosure permission from Player 2 who is prohibited from disclosure when a play that meets the disclosure recommendation conditions is made.

[0220] FIG. 21 is a flowchart illustrating the flow of the recommended disclosure condition change process. When a predetermined recommended disclosure condition change request operation is input on the player terminal 1500 accessing the disclosure site (YES in step S110), the server system 1100 presents additional recommended disclosure condition candidates on the player terminal 1500 and accepts their selection operation (step S112). For example, on the player terminal 1500, an explanation of the conditions in the additional recommended disclosure condition candidate data 844 is presented and a selection operation icon corresponding to each of the conditions is displayed. The viewing user operates the selection operation icon corresponding to the content they desire to add, 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 and activates the activation information 846 for the additional recommended disclosure condition candidate data 844 of the selected description (step S114), and terminates the recommended disclosure 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, no publication, etc. Replays of Player 2 who have selected "no publication" as their publication restriction setting will in principle be kept private, but if the recommended publication conditions set by the management are met, they will be made public as an exception, with the possibility of identifying the individual minimized.

[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] Therefore, it is possible to appropriately balance the benefits to the entire player community that can be gained by making a replay of a player public, while respecting the personal wishes of the player who does not want to make the 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 about the entire game and the public site. The following will mainly describe the differences from the first embodiment, and components similar to those in the first embodiment will be assigned the same reference numerals as in the first embodiment, and redundant explanations will be omitted.

[0226] 22 is a functional block diagram showing an example of the functional configuration of the player terminal 1500 B. The player terminal 1500 B has a user management unit 202, a game management unit 210 (excluding the matching unit 212), a first disclosure control unit 220, and a second disclosure 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 disclosure 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 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 original data of the game initial setting data 510, highlight scene definition data 520, recommended disclosure condition definition data 540, and precedent record data 800 is managed by the server system 1100B and is updated each time before the game starts.

[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 previous data management unit 252, a data providing unit 254, a condition changing unit 256, and a public site management unit 270.

[0231] The play replay data acquisition control unit 250 controls the acquisition of play replay 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 disclosure condition definition data 540, the previous record data 800, the additional recommended disclosure 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 recommended public condition definition data 540, acquired play reproduction data 750, original previous record data 800, public site data 842, original additional recommended public condition candidate data 844, original activation information 846, and the current date and time 900.

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

[0236] However, before starting the game progress control, the server system 1100B is accessed as needed 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 is executed upon the end of the game.

[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 a manner intermediate between the first and second embodiments. For example, a configuration is possible in which user management and game management are handled by the player terminal 1500, and publication control and publication site management are handled by the server system 1100. In this case, each time the player terminal 1500 updates the play data 700, it transmits the updated content to the server system 1100B, which receives the updated content and stores it as play replay 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 a 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 FIGS. 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 cutout 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 cutout timing list 850. The scene cutout timing list 850 indicates the timing at which scenes are divided when game play is divided into scenes sequentially from the beginning. Specifically, it includes a cutout source play ID 851 and a cutout timing 853 associated with a scene ID 852. The cutout timing 853 stores a range of elapsed time from the start of play, or a range of frame numbers. For example, when the game is divided into scenes every predetermined time (for example, every two minutes) from the start of the game, the cutout timing 853 stores the elapsed time every two minutes in chronological order. The cutout timing 853 of an initialized scene cutout 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, 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 live distribution.

[0244] 26, the server system 1100 stops publishing the gameplay video published for this gameplay after a predetermined publishing period (for example, immediately after, a few minutes later, or at most a few hours), effectively making it a time-limited publication (step S122). If the publishing process (step S100) is realized in a live streaming format, this step can be omitted.

[0245] Next, the server system 1100 integrates the scene-specific play reproduction data 820 obtained in the current game play (step S124), and then determines whether the disclosure restriction settings of player 2 satisfy predetermined setting conditions (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 one 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-publication recommendation conditions is prepared separately by the operator of the publication control system 1000. The content of the definition data of the re-publication recommendation conditions is the same as that of the publication recommendation condition definition data 540, or has higher standards set for the rarity, excellence, and interest of the play content.

[0249] If it is determined that the re-release recommendation conditions are met (YES in step S128), the server system 1100 creates gameplay video data 840 (step S130) and performs the publication 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 play reproduction data 820 and makes it unpublished.

[0250] In this configuration, as gameplay progresses, scenes are extracted in order from the beginning. If Player 2 has set the release restriction setting to "unlimited release" or "restricted release," the scenes will be released one after the other in the order they were extracted. In other words, if you watch the scenes in the order they were released, it will essentially be a live streaming release.

[0251] However, in the case of a play by player 2 whose publication restriction setting is set to "publication prohibited," scenes are processed in the publication prohibition processing in the order in which they were extracted, and only scenes that satisfy the publication recommendation conditions are published sequentially. In this case, if a scene does not satisfy the publication recommendation conditions, that scene will not be published. Therefore, scenes will be published intermittently, 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 will be published one after another in succession. In other words, a pseudo-live broadcast is realized.

[0252] To summarize this configuration, the server system 1100 shifts target portions of consecutive gameplays in chronological order, determines whether the publication restriction settings for the target portions do not satisfy the setting conditions and satisfy the publication recommendation conditions, and if a positive determination is made, can publish at least the replays of the target portions. The replays of the target portions are published as pseudo-live streaming with a timed publication or as live streaming publication.

[0253] As shown in FIG. 28, the second disclosure control unit 230 of the server system 1100 will have a fourth disclosure control unit 239 that controls the disclosure of replays of consecutive game plays including the target portion based on the play reproduction data of the game play after the replay of the target portion is disclosed.

[0254] This embodiment can also be realized based on the second embodiment. Moreover, the present invention can be applied not only to single-player games but also to multiplayer games.

[0255] [Modification] Although the embodiments to which the present invention is applied have 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 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 this 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 these 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 it also creates and initializes individually applied publication restriction setting data that is individually applied to the scene-specific play reproduction data 820 created in conjunction with the selection of highlight scenes (step S26). Specifically, it copies the contents of the publication restriction setting data 720 to Player 2 as is.

[0259] Also, in loop A, instead of step S40, the individually applied 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 met (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 met, and the server system 1100 executes publication prohibition response processing 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 detailed restriction setting being the deletion of personally identifiable elements (step S67).

[0262] When publication prohibition response process D is completed, the server system 1100 returns to before step S41 and repeats loop A again for the same highlight scene. In the second loop A, the individually applied publication restriction setting data for the scene that satisfies the publication recommendation conditions has been changed to something other than "publication prohibited," so the scene will be 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 a team-based multiplayer game, disclosure restriction settings can also be set for each team. In this case, the disclosure restriction settings can be set by a team representative who calls up the setting screen W5 after discussing them separately through chat among the team members.

[0264] (Variation 4) The content of the detailed restriction settings 776 is not limited to the example in the above embodiment. The detailed restriction settings 776 may also include those described as conditions for determining whether or not to allow disclosure (condition description type), such as "allowing someone to appear in a photo, but not allowing them to be large in the photo" or "not allowing the view from your own camera."

[0265] To describe this modified example in detail based on the first embodiment, as shown in FIG. 31, after step S40, the server system 1100 determines whether the applied restriction detail setting 776 includes a condition description type (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 publication described in the restriction detailed settings 776 are met (step S48), and if they are met (YES in step S48), proceed to step S42, and if they are not met (NO in step S48), proceed to step S44.

[0267] If the detailed restriction setting 776 is set to "Allow reflection, but not large reflection," the server system 1100 calculates the size of the player character controlled by player 2 on the screen of the highlight scene and compares it with a predetermined reflection size standard that represents the "large reflection" condition in step S48. Alternatively, the server system 1100 compares the area ratio of the player character to the game screen with a predetermined reflection screen ratio standard that represents the "large reflection" condition to make a judgment. Then, if the "large reflection" condition is not met (YES in step S48), the server system 1100 applies any other detailed restriction setting 776 that has been set and makes the content public. If the "large reflection" condition is met (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; 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 content of the disclosure privilege (step S68; see, for example, FIG. 17) depending on the type of original disclosure restriction setting of player 2. For example, it is preferable to set the content of the disclosure privilege for player 2 who has set "Publication prohibited" to have a higher privilege value than the disclosure privilege for player 2 who has set "Restricted disclosure." By making a difference in the disclosure privilege, it is possible to give a sense of satisfaction to player 2 who has set "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 keywords contained in the chat are set as the disclosure recommendation conditions. 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 the keyword, and if the keyword is included, it is determined that the disclosure recommendation conditions are met. Similarly, if it is desired that the disclosure recommendation conditions be met when a specific object is shown in a highlight scene, dictionary data for image recognition is prepared in association with the disclosure recommendation conditions. In this case, in step S50, it is possible to perform image recognition processing on the highlight scene to determine whether the specific object that satisfies the disclosure recommendation conditions is shown. [Explanation of symbols]

[0273] 2...Player 20...Notice of public disclosure 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...Setting content 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 reproduction 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 disclosure condition candidate data 850...Scene extraction timing list 1000...Publication 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 the game play based on play reproduction data for reproducing a part or all of the game play, 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 set by a player regarding whether or not to restrict disclosure of the replay 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, regardless of the disclosure restriction setting, for the game play for which the disclosure restriction setting does not satisfy the setting condition and the game play satisfies a given disclosure recommendation condition; A computer system comprising:

2. the second disclosure control means includes a display suppression control means for not displaying, during the replay, the identification information of the player who has set the disclosure restriction setting that does not satisfy the setting condition.

10. The computer system of claim 1.

3. the gameplay is a multiplayer gameplay; the publication restriction setting is a setting for each player, The set conditions are conditions 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: 1) the play content satisfies a given rarity condition; 2) the achievement of the game play satisfies a given excellence condition; and 3) the play content satisfies a given interest condition. The 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 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 replay of at least the target portion; A computer system according to any one of claims 1 to 5.

7. the second disclosure control means controls the disclosure of the re-enactment play related to the target portion to a time-limited disclosure or a live streaming disclosure; 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 has been disclosed by the second disclosure control means; 8. The computer system according to claim 6 or 7, further comprising:

9. A computer system that controls the publication of a replay of a game play that reproduces the game play based on play reproduction data for reproducing a part or all of the game play, 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 set by a player regarding whether or not to restrict disclosure of the replay 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 disclosure restriction setting conditions 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 that is the computer system according to any one of claims 1 to 9; A disclosure control system comprising:

Images