Method, apparatus and electronic device for visualizing execution of a script

Abstract

The application provides a method and device for visualizing script execution and an electronic device, and relates to the field of computer application, to alleviate the technical problem of low debugging efficiency of the visual script. The method comprises the following steps: obtaining and analyzing file data to be executed corresponding to a current visual script to obtain a program outline used for representing a data structure, wherein the program outline comprises functions and variables of the file data to be executed, and each function corresponds to a blueprint; each function and each variable is valued according to the file data to be executed; each blueprint corresponding to each function is instantiated and analyzed to obtain a runnable blueprint, so that the runnable blueprint executes a corresponding target operation according to a user operation instruction.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer application, and in particular, to a visual script execution method and device and electronic equipment. BACKGROUND

[0002] At present, there are various mature visual scripts in the game development industry. However, before the current visual script is run, a set of visual script systems is used to deserialize the to-be-executed data into node instances at runtime, and then each node instance is executed according to the execution rules of the visual script. The node instance obtained in this way is relatively complex, and the debugging process is relatively low in efficiency. SUMMARY

[0003] The present application aims to provide a visual script execution method and device and electronic equipment to alleviate the technical problem of low debugging efficiency of the visual script.

[0004] In a first aspect, the present application provides a visual script execution method, which comprises the following steps:

[0005] Obtaining and parsing to-be-executed file data corresponding to a current visual script to obtain a program outline used to represent the data structure, wherein the program outline comprises functions and variables of the to-be-executed file data, and each function corresponds to a blueprint.

[0006] Assigning values to each function and each variable according to the to-be-executed file data.

[0007] Instantiating and parsing the blueprint corresponding to each function to obtain a runnable blueprint, so that the runnable blueprint performs a corresponding target operation according to a user operation instruction.

[0008] In one possible implementation, the visual script is a single-linked list formed by a plurality of different action nodes, wherein the action node infers a parameter tree in the case of passing in parameters, the parameter tree takes the action node as the root, and the child nodes of the parameter tree are composed of parameter nodes; the action node is a node with a connection for a logical output port, and the parameter node is a node without a connection for a logical output port.

[0009] In one possible implementation, when the node has a plurality of logical output ports, a branch is generated from the main trunk of the single-linked list, and the structure of the branch is exactly the same as that of the main trunk.

[0010] In one possible implementation, the program outline is a node tree, and each node corresponds to a variable or a function or a class.

[0011] In a possible implementation, before the step of assigning a value to each of the functions and each of the variables according to the to-be-executed file data, the method further includes:

[0012] The data of the to-be-executed file is deserialized, and a connection between the runtime node of the program outline and the node is constructed.

[0013] In one possible implementation, the step of assigning a value to each of the functions and each of the variables according to the to-be-executed file data includes:

[0014] The functions and variables corresponding to each node in the program outline are assigned values ​​in sequence according to the to-be-executed file data.

[0015] In one possible implementation, the step of instantiating and parsing the blueprint corresponding to each function to obtain an executable blueprint includes:

[0016] Calling the data reading function to obtain the preliminarily sorted node information and node connection information from the to-be-executed file data, wherein the node information includes the node ID and Meta type, and the node ID is the uuid of the node in the editor;

[0017] Instantiate each node based on its Meta type and class, and obtain the new node ID at runtime.

[0018] generating a runtime node connection according to the node connection information;

[0019] Determining the connection relationship between the nodes according to the logical output ports of the nodes;

[0020] Repeat the above steps to construct each node of the program outline at runtime in a depth-first search order to generate a runnable blueprint.

[0021] In one possible implementation, the method further includes:

[0022] The corresponding logic in the executable blueprint is executed according to the different return values ​​of each node, wherein the parameter nodes are executed in post-order traversal and the process nodes are executed in pre-order traversal, and the process nodes are a type of action nodes.

[0023] In one possible implementation, a node in the program outline corresponds to a main function, and the method further includes:

[0024] When the to-be-executed file data is executed as a main module, the executable blueprint corresponding to the main function is executed.

[0025] In one possible implementation, the method further includes:

[0026] In a possible implementation, the program outline is converted into a preset scripting language format according to a preset code template.

[0027] The step of converting the program outline into a preset scripting language format according to a preset code template includes:

[0028] The nodes of the program outline are traversed, and according to the type of each node of the program outline, a template code of a corresponding type is obtained from the preset code template, and a node code is converted from the template code.

[0029] In a possible implementation, the method further includes: defining a module name, a class name, a function name, and a variable name of the visual script according to the preset scripting language.

[0030] In a second aspect, a visual script execution device is provided, comprising:

[0031] A parsing module, configured to obtain and parse the to-be-executed file data corresponding to the current visual script to obtain a program outline for representing the data structure, wherein the program outline includes functions and variables of the to-be-executed file data, and each function corresponds to a blueprint;

[0032] An assignment module, configured to assign a value to each of the functions and each of the variables according to the to-be-executed file data;

[0033] The execution module is used to instantiate and parse the blueprint corresponding to each function to obtain an executable blueprint, so that the executable blueprint executes the corresponding target operation according to the user operation instruction.

