Method of generating non-player character schedules and schedule generation model training method

Abstract

This application provides a method for generating a schedule for a non-player character, comprising: obtaining scene information corresponding to the game map of the target game, including area information indicating multiple areas in the game map, atmosphere information indicating the environmental conditions of each area in different time periods of the target game, and point information indicating specific locations within each area; obtaining the identity information of the target non-player character, including at least the name information, occupation information, and character introduction of the target non-player character; and generating a schedule for the target non-player character using a trained first language model based at least on the scene information, identity information, and candidate game actions corresponding to the target non-player character. The candidate game actions are obtained by selecting corresponding game actions as candidate game actions from an entity knowledge base based on at least one of the scene and identity information. The entity knowledge base is pre-constructed based on at least a number of game actions pre-designed for the target game.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method, apparatus, computing device, computer-readable storage medium, and computer program product for generating schedules for non-player characters. Furthermore, this application also relates to a method for training a schedule generation model. Background Technology

[0002] In recent years, with the rapid development of the game industry, various types of games have emerged, attracting a large number of players. Whether in open-world games, role-playing games (RPGs), simulation games, or other types of games, non-player characters (NPCs) are important elements in the game, and their schedules have a significant impact on the game experience of players.

[0003] Currently, NPC scheduling relies heavily on manual design, typically involving steps such as location placement, behavior design, and timetable arrangement. However, these steps often require significant manpower, and the resulting NPC schedules are often monotonous and repetitive, making it difficult to implement complex interactive behaviors (e.g., interactions between multiple NPCs or diverse reactions based on different player actions). This not only increases development costs but also impacts the overall quality of the game and the user experience. Summary of the Invention

[0004] In view of this, this application provides a method, apparatus, computing device, computer-readable storage medium, and computer program product for generating schedules for non-player characters, in order to alleviate, mitigate, or even eliminate the aforementioned problems.

[0005] According to one aspect of this application, a method for generating a schedule for a non-player character is provided, comprising: obtaining scene information corresponding to a game map of a target game, the scene information including area information, atmosphere information, and location information, the area information indicating multiple areas in the game map, each of the multiple areas being used to host a corresponding function and a corresponding non-player character, the atmosphere information indicating the corresponding environmental conditions of each of the multiple areas in the target game at different time periods, and the location information indicating the specific location within each of the multiple areas; obtaining identity information of a target non-player character, the identity information including at least the name information, occupation information, and character description of the target non-player character; and generating a schedule for the target non-player character using a trained first language model, at least based on the scene information, the identity information, and candidate game actions corresponding to the target non-player character, wherein the candidate game actions are obtained by: selecting a corresponding game action as the candidate game action from a pre-built entity knowledge base based on at least one of the scene information and the identity information, wherein the entity knowledge base is constructed based on at least a multiple game actions pre-designed for the target game.

[0006] According to another aspect of this application, a training method for a schedule generation model is provided, comprising: obtaining sample scene information corresponding to a sample game map of a sample game, the sample scene information including sample area information, sample atmosphere information, and sample point information, the sample area information indicating multiple sample areas in the sample game map, each of the multiple sample areas being used to carry a corresponding function and a corresponding non-player character, the sample atmosphere information indicating the corresponding environmental conditions of each of the multiple sample areas in the sample game at different time periods, and the sample point information indicating the specific location within each of the multiple sample areas; obtaining multiple sample identity information corresponding to multiple sample non-player characters, each sample identity information including at least the name information, occupation information, and character introduction of the corresponding sample non-player character among the multiple sample non-player characters; Based at least on the sample scene information, the multiple sample identity information, and the multiple candidate game actions corresponding to the multiple sample non-player characters, a schedule generation model is used to generate multiple sample schedules corresponding to the multiple sample non-player characters. Each candidate game action is obtained in the following way: based on the sample scene information and at least one of the sample identity information corresponding to the corresponding sample non-player character, a corresponding game action is selected as a corresponding candidate game action from a pre-built entity knowledge base, wherein the entity knowledge base is constructed based on at least multiple game actions pre-designed for the sample game; based on the multiple sample schedules and the multiple labeled schedules corresponding to the multiple sample schedules, a target loss is determined; and the parameters of the schedule generation model are iteratively updated so that the target loss satisfies the preset training conditions.

[0007] According to another aspect of this application, an apparatus for generating a schedule for a non-player character is provided, comprising: a scene information acquisition module configured to acquire scene information corresponding to a game map of a target game, the scene information including area information, atmosphere information, and location information, the area information indicating multiple areas in the game map, each of the multiple areas being used to host a corresponding function and a corresponding non-player character, the atmosphere information indicating the corresponding environmental conditions of each of the multiple areas in the target game at different time periods, and the location information indicating the specific location within each of the multiple areas; and an identity information acquisition module configured to acquire the target non-player character's identity information. The system includes the player character's identity information, which includes at least the name, occupation, and character description of the target non-player character; and a schedule generation module configured to generate the target non-player character's schedule using a trained first language model, based at least on the scene information, the identity information, and candidate game actions corresponding to the target non-player character. The candidate game actions are obtained by selecting corresponding game actions from a pre-built entity knowledge base as candidate game actions based on at least one of the scene information and the identity information. The entity knowledge base is constructed based on at least a number of pre-designed game actions for the target game.

[0008] According to another aspect of this application, an apparatus for training a schedule generation model is provided, comprising: a sample scene information acquisition module configured to acquire sample scene information corresponding to a sample game map of a sample game, the sample scene information including sample area information, sample atmosphere information, and sample point information, the sample area information indicating multiple sample areas in the sample game map, each of the multiple sample areas being used to carry a corresponding function and a corresponding non-player character, the sample atmosphere information indicating the corresponding environmental conditions of each of the multiple sample areas in the sample game at different time periods, and the sample point information indicating the specific location within each of the multiple sample areas; and a sample identity information acquisition module configured to acquire multiple sample identity information corresponding to multiple sample non-player characters, each sample identity information including at least the name information, occupation information, and character description of the corresponding sample non-player character among the multiple sample non-player characters; The schedule generation module is configured to generate multiple sample schedules corresponding to the multiple sample non-player characters based on at least the sample scene information, the multiple sample identity information, and the multiple candidate game actions corresponding to the multiple sample non-player characters, using a schedule generation model. Each candidate game action is obtained by selecting a corresponding game action from a pre-built entity knowledge base based on the sample scene information and at least one of the sample identity information corresponding to the corresponding sample non-player character. The entity knowledge base is constructed based on at least a multiple game actions pre-designed for the sample game. The loss determination module is configured to determine a target loss based on the multiple sample schedules and the multiple labeled schedules corresponding to the multiple sample schedules. The model training module is configured to iteratively update the parameters of the schedule generation model so that the target loss meets preset training conditions.

[0009] According to another aspect of this application, a computing device is provided, comprising: a memory configured to store computer-executable instructions; and a processor configured to perform any of the methods provided according to the foregoing aspects of this application when the computer-executable instructions are executed by the processor.

[0010] According to another aspect of this application, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed, perform any of the methods provided according to the foregoing aspects of this application.

[0011] According to another aspect of this application, a computer program product is provided, including computer-executable instructions, wherein when executed by a processor, the computer-executable instructions perform any of the methods provided according to the foregoing aspects of this application.

[0012] According to the method for generating a schedule for a non-player character provided in this application, rich, multi-layered information about the target game can be obtained by acquiring scene information (including area information, atmosphere information, and location information) corresponding to the game map of the target game and identity information of the target non-player character (including at least the name information, occupation information, and character introduction of the target non-player character). Then, based at least on the scene information, identity information, and candidate game actions corresponding to the target non-player character, a trained first language model is used to generate a schedule for the target non-player character. The trained first language model can use this rich information of the target game to obtain a diverse schedule that suits the target non-player character. This reduces manpower input while enabling rich interactive behaviors of the non-player character, thereby reducing development costs and improving the user experience of the target game.

[0013] These and other aspects of this application will be clear from the embodiments described below, and will be elucidated with reference to the embodiments described below. Attached Figure Description

[0014] In the following description of exemplary embodiments in conjunction with the accompanying drawings, further details, features, and advantages of the technical solutions of this application are disclosed, as shown in the drawings:

[0015] Figure 1 The illustrations illustrate example scenarios in which the technical solutions provided according to some embodiments of this application can be applied;

[0016] Figure 2 An example flowchart illustrating a method for generating a schedule for a non-player character according to some embodiments of this application is shown schematically;

[0017] Figure 3 Schematic illustration Figure 2 A schematic diagram illustrating the method for generating schedules for non-player characters;

[0018] Figure 4 This schematically illustrates an example schematic diagram of a method for generating a schedule for a non-player character according to other embodiments of this application;

[0019] Figure 5 The schematic diagram illustrates an example of a method for generating a schedule for a non-player character according to yet another embodiment of this application;

[0020] Figure 6 The illustration shows a waypoint map generated as an NPC moves across the game map according to their schedule.

[0021] Figure 7 This schematically illustrates an example schematic diagram of a training method for a schedule generation model according to some embodiments of this application;

[0022] Figure 8 Schematic illustration Figure 7 The training method for the schedule generation model can use an example structure diagram of the training data;

[0023] Figure 9 Schematic illustration Figure 7 The training method of the schedule generation model in the example shows the input and output data structure of the schedule generation model.

[0024] Figure 10 An example block diagram illustrating an apparatus for generating a schedule for a non-player character according to some embodiments of this application is shown schematically;

[0025] Figure 11 An example block diagram illustrating an apparatus for generating a model based on a training schedule according to some embodiments of this application is shown schematically; and

