Content interaction system and method

Abstract

An entertainment system comprising a content obtaining unit configured to obtain content 400 comprising video of gameplay and a corresponding input log indicating inputs used to perform one or more actions shown in said video of gameplay, a content display unit configured to output the obtained video of gameplay to a user, an input receiving unit configured to receive inputs 420 from the user, via an input device, during the display of the content, an input comparison unit configured to compare the received inputs to the inputs indicated by the input log 430, and an output generation unit configured to generate one or more outputs 440 in dependence upon the results of the comparison of inputs. Also disclosed is a method for generating outputs depending on the comparison of user inputs to an input log.

Description

BACKGROUND OF THE INVENTION Field of the invention This disclosure relates to a content interaction system and method. Description of the Prior Art The "background" description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description which may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present invention. Over the years there has been a consistent increase in the available processing power for providing entertainment for users through applications such as computer gaming. This has led to a corresponding increase in the demands of such applications, as the additional processing power is used to provide high-quality rendering of image content or the like. However, such demands are not able to be met by all devices. Users may often have devices which are older (such as a previous generation of console) or otherwise limited in their performance. For instance, portable devices (such as mobile phones, portable games consoles, and laptops) may have limitations relating to battery consumption or heat production that can make them unsuitable for high-performance processing units. Many users possess at least one of each of high-performance and low-performance devices. The variation in performance capabilities between such devices can lead to frustration if the user is unable to engage with interactive content (such as computer games) on each of their devices in a consistent manner - or in some cases are unable to engage with interactive content on some devices at all. In some cases, it may be possible to overcome such limitations by using a cloud gaming service or the like. This enables the bulk of the processing to be performed remotely, and as such means that the device limitations can be circumvented. However, the requirement of an internet connection (which may not always be available) can cause other issues such as latency affecting responsive gameplay and costly data usage. Another approach that has been adopted is that of the provision of companion applications, which offer a degree of functionality or interactivity that aligns with the primary content. For instance, mini-games may be provided which enable a user to earn rewards that can be redeemed in the associated full game or data about the game may be made available in an encyclopaedic fashion. Producing a new version of a game to make it suitable for another platform can be difficult and timeconsuming for a developer and as such may not be an attractive option. In addition to this, in many cases a game may not be able to be accurately replicated by a device with inferior processing power -for instance, requiring gameplay changes or a significant degradation in graphical quality in order to reduce the processing demands. It is in the context of the above discussion that the present disclosure arises. SUMMARY OF THE INVENTION This disclosure is defined by claim 1. Further respective aspects and features of the disclosure are defined in the appended claims. It is to be understood that both the foregoing general description of the invention and the following detailed description are exemplary, but are not restrictive, of the invention. BRIEF DESCRIPTION OF THE DRAWINGS A more complete appreciation of the disclosure and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein: Figure 1 schematically illustrates an exemplary entertainment system; Figure 2 schematically illustrates an alternative entertainment system; Figure 3 schematically illustrates a content interaction system; Figure 4 schematically illustrates a content interaction method; Figure 5 schematically illustrates an exemplary data package; Figure 6 schematically illustrates an entertainment system; and Figure 7 schematically illustrates a content interaction method. DESCRIPTION OF THE EMBODIMENTS Referring now to the drawings, wherein like reference numerals designate identical or corresponding parts throughout the several views, embodiments of the present disclosure are described. Referring to Figure 1, an example of an entertainment system 10 is a computer or console such as the Sony® PlayStation 5® (PS5). The entertainment system 10 comprises a central processor 20. This may be a single or multi core processor, for example comprising eight cores as in the PS5. The entertainment system also comprises a graphical processing unit or GPU 30. The GPU can be physically separate to the CPU, or integrated with the CPU as a system on a chip (SoC) as in the PS5. The entertainment device also comprises RAM 40, and may either have separate RAM for each of the CPU and GPU, or shared RAM as in the PS5. The or each RAM can be physically separate, or integrated as part of an SoC as in the PS5. Further storage is provided by a disk 50, either as an external or internal hard drive, or as an external solid state drive, or an internal solid state drive as in the PS5. The entertainment device may transmit or receive data via one or more data ports 60, such as a USB port, Ethernet® port, Wi-Fi® port, Bluetooth® port or similar, as appropriate. It may also optionally receive data via an optical drive 70. Audio / visual outputs from the entertainment device are typically provided through one or more A / V ports 90, or through one or more of the wired or wireless data ports 60. Interaction with the system is typically provided using one or more handheld controllers 80, such as the DualSense® controller in the case of the PS5. Where components are not integrated, they may be connected as appropriate either by a dedicated data link or via a bus 100. Figure 2 schematically illustrates an alternative entertainment system; in many cases, this may be a system with reduced processing power than that discussed with reference to Figure 1. Examples of such a system include mobile phones, portable games consoles, laptops, and mobile computing devices such as tablet computers; portability is not essential, however such devices are often provided with reduced processing power than non-portable devices due to concerns such as power consumption and / or heat generation. Further examples of the second entertainment system include older personal computers or legacy devices such as a previous generation of games console. The entertainment system 200 comprises a processing unit 210 which is configured to perform processing on behalf of the system 200. This processing unit 210 may comprise any one or more of CPUs and GPUs so as to realise this functionality; more detailed examples of the processing that may be performed are discussed in more detail below, but this may include tasks such as the processing of inputs and the rendering of image content for display. The system 200 further comprises a display 220 and an input device 230 to enable a user to interact with the system. These may each be provided within a single housing (along with the processing unit 210) such as in the example of a mobile phone with a touch screen input; alternatively, these may be provided separately to one another, such as a dedicated display device and gamepad. The system 200 also comprises a communication interface 240 which can be embodied by any suitable communication means. This may enable any wired or wireless communication as appropriate for the device 200; for instance, a mobile phone may have a communication interface 240 which enables communication with a cellular telecommunication network. Further examples of communications include those discussed with reference to the data port 60 of the system 10 illustrated in Figure 1. Figure 3 schematically illustrates a system 300 which is suitable for implementing the methods described throughout this document. While shown here as three separate units, implementations may utilise a greater number of devices (such as several of either or both of the first and second entertainment systems). Similarly, in some implementations the server 310 or first entertainment system 10 may be omitted in the case that the other of these is used as the sole source of external data by the second entertainment system 200. It is also considered that while each of the units shown may be in direct communication with one another, in some cases the communication may be indirect - such as the first and second entertainment systems 10 / 200 communicating with one another through the server 310, or the second entertainment system 200 communicating with the server 310 via the first entertainment system 10. Figure 4 schematically illustrates a method which may be implemented using the arrangement discussed with reference to Figure 3, or any other suitable arrangement of devices comprising a second entertainment system 200 (as discussed with reference to Figure 2) and a source of content. This method enables devices with a reduced processing capacity or compatibility issues to interact with content in a manner consistent with that in which they interact with the content on a native and / or more powerful device. In other words, a user is able to interact with desired content independent of the device which they are using (as long as basic processing / input / display functionality is provided) without deviating significantly from the source content. In addition to this, a user is able to simulate playing of the game without installing the game - thereby enabling a user to interact with the content with a reduced delay when content is not already installed. It is therefore also not required that a user own a game in order to interact with associated content in this manner, thereby enabling users to share their experience with other users who would otherwise not be able to play. In particular, this method provides a user with video content from a game or other application with which they wish to interact rather than interactive gameplay or the like. This video content is obtained in conjunction with an input log which indicates a sequence of inputs (and associated timings) corresponding to actions performed by the subject of the video. For instance, a video may include a sequence from a fighting game with the input log comprising the inputs provided by the player controlling one of the fighters. A user is then able to provide inputs while watching this video to simulate playing the game, with their inputs being compared to those detailed by the input log and a corresponding output being generated in dependence upon the degree of similarity and / or which differences are apparent between the two sets of inputs being compared. A step 400 comprises obtaining content at the second entertainment system 200; the content may be obtained from the first entertainment system 10 (such as a games console belonging to the user of the second entertainment system 200) and / or from the server 310 which acts as a content database. The content may be obtained via any suitable data connection, such as a wired or wireless network connection or via the internet. As discussed above, the content comprises video content (or content which enables the rendering of an image, such as information about object positions and the like over time) and an input log. An example of such data is described below with reference to Figure 5. In some cases content may be obtained at the time it is to be displayed (such as in response to a user selecting content via an online portal) or a plurality of content items may be obtained at the same time. For instance this could include desired content and content related to that desired content (such as other content in a gameplay sequence), or a plurality of content items forming a single playlist. A step 410 comprises selecting content for display from amongst content items that have been obtained in step 400, and subsequently displaying the selected content at the second entertainment system 200. This content may be selected manually by the user of the second entertainment system 200, assigned by another user (for instance, as a challenge issued by a friend or gaming coach), or selected by the system in dependence upon one or more criteria such as prior user performance or relevance to user gameplay in the corresponding or similar games. A step 420 comprises receiving one or more inputs from the user during the display of the selected content. These inputs may be received from any input device or the like associated with the second entertainment system 200; these may include integrated touch screens, for example, and / or dedicated gamepads. These inputs are expected to be those of the user seeking to replicate particular gameplay, such as an impressive combo in a fighting game, good handling in a tricky segment of a racing game, or a skilled sequence of play in a sports game. In some cases, the user may be shown the content in advance (or otherwise be forewarned as to its contents) so as to enable them to better attempt to approximate the original inputs - however, in some cases the user may not be shown the content in advance so as to determine whether they are able to read the in-game situation and identify the same course of action. A step 430 comprises comparing the received inputs to those contained within the input log that is associated with the selected content. This can include comparing both the identities of inputs (for instance, whether the correct button was pressed or whether the correct magnitude of input was provided) and the timings (whether a button was pressed at the correct time, or held for the correct duration). Tolerances may be applied on a per-content basis so as to account for inputs being functionally equivalent in some games but not others, for example. For instance, in games where only orthogonal motion is allowed there may be greater tolerances on directional inputs as no diagonal inputs are possible. Tolerances may also vary on any other suitable basis, such as which input device is used, the type of game (in that timing may be less important in some games than others), and / or on a per-input basis (in that some inputs and / or their timing may be less important than others). In some cases (such as if a user is providing inputs using a different device to that which was used to generate the content initially) this may require a mapping of the received inputs to those in the input log (or vice versa) to enable a suitable comparison. In some cases this may include modifying tolerances, as some input devices may not allow the same level of precision or ease of use. For instance, a different layout of buttons may mean that a user has to move their thumb a greater distance between inputs and as such this can cause issues with providing inputs with the correct timing. A step 440 comprises generating an output in dependence upon the comparison of step 430. This output may take any of a number of forms, and in some cases the output may comprise multiple component parts. A first example of a component of the output is an indication of the user's performance; this may be provided in any suitable format for providing feedback to the user on how well their inputs matched those of the input log. For instance, a display may be generated which graphically compares the input log associated with the content with a log of the inputs provided by the user. Alternatively, or in addition, a score (such as a percentage) or rank indicating how well the user's inputs matched those in the logs can be provided - this may be an overall score, or different categories may be scored independently (such as scoring each of movement input accuracy, attack input accuracy, and input timing accuracy separately). In some cases, the indication of the user's performance may be a simple 'pass / fail'-style indication without further detail. A second example of a component of the output is that of a suggested course of action for the user. This could include suggestions such as replaying the content to try again, suggesting content that represents a suitable continuation based upon the outcome of the content (for instance, if the first content ends in a goal then a second content could be recommended which requires defending from a kick-off), or playing the full game on another device if it is determined that a user has performed well. A third example of a component is that of generating content for the source game from which the content was obtained. For instance, this can include unlocking new content (such as additional levels or cosmetic items) based upon the user's performance, or generating challenges for the user to complete (such as 'execute the trained manoeuvre in an online game'). In some cases, a log of the content that has been obtained and / or attempted by the user may be kept within the game so as to assess a skill level for matchmaking between players or to otherwise monitor user progression - in such cases, an output may be generated which transmits this content to the user's primary device or otherwise updates the user's profile. A further example is that of predicting an outcome of the content in response to the user's inputs based upon their deviation from the input log associated with the content. For example, in a football game if a user fails to adequately match the input log with their inputs it can be determined whether the user would still score (for instance, due to a weaker shot than shown still being capable of beating the keeper) or whether they would miss (for instance, due to the shot no longer being on target, or allowing a defender to make a tackle or block). This can assist providing a user with more salient feedback, as it can be identified where the mistake was and what the repercussions were - this can also be less frustrating than a blanket 'pass / fail' outcome with no further detail. In response to this prediction, additional content may be recommended. For instance, if a user misses their shot and instead hits the post then content which includes attacking a rebound from the post may be provided to the user. Outputs may be generated in accordance with any one or more of these examples, with other possible outputs also being considered as appropriate. Figure 5 schematically illustrates an exemplary data package that may be used in accordance with implementations of the present disclosure. This may be encoded using any suitable file format for carrying video data and metadata, or non-video data and metadata in implementations in which game data or the like (rather than video data) is transmitted for rendering at the second entertainment system 200. This video content can be platform-agnostic, such that any device with sufficient processing and display capabilities can be used to display the content; it is not required that a particular device type is used, or that the device be able to render full virtual environments and associated physics simulations and the like. While discussed generally in the context of the content being provided to a device for playback, in some implementations it may be considered advantageous that the user device streams video of the content from a cloud-based computing arrangement. While this may aid compatibility with devices, by further reducing the processing requirements, this does introduce the requirement to be online during 7 playback and as such may not be appropriate when an offline experience is required (such as when travelling on an underground rail system). The header data 510 may be used to indicate any properties of the file that are used for decoding the content, for instance. Examples of salient information that may be provided in the header include a file format, file size, and video resolution. Of course, in the case that non-video data is provided this header should be modified accordingly. The video data 520 comprises video footage of a game being played (or other content being interacted with), or sufficient information (such as scripting for a number of objects) to enable such content to be reconstructed into a video. This video may be encoded using any existing suitable encoding scheme, such as MPEG, AVI, or HEVC file formats, or a new encoding scheme that is suited to such an application. The input log 530 comprises information indicating both the identity and timing (within the video data) of a plurality of inputs. This may be provided in any suitable format - for instance, a temporal track comprising a number of events representing specific inputs may be provided. Alternatively, or in addition, the input log may comprise a look-up table or the like which provides information about specific inputs and the corresponding time or times at which they were provided. The metadata 540 may be used to store any additional information that may be required or desired as a part of the content interaction process. For instance, a content source may be identified as well as the identities of any players / player characters associated with the content. The metadata 540 may comprise information identifying related content, or characterisation of the content to assist with the generation of outputs (such as those generated in step 440 of Figure 4). Content for use in the method of Figure 4 and related methods may be generated in any of a number of different ways to provide suitable content to a user; content may be derived from a single source, or may be derived from a number of sources. Examples of content sources are provided below, although these should not be regarded as being limiting - the only requirement is that content and an associated input log can be obtained, and as such the specific content generation process can be determined freely. In some cases the input log may be generated based upon recording inputs at the time of recording the video content, while in other cases the inputs log may be generated through analysis of the video content to identify which inputs were provided and when. In a first example, content may be generated based on a user's own gameplay. For instance, clips of the user's gameplay on a games console can be recorded along with the inputs provided by the user. These clips may be selected on the basis of a user input, or may be selected automatically based upon a particular metric relating to success (such as achieving a better-than-average outcome in a particular scenario, or obtaining a particular in-game award or achievement). The clip and input log can then be used to generate a content file which can be transferred to the second device (such as the user's phone or mobile games console) over a local network, direct data connection, or via an online server. In a second example, content may be generated based upon players associated with the user, such as friends, gaming coaches, or direct opponents. For instance, if a user plays a game with opponents who play well the user may wish to emulate their gameplay so as to improve their own; alternatively, or in addition, friends or gaming coaches may perform a sequence to be used to generate such content to aid a player in improving their skill or as a challenge that can be undertaken. Similarly, content may be generated based upon high-level gameplay, such as footage of professional (or highly-ranked) players or footage from esports tournaments. This may be performed in much the same way as the first two examples, albeit with different players providing the source gameplay. This may be particularly desirable, as not only would the gameplay represent a high skill level (and as such have high training value) but would also be a new way of immersing a user in the viewing experience in a streamlined manner. This is because rather than having to explicitly script an in-game encounter based upon the events, the content can be provided without significant processing burden or latency thereby enabling the content to be interacted with on an almost-live basis. In some cases, the content may not be based upon player performances and instead can be derived from Al-guided gameplay. This can be based upon user prompts to generate desired gameplay from which content can be generated, or may be generated by having Al-controlled characters play against each other and then extracting the 'good' or 'interesting' play from that game to generate content. Of course, 'good' and 'interesting' may be defined in any suitable manner - this may be play with a particularly unique or unusual (compared to other gameplay) sequence of events, or with a particularly good outcome for a particular Al player. It is also possible that the player's own gameplay may be enhanced or modified to generate content. For instance, this can include identifying a player's failure during their own gameplay and then providing an Al agent or the like to adopt the same approach but with an improved outcome. For instance, in a platforming segment in a game a user may fail to make a particular jump; this gameplay can be used to generate content with a modification which completes the failed jump and any subsequent jumps. This can therefore offer a personalised coaching that can be undertaken on any suitable device. In some implementations, real-world events can be a source of content if corresponding games exist. For instance, plays from a professional sports match can be analysed and recreated within a game engine; this recreation can then be used to generate content that can be selected by a user. In some cases, this may be able to be automated by machine learning models which are trained to interpret 9 sports events captured using cameras. In either case, the source data may include player tracking data using GPS or the like, as this can be commonly available in some sports. The use of such a data source can enable a player to import real-world plays into their own gameplay, which can lead to the game providing a more realistic representation of a real sport due to players playing more like those who actually play the sport. A more widespread adoption of real-world playstyles can also lead to a more complete dataset for training Al players of a game, thereby improving the realism of computer-controlled opponents and the like. While the content has been described largely with reference to isolated segments of gameplay, it is also considered that content may be provided in a much more interrelated fashion. For instance, playlists of content may be provided which comprise a predetermined set of content (the set being defined by a player or by a content moderator or the like) based on a theme such as similar plays, highly-rated content, content generated in a particular time period, content from the same player's gameplay, a sequence of events in a game, or any other link between the pieces of content. Of course, no link is required between the content and the playlist may comprise an entirely arbitrary selection of content. Rather than playlists, each piece of content may simply indicate a next piece of content in the metadata 540 as shown in Figure 5. This can enable a simple chaining of content without an overarching data structure which details this. This may be particularly appropriate when obtaining multiple pieces of content which each relate to the same game session or the like, and as such can lend itself to a sequence well. In some implementations, rather than a playlist or sequential grouping of content it is considered that a branching structure may be more appropriate. A branching structure here refers to an arrangement of content into a structure in content is typically linked in a one-to-many manner so as to create a number of possible paths from a single starting point. For instance, a single piece of content may be linked to two or three (or indeed more) pieces of content which follow on from the first piece of content. In some cases the follow-on may be narrative (so as to follow the progression of the represented events over time), but this is not necessary. In this manner, users can simulate a more complete playthrough of events or a portion of a game. In one example of the use of a branching structure, a user may be presented with sequential pieces of content which are selected from amongst a number of linked candidates (that is, the content following the initial content within the branching structure) in dependence upon the user's performance with respect to that initial content. For instance, if the initial content represented gameplay in which the player takes a shot in a football match then the branching can have several pieces of content each representing a different outcome. In this case, the second content can be selected from amongst the 10 candidates based upon the outcomes of 'scored', 'missed', 'hit the post', 'tackled before shooting', and 'shot blocked'. It is not necessary that the subsequent content options are obtained from the same source as the initial content, as narrative consistency may be considered less important to many users during a training process, but instead it may be sufficient that a representative event is present in the content. While in many cases the selection of content for display to a user may be performed arbitrarily, with a random or user-provided selection of content being utilised. However, in some implementations a more purposeful selection of content to be displayed to a user may be performed. In a first example, it may be considered advantageous for a user's gameplay to be analysed to identify weaknesses - this can be determined by identifying user failures, or below-average performance metrics, in respect of particular tasks, for instance. In some cases, a trained machine learning model may be used to identify weaknesses of a user - this may include ranking their performances using a number of different characteristics representing different elements of gameplay (such as passing / shooting / dribbling / defending in a football game, or indeed a more specific approach which breaks these down to more precise component skills). Once identified, content can be selected which enables a user to practice sequences which incorporate those weaknesses. A second example also utilises analysis of the user's gameplay in that it can measure the user's progress through a game. By analysing a user's gameplay it is possible to identify future challenges that a user will encounter - this can enable content to be selected which incorporates skills that are required to overcome those challenges without necessarily comprising those challenges so as to avoid content spoilers. For instance, if it is determined that a user will soon reach a platforming section with tricky jumps, content may be selected from earlier segments (or indeed newly-generated content) which enables a user to practice. The identification of future challenges can also be dependent upon a user's skill level in different areas - for instance, a user that has demonstrated a high level of platforming competency may skip such training. A third example is that of selecting content which comprises counterplays to a user's typical playstyle. This can be content from either perspective (that is, the user facing the counterplay or executing it), or indeed both. This can enable a user to gain experience in a scenario in which they would typically be expected to struggle. A user's playstyle can be classified in any suitable manner, including both preferred actions, sequences of actions, levels of aggression in-game, or any other metric. Figure 6 schematically illustrates an entertainment system in accordance with the exemplary implementations discussed above. This system may be implemented using any suitable arrangement of processing units amongst corresponding devices as appropriate. In some implementations the 11 functionality of these units may be implemented by a single device (such as the device discussed with reference to Figure 2, using the processing unit 210), while in others processing may be performed by other devices in communication with this device. For instance, the input comparison may be performed by an alternative device, such as the server 310 or the device 10 discussed in Figure 3. A content obtaining unit 600 is configured to obtain content comprising video of gameplay and a corresponding input log indicating inputs used to perform one or more actions shown in said video of gameplay. Examples of the format obtained content is discussed with reference to Figure 5. In some implementations the content obtaining unit 600 is configured to stream the video content from another device or server, although it may also be configured to download and store the video content from another device or server in advance of display to the user. In the latter case, this can enable offline access of the content. The obtained content may comprise video of the user's own gameplay and / or the gameplay of other players of a game in some implementations; this can enable a user to revisit content to practice sequences they have already seen or that have occurred in other games. However, as discussed above, other sources of content may also be considered - for instance, the obtained content may comprise video representative of a real-world event which is simulated by a computer game (such as a football match or a driving race, each of which have numerous computer game equivalents). While content may be obtained on an individual basis, it may be more appropriate in some cases to obtain multiple pieces of content at a single time - for instance, when a user has only temporary access to a high-speed internet connection. In such cases, the content obtaining unit 600 may be configured to download a plurality of items of a playlist of content and / or a plurality of items of content which are linked via metadata associated with the content items. This can include sequences of content with a narrative arc, for instance, or content forming a branching structure as discussed above. In some implementations the content obtaining unit 600 can be configured to obtain content in dependence upon analysis of a user's performance in a game from which the gameplay video is derived; for instance, so as to obtain content that enables a user to practice sequences that match tasks that they typically do poorly in. However, any suitable method for selecting which content to be obtained may be considered - user selections, recommendations or challenges from other users, forecasts of a user's future gameplay, and random selections are all examples of approaches to content selection. A content display unit 610 is configured to output the obtained video of gameplay to a user. This may be via any suitable display screen, such as one that is integrated with an entertainment device which is being operated by the user. In some cases, the obtained video may be displayed with an overlaid representation of the input log to assist the user with identifying which inputs correlate with which 12 actions; this may be an optional feature that is provided in response to user requests or in response to a user's poor performance in previous displays of the content. As noted above, in some cases the obtained content does not comprise video but rather comprises data that enables a video to be generated for display. Examples of such data include object positioning data for a virtual environment, or an event log for a sequence of events. In such a case, an appropriate rendering engine or the like may be used by the content display unit 610 to generate the video for display; this may be a reduced version of the original game, for instance, which is able to generate images for display but not compute interactions or in-game physics or the like. An input receiving unit 620 is configured to receive inputs from the user, via an input device (such as a games controller or a touchscreen device), during the display of the content. The inputs provided by the user represent the user 'controlling' a character or the like shown in the video content; of course, the 'controlling' does not comprise actual user control (as the content is a pre-generated video), but instead represents a user's attempts to perform the actions shown in the content. An optional input mapping unit 630 is configured to map the received inputs to an input scheme consistent with the input log, to map the inputs in the input log to an input scheme consistent with the received inputs, or to map both to an alternative input scheme. While this may not be necessary when the input devices are the same for both the content generation and the user inputs, this can be particularly advantageous when the input devices are different. This is because this can enable crossplatform use of content, and the use of entirely different input methods (such as touchscreens instead of a native game controller associated with the device at which the content was generated). In some cases the input mapping may comprise translating inputs (such as 'button X' is equal to 'space bar'); alternatively, or in addition, tolerances may be adjusted such as for the input timing, pressure, and / or direction to account for differences in input devices causing the exact inputs to be more challenging for a user to perform. An input comparison unit 640 is configured to compare the received inputs to the inputs indicated by the input log; of course, in the case that a mapping is performed by the optional input mapping unit 630 the mapped inputs may be used in place of the corresponding set of inputs as appropriate. This can include any suitable assessment of the similarities between the set of received inputs which considers one or both of the identities of the inputs (that is, do the sequences of inputs match) and the timings of the inputs (that is, were inputs provided at the correct time). In the case that both of these are considered, the assessment is more specifically of whether the correct input was provided at the right time, where 'correct' is a determination that the received input matches the inputs indicated in the input log. An output generation unit 650 is configured to generate one or more outputs in dependence upon the results of the comparison of inputs (that is, the comparison of the input log and the received inputs). This output can take any suitable form, from generating information for display to a user to initiating the display of new content. A first example is that of the output generation unit 650 being configured to generate one or more statistics indicative of the similarity between the compared inputs. This can indicate a number of correct inputs that were provided, for example, or any other indicator or metric which indicates how well the input log was simulated by the user. In some cases, this may include a ranking ('gold', 'silver', or 'bronze' medals, for example) or an overall 'pass' or 'fail' designation; alternatively, or in addition, a more detailed breakdown may be provided which indicates successful sections of the input sequence or highlighting particular areas of difficulty. Alternatively, or in addition, the output generation unit 650 may be configured to generate an output indicating a next content to be displayed - in some cases, the output may also cause the next content to be displayed with or without further user input as appropriate for a given implementation. The next content can be determined in a number of ways; for instance, user performance can determine whether the same content should be replayed or whether the next content in a playlist or sequence should be initiated. Similarly, the outcome of the comparison can also be used to determine which branch to take in the case in which a branched structure of content is utilised. The results of the comparison can also be used to determine whether a user requires further practice at a particular task or should move on to a new task, and to select content accordingly. A further example is that of the output generation unit 650 being optionally configured to generate an output comprising one or more elements or modifications for a game from which the video of gameplay is obtained. This may include generating new in-game challenges for a user, for example, or unlocking one or more cosmetic items for use. In some cases, the completion of content by a user (that is, obtaining at least a threshold match between the input log and the received inputs) can lead to progression within a game or an update of the user's profile so as to provide new content to play and / or to modify matchmaking parameters or the like. Another alternative or additional example is that of the output generation unit 650 being configured to generate an output which is indicative of an alternative outcome of the gameplay due to a deviation between the compared inputs. For instance, if a user fails to provide inputs in a timely manner or provides the wrong inputs then an alternative outcome can be predicted - this can be based upon a trained machine learning model which is trained to predict such outcomes (for instance, from training data comprising a range of in-game scenarios and associated input logs to determine correlations between inputs / sequences of inputs and outcomes), or from a look-up table or the like associated with the content that indicates a likely outcome based upon the identified differences between the user's inputs and the input log. The arrangement of Figure 6 is an example of a processor (for example, a GPU, TPU, and / or CPU located in a games console or any other computing device) that is operable to provide an interactive user experience, and in particular is operable to: obtain content comprising video of gameplay and a corresponding input log indicating inputs used to perform one or more actions shown in said video of gameplay; output the obtained video of gameplay to a user; receive inputs from the user, via an input device, during the display of the content; compare the received inputs to the inputs indicated by the input log; and generate one or more outputs in dependence upon the results of the comparison of inputs. Figure 7 schematically illustrates a method in accordance with the above discussion; such a method may be implemented in accordance with the discussion of the entertainment system of Figure 6. A step 700 comprises obtaining content comprising video of gameplay and a corresponding input log indicating inputs used to perform one or more actions shown in said video of gameplay. A step 710 comprises outputting the obtained video of gameplay to a user via a display. A step 720 comprises receiving inputs from the user, via an input device, during the display of the content to the user. An optional step 730 comprises mapping the received inputs to an input scheme consistent with the input log, mapping the inputs in the input log to an input scheme consistent with the received inputs, or mapping both to an alternative input scheme that is consistent with neither the input log nor the received inputs (such as a semantic representation of the inputs, using indicators of the actions such as 'jump' or 'attack' in place of identifying specific button presses or the like). A step 740 comprises comparing the received inputs to the inputs indicated by the input log. A step 750 comprises generating one or more outputs in dependence upon the results of the comparison of inputs (that is, the result of the comparison of the received inputs to the inputs identified by the input log associated with the content). 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 machine-readable storage medium by which such software is provided, are also considered as embodiments of the disclosure. Thus, the foregoing discussion discloses and describes merely exemplary embodiments of the present 5 invention. As will be understood by those skilled in the art, the present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting of the scope of the invention, as well as other claims. The disclosure, including any readily discernible variants of the teachings herein, defines, in part, the scope of the foregoing claim terminology such that no inventive 10 subject matter is dedicated to the public.

