CN115175750A - AI-based game application content generation - Google Patents

Abstract

The invention discloses a program content generation tool, which operates by: generating a graphic of the existing game content via image analysis; generating a Symmetric Markov Random Field (SMRF) model based on the graph; and automatically generating new game content based on the SMRF model via iterative Artificial Intelligence (AI).

Description

AI-based game application content generation

Technical Field

The present disclosure relates to processing systems and applications used in the development of gaming applications for use by gaming systems and other gaming devices.

Drawings

This patent or application document contains at least one drawing executed in color. The patent office will provide copies of the patent or patent application publication in color drawing(s) on demand and for the necessary fee.

Fig. 1 presents a pictorial/block diagram representation of a game development system in accordance with an embodiment of the present disclosure.

FIG. 2 presents a block diagram representation of a game development platform according to an embodiment of the present disclosure.

FIG. 3A presents a flow/block diagram representation of a game development pipeline in accordance with an embodiment of the present disclosure.

FIG. 3B presents a flow/block diagram representation of components of a general experience persona according to an embodiment of the present disclosure.

Fig. 4 presents a flowchart representation of a method in accordance with an embodiment of the present disclosure.

FIG. 5 presents a graphical representation of game telemetry data in accordance with an embodiment of the present disclosure.

Fig. 6 presents a flowchart representation of a method in accordance with an embodiment of the present disclosure.

Fig. 7 presents a flowchart representation of a method in accordance with an embodiment of the present disclosure.

Fig. 8 presents a flowchart representation of a method in accordance with an embodiment of the present disclosure.

Fig. 9 presents a flowchart representation of a method in accordance with an embodiment of the present disclosure.

Fig. 10A and 10B present a graph according to an embodiment of the present disclosure.

Fig. 10C presents a flowchart representation of a method in accordance with an embodiment of the present disclosure.

FIG. 11A presents a pictorial representation of an existing game in accordance with an embodiment of the present disclosure.

FIG. 11B presents a graphical representation of an existing game according to an embodiment of the present disclosure.

Fig. 11C presents a pictorial representation of an existing game in accordance with an embodiment of the present disclosure.

FIG. 11D presents a graphical representation of an existing game according to an embodiment of the present disclosure.

FIG. 11E presents a cumulative configuration table in accordance with the present disclosure.

Fig. 11F presents a conditional probability table according to the present disclosure.

Fig. 12A presents a pictorial representation of an existing game in accordance with an embodiment of the present disclosure.

Fig. 12B presents a pictorial representation of an existing game in accordance with an embodiment of the present disclosure.

Fig. 12C presents a graphical representation of an existing game according to an embodiment of the present disclosure.

FIG. 12D presents a graphical representation of an existing game according to an embodiment of the present disclosure.

Detailed Description

Fig. 1 presents a pictorial/block diagram representation of a game development system in accordance with an embodiment of the present disclosure. In particular, a game development platform 125 is presented that communicates game data 118 and player data 119 with gaming devices, such as mobile device 113, and gaming system 112 via network 115. The network 115 may be the internet or other wide area network or local area network. The game development system 125 may be used for the creation, development, testing, balancing, and updating of game applications.

Game data 118 may include, for example, a current version of a game application presented to a gaming device for play. Further, game data 118 transmitted from the gaming devices to game development platform 125 may include game telemetry data or be processed to generate game telemetry data and/or other game analysis for use in game development. The player data 119 may include one or more output modes, such as player or spectator language data generated by a microphone associated with the game system 112 or 113, chat data associated with the player or spectator, and/or non-language data of the player or spectator, such as facial expressions, head gestures, captured via a camera or other imaging sensor associated with the game system 112 or 113 that indicates, for example, the mood of the player and/or spectator.

The operation of game development platform 125, including several optional functions and features and examples thereof, will be described in more detail in connection with fig. 2-12.

FIG. 2 presents a block diagram representation of a game development platform according to an embodiment of the present disclosure. In particular, the game development platform 125 includes a network interface 220, such as a 3G, 4G, 5G or other cellular wireless transceiver, a Bluetooth transceiver, a WiFi transceiver, an ultra-wideband transceiver, a WIMAX transceiver, a ZigBee transceiver or other wireless interface, a Universal Serial Bus (USB) interface, an IEEE 1394 firewire interface, an Ethernet interface or other wired interface, and/or other network cards or modems, for communicating with one or more gaming devices over the network 115.

The game development platform 125 also includes a processing module 230 and a memory module 240 (e.g., apple, unix, linux, or Microsoft operating system or other operating system) that stores an operating system (O/S) 244, a game development application 246, one or more game applications 248, one or more gaming robots 250, one or more Procedural Content Generation (PCG) tools 252, and one or more Behavioral Experience Analysis (BEA) tools 254. In particular, O/S244, game development application 246, game application 248, gaming robot 250, PCG tool 252, and BEA tool 254 each include operational instructions that, when executed by processing module 230, cooperate to configure the processing module into a special-purpose device to perform the particular functions described herein.

The game development platform 125 also includes a user interface (I/F) 262, such as a display device, touch screen, keypad, touch pad, joystick, thumbwheel, mouse, one or more buttons, speaker, microphone, accelerometer, gyroscope or other motion or position sensor, camera, or other interface device that provides information to a user of the game development platform 125 and generates data in response to user interaction with the game development platform 125.

The processing module 230 may be implemented via a single processing device or a plurality of processing devices. Such a processing device may include a microprocessor, microcontroller, digital signal processor, microcomputer, central processing unit, field programmable gate array, programmable logic device, state machine, logic circuitry, analog circuitry, digital circuitry, and/or any device that manipulates signals (analog and/or digital) based on operational instructions stored in a memory (e.g., memory 240). Memory module 240 may include a hard disk drive or other magnetic disk drive, read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, cache memory, and/or any device that stores digital information. Note that when the processing device implements one or more of its functions via a state machine, analog circuitry, digital circuitry, and/or logic circuitry, the memory storing the corresponding operational instructions may be embedded within or external to the circuitry comprising the state machine, analog circuitry, digital circuitry, and/or logic circuitry. Although a particular bus architecture is presented that includes a single bus 260, other architectures are possible that include additional data buses and/or direct connections between one or more elements. Further, game development platform 125 may include one or more additional elements not specifically shown.

The game development application 246 may be used by game developers for the creation, development, testing, balancing, improvement, revision, optimization, and/or updating of the game application 248. The game applications 248 may be, for example, multiplayer or solitaire games, including shooting or other combat games, fantasy games or other action or adventure games, simulation games that simulate the operation of real-world vehicular devices or systems, real-time strategy games, trivia games, sports games, role-playing games, board games, or other video or digital animation games. In various embodiments, one or more versions of the game application 248 may be stored, including, for example, multiple versions or updates of the game application, one or more sets of game parameters, one or more levels, and other content and/or other game data.

The game bot 250 operates in conjunction with the game development application 246 to test the operation of the game application 246 and/or to operate as one or more non-player characters (NPCs) in a game. The game robot 250 may include and/or operate as a game-playing AI (artificial intelligence) character that is built and implemented via machine learning algorithms and operates, for example, as an automated tester designed to represent a particular game style or skill level. These AI characters can be used, for example, to play games faster than actual players to evaluate game content faster; randomly evaluating the difficulty of the level by using thousands of play changes; generating Key Performance Indicators (KPIs), increasing the speed of design iterations to free designers time to focus on gameplay and high-level concepts; for example, the iterative testing may be performed with the same skill level and style through various versions and/or iterations of the game application 248. The use of artificial intelligence rather than human intelligence allows the gaming robot 250 to perform at speeds and with consistency that cannot be practically performed in the human brain.

Further, one or more of the AI characters may operate as a regression game tester playing the game based on machine learning of the recorded human demonstration and check that the game is still playable after content or code changes. Specifically, when an error is found in the game, the return game tester may generate reports, generate KPIs, predict changes in overall game time and game difficulty, and/or operate in conjunction with the BEA tool 250 to predict changes in player behavioral motivation, both positive and negative, including boredom, excitement, completion, and the like.