[0026] Figure 12 An example system is illustrated, which includes an example computing device representing one or more systems and / or devices that can implement the various technologies described herein. Detailed Implementation

[0027] Several embodiments of this application will now be described in more detail with reference to the accompanying drawings to enable those skilled in the art to implement the technical solutions of this application. The technical solutions of this application can be embodied in many different forms and for many different purposes, and should not be limited to the embodiments set forth herein. These embodiments are provided to make the technical solutions of this application clear and complete, but the described embodiments do not limit the scope of protection of this application.

[0028] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It will be further understood that terms such as those defined in commonly used dictionaries shall be interpreted as having a meaning consistent with their meaning in the relevant field and / or the context of this specification, and shall not be interpreted in an idealized or overly formal sense unless expressly defined herein.

[0029] Figure 1 The illustration shows an example scenario 100 where the technical solutions provided according to some embodiments of this application can be applied. For example... Figure 1As shown, scenario 100 may include user 110, terminal device 120 (e.g., computer), terminal device 130 (e.g., tablet), network 140, and remote facility 150. As an example, remote facility 150 includes server 151 and optionally database device 152 for storing relevant data, and these servers or devices can communicate via network 140.

[0030] For example, on the terminal device 120 side, scene information corresponding to the game map of the target game can be obtained. This scene information includes area information, atmosphere information, and location information. The target game can be any type of game featuring non-player characters, including but not limited to various open-world games, role-playing games, simulation games, and other types of games. Furthermore, when obtaining the scene information corresponding to the game map of the target game, the number of target games can be multiple (e.g., several, dozens, hundreds, or even more). Accordingly, in this case, the multiple scene information pieces correspond to multiple game maps of multiple target games.

[0031] For example, the scene information corresponding to the game map of the target game can be stored in the database device 152 of the remote facility 150, and the terminal device 120 obtains the scene information corresponding to the game map of the target game from the database device 152 by communicating with the server 151 of the remote facility 150. Alternatively, the scene information corresponding to the game map of the target game can be stored in the terminal device 120, so that the user 110 can directly access this data by operating the terminal device 120.

[0032] The scene information, including regional information, atmosphere information, and location information, has multiple levels of detail, with each level providing detailed background and settings for the next level. Specifically, the regional information indicates multiple regions in the game map, each of which serves a corresponding function and a corresponding non-player character. These regions can also be referred to as "cultural points." For example, the regional information can describe the location and function of each region, as well as the non-player characters (hereinafter referred to as NPCs) residing in each region and their activity objectives. For instance, a cultural point could be a market, positioned as a trading center, where the NPCs are mainly merchants and customers who conduct transactions and shopping activities.

[0033] Additionally, the atmosphere information indicates the environmental conditions of each of the multiple areas within the target game at different time periods. The atmosphere information further refines the description of the cultural elements; for example, it can describe the theme and atmosphere of each area at different time periods in the target game. For instance, a morning market is bustling with the sounds of vendors hawking their wares and people strolling around, while an evening market gradually quiets down as vendors pack up their stalls to leave. Furthermore, the atmosphere information can also describe the types of NPCs within each area and their proportions (e.g., 60% are merchant NPCs, 30% are customer NPCs, and 10% are beggar NPCs). The location information indicates the specific location within each of the multiple areas.

[0034] For example, the point information can be represented by points (NavigationNode, NavNode) to indicate the specific location within each of the multiple regions, serving as reference points for NPC movement and behavior. In game development, points in the game map are part of the navigation mesh (Nav Mesh), which can be used to define the paths that NPCs can move on the map. Each point represents a location where an NPC can stand or pass through; multiple points are connected to form a path to guide the NPC to complete the corresponding movement within the game map.

[0035] Next, the terminal device 120 can obtain the identity information of the target non-player character. This identity information includes at least the target non-player character's name, occupation, and character description. Additionally, the identity information may also include other content, such as personality information describing the target NPC's character, gender information describing the target NPC, and body type information describing the target NPC's physique—one or more of these. This identity information gives the target NPC a unique personality and background, helping to enhance the game's immersion and realism. Those skilled in the art will understand that NPCs can have a wide variety of names and occupations, and the corresponding character description can be a brief description of the NPC's background story, personal history, etc. (e.g., summarized in one or a few sentences).

[0036] Furthermore, the number of target non-player characters can be multiple (e.g., several, dozens, hundreds, thousands, or even more), and correspondingly, the multiple identity information obtained in this case corresponds to multiple target NPCs. For example, the identity information of the target NPCs can be stored in a database device 152 of remote facility 150, and terminal device 120 obtains the target NPCs' identity information from the database device 152 by communicating with a server 151 of remote facility 150. Alternatively, the identity information of the target NPCs can be stored in terminal device 120, allowing user 110 to directly access this data by operating terminal device 120.

[0037] Finally, the terminal device 120 can generate the schedule of the target non-player character using a trained first language model, based at least on the scene information, the identity information, and the candidate game actions corresponding to the target non-player character. The candidate game actions are obtained by selecting corresponding game actions from a pre-built entity knowledge base as candidate game actions based on at least one of the scene information and the identity information. The entity knowledge base is constructed based on at least a plurality of game actions pre-designed for the target game. The trained first language model can be deployed on the terminal device 120. Alternatively, the trained first language model can be deployed on a remote facility 150 (e.g., in server 151), and the user 110 obtains the service of the trained first language model by accessing a corresponding interface (e.g., a web interface) deployed on the terminal device 120. The entity knowledge base can be deployed on the terminal device 120 or on a remote facility 150 (e.g., in database device 152).

[0038] For example, when the occupation information included in the identity information describes the occupation of "fisherman," the game action "fishing" can be selected as a candidate game action from a pre-built entity knowledge base based on this identity information; when the occupation information included in the identity information describes the occupation of "merchant," the game action "hawking" can be selected as a candidate game action from the pre-built entity knowledge base based on this identity information. The trained first language model can refine and expand the candidate game actions, for example, expanding the game action "hawking" to: "The vendor is hawking his goods to a passing family." Correspondingly, scene information and identity information can be input into the trained first language model. The trained first language model can select the corresponding game action as a candidate game action from the pre-built entity knowledge base based on at least one of the scene information and identity information, and then generate a specific schedule based on the scene information. Thus, the trained first language model not only generates a specific schedule, but also ensures that these schedules are consistent with the NPC's identity and background, further enhancing the game's realism and immersion.

[0039] Additionally, it should be noted that although the above steps can all be performed on the terminal device 120 side (e.g., in the form of a program or system deployed on the terminal device 120), those skilled in the art will understand that these steps can also be performed on the remote facility 150 side (e.g., in the server 151). Alternatively, these steps can be performed on both the terminal device 120 side and the remote facility 150 side. For example, the step of obtaining scene information corresponding to the game map of the target game can be performed on the terminal device 120 side, while the steps of obtaining the identity information of the target non-player character and generating the schedule of the target non-player character using a trained first language model can be performed on the remote facility 150 side.

[0040] In this application, the server 151 in the remote facility 150 can be a single server or a server cluster, and the database device 152 in the remote facility 150 can store various data required for generating the NPC schedule. Exemplarily, user 110 can access the remote facility 150 via a webpage through terminal device 120 or terminal device 130. Alternatively, user 110 can communicate with the remote facility 150 through a client installed on terminal device 120 or terminal device 130 to complete the corresponding NPC schedule generation process. Optionally, server 151 can also run other applications and store other data. For example, server 151 may include multiple virtual hosts to run different applications and provide different services.

[0041] In this application, terminal devices 120 and 130 can be various types of devices, such as mobile phones, tablets, laptops, in-vehicle devices, etc. A client can be deployed on terminal devices 120 and 130. This client can be used to perform NPC schedule generation-related operations and optionally provide other services, and can take any of the following forms: a locally installed application, a small program accessed via other applications, a web application accessed via a browser, etc. User 110 can view the information presented by the client and perform corresponding interactive operations through the input / output interfaces of terminal devices 120 and 130. Optionally, terminal devices 120 and 130 can be integrated with server 151.

[0042] In this application, the database device 152 can be considered as an electronic filing cabinet, that is, a place to store electronic files, where users can perform operations such as adding, querying, updating, and deleting data in the files. A "database" is a collection of data stored together in a certain way, which can be shared by multiple objects, has the lowest possible redundancy, and is independent of application programs.

[0043] Furthermore, in this application, network 140 can be a wired network connected via a cable, fiber optic cable, or a wireless network such as 2G, 3G, 4G, 5G, Wi-Fi, Bluetooth, ZigBee, Li-Fi, etc.

[0044] It should be noted that the term "user" as used in this article refers to any party that can interact with the system (e.g., a client system deployed on terminal device 120), including but not limited to people, software programs, network platforms, and even machines.

[0045] Figure 2 An example flowchart illustrating a method 200 for generating a schedule for a non-player character (hereinafter referred to as schedule generation method 200) according to some embodiments of this application is shown. Exemplarily, schedule generation method 200 can be... Figure 1 The terminal device shown is 120 or 130, but this is not a limitation. The following is in conjunction with... Figure 2 and Figure 3 This section describes in detail the steps and technical principles of the schedule generation method 200.

[0046] Specifically, in step 210, scene information corresponding to the game map of the target game can be obtained. The scene information includes area information, atmosphere information, and location information. The area information indicates multiple areas in the game map. Each of the multiple areas is used to carry corresponding functions and corresponding non-player characters. The atmosphere information indicates the corresponding environmental conditions of each of the multiple areas in the target game at different time periods. The location information indicates the specific location within each of the multiple areas.

