GB2557976A

GB2557976A - Gameplay sharing method and apparatus

Info

Publication number: GB2557976A
Application number: GB1621808.3A
Authority: GB
Inventors: Anderson Mark; Alexander Dinsdale Spencer Hugh
Original assignee: Sony Interactive Entertainment Inc
Current assignee: Sony Interactive Entertainment Inc
Priority date: 2016-12-21
Filing date: 2016-12-21
Publication date: 2018-07-04
Also published as: GB201621808D0

Abstract

In a method for generating gameplay data, game state information is generated for the start of one or more gameplay segments, wherein the one or more gameplay portions together represent a user's gameplay session. Video data corresponding to the gameplay session is generated along with information linking portions of this video replay to corresponding game state information. This linking information may be inserted into the video via stenographic techniques or provided as metadata. The method may provide a rewind function for a user, allowing them to replay parts of a game session without the need to, for example, retry a particular level or reload a save point. Also disclosed are a computer program causing a computer to perform this method, and an apparatus performing the method.

Description

(71) Applicant(s):

Sony Interactive Entertainment Inc.

1-7-1 Konan, Minato-Ku 108-8270, Tokyo, Japan (72) Inventor(s):

Mark Anderson

Hugh Alexander Dinsdaie Spencer (51) INT CL:

A63F13/497 (2014.01) (56) Documents Cited:

US 6699127 A US 20150375102 A1

US 20140194211 A1 US 20140045591 A1

US 20130172086 A1 (58) Field of Search:

INT CL A63F Other: EPODOC, WPI (74) Agent and/or Address for Service:

D Young & Co LLP

120 Holborn, LONDON, EC1N 2DY, United Kingdom (54) Title of the Invention: Gameplay sharing method and apparatus Abstract Title: Method for generating gameplay data (57) In a method for generating gameplay data, game state information is generated for the start of one or more gameplay segments, wherein the one or more gameplay portions together represent a user's gameplay session. Video data corresponding to the gameplay session is generated along with information linking portions of this video replay to corresponding game state information. This linking information may be inserted into the video via stenographic techniques or provided as metadata. The method may provide a rewind function for a user, allowing them to replay parts of a game session without the need to, for example, retry a particular level or reload a save point. Also disclosed are a computer program causing a computer to perform this method, and an apparatus performing the method.

Figure 1

1/4

Figure 1

Figure 2

2/4

Video Content 301

Game State information 302

Video	Game State	Video	Game State	Video	Game State
Content	information	Content	information	Content	information
311	312	311	312	311	312

Figure 3B

Common State information	Video Content	Game State information
321	322	323

Figure 3G

Video Content	Link information
331	332

Figure 3D

3/4

User 1

User 2

User 3

Gameplay Content 3

Gameplay Content 1

Gameplay Content 2

Gameplay Content 4

GameplayContent 5

Figure 4

500

Game Execution		Game State
Unit		Information
		Generator
501		502

Gameplay		Gameplay Video
Segment		Generator
Generator		504
503

Figure 5

600

Video Playback		Game State
Unit		information
		Processor
601		602

Gameplay		Gameplay
Segment		Initiation Unit
Identifier		604
603

Figure 6

GAMEPLAY SHARING METHOD AND APPARATUS

This disclosure relates to a gameplay sharing method and apparatus.

The increase of availability of high-speed internet and video-sharing websites has increased the generation of online content greatly in recent years. In the context of modern gaming, this means that it is common for users to wish to share videos of their gameplay with other users, for example as a means of bragging about achievements or highlighting an amusing moment within a game. Many games have in-game replay systems that cause replays to be generated automatically that may easily be shared, and different tools or applications may exist on an entertainment system to facilitate sharing of such content with prospective viewers. An example of this is the ‘Broadcast Gameplay’ option that is provided by the Sony® PlayStation® 4 which allows gamers to share video of their gameplay.

Recent developments such as this have led to a huge number of videos being uploaded onto popular video-hosting websites, in addition to websites dedicated to allowing game players to stream their gameplay in real-time.