As noted above, AI characters can act as player proxies, AI opponents, and/or NPCs for single and multiplayer games. This enables game developers to ensure that someone is always fighting and mimicking a real opponent before and after startup; an adversary, different from skill level and style, challenges the player; and generate a lively, convincing world in which the character behaves in a different pattern.

The PCG tool 252 uses program content generation, such as program content generation via machine learning (PCGML) or other AI, to initiate and accelerate the creative process of game developers using the game development application 246 to develop new game applications 248 and/or new content or levels to existing game applications. The PCG tool 252 may be constructed via machine learning algorithms and include, for example, markov random field (Markov random field) models, symmetric Markov random field models, convolutional neural networks, stacked neural networks, generating countermeasure networks, deep learning algorithms, unsupervised learning algorithms, costing Mei Teluo bolis samples, or other artificial intelligence models or methodologies that are iteratively trained and operated based on analysis of previous versions of games, game data 118 (e.g., game telemetry data, behavioral motivational data, and/or gameplay by one or more AI character characters) to generate new game content (e.g., new game changes, new checkpoints, and other content).

In various embodiments, an AI character playing a game may evaluate and comment on content generated via a PCG by generating AI character game trajectories and statistics across game content, and evaluate program-generated content according to predicted KPIs and/or other performance metrics. This allows the game development application 246 to help game developers understand and evaluate the game space of a PCG-enabled game to protect the PCG design from unplayable or degraded instances.

Further, the PCG tool 252 may generate new developmental games, levels, or other content by learning instances provided by game developers to the game development platform 125 to seed artificial intelligence models and generate new candidate content for evaluation. This allows game developers using the game development platform 125 to utilize pre-generated developmental games, levels, and/or other content to increase their productivity; focus on concepts and important details, rather than trivial layouts; created starting from the generated instance instead of a blank canvas, and/or generated content based on style and preferences learned from previous game developers provided to the spawner instance of the game development platform 125 by the game developer.

BEA tool 254 operates in conjunction with game development application 246 to automatically predict player motivations and other player experiences from a player's game track in real-time. Further, the use of the BEA tool 254 in conjunction with the gaming robot 250 and/or the PCG tool 252 allows game developers to predict future player motivations and other player experiences from the play trajectory of the AI character based on simulated game play.

The use of the game development platform 125 helps game developers understand what players like a particular game application 248, reduces churn, optimizes player experience, and long term participation. In particular, potential game players are different and play for different reasons. Predicting gamer motivation helps game developers understand these differences and groupings of potential player groups.

BEA tool 254 may be constructed by preference learning or other machine learning techniques trained based on player questionnaires, game data 118, and/or player data 119 to learn and predict actual player motivations. In operation, BEA tool 254 uses game telemetry data, game data 118, and/or player data from other players to predict the reasons that various players interacted with the game. For example, generating BEA data indicating the extent to which players are motivated by motivational factors allows game developers to optimize player experience accordingly, match according to players' motivations to create better game sessions, optimize and personalize games to players to stay with players and improve life-long value, identify poor player matches and potential negative interactions before they become problematic, track player-based developments over time, and learn daily whether your typical gamer motivation or behavioral profile begins to change.

Consider the following example of a case.

Case #1

Background

The game developer uses the game development platform 125 to develop the game application 248 as a multiplayer mobile game.

The game is characterized by two opposing teams, each team having up to four characters, playing the fantasy american football style.

The personas that a player may use are taken from a larger pool, made available to the player, and built into a "deck" for a particular tournament.

Each character has different capabilities, fundamentally changing the player's experience. Combining different characters in different card sets may give players different teams.

Additionally, each character can be infinitely adjusted according to a combination of vital value, injury, speed, and the like.

It is important to know how these different card sets compete against each other to ensure that the game is well balanced and to encourage players to gain more characters when playing the game.

The game developer plans to continue developing new characters and to release new characters on a regular basis after initial startup.

Additionally, game developers plan to develop and release new game zones that change the characteristics of the game, again affecting the play value of a particular deck.

Need to make sure that

The game developer needs to understand the play characteristics of each character, whether alone or when combined with other characters in the deck.

This means that the game developer needs to understand that different characters are dynamically competing against each other in the game during the course of the game.

This means that many games are played with different configurations of character decks and the impact of various game styles and strategies is observed and analyzed in various combinations.

The game feature is 18 characters, and in addition to selecting 4 characters, the player can choose between 4 magicians who can add to their deck.

This means that the current version of the game supports 293,760 different card combinations, where the character and legal characteristics can vary infinitely.

Since two card sets (possibly identical) are used per game, a different game may be set and played for 86,294,937,600 before any game values are adjusted.

In addition to this, different game maps add further complexity.

The combinatorial problem continues to grow as more characters and maps are added to the game.

The game developer wants to explore as many different deck solutions and matching combinations of characteristics as possible to optimize the game and ensure good monetization of products with high retention rates in order to maximize the customer life value (LTV).

Use of the Game development platform 125

Two people playing a single game to investigate the character and card set characteristics currently take about 5 minutes, each person needing to be coordinated to be able to play at the same time.

Two gaming robots 250 currently take 20 to 25 seconds to play a singles tournament to investigate the character of the character and card set.

In addition to being 15 times faster than a human player, gaming robot 250 allows many matches to be performed in parallel, using statistics to summarize and compare data without requiring qualitative interpretation.

A game developer performing a qualitative check on the character may engage with the gaming robot 250, reducing the manpower involved by 50%, and freeing up staff time for other tasks, while eliminating the need for scheduling between two staff members.

Additionally, the gaming robot 250 may be included in the completed game as a player-oriented NPC. This eliminates the need for game developers to develop AI-oriented players separately internally and improves hard-start of games by providing an unlimited number of opponents for new players, as game developers are building their player base.

Case #2

Background

The game developer has an existing game application 248 that implements the developmental game.

Keeping the player fresh of the game requires continuous production of new content.

New content needs to be of high quality.

Content is not interchangeable: game developers report from the analysis that differences in the quality of the level have a major impact on the life-long value of the client, with good levels being a critical component in retaining players.

The team currently creating the new level consists of 2 to 3 level designers creating the new level.

Previously, the designer could make 15 new slots every two weeks to release into the game. It takes 1 week to evaluate these levels with an external game testing company.

Reducing the iteration time allows the designer to focus on new features that increase the quality of the level, which is a major predictor of game performance.

Need to make sure that

The game developer wants to automatically generate an algorithm for the new level concept for the designer to choose from to allow the designer to focus on the new level idea rather than building the trivial aspects of the level design.

The game developer wants to use automatic content generation to motivate the designer's new idea-solve the "blank canvas problem" -i.e. think from scratch.

The game developer wants the robot to play more like a human in order to improve their assessment of the designer's creation of the level.

Use of the Game development platform 125

The speed may be increased to 30 level checkpoints per 1 week through an automatic game test by a single gaming robot 250. The assessment level is almost instantaneous, allowing the designer to iterate when his thoughts are fresh.

Case #3

Background

The game developer is developing a game application 248 that implements a multi-platform narrative game for the PC, mac and gaming stations 4.

The game is a highly complex branch narrative consisting of a game of about 8 hours of full play.

Need to make sure that

The elements of the game are highly interdependent.

Changing the early part of the story may have an effect on the later part of the story and make the game unfinishable.

Altering code to address the need for late development determinations or fixing errors may destroy the functionality of the early parts of the game.

The team is of limited size and there are no full-time quality assurance staff in the team.

When non-programmer team members encounter an error, their work typically stops because of the inability to test the game or experience the content as it is created.

This breaks the creative flow and dramatically increases the iteration time on the story idea.

Requesting urgent bug fixes from the programmer tends to disrupt the programmer's workflow and therefore has a cascading cost effect.