[0047] As an example, the scene information can be manually designed. As another example, the scene information can be generated using a model. For instance, based on the map description information corresponding to the game map, a trained second language model can be used to obtain the scene information corresponding to the target game's map. The map description information may include text descriptions provided by the game developer, such as terrain features, building layouts, landmark locations, and geographical information extracted from the game engine. Those skilled in the art should understand that the map description information can be structured data obtained through necessary preprocessing, thereby facilitating model understanding and processing.

[0048] In step 220, the identity information of the target non-player character can be obtained. This identity information includes at least the target non-player character's name, occupation, and a brief character description. As an example, this identity information can be manually designed. As another example, the identity information can be generated using a model. For instance, based on the area information and atmosphere information in the scene information, a trained third-language model can be used to obtain the target non-player character's identity information. (See above for reference...) Figure 1 In addition to the NPC's name, occupation, and character description, the identity information mentioned in the description may also include other information, such as personality information describing the target NPC's character, gender information describing the target NPC, and body type information describing the target NPC's physique, or one or more of these. Additionally or alternatively, the identity information may also include ethnicity information, indicating the NPC's ethnicity or race (e.g., human, elf, dwarf, etc.). Ethnicity information can influence the NPC's behavior and interaction style; for example, elves may be more inclined to engage in activities in their natural environment.

[0049] In step 230, the schedule of the target non-player character can be generated using a trained first language model, based at least on the scene information, the identity information, and the candidate game actions corresponding to the target non-player character. The candidate game actions are obtained by selecting corresponding game actions from a pre-built entity knowledge base as the candidate game actions based on at least one of the scene information and the identity information. The entity knowledge base is constructed based on at least a number of game actions pre-designed for the target game.

[0050] Regarding the selection process for candidate game actions, the trained first language model can select corresponding game actions as candidate game actions from a pre-built entity knowledge base based on at least one of scene information and identity information, and then generate a specific schedule based on the scene information. In this case, the pre-built entity knowledge base can be input into the trained first language model in the form of text data, or it can be uploaded to the trained first language model in the form of a file (such as a table file) through the corresponding interface for the model to query relevant information.