With such content being widely available, many players are inspired to recreate these ingame moments or improve upon the feats that are depicted in them. Traditionally this is achieved via comparing high-scores or the like, but in many game modes this is not appropriate. Recreating a moment in a game in order to improve on another user’s performance may be problematic for users, as often the exact gameplay conditions may be hard to reproduce. It is in view of this that the present invention arises.

This disclosure is defined by claims 1 and 14, with further respective aspects and features of the disclosure being defined in the appended claims.

Embodiments of the disclosure will now be described with reference to the accompanying drawings, in which:

Figure 1 schematically illustrates a method for generating and sharing gameplay content;

Figure 2 schematically illustrates a method for receiving and using gameplay content;

Figures 3A, 3B, 3C and 3D schematically illustrate possible data storage arrangements;

Figure 4 schematically illustrates gameplay content created by a plurality of users;

Figure 5 schematically illustrates an apparatus for generating gameplay content;

Figure 6 schematically illustrates an apparatus for using gameplay content.

Figure 1 schematically illustrates a method for generating gameplay content that may be shared with other users. Gameplay content generated according to this method comprises video content, game state information and information linking the two of these by defining gameplay segments in a video, each gameplay segment beginning with the recording of a new piece of game state information.

A step 100 comprises generating gameplay segments and game state information. This is performed by generating game state information for the start of one or more gameplay segments, wherein the one or more gameplay segments together represent a user’s gameplay session. Game state information describes the conditions in the game, and it is possible to recreate game conditions at a particular point in the gameplay using this information. Game state information may be generated at predefined time intervals or in response to predefined events, each of these intervals or events representing the start of a new gameplay segment.

An example of the use of predefined time intervals is to record the game state every 10 seconds, or any other appropriate timescale so long as game state records are sufficiently granular so as to allow a user to be close to any event in the gameplay by loading the game state information. In such an arrangement, a new gameplay segment is defined after a predetermined amount of time has elapsed.

An example of the use of predefined events is the generating of game state information when approaching a corner in a driving game; of course, any other suitable action or event (such as an attempted overtake in the driving game example) could be used instead. A suitable event or action is something that occurs sufficiently regularly such that the saved game states are regular enough to allow easy access to a particular part of a game, and that the user does not have to perform an action specifically to cause a game state to be recorded. Events that are less common may also be used, and in this case several events may be used as a trigger to store game state information. In such an arrangement, a new gameplay segment is defined in response to an in-game event occurring.

It will be appreciated that a combined approach may be used, where the game state is recorded periodically and also in response to predetermined events. Optionally, where a predetermined event occurs within a threshold period before a periodic record is to be made, then that subsequent periodic record is not made.

Alternatively or in addition to period records and records triggered by in-game events, records could be made responsive to a cumulative amount of user activity. For example a record could be made after the user’s character has been made to travel a distance or after its health level has changed by a threshold amount (both suitable proxies for significant activity). Similarly, a record could be made after a predetermined number of control inputs have been received, so that the record is regular in terms of the amount of user activity between records. Optionally this could be weighted to reduce the effective count for some inputs, or ignore some inputs in the count all together (for example, inputs relating to looking around or looking at an inventory, which may not progress the game as such).

While an increased granularity (a greater frequency of game state recordals/shorter game segments) is advantageous in allowing a user to identify a game state that is closer to an in-game event, it can be disadvantageous in terms of the increased data storage required and increased processing overheads in generating and recording the data. A suitable balance may be made at the discretion of a game designer, and/or by a user via a control interface.

A step 110 comprises generating gameplay video, which is video data corresponding to the gameplay session. This is performed at least partially simultaneously with the step 100, as the generating of gameplay video is continuous during a gameplay session. The gameplay video is recorded either by default, in response to user instruction, an in-game event or any other appropriate indicator that recording of gameplay video should be initiated. The game state information that is generated for the gameplay video describes the game state at the start of each segment of gameplay.