[0034] In a third aspect, an embodiment of the present application provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the computer program, the method described in the first aspect is implemented.

[0035] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions prompt the processor to execute the method described in the first aspect above.

[0036] The embodiments of the present application bring the following beneficial effects:

[0037] The embodiments of the present application provide a method, device, and electronic device for executing a visual script to alleviate the technical problem of low debugging efficiency through visual scripts.

[0038] In this solution, the program outline for representing the data structure of the executable file of the visual script can be obtained by parsing the executable file data. Based on the program outline, each function and variable of the executable file can be assigned a value, and instantiated nodes and connections can be constructed to obtain an executable blueprint, so that the user can directly execute the operations corresponding to the executable blueprint without compiling or reloading the script, and can also be directly executed when the game is running, which is convenient for user debugging.

[0039] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the specific implementation methods of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the specific implementation methods or the description of the prior art. Obviously, the drawings described below are some implementation methods of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0041] Figure 1 A schematic diagram of a visual script editor interface provided by an embodiment of the present application is shown;

[0042] Figure 2 A flowchart of a method for executing a visual script provided in an embodiment of the present application;

[0043] Figure 3 A schematic diagram showing a script structure provided by an embodiment of the present application is shown;

[0044] Figure 4 A schematic diagram showing another script structure provided in an embodiment of the present application is shown;

[0045] Figure 5 A schematic diagram showing another script structure provided in an embodiment of the present application is shown;

[0046] Figure 6 A schematic diagram of the structure of a visual script execution device provided in an embodiment of the present application;

[0047] Figure 7 A schematic structural diagram of an electronic device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0048] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0049] The terms "including," "having," and any variations thereof, as used in the embodiments of this application, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or units is not limited to the listed steps or units but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to the process, method, product, or apparatus.

[0050] Visual scripting is a script editing tool that allows you to edit scripts interactively through a GUI interface. Examples include triggers in the classic Warcraft 3 World Editor, Blueprints in the UE4 engine, third-party plugins like Bolt in Unity, and triggers in the Uni Editor in Onmyoji Arena.

[0051] Compared to code, visual scripting is more intuitive and easier for non-technical people to accept. In the game industry, it is very common for non-technical people (planners and artists) to verify their ideas by making prototypes. Therefore, visual scripting is widely used in the game development industry.

[0052] However, this type of visual script only saves the data of the graph edited by the user as a file, such as the location of nodes in the graph, node data, and connection information between nodes. When the visual script is run, a visual script system first deserializes this saved data into runtime node instances, and then executes each node instance according to the visual script's execution rules. This method instantiates the script's saved data into multiple classes, requiring calls to corresponding methods in the instances for execution. Even if the saved data to be executed is relatively simple, the above complex instantiation operation is still required.

[0053] To address this issue, visual scripts are compiled into code, which is then executed to run the visual script. However, this approach also has some issues. For example, the compiled code lacks a universal scripting language, making it difficult to widely apply. Furthermore, the compiled code contains many character sequences, such as function names and memory addresses, making it difficult to read and maintain.

[0054] Based on this, an embodiment of the present application provides a method for executing a visual script, which can alleviate the technical problem of low execution efficiency during the visual script debugging process.

[0055] like Figure 1 As shown, Figure 1 Schematic diagram of the visual script editor interface provided for the embodiment of the present application. The visual script editor interface structure is divided into 6 areas in total to enable users to edit the script content. Among them, the menu bar 1 is mainly used for file management and window management; the toolbar 2 mainly contains some common operating actions during editing; the program outline Hierarchy window 3 is a window proposed in the embodiment of the present invention, which displays the currently edited file structure to be executed, and variables, functions, classes, and import modules can be added through this window; the export information editing window 4 is used to edit the export information of the current file to be executed; the blueprint editing window 5 is the main window for logic editing; the node attribute window 6 is used to enter the variable name, enter the original value, and add the node port.

[0056] The embodiments of the present application are further described below with reference to the accompanying drawings.

[0057] Figure 2 A flowchart of a method for executing a visual script provided in an embodiment of the present application. The method is applied to a client, such as a visual script editor. Figure 2 As shown, the method includes:

[0058] Step S110 , obtaining and parsing the to-be-executed file data corresponding to the current visual script, and obtaining a program outline for representing the data structure, wherein the program outline includes functions and variables of the to-be-executed file data, and each function corresponds to a blueprint.

[0059] Among them, the visual script in the embodiment of the present invention is UchihaVScript. Based on the structure of this visual script, the effect of fast debugging execution can be achieved. After the visual script is run, the editor will save the file data to be executed (a file with the extension uvs), and the editor can achieve visual reproduction of the script based on the file data to be executed. It should be noted that the name UchihaVScript and the file extension uvs of the visual script in the embodiment of the present application are only used for convenience of description and do not constitute a limitation on the scope of protection of this application.

[0060] In some embodiments, the following method is also included: when the file data to be executed is executed as a main module, the executable blueprint corresponding to the main function is executed.