[0051] As an example, the scene information, the identity information, the action description information corresponding to the candidate game action, and the corresponding prompt statement (taking the target NPC's name information as "Zhuge Liang" as an example, the prompt statement may include, for example, "Generate Zhuge Liang's schedule based on the information provided above") can be used as input data and input into the trained first language model to generate the schedule of the target non-player character. The action description information can be text data used to describe the candidate game action.

[0052] As another example, the scene information, the identity information, and the corresponding prompts can be used as input data to the trained first language model. When the schedule of the target NPC output by the trained first language model does not contain any content related to the candidate game action, the action description information (hereinafter represented by "X") corresponding to the candidate game action and the necessary prompts (e.g., "Please generate an NPC action that matches the action description information "X") can be used as input data to the trained first language model to guide the trained first language model to generate a more reasonable schedule.

[0053] like Figure 3 As shown, in scenario 300 where a schedule for a non-player character is generated, scenario information 310, identity information 320, and action description information 330 of the candidate game actions corresponding to the target non-player character are input as input data to a trained first language model 340, thereby generating a schedule 350 for the target non-player character from the trained first language model 340.

[0054] It should be noted that the trained first language model 340 can be any generative language model capable of generating the schedule 350 of the target non-player character. Similarly, the trained second language model described above as an example can be any generative language model capable of generating scene information corresponding to the game map of the target game, and the trained third language model can be any generative language model capable of generating the identity information of the target non-player character. Generative language models are models trained on large amounts of multi-domain and multi-scenario training data, and can be used to generate high-quality text, images, speech, and even video. Typical examples include the GPT series models based on the Transformer architecture developed by OpenAI. For example, the trained first language model 340 can be a pre-trained generative language model built on Transformer, including but not limited to open-source generative language models such as LLaMA, GPT, BLOOM, T5, Baichuan, ChatGLM, and Qwen.

[0055] In addition, to further enhance the model's ability to generate NPC schedules, a training set can be constructed using the corresponding text data to fine-tune the pre-trained generative language model to obtain a trained first language model 340 (the trained second language model and trained third language model described above as examples can also be fine-tuned based on the pre-trained generative language model in a similar way).

[0056] By combining Figure 2 and Figure 3 The described schedule generation method 200 obtains rich information about the target game by acquiring scene information corresponding to the game map and identity information of the target non-player character. Based on this information, and at least candidate game actions corresponding to the target non-player character, a trained first language model is used to generate a schedule for the target non-player character. Since the candidate game actions are selected from a pre-built entity knowledge base based on at least one of the scene information and identity information, this selection is based on the NPC's profession, character profile, or other game-related information (e.g., specific game area, atmosphere), making the generated schedule more consistent with the NPC's character. Therefore, the trained first language model can utilize this rich, multi-layered information of the target game to generate diverse schedules that match the target non-player character, helping to reduce related human input and achieve rich interactive behaviors of the NPC, thereby improving the user experience of the target game.

[0057] In some embodiments, obtaining scene information corresponding to the game map of the target game includes: obtaining scene information corresponding to the game map of the target game using a trained second language model based on the map description information corresponding to the game map. The map description information may include text descriptions provided by the game developer, such as terrain features, building layouts, landmark locations, and geographical information extracted from the game engine. The trained second language model may be various generative language models capable of generating scene information corresponding to the game map of the target game. To further enhance the model's ability to generate scene information corresponding to the game map of the target game, a training set can be constructed using relevant text data to fine-tune the pre-trained generative language model to obtain the trained second language model. For example, multiple released games can be used as sample games, and the scene information (including regional information, atmosphere information, and location information) corresponding to the game maps of these games can be used as corresponding sample labels to guide the output of the generative language model. For example, model parameters can be adjusted through supervised learning so that the model can ultimately generate expected scene information based on the map description information corresponding to the game map of the input sample games. The map description information corresponding to the game map can provide the trained second language model with rich and detailed information about the game map of the target game. The trained second language model can use this information and its own powerful semantic understanding ability to efficiently and reasonably generate the scene information corresponding to the game map of the target game, thereby greatly reducing or even completely eliminating the related human resources investment in the game development process.

[0058] In some embodiments, obtaining the identity information of the target non-player character includes: at least based on the area information and atmosphere information in the scene information, using a trained third language model to obtain the identity information of the target non-player character. The trained third language model can be various generative language models capable of generating the identity information of the target non-player character. To further enhance the model's ability to generate the identity information of the target non-player character, a training set can be constructed using corresponding text data to fine-tune the pre-trained generative language model to obtain the trained third language model. For example, multiple released games can be used as sample games, and the identity information of NPCs in these games can be used as corresponding sample labels to guide the output of the generative language model. For example, the model parameters can be adjusted through supervised learning so that the model can ultimately generate the expected identity information based on the input data (e.g., the area information and atmosphere information in the scene information corresponding to the game map of the sample games). The area information and atmosphere information in the scene information are important reference information in generating the identity information of NPCs. Using this information and the model's capabilities, the trained third language model can generate diverse, unique NPC identity information that conforms to the game context, thereby reducing game development time while further enriching the content and details of the game world.

[0059] In addition to regional and atmospheric information, the data input to the trained third-language model can also include supplementary information (e.g., the historical background of the target game), thereby helping to generate richer and more game-appropriate NPC identity information. Those skilled in the art will understand that, in this case, supplementary information related to the sample game (e.g., the historical background of the sample game) can also be considered as part of the training set during the training (fine-tuning) of the third-language model.

[0060] It should be noted that, without contradiction, the features described in the various embodiments of this application can be combined to obtain more technical solutions. For example, the following features described in the above embodiments can be combined to obtain a new technical solution: using a trained second language model to obtain scene information corresponding to the game map of the target game, and using a trained third language model to obtain the identity information of the target non-player character. For example... Figure 4As shown, in scenario 400, where the schedule of the target NPC is generated, map description information 410 corresponding to the game map is input into a trained second language model 420 to obtain scene information 430 corresponding to the game map of the target game. Next, based at least on the area information and atmosphere information in the scene information 430, the identity information 450 of the target NPC is obtained using a trained third language model 440. Then, the scene information 430, the identity information 450, and the action description information 460 of the candidate game actions corresponding to the target NPC are used as input data and input into a trained first language model 470, thereby generating the schedule 480 of the target NPC from the trained first language model 470.

[0061] In some embodiments, generating the schedule of the target non-player character using a trained first language model based at least on the scene information, the identity information, and the candidate game actions corresponding to the target non-player character includes: inputting the scene information, the identity information, and the action description information corresponding to the candidate game actions as at least a part of the input data into the trained first language model to generate the schedule of the target non-player character. For example, the scene information, the identity information, the action description information of the candidate game actions corresponding to the target non-player character, and corresponding prompt statements can be used as input data into the trained first language model to generate the schedule of the target non-player character. As mentioned above, the action description information can be text data used to describe the candidate game actions. Taking the name information of the target NPC as "Zhu Bajie" as an example, the prompt statement may include, for example, "Please generate Zhu Bajie's schedule based on the provided scene information and identity information, wherein the game actions should be based on the provided candidate game actions"). Scene information, identity information, and action descriptions corresponding to candidate game actions can provide the trained first language model with rich and detailed reference information about NPCs (e.g., area, atmosphere, and location information in the game map, NPC's profession information, NPC's candidate game actions, etc.). By combining this information with the model's powerful natural language generation capabilities, diverse and context-appropriate NPC schedules can be obtained. Since these schedules are consistent with the NPC's identity and background, the realism and immersion of the game can be further enhanced.

[0062] Those skilled in the art will understand that, whether it is the aforementioned trained first language model, trained second language model, or trained third language model, the input data for these language models can be text statements (also known as "prompt statements"), files (e.g., PDF, WORD, or other file formats), or a combination thereof. Taking the aforementioned trained first language model as an example, its input data can consist of prompt statements, which at least include the scene information, the identity information, and the action description information corresponding to the candidate game action.

[0063] In some embodiments, the input data further includes entity supplementary information, which is obtained through the following steps: performing named entity recognition processing on at least one of the scene information, the identity information, and the action description information to obtain the corresponding entity recognition result; and selecting corresponding entity knowledge from the entity knowledge base as the entity supplementary information based on the entity recognition result. The selected entity knowledge includes at least one of the following: game background information, character background information, positional relationship information, and character relationship information.

[0064] like Figure 5 As shown, in scenario 500, where the schedule of the target NPC is generated, the map description information 510 corresponding to the game map is input into a trained second language model 511 to obtain scenario information 512 corresponding to the game map of the target game. The identity information 514 of the target NPC is obtained using a trained third language model 513, based at least on the regional information and atmosphere information in the scenario information 512. Figure 5 As shown, named entity recognition processing is performed on at least one of the scene information 430, identity information 450, and action description information 515 of the candidate game actions corresponding to the target NPC. The obtained entity recognition result 516 is used to select the corresponding entity knowledge from the entity knowledge base 517 as entity supplementary information 518. Finally, as Figure 5 As shown, scene information 512, identity information 514, action description information 515 of the candidate game action corresponding to the target NPC, and entity supplementary information 518 are used as input data and input into the trained first language model 519, thereby generating the target NPC's schedule 520 by the trained first language model 519.

[0065] The entity knowledge base 517 can pre-store various entity knowledge, including but not limited to entity knowledge corresponding to various entities (various characters, items, locations, professions, scenes, character relationships, etc. existing in the game world). This entity knowledge can include multiple pre-designed game actions, game background information, character background information, positional relationship information, and character relationship information, etc. (This entity knowledge can be pre-designed manually, generated by the aforementioned trained second language model and the aforementioned trained third language model, or a combination of pre-designed content and content generated by these models). Game background information and character background information respectively indicate background information related to the game and the character (e.g., NPC). This detailed background information helps the trained first language model 519 consider the unique personality and story of each NPC when generating NPC schedules, making the generated schedules more consistent with the NPC's setting. Positional relationship information indicates the relationships between different areas and points on the game map. This information helps the trained first language model 519 consider the relationships between different areas and points on the game map when generating NPC schedules, making the generated schedules more logical and reasonable. Character relationship information indicates the relationships between characters in the game (e.g., friends, enemies, relatives, etc.). By understanding the relationships between NPCs, the trained first language model 519 can generate more reasonable and interactive schedules, such as arranging meetings between relatives or confrontations between enemies.

[0066] In the entity knowledge base, various entity knowledge data can be stored in appropriate ways according to their characteristics. For example, some entity knowledge can be stored in JSON format, some in key-value pairs, some in CSV format, and so on. Entity knowledge selected from the entity knowledge base 517 based on entity recognition results will be used as supplementary entity information 518 and input together with other information into the trained first language model 519. By utilizing this information, the trained first language model 519 can understand the current situation of the NPC in a broader context, thereby generating more accurate and richer schedules.

[0067] Furthermore, the process of performing named entity recognition processing on at least one of the scene information, identity information, and action description information to obtain the corresponding entity recognition result can be accomplished using Named Entity Recognition (NER) technology. Named entity recognition, also known as "property name recognition," refers to the identification of entities with specific meanings in text, mainly including personal names, place names, organization names, proper nouns, etc. For example, various pre-trained NER models (e.g., SpaCy, BERT-NER) can be used to perform named entity recognition processing on at least one of the scene information, identity information, and action description information to obtain the corresponding entity recognition result. Alternatively, even a trained first language model can be used for named entity recognition processing. Those skilled in the art should understand that in this case, it is necessary to provide the trained first language model with corresponding prompts (e.g., "Identify all professions in the provided identity information").

[0068] In some embodiments, each entity knowledge in the entity knowledge base is stored in the entity knowledge base in vector form. The entity feature vector corresponding to each entity knowledge is obtained by converting the corresponding entity knowledge using a trained fourth language model and has a preset length. The step of selecting corresponding entity knowledge from the entity knowledge base as supplementary entity information based on the entity recognition result includes: converting the entity recognition result into a query feature vector using the trained fourth language model; when the length of the query feature vector is inconsistent with the preset length, performing length scaling on the query feature vector so that the length of the query feature vector is consistent with the preset length; and comparing the similarity between the query feature vector and the entity feature vector corresponding to each entity knowledge in the entity knowledge base, and using the entity knowledge corresponding to the entity feature vector that meets the preset comparison conditions as the supplementary entity information.

[0069] For example, the text corresponding to each entity knowledge in the entity knowledge base can be input as input data into a trained fourth language model (e.g., BERT model, GPT series models). The trained fourth language model will automatically encode the input data and generate a fixed-dimensional feature vector (i.e., the aforementioned entity feature vector). This feature vector can capture the semantic information in the text and represent it in numerical form. The dimension of the feature vector can be flexibly set according to actual needs. For example, 128-dimensional, 256-dimensional, 512-dimensional, or higher dimensions can be selected to ensure that the feature vector can fully express the complexity of the entity knowledge. Storing and retrieving entity knowledge through feature vectors can save storage costs while achieving high retrieval accuracy. The retrieval process can be completed by writing a corresponding program or by using a corresponding language model (e.g., a trained first language model).

[0070] To improve the accuracy of retrieving supplementary entity information from an entity knowledge base and adapt to different application scenarios, when the length of the query feature vector differs from the preset length (which can be a unit length or a length other than a unit length), length scaling can be applied to the query feature vector to make its length consistent with the preset length. For example, when the preset length is a unit length and the length of the query feature vector differs from the preset length, L2 normalization can be used to scale the length of the query feature vector to a unit length consistent with the preset length.

[0071] In addition, regarding the preset comparison conditions, it can be that the similarity (e.g., cosine similarity) between the query feature vector and the entity feature vector corresponding to one or more entity knowledge in the entity knowledge base meets certain conditions (e.g., greater than 0.8, greater than 0.9, greater than 0.95, etc.). It can be flexibly set according to actual needs, so that the entity knowledge corresponding to the entity feature vector with a high similarity to the query feature vector in the entity knowledge base is used as the entity supplementary information.

[0072] In some embodiments, the schedule of the target non-player character includes: a target game action corresponding to the candidate game action, a target time period in the target game for the target non-player character to perform the target game action, and a target location within a target area in the plurality of areas for the target non-player character to perform the target game action. For example, the target time period could be 8:00-10:00 AM, 2:00-4:00 PM, etc. The target location could be the specific location (NavNode) of the NPC on the game map selected by a trained first language model based on the NPC's activity needs and point information in the scene information. Figure 6The diagram schematically illustrates a waypoint map 600 generated by an NPC's movement within the game map according to their schedule. Waypoint map 600 includes all possible movement points of the NPC within the game map. For example, Figure 6 As shown, the movement range of the NPC spawned at point 610 on the game map is represented by three point sets (point set 1, point set 2, and point set 3). By generating NPC schedules that include time, location, and actions, players can be provided with diverse and information-rich NPC schedules (for example, players may encounter different NPCs at different times and locations in the game, and these NPCs may have different game actions and interactive behaviors), thereby improving game quality and enhancing the player's gaming experience.

[0073] In some embodiments, the schedule of the target non-player character further includes: the location type of the target location, wherein the location type indicates whether the target non-player character performs the target game action at a single location. The location type can indicate more details about the NPC's activity range, facilitating the development of more complex and diverse NPC behaviors. For example, some NPCs may remain stationary at a single location (i.e., not moving to other locations) to perform corresponding tasks, while others may move back and forth between multiple locations. The former can be called "static NPCs," and the latter can be called "dynamic NPCs." Static NPCs are those that remain stationary on the game map, such as guards and vendors, while dynamic NPCs are those that move and perform specific behaviors (such as shopping or visiting) on ​​the game map according to a set schedule. By generating a reasonable schedule for each NPC, these NPCs can exhibit a wide variety of behaviors in the game, thereby enhancing the game's dynamism and realism.

[0074] Figure 7 The diagram schematically illustrates an example principle of a training method 700 for a schedule generation model according to some embodiments of this application. Figure 7As shown, the training method 700 includes: obtaining sample scene information 712 corresponding to the sample game map of the sample game (referring to the above description of the trained second language model, exemplarily, the sample scene information 712 corresponding to the sample game map of the sample game can be obtained based on the map description information 710 corresponding to the sample game map of the sample game, using the trained second language model 711), wherein the sample scene information 712 includes sample area information, sample atmosphere information, and sample point information, wherein the sample area information indicates multiple sample areas in the sample game map, each of the multiple sample areas is used to carry corresponding functions and corresponding non-player characters, the sample atmosphere information indicates the corresponding environmental conditions of each of the multiple sample areas in the sample game at different time periods, and the sample point information indicates the specific location within each of the multiple sample areas; obtaining multiple sample identity information 714 corresponding to multiple sample non-player characters (referring to the above description of the trained third language model, exemplarily, the sample identity information 712 can be obtained based at least on the sample area information and the sample atmosphere information in the sample scene information 712, using the trained third language model 711). 3. Obtain multiple sample identity information 714 corresponding to multiple sample non-player characters, each sample identity information including at least the name information, occupation information, and character introduction of the corresponding sample non-player character among the multiple sample non-player characters; generate multiple sample schedules 718 corresponding to the multiple sample non-player characters using a schedule generation model 717, based at least on sample scene information 712, the multiple sample identity information 714, and multiple candidate game actions 716 corresponding to the multiple sample non-player characters, wherein each candidate game action in the multiple candidate game actions 716 is obtained by: selecting the corresponding game action as the corresponding candidate game action from a pre-built entity knowledge base 715 based on at least one of the sample scene information 712 and the sample identity information corresponding to the corresponding sample non-player character in the multiple sample identity information 714, wherein the entity knowledge base 715 is constructed based at least on multiple game actions pre-designed for the sample game; determine the target loss based on the multiple sample schedules and the multiple labeled schedules corresponding to the multiple sample schedules; and iteratively update the parameters of the schedule generation model so that the target loss satisfies the preset training conditions.

[0075] pass Figure 7The training method 700 shown can obtain rich, multi-layered information about the sample game by acquiring sample scene information corresponding to the sample game map and multiple sample identity information corresponding to multiple sample non-player characters. Based on this information and multiple candidate game actions corresponding to multiple sample non-player characters, a schedule generation model is used to generate multiple sample schedules corresponding to multiple sample non-player characters. Then, a target loss is established based on these sample schedules and corresponding multiple labeled schedules. This target loss guides the training process of the schedule generation model, enabling the finally trained schedule generation model to generate detailed and diverse NPC schedules. In these schedules, each NPC has its unique behavior pattern and game actions, thus avoiding the problem of monotonous and repetitive NPC behavior in traditional designs. Furthermore, through... Figure 7 The training method shown in Figure 700 produces a schedule generation model with high flexibility and scalability. For example, regardless of the game type (e.g., various open-world games), as long as the model is provided with game-related scene information, identity information, and candidate game actions, it can generate the corresponding NPC's schedule. This flexibility allows... Figure 7 The training method shown in Figure 700 yields a schedule generation model that is applicable to various types of games and has broad application prospects.

[0076] It should be noted that, in order to improve sample quality and further enhance the NPC schedule generation capability of the schedule generation model, such as... Figure 7 As shown, the multiple sample identity information 714 can be manually or machine-verified. For example, code can be written to verify whether the identity information of the NPC generated by the third language model 713 is duplicated or does not conform to the game's world view. When these situations occur, the trained third language model 713 can regenerate the identity information until its output no longer shows these situations. Furthermore, although in Figure 7 In the example shown, the sample scene information 712 is obtained using the map description information 710 corresponding to the sample game map of the sample game and a trained second language model 711. Those skilled in the art should understand that the sample scene information 712 can also be manually designed. Alternatively, the sample scene information 712 can be a combination of manually pre-designed content and content generated by the trained second language model 711. Similarly, although in Figure 7In the example shown, multiple sample identity information 714 is obtained using a trained third language model 713, based at least on sample region information and sample atmosphere information in sample scene information 712. Those skilled in the art should understand that multiple sample identity information 714 can also be manually designed. Alternatively, multiple sample identity information 714 can be a combination of manually pre-designed content and content generated by the trained third language model 713.

[0077] Additionally, as mentioned above... Figure 7 In the training method 700 described, in order to more efficiently prepare and organize the training data for the schedule generation model 717 (which includes at least sample scene information 712, multiple sample identity information 714, and multiple candidate game actions 716 corresponding to multiple sample non-player characters), multiple basic data sources can be prepared in advance (which together constitute the entity knowledge base described above), so that the training data has the following characteristics: Figure 8 The structure 800 shown. These basic data sources provide the schedule generation model 717 with the basic information and context required to generate NPC schedules, thereby enabling the schedule generation model 717 to generate reasonable and diverse NPC schedules.

[0078] like Figure 8 As shown, exemplarily, specific basic data sources can include the following categories: character cards, NPC data, schedule template tables, game action (behavior) libraries, waypoint libraries, and performance animation libraries. Character cards are cards describing the identity and background information of NPCs. They can include identity tags, ethnic information, and character packaging. Identity tags identify the NPC's identity. Additionally, appropriate personality and ethnic information (e.g., name, gender, age, basic introduction, personality) can be selected from an NPC personality and ethnic knowledge base. These tags help the schedule generation model understand the NPC's basic role positioning. Ethnic information describes the NPC's ethnicity or race (e.g., human, elf, dwarf, etc.). As mentioned above, ethnic information can influence the NPC's behavior and interaction methods; for example, elves may be more inclined to activities in their natural environment. Character packaging is a general description of an NPC, i.e., a character biography, such as a two-sentence summary of the NPC. Character cards provide basic background information for each NPC, helping the schedule generation model consider the NPC's identity and ethnic characteristics when generating schedules, thus generating schedules that match their role positioning.

[0079] NPC data meticulously records each NPC's specific information and placement location, including NPCID, NPC placement location (e.g., represented by three-dimensional coordinates XYZ in the case of a 3D game map), permanent dialogues, and optional schedules. The NPC ID is a unique identifier for each NPC, used to distinguish different NPCs. The NPC placement location describes the NPC's specific position on the game map; these locations form the basis for NPC actions and activities (e.g., a merchant selling goods at a market stall, a soldier patrolling the city walls). NPC data enables the schedule generation model to accurately assign specific locations to each NPC when generating NPC schedules, ensuring spatial plausibility and consistency of NPC activities within the game. The schedule template table includes the schedule's name, time, location (represented by waypoints, i.e., points), and behavior (i.e., game actions; exemplified here, this could be action description information and corresponding identifiers, such as...). Figure 8 As shown in POIBehaviorID, the Schedule template table provides a templated reference for schedule content for the schedule generation model.

[0080] Game Behavior Library (i.e.) Figure 8 The POIBehavior library shown is a game action library that records detailed information about various NPC game actions, including behavior tags (behavior IDs) and actions (i.e., game actions). The behavior ID is a unique identifier for each action, used to distinguish different actions. POIBehaviorIDs are tags describing actions (e.g., "fishing," "selling," "patrolling," etc.). These tags help the schedule generation model understand and select appropriate game actions (which can have corresponding animation tags and task data), facilitating the generation of reasonable schedules based on the NPC's identity and context. The waypoint library is a database recording all points (NavNodes) on the game map. It can include the unique identifier (waypoint ID) for each point, the specific coordinates of each waypoint on the map, and the connections between points. The performance animation library provides the animation resources needed for NPCs to perform various game actions in the schedules generated by the schedule generation model.

[0081] In some embodiments, generating multiple sample schedules corresponding to the multiple sample non-player characters using a schedule generation model based at least on the sample scene information, the multiple sample identity information, and the multiple candidate game actions corresponding to the multiple sample non-player characters includes: taking the sample scene information, the multiple sample identity information, the multiple action description information corresponding to the multiple candidate game actions, and the multiple historical schedules corresponding to the multiple sample non-player characters as at least a part of the input data, inputting them into the schedule generation model to generate multiple sample schedules corresponding to the multiple sample non-player characters, wherein each of the multiple historical schedules includes: a historical game action, a target time period in the historical game for the historical non-player character to perform the historical game action, and a historical location in the historical game map of the historical game for the historical non-player character to perform the historical game action.

[0082] To enable the schedule generation model to respond to specific events (e.g., generating corresponding NPC schedules based on different weather conditions or player interaction information), for example, multiple weather conditions (e.g., sunny, rainy, cloudy, snowy) can be predefined for the target game. Then, for each input data point to the schedule generation model, a weather condition is randomly selected and added to the prompt. Alternatively, multiple player interaction conditions (e.g., the player's health, whether they are injured, player actions (e.g., jumping onto a table, swinging a sword at an NPC)) can be predefined for the target game. Then, for each input data point to the schedule generation model, a player interaction condition is randomly selected and added to the prompt. This ensures that each dataset in the training dataset includes at least one of weather information and player interaction information, allowing the schedule generation model to learn how to generate corresponding NPC schedules based on different weather conditions and player interaction information. For example, vendors (NPCs) might pack up and go home on a rainy day, while fishermen (NPCs) might go fishing on a sunny day. And regarding player interactions (e.g., a player jumping onto a table), NPCs might get angry or frustrated.

[0083] For example, the multiple historical schedules corresponding to the multiple sample non-player characters can be obtained from an existing schedule configuration (which can be regarded as a database), for example, such as Figure 8As shown, this database records previously designed (manually designed or model-designed) NPC schedules, including time (i.e., the target time period for historical non-player characters to perform the historical game actions mentioned above), location (i.e., the historical location within the historical game map for the historical non-player characters to perform the historical game actions mentioned above), and behavior (i.e., the historical game actions mentioned above). These existing NPC schedules provide additional training data for the schedule generation model, helping it learn how to generate NPC schedules more reasonably. This makes the schedules generated by the schedule generation model more consistent with the actual game scenarios and closer to the NPCs' identities and backgrounds, thereby further improving game quality and enhancing the player's gaming experience.

[0084] exist Figure 9 In the scenario 900 shown, an example is illustrated. Figure 7 The possible structures of the input and output data for the schedule generation model 717 in the example. Figure 9 As shown, the NPC character card information input to the schedule generation model includes identity tags (which correspond to sample identity information during the training phase of the schedule model, and to identity information during the application phase), scene information (which corresponds to sample scene information during the training phase of the schedule model, and to scene information during the application phase), and behavior information (which corresponds to the action description information of candidate game actions).

[0085] Taking the application stage of the schedule generation model as an example, such as Figure 9 As shown, the schedule generated by the schedule generation model outputs the NPC's schedule, which includes the event's behavior (i.e., the target game action), the event's location (i.e., the target location where the NPC performs the target game action), and the event's time (i.e., the target time period in the target game for the NPC to perform the target game action). Figure 9 This diagram illustrates a data structure for an NPC's schedule output by a schedule generation model. The `BehaviorID` field is a label describing the NPC's game actions (e.g., "fishing," "selling," "patrolling," etc.). The `NavNode Set` is used for path planning and action definition, defining the character's navigation behavior. The `NavNode SetName` field represents the unique identifier of this navigation node set. The `NavNode Tag` field represents the node label. These identifiers / tags can be used to plan the NPC's trajectory in later stages of game development (e.g., animation setup).

[0086] In some embodiments, the schedule generation model includes an embedding acquisition module, a position encoding module, and a decoding output module, wherein the embedding acquisition module is configured to convert the input data of the schedule generation model into a first feature vector. Exemplarily, word embedding techniques (e.g., Word2Vec, GloVe, BERT, etc.) can be used to convert the input data into a first feature vector, which may have appropriate dimensions (e.g., 256-dimensional, 512-dimensional, 768-dimensional, etc.); the position encoding module is configured to convert the first feature vector into a second feature vector by adding position information to the first feature vector, wherein the position information is used to characterize the relative positions between different parts of the input data; the decoding output module is configured to convert the second feature vector into the output data of the schedule generation model. An example formula for determining position information is given below:

[0087] PE pos,2i =sin(pos / 10000) (2i / d) ),

[0088] PE pos,2i+1 =cos(pos / 10000) (2i / d) ).

