Adaptive Difficulty Calibration for Skill-Based Activities in a Virtual Environment

Abstract

The method of the present disclosure can collect data when determining whether to change the difficulty level of a game when a user plays one or more different types of games. 【Solution means】The collected data can be evaluated to identify whether the user game performance level corresponds to the expected performance level. If the user game performance level does not correspond to the expected performance level, the parameter for changing the game difficulty can be automatically changed. Parameters related to movement speed, lag or hesitation, character strength, number of opponents, or other metrics can be incrementally changed until the current user performance level corresponds to the expected level of the specific user currently playing the game. At this time, the expected level of the user can be changed, and as the user's skills improve over time, the process can be repeated.

Description

Technical Field

[0001] 1. Field of the Disclosure: The present disclosure generally relates to adjusting the difficulty level of a game based on skills associated with a user. More particularly, the present disclosure is directed to improving user satisfaction by calibrating an interactive session across specific skills of a particular user.

Background Art

[0002] 2. Description of Related Art: In recent years, the technical field of computer games has come to include many different types of games and many different types of game devices. Generally, computer games have different fixed difficulty levels. These difficulty levels may include a beginner level, an intermediate level, and an advanced level, and each level often presents the user with greater challenges related to the theme of the game. For example, in the case of a first-person shooting game, the user's character typically battles characters moving within a battle space, during which the user attempts to shoot each adversarial character in order to achieve the game's objective. Here, the lower the level of difficulty, the fewer adversarial characters are included, and the characters may move more slowly, while the higher the level, the more adversarial characters are included, and the characters may move more quickly. Higher-level games operate with a higher level of proficiency and may include adversarial characters that are more difficult to damage compared to those associated with lower-level games.

[0003] When the game level transitions from one level to another (e.g., from an intermediate level to a high level), due to the challenges presented to the user, a user who performs very well at the intermediate difficulty level may experience a significant drop in performance at the high difficulty level. Since the difficulty levels of today's games are fixed, a user who was enjoying playing the game at a certain level may not be able to enjoy the game as much at a higher difficulty. In some cases, a certain difficulty level may be judged by the user to be too easy, while the next level may be judged by the user to be too difficult. Furthermore, a user may have accumulated advanced skills and experience in one type of challenge, but may lack skills and experience in another type of challenge, and both may be included in the same game or the same session. Therefore, if the difficulty is high, there is a possibility that the user may not be able to compete regarding the lacking skills, while if the difficulty is low, few challenges are presented. In such cases, the user may simply stop playing the game due to a combination of boredom and frustration.

[0004] What is needed is a new method that can dynamically adjust the difficulty of the interactive session according to the user's current capabilities and change the difficulty as the user's capabilities change over time. SUMMARY OF THE INVENTION

[0005] The presently claimed invention relates to a method, non-transitory computer-readable storage medium, or apparatus that performs a function consistent with the present disclosure to assist in improving the performance of a user when playing a game. In a first embodiment, the method consistent with the present disclosure may include the steps of identifying a user performance level based on an analysis of collected game performance data, comparing the user performance level to a user-expected level, identifying, based on the comparison, that the user performance level does not correspond to the user-expected level, and selecting and updating a game difficulty parameter based on the game difficulty parameter being associated with changing the user performance level. Thereafter, the game difficulty parameter may be updated, and then the user may continue to play the game. The method may also include identifying that an updated user performance level corresponds to the user-expected level based on an analysis of additional game performance data, where the additional game performance data is collected after the update of the game difficulty parameter.

[0006] In the second embodiment, the method as actually claimed may be implemented as a non - transitory computer - readable storage medium on which a processor executes instructions. Again, the method may include the steps of identifying a user performance level based on an analysis of collected game performance data, comparing the user performance level with a user - expected level, identifying, based on the comparison, that the user performance level does not correspond to the user - expected level, selecting and updating a game difficulty parameter based on the fact that the game difficulty parameter is associated with changing the user performance level. Thereafter, the game difficulty parameter may be updated, and then the user may continue to play the game. The method may also include identifying that an updated user performance level corresponds to the user - expected level based on an analysis of additional game performance data, where the additional game performance data is collected after the update of the game difficulty parameter.

Brief Description of the Drawings

[0007]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Best Mode for Carrying Out the Invention