[0061] It should be noted that each uvs file has a program outline Hierarchy node named main function `__main__`. When this uvs is executed as the main module, the blueprint corresponding to `__main__` will be executed.

[0062] It should be noted that a blueprint can be used to represent the operating logic of its corresponding function.

[0063] To understand the data structure of the script, let's take a look at a simple script:

[0064] print('script start')

[0065] print('Hello world')

[0066] print('script end')

[0067] Among them, this script is very simple and just prints 3 strings. If each line of code is regarded as a node, and the nodes are connected through logical ports, we will get a Figure 3 The script structure shown is that the script is a one-way linked list formed by stringing together several different action nodes.

[0068] In some slightly more complex structures, such as the following script:

[0069] print([0,len([1,2,3])])

[0070] Among them, the script can be understood as the printing operation needs to pass in 1 parameter, which is a list list, which has 2 items: the first item is 0, the second item is the length of an object, and the object needs to be passed in, and the object is another list list, which has 3 items: the first item is 1, the second item is 2, and the third item is 3. The incoming script structure of this parameter is actually a tree, such as Figure 4 shown.

[0071] In some embodiments, different nodes can be classified as follows: action nodes: each row can be regarded as an action node, corresponding to the nodes with connected logical ports in the graph; parameter nodes: each action node may require the input of several parameters, and the parameter node may also require the input of several parameters. These nodes can be regarded as parameter nodes, and their characteristic is that the logical ports are not connected.

[0072] In some cases, there are more complex situations, such as this script:

[0073]

[0074] Among them, if appears in this script, and the logic has branches. The script is no longer a simple one-way linked list structure, but has branches along with the logic, such as Figure 5 As shown, when a script encounters a logic control node (if / for / while / def...), or when a node has multiple logical output ports, a branch is generated. The data structure of the branch is exactly the same as the main branch. If a new logic control node is encountered in a branch, a new sub-branch will be generated, and so on.

[0075] The visual script provided by the embodiments of the present invention can be understood as a one-way linked list consisting of several different action nodes. Each action node may extend a parameter tree due to the need to input parameters. The parameter tree is rooted at the action node, and its child nodes are composed of parameter nodes. When the script encounters a node with multiple logical output ports, it branches from the main trunk, and the structure of the branches is exactly the same as that of the main trunk. In other words, the script can be understood as a combination of a process tree composed primarily of action nodes and a parameter tree composed primarily of parameter nodes.

[0076] Step S120 , assigning values ​​to each function and each variable according to the file data to be executed.

[0077] Among them, according to the number of functions, variables and static classes in the to-be-executed file data of the program outline, it should be noted that corresponding values ​​can be assigned to each function and variable according to the to-be-executed file data.

[0078] Step S130: instantiate and parse the blueprint corresponding to each function to obtain an executable blueprint, so that the executable blueprint executes the corresponding target operation according to the user operation instruction.

[0079] Among them, the blueprint can be edited by creating instantiated nodes and connecting them to obtain a runnable blueprint. It should be noted that when a user clicks the run control on a client, the runnable blueprint can be directly executed. The client can be the same client as the editor client or a different client.

[0080] In an embodiment of the present application, a program outline for characterizing the data structure of a visual script's executable file can be obtained by parsing the executable file data. Based on the program outline, each function and variable of the executable file can be assigned a value, and instantiated nodes and connections can be constructed to obtain an executable blueprint, so that the user can directly execute the operations corresponding to the executable blueprint without compiling or reloading the script, and can also be directly executed when the game is running, which is convenient for user debugging.

[0081] In some embodiments, before step S120, a simulation run is required to deserialize the UVS file data to generate runtime nodes and execute the corresponding logic. The advantage is that it does not require compilation or script reloading, and can be directly executed during game runtime, making it easier for users to debug. As an example, it includes the following steps:

[0082] Step 1.1) Deserialize the data of the file to be executed and construct the connection between the runtime node of the program outline and the nodes.

[0083] For example, the first step of the simulation run is deserialization. The uvs file is a json file with the following data structure:

[0084]

[0085]

[0086] The outermost layer in the above code is a dictionary with three keys. UchihaVScript corresponds to the hierarchy data of uvs; Version is the version information of uvs, which is currently 1.0; ModuleID: the module ID corresponding to the uvs file, such as `gcore.systems.gameplay_system.demo_system`, which will only be available after the user specifies the export directory of uvs.