[0089] Here, pos represents the position, i represents the dimension index, and d represents the feature dimension. In this way, location information can be encoded into the schedule generation model without changing the original order of the input data. Specifically, the calculated location encoding vector can be added element-wise to the first feature vector to transform the first feature vector into a second feature vector, thereby encoding the location information into the schedule generation model without changing the original order of the input data.

[0090] Regarding the process by which the decoding output module converts the second feature vector into the output data of the schedule generation model, for example, the position-encoded data (i.e., the second feature vector) can be input into a generative language model (e.g., LLM) for processing. Taking LLM as an example, its core component is the multi-head attention mechanism, which aims to capture different semantic features in the data by computing multiple attention heads in parallel. The core formula of the multi-head attention mechanism is as follows:

[0091] Attention(Q,K,V) = softmax(QK) T / (d k 1 / 2 ))*V,

[0092] Where Q, K, and V represent the query vector, key vector, and value vector, respectively, and d kThe feature dimension is represented by the dot product of the query vector Q and the key vector K, which yields the similarity at each position (i.e., the dot product matrix QK). T Then, for this dot product matrix QK T Scaling (denominator is d) k 1 / 2 The weight distribution (i.e., weight matrix) of each position is obtained by using the softmax function. Finally, the weight matrix processed by the softmax function is multiplied by the value vector V to obtain the final calculation result.