Testing a full game to take at least 8 hours of full time work in response to changes, plus logging, case creation, and derivative tasks.

The game developer needs a solution that can automatically identify the failure points when traversing the game story content.

Use of the Game development platform 125

The gaming robot 250 automatically walks through the story of the game, allowing the game developer to identify when the game will crash or when the player will jam.

The system operates in two ways:

1. through player impersonation, the gaming robot 250 simulates previous player actions to verify that the previous demonstration was still valid after the game code or content changed.

2. The gaming robot 250 automatically searches for games, walks through storylines, looks for crashes, and/or dead ends.

The implementation of the game development platform 125 has three benefits:

1. the game development platform 125 may continuously verify that the game is still working after the change.

2. The game development platform 125 may continuously verify that the game is achievable.

3. The game development platform 125 can play games indefinitely, enable stress testing that simulates human interaction and provides more realistic use cases than simply letting a game run without input.

The game development platform 125 substantially replaces the work of one QA employee.

For a team of about 10 people, this corresponds to a budget saving of about 7% after the initial implementation.

Additionally, the game development platform 125 provides improvements in creative efficiency, resulting in higher quality content, which can positively impact final game performance.

Case #4

Background

The game developer has implemented an unlimited running game.

Need to make sure that

When the player base is large, it is difficult to know the player.

Only about 5% of the players complete the game.

The goal of the game designer is to have most players complete the game.

Use of the Game development platform 125

The use of BEA tools 254 can determine real-time player experience and help improve game completion and player survival rates.

FIG. 3A presents a flow/block diagram representation of a game development pipeline 325 in accordance with an embodiment of the present disclosure. The game development pipeline 325 operates in conjunction with the game development platform 125 of fig. 1 and 2 and uses one or more of the functions and features described therein. In particular, a game development pipeline is presented in which game development temporarily progresses from the initial generation of the game in step 300 to passing, for example, alpha testing, beta testing, and/or soft start, and results in the generation of an improved game for hard start in step 314.

In step 300, a game, such as an initial version of the game application 248, is generated. In various embodiments, the initial version of the game is developed by a game developer using the game development application 246 from scratch or from initial game content generated by the PCG tool 252 based on, for example, a previous game or a previous version of a game developed by the game developer.

In step 302, the game is tested using the non-mock gaming robot 250, for example, the gaming robot is developed and trained by testing and evaluating a previous game or a previous version of the game developed by the game developer. In various embodiments, gaming robots 250 include a library of non-mock gaming robots and descriptive metadata indicating, for example, the source, previous usage, corresponding player motivations, and/or other characteristics of each gaming robot. The game developer may select and evaluate one or more existing gaming robots for the test. Once one or more gaming robots 250 are selected, the game may be tested and improved, for example, to identify dead ends and begin balancing the game, increase playability, and the like.

In step 304, the emulated gaming robot 250 is generated based on game telemetry from an actual player, such as an internal or external player used in the test prior to hard start. In various embodiments, game telemetry data may include data collected from game tracks, which may include, for example, game outputs including audio and pixel data, player inputs, game states, game events, game achievements, game goal progress, game parameters, KPIs, and other game analytics.

In various embodiments, gaming robot 250 operates via a machine learning algorithm that is trained via game telemetry data from actual players. Examples of such machine learning algorithms include artificial neural networks (or more simply "neural networks" as used herein), support vector machines, bayesian networks, genetic algorithms, and/or other machine learning techniques via unsupervised, semi-supervised, and/or reinforcement learning training and may also include feature learning, sparse dictionary learning, anomaly detection, decision trees, association rules, and/or other processes.

In step 306, the game is further tested and improved by monitoring the output, e.g., game telemetry data including, for example, KPIs generated by the game play of the gaming robot 250 and other game analysis. In this manner, various versions of a game may be tested, evaluated, and improved, for example, to identify dead ends, to further balance the game, to further increase playability, to optimize predicted player retention, and the like.

In step 308, BEA data is collected from game data, player questionnaires, or other experience metrics including various gamer incentives, which may be related to KPIs, game events, player behavior, game state, game achievements, game goal progress, game parameters, and other game analysis, for example. Gamer motivation can be a wide range of motivational factors such as competence, autonomy, relevance, and presence. Additionally or alternatively, player motivations and behaviors may be game-related, including competition, completion, fantasy, destruction, discovery, strategy, excitement, strength, including more specific motivations, such as achieving high scores, continually challenged, challenged at some other frequency, achieving game goals and achievements, completing level, relaxing, defeating or destroying the game of other players, cheating, avoiding cheating by other players, and other game styles, etc.

In step 310, the BEA data is used to train one or more BEA tools. As previously described, BEA tool 254 may be constructed via preference learning or other ordered machine learning techniques trained based on BEA data in order to learn and predict actual gamer motivation.

In step 312, the player experience may be predicted automatically and in real-time via the BEA tool based on game telemetry data from the actual player and/or the emulated or non-emulated gaming robot 350. This player experience data may be used in conjunction with the gaming robot testing in step 306 to further refine the game in step 314 for hard start, for example, by improving predicted player satisfaction with the game, increasing predicted player retention, and/or increasing predicted revenue generation.

While a game development pipeline 325 has been described that corresponds to testing, analyzing, and refining an initial version of a game into an improved game for hard start, one or more steps in the game development pipeline 325 may also be used to similarly process new versions, updates, and/or new content additions to the game application 248. Further, while game development pipeline 325 is described as including step 308 of collecting BEA data and step 310 of generating BEA tools 254 based on the BEA data, where game development platform 125 is used to process new versions, updates, and/or new content additions to similar games, game applications 248, one or more BEA tools 254 generated from previous versions of the game or from similar games may be selected for reuse. For example, BEA tools 254 include a library of BEA tools and descriptive metadata that refers to instances such as the source, previous usage, and/or other characteristics of each BEA tool. The game developer may select and evaluate one or more existing BEA tools 254 used in step 312 to predict player experiences, including motivations and/or behavior, and other experiences based on game telemetry data from external players.

Additionally, consider the following further example of a computational model for a generated and general player experience (e.g., "general experience persona"). The character is generated because it is able to simulate the player experience provided as a human experience presentation. This process is also common in various examples of specific areas involving digitization and simulation of human experiences.

To obtain a generic experience character, the game development platform 125 can incorporate innovations in three aspects of the computational model: model inputs, calculations, and model outputs. The method can be built on a psychological anchoring method according to which humans encode values in a comparative (relative) manner. Based on innovative, ordered modeling approaches, personas perceive humans (or their presentations) via generalizable features, and they gradually experience the environment like humans through machine learning.

The game development platform 125 generally solves the basic problems of psychometrics and human psychology: experience is computationally measured in a reliable and efficient manner. It also solves the core problems of human-computer interaction and player experience research: how to simulate the same experience as human perception in a simulated world. Finally, it solves a traditional problem at the intersection of machine learning and emotion computation: how we learn most from less subjective data.

FIG. 3B presents a flow/block diagram 350 representation of components of a general experience persona according to an embodiment of the present disclosure. In particular, a method is proposed for any of the functions and features described in connection with fig. 1, 2 and 3A. This process is an innovation by combining three core sub-processes: input (descriptor mapping), computation itself (generative model), and output (presentation) provide a reliable and efficient solution for modeling the generation of the player experience (e.g., including motivation and/or behavior).

Step 352 — experience demonstration: the proposed method for processing character output is general in that it can support any annotation type from traditional psychometrics. For example, it may differ from previous approaches in the way experience indicia are collected and processed. In particular, human experience demonstrations may be collected in a persistent manner via engagement metrics extracted from the interactions. This includes the entire process from passively observing the video (e.g., game video) to actively annotating any interactions (e.g., games). Experience markup is processed in an orderly and unbounded manner, allowing the construction of a generic experience model that is agnostic to value. By following first and second order combining techniques, we can not only produce an effective and reliable demonstration of human experience, but can also generate large datasets from limited data. There is no longer a need for any type of questionnaire-the dominant state of practice in human computer interaction (even though questionnaire data can still be processed), and human participation is limited to actual small-scale player population sizes.