[0087] The data of each hierarchy node is a dict, and its key is as follows: Type: is the type of the node, the root node and import node are HierarchyTreeNode, and the variables / functions / methods / classes / `__main__` are uvsVariable / uvsFunction / uvsMethod / uvsClass / uvsMain respectively; nodeType is the Enum corresponding to the node type; nodeID is the unique id of the node; varName is the variable name corresponding to the node, which is only available for variables, functions, methods, and classes; children represents the information of all child nodes. graphData is the blueprint information corresponding to the node, which is only available for nodes with blueprints. It is a dict, and its key is as follows: lineData is the connection information, which is an array. Each item in the array is a dict, and its key is as follows: startNode: the uuid of the starting node of the connection; startPort is the name of the starting port of the connection; endNode: the uuid of the ending node of the connection; endPort: the name of the ending port of the connection. nodeData is the blueprint node information, which is a dict. The key is the uuid of each blueprint node, and the value is a dict. The key is as follows: nodeID is the uuid of the blueprint node; Type is the blueprint node class name; Name is the blueprint node title; Pos is the position of the blueprint node in the interface; Data: the custom data of the node; libInfo: only available for import nodes, it is a dict, the key is as follows: libID is 'libType.' + ModuleID, for example `uvs.gcore.systems.gameplay_system.demo_system`; memberName: this key is only available for from import, indicating the name of the imported member;

[0088] It should be noted that after the above code clarifies the data structure of the uvs file, it can be deserialized based on the data to achieve runtime node and line generation. Among them, the NodeGraphBuilder module is responsible for runtime node and line generation.

[0089] Deserialization first requires building runtime hierarchy information. After NodeGraphBuilder is instantiated, it reads the `'UchihaVScript'` key from the uvs file to obtain the program outline hierarchy information. This information is then passed to the program outline node constructor, `HierarchyNode.CreateWithDict`, to complete the construction of the runtime program outline nodes and their parent-child relationships. It's important to note that this constructor sorts the node information to create the runtime program outline nodes.

[0090] The HierarchyNode.CreateWithDict function recursively calls itself until all child nodes are created. Therefore, you only need to pass the entire Hierarchy data into it to get the root node of the Hierarchy, and then get the entire Hierarchy information through the root node.

[0091] After the Hierarchy node is instantiated at runtime, the Hierarchy variables, classes, and functions are constructed by calling the `nodeGraphBuilder.ConstructWithHierarchyNode(hierarchyRoot)` function. Step S120 also includes assigning values ​​to the functions and variables corresponding to each node in the program outline in turn according to the data of the file to be executed.

[0092] The ConstructWithHierarchyNode function first reads the blueprint information of the Hierarchy node and uses this blueprint information to build the runtime blueprint, as detailed in subsequent step S130. Secondly, this function processes various types of Hierarchy nodes, including Main / Import / Variable / Function / Class / Method, etc. The generation of functions, classes, and variables is completed in the `self.BuildHierarchyNode(hierarchyNode)` function. Finally, each node in the program outline is traversed, recursively calling the current function, and building the entire Hierarchy in a depth-first search order.

[0093] The `self.BuildHierarchyNode(hierarchyNode)` function instantiates a NodeGraph for building, then calls the `NodeGraph.BuildRun()` interface to generate the various variables, classes, and functions defined in the user's UVs. Because the execution process for variables and functions is identical to the Blueprint execution process (except for classes, which are created directly in this function), the NodeGraph is reused here to generate this information. This will be detailed in the subsequent section on the Blueprint execution process.

[0094] After the runtime Hierarchy information is built, you can start building the runtime blueprint information.

[0095] `builder.ConstructWithHierarchyNode(hierarchyNode)` will call `builder.BuilduvsData(uvsData)` to build blueprint information.

[0096] The process can be implemented by the following steps. As an example, step S130 further includes the following steps:

[0097] Step 2.1) Call the data reading function to obtain the preliminary sorted node information and node connection information from the file data to be executed. The node information includes the node ID and Meta type. The node ID is the uuid of the node in the editor.

[0098] For example, by calling uvsDataReader, we can get the preliminary sorted node information and node connection information. The node ID we get here is the uuid of the node in the editor.

[0099] Step 2.2) Instantiate each node based on its Meta type and class, and obtain the new node ID at runtime.

[0100] Among them, traverse the nodes obtained by uvsDataReader, and use the corresponding class to instantiate nodes of different Meta types according to the META_TYPE information sorted out. The previous Meta types are equivalent to special processing (RawInputParameter / Event / Variable / Function / Method) because the Meta definitions of these nodes are in the editor, and almost all node META_TYPE is Action, that is, the Meta definition of the node is on the game side. These nodes are instantiated through NodeManager, and the PROPERTIES (that is, the information edited in the PropertyWindow) is updated to the node through the UpdataObject method. For dynamic port nodes, you also need to call `initPorts()` to create dynamic ports;

[0101] Step 2.3), generating runtime node connections based on the node connection information;

[0102] It should be noted that after the node is instantiated, the runtime id of the node is obtained through the `self.AddNode(node)` method. The runtime nodes are added to a list, so the runtime node ID is an int. It should be noted that the runtime node is wrapped in a layer of NodeRuntime. The NodeRuntime is also taken out from the NodeBuffer. The node itself needs to be obtained through NodeRuntime.node;

[0103] Step 2.4), determine the connection relationship between nodes based on the logical output ports of the nodes;

[0104] For example, after the runtime node id is generated, the runtime node connection is generated according to the node connection information obtained by uvsDataReader (calling the `self.ConnectNode()` method). Note that the runtime node connection also exists on NodeRuntime, and when connecting nodes, it will also determine whether the ports can be connected;