A step 120 comprises linking or associating game state records and the gameplay video, by generating information linking portions of the generated video data to a corresponding record. This may be performed in a number of ways. In one embodiment, the linking information is inserted into the video using steganographic techniques; for example, the steganographic techniques are used to insert a segment ID into the gameplay video at the same point as the gameplay segment begins in the video. The segment ID may be present in each frame, or only a subset of frames. An example of such a method is simply stating the segment ID in a predefined location in the video at all times; however a more well-concealed and/or periodic display of this information may be appropriate so as to not impair the viewing experience of a viewer. The segment ID indicates the corresponding game state record for a section or segment of generated video data, or this may be provided separately. It will be appreciated that gameplay segments are therefore notional sections of the overall game play session that are demarcated by the creation of a game state record during game play. Hence the time at which a game state record is created corresponds to the time of a new gameplay segment in the video of the game play session.

It should be appreciated that any number of suitable methods of linking a gameplay segment to a gameplay video could be used instead of the steganographic technique described above. For example, the linking information may be provided as metadata embedded in the video data or provided in an associated metadata file for the video that identifies each segment and its start time with respect to the elapsed time in the gameplay video. Alternatively, or in addition, the gameplay video may comprise a plurality of watermarks that may be used to identify a gameplay segment for a particular portion of the gameplay video.

It will be appreciated that steps 100 and 110 may occur in either order prior to linking (e.g. the video may be created first, and then the segment subsequently defined and game state information associated with the video).

A step 130 comprises the distribution of content to other users. This may comprise the upload of the gameplay video and associated segment data to a server such that other users may access and view the gameplay video, and acquire game state information from the associated segment data. The content may also be stored on local or removable storage media, or sent to a particular user, rather than uploading it to a server.

The method of Figure 1 may be performed on a ‘live’ basis, in which game state information is recorded and uploaded as the user plays the game; this may be particularly suitable for gamers who broadcast their gameplay live, or for cloud-based game streaming applications. Alternatively, or in addition, the game state information may be recorded in real time, but not uploaded until the conclusion of a gameplay session. The latter may be advantageous to a user, as it reduces the processing burden during gameplay. If each of these approaches is performed for the same content, the game state information that is uploaded at the conclusion of the session may be in a different format so as to reduce storage requirements or the like (as is discussed below).

It is also envisaged that the method of Figure 1 may be suitable for generating a more interactive leaderboard for a particular game. Videos of user’s attempts at a portion of a game (which could span any number of segments) could be uploaded along with their score (or any other measure of attainment), and any other user could then access the game state information for a particular segment of any of these high-scoring attempts in order to improve upon the scores. This could therefore drive competition more fiercely, as it provides a more direct way to compete in both single-player and multiplayer games.

Figure 2 schematically illustrates a method for acquiring and using gameplay content generated according to the method of Figure 1.

A step 200 comprises receiving content that has been generated using a method according to that shown in Figure 1. As noted above, this content comprises at least gameplay video and game state information for a number of gameplay segments.

A step 210 comprises initiating playback of video data at the user’s device. The video playback may be provided with an indicator (such as an on-screen marker) that game state information is available for use, so that a user is encouraged to play the game content themselves, or at least notified of the possibility to do so. Information could also be provided to the user to indicate the start of a new gameplay segment, or indicate a time elapsed since the last change in gameplay segment. This may be desirable in that a user is able to determine how much gameplay they would have to re-play in order to reach the events currently shown in the gameplay video. Hence for example an indicator might be shown at the start of a segment for a predetermined number of seconds, since the start of a segment is when the video will most closely correspond to the game state saved at the start of that segment.

In some embodiments, information about the availability of game state information may be provided with the video content (for example, in an associated metadata file). This could be provided on a per-video-content basis, or on a per-segment basis. Alternatively, or in addition, information about the game state information could be generated by the playback (or other) device either before or after the initiation of the video playback.