Step 354-experience Generation model: experience personas may learn to predict human experiences, or even express experiences like humans. With respect to the former, game development platforms involve methods of learning global or partially sequential depth (preference) learning of predictive tagging experiences. For the latter, the order of human presentation (as from above) defines the utility of reinforcement learning methods (e.g., neural evolution, random tree search) to learn inferences. The result is a generated experience model that can be "felt" like a human player in a simulated environment.

Step 356-experience descriptor mapping: the experience is perceived by means of interaction and is limited by the experience label. The perceptual model focuses on areas of the marked experience that are meaningful to the model and eliminates areas where no changes are observed or reported about the experience. The representation of the experience is learned by observing the general aspect of the interaction, i.e., the general experience descriptor mapping. The design of the mapping can vary from high-level behavioral representations to sequential patterns of interaction to detailed latent variables mapped to experience markup. The latter is built directly, where possible, by simulating interactions, or indirectly when the code generating the interactions is inaccessible, by a machine-learned interaction forward model.

In addition to pure game development, the BEA tools 254 of the game development platform 125 may be incorporated into the final game itself. In this manner, individual players may be evaluated for motivation and/or behavior. In various embodiments, a particular game version or game parameter setting may be selected from a library of possible game versions/settings for an individual player to supplement or otherwise match a particular incentive and/or behavior predicted to correspond to the individual player, for example, to improve the experience of the particular player. In this way, players who like challenges may be challenged, players who like to complete may be given a game that provides easier completion, and so on.

In addition, the BEA tools 254 of the game development platform 125 may be used to pair players together in a multiplayer game based on their respective motivations and/or behaviors. For example, based on the judgment of the BEA tool, a valuable player who likes playing a drama may be retained by routinely pairing him or her with an inexperienced player. In another example, a player determined to be cheating by the BEA facility may be paired with other such players or cheating-neutral players, thereby avoiding other players from being struck by cheating opponents, or the like.

Although described above in connection with generating BEA data for a game, the techniques described above may also be applied to other industries. The method can be used for modeling and generating human experiences, and can be used in any research field or industrial department related to human behaviors and experiences. The potential applications of this process are wide ranging and include areas such as creative industry, marketing, retail, web services, construction and built-up environments, cyber-physical systems, automotive industry, and digital arts. Generating and generally experiencing personas not only takes advantage of the ability to test, develop, and provide services more quickly and efficiently. They also enable better (role-driven) decisions from conception to all ways of prototyping, producing and publishing services, items or objects with which humans will interact.

Fig. 4 presents a flowchart representation of a method in accordance with an embodiment of the present disclosure. In particular, a method is proposed for any of the functions and features described in connection with fig. 1 to 2, 3A and 3B. In step 400, a gaming robot model corresponding to a gaming robot, such as any of the gaming robots 350 previously described, is generated.

Step 402 includes receiving game output from a game application (app), such as game application 348. Step 404 includes generating game input to the game application via the gaming robot model, wherein the game input corresponds to game play of one or more simulated players. Step 406 includes generating game performance data in response to simulating game play of a player. The game performance data may be used to more quickly evaluate the game content; randomly evaluating the difficulty of the level by using thousands of play methods; and may include Key Performance Indicators (KPIs) or other game analysis.

Fig. 5 presents graphical representations 500 and 510 of game telemetry data according to an embodiment of the disclosure. Specifically, game telemetry data in the form of actual game output is at time t ₁ Is presented in graph 500, and at time t ₂ Is presented in diagram 510. Game telemetry data includes a character 502 generated by a game robot model, such as game robot 250, another AI character, or other AI. Game telemetry also includes characters 504 generated by the actual player, such as the master player that the gaming robot model is attempting to mimic or simulate.

The game development application 246 generates a difference between the position of the character 502 and the position of the character 504. In the example shown in game telemetry 500, time t ₁ Difference d (t) of ₁ ) Measured as the Euclidean distance (Euclidean distance) between the centroids of characters 502 and 504. In the example shown by game telemetry 510, time t ₂ Difference d (t) of ₂ ) Measured as the euclidean distance between the centroids of characters 502 and 504. Taking into account the time period t ₀ To t _n Corresponding to, for example, the length of time it takes for the primary player to complete the level, the length of time of the sample of the primary player's game track, or some other time interval, may be determined by d (t) for i =0, n _i ) Are integrated or summed to generate difference data.

The difference data generated in this manner can be used as a measure of fit to update the gaming robot to more closely mimic the master player. For example, gaming robot 250 may use reinforcement learning to learn how to "track" a human master player, while also learning from the environment how to handle new, unseen conditions. Distance measurements from the master to the shadow are used to understand how close it is to replicating human behavior. It should be noted that the value d (t) _i ) May be a linear distance measurement, a logarithmic distance measurement, or a distance measurement converted by some other non-linear function. Further, although described above as Euclidean distances, other distances including non-Euclidean distances may be equally employed.

Although described above in terms of cumulative distance measurements, the difference data may include one or more other measurements in addition to or instead of distance, for example over time period t ₀ To t _n During which the difference in cumulative game score between the gaming robot and the human player, at time period t ₀ To t _n During which the difference in game achievement between the gaming robot and the human player, at time period t ₀ To t _n Differences in time to reach a game goal between the game robot and the human player, differences in other game metrics or other game analysis between the game robot and the human player, and/or any combination thereof.

Fig. 6 presents a flowchart representation of a method in accordance with an embodiment of the present disclosure. In particular, a method for any of the functions and features described in connection with fig. 1 to 2, 3A, 3B, 4 and 5 is proposed. Step 602 includes generating a gaming robot. Step 604 includes receiving game telemetry from a game application corresponding to an actual player. Step 606 includes generating game telemetry from a game application corresponding to the gaming robot.

Step 608 includes updating the gaming robot based on difference data generated from game telemetry data corresponding to the actual player and game data corresponding to the gaming robot, the difference data indicating a time-varying distance between a first character generated by the actual player and a second character generated by the gaming robot.

Fig. 7 presents a flowchart representation of a method in accordance with an embodiment of the present disclosure. In particular, a method for any of the functions and features described in connection with fig. 1 to 2, 3A, 3B, and 4 to 6 is proposed. Step 702 includes generating a Behavioral Experience Analysis (BEA) tool based on preference learning. Step 704 includes receiving game telemetry data from the game application. Step 706 includes generating a predicted user experience, such as motivation and/or behavior, by applying the BEA tool to the game telemetry data. Step 708 includes optimizing the game and/or player experience based on the predicted user motivation and/or behavior.

Fig. 8 presents a flowchart representation of a method in accordance with an embodiment of the present disclosure. In particular, a method for any of the functions and features described in connection with fig. 1 to 2, 3A, 3B, and 4 to 7 is proposed. Step 800 includes receiving, via a system comprising a processor, program content based on prior game content. Step 804 includes iteratively improving program content via the system based on machine learning and game trajectory data and/or behavioral motivational data from a simulated game of the gaming robot. Step 806 includes generating, via the system, candidate game content based on the improved program content.

Fig. 9 presents a flowchart representation of a method in accordance with an embodiment of the present disclosure. In particular, a method for any of the functions and features described in connection with fig. 1 to 2, 3A, 3B, and 4 to 8 is proposed. Step 902 includes receiving, via a system comprising a processor, a game application corresponding to a game. Step 904 includes updating, via the system, the gaming application based on game play of the at least one non-emulated gaming robot to generate a first updated gaming application corresponding to the first updated game. Step 906 includes generating, via the system, at least one mock gaming robot based on first game telemetry data generated in response to play of a first updated game by a first plurality of actual players. Step 908 includes generating, via the system, behavioral Experience Analysis (BEA) data based on the play of the first updated game by the first plurality of actual players. Step 910 includes generating, via the system, at least one BEA tool based on the BEA data. Step 912 includes updating, via the system, the first game application based on the playing of the first updated game by the at least one mock gaming robot to generate a second updated game application corresponding to the second updated game. Step 914 includes generating, via the system, a predicted player experience based on second telemetry data generated in response to play of a second updated game by a second plurality of actual players. Step 916 includes updating, via the system, the second game application based on the predicted player experience to generate a third updated game application corresponding to a third updated game.