[0105] Step 2.5), repeat the above steps to construct each node of the runtime program outline in the order of depth-first search to generate a runnable blueprint.

[0106] After the above steps, deserialization has been completed and the blueprint can be executed.

[0107] It should be noted that there are two ways to run the blueprint. The first is to run uvs as the main module:

[0108] uvs.Run()

[0109] Another way is to import uvs as a module and execute the module members:

[0110] uvsSpellModule=uvs.Importuvs(uvsFilename)

[0111] uvsSpellModule.SpellStart(spell)

[0112] Regardless of the method, the Blueprint is executed through the NodeGraph, which is also described as the Blueprint below.

[0113] For example, before explaining how a blueprint is executed, the classification of nodes and their return values ​​are explained. The most basic nodes include two types: action nodes and parameter nodes.

[0114] Action nodes generally execute certain logic and do not return a value, while parameter nodes involve parameter passing and do return a value. Action nodes can be further divided into: ordinary action nodes: which only execute certain logic; compound action nodes: which execute certain logic and return a value; process nodes: when executed at this node, different branches will be executed based on the conditions, such as if / for / while; process control nodes: when executed at this node, the current logic branch can be controlled, such as continue / break / return / yield; compound process control nodes: which can both control the current logic branch and affect the return value of the blueprint, such as return value / yield value.

[0115] In some embodiments, different types of nodes may have different types of return values, and the blueprint executes corresponding logic based on the different return values ​​of the nodes. In one embodiment of the present invention, the method further includes, in step 3.1), executing corresponding logic in the executable blueprint based on the different return values ​​of each node, wherein parameter nodes are executed in post-order traversal and action nodes are executed in pre-order traversal.

[0116] The execution of a blueprint starts from the root node. Therefore, to start executing a blueprint, you only need to call the graph.StartNode(rootID) function.

[0117] It should be noted that the StartNode execution process is as follows:

[0118] 1. Post-order traversal of the execution parameter tree to obtain the port parameter input value;

[0119] 2. Execute the current node and get the node return value `runResult`;

[0120] 3. When the `runResult` type is str, it indicates a process node; when the type is int, it indicates a process control node; when the type is tuple, it indicates a composite node, and the corresponding logic is executed according to the different types of nodes;

[0121] 4. For the remaining nodes, execute FinishNode to end the current node;

[0122] FinishNode execution process is as follows:

[0123] 1. Pass the return value of the parameter node to the next port according to the port;

[0124] 2. Get the next logical node and recursively call StartNode to execute its logic;

[0125] 3. When there is no next logical node, execute FinshGraph;

[0126] FinishGraph is relatively simple and calls back the finishCallback of the blueprint.

[0127] In general, it can be summarized as follows: the parameter tree is executed in post-order traversal, and the process tree is executed in pre-order traversal. Among them, the process tree is composed of process nodes.

[0128] In some embodiments, if the return value of the process control node is str, and str is the logical port name corresponding to the logical branch currently to be executed, the specific implementation is:

[0129]

[0130] It can be understood that the process control node obtains the process subtree root node ID through the return value; if there is no connection, the current node is terminated directly; if there is a connection, the subtree is executed;

[0131] It can be seen from the above embodiments that the structure of the process branch is consistent with the structure of the trunk. Therefore, when executing the process subtree, it is only necessary to instantiate a new blueprint and execute the above-mentioned operation process from its root node. Among them, when the process subtree is executed, `_finishCb` will be called back, and whether to exit the loop will be decided based on the node type and the corresponding end reason of the node.

[0132] It should be noted that the reason for the end will be transmitted when the subgraph ends. If the reason is return, the subgraph will be released; if it ends normally, the FinishNode function will be called to continue triggering the next node of the original tree. If the current node type is a loop node, the reason for the end of the loop sub-blueprint corresponding to the loop node will be used to decide whether to continue entering the loop or exit the loop.

[0133] In some embodiments, if the return value of the flow control node is int, int is an Enum:

[0134]

[0135] The specific implementation is:

[0136]

[0137] According to the above code, the return node ends each subgraph of the current process with the reason of RETURN. The yield node pauses the current graph and waits for the next activation. The break and continue nodes find the subgraph of the nearest loop.

[0138] In some embodiments, if the return value of a composite node is a tuple, there are three cases:

[0139] 1. int+list is a return value node or yield value node;

[0140] 2.None+dict is a function call that can return a value;

[0141] 3.str+dict is a for loop;

[0142] The specific implementation is:

[0143]

[0144]

[0145] As can be seen from the above code, in the first case, the yield node and return node are basically the same as before, except that the blueprint output is set; in the second case, the function call that can return a value determines whether to end the current node based on whether the current node is a parameter node; in the third case, the for loop is also similar to the previous process node implementation, with the addition of passing the value of the loop local variable, which will not be repeated here.

[0146] As an optional embodiment, the method further includes step 4.1) converting the program outline into a preset scripting language format according to a preset code template. In the embodiment of the present invention, the preset scripting language is Python.