[0008] The method of the present disclosure can collect data when determining whether to change the difficulty level of a game when a user plays one or more different types of games. The collected data can be evaluated to identify whether the user game performance level corresponds to the expected performance level. If the user game performance level does not correspond to the expected performance level, the parameter for changing the game difficulty can be automatically changed. Parameters related to movement speed, lag or hesitation, character strength, number of opponents, or other metrics can be incrementally changed until the current user performance level corresponds to the expected level of the specific user currently playing the game. At this time, the expected level of the user can be changed, and as the user's skills improve over time, the process can be repeated.

[0009] FIG. 1 shows a network environment in which a system for a computer game can be implemented. The network environment 100 can include one or more interactive content servers 110 that provide streaming content (e.g., interactive video, podcasts, etc.), one or more platform servers 120, one or more user devices 130, and one or more databases 140.

[0010] The interactive content server 110 can maintain, stream, and host interactive media that is available for streaming on the user device 130 via a communication network. Such an interactive content server 110 can be implemented in a cloud (e.g., one or more cloud servers). Each media can include one or more object data sets that are available for user participation (e.g., display of activities or interaction with activities). Data regarding objects shown in the media can be stored in an object file 216 (“object file”) by the media streaming server 110, the platform server 120, and / or the user device 130, as discussed in detail with respect to FIGS. 2A and 3.

[0011] The platform server 120 can be capable of communicating with different interactive content servers 110, databases 140, and user devices 130. Such a platform server 120 can be implemented in one or more cloud servers. The streaming server 110 can communicate with multiple platform servers 120, although the media streaming server 110 may be implemented in one or more platform servers 120. Also, the platform server 120 can execute instructions such as receiving user requests to stream, for example, streaming media (i.e., games, activities, videos, podcasts, user-generated content (“UGC”), publisher content, etc.) and computer games. The platform server 120 can further execute instructions for streaming, for example, streaming media content titles. Such streaming media can have at least one object set associated with at least a portion of the streaming media. Each set of object data can have data regarding objects displayed among at least a portion of the streaming media (e.g., activity information, zone information, actor information, mechanic information, game media information, etc.).

[0012] Streaming media and at least one associated object data set can be provided by an application programming interface (API) 160, whereby various types of media streaming servers 110 can communicate with different platform servers 120 and different user devices 130. The API 160 can be specific to the particular computer programming language, operating system, protocol, etc. of the media streaming server 110 that provides the streaming media content title, the platform server 120 that provides the media and at least one associated set of object data, and the user device 130 that receives the object data. In a network environment 100 that includes multiple different types of media streaming servers 110 (or platform servers 120 or user devices 130), there can similarly be a corresponding number of API 160s.

[0013] The user device 130 may include multiple different types of computing devices. For example, the user device 130 may include any number of different gaming consoles, mobile devices, laptops, and desktops. In another example, the user device 130 may be implemented in the cloud (e.g., one or more cloud servers). Also, such a user device 130 may be, but is not limited to, a memory card or a disk drive appropriate for downloaded services, and may be configured to access data from other storage media. Such a device 130 may include standard hardware computing components such as, but not limited to, a network interface, a media interface, a non-transitory computer-readable storage device (memory), and a processor that executes instructions that may be stored in the memory. These user devices 130 may also be executed using various different operating systems (e.g., iOS®, Android®), applications, or computing languages (e.g., C++®, JavaScript®). An example of the user device 130 is a computer gaming console.