The user may be presented with information about the availability of game state information for video content at any suitable time; for example, prior to playback (such as with a notification or by stating that the video is the correct type to allow game state information to be accessed), during playback (such as with an on-screen marker), or even after playback so as to not interrupt a user’s viewing experience (but upon notification, the user could re-watch the content knowing that the game state information is present and thus make use of the game state information to play game content).

A step 220 comprises receiving an indication of a desire to begin gameplay. An indication of a desire to begin gameplay is based upon some form of input from a user; for example, a button press, hand gesture or audio input depending on the game-playing arrangement. Alternatively, or in addition, a user could define in-game events that could act as a trigger; for example, in a football game, when a player in the gameplay video has a shot that misses the goal, the most recent game state information is loaded automatically so that the user can try and score a goal in the same scenario. Optionally game state data, particularly when recorded in response to an event, may comprise a success or failure indicator (based on suitable in-game criteria) to facilitate subsequent filtering or detection of such events by viewers. Hence a ‘goal’ event is flagged as a success, whereas a goalkeeper save or corner kick event is flagged as a failure as it implies a goal was tried for and missed. In these cases, the game save for the preceding segment may be loaded. Alternatively, event evaluation indicators could be saved separately to (and for example at a higher frequency than) full game state recordings in response to events. Optionally this could also be used where the game state recording is periodic, but the ability to scan for significant events is also desired. It will be appreciated that such event and event outcome indicators would be much smaller than a game state record, and hence impose less of a processing and storage burden.

A step 230 comprises identifying game state information associated with the currently displayed segment of video content (that is to say, the gameplay segment corresponding to the gameplay video that is being viewed at the time of receiving the indication of a desire to begin gameplay). This may be performed in a number of different manners, depending on how the links between gameplay segments and video content are indicated, so long as a gameplay segment that corresponds to the currently-viewed part of the video content when an indication of a desire to begin gameplay is received from a viewer of the video data is identified.

In one example, the step 230 comprises examining metadata associated with the gameplay video that lists a gameplay segment ID for each time in the video content, the gameplay segment information being used to locate game state information. In another example, processing may be performed to identify the segment IDs from the gameplay video if the segment ID is present in every frame, or for each group of pictures (GOP). In another example, the game play segment ID is provided as metadata for the frame or GOP corresponding to the start of the next segment, and this ID is stored until a new ID is encountered. Alternatively, when segment data is requested the processor may examine previously-viewed content in order to locate the last frame that displayed a segment ID and then identify the segment ID.

A step 240 comprises the initiation of gameplay using game state information that is identified in step 230. In one embodiment, this comprises the acquiring of the game state information (for example, downloading from a server) and initiating a related game application. The application is then provided with the game state information so as to launch a new game with the variables described in the game state information (such as teams, players, scores and locations of players for a sports game).

If desired by the user, the gameplay initiated by the method of Figure 2 could be used to generate gameplay data according to the method of Figure 1. The recorded gameplay video could be inserted into the original video to replace the segment that was played, and uploaded or stored as a new video; alternatively, it could be appended to the viewed video content corresponding to gameplay before the played segment. This may therefore create a ‘feedback loop’ of content creation, in which the creation of content by users encourages the creation of content by other users that in turn may encourage the original (or another) user to create more content. Of course, this newly-recorded gameplay video could be provided not in the context of the original gameplay video and instead as standalone gameplay video.

The method of Figure 2 could of course be applied to a user’s own previously-created content, not just downloaded content of another user’s gameplay. This would allow a user to revisit their past gameplay and try to improve upon specific gameplay segments and practice the same segment repeatedly. This may be more useful to a user than an alternative arrangement, such as a ‘ghost’ function used in some games (for example, racing games) in which allows a user to compete against an in-game avatar that replicates a past attempt at a level in order to track improvement; this is because individual segments are able to be replayed, rather than having to compare performance over a whole level.