[0093] By designing the architecture described in the above embodiments for the schedule generation model (which includes an embedding acquisition module, a position encoding module, and a decoding output module), positional information can be introduced into the input data of the schedule generation model. This enables the schedule generation model to understand the importance of word order and contextual order in the input data, thereby ensuring that the schedule generation model can capture the positional relationship of each word in the input statement (i.e., input data) when understanding and generating the schedule of the NPC, thus accurately understanding the semantic features of the input statement and generating the schedule of the NPC that meets the requirements.

[0094] Regarding the above reference Figure 7-9 The training process of the schedule generation model in the various embodiments described above, as described above, involves determining the target loss based on multiple sample schedules and multiple labeled schedules corresponding to these sample schedules; and iteratively updating the parameters of the schedule generation model so that the target loss meets preset training conditions. Exemplarily, the schedule generation model can be various pre-trained generative language models, and the aforementioned training process for the schedule generation model can correspond to the "fine-tuning stage." Accordingly, various fine-tuning methods can be used to complete the above training process. Exemplarily, a full fine-tuning method can be used to adjust all parameters of the schedule generation model to make it perform better on the task of generating schedules for NPCs. For the training data of the schedule generation model, some special tokens (e.g., [PAD], etc.) can be added by adjusting the tokenizer (e.g., tokenizer) and the word embedding layer of the schedule generation model (i.e., the embedding acquisition module mentioned above). <s>、 <unk>) to adapt to the needs of specific tasks. The adjusted tokenizer and word embedding layer can ensure that the schedule generation model correctly processes special symbols in the input data.

[0095] Specifically, "[PAD]" is used to pad the input data so that input data sequences of different lengths can be made the same length, facilitating batch processing of these sequences by the schedule generation model.< / unk> < / s> "(EndofSentenceToken)" indicates the end of a sentence, helping schedule generation models know when to stop generating or mark the boundaries of text (this is especially important during decoding, such as determining whether a generated sentence is complete in a generation task). <s>The "(Start of Sentence Token)" indicates the start of a sentence and is used to guide the schedule generation model to begin generating text. It provides a marker for the beginning of a sentence, allowing the schedule generation model to initialize correctly during generation or encoding. <unk>"(Unknown Token)" represents an unknown word, that is, a word that does not appear in the vocabulary. When a word in the input text is not in the vocabulary of the calendar generation model, it will be replaced with "(Unknown Token)". <unk>This helps calendar generation models handle OOV (Out-of-Vocabulary) vocabulary, preventing calendar generation models from crashing during training or inference.

[0096] In the training configuration, custom training arguments can be used, including learning rate, batch size, and number of training steps. To improve training efficiency and reduce memory usage, mixed-precision training can be enabled. During training, various types of loss functions (e.g., cross-entropy loss, contrastive loss, etc.) can be used for the target loss. For example, the preset training condition can be that the number of training iterations reaches a preset number, or it can be that the target loss is minimized. It should be noted that in this application, the expression "minimization of target loss" can refer to the target loss being minimized when the number of training iterations of the schedule generation model reaches a threshold, or it can refer to the target loss being minimized when the target loss is less than the corresponding loss function threshold, triggering training termination, or it can refer to obtaining the global minimum of the target loss, which is ideal or very close to ideal. In addition, alternative expressions for "minimization of target loss" can be "target loss convergence" or "target loss reaching its maximum value," etc. The corresponding threshold for the number of training iterations and the threshold for the loss function can be set empirically or flexibly adjusted according to the application scenario, and this application does not impose any restrictions on this. In addition, during the training of the schedule generation model (i.e., during the iterative updating of the parameters of the schedule generation model), various parameter update methods (e.g., backpropagation algorithm) can be used.

[0097] Figure 10 An example block diagram of an apparatus for generating schedules for non-player characters (hereinafter referred to as schedule generation apparatus 1000) according to some embodiments of this application is illustrated schematically. Exemplarily, schedule generation apparatus 1000 can be deployed in... Figure 1 On the terminal device 120 or terminal device 130 or remote facility 150 shown. For example... Figure 10 As shown, the schedule generation device 1000 includes a scene information acquisition module 1010, an identity information acquisition module 1020, and a schedule generation module 1030.

[0098] Specifically, the scene information acquisition module 1010 can be configured to acquire scene information corresponding to the game map of the target game. The scene information includes area information, atmosphere information, and location information. The area information indicates multiple areas in the game map, each of which is used to carry corresponding functions and corresponding non-player characters. The atmosphere information indicates the corresponding environmental conditions of each of the multiple areas in the target game at different time periods. The location information indicates the specific location within each of the multiple areas. The identity information acquisition module 1020 can be configured to acquire the identity information of the target non-player character. The identity information includes at least the name information, occupation information, and character introduction of the target non-player character. The schedule generation module 1030 can be configured to generate the schedule of the target non-player character using a trained first language model, based at least on the scene information, the identity information, and the candidate game actions corresponding to the target non-player character. The candidate game actions are acquired by selecting corresponding game actions from a pre-built entity knowledge base as candidate game actions based on at least one of the scene information and the identity information. The entity knowledge base is constructed based on at least a number of game actions pre-designed for the target game.

[0099] Furthermore, the schedule generation device 1000 can be used to implement the schedule generation method 200 described above, the details of which have been described in detail above and will not be repeated here for the sake of brevity. In addition, these devices can have the same features and advantages as those described in the corresponding methods.

[0100] Figure 11 An example block diagram of an apparatus for generating a model through a training schedule according to some embodiments of this application (hereinafter referred to as model training apparatus 1100) is illustrated schematically. Exemplarily, model training apparatus 1100 can be deployed in... Figure 1 The remote facility 150 is shown. Figure 11 As shown, the model training device 1100 includes a sample scene information acquisition module 1110, a sample identity information acquisition module 1120, a sample schedule generation module 1130, a loss determination module 1140, and a model training module 1150.