[0147] For example, first get the template code of each node. The template code is defined by the node designer in NodeMeta, such as the NodeMeta of PrintNode:

[0148]

[0149] The `TPL_CODE` is the template code defined by the node designer. After the node designer defines the template code of the node, the uvs editor generates the py code corresponding to the uvs according to the template code of each node.

[0150] The real-time uvs2Code pre-processes the template code by the function_fixTemplateIndent before generating the template, removes unnecessary indentation and line breaks, and obtains clean and effective template code.

[0151] In addition, there are some Hierarchy nodes without template code, such as class, import, main, and their template definitions are in another file.

[0152] The template code of the class is as follows:

[0153] class{{varName}}({{base|join(',')}}):

[0154] {%if code!=”%}{{'\n'}}{{code}}{%else%}{{indent}}pass{%-endif%}

[0155] The template code of the variable is as follows:

[0156] {%if code!=”%}{{code}}{{'\n'}}{%endif%}

[0157] The template code of the function is as follows:

[0158] {%if methodDecorator%}@{{methodDecorator}}{{'\n'}}{%endif%}{%ifdecorator%}@{{decorator}}{{'\n'}}{%endif%}def{{varName}}({{formalArgs|join(',')}}):

[0159] {%if importInfo%}{{importInfo}}{{'\n'}}{{'\n'}}{%endif%}{%if do!=”%}{{do}}{%else%}{{indent}}pass{%-endif%}

[0160] The template code of the method is as follows:

[0161] {%if decorator%}@{{decorator}}{{'\n'}}{%endif%}def{{varName}}(self{%if formalArgs%},{%endif%}{{formalArgs|join(',')}}):

[0162] {%if importInfo%}{{importInfo}}{{'\n'}}{{'\n'}}{%endif%}{%if do! =”%}{{do}}{%else%}{{indent}}pass{%-endif%}

[0163] `__main__` template code:

[0164] {%if code! ="%}if__name__=='__main__':{{'\n'}}{{code}}{{'\n'}}{%endif%}

[0165] Import template code:

[0166] {%if memberName%}from{{libID}}import{{memberName}}{%else%}import{{libID}}{%endif%}

[0167] The template code of the entire uvs module:

[0168] #-*-coding:utf-8-*-

[0169] #This file is automatically generated by the UchihaVScript plug-in

[0170] #Please do not modify the code manually, your changes will be overwritten the next time you generate the code, unless you know what you are doing

[0171] {%if importInfo! ="%}{{importInfo}}{{'\n'}}{{'\n'}}{{'\n'}}{%endif%}{{code}}

[0172] After getting the uvs data, the first thing we get is the Hierarchy data, so the first step of uvs2Code should be to analyze the Hierarchy and get its corresponding code.

[0173] Its main functions are the following two:

[0174]

[0175]

[0176]

[0177] The above-mentioned step 4.1) can also be implemented by the following steps:

[0178] Step 5.1) traverse the nodes of the program outline, obtain the corresponding type of template code from the preset code template according to the type of each node of the program outline, and convert the node code through the template code.

[0179] In actual application, the Hierarchy child nodes are traversed to generate the code for each child node; different template codes are obtained from jinja_env according to different types of Hierarchy nodes, and the code is rendered through the template code; it can be seen that if the Hierarchy node has blueprint information, a uvsEditor will be instantiated through the `_contructEditor()` function and this uvsEditor instance will be used to generate the blueprint code.

[0180] Among them, the root node of the blueprint can be found through the genEditorCode function, and then the most important function genNodeCode is called to generate the blueprint code.

[0181] The parameters of genNodeCode are as follows:

[0182]

[0183] When the render template generates code, the values ​​of the variables in the template code must be passed in to render the code normally, so all the parameters that need to be passed in when rendering are recorded in this inputKwargs dictionary.

[0184] inputKwargs={}#Parameters to be passed when rendering the template

[0185] The first thing to do when generating blueprint node code is to check the library dependency node. Let's take a look at the template code of the library dependency node:

[0186]

[0187]

[0188] This is the pi function `math.pi`, and its dependent library is `math`. When the user `import math`, the node code is `math.pi`, and when the user `from math import pi`, the node code is `pi`. Therefore, it is necessary to check the library import type of this node and generate different library information prefixes based on the library import type.

[0189] Once the library information prefix is ​​confirmed, the next step is to generate the parameter subtree code.

[0190] Similar to simulation, the code of the parameter subtree is obtained by recursively calling the current function in post-order traversal, and the key of the parameter subtree code is set to the parameter port name. This is done to facilitate node designers in designing node template code.

[0191]

[0192] Next, we need to generate the source code related to the variable names.

[0193] When rendering a template, if a string is passed in, the resulting string will be without quotes. This can be shown in the following script:

[0194] a='a'

[0195] A variable named a is defined, and its value is the string `'a'`. It is not difficult to imagine that its template code should be similar to:

[0196] '{{varName}}={{value}}'

[0197] But if the render template looks like this:

[0198] template=Template('{{varName}}={{value}}')

[0199] template.render(varName='a',value='a')

[0200] The result is:

[0201] a=a

[0202] As you can see, the above situation does not meet the requirements. Therefore, for terms whose values ​​are strings, we need to first distinguish whether the string is source code or value.

[0203] Another example is setting the Meta of a variable node:

[0204]

[0205] When defining node meta, you can define `SRC_CODE_KEYS` and pass in a key list. When generating code, the keys in this list will not be quoted when input.

[0206] The next step is to generate the code for the process subtree.

[0207] For process nodes with multiple logical output ports, similar to the parameter subtree, the current function is still recursively called to obtain the process subtree code.

[0208]

[0209]

[0210] Note that `subtreePort` is used here to record the process subtree port name. This is mainly used to add indentation to the process subtree. Because in Python syntax, a process subtree is always indented one more space than the parent tree. Therefore, you need to add one more space of indentation before adding the process subtree to the parent tree.

[0211] As you can see, inputKwargs is ready at this point, and you can directly call the render function to generate the source code:

[0212] nodeCode=nodeCodeTemplate.render(**inputKwargs)

[0213] At this time, if the current node is a parameter node, the code is returned directly:

[0214] if isParameter:

[0215] #Parameters return the code directly

[0216] return True,nodeCode

[0217] If it is not a parameter node, the current function can be recursively called to continue generating the next process node code. If there are no subsequent nodes, the generated code can be returned.

[0218]

[0219] The UchihaVScript of the embodiment of the present invention can design the node creation rules, connection rules, function definition rules, class definition rules, and module import rules of the visual script according to Python syntax, and implement the editor of the visual script based on these rules. After the editor is implemented, the visual script data serialized by the editor is read to generate the runtime blueprint. According to the following principles, the blueprint is traversed:

[0220] A script is a singly linked list consisting of several action nodes. Each action node may extend a parameter tree due to the required parameters. The parameter tree is rooted at the action node, with child nodes consisting of parameter nodes. When a script encounters a node with multiple logical output ports, branches are generated from the main trunk. The branch structure is identical to the main trunk. Each node in a blueprint has a runtime callback function and node template code.

[0221] When traversing a blueprint, calling the callback function of the node runtime completes the simulation run of the visual script. Simulation run can skip the code generation step and directly execute the visual script during game runtime, skipping the steps such as reloading the script or restarting the client, making it easier for users to debug.

[0222] When traversing the blueprint, the template code of the node is read to convert the visual script into Python script code.

[0223] The UchihaVScript of the embodiment of the present invention has the following advantages as a visual script: it supports both execution by deserializing data to generate runtime nodes and exporting code for execution, which is convenient for user debugging and can solve the execution efficiency problem of the visual script; the module name, class name, function name, and variable name of the generated code are consistent with those defined by the user in the visual script, keeping the Python script and the visual script with the same readability and maintainability; based on Python script design, it can be applied to many projects that use Python scripts to write game logic; it can be applied not only to games that use Python scripts to write game logic, but any program written in Python scripts can be connected to UchihaVScript.

[0224] Figure 6 A schematic diagram of a visual script execution device is provided. The device can be applied to a client, such as a visual script editor. Figure 6 As shown, the visual script execution device 600 includes:

[0225] A parsing module 601 is configured to obtain and parse the to-be-executed file data corresponding to the current visual script to obtain a program outline representing the data structure, wherein the program outline includes functions and variables of the to-be-executed file data, and each function corresponds to a blueprint;

[0226] The assignment module 602 is used to assign a value to each of the functions and each of the variables according to the to-be-executed file data;

[0227] The execution module 603 is used to instantiate and parse the blueprint corresponding to each function to obtain an executable blueprint, so that the executable blueprint executes the corresponding target operation according to the user operation instruction.

[0228] The visual script execution device provided in the embodiment of the present application has the same technical features as the visual script execution method provided in the above embodiment, so it can also solve the same technical problems and achieve the same technical effects.

[0229] An electronic device provided in an embodiment of the present application is Figure 7 As shown, the electronic device 700 includes a memory 701 and a processor 702. The memory stores a computer program that can be run on the processor. When the processor executes the computer program, the steps of the method provided in the above embodiment are implemented.

[0230] Corresponding to the above method, an embodiment of the present application also provides a computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are called and executed by the processor, the computer-executable instructions prompt the processor to execute the steps of the above method.

[0231] The execution device of the visual script provided in the embodiment of the present application can be specific hardware on the device or software or firmware installed on the device. The implementation principle and technical effects of the device provided in the embodiment of the present application are the same as those in the aforementioned method embodiment. For the sake of brief description, for parts not mentioned in the device embodiment, reference can be made to the corresponding contents in the aforementioned method embodiment. Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can all refer to the corresponding processes in the aforementioned method embodiment, and will not be repeated here.