Claims

1. An entertainment system comprising:a content obtaining unit configured to obtain content comprising video of gameplay and a corresponding input log indicating inputs used to perform one or more actions shown in said video of gameplay;a content display unit configured to output the obtained video of gameplay to a user;an input receiving unit configured to receive inputs from the user, via an input device, during the display of the content;an input comparison unit configured to compare the received inputs to the inputs indicated by the input log; andan output generation unit configured to generate one or more outputs in dependence upon the results of the comparison of inputs.

2. A system according to claim 1, wherein the content obtaining unit is configured to stream the video content from another device or server.

3. A system according to any preceding claim, wherein the content obtaining unit is configured to download and store the video content from another device or server in advance of display to the user.

4. A system according to claim 3, wherein the content obtaining unit is configured to download a plurality of items of a playlist of content and / or a plurality of items of content which are linked via metadata associated with the content items.

5. A system according to any preceding claim, wherein the output generation unit is configured to generate one or more statistics indicative of the similarity between the compared inputs.

6. A system according to any preceding claim, wherein the output generation unit is configured to generate an output indicating a next content to be displayed.

7. A system according to any preceding claim, wherein the output generation unit is configured to generate an output comprising one or more elements or modifications for a game from which the video of gameplay is obtained.

8. A system according to any preceding claim, wherein the output generation unit is configured to generate an output which is indicative of an alternative outcome of the gameplay due to a deviation between the compared inputs.

9. A system according to any preceding claim, wherein the obtained content comprises video of the user's own gameplay and / or the gameplay of other players of a game.

10. A system according to any preceding claim, wherein the obtained content comprises video representative of a real-world event.

11. A system according to any preceding claim, further comprising an input mapping unit configured to map the received inputs to an input scheme consistent with the input log, to map the inputs in the input log to an input scheme consistent with the received inputs, or to map both to an alternative input scheme.

12. A system according to any preceding claim, wherein the content obtaining unit is configured to obtain content in dependence upon analysis of a user's performance in a game from which the gameplay video is derived.

13. A method comprising the steps of:obtaining content comprising video of gameplay and a corresponding input log indicating inputs used to perform one or more actions shown in said video of gameplay;outputting the obtained video of gameplay to a user;receiving inputs from the user, via an input device, during the display of the content;comparing the received inputs to the inputs indicated by the input log; andgenerating one or more outputs in dependence upon the results of the comparison of inputs.

14. Computer software which, when executed by a computer, causes the computer to carry out the method of claim 13.

15. A non-transitory machine-readable storage medium which stores computer software according to claim 14.

Images