Fig. 10A and 10B present graphs according to embodiments of the present disclosure. As previously discussed, the PCG tool 252 may generate new developmental games, checkpoints, or other content by learning instances provided by game developers to the game development platform 125 to seed artificial intelligence models and generate new candidate content for evaluation. In particular, the PCG tool 252 may employ a machine learning model as a content generator for a game. In various instances, PCGML uses machine learning algorithms to learn the appropriate invariants of its trained content, such that content sampled from the learned model preserves the "style" of the content, while introducing diversity in new checkpoints. For example, if trained on a platform game level, the model may learn the maximum gap length that it can generate to still obtain a playable level, but may also introduce new challenges and scenarios (e.g., gap combinations) not present in the original level. Such use of the PCG tool 252 allows game developers using the game development platform 125 to utilize pre-generated developmental games, levels, and/or other content to increase their productivity; focus on concepts and important details rather than the trivial layout; created starting with the generated instance instead of a blank canvas, and/or generating content based on the style and preferences learned from previous game developers that the game developers provided to the spawner instance of the game development platform 125.

In various embodiments, a Symmetric Markov Random Field (SMRF) model may be used to generate new game content in conjunction with the artificial intelligence of the PCG tool 252 of the game development platform 125. Markov Random Fields (MRFs) can be used to model relationships between variables in a graph by modeling the probability of random variable X (which corresponds to a vertex in the graph) taking values given the neighbors of the variables. Or P (X = X | neighbor (X)). In this case, MRF typically uses a local neighborhood defined as 4 or 8 pixels/grid positions adjacent to the current pixel/grid position.

Other approaches have explored non-local neighbors and dynamic neighborhoods of MRFs. In particular, some approaches use longer range dependencies, and the particular neighbors selected vary depending on the content of the patch around the current variable and potentially other neighbors. Some approaches have used remote neighbors defined by including nodes that are further and further away from the current location. However, these neighborhood functions do not change based on content or spatial location in the graph. Some approaches have used adaptive neighborhoods for each variable based on the strength of the relationship between the current variable and other variables in a predefined region. However, these methods are limited to predefined local regions when defining neighbors rather than neighbors of arbitrary distance.

The symmetric MRF introduced herein modifies the standard MRF neighborhood formula by including symmetric positions in the graph in addition to local neighbors. SMRF defines different neighbors based on spatial relationships between variables in the graph rather than on content. This results in an MRF neighborhood that includes non-local neighbors and is able to capture a particular symmetry relationship in the graph. This makes the methods described herein more suitable for generating tasks, where the content of each variable may not be well defined initially. Furthermore, while MRF has been used for image and texture processing tasks such as image denoising, image filling, and signal reconstruction, in contrast, the methods discussed herein provide improvements in the field of game content generation, including image composition, game level generation, and other content composition. As a result, game development techniques are improved by automatic game content generation that more quickly and accurately mimics the content and features of existing games.

Standard markov random field definition:

formally: given a undirected graph G = < V, E >, a set of random variables X corresponding to vertices V forms a markov random field if the markov property is satisfied:

1. paired Markov property: any two non-adjacent variables are condition independent

2. Local Markov Properties: a variable is conditionally independent of all other variables given its neighbors.

3. Global markov property: any two subsets of variables are conditionally independent given separate sets of variables.

Informal: the markov random field is defined by a neighborhood structure that defines which variables in the graph depend on each other. This essentially models the relationship between the variable and its neighbors.

Typically, MRF uses a neighborhood of spatially local nodes in the graph. Namely for example: x is the current variable/vertex, 1 is the dependent variable/vertex, and 0 is independent of X, as shown in the example graph of FIG. 10A.

Symmetric markov random field expansion:

the SMRF model employed herein may employ local MRF neighborhoods that use neighborhoods of spatially local nodes in the example graph of fig. 10A and global neighborhoods that potentially include distant symmetric locations in the graph shown in fig. 10B. Namely for example: x is the current variable/vertex, 1 is the dependent variable/vertex, and 0 is independent of X. This shows a network structure with horizontally, vertically and diagonally symmetric nodes.

The difference between SMRF and standard MRF is that

Smrf uses non-local neighbors in the network structure; and

2. in SMRF, the network positioning of neighboring vertices/variables relative to the current vertex changes depending on the position of the current vertex in the graph, i.e., local neighbors remain the same, but symmetric neighbors may be far or close to the current vertex, depending on their distance from the center of the graph.

Fig. 10C presents a flowchart representation of a method in accordance with an embodiment of the present disclosure. A method as described in connection with figures 1 to 2, 3A, 3B and 4 to 9 is proposed for any of the functions and features. In particular, a method is presented for generating new game content using a symmetric Markov random field model in conjunction with PCG tool 252 or other uses of game development platform 125.

Step 1002 includes generating a graphic of existing game content via image analysis. Step 1004 includes generating a Symmetric Markov Random Field (SMRF) model based on the graph. Step 1006 includes automatically generating new game content based on the SMRF model via iterative artificial intelligence.

In various embodiments, each graphic of the existing game content represents a position of a plurality of game elements in the existing game content. The SMRF model may comprise a conditional probability distribution indicative of a subset of the plurality of game elements that are likely to be within a predetermined distance of each other in the graphic.

Step 1006 may include: selecting a candidate figure based on the frequency of occurrence of the plurality of game elements; generating an improved candidate graph based on the SMRF model; and generating new game content based on the improved candidate graph. The improved graph may be generated based on Mei Teluo bolis-costing (Metropolis-Hastings) sampling or other AI-based techniques.

Step 1006 may include: generating candidate new game content based on the improved candidate graph; testing candidate new content via game play with a gaming robot (e.g., one or more gaming robots 250); and accepting the candidate new game content as new game content based on game play with the game robot. In this way, when one or more gaming robots determine that new gaming content is playable (e.g., no dead ends, endless loops, likely to complete) and furthermore has a predicted user experience greater than a user experience threshold, it may be accepted as viable new content. The use of artificial intelligence rather than human intelligence allows the gaming robot 250 to perform at speeds and with consistency that cannot practically be performed in the human mind, and further improves the techniques of game development.

Various embodiments including several optional functions and features may be further described in connection with the following examples.

Consider the case of modeling and generating video game levels for 2D games. To do so, the method takes an image of the level and converts it into a graphic, such as a tile-based grid representation of the different game elements in a grid array of tiles. In the illustrated example, the image is analyzed by image analysis, such as a computer vision model, pattern recognition techniques, or other artificial intelligence model that assigns unique symbols to each type of game element present in each square grid of the image. For example, a portion of the game super marrio sibling level presented in fig. 11A is used for training based on the 13 x 13 graphical representation (which may also be referred to as an array or tile grid) presented in conjunction with fig. 11B. In the example shown below, the following symbols are used to represent the indicated type of game element:

b = brick

M = mushroom power-up

G = enemy

Is there a Element of type = hidden

# = grounded

p P [ ] (sum over 2x2 area of tile) = pipe