[0101] Specifically, the sample scene information acquisition module 1110 can be configured to acquire sample scene information corresponding to the sample game map of the sample game. This sample scene information includes sample area information, sample atmosphere information, and sample point information. The sample area information indicates multiple sample areas in the sample game map, each of which is used to host corresponding functions and corresponding non-player characters. The sample atmosphere information indicates the environmental conditions of each sample area in the sample game at different time periods. The sample point information indicates the specific location within each sample area. The sample identity information acquisition module 1120 can be configured to acquire multiple sample identity information corresponding to multiple sample non-player characters. Each sample identity information includes at least the name, occupation, and character description of the corresponding sample non-player character. The sample schedule generation module 1130 can be configured to... Based on the sample scene information, the multiple sample identity information, and the multiple candidate game actions corresponding to the multiple sample non-player characters, a schedule generation model is used to generate multiple sample schedules corresponding to the multiple sample non-player characters. Each candidate game action is obtained by selecting a corresponding game action from a pre-built entity knowledge base based on the sample scene information and at least one of the sample identity information corresponding to the corresponding sample non-player character. The entity knowledge base is constructed based on at least a multiple game actions pre-designed for the sample game. The loss determination module 1140 can be configured to determine a target loss based on the multiple sample schedules and the multiple labeled schedules corresponding to the multiple sample schedules. The model training module 1150 can be configured to iteratively update the parameters of the schedule generation model so that the target loss meets the preset training conditions.

[0102] Furthermore, the model training device 1100 can be used to implement the training method 700 of the schedule generation model described above, the details of which have been described in detail above and will not be repeated here for the sake of brevity. In addition, these devices can have the same features and advantages as those described in the corresponding methods.

[0103] It should be understood that the schedule generation device 1000 and the model training device 1100 can be implemented in software, hardware or a combination of software and hardware. Multiple different modules in these devices can be implemented in the same software or hardware structure, or a module can be implemented by multiple different software or hardware structures.

[0104] Figure 12 The illustration depicts an example system including an example computing device 1200 representing one or more systems and / or devices that can implement the various technologies described herein. The computing device 1200 may be, for example, a server used by a node in a blockchain, a device associated with a server, a system-on-a-chip, and / or any other suitable computing device or computing system. (Refer to above) Figure 10 The described schedule generation device 1000 and the above reference Figure 11 The model training device 1100 described can both take the form of a computing device 1200. Alternatively, both the schedule generation device 1000 and the model training device 1100 can be implemented as computer programs in the form of an application 1216.

[0105] like Figure 12 The example computing device 1200 shown includes a processing system 1211, one or more computer-readable media 1212, and one or more I / O interfaces 1213 that are communicatively coupled to each other. Although not shown, the computing device 1200 may also include a system bus or other data and command transfer system that couples the various components to each other. The system bus may include any or a combination of different bus architectures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and / or a processor or local bus utilizing any of the various bus architectures. Various other examples, such as control and data lines, are also conceived.

[0106] Processing system 1211 represents the functionality of performing one or more operations using hardware. Therefore, processing system 1211 is illustrated as including hardware elements 1214 that can be configured as processors, function blocks, etc. This may include other logic devices implemented in hardware as application-specific integrated circuits (ASICs) or formed using one or more semiconductors. Hardware element 1214 is not limited by the materials in which it is formed or the processing mechanism employed therein. For example, a processor may consist of semiconductors and / or transistors (e.g., integrated circuits (ICs)). In such a context, processor-executable instructions may be electronically executable instructions.

[0107] Computer-readable medium 1212 is illustrated as including memory / storage device 1215. Memory / storage device 1215 represents a memory / storage capacity associated with one or more computer-readable media. Memory / storage device 1215 may include volatile media (such as random access memory (RAM)) and / or non-volatile media (such as read-only memory (ROM), flash memory, optical disk, magnetic disk, etc.). Memory / storage device 1215 may include fixed media (e.g., RAM, ROM, fixed hard disk drive, etc.) and removable media (e.g., flash memory, removable hard disk drive, optical disk, etc.). Computer-readable medium 1212 may be configured in various other ways as further described below.

[0108] One or more I / O interfaces 1213 represent the functionality to allow users to input commands and information to computing device 1200 using various input devices and optionally also to present information to the user and / or other components or devices using various output devices. Examples of input devices include keyboards, cursor control devices (e.g., mice), microphones (e.g., for voice input), scanners, touch functionality (e.g., capacitive or other sensors configured to detect physical touch), cameras (e.g., capable of detecting non-touch-related motion as gestures using visible or invisible wavelengths (such as infrared frequencies), etc. Examples of output devices include display devices (e.g., projectors), speakers, printers, network interface cards, haptic-responsive devices, etc. Therefore, computing device 1200 can be configured to support user interaction in various ways as further described below.

[0109] The computing device 1200 also includes an application 1216. The application 1216 may be, for example, a software instance of a schedule generation device 1000 or a model training device 1100, and implements the techniques described herein in combination with other elements in the computing device 1200.

[0110] This document describes various technologies within the general context of software and hardware components or program modules. Generally, these modules include routines, programs, elements, components, data structures, etc., that perform specific tasks or implement specific abstract data types. As used herein, the terms "module," "function," and "component" generally refer to software, firmware, hardware, or a combination thereof. The technologies described herein are platform-independent, meaning that they can be implemented on a variety of computing platforms with various processors.

[0111] Implementations of the described modules and technologies may be stored on or transmitted across some form of computer-readable medium. The computer-readable medium may include a variety of media accessible by the computing device 1200. By way of example and not limitation, the computer-readable medium may include "computer-readable storage media" and "computer-readable signal media".

[0112] In contrast to simple signal transmission, carrier waves, or signals themselves, "computer-readable storage media" refers to media and / or devices capable of persistently storing information, and / or tangible storage devices. Therefore, computer-readable storage media refers to non-signal-bearing media. Computer-readable storage media include hardware such as volatile and non-volatile, removable and non-removable media and / or storage devices implemented using methods or techniques suitable for storing information (such as computer-readable instructions, data structures, program modules, logic elements / circuits, or other data). Examples of computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage devices, hard disks, cassette tapes, magnetic tapes, disk storage devices or other magnetic storage devices, or other storage devices, tangible media, or articles of art suitable for storing desired information and accessible by a computer.

[0113] "Computer-readable signal medium" refers to a signal-bearing medium configured to transmit instructions, such as via a network, to computing device 1200. A signal medium typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, data signal, or other transmission mechanism. Signal media also include any information transmission medium. The term "modulated data signal" refers to a signal in which one or more of its characteristics are set or altered to encode information. By way of example and not limitation, communication media include wired media such as wired networks or direct connections, and wireless media such as acoustic, RF, infrared, and other wireless media.

[0114] As previously described, hardware element 1214 and computer-readable medium 1212 represent instructions, modules, programmable device logic, and / or fixed device logic implemented in hardware, which in some embodiments can be used to implement at least some aspects of the techniques described herein. Hardware elements may include components of integrated circuits or systems-on-a-chip, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), and other implementations or other hardware devices in silicon. In this context, hardware elements can serve as processing devices for executing program tasks defined by instructions, modules, and / or logic embodied by the hardware element, and as hardware devices for storing instructions for execution, such as the previously described computer-readable storage medium.

[0115] The foregoing combinations can also be used to implement the various techniques and modules described herein. Therefore, software, hardware, or program modules and other program modules can be implemented as one or more instructions and / or logic embodied on some form of computer-readable storage medium and / or by one or more hardware elements 1214. The computing device 1200 can be configured to implement specific instructions and / or functions corresponding to the software and / or hardware modules. Thus, modules can be implemented at least partially in hardware as modules executable as software by the computing device 1200, for example, by using the computer-readable storage medium and / or hardware elements 1214 of the processing system. Instructions and / or functions can be executable / operable by one or more articles of art (e.g., one or more computing devices 1200 and / or processing systems 1211) to implement the techniques, modules, and examples described herein.

[0116] In various embodiments, the computing device 1200 can be configured in various ways. For example, the computing device 1200 can be implemented as a computer-type device, including personal computers, desktop computers, multi-screen computers, laptop computers, netbooks, etc. The computing device 1200 can also be implemented as a mobile device, including mobile devices such as mobile phones, portable music players, portable gaming devices, tablet computers, multi-screen computers, etc. The computing device 1200 can also be implemented as a television-type device, including devices with or connected to a generally large screen in a leisure viewing environment. These devices include televisions, set-top boxes, game consoles, etc.

[0117] The techniques described herein can be supported by these various configurations of computing device 1200, and are not limited to specific examples of the techniques described herein. Functionality can also be implemented, wholly or partially, on "cloud" 1220 using distributed systems, such as through platform 1222 as described below.

[0118] Cloud 1220 includes and / or represents platform 1222 for resource 1224. Platform 1222 abstracts the underlying functionality of the hardware (e.g., server) and software resources of cloud 1220. Resource 1224 may include applications and / or data that can be used when performing computer processing on a server remote from computing device 1200. Resource 1224 may also include services provided via the Internet and / or via subscriber networks such as cellular or Wi-Fi networks.

[0119] Platform 1222 can abstract resources and functions to connect computing device 1200 to other computing devices. Platform 1222 can also be used to abstract resource hierarchy to provide a corresponding level of hierarchy for any encountered needs for resource 1224 implemented via platform 1222. Therefore, in interconnect device embodiments, the implementation of the functions described herein can be distributed throughout system 1200. For example, functions can be implemented partly on computing device 1200 and partly through platform 1222, which abstracts the functions of cloud 1220.

[0120] It should be understood that, for clarity, embodiments of this application have been described with reference to different functional units. However, it will be apparent that, without departing from this application, the functionality of each functional unit may be implemented in a single unit, in multiple units, or as part of other functional units. For example, functionality described as being performed by a single unit may be performed by multiple different units. Therefore, references to specific functional units are considered merely as references to the appropriate units used to provide the described functionality, and not as indicating a strict logical or physical structure or organization. Thus, this application may be implemented in a single unit, or may be physically and functionally distributed among different units and circuits.