In this way a ‘rewind’ function is provided for an individual, allowing a user to replay segments of a game session, optionally without losing any game data; in many gaming applications it is only possible to either retry a particular level, or reload a save point. The first of these alternatives is not a replaying of a segment, and may result in a different game state on each attempt due to the player not performing identical actions throughout the level each time. The latter of the alternatives means that any progress between the save point and the current time is lost; this is because newer save data often replaces earlier save data. As such, neither of these provides the functionality of the arrangement described in this disclosure. Moreover, this rewind function allows the user to visually review the gameplay to find the desired point at which they wish to recommence play, and then the closest (optionally closest previous) recorded game state record is accessed to resume the game. This creates an intuitive means of identifying and replaying a particular part of a game.

In some embodiments, game assets may be provided with the game state information or the gameplay video. Such game assets could be provided so as to enable a user that does not own the game being played to play a segment (or multiple segments) of the game; alternatively, game assets corresponding to non-standard game content (such as any mods or custom assets) may be provided so as to enable a user who does own the game to play a segment even if they don’t otherwise have all of the assets available. For example, if a user of a receiving device doesn’t own the game, then game assets may be included with the game state information, or may be requested using the game state information (which may describe the required assets or indicate a file to be downloaded that comprises the required assets).

A user may be restricted in interactions with a gameplay video if they do not own the game shown; for example, a user may only be able to play segments associated with a particular game mode or portion of a game, or only able to play a predetermined number of segments. This therefore allows a user to still have some interaction, encouraging them to purchase the game content so as to be able to interact with a larger portion of the uploaded content.

It would be appreciated that there are a plurality of methods of storing the information generated by the method of Figure 1. A selection of exemplary methods for storing content are discussed below with reference to Figures 3A-3D. The provision of segment ID information is not discussed below, although it would be apparent from the above discussion that this could be provided as metadata in the stream or be inserted into the video content for example.

The format that is used may be dependent upon or determined by the content source device or the content-receiving device, and may be selected in response to other factors such as whether or not a particular user owns that game shown in the video content, or the current availability of local storage space on a user’s device. For example, the content source device could package information in a predetermined or user-selected manner; alternatively, or in addition, the raw data could be uploaded to a server that packages the information in a suitable manner for the content-receiving device.

Figure 3A schematically illustrates a format in which all video content 301 is supplied before any game state information 302; this may be more suitable for embodiments in which a user downloads all content before video playback begins.

Figure 3B schematically illustrates an arrangement in which video content 311 and game state information 312 are supplied alternately; this may be in any appropriate division, although on a per-segment basis may be more appropriate in this arrangement as switching between content types transferred could create overheads or impair transmission in view of size constraints for data blocks or the like. While it is shown that the video content 311 is transmitted before the game state information 312, it may be advantageous that the game state information is transmitted before the video to reduce the delay between indicating a desire to play a segment and beginning gameplay.

Figure 3C schematically illustrates an arrangement in which common state data 321 is provided to a device before the video content 322 and game state information 323. As noted with reference to Figure 3B, the order of the video content 322 and game state information 323 may be reversed when transmitting the content.

Common state data 321 comprises data that is relevant to at least a subset of the numerous pieces of game state information describing the game state at different times; for example, if the gameplay content relates a sports game then variables such as ‘teams’, ‘venue’ and ‘weather conditions’ might be constant throughout a portion of the gameplay and therefore it would be more efficient to transmit this information only once for a given portion of gameplay. By providing this information separately, it is not required to provide this information as part of the game state information 323; the game state information 323 may therefore be limited to information about the state of play, such as player and ball positions, and game score. Thus more generally, game state information may provide an initial complete description of the game state, and then provide only a differential description of the game state for successive game segments with respect to that complete game state, or an incremental description with respect to the last game state. Complete game states may then be provided at a lower frequency of occurrence than differential or incremental game states.

Common state data 321 could therefore be re-transmitted or updated at the start of each stage in the game (or in response to any other in-game event which causes a change in the common state data 321). Providing common state data 321 means that the game state information 323 may be reduced in size, as well as reducing the amount of data required for storing the whole of the content as common information is not always stored multiple times.