[0014] Database 140 can be stored in platform server 120, in media streaming server 110, in any of servers 218 (shown in FIG. 2A), in the same server, in different servers, in a single server, across different servers, or in any of user devices 130. Such a database 140 can store a set of streaming media and / or related object data. Such streaming media can depict one or more objects (e.g., activities) in which a user can participate, and / or UGC (e.g., screenshots, videos, interpretations, mashups, etc.) created by a publisher of a media content title and / or a third-party publisher. Such UGC can include metadata for searching such UGC. Such UGC can also include information about the media and / or peers. Such peer information can be derived from data collected during peer interaction with an object of an interactive content title (e.g., video game, interactive book, etc.), can be "bound" to the UGC, and can be stored with the UGC. Such binding can extend the UGC because it can enable the UGC to deep link (e.g., directly initiate) to an object, provide information about the object and / or peers of the UGC, and / or enable a user to interact with the UGC. One or more user profiles can also be stored in database 140. Each user profile can include information about the user (e.g., activities and / or user progress within a media content title, user ID, user's game character, etc.) and can be associated with the media.

[0015] FIG. 2 shows an exemplary general-purpose data system and a Unified Data System (UDS) that can be used to provide data to a system for updating the functionality of a gaming device. Based on the data provided by the UDS, the game server can recognize in-game objects, entities, activities, and events that a user has participated in, and thus support the analysis and adjustment of in-game activities. Each user interaction can be associated with metadata such as the type of in-game interaction, the location within the in-game environment, the point in time within the in-game timeline, and other players, objects, entities, etc. involved. Thus, the metadata can track any of the various user interactions that may occur during a game session, including related activities, entities, settings, results, actions, effects, locations, character statistics, etc. Such data can be further aggregated, applied to a data model, and be subject to analysis. Such a UDS data model can be used to assign context information to each part of the information in a unified manner across multiple games.

[0016] As shown in FIG. 2, an exemplary console 228 (e.g., user device 130) and exemplary servers 218 (e.g., streaming server 220, activity feed server 224, user-generated content (UGC) server 232, and object server 226) are shown. In one example, console 228 may be implemented on either platform server 120, a cloud server, or server 218. In an exemplary example, content recorder 202 may be implemented on platform server 120, a cloud server, or any server 218. Such a content recorder 202 receives content (e.g., media) from interactive content title 230 and records it on content ring buffer 208. Such a ring buffer 208 may store a plurality of content segments (e.g., v1, v2, and v3), a start time for each segment (e.g., V1_START_TS, V2_START_TS, V3_START_TS), and an end time for each segment (e.g., V1_END_TS, V2_END_TS, V3_END_TS). Such segments may be stored by console 228 as media file 212 (e.g., MP4, WebM, etc.). Such a media file 212 may be uploaded to streaming server 220 for storage and subsequent streaming or use, but media file 212 may be stored on any server, cloud server, any console 228, or any user device 130. The console 228 may store the start time and end time for each such segment as content timestamp file 214. Also, such a content timestamp file 214 may include a streaming ID that matches the streaming ID of media file 212, thereby associating content timestamp file 214 with media file 212.Such a content time stamp file 214 can be uploaded and stored in the activity feed server 224 and / or the UGC server 232, but the content time stamp file 214 can be stored in any server, cloud server, any console 228, or any user device 130.

[0017] While the content recorder 202 receives and records content from the interactive content title 230, the object library 204 receives data from the interactive content title 230, and the object recorder 206 tracks the data to determine the start time and end time of the object. The object library 204 and the object recorder 206 can be implemented on any of the platform server 120, the cloud server, or the server 218. When the object recorder 206 detects the start of an object, the object recorder 206 receives object data (e.g., when the object is an activity, user interaction with the activity, activity ID, activity start time, activity end time, activity result, activity type, etc.) from the object library 204, and records this activity data (e.g., ActivityID1, START_TS; ActivityID2, START_TS; ActivityID3, START_TS) in the object ring buffer 210. Such activity data recorded on the object ring buffer 210 can be stored in the object file 216. Such an object file 216 can also include the activity start time, activity end time, activity ID, activity result, activity type (e.g., confrontation match, quest, task, etc.), user or peer data related to the activity. For example, the object file 216 can store data regarding items used during the activity. Such an object file 216 can be stored in the object server 226, but the object file 216 can also be stored in any server, cloud server, any console 228, or any user device 130.

[0018] Such object data (e.g., object file 216) can be associated with content data (e.g., media file 212 and / or content timestamp file 214). In one example, UGC server 232 stores and associates content timestamp file 214 with object file 216 based on a matching between the streaming ID of content timestamp file 214 and the corresponding activity ID of object file 216. In another example, object server 226 can store object file 216 and can receive a query about object file 216 from UGC server 232. Such a query can be executed by searching for the activity ID of object file 216 that matches the streaming ID of content timestamp file 214 sent with the query. In yet another example, a query of the stored content timestamp file 214 can be executed by matching the start time and end time of content timestamp file 214 with the corresponding start time and end time of object file 216 sent with the query. Also, such object file 216 can be associated by UGC server 232 with the matching content timestamp file 214, but this association can be performed by any server, cloud server, any console 228, or any user device 130. In another example, object file 216 and content timestamp file 214 can be associated by console 228 during the creation of each of files 216, 214.

[0019] Figure 3 shows a series of steps that can be executed when parameters related to the game difficulty are maintained or updated based on how well a user performs when playing a game. This user information can uniquely identify the user and can include a username and / or login information. Next, in step 320, this user information can be stored as part of a set of user profile information, and then, in step 330, data can be collected when the user plays one or more games. Step 330 can also include monitoring and collecting metrics related to game performance.

[0020] Step 340 in Figure 3 can include generating and evaluating game performance data. This can include identifying whether the objective of the game the user is currently playing meets a threshold level or some predetermined levels (i.e., the expected user performance level). For example, in a racing game, the metric can be related to the user's ability to drive a vehicle in the game and prevent other vehicles from overtaking the user's vehicle. This metric of the racing game may also be related to the success rate of overtaking attempts associated with the user. Here, the median level of performance may correspond to the user successfully preventing their vehicle from being overtaken by another vehicle 80% of the time. This median level may also correspond to a 50% overtaking success rate. Such an overtaking success level may correspond to the user successfully overtaking at least half of the vehicles they attempt to overtake once every two overtaking attempts during the game play period. In such a case (when the user expectation level is set to this median level), the user should be able to prevent other vehicles from overtaking their vehicle 8 out of at least 10 times, and the user should be able to successfully overtake at least half of the vehicles they attempt to overtake. Otherwise, the user's current performance level will not correspond to the current user expectation level.

[0021] Decision step 350 may identify whether the game difficulty parameter should be changed. This step may include identifying whether the user's current user performance level meets or exceeds the current user expectation level (i.e., corresponds to that user expectation level). If decision step 350 identifies that the difficulty parameter should not be changed, the program flow may return to step 330 where additional data is collected and stored. If decision step 350 identifies that the difficulty parameter should be updated, the program flow proceeds to step 360 where one or more difficulty parameters are updated.

[0022] In some cases, the change of parameters may need to be approved based on user feedback. This may include providing the user with a prompt to identify that the game difficulty can be increased or decreased based on the user's performance when using the current set of game difficulty parameters. In that case, the user may confirm that the game difficulty should be increased or decreased. Alternatively, the user may give a command to change the difficulty parameter. This may include receiving an immediate indication from the user via the user interface to increase or decrease the game difficulty. Here, the user can simply press a button to instruct the game system to update the difficulty level. In yet another example, the game system's difficulty parameter may be automatically updated based on the rules of a set of machine learning or artificial intelligence program codes.

[0023] If the user's driving meets the expectation level and potentially the user agrees, decision step 350 may identify the specific game difficulty parameter to be changed in step 360. After step 360, the program flow may return to step 330 where additional data can be collected and stored.

[0024] Regarding the above example, the determination step 350 may identify that the difficulty parameter should be updated when the user's driving meets or exceeds an 80% overtaking prevention level and meets or exceeds a 50% overtaking success level. The difficulty parameter assigned to the user may be different classes that may include a speed class, a sensitivity class, a proficiency class, and possibly the number of opponents in some cases. The metric of this speed class may be associated with a mobility parameter related to how fast an enemy can move in a straight line direction, or an agility parameter related to how fast an enemy can change direction. The sensitivity class of the metric may be associated with a reaction time parameter (e.g., a reflex reaction time) or a delay parameter (e.g., a thinking or concentration time). The proficiency class of the metric may be associated with a foresight parameter related to predicting the next action the user can take and initiating a countermeasure based on that prediction. The proficiency class of these metrics may also include a durability or strength parameter, and possibly a tenacity parameter in some cases. The metric of the number of opponents may be used to set the number of opponents (e.g., virtual cars) that compete with the user in the game.

[0025] Figure 4 shows a series of steps that can be executed when one or more parameters related to the performance of a game can be updated based on how well a particular user is performing during play of the game. Figure 4 begins with step 410 where game performance data is accessed. This data can indicate how well the user is performing in the game. As described with respect to Figure 3, the level of game performance can correspond to how often a user playing a driving game prevents other vehicles from overtaking the vehicle the user is driving and how often the user is successful in overtaking other vehicles. In a first-person shooting game, the game performance data can be related to the number of targets hit out of the number of shots fired at the target. Other examples of game performance data can be related to how successful the user is in destroying a target or how successful the user is in achieving other game objectives. Next, in step 420, the order of user skills can be determined. A user of a first-person shooting game may be proficient at using a sniper rifle, have an intermediate skill at using an automatic pistol, and may have a low skill at close combat. Such skills and the levels of related skills can be determined based on an evaluation of the accessed game performance data.

[0026] Next, the game parametric data can be accessed at step 430 of FIG. 4. This game parametric data can include the classes of the above metrics, such as a metric speed class, a sensitivity class, and a proficiency class. Further, the parametric data can include the number of the above opponents. Next, at decision step 440, the game performance data, the skill order data, and the game parametric data can be evaluated to check whether the current set of difficulty parametric settings should be maintained or changed. If it is identified at decision step 440 that the current parametric setting set should be maintained, the program flow can return to step 410, where the process is repeated when the user continues to play the game.

[0027] In decision step 440, if it is identified that the current difficulty parametric setting set should not be maintained, the program flow can move to step 450, where the specific difficulty parametric settings to be updated are identified. Thereafter, these difficulty parametric settings can be updated in step 460 of FIG. 4. In some cases, the difficulty parametric settings identified in step 450 may be identified based on the order of user skills in step 420. For example, for a user playing a first-person shooting game, if the skill of using a sniper rifle is excellent, the skill of using an automatic pistol is medium, and the close combat skill is low, the performance metrics related to the actions of opponents in the game scenes where the automatic pistol is used and in the game scenes where close combat occurs can be decelerated using parameters of speed, sensitivity, and / or proficiency. As a result, the movement of the opponents becomes slower, their agility decreases, the reaction time to stimuli (the actions of the user's character or the action of aiming the rifle) becomes slower, and the accuracy or strength can decrease. As a result of such adjustments, the user of the game becomes more proficient when playing the game. As the gameplay continues, one or more of these parameters can be changed to gradually increase the ability of the opponents the user fights against. Here, the opponents may move somewhat faster, but their agility is still limited and the reaction time can be slowed down. In the next update, the agility of the opponents may be improved, but the reaction time to stimuli may still be slowed down. As previously described with respect to FIG. 3, the difficulty parameters may be updated automatically, based on the user's consent, or commanded by the user. After step 460, the program flow can return to step 410, where the gameplay can continue, and at that time, the updated set of difficulty parameters is used.

[0028] In some cases, the skills related to one game may be applicable to the suitability of another game. For example, a person who is good at moving to a new position in a first-person shooting game may correspond to a person who runs fast in a racing game. Alternatively, if it is cited that as a weakness of a person playing a first-person game, it takes too much time to accurately aim at a target, this weakness may correspond to the tendency that the person does not show a quick reaction when a vehicle in a racing game tries to overtake their vehicle. This means that the data collected from one game may be used to help select the difficulty parameters to be updated when a person plays another game.

[0029] FIG. 5 is a block diagram of an exemplary electronic entertainment system 500. The entertainment system 500 of FIG. 5 includes a main memory 505, a central processing unit (CPU) 510, a vector unit 58, a graphics processing unit 520, an input / output (I / O) processor 525, an I / O processor memory 530, a controller interface 535, a memory card 540, a universal serial bus (USB) interface 545, and an IEEE interface 550. The entertainment system 500 may further include an operating system read-only memory (OS ROM) 555, an audio processing unit 560, an optical disk control unit 570, and a hard disk drive 565, which are connected to the I / O processor 525 via a bus 575.

[0030] The entertainment system 500 may be an electronic game console. Alternatively, the entertainment system 500 may be implemented as a general-purpose computer, a set-top box, a handheld game device, a tablet computing device, a mobile computing device, or a mobile phone. The entertainment system may include a greater or fewer number of operating components depending on the specific form factor, purpose, or design.

[0031] The CPU 510, vector unit 58, graphics processing unit 520, and I / O processor 525 in FIG. 5 communicate via a system bus 585. Further, the CPU 510 in FIG. 5 communicates with the main memory 505 via a dedicated bus 580, and the vector unit 58 and the graphics processing unit 520 may communicate via a dedicated bus 590. The CPU 510 in FIG. 5 executes programs stored in the OS ROM 555 and the main memory 505. The main memory 505 in FIG. 5 may include pre-stored programs and programs transferred via the I / O processor 525 from a CD-ROM, DVD-ROM, or other optical disk (not shown) using the optical disk control unit 570. The I / O processor 525 in FIG. 5 may also enable the introduction of content transferred through a wireless or other communication network (e.g., 4G, LTE, 3G, etc.). The I / O processor 525 in FIG. 5 mainly controls data exchange between various devices of the entertainment system 500 including the CPU 510, vector unit 58, graphics processing unit 520, and controller interface 535.

[0032] The graphics processing unit 520 in FIG. 5 executes graphics instructions received from the CPU 510 and the vector unit 58 to generate an image for display on a display device (not shown). For example, the vector unit 58 in FIG. 5 may convert an object from three-dimensional coordinates to two-dimensional coordinates and transmit the two-dimensional coordinates to the graphics processing unit 520. Further, the audio processing unit 560 executes instructions to generate an audio signal, and the audio signal is output to an audio device such as a speaker (not shown). Other devices may be connected to the entertainment system 500 via a USB interface 545 and an IEEE 1394 interface 550 such as a wireless transceiver, and these interfaces may also be embedded in the system 500 or as part of some other components such as a processor.

[0033] The user of the entertainment system 500 in FIG. 5 provides instructions to the CPU 510 via the controller interface 535. For example, the user may instruct the CPU 510 to store specific game information in the memory card 540 or other non-transitory computer-readable storage medium, or may instruct a character in the game to perform some specific actions.

[0034] The present invention may be implemented in applications that may be operable by various end-user devices. For example, the end-user device may be a personal computer, a home entertainment system (e.g., Sony PlayStation2 (registered trademark) or Sony PlayStation3 (registered trademark) or Sony PlayStation4 (registered trademark)), a portable game device (e.g., Sony PSP (registered trademark) or Sony Vita (registered trademark)), or, although lower, a home entertainment system of a different manufacturer. The method described herein is fully intended to be operable on various devices. The present invention may also be implemented in a cross-title neutral state, and embodiments of the system of the present invention may be utilized across various titles from various publishers.

[0035] The present invention may be implemented in an application that may be operable using various devices. A non-transitory computer-readable storage medium refers to any medium or plurality of media involved in providing instructions to a central processing unit (CPU) for execution. Such media can take many forms including, but not limited to, non-volatile media such as optical disks, magnetic disks, and volatile media such as dynamic memory. Common forms of non-transitory computer-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, any other magnetic media, CD-ROM disks, digital video disks (DVDs), any other optical media, RAM, PROM, EPROM, FLASHEPROM, as well as any other memory chip or cartridge.

[0036] Various forms of transmission media may be involved in conveying one or more sequences of one or more instructions to a CPU for execution. A bus transfers data to system RAM from which the CPU fetches and executes instructions. Instructions received by system RAM can optionally be stored on a fixed disk either before or after being executed by the CPU. Various forms of storage, as well as the network interfaces and network topologies necessary to implement them, may be implemented as well.

[0037] The detailed description of the foregoing technology has been presented for purposes of illustration and description. The above detailed description is not intended to be exhaustive or to limit the technology to the exact form disclosed. Many modifications and variations are possible in light of the above teachings. The described embodiments were chosen in order to best explain the principles of the technology, its practical application, and to enable others skilled in the art to utilize the technology in various embodiments and with various modifications suitable for the particular purposes contemplated. The scope of the technology is intended to be defined by the claims.

Claims

1. A method for adaptive difficulty between skills, comprising: storing data indicating a user performance level identified based on analysis of collected game performance data associated with a user who uses a plurality of different skills in a virtual environment of a digital content title; comparing the user performance level with a specified expected level associated with the digital content title; predicting, based on the comparison, one or more deviations between the user performance level and the specified expected level, wherein the predicted deviation corresponds to one or more next events of a current interactive session; selecting a game difficulty parameter from a set of game difficulty parameters to be applied to each of the next events, based on the predicted deviation, wherein the game difficulty parameter is selected based on one or more of the different skills associated with each of the next events; dynamically applying the selected game difficulty parameter to the relevant event during the interactive session, such that the user is required to use the skill associated with the event according to the dynamically applied game difficulty parameter; the method as described above.

2. The method according to claim 1, further comprising: identifying whether an updated user performance level corresponds to the user's expected level based on analysis of game performance data regarding the event; and dynamically adjusting the game difficulty parameter based on whether the user performance level is greater or less than the specified expected level by a threshold.

3. The method according to claim 1, wherein the game difficulty parameter corresponds to the speed or strength of a character played by the user or an adversarial game character.

4. The method according to claim 1, wherein the game difficulty parameter corresponds to an adjustment of a time delay or the timing of the event.

5. generating the order of the skills based on the collected game performance data, further comprising selecting the game difficulty parameter based on the order of the skills, the method according to claim 1.

6. evaluating game performance data collected when the user plays a second interactive session associated with the same or different digital content titles; identifying that the evaluated game performance data corresponds to using one or more of the skills associated with the user; updating the stored game performance data based on the evaluated performance data associated with the one or more skills used in the second interactive session; the method according to claim 5, further comprising.

7. the method according to claim 1, wherein the stored performance data regarding the different skills of the user includes game data associated with a plurality of different digital content titles.

8. the method according to claim 1, wherein a plurality of selected game difficulty parameters are dynamically applied to the different events during the interactive session to adjust the difficulty level of each of the different events according to the relevant skills.

9. the method according to claim 1, wherein different selected game difficulty parameters are selected for different users associated with different user performance levels across the different skills.

10. the method according to claim 1, wherein the user performance level includes a plurality of different user performance levels for each of the different skills.

11. A system for adaptive difficulty between skills, comprising: a memory storing data indicating a user performance level identified based on an analysis of collected game performance data associated with a user using a plurality of different skills in a virtual environment of a digital content title; a processor executing instructions stored in the memory, the processor: comparing the user performance level with a specified expected level associated with the digital content title; Predicting one or more deviations between the user performance level and the specified expected level based on the comparison, wherein the predicting corresponds to one or more next events of the current interactive session; Selecting game difficulty parameters from a set of game difficulty parameters applicable to each of the next events based on the predicted deviation, wherein the game difficulty parameters are selected based on one or more of the different skills associated with each of the next events; During the interactive session, dynamically applying the selected game difficulty parameters to the relevant events, wherein the user is required to use the skills associated with the events according to the dynamically applied game difficulty parameters; The processor that executes the instructions to perform; The system comprising.

12. The system according to claim 11, wherein the processor further executes instructions to identify whether an updated user performance level corresponds to the user's expected level based on an analysis of game performance data regarding the events, and to dynamically adjust the game difficulty parameters based on whether the user performance level is greater than or less than the specified expected level by a threshold.

13. The system according to claim 11, wherein the game difficulty parameters correspond to the speed or strength of a character played by the user or an adversarial game character.

14. The system according to claim 11, wherein the game difficulty parameters correspond to an adjustment of a time delay or the timing of the events.

15. The system according to claim 11, wherein the processor further executes instructions to generate an order of the skills based on the collected game performance data, and the game difficulty parameters are selected based on the order of the skills.

16. The processor is evaluating game performance data collected when the user plays a second interactive session associated with the same or a different digital content title; identifying that the evaluated game performance data corresponds to using one or more of the skills associated with the user; updating the stored game performance data based on the evaluated performance data associated with the one or more skills used in the second interactive session; The system of claim 15, further executing instructions to perform the above.

17. The system of claim 11, wherein the stored performance data regarding the different skills of the user includes game data associated with a plurality of different digital content titles.

18. The system of claim 11, wherein a plurality of selected game difficulty parameters are dynamically applied to the different events during the interactive session to adjust the difficulty level of each of the different events according to the relevant skills.

19. The system of claim 11, wherein different selected game difficulty parameters are selected for different users associated with different user performance levels across the different skills.

20. The system of claim 11, wherein the user performance level includes a plurality of different user performance levels for each of the different skills.

21. A non-transitory computer-readable storage medium having an embodied program executable by a processor to perform a method for adaptive difficulty between skills, the method comprising: storing data indicating a user performance level identified based on an analysis of collected game performance data associated with a user who uses a plurality of different skills in a virtual environment of a digital content title; comparing the user performance level with a specified expected level associated with the digital content title; Predicting, based on the comparison, one or more deviations between the user performance level and the specified expected level, wherein the predicted deviations correspond to one or more next events of the current interactive session; Selecting, based on the predicted deviations, a game difficulty parameter from a set of game difficulty parameters to be applied to each of the next events, wherein the game difficulty parameter is selected based on one or more of the different skills associated with each of the next events; During the interactive session, dynamically applying the selected game difficulty parameter to the associated event, wherein the user is required to use the skills associated with the event according to the dynamically applied game difficulty parameter; The non-transitory computer-readable storage medium comprising the above.

Images