Note that a marker tile "s" is added to represent the boundary of the level in the grid. Although marker boundaries are used at the left and lower edges of the graph, marker tiles may also be located on the upper and right boundaries. Further, tiles corresponding to "empty" elements of the game (e.g., clouds, sky, foliage, etc.) may be assigned a common symbol "-" indicating that they are not active game elements. In the above example, certain game elements are represented by generic symbols that may represent multiple game element types/subtypes. For example, "G" represents any of a plurality of enemy types, "M" represents any of a plurality of power-up types, "? "means any of a number of elements that can be hidden, including coins of different value, different types of power-up, and the like. In other instances, a separate symbol may be used to uniquely represent each particular type of game element. In this way, "M6" may represent the sixth power-up. "? C3 "may represent a third monetary value that is hidden, G9 may represent a ninth enemy, and so on. In either case, the process may be repeated for a plurality of game images of an existing game in order to construct a training data set representing a tile grid/graphic of the existing game.

In various embodiments, machine learning is used to model relationships between different tile types and/or sub-types (in general or in particular) and their corresponding (e.g., relative) locations in existing games. In particular, the SMRF model is trained on a tile grid of a training dataset, learning the relationships between different tile types/subtypes and locations and adjacent grid locations, which may be local and may also include symmetric and possibly non-local neighbors. For example, the SMRF model indicates a subset of the plurality of game elements that may be located within a predetermined distance from each other in the graphic, and produces a conditional probability distribution that describes which tile types are typically located at or relative to each other in a particular configuration, as presented by a training data set of a tile grid in an existing game.

Consider a further example of the local MRF model presented in connection with fig. 11C and 11D. A portion of the level of the game supermario brother (Super Mario Brothers) presented in fig. 11C is used for training based on the 10x12 graphical representation presented in connection with fig. 11D. In the example shown, the following symbols are used to represent the indicated types of game elements:

e = null

Q = power block

X = ground

S = boundary

Consider the neighborhood defined by the following relative grid positions:

0	1	0
			1	2	1
0	1	0

where 2 represents the current grid position, grid position 1 is included in the neighborhood and grid position 0 is not included in the neighborhood. The possible combinations of tiles at the four 1 locations yield a configuration for each possible current tile location 2. The occurrence of these configurations may be accumulated in the graph of fig. 11D for all possible current positions 2. The results are presented in the table of fig. 11E. The conditional probabilities for each of the neighborhood configurations in the model are presented in the table of FIG. 11F. Although the neighborhood used in the above example is based on a local MRF model, the SMRF model may equally be used to generate conditional probabilities for the corresponding configuration as previously discussed.

The method can then employ an iterative search algorithm, such as Mei Teluo bolis-blacknstein sampling or other iterative artificial intelligence techniques, to generate one or more new checkpoints. For example, the method first randomly populates tile grids with different tile types/subtypes according to their overall frequency in the training data (e.g., 70% empty tile type, 15% grounded type, 10% enemy, 5% power up, etc.). The method then randomly selects two locations in the graph, calculates the likelihood of tile configurations for those locations based on the conditional probabilities of the SRMF model, and calculates the likelihood of tiles if locations are to be swapped. If the likelihood of swapping is high, the method keeps them swapped. The method is iterated multiple times (e.g., thousands of times, tens of thousands or more) until the overall likelihood of the level is above a threshold or within a predetermined range.

In effect, the PCGML operates to inherently learn invariant patterns from a set of instances of existing games. The type and size of the pattern captured is largely determined by the underlying machine learning method, training data, and their representation. The term "schema" has different meanings in different fields, but the term generally describes regularity within a given object. In the context of frequent pattern mining, this means a collection of items, sub-sequences, or sub-structures that occur multiple times. The most prominent use of patterns in games is that multiple shapes can be used in a game design pattern, including fairly abstract patterns related to the overall game design, as well as finer grained and visible spatial patterns that define specific relationships between tiles that can be learned by PCGML.

Consider the following additional example of a Candy crumbling legend (CCS), a free trivia puzzle game released by King in 2012, which thereafter has had great success as one of the top-level mobile casual games. In a CCS, three or more candies (tiles) may be horizontally or vertically matched with adjacent candies of the same color. When matched, the candy disappears from the board. If there are no items to block, this causes the existing candy to drop and fill the resulting gap and create a new candy of random color (usually on top of the board). The game introduces various limits, barriers and goals that together define each level, thereby creating a puzzle of varying difficulty. In the context of CCS, the following terminology may be used:

global mode: patterns that can only be identified by observing the spatial structure of all elements on the game board.

Local mode: patterns that can be identified in a small area of the game board.

CCS checkpoints typically exhibit a global pattern that is generally considered aesthetically pleasing or eye-catching. Examples include placing items on a chessboard in recognizable shapes or in a symmetrical arrangement (see, e.g., the blue square area of fig. 12B). There are also checkpoints that repeat smaller local patterns. A common example is that candies with additional beneficial effects are surrounded by deterrent items, making them more difficult to use (see, e.g., red and green square areas of fig. 12A). The level may display local and global modes. The global aspect of CCS differs from other applications of PCGML, such as super marrio brothers, where many primary game elements (gaps, pipes, enemy groups, etc.) may be defined using local tile neighborhoods. To this end, PCGML is employed on the CCS to inherently learn different types of patterns, including, for example, local and global patterns. Consider the following three methods described in detail in the following sections.

1. Enriching data

One way to encourage the generation of a particular type of pattern is to enrich the data for training. The explicit way to do this is by marking each instance with the type of global mode displayed. Conditional generation countermeasure networks (GANs) are examples of AI techniques well suited to handling such data. The model can also be trained on each class separately. Both options aim at enhancing the signal around the global pattern present in the data. In addition, data-driven approaches can be employed to enrich the data and use unsupervised learning to automatically recognize class labels. A corresponding method with a classifier encoding the learned deviations is also possible if limited label data is available.

2. Extended algorithm

Another strategy to improve the model is to augment the algorithm to ensure that it focuses on one or more desired patterns. If domain knowledge is available, this can be done explicitly by modifying the structure of the model to detect the desired pattern. For example, to generate an MRF model with symmetry, positions that should be mirrored at a given position may be added as inputs to the algorithm.

Another approach is to feed metrics describing the desired features (e.g., symmetry scores) to the algorithm, so as to facilitate identification of fitness of the individual based on the desired features. This can be done, for example, by giving additional input to the discriminator of the GAN. While these methods may generate content that exhibits the desired characteristics, they may rely on domain knowledge and the ability to numerically characterize the characteristics.

Another approach is not to rely on domain knowledge, but to ensure that the inputs at least allow the algorithm to establish connections between items on the scale of the desired global pattern. An example of such a data driven approach is to add a fully connected layer in the GAN as the first layer of the discriminator. Another approach is to add the location of each input (e.g., as coordinates) to the inputs of the neural network. There are methods with learned deviations between these two extremes. Such deviations can be learned by labeling samples or opponent training and then given as additional input to the model.

3. Filtering solution

A third approach is a filtering solution, which is the simplest if done explicitly, but it is conceivable to learn the desired patterns and ways to identify them. The filtering may be performed at different times during the training process. Before training will mean creating a representation that encodes only the solution with the desired global pattern. For example, in the symmetric case, only half of the levels are generated and automatically mirrored to build the final level. The solution may also be repaired to comply with the pattern (e.g., by mirroring) during or after training. A further option for post-training filtering is to apply a search algorithm to the space in which the content is generated, e.g., the potential vector evolution of GAN.

Continuing with the PCGML example of CSS, note that the CCS contains approximately 80 game elements with different characteristics. Some checkpoints rely on unique mechanisms or game elements, which make them difficult to replicate. To this end, a subset of the published CCS checkpoints may be selected for more homogenous training. Specifically, levels are selected from a particular game model (jelly) and levels containing complex dynamic elements (e.g., frogs and carousels) are discarded to generate 504 levels for training. There are still 51 unique items in the reduced level set. Some items may be stacked on the same cell in the checkerboard, and there are 789 unique stacks of items in the training data set.

To reduce the complexity of the representation, an abstract representation of the following CCS checkpoint is generated:

shape: indicating which game board cell is non-empty.

Rule: six types of common candies that can be matched with other candies of the same color.

Special: matchable items with additional effects

Block: blocking matched items by occupying cells