The use of common state data 321 may thus provide an arrangement in which the game state information comprises a file that contains one or more variables representing at least a portion of the gameplay session such that the variables do not have to be present in each piece of game state information

Figure 3D schematically illustrates an arrangement in which video content 331 is provided with link information 332. It would be apparent to the skilled person that the link information 332 could instead be sent before the video content 331. Also, the video content 331 and link information 332 could be sent in a comparative manner to that of Figure 3B in which the two are interleaved.

The link information 332 may comprise information linking the video content to gameplay segments and game state information, as well as providing information to enable the location of the appropriate game state information at a given time in the video content. An example of this is using time stamps to define segment boundaries, and then providing a link to locate the game state information corresponding to the segment on a server or other storage medium. Transmitting link information 332 instead of game state information may be advantageous in that the data requirements for the stream are reduced, and there may be a reduction in unused data being transmitted as only game state information to be used is downloaded. Optionally, link information for a next segment may be included with a current segment, so that the corresponding game state data can be downloaded by the time the corresponding section of video is playing.

As was noted previously, game assets for playing a segment of the gameplay session may be included in the gameplay data, or the game files required for playing the segment may be indicated in the gameplay data. For example, this could include game files so as to allow a user that does not own a specific game to still play at least a segment of the game. Alternatively, or in addition, such information could be available on a server and the game state information could be sufficiently detailed so as to allow for a download of the appropriate content to the receiving device to be performed; a combination of the two could be provided such that some data is provided with the video content and other data must be downloaded in addition.

The information storage formats described with reference to Figures 3A, 3B, 3C and 3D are of course only illustrative and not intended to be limiting. It would be apparent to the skilled person that any suitable combination of common state information, video content, game state information and/or link information could be provided in any suitable order. It would also be apparent that these could be combined in a number of different manners; for example, game state information and link information could be provided in a single file, or video content and link information could be provided together.

Figure 4 is a schematic illustration of modifications to a piece of uploaded gameplay content. Depending on a user’s settings, such modifications (replays) of content may be performed by any other user, or only a subset of users (such as users that appear on their friends list).

User 1 creates and uploads gameplay content 1, which is a video associated with game states I segments created in accordance with techniques previously described herein. This game play content 1 is viewed by users 2 and 3. Users 2 and 3 are thus able to obtain game state information in order to replay segments of gameplay content 1, and in turn create (and upload) gameplay contents 2 and 3 respectively. Users 2 and 3 may replay different segments of gameplay content 1, such that gameplay contents may contain different amounts of the original gameplay as well as different performance in the replayed segments. User 1 may be notified of these replays by users 2 and 3, such that the user is kept informed of improvements (or attempted improvements) to their gameplay by other users.

User 3 may then view and replay gameplay content 2, by obtaining game state information for a particular segment of gameplay content 2; this may occur, for example, in view of the fact that user 2 may have improved upon a different part of user 1’s gameplay to that of user 3 and user 3 believes that a combination of these improvements would provide a better overall score.

Gameplay content 4 is created as a result of replay of gameplay content 2 by user 3, and may comprise mostly contributions of user 1, or any other level of contribution through to none at all; for example, if user 2 improved the first half of the gameplay and user 3 improved the second half then the original gameplay of user 1 would be entirely lost. Similarly, gameplay content 4 may not comprise any of the gameplay of user 2 either if user 3 has replayed the same segments as user 2. In view of this, each gameplay segment may comprise information to identify the user that created that gameplay segment; this information may be provided by a watermark or in metadata or the like.

In this example, user 1 may view gameplay content 4 and not want to feel outdone; user 1 then obtains the game state information for segments of gameplay content 4 and replays any number of gameplay segments, creating gameplay content 5. Such a process of improvement upon segments of uploaded gameplay may continue indefinitely between the users.

In an embodiment in which the device receiving the gameplay content is different to the original device, several options are possible.

Firstly, for devices that are roughly equivalent and for which a substantially similar version of the game has been released (for example different consoles of a similar generation and/or PCs), then the game state records may utilise a common data format and be crosscompatible. This would, for example, allow any user of such a console or PC to access the same uploaded video and potentially play the game.