[0121] It will be understood that although the terms first, second, third, etc., may be used herein to describe various devices, elements, components, or parts, these devices, elements, components, or parts should not be limited by these terms. These terms are used only to distinguish one device, element, component, or part from another device, element, component, or part.

[0122] Although this application has been described in conjunction with some embodiments, it is not intended to be limited to the specific forms set forth herein. Rather, the scope of this application is limited only by the appended claims. Additionally, although individual features may be included in different claims, these may be advantageously combined, and inclusion in different claims does not imply that such a combination of features is not feasible and / or advantageous. The order of features in the claims does not imply that the features must be in any particular order of their operation. Furthermore, in the claims, the word "comprising" does not exclude other elements, and the terms "a" or "an" do not exclude a plurality. Reference numerals in the claims are provided only by way of explicit example and should not be construed as limiting the scope of the claims in any way.

[0123] It should be understood that, for clarity, embodiments of this application have been described with reference to different functional units. However, it will be apparent that, without departing from this application, the functionality of each functional unit may be implemented in a single unit, in multiple units, or as part of other functional units. For example, functionality described as being performed by a single unit may be performed by multiple different units. Therefore, references to specific functional units are considered merely as references to the appropriate units used to provide the described functionality, and not as indicating a strict logical or physical structure or organization. Thus, this application may be implemented in a single unit, or may be physically and functionally distributed among different units and circuits.

[0124] This application provides a computer-readable storage medium storing computer-readable instructions thereon, which, when executed, implement the above-described method for generating a schedule for a non-player character or a training method for a schedule generation model.

[0125] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computing device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computing device to perform the methods for generating schedules for non-player characters or the training methods for schedule generation models provided in the various optional implementations described above.

[0126] By studying the accompanying drawings, the disclosure, and the appended claims, those skilled in the art can understand and implement variations of the disclosed embodiments in practicing the claimed subject matter. In the claims, the word "comprising" does not exclude other elements or steps, and "a" or "an" does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used advantageously.

[0127] It is understood that the specific embodiments of this application involve data related to the training process of generating schedules for non-player characters or schedule generation models. When the above embodiments of this application are applied to specific products or technologies, permission or consent from relevant users / platforms / organizations is required, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.< / unk> < / unk> < / s>

Claims

1. A method for generating a schedule for a non-player character, comprising: Obtain scene information corresponding to the game map of the target game. The scene information includes area information, atmosphere information, and location information. The area information indicates multiple areas in the game map. Each of the multiple areas is used to carry corresponding functions and corresponding non-player characters. The atmosphere information indicates the corresponding environmental conditions of each of the multiple areas in the target game at different time periods. The location information indicates the specific location within each of the multiple areas. Obtain the identity information of the target non-player character, wherein the identity information includes at least the name, occupation, and character description of the target non-player character; as well as Based at least on the scene information, the identity information, and the candidate game actions corresponding to the target non-player character, a schedule for the target non-player character is generated using a trained first language model, wherein the candidate game actions are obtained by selecting corresponding game actions as candidate game actions from a pre-built entity knowledge base based on at least one of the scene information and the identity information, wherein the entity knowledge base is constructed based on at least a plurality of game actions pre-designed for the target game.

2. The method according to claim 1, wherein obtaining the scene information corresponding to the game map of the target game includes: Based on the map description information corresponding to the game map, the scene information corresponding to the game map of the target game is obtained using a trained second language model.

3. The method according to claim 1, wherein obtaining the identity information of the target non-player character includes: Based at least on the area information and atmosphere information in the scene information, the identity information of the target non-player character is obtained using a trained third language model.

4. The method according to claim 1, wherein generating the schedule of the target non-player character using a trained first language model based at least on the scene information, the identity information, and the candidate game actions corresponding to the target non-player character includes: The scene information, the identity information, and the action description information corresponding to the candidate game actions are used as at least a part of the input data and input into the trained first language model to generate the schedule of the target non-player character.

5. The method according to claim 4, wherein the input data further includes entity supplementary information, the entity supplementary information being obtained through the following steps: Named entity recognition processing is performed on at least one of the scene information, the identity information, and the action description information to obtain the corresponding entity recognition result; Based on the entity recognition result, corresponding entity knowledge is selected from the entity knowledge base as supplementary information for the entity. The selected entity knowledge includes at least one of the following: game background information, character background information, positional relationship information, and character relationship information.

6. The method according to claim 5, wherein each entity knowledge in the entity knowledge base is stored in the entity knowledge base in vector form, the entity feature vector corresponding to each entity knowledge is obtained by transforming the corresponding entity knowledge using a trained fourth language model and has a preset length, and wherein selecting corresponding entity knowledge from the entity knowledge base as supplementary entity information according to the entity recognition result includes: The trained fourth language model is used to convert the entity recognition result into a query feature vector; When the length of the query feature vector is inconsistent with the preset length, the query feature vector is scaled to make its length consistent with the preset length; and The similarity between the query feature vector and the entity feature vector corresponding to each entity knowledge in the entity knowledge base is compared, and the entity knowledge corresponding to the entity feature vector that meets the preset comparison conditions is used as the entity supplementary information.

7. The method according to any one of claims 1-6, wherein the schedule of the target non-player character includes: The target game action corresponding to the candidate game action, the target time period in the target game for the target non-player character to perform the target game action, and the target location in the target area of ​​the multiple regions for the target non-player character to perform the target game action.

8. The method of claim 7, wherein the schedule of the target non-player character further comprises: The location type of the target location, wherein the location type indicates whether the target non-player character performs the target game action at a single location.

9. A training method for a schedule generation model, comprising: Obtain sample scene information corresponding to the sample game map of the sample game. The sample scene information includes sample area information, sample atmosphere information, and sample point information. The sample area information indicates multiple sample areas in the sample game map. Each sample area in the multiple sample areas is used to carry corresponding functions and corresponding non-player characters. The sample atmosphere information indicates the corresponding environmental conditions of each sample area in the multiple sample areas during different time periods in the sample game. The sample point information indicates the specific location within each sample area in the multiple sample areas. Obtain multiple sample identity information corresponding to multiple sample non-player characters. Each sample identity information includes at least the name information, occupation information, and character introduction of the corresponding sample non-player character among the multiple sample non-player characters. Based at least on the sample scene information, the multiple sample identity information, and the multiple candidate game actions corresponding to the multiple sample non-player characters, a schedule generation model is used to generate multiple sample schedules corresponding to the multiple sample non-player characters. Each of the multiple candidate game actions is obtained by selecting a corresponding game action as a corresponding candidate game action from a pre-built entity knowledge base based on at least one of the sample scene information and the sample identity information corresponding to the corresponding sample non-player character from the multiple sample identity information. The entity knowledge base is constructed based at least on multiple game actions pre-designed for the sample game. Based on the multiple sample schedules and the multiple labeled schedules corresponding to the multiple sample schedules, the target loss is determined; as well as The parameters of the schedule generation model are iteratively updated so that the target loss meets the preset training conditions.

10. The method according to claim 9, wherein generating multiple sample schedules corresponding to the multiple sample non-player characters using a schedule generation model based at least on the sample scene information, the multiple sample identity information, and the multiple candidate game actions corresponding to the multiple sample non-player characters includes: The sample scene information, the multiple sample identity information, the multiple action description information corresponding to the multiple candidate game actions, and the multiple historical schedules corresponding to the multiple sample non-player characters are used as at least a part of the input data and input into the schedule generation model to generate multiple sample schedules corresponding to the multiple sample non-player characters, wherein each of the multiple historical schedules includes: The historical game action, the target time period for a non-player character to perform the historical game action in the historical game, and the historical location within the historical area of ​​the historical game map for the non-player character to perform the historical game action.

11. The method of claim 9, wherein the schedule generation model comprises an embedding acquisition module, a location encoding module, and a decoding output module, and wherein, The embedding acquisition module is configured to convert the input data of the schedule generation model into a first feature vector; The position encoding module is configured to convert the first feature vector into a second feature vector by adding position information to the first feature vector, wherein the position information is used to characterize the relative positions between different parts of the input data; The decoding output module is configured to convert the second feature vector into output data of the schedule generation model.

12. An apparatus for generating a schedule for a non-player character, comprising: The scene information acquisition module is configured to acquire scene information corresponding to the game map of the target game. The scene information includes area information, atmosphere information, and location information. The area information indicates multiple areas in the game map. Each of the multiple areas is used to carry corresponding functions and corresponding non-player characters. The atmosphere information indicates the corresponding environmental conditions of each of the multiple areas in the target game at different time periods. The location information indicates the specific location within each of the multiple areas. The identity information acquisition module is configured to acquire the identity information of the target non-player character, wherein the identity information includes at least the name information, occupation information, and character introduction of the target non-player character; as well as The schedule generation module is configured to generate a schedule for the target non-player character using a trained first language model, based at least on the scene information, the identity information, and candidate game actions corresponding to the target non-player character. The candidate game actions are obtained by selecting corresponding game actions from a pre-built entity knowledge base as the candidate game actions based on at least one of the scene information and the identity information. The entity knowledge base is constructed based on at least a number of game actions pre-designed for the target game.

13. A computing device, comprising: Memory, which is configured to store computer-executable instructions; A processor configured to perform the method according to any one of claims 1 to 11 when the computer-executable instructions are executed by the processor.

14. A computer-readable storage medium storing computer-executable instructions that, when executed, perform the method according to any one of claims 1 to 11.

15. A computer program product comprising computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, perform the method according to any one of claims 1 to 11.

Images