Jelly: in the jelly game mode, items indicating cells for which matching needs to occur to win the level are indicated.

Locking: blocking matched items by restricting movement of items in the same cell

For the six categories mentioned above, each level is represented as a matrix having a size of 9 x 6 with a binary code to represent the occurrence of the category of items in a given cell.

In order to be able to ensure the validity of the generated CCS checkpoint, the following post-processing method may be introduced. The first four layers cannot coexist in the same cell. The selection of each cell is determined by selecting the layer with the highest value. However, if no value is above the threshold (e.g., 0.5), the cell is indicated as empty. Furthermore, it is only allowed to place locks on non-empty or empty cells, and jellies on non-empty cells only.

To keep the complexity of the level representation low, the following post-processing steps can be added to all levels, including the original level: and (1) producing the candy through candy processing. The candy cannon is not included in the presentation so it is automatically placed over the non-empty cell to ensure that new candy is dropped. (2) Additional, complex dynamic elements (e.g., transfer gates, special candy cannons) are removed from the game to avoid introducing unnecessary complexity. (3) No further game metadata is included, such as the number of available movements in the representation.

Two different MRF techniques were evaluated, a routine called localmerf-MRF that fits the sample neighborhood of fig. 12C and a routine called GlobalMRF-SMRF that includes local and non-local symmetric neighbors that fit the sample neighborhood of fig. 12D. To use these models with CCS, the six-layer representation is compressed into a single-layer representation, where the value at a location is a concatenation of the values in each layer. Thus, each possible combination of values for the six layers is treated as a different tile type.

Given the strict local neighborhood of the model, the checkpoint generated by LocalMRF results in a very low score for horizontal and vertical symmetry, and therefore a greater difference from the traditional CSS checkpoint. Extending the neighborhood with symmetric neighbors (GlobalMRF) significantly increases the symmetry score along the horizontal and vertical axes and results in greater similarity to the traditional CSS checkpoint.

Two different GAN techniques were also evaluated. The first GAN model discriminator uses a filter that produces 9 x 9 patches-the entire checkpoint in the case of CCS. The first variant was trained on the entire set of checkpoints (GlobalGAN), the second variant was trained only on the vertically symmetric checkpoints (GlobalGAN-vert). It should be noted that in other variations, two convolution streams may be employed, one with a 9 × 9 filter for global mode and one with a 3 × 3 filter for local mode. The results show that GlobalGAN produces an average score on the checkerboard, whereas a clear improvement in vertical symmetry is achieved by using (GlobalGAN-vert) to train only on the vertical symmetry level. However, the fractional boost is not large, probably because most of the original checkpoints are already vertically symmetric.

As previously discussed, the gaming robot may further verify the candidate level generated in this manner by determining that the new game content is playable and has a predicted user experience greater than a user experience threshold. The use of artificial intelligence, rather than human intelligence, to perform the various elements of the process allows the PCG tool 252 to perform at speeds, accuracies, and consistencies that are virtually impossible to perform in the human brain. While several examples have been described above in terms of a single process based on conditional tile type probabilities, the above process may be repeated in a hierarchical manner to first consider tile types and then perform extended sampling based on the subtype of the selected tile type. Further, the AI bot can be used to evaluate particular subtypes of selected tile types in order to enhance or maximize the predictive metrics of the viewer/user experience.

It should be noted that terms (e.g., bitstream, stream, signal sequence, etc. (or equivalents thereof)) that may be used herein interchangeably have been used to describe digital information (e.g., data, video, voice, text, graphics, audio, etc., any of which may be generally referred to as "data") whose content corresponds to any of several desired types.

As used herein, the terms "substantially" and "approximately" provide an industry-accepted tolerance for the relativity between their corresponding terms and/or items. For some industries, the industry-acceptable tolerance is less than 1%, while for other industries, the industry-acceptable tolerance is 10% or more. Other examples of industry-acceptable tolerance ranges from less than 1% to 50%. Industry-accepted tolerances correspond to, but are not limited to, component values, integrated circuit process variations, temperature variations, rise and fall times, thermal noise, dimensions, signal errors, dropped packets, temperature, pressure, material composition, and/or performance metrics. Tolerance differences to acceptable tolerances in the industry may be greater or less than a percentage level (e.g., dimensional tolerances less than +/-1%). Some correlations between items may range from less than a percentage level of difference to a few percent. Other correlations between items can range from a few percent difference to a large difference.

As also used herein, the terms "configured to," "operatively coupled to," "coupled to," and/or "coupled" include direct couplings between items and/or indirect couplings between items via intermediate items (e.g., items including, but not limited to, components, elements, circuits, and/or modules), where, for the example of indirect coupling, intermediate items do not modify the information of a signal but may adjust its current level, voltage level, and/or power level. As may be further used herein, inferred coupling (i.e., where one element is coupled to another element by inference) includes direct and indirect coupling between two items in the same manner as "coupled to".

As may be used even further herein, the terms "configured to," "operable to," "coupled to," or "operably coupled to" indicate that an item includes one or more of a power connection, an input, an output, etc., to perform one or more of its corresponding functions when activated, and may further include inferred coupling with one or more other items. As may be further used herein, the term "associated" includes a direct and/or indirect coupling of an individual item and/or one item embedded within another item.

As used herein, the term "compares favorably", indicates that a comparison between two or more items, signals, etc., provides a desired relationship. For example, when the desired relationship is that the amplitude of signal 1 is greater than the amplitude of signal 2, a favorable comparison may be achieved when the amplitude of signal 1 is greater than the amplitude of signal 2 or when the amplitude of signal 2 is less than the amplitude of signal 1. As used herein, the term "disadvantageously compares" means that a comparison between two or more items, signals, etc., does not provide a desired relationship.

As may be used herein, one or more claims may include the phrase "at least one of a, b, and c" in a particular form of the common form or "at least one of a, b, or c" in the common form, having more or less elements than "a", "b", and "c". In any of the phrases, the interpretation of the phrase is the same. Specifically, "at least one of a, b, and c" is equivalent to "at least one of a, b, or c" and shall mean a, b, and/or c. By way of example, it means: only "a", only "b", only "c", "a" and "b", "a" and "c", "b" and "c" and/or "a", "b" and "c".

As also used herein, the terms "processing module," "processing circuit," "processor," "processing circuit," and/or "processing unit" may be a single processing device or a plurality of processing devices. Such a processing device may be a microprocessor, microcontroller, digital signal processor, microcomputer, central processing unit, field programmable gate array, programmable logic device, state machine, logic circuitry, analog circuitry, digital circuitry, and/or any device that manipulates signals (analog and/or digital) based on hard coding of circuits and/or operational instructions. The processing module, processing circuit, processing circuitry, and/or processing unit may be or further include memory and/or integrated memory elements, which may be a single memory device, multiple memory devices, and/or embedded circuitry of another processing module, processing circuit, processing circuitry, and/or processing unit. Such a memory device may be a read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, cache memory, and/or any device that stores digital information. Note that if the processing module, processing circuit, processing circuitry, and/or processing unit includes more than one processing device, the processing devices may be centrally located (e.g., directly coupled together via a wired and/or wireless bus structure) or may be distributively located centrally (e.g., cloud computing indirectly coupled via a local area network and/or a wide area network). It is further noted that if the processing module, processing circuit, processing circuitry, and/or processing unit implements one or more of its functions via a state machine, analog circuitry, digital circuitry, and/or logic circuitry, the memory and/or memory elements storing the corresponding operational instructions may be embedded within, or external to, the circuitry comprising the state machine, analog circuitry, digital circuitry, and/or logic circuitry. It should also be noted that the memory elements may store and the processing modules, processing circuits, processing circuitry, and/or processing units execute hard-coded and/or operational instructions corresponding to at least some of the steps and/or functions depicted in one or more of the figures. Such memory devices or memory elements may be included in an article of manufacture.