Secondly, it is envisioned that the game state information could be interpreted to provide a different experience for the user of the receiving device, for example when a game is developed for both a games console and a portable device, and as such it may be impossible to exactly recreate a game state. In such an arrangement, it may be possible for the portable io device to simply approximate the game state recorded in the video using the acquired information. Alternatively, or in addition, game state information may be converted to a suitable format before downloading.

If gameplay video is uploaded from the portable device (and thus generated by a portable version of the game), it may be associated with game state information that describes the game state with respect to the portable version of the game. Alternatively, or in addition, game state information describing an equivalent game state in the full (console) version of the game may be uploaded in association with the gameplay video. The latter of these is an example of a method in which game state information is converted into information that is usable by a different application than that used to generate the initial game content.

Thirdly, it is envisioned that the game state information could be interpreted to provide a gaming experience for a user of a device for which no current version of the game is provided, or who simply does not own the game (for example, where the game assets necessary to play the game are undesirably large to download in order to play a limited game session). In this case, a compatible video viewing app distinct form the original game may obtain the game state information in any one of the ways described previously herein and, in response to a user request to play the game from a certain point, send a request to a cloud gaming service to start the game using the indicated game state information, and to stream the ensuing game play to the user. Thus for example a user of a mobile phone or smart TV may be able to play the game from the selected game state, optionally subject to any permissions or restrictions as described previously for non-owners of games. It will be appreciated that such a compatible video viewing app may thus be provided by a cloud gaming service to instigate play of any supported game that the user happens to see when using videos created according to the techniques described herein.

In some embodiments, the gameplay video is instead replaced by video of a real event; for example, a football match. It is possible that ‘game state information’ could be provided for a real football match (either generated by a computer based upon video or other data, or generated by a human operator viewing the match, for example) that would allow the match conditions to be reproduced in a corresponding game. The ‘game state information’ in this example would be ‘match information’, and comprise enough information to reproduce the match state within a game; examples of the match information include the score, players that are on the pitch, the position of the players, teams playing, location of the ball, time elapsed, match attendance, weather conditions, and the venue ofthe match.

Figure 5 schematically illustrates a processing apparatus 500 for implementing a method for sharing gameplay content. The processing apparatus comprises a game execution unit 501, a game state information generator 502, a game segment generator 503 and a gameplay video generator 504. Further functional modules, such as for providing connectivity to a network, have been omitted but would be obvious to provide in view of the present disclosure.

The game execution unit 501 is operable to perform processing related to the execution of a game in order to generate an output for a display. This functional unit could comprise a CPU and a GPU, for example, which are operable to convert user inputs into in-game actions that are subsequently displayed to the user via a display.

The game state information generator 502 is operable to generate game state information for the start of one or more segments of gameplay. This function is performed in response to information about the start of each gameplay segment provided by the gameplay segment generator 503.

The gameplay segment generator 503 is operable to generate information linking portions of generated video data to a corresponding gameplay segment. The gameplay segment generator 503 is further operable to generate information about the segmenting of gameplay, and provide this information to the game state information generator 502 so as to cause game state information to be recorded for the start of each segment.

The gameplay segment information is also used by the gameplay video generator 504 in at least an embodiment in which the gameplay segment information is steganographically inserted into the gameplay video. The gameplay segment generator may also be used to generate link information, or any other information that is used to identify a gameplay segment or appropriate game state information from the video content.

The gameplay video generator 504 is operable to generate video data corresponding to the gameplay of a user. This content is then stored along with the game state information and gameplay segment information, for example on a server.

Figure 6 schematically illustrates a processing apparatus 600 that is operable to receive and use gameplay content as has been described above. This comprises a video playback unit 601, a game state information processor 602, a gameplay segment identifier 603 and a gameplay initiation unit 604.

The video playback unit 601 is operable to initiate playback of video data, such as the gameplay video generated by a device according to Figure 5. When viewing this gameplay content, a user of the processing apparatus 600 is able to provide an input to indicate a desire to being gameplay.