[0232] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present application, which are used to illustrate the technical solutions of the present application rather than to limit them. The scope of protection of the present application is not limited thereto. Although the present application has been described in detail with reference to the above-mentioned embodiments, ordinary technicians in this field should understand that any technician familiar with this technical field can still modify the technical solutions recorded in the above-mentioned embodiments within the technical scope disclosed in the present application, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for executing a visual script, characterized in that: The method comprises: Obtain and parse the to-be-executed file data corresponding to the current visual script to obtain a program outline for representing the data structure, wherein the program outline includes functions and variables of the to-be-executed file data, and each function corresponds to a blueprint; the visual script is a one-way linked list formed by stringing together multiple different action nodes, wherein the action node derives a parameter tree when parameters are passed in, the parameter tree having the action node as the root, and the child nodes of the parameter tree consisting of parameter nodes; the action node is a node with a connection to a logical output port, and the parameter node is a node without a connection to a logical output port; Assigning a value to each of the functions and each of the variables according to the to-be-executed file data; Performing instantiation and parsing on the blueprint corresponding to each of the functions to obtain an executable blueprint, so that the executable blueprint executes the corresponding target operation according to the user operation instruction; Among them, the step of instantiating and parsing the blueprint corresponding to each of the functions to obtain an executable blueprint includes: step 2.1, calling the data reading function to obtain preliminary sorted node information and node connection information from the to-be-executed file data, wherein the node information includes node ID and Meta type, and the node ID is the uuid of the node in the editor; step 2.2, instantiating the node according to the Meta type and class of each node to obtain the new node ID of the node at runtime; step 2.3, generating runtime node connection according to the node connection information; step 2.4, determining the connection relationship between the nodes according to the logical output port of the node; step 2.5, repeating the above steps 2.1 to 2.4, constructing each node of the program outline at runtime in a depth-first search order to generate an executable blueprint.

2. The method according to claim 1, characterized in that When the node has multiple logical output ports, branches are generated from the trunk of the one-way linked list, and the structure of the branches is completely the same as that of the trunk.

3. The method according to claim 1, characterized in that The program outline is a node tree, and each node corresponds to a variable, function or class.

4. The method according to claim 3, characterized in that Before the step of assigning a value to each of the functions and each of the variables according to the to-be-executed file data, the method further includes: The data of the to-be-executed file is deserialized, and a connection between the runtime node of the program outline and the node is constructed.

5. The method according to claim 4, characterized in that The step of assigning a value to each of the functions and each of the variables according to the to-be-executed file data includes: The functions and variables corresponding to each node in the program outline are assigned values ​​in sequence according to the to-be-executed file data.

6. The method according to claim 1, characterized in that The method further comprises: The corresponding logic in the executable blueprint is executed according to the different return values ​​of each node, wherein the parameter nodes are executed in post-order traversal and the process nodes are executed in pre-order traversal, and the process nodes are a type of the action nodes.

7. The method according to claim 6, characterized in that A node in the program outline corresponds to a main function, and the method further includes: When the to-be-executed file data is executed as a main module, the executable blueprint corresponding to the main function is executed.

8. The method according to any one of claims 1 to 7, characterized in that The method further comprises: The program outline is converted into a preset script language format according to a preset code template.

9. The method according to claim 8, characterized in that The step of converting the program outline into a preset scripting language format according to a preset code template includes: The nodes of the program outline are traversed, and according to the type of each node of the program outline, a template code of a corresponding type is obtained from the preset code template, and a node code is converted from the template code.

10. The method according to claim 9, characterized in that The method further comprises: The module name, class name, function name and variable name of the visual script are defined in the preset script language.

11. A visual script execution device, characterized in that: include: A parsing module is configured to obtain and parse the to-be-executed file data corresponding to the current visual script to obtain a program outline for representing the data structure, wherein the program outline includes functions and variables of the to-be-executed file data, and each function corresponds to a blueprint; the visual script is a one-way linked list formed by stringing together a plurality of different action nodes, wherein the action node derives a parameter tree when parameters are passed in, the parameter tree having the action node as the root, and the child nodes of the parameter tree consisting of parameter nodes; the action node is a node with a connection to a logical output port, and the parameter node is a node with no connection to a logical output port; An assignment module, configured to assign a value to each of the functions and each of the variables according to the to-be-executed file data; An execution module, configured to instantiate and parse the blueprint corresponding to each of the functions to obtain an executable blueprint, so that the executable blueprint executes the corresponding target operation according to the user operation instruction; Among them, the execution module is specifically used to: step 2.1, call the data reading function, obtain the preliminary sorted node information and node connection information from the to-be-executed file data, wherein the node information includes node ID and Meta type, and the node ID is the uuid of the node in the editor; step 2.2, instantiate the node according to the Meta type and class of each node, and obtain the new node ID of the node at runtime; step 2.3, generate the runtime node connection according to the node connection information; step 2.4, determine the connection relationship between the nodes according to the logical output port of the node; step 2.5, repeat the above steps 2.1 to 2.4, and construct each node of the program outline at runtime in the order of depth-first search to generate an executable blueprint.

12. An electronic device comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 10 are implemented.

13. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions prompt the processor to execute the method according to any one of claims 1 to 10.

Images