One or more embodiments have been described above with the aid of method steps illustrating the performance of specified functions and relationships thereof. Boundaries and the order of these functional building blocks and method steps have been arbitrarily defined herein for convenience of description. Alternate boundaries and sequences may be defined so long as the specified functions and relationships are appropriately performed. Accordingly, any such alternate boundaries or sequences are within the scope and spirit of the claims. Further, boundaries of these functional building blocks have been arbitrarily defined for the convenience of the description. Alternate boundaries may be defined so long as some important functions are properly performed. Similarly, flow block diagrams may also be arbitrarily defined herein to illustrate certain important functions.

To the extent used, block diagram boundaries and sequences may be defined in other ways and still perform some important functions. Accordingly, such replacement of functional building blocks and flow block and sequences is defined within the scope and spirit of the claims. Those of ordinary skill in the art will also recognize that the functional building blocks and other illustrative blocks, modules, and components herein can be implemented as depicted or by discrete components, application specific integrated circuits, processors executing appropriate software, etc., or any combination thereof.

Additionally, the flow diagrams may include "start" and/or "continue" indications. The "start" and "continue" indications reflect that the presented steps may optionally be incorporated into or otherwise used in conjunction with one or more other routines. Additionally, the flow chart may include an "end" and/or "continue" indication. The "end" and/or "continue" indications reflect that the presented steps may end as described and illustrated, or optionally be incorporated in or otherwise used in connection with one or more other routines. In this context, "start" indicates the start of the first step presented, and may be performed prior to other activities not specifically shown. Further, the "continue" indication reflects that the presented step may be performed multiple times and/or may be continued by other activities not specifically shown. Further, while the flow chart indicates a particular order of steps, other orders are equally possible as long as the causal principles are maintained.

One or more embodiments are used herein to illustrate one or more aspects, one or more features, one or more concepts, and/or one or more examples. Physical embodiments of devices, articles, machines and/or processes may include one or more aspects, features, concepts, examples, etc. described with reference to one or more embodiments discussed herein. Further, from figure to figure, embodiments may incorporate the same or similarly named functions, steps, modules, etc., which may use the same or different reference numbers, and the functions, steps, modules, etc., may be the same or similar functions, steps, modules, etc., or different functions, steps, modules, etc.

Signals to, from, and/or between elements in the figures of any of the figures presented herein may be analog or digital, time-duration or discrete-time, and single-ended or differential, unless specifically noted. For example, if the signal path is shown as a single-ended path, it also represents a differential signal path. Similarly, if the signal path is shown as a differential path, it also represents a single-ended signal path. Although one or more particular architectures are described herein, other architectures using one or more data buses, direct connections between elements, and/or indirect couplings between other elements not explicitly shown may also be implemented, as will be recognized by those of ordinary skill in the art.

The term "module" is used in the description of one or more embodiments. A module implements one or more functions via, for example, a processor or other processing device or other hardware that may include or operate in association with a memory that stores operating instructions. The modules may operate independently and/or in conjunction with software and/or firmware. As used herein, a module may contain one or more sub-modules, each of which may be one or more modules.

As further used herein, computer-readable memory includes one or more memory elements. The memory element may be a single memory device, multiple memory devices, or a group of memory locations within a memory device. Such a memory device may be a read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, cache memory, quantum register or other quantum memory, and/or any other device that stores data in a non-transitory manner. Further, the memory device may be in the form of solid state memory, hard drive memory or other disk storage, cloud storage, thumb drive, server memory, computing device memory, and/or other non-transitory media for storing data. Storage of data includes temporary storage (i.e., data is lost when power is removed from the memory element) and/or persistent storage (i.e., data is retained when power is removed from the memory element). As used herein, a temporary medium shall mean one or more of the following: (a) Wired or wireless media for transmitting data as signals from one computing device to another for temporary or persistent storage; (b) A wired or wireless medium for transmitting data as a signal within a computing device from one element of the computing device to another element of the computing device for temporary or persistent storage; (c) Wired or wireless media for transmitting data as signals from one computing device to another for processing of the data by the other computing device; and (d) a wired or wireless medium for transmitting data from one element of the computing device to another element of the computing device as a signal within the computing device for processing the data by the other element of the computing device. As used herein, a non-transitory computer readable memory is substantially equivalent to a computer readable memory. The non-transitory computer readable memory may also be referred to as a non-transitory computer readable storage medium.

While particular combinations of features and characteristics of one or more embodiments have been described explicitly herein, other combinations of features and functions are also possible. The present disclosure is not limited to the specific examples disclosed herein, and these other combinations are expressly incorporated.

Claims (20)

1. A game development platform, comprising:

a machine, comprising:

a processing circuit; and

a non-transitory computer-readable storage medium configured to store a gaming application and further operational instructions that, when executed by the processing circuit, cause the processing circuit to perform operations comprising:

generating a graphic of the existing game content via image analysis;

generating a Symmetric Markov Random Field (SMRF) model based on the graph; and

automatically generating new game content based on the SMRF model via iterative Artificial Intelligence (AI).

2. The game development platform of claim 1, wherein each of the graphics of the existing game content represents a location of a plurality of game elements in the existing game content.

3. The game development platform of claim 2, wherein the SMRF model comprises a conditional probability distribution indicating a subset of the plurality of game elements that are likely to be within a predetermined distance of each other in the graphic.

4. The game development platform of claim 2, wherein the SMRF model is trained via machine learning based on the graphics.

5. The game development platform of claim 2, wherein the iterative AI operates by:

selecting a candidate graphic based on the frequency of occurrence of the plurality of game elements;

generating an improved candidate graph based on the SMRF model; and

generating the new game content based on the improved candidate graphics.

6. The game development platform of claim 5, wherein the refined candidate graphics are generated based on Mei Teluo bolis-blacknstein samples.

7. The game development platform of claim 5, wherein generating the new game content based on the refined candidate graphics comprises:

generating candidate new game content based on the improved candidate graphics;

testing the candidate new content via game play with a gaming robot; and

accepting the candidate new game content as the new game content based on the game play with the gaming robot.

8. The game development platform of claim 7, wherein the game play is an AI simulated game play of the new game content performed by the gaming robot.

9. The game development platform of claim 7, wherein the candidate new game content is accepted as the new game content when a predicted user experience associated with the game play exceeds a threshold.

10. The game development platform of claim 7, wherein the candidate new game content is accepted as the new game content when the game play indicates that the new game content is playable.

11. A method for implementing a program content generation tool, comprising:

generating a graphic of the existing game content via image analysis;

generating a Symmetric Markov Random Field (SMRF) model based on the graph; and

automatically generating new game content based on the SMRF model via iterative Artificial Intelligence (AI).

12. The method of claim 11, wherein each of the graphics of the existing game content represents a location of a plurality of game elements in the existing game content.

13. The method of claim 12, wherein the SMRF model comprises a conditional probability distribution indicative of a subset of the plurality of game elements that are likely to be within a predetermined distance of each other in the graphic.

14. The method of claim 12, wherein the SMRF model is trained via machine learning based on the graph.

15. The method of claim 12, wherein the iterative AI operates by:

selecting a candidate graphic based on the frequency of occurrence of the plurality of game elements;

generating an improved candidate graph based on the SMRF model; and

generating the new game content based on the improved candidate graphics.

16. The method of claim 15, wherein the refined candidate graph is generated based on Mei Teluo bolis-blackins sampling.

17. The method of claim 15, wherein generating the new game content based on the refined candidate graphic comprises:

generating candidate new game content based on the improved candidate graphics;

testing the candidate new content via game play with a gaming robot; and

accepting the candidate new game content as the new game content based on the game play with the gaming robot.

18. The method of claim 17, wherein the gameplay is an AI simulated gameplay of the new game content performed by the gaming robot.

19. The method of claim 17, wherein the candidate new game content is accepted as the new game content when a predicted user experience associated with the game play exceeds a threshold.

20. The method of claim 17, wherein the candidate new game content is accepted as the new game content when the gameplay indicates that the new game content is playable.

Images