The game state information processor 602 is operable to identify game state information associated with the displayed segment of video content. The game state information processor

602 is further operable to obtain the game state information from the received content, selecting game state information corresponding to a gameplay segment as identified by the gameplay segment identifier 603.

The gameplay segment identifier 603 is operable to identify a gameplay segment that corresponds to a currently-viewed part of the video content when an indication of a desire to begin gameplay is received from a viewer of the video data. As noted above, this could be performed using link information associated with the video content, or by identifying steganographic markers in the video.

The gameplay initiation unit 604 is operable to initiate gameplay in accordance with the identified game state information identified by the game state information processor 602.

In some embodiments, the processing apparatuses 500 and 600 are in fact the same device; this is useful when the video content is stored locally, or when multiple users share a single games console or the like.

The techniques described above may be implemented in hardware, software or combinations of the two. In the case that a software-controlled data processing apparatus is employed to implement one or more features of the embodiments, it will be appreciated that such software, and a storage or transmission medium such as a non-transitory machine15 readable storage medium by which such software is provided, are also considered as embodiments of the disclosure.

Claims

Claims:

1. A method for generating gameplay data, the method comprising:

generating respective game state information for the start of one or more of gameplay segments, wherein the one or more gameplay segments together represent a user’s gameplay session;

generating video data corresponding to the gameplay session; and generating information linking portions of the generated video data to corresponding game state information.

2. A method according to claim 1, wherein a new gameplay segment is defined in response to one or more selected from the list consisting of:

i. a predetermined amount of time having elapsed;

ii an in-game event occurring; and iii. a predetermined number of user inputs occurring.

3. A method according to claim 1, wherein the linking information is inserted into the video using steganographic techniques.

4. A method according to claim 1, wherein the linking information is provided as metadata.

5. A method according to claim 1, wherein the game state information is uploaded to a server.

6. A method according to claim 1, wherein each gameplay segment comprises information to identify the user that created that gameplay segment.

7. A method according to claim 1, wherein the game state information comprises a file that contains one or more variables representing at least a portion of the gameplay session such that the variables do not have to be present in each piece of game state information.

8. A method according to claim 1, wherein game assets for playing a segment of the gameplay session are included with the gameplay data, or the game files required for playing the segment are indicated in the gameplay data.

9. A method for utilising gameplay data generated according to the method of claim 1, the method comprising:

initiating playback of video data;

identifying a gameplay segment that corresponds to a currently-viewed part of the video content when an indication of a desire to begin gameplay is received from a viewer of the video data;

identifying game state information associated with the gameplay segment; and initiating gameplay in accordance with the identified game state information.

10. A method according to claim 9, wherein the gameplay initiated with the identified game state information is in turn used to generate gameplay data using a method according to claim 1.

11. A method according to claim 9, wherein game state information is converted into information that is usable by a different application than that used to generate the initial game content.

12. A method according to claim 9, wherein game state information is used to request initiation of a cloud-based game session for streaming to a different application than that used to generate the initial game content.

13. A computer program which, when executed by a computer, causes a computer to perform the method of any of the preceding claims.

14. An apparatus for generating gameplay data, the apparatus comprising:

a game state information generator operable to generate respective game state information for the start of one or more gameplay segments;

a gameplay video generator operable to generate video data corresponding to the gameplay of a user; and a gameplay segment generator operable to generate information linking portions of the generated video data to corresponding game state information.

15. An apparatus for utilising gameplay data generated by an apparatus according to claim 14, the apparatus comprising:

a video playback unit operable to initiate playback of video data;

a gameplay segment identifier operable to identify a gameplay segment that corresponds to a currently-viewed part of the video content when an indication of a desire to begin gameplay is received from a viewer of the video data;

a game state information processor operable to identify game state information associated with the displayed segment of video content; and a gameplay initiation unit operable to initiate gameplay in accordance with the identified game state information.

Intellectual

Property

Office