CN114588638A

CN114588638A - Method for developing game based on Lua language and program development device

Info

Publication number: CN114588638A
Application number: CN202210091862.4A
Authority: CN
Inventors: 王远明; 徐刚; 罗世鑫
Original assignee: Chengdu Fantasy Mermaid Technology Co ltd
Current assignee: Chengdu Fantasy Mermaid Technology Co ltd
Priority date: 2022-01-26
Filing date: 2022-01-26
Publication date: 2022-06-07

Abstract

The application provides a method for game development based on Lua language, which comprises the following steps: exporting a pre-specified object code through a game engine interface, packaging the object code in the game engine, generating an injection item according to an engine function and/or an engine attribute contained in the object code, and injecting the injection item into a virtual machine; and searching the injection item corresponding to the calling instruction based on the written calling instruction, and calling the engine function corresponding to the injection item according to the injection item. The application also provides a program development device. The problem that the game integral installation package needs to be downloaded again when the game logic is changed can be avoided, and the game maintenance efficiency is improved.

Description

Method for developing game based on Lua language and program development device

Technical Field

The present application relates to the field of game development, and in particular, to a method for game development based on the Lua language, a program development device, a computer device, and a computer-readable storage medium.

Background

The illusion Engine, whose english name is unknown Engine, is manufactured by EpicGames, is one of the mainstream game engines in the market. Based on its powerful performance and its excellent visual effect, more and more game projects, both of which are PC-side and mobile-side, are developed using illusion engines. The native development language of the illusion engine is the C + + language, and although the native development language has better operation efficiency compared with the interpreted scripting language, hot update cannot be performed after the project is externally released due to the characteristics of the C + + language. With the richness of the visual effect and content of the game, the game installation package often moves to several GB or even tens of GB. If only a few game logics are modified, the user side needs to download the game installation package again, and the game maintenance efficiency is extremely low.

Disclosure of Invention

An object of the embodiments of the present application is to provide a method, an apparatus, a device and a computer-readable storage medium for game development based on the Lua language, which are used to solve the above-mentioned drawbacks.

One aspect of an embodiment of the present application provides a method for game development based on the Lua language, the method including:

exporting pre-designated object codes through a game engine interface, wherein the object codes are packaged in the game engine;

generating an injection item according to an engine function and/or an engine attribute contained in the object code, and injecting the injection item into a virtual machine;

based on the written call instruction, searching the injection item corresponding to the call instruction, and calling the engine function corresponding to the injection item according to the injection item.

Optionally, the object code is specified by a pre-created configuration file specifying engine functions and/or engine attributes that need to be exported.

Optionally, the configuration file further specifies an engine class, the engine function or the engine attribute to be exported is packaged in the engine class, and the step of exporting the pre-specified object code through the game engine interface includes:

calling the game engine interface based on the name of the engine class specified by the configuration file to obtain a reflection class of the engine class;

and acquiring code information corresponding to the engine function and/or code information corresponding to the engine attribute which need to be derived through the code information recorded in the reflection class.

Optionally, the step of calling the game engine interface to obtain the reflection class of the engine class based on the name of the engine class specified by the configuration file includes:

calling the game engine interface, and acquiring a pointer of a reflection class corresponding to the engine class returned from the game engine interface through the name of the engine class;

and obtaining the reflection type and the code information of the reflection type through the pointer of the reflection type.

Optionally, the step of obtaining, through the code information recorded in the reflection class, code information corresponding to the engine function and/or code information corresponding to the engine attribute that need to be derived includes:

traversing each function in the reflection class, and if an engine function specified by the configuration file exists, deriving a function code of the engine function;

traversing each attribute in the reflection class, and if the engine attribute specified by the configuration file exists, exporting an attribute code of the engine attribute.

Optionally, the step of generating an injection item according to an engine function and/or an engine attribute included in the object code, and injecting the injection item into the virtual machine includes:

redefining the engine function and/or the engine attribute to generate the injection item;

and calling a native interface, and injecting the injection item into the virtual machine.

packaging the injection items to form a packaged file, and adding a registration interface in the packaging process, wherein the registration interface is used for registering the injection items in the virtual machine;

and calling the registration interface, and injecting the injection item corresponding to the registration interface into the virtual machine.

Optionally, a package class of the engine function is defined in the injection item, and a relationship interface is further added to the package file in the package process, where the relationship interface is used to set a meta table of the package class to restore parent-child relationships between engine classes in the game engine.

Optionally, after the step of encapsulating the injection item to form an encapsulated file, the method further includes:

and generating a master control interface, wherein the master control interface is used for calling the registration interface and the relation interface of the packaging file.

Optionally, the step of encapsulating the injection item to form an encapsulated file further includes: in the packaging process, the first object defined by the first type is created, and the injection item is embedded into the first object, wherein the first type is a preset type of the Lua language.

Optionally, the step of searching for the injection item corresponding to the call instruction based on the written call instruction, and calling the engine function corresponding to the injection item according to the injection item includes:

acquiring a function name called in the calling instruction, and searching the injection item corresponding to the function name;

and directly calling the engine function according to the pointer of the engine function stored in the injection item.

and calling the engine function according to the pointer of the engine function stored in the injection item, pressing a transmission reference into a stack, and acquiring a calling return value from the top of the stack.

Optionally, the call instruction further specifies a name of the first object, and the engine function specified by the call instruction is looked up from a meta table of the first object.

Optionally, after the step of searching for the injection item corresponding to the call instruction based on the written call instruction and calling the engine function corresponding to the injection item according to the injection item, the method further includes:

and if the calling exception occurs, capturing the exception and calling an exception handling interface, and delivering the exception to the virtual machine for handling, wherein the exception handling interface is one of the native interfaces.

Optionally, the deriving a pre-specified object code through a game engine interface, the object code being encapsulated before the step in the game engine, further includes:

embedding the virtual machine and Lua library in the game engine to enable the game engine to call Lua functions.

and calling a resource loading interface of the game engine and transmitting a callback function.

if the injection item corresponding to the calling instruction does not exist, calling the game engine interface to acquire an engine object;

and calling an interface corresponding to the calling instruction in the engine object to acquire a return value.

Yet another aspect of the embodiments of the present application provides a program development apparatus, including:

the export module is used for exporting a pre-designated object code through a game engine interface, and the object code is packaged in the game engine;

the injection module is used for generating injection items according to the engine functions and/or the engine attributes contained in the object codes and injecting the injection items into the virtual machine;

and the calling module is used for searching the injection item corresponding to the calling instruction based on the written calling instruction and calling the engine function corresponding to the injection item according to the injection item.

A further aspect of embodiments of the present application provides a computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor when executing the computer program being configured to implement the steps of the method as described above.

Yet another aspect of embodiments of the present application provides a computer-readable storage medium having stored thereon a computer program, which is executable by at least one processor to cause the at least one processor to perform the steps of the method as described above.

The method for game development based on the Lua language, the program development device, the computer device and the computer readable storage medium provided by the embodiment of the application can have the following advantages: the method provides a prerequisite for realizing interaction behaviors such as functions of the unreal engine called by Lua, so that developers can use Lua language to modify the logic of the unreal engine at the Lua end, thereby realizing game development based on the Lua language, solving the problem that the original modified logic needs to download a complete game installation package again, and greatly improving the game maintenance efficiency.

Drawings

Fig. 1 is a flowchart schematically illustrating a method for game development based on the Lua language according to a first embodiment of the present application;

FIG. 2 is a flow chart schematically illustrating steps of exporting pre-specified object code through a game engine interface according to a first embodiment of the present application;

FIG. 3 is a flow chart that schematically illustrates a step of invoking the game engine interface to obtain a reflection class for the engine class based on the name of the engine class specified by the configuration file, in accordance with an embodiment of the present application;

fig. 4 is a flowchart schematically illustrating a step of acquiring, according to the code information recorded in the reflection class, code information corresponding to the engine function and/or code information corresponding to the engine attribute that needs to be derived;

FIG. 5 is a flowchart schematically illustrating steps of generating injection items according to engine functions and/or engine attributes included in the object code, and injecting the injection items into a virtual machine according to an embodiment of the present application;

FIG. 6 is a flow diagram schematically illustrating another embodiment of the steps of generating injection items according to engine functions and/or engine attributes included in the object code, and injecting the injection items into a virtual machine according to the embodiment of the present application;

fig. 7 is a flowchart schematically illustrating a step of searching the injection item corresponding to the call instruction based on the written call instruction, and calling the engine function corresponding to the injection item according to the written call instruction according to an embodiment of the present application;

fig. 8 is a flowchart schematically illustrating another implementation of the step of searching the injection item corresponding to the call instruction based on the written call instruction, and calling the engine function corresponding to the injection item according to the step of writing the injection item according to the embodiment of the present application;

FIG. 9 is a flow chart schematically illustrating another embodiment of a Lua-based game development method according to the first embodiment of the present application;

fig. 10 is a partial schematic flow chart showing a game development by the Lua language according to the program development device in the second embodiment of the present application;

FIG. 11 is a partial flowchart schematically illustrating the process of the program development apparatus for deriving the engine function according to the second embodiment of the present application;

FIG. 12 schematically illustrates an interaction diagram of the interaction of the Lua with the illusion engine;

fig. 13 is a block diagram schematically showing a program development apparatus according to a third embodiment of the present application; and

fig. 14 schematically shows a hardware architecture diagram of a computer device suitable for implementing game development based on the Lua language according to the fourth embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the application and are not intended to limit the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

It should be noted that the descriptions relating to "first", "second", etc. in the embodiments of the present application are only for descriptive purposes and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature limited to "first" or "second" may explicitly or implicitly include at least one of the feature. In addition, technical solutions between the embodiments may be combined with each other, but must be based on the realization of the technical solutions by a person skilled in the art, and when the technical solutions are contradictory or cannot be realized, the technical solutions should not be considered to exist in combination, and are not within the protection scope claimed in the present application.

In the description of the present application, it should be understood that the numerical references before the steps do not identify the order of performing the steps, but merely serve to facilitate the description of the present application and to distinguish each step, and therefore should not be construed as limiting the present application.

The applicant has appreciated that, for example, a game engine written in C + + language such as a ghost engine cannot be updated thermally after a game item is released, and many dozens of GB game installation packages need to be downloaded again to change some game logic, so that the game maintenance efficiency is very low, and the download resources are wasted for the user side.

Aiming at the problems, the following scheme is implemented, so that developers can modify the logic of the illusion engine through the Lua language, game development based on the Lua language is realized, the problem that the original game installation package needs to be downloaded again when part of the logic is modified is solved, the game maintenance efficiency is greatly improved, and the engine function can be called more quickly.

The following is an explanation of the nouns of the present application:

the game engine refers to a core component of some programmed editable computer game systems or some interactive real-time image application programs. These systems or components provide game designers with the various tools needed to write games with the goal of allowing game designers to easily and quickly program games without starting from scratch. Most support various operating platforms, such as Linux, Mac OS X, microsoft Windows. The game engine comprises the following systems: rendering engine, physics engine, collision detection system, sound effects, script engine, computer animation, artificial intelligence, network engine, and scene management.

The Unreal Engine, called UE Engine for short, is a Game development Engine proposed by Epic Game company, and compared with other engines, the Unreal Engine is efficient and comprehensive, can also directly preview development effects, and endows Game project developers with stronger capability.

Lua, a scripting language, was developed in 1993 by a research group consisting of Roberto Ierussalsky, Waldmar cells and Luiz Henrique de Figueiredo, at the University of Olympic University of Hot Neugu, Ba Xie. The purpose of this design is to provide flexible extension and customization functionality for applications by flexible embedding in the application. Lua is written by standard C and can be compiled and run on almost all operating systems and platforms. The Lua script can be called by C/C + + codes and can also call C/C + + functions in reverse.

A Chunk, a code that can be interpreted and executed by the Lua interpreter is called Chunk, and the Chunk can be very small, and is as small as only one statement or two statements; and can be large enough to contain thousands of statements and complex function definitions. In order to obtain higher execution efficiency, Lua does not directly interpret the execution chunk, but the existing interpreter compiles an internal structure (containing information such as byte codes) and then executes the byte codes by the virtual machine. This internal structure is called a Precompiled (Precompiled) chunk in Lua, and is also called a Binary (Binary) chunk because of the Binary format.

And the Lua interpreter is used for compiling the written script codes into byte codes and delivering the byte codes to the virtual machine for execution. Before executing a Lua script, the Lua interpreter compiles the Lua script into a Lua virtual machine instruction sequence in a main function, and then packages the Lua script into a binary chunk together with other information.

The virtual machine is used for referring to a Lua virtual machine, and the core task of the virtual machine is to execute an instruction, take over a binary chunk and execute the instruction in the binary chunk.

Classes, which are concepts in the programming of object-oriented languages, are the basis for object-oriented programming. Instances of classes are referred to as objects. To create an object in a program, a class needs to be defined first. A class is an abstraction of an object that is used to describe the common characteristics and behavior of a set of objects.

A function, a piece of program or code to implement a logic or a function. Which may be included in a class.

Properties, classes, can define member variables and member methods, where member variables are used to describe characteristics of an object, also referred to as properties.

The interface is not an interface (interface) concept in JAVA, and is used to represent functions that can be called externally, and is the same as the common words of developers in C # language.

The native interface, which is used in this application to refer to an API preset by the Lua language itself, includes many callable functions such as a Lua functions set, a C API functions set, and an auxiary library functions set, where stack operation and function injection operation into the virtual machine may be performed through the Lua functions in the C API functions set.

Example one

The application provides a method for game development based on a Lua language, and referring to FIG. 1, FIG. 1 schematically illustrates a method for game development based on a Lua language according to a first embodiment of the application, where the method includes:

step S100, exporting a pre-designated object code through a game engine interface, wherein the object code is packaged in the game engine.

As an example, a game engine may open a partial interface, and the opened partial interface may be used to be called externally to obtain some function codes encapsulated in the game engine to realize partial logic or functions or to call the functions. Taking the illusion engine as an example, a reflection mechanism is arranged in the illusion engine, code fields of engine functions or engine attributes and the like which are wanted or specified by developers can be obtained through an interface provided by the illusion engine related to the reflection mechanism, the developers can know names, addresses, return values, parameters corresponding to the functions and the like of the engine functions and the engine attributes through the obtained code fields of the engine functions and the engine attributes, and then the engine functions are called or the engine attributes are accessed, and a series of game programming operations and development design are completed.

In a specific embodiment of the present application, as mentioned above, the object code may be a code field corresponding to an engine function or an engine attribute encapsulated in the engine, and may also be any code field that can be derived, such as an engine class and an engine object in the engine. The specified export target can be preset by a developer, the developer can write a configuration file, import Lua execution, and export the target code specified by the configuration file by a Lua program. Of course, the developer can also export the desired engine functions or attributes from the ghost engine step by writing the calling code and the export code at the beginning of development.

Step S200, generating injection items according to the engine functions and/or the engine attributes contained in the object codes, and injecting the injection items into the virtual machine.

As an example, based on the reflection mechanism of the phantom engine, in the process of exporting the object code, a reflection class of an engine class may be led out, and in this reflection class, it is searched whether there is an engine function and/or an engine attribute that is desired to be exported, and if there is, the engine function and/or the engine attribute that is desired to be exported may be exported.

As an example, after the engine function and/or the engine attribute are obtained, since the code format of the illusion engine is not the same as the code format of the Lua program, the obtained engine function and/or the engine attribute need to be redefined to generate the injection item so as to meet the format requirement identified by the Lua program, and then the redefined engine function and/or the engine attribute are injected into the Lua virtual machine through the C API function set in the Lua native interface, thereby completing the injection operation. After the injection item is injected into the Lua virtual machine, the developer can call the engine function of the illusion engine corresponding to the injection item.

By way of example, the derived engine function may be a methodology of the engine function or may be a pointer to the engine function. Based on the lightweight property of the Lua language, it is preferable to derive only the pointer code of the engine function, and not to select the code for deriving the engine function (of course, parameters, the number of parameters, return values, and the like of the function need to be derived). Correspondingly, when only the pointer of the engine function is derived for the engine function, the injection item also only includes the pointer of the redefined engine function and code information such as other function parameters, the number of parameters, and the return value.

Step S300, based on the compiled calling instruction, searching the injection item corresponding to the calling instruction, and calling the engine function corresponding to the injection item according to the injection item.

As an example, after the item to be injected is injected into the Lua virtual machine, a developer may compile a call instruction in an editor or any code editor, and when the Lua virtual machine executes the call instruction, the developer may first search whether there is a corresponding injection item in the call instruction, and if there is the injection item, may call or access an engine function of the ghost engine through a pointer of the engine function and an engine attribute stored in the injection item, and if the engine function requires a parameter, press a corresponding transfer parameter (i.e., a parameter) into a stack (Lua stack), the stack delivers the corresponding parameter to the ghost engine, and then the Lua end takes out a call return value from the stack top or the stack, thereby implementing a call (also referred to as an interactive) operation of the ghost engine by the Lua end.

The method for developing the game based on the Lua language, provided by the embodiment of the application, provides a prerequisite for realizing that the Lua calls the function of the ghost engine side, so that a developer can use the Lua language to modify the logic of the ghost engine at the Lua end, thereby realizing the game development based on the Lua language, solving the problem that the complete game installation package needs to be downloaded again when part of the logic is changed originally, greatly improving the game maintenance efficiency, and based on the characteristics of the Lua language, the game development becomes more efficient.

The method provided by the present application is not limited to the method between Lua and the ghost engine, and may also be applied between Lua and other game engines written in C # language or supporting C # language, such as Unity 3D.

As an alternative embodiment:

the object code is specified by a pre-created configuration file specifying the engine functions and/or engine attributes that need to be exported.

Specifically, the object code may be specified by a configuration file written or created in advance by a developer, the specified object code may be a code field corresponding to an engine function or an engine attribute encapsulated in the engine, or may also be any code field that can be exported, such as an engine class and an engine object in the engine, and by importing the configuration file as the object specification of the object code export operation, the method is more convenient and faster than writing a call instruction one by one.

As an example, the object code may be a combination of multiple engine functions and engine attributes, etc., for example, a configuration file, which specifies to call out three engine functions and one engine attribute, or specifies to export one engine function and five engine attributes, and the combination of the engine functions and the engine attributes specified by the object code is not limited.

By way of example, there may be more than one configuration file or only one configuration file. An input window and window logic codes can be set together with the configuration file, a developer only needs to input index values such as function names, attribute names and class names of the target codes in the input window, and the window logic codes automatically convert the information input in the input window into the configuration file and input the configuration file into the editor.

An example of a configuration file in XML format is as follows:

<Item>

<Class>XXXClassName</Class>

<Property>PropertyName</Property>

<Method>MethodName</Method>

<ExMethod>ExMethodName</ExMethod>

wherein, the explanation of each field is as follows:

class: the class of engines that need to be derived can be in the form of the "/Script/modulename.

Property: and (4) the engine attribute needing to be exported, and if the engine attribute is an x number, all exports are exported. The symbol "|" may also be used to exclude attributes that are not to be derived

A Method: and engine functions needing to be derived, and if the engine functions are of the number, all the derivatives are derived (UFintersection functions containing the meta tag of default are not included). The symbol "|" may also be used to exclude methods that are not intended to be derived

ExMethod: a derived custom function is required.

As an alternative embodiment:

the configuration file further specifies an engine class, the engine function or the engine attribute to be exported is packaged in the engine class, please refer to fig. 2, and the step of exporting the pre-specified object code through the game engine interface in step S100 includes:

step S110, based on the name of the engine class specified by the configuration file, calling the game engine interface to obtain the reflection class of the engine class.

In a particular embodiment of the present application, the configuration file may also specify an engine class. Based on the encapsulation property of the class, in the internal encapsulation of the illusion engine, the engine attribute, the engine function, and the like are encapsulated in the engine class, for example, the class is named as "flame skill", and usually the engine function and the engine attribute related to "flame skill" in the actual scene are encapsulated in this class, and for example, the engine function encapsulated in this class may be flame skill 1(), flame skill 2(), flame skill 3(), flame advance skill 1(), flame advance skill 2(), flame advance skill 3(), and the like, and the attribute may be combustion, dizzy, and the like. The above examples are merely for ease of understanding.

In the reflection mechanism of the ghost engine, one reflection class, namely a UCLASS class, is set for each engine class. This reflection class is used to record various information of the engine class, such as how many functions there are, the name of each function, how many parameters there are, and so on. For example, the engine class with the class name "flame skill" may have the name, method, pointer, and parameter of the member function of each engine class, i.e., specific information of each function, such as flame skill 1(), flame skill 2(), flame skill 3(), flame advance skill 1(), flame advance skill 2(), flame advance skill 3(), and the like, recorded in the reflection class uclas. Of course, the reflection class also has an engine attribute of the engine class recorded therein. In the reflection class, engine functions are declared with the macro field of UFunction and engine properties are declared with the macro field of uproughness.

After the configuration file is provided or the configuration file is written by a developer, the Lua program reads the class name of the engine class specified by the configuration file after obtaining the export instruction input by the developer, calls the corresponding interface of the illusion engine end, and takes the class name as an index to further obtain the reflection class of the engine class and all code information of the reflection class.

And step S120, obtaining code information corresponding to the engine function and/or code information corresponding to the engine attribute that need to be derived, through the code information recorded in the reflection class.

As an example, after obtaining the reflection class of the engine class and all the code information of the reflection class, traverse all the code fields of the reflection class, and derive the corresponding fields from the code information of the reflection class according to the specified engine function and engine attribute of the configured file.

As an example, in the code information of the reflection classes, the engine function has a macro field of UFunction, and the engine attribute has a macro field of uproughness, so that in the process of traversing the code information of the reflection classes, the UFunction function in each reflection class is traversed, the UFunction function with the same name as the configuration file-specified engine function is the specified engine function, and all the code information of the UFunction function is derived and stored. The same applies to the export of the engine attributes specified by the configuration file.

Illustratively, an engine class name specified by the configuration file is called "flame skill", a specified engine function name is called flame skill 1 and flame advance skill 2, after a reflection class uclas corresponding to the engine class of the "flame skill" is obtained, each UFunction function is traversed in the uclas, UFunction functions with the same name as "flame skill 1" and "flame advance skill 2" are found, and code information of the two functions is derived.

In other embodiments of the present application, all codes of the reflection class may be received, the specified function and attribute fields may be retained, and the remaining fields that are not specified may be deleted.

By way of example, the engine functions and/or the engine attributes required by the developer can be quickly exported through the reflection class in combination with the pointing of the configuration file to the engine functions and/or the engine attributes, and the export efficiency is greatly improved.

As an alternative embodiment:

step S110, the step of calling the game engine interface to obtain the reflection class of the engine class based on the name of the engine class specified by the configuration file includes the following steps:

step S111, calling the game engine interface, and acquiring a pointer of a reflection class corresponding to the engine class returned from the game engine interface through the name of the engine class;

step S112, obtaining the reflection class and the code information of the reflection class through the pointer of the reflection class.

By way of example, referring to fig. 3, taking the ghost engine as an example, uclas is a derivative class of Uobject in the ghost engine. And calling a fantasy engine interface FindObject < UClass > based on the class name of the engine class specified by the configuration file, taking the class name of the engine class as a parameter, pushing the parameter into a stack, transmitting the parameter to the fantasy engine, and then obtaining a returned pointer of the reflection class.

And calling the fantasy engine interface FindObject based on the pointer of the reflection class so as to obtain the reflection class and the code information of the reflection class. The engine function and the engine attribute which need to be derived are extracted by utilizing the code information of the reflection class, and the code acquisition efficiency is greatly improved.

As an alternative embodiment:

step S120, obtaining, through the code information recorded in the reflection class, code information corresponding to the engine function and/or code information corresponding to the engine attribute that need to be derived, further including the following steps:

step 121, traversing each function in the reflection class, and if an engine function specified by the configuration file exists, deriving a function code of the engine function;

step 122, traversing each attribute in the reflection class, and if the engine attribute specified by the configuration file exists, deriving an attribute code of the engine attribute.

Referring to fig. 4, in an embodiment of the present application, uclas is used as a reflection class of an engine class, and each engine function and engine attribute in the corresponding engine class are described in the uclas. In the UClass, the described engine function is decorated or declared by a UFunction macro, and the described engine property is decorated or declared by an uploperty.

Specifically, the code information of the reflection class is traversed, and the engine function and the engine attribute recorded in the reflection class are found through the UFunction and the uproughness. And if the engine function name is the same as the function name specified in the configuration file, the code of the engine function is exported. Similarly, for exporting the engine attribute, the code of the engine attribute is exported by comparing whether the name of the engine attribute is the same as the name of the attribute specified in the configuration file, and if so, the engine function and/or the engine attribute specified by the configuration file are automatically exported.

As an alternative embodiment:

step S200, the step of generating an injection item according to the engine function and/or the engine attribute included in the object code, and injecting the injection item into the virtual machine further includes the following steps:

step S210, redefining the engine function and/or the engine attribute to generate the injection item;

step S220, calling a native interface, and injecting the injection item into the virtual machine.

As an example, referring to fig. 5, in view of the format difference between the Lua language and the illusion engine, the derived engine function and/or engine attribute code cannot be directly identified by the Lua program, and the derived engine function and/or engine attribute needs to be redefined according to the Lua requirement to be injected into the virtual machine.

Specifically, a redefined field may be added to the code of the derived engine function and/or engine attribute, for example, defined by typedef int (Lua _ CFunction) (Lua _ State × L), so as to generate an injection item that can be injected into the Lua virtual machine.

As an example, an injection may include one or more engine function codes, and one or more engine properties. After redefining the engine function and the engine attribute, packaging the codes to generate a set type and get type packaging function which can be used for injecting into the virtual machine, wherein the set method and the get method added in the specific packaging process can be set according to an actual application scene; after the packing, the set of codes containing the set class and get class functions of redefining the engine functions and/or the engine attributes is the injection item.

And after the injection item is generated, the injection item is injected into the virtual machine by calling the Lua native interface. The Lua language is preset with a plurality of native interfaces, namely preset APIs, and the injection items are injected into the virtual machine through the native interfaces C API, which is substantially equivalent to registering the injection items in the virtual machine.

By redefining the derived engine function and the derived engine attribute and then generating an injection item which can be injected into the virtual machine, when a developer calls the engine function, a calling instruction can be directly compiled, the virtual machine finds the injection item corresponding to the instruction according to the calling instruction and calls the engine function according to an engine function pointer contained in the injection item, and the method realizes the quick calling of the engine function by the Lua.

As an alternative embodiment:

step S230, redefining the engine function and/or the engine attribute to generate the injection item;

step S240, packaging the injection item to form a packaged file, and adding a registration interface in the packaging process, wherein the registration interface is used for registering the injection item to the virtual machine;

step S250, invoking the registration interface, and injecting the injection item corresponding to the registration interface into the virtual machine.

By way of example, referring to fig. 6, registration code for calling the Lua C API to inject the injection item into the virtual machine may be further added to the injection item, a registration function in the registration code is defined as an interface that can be called, and finally the injection item and the registration code are packaged together to form a CPP file. CPP is C + + (C Plus), and CPP files can be identified by C/C + + language.

The developer can directly call the registration interface to complete the operation of injecting the injection items associated with the registration interface into the virtual machine.

In a specific embodiment of the present application, for the encapsulation of the CPP file, it is preferable to perform the encapsulation in units of each engine class. The method comprises the following steps that a CPP file is formed by packaging a wrapper function corresponding to an engine function in an engine class A, a wrapper function corresponding to an attribute in the engine class A and a registration code, wherein the CPP file can be named according to the class name of the engine class A; and packaging the wrapper function corresponding to the engine function in the engine class B, the wrapper function corresponding to the attribute in the engine class B and the registration code into a CPP file, wherein the CPP file can be named by the class name of the engine class B, and the like.

The registration interface is formed by adding the registration codes to the injection items, and the registration interface is packaged into the called CPP file, so that a developer can directly call the registration interface to complete the operation of injecting the injection items associated with the registration interface into the virtual machine, and the operation is simple and the management is convenient.

As an alternative embodiment:

the injection item defines a package class of the engine function, and in the packaging process of the package file in step S240, a relationship interface is further added, where the relationship interface is used to set a meta table of the package class, so as to restore parent-child relationships between engine classes in the game engine.

In the illusion engine, some engine classes may have parent-child relationships with other engine classes, and thus between derived engine classes, there may be a subclass in which one or some engine classes are another or some other engine classes. The illusion engine is written and established by C + +, and the subclasses can call the functions of the parent classes, so that when the classes are exported to Lua, the parent-child relationship among the engine classes also needs to be restored. Therefore, the method and the device correspondingly restore the parent-child relationship between the classes in the illusion engine through the setting of the Lua meta-table, and further enable the derived engine class to call the function in the meta-table corresponding to the parent class.

As an example, the injection item may further include an engine class to which an engine function and/or an engine attribute belongs, in the Lua, an original table of the Lua is set for each engine class, and a relationship interface is added to set the original table of the Lua corresponding to the engine class, and associate the original tables of the engine classes originally belonging to the parent-child relationship, so that the engine classes of the subclasses can call the meta-table function corresponding to the engine classes of the parent class, and further complete restoration of the parent-child relationship between the classes in the illusion engine.

The parent-child relationship between the classes in the original ghost engine can be obtained from the code information of the reflection class.

As an alternative embodiment:

in step S240, after the step of encapsulating the injection item to form an encapsulated file, the method further includes:

As an example, as described above, after all the CPP files are encapsulated, a single CPP file may be separately generated for storing the grandmaster interface. The master control interface is used for calling the registration interfaces and the relationship interfaces in all the packaging files. The master control interface can call other registration interfaces and relationship interfaces in an inheritance mode. Through the setting of total accuse interface, further promote the convenience of calling the engine function to through total accuse interface, can make things convenient for the developer to select which engine function and/or engine attribute of concrete injection.

As an alternative embodiment:

in step S240, the step of encapsulating the injection item to form an encapsulated file further includes: in the packaging process, the first object defined by the first type is created, and the injection item is embedded into the first object, wherein the first type is a preset type of the Lua language.

The first type is the userdata type of the Lua language. The userdata is the same as table, function, thread, belonging to the object type, managed and reclaimed by the Lua. Therefore, the object defined by userdata is created to accommodate the injection item, and management and recovery can be carried out by the Lua self mechanism, so that the overall compiling efficiency is improved.

For example, a class a defined by userdata may be created to accommodate engine functions and/or engine attributes in the engine class "flame skill", that is, an injection item generated by the class of "flame skill" is embedded in this class a, and the creation of the class a may be created when the target code is derived, or after the engine functions and/or engine attributes are redefined, which is not limited herein.

Because the object defined by the userdata can own an independent meta table, the setting of the relationship interface is more convenient, and the logic of the relationship interface only needs to associate the engine class with the parent-child relationship with the corresponding meta table of the userdata object.

As an alternative embodiment:

step S300, the step of searching the injection item corresponding to the calling instruction based on the written calling instruction and calling the corresponding engine function according to the injection item comprises the following steps:

step S310, acquiring a function name called in the calling instruction, and searching the injection item corresponding to the function name;

step S320, directly calling the engine function according to the pointer of the engine function stored in the injection item.

In an embodiment of the present application, referring to fig. 7, based on the Lua portability feature, it is preferable not to derive the method body code of the engine function, but instead derive the address of the engine function (of course, necessary information such as parameters and return values also need to be derived). That is, the injection item does not include the method body of the engine function, but includes the address of the engine function. After a developer writes a call instruction, the name of a function called in the instruction is obtained, a corresponding injection item is searched, and the engine function is called according to a pointer of the engine function stored in the injection item. If the engine function does not require a parameter, it is called directly.

As an alternative embodiment:

step S300, the step of searching the injection item corresponding to the calling instruction based on the written calling instruction, and calling the engine function corresponding to the injection item according to the injection item comprises the following steps:

step S330, acquiring the function name called in the calling instruction, and searching the injection item corresponding to the function name;

step S340, according to the pointer of the engine function stored in the injection item, calling the engine function and pushing the transfer reference into the stack, and obtaining a call return value from the stack top.

Referring to fig. 8 and 12, fig. 12 is a flow chart illustrating function calls between the Lua program and the ghost engine. The present embodiment refers to the flow block of the Lua static call engine function. Specifically, when the Lua program initiates the calling of the engine function, the address of the called engine function is found through the injection item injected into the virtual machine, and a request is initiated for the ghost engine; if the called engine function needs parameters, the Lua program presses the parameters needed by the engine function into the Lua stack, the unreal engine obtains the parameters through the Lua stack, then runs the function pointed by the calling request, and presses the function return value into the stack top; the Lua program gets the function return value from the top of the stack.

As an alternative embodiment:

the calling instruction is specified with the name of the first object, and the engine function specified by the calling instruction is searched in a meta table of the first object.

As an example, the injection terms may also be housed or embedded in an object defined in the userdata type. At this time, the engine function can be called by directly specifying the userdata object name where the function is located and the function position in the meta table of the object. The interaction with the Lua stack and the illusion engine after being called can refer to the flow block of the Lua static call engine function in FIG. 12. The userdata is used for definition, and the userdata and the element table thereof are used as media, so that the engine function is called more efficiently and conveniently.

As an alternative embodiment:

step S300, after the step of searching for the injection item corresponding to the call instruction based on the written call instruction and calling the engine function corresponding to the injection item according to the injection item, further includes:

In a specific embodiment of the present application, when a Lua program calls an engine function abnormally, the function body of the engine function is directly protected in a try { } catch { } manner, and after capturing the abnormality, a Lua _ error function is called to throw out the abnormality, and the abnormality is processed by a Lua virtual machine. The Lua _ error function, namely an exception handling interface, is also one of the native interfaces preset by Lua.

As an alternative embodiment:

step S100, the deriving a pre-specified object code through a game engine interface, where the object code is packaged in the game engine before the step, further includes:

For example, in some scenarios, for example, the engine triggers some callback functions, the Lua needs to be notified to perform corresponding processing, and at this time, the Lua function needs to be called. For example, some configuration data related to the engine is stored in the Lua, and the engine needs to call the Lua function to obtain the configuration data. In order to realize the call between the Lua program and the game engine, the embodiment may embed the virtual machine and the Lua library in the game engine in advance, so that the game engine can call the Lua function.

The virtual machine may be embedded by writing code for creating a new virtual machine in the code of the game engine, or even in the main program, such as lua _ state L _ luaL _ news. The embedding method may be automatically transferring the above fields into the game engine by the logic code implementing the present application, or may be written in advance by a developer in the main program of the game engine, which is not limited herein.

Continuing to refer to fig. 12, as shown in the flow block of the Lua function called by the engine in the figure, the illusion engine calls the Lua C API, presses the called function object and the parameter into the stack, calls the Lua function in the Lua _ pcall and other APIs, the Lua program runs the called function, sequentially presses the function return values into the stack top, and the illusion engine sequentially obtains the function return values from the stack top.

Illustratively, in the process of calling the Lua function by the game engine, the interaction process is as follows:

step one, an engine accesses a Lua stack, calls a C API (application program interface) of the Lua, and presses calling object information 'LuaFunc' into the stack;

step two, the engine operation stack recalls the result

Lua_pcall(L,0,4,0)；

The code is characterized in that the engine tells a Lua virtual machine (L), the function is input into the stack, the function transmits 0 parameters and returns 4 functions, error information (0) is not needed, the parenthesis content respectively corresponds to four parameters in Lua _ call (), and an element 'LuaFunc' is arranged in the stack at the moment;

and step three, after the engine requests, the virtual machine starts to access the stack, and the LuaFunc is taken out from the stack. At this time, there is no element in the stack: null.

And step four, the virtual machine sends the obtained 'LuaFunc' information to the Lua program.

And step five, calling the Lua file Global table (Global table) by the Lua program to search the LuaFunc, and operating to return a result of 1,2,3 and 4. At this time, there is no element in the stack: null.

Step six, the return result 1,2,3,4 is pushed into the stack by the Lua program; the push sequence is "1" is pushed first, "2" is pushed, and so on, at this time, four elements in the stack: 1,2,3 and 4, and the sequence is the stack bottom-the stack top.

And seventhly, the engine reads data in the stack.

In addition, aiming at exception handling when the game engine calls the Lua, a corresponding logic code is preset and used for calling a function in a Lua _ pcall mode, judging whether the return value of the function is 0 or not, if not, indicating that the execution function is abnormal, popping the current stack top information of the Lua stack, calling an interface corresponding to the output exception of the engine, outputting the exception information and releasing the data in the current Lua stack, further enabling the game engine to detect the call exception in time and handle the exception, and improving the robustness of the whole operation.

As an alternative embodiment:

step S300, after the step of searching for the injection item corresponding to the call instruction based on the written call instruction and calling the engine function corresponding to the injection item according to the injection item, the method further includes:

In a specific embodiment of the present application, when part of the engine functions relate to resource modules such as scenes and memory allocation, after the engine functions are called, the resource loading interface of the game engine is called, and a callback function is introduced to receive a notification returned by the resource loading interface.

As an alternative embodiment:

step S300, based on the written call instruction, searching the injection item corresponding to the call instruction, and after the step of calling the engine function corresponding to the injection item, further comprising:

step S400, if the injection item corresponding to the calling instruction does not exist, calling the game engine interface to acquire an engine object;

step S500, calling an interface corresponding to the calling instruction in the engine object, and acquiring a return value.

Referring to fig. 9, an embodiment of the present application further discloses a dynamic call scheme, so as to compensate for a method for performing engine function or engine attribute access when there is no injection item corresponding to a call instruction when a static call (generating an injection item and injecting the injection item into a virtual machine) is performed.

In particular, with continued reference to FIG. 12, the flow of the Lua dynamic call engine function is illustrated in the flow diagram. In the process of executing the call to the engine function, if the injection item corresponding to the written call instruction cannot be found, the engine function and/or the attribute requested by the call instruction are not injected in advance in the virtual machine. And then, executing a dynamic calling scheme, calling an engine object interface of the illusion engine, acquiring the engine object, finding an interface corresponding to the calling instruction from the interfaces contained in the engine object, calling the interface, and acquiring a return value.

In the same way, the read-write operation can be performed on the relevant attributes of the engine object, and the dynamic calling mode has lower efficiency compared with the static calling mode, but the calling defect existing when the engine function is not injected in advance in the static calling process is well overcome.

It should be noted that there is no order restriction between the call flow sets corresponding to the dashed boxes in fig. 12, that is, the engine call Lua function may be after or before the Lua static call engine function.

Example two

Fig. 13 is a block diagram schematically illustrating a program development apparatus according to the second embodiment of the present application, the media streaming apparatus may be divided into one or more program modules, and the one or more program modules are stored in a storage medium and executed by one or more processors to implement the second embodiment of the present application. The program modules referred to in the embodiments of the present application refer to a series of computer program instruction segments capable of performing specific functions, and the following description will specifically describe the functions of each program module in the embodiments.

As shown in fig. 13, the media streaming apparatus 1100 may include an export module 1110, an injection module 1120, and a call module 1130, wherein:

a exporting module 1110, configured to export a pre-specified object code through a game engine interface, where the object code is encapsulated in the game engine;

an injection module 1120, configured to generate an injection item according to an engine function and/or an engine attribute included in the object code, and inject the injection item into the virtual machine;

the calling module 1130 is configured to search the injection item corresponding to the calling instruction based on the written calling instruction, and call the engine function corresponding to the injection item according to the injection item.

In addition, referring to fig. 10, fig. 10 schematically shows a workflow diagram for game development using Lua and illusion engine, and in fig. 10, the program development apparatus is referred to as "WLua system".

Specifically, the WLua system includes an export plug-in for automatically exporting pre-specified engine functions and/or engine attributes from the game engine interface and injecting them into the virtual machine.

The steps in the figure are as follows:

(1) a developer writes a configuration file;

(2) starting an editor, loading the export plug-in of the application, and executing the export plug-in the editor to export the target code;

(3) the export plug-in automatically redefines the exported engine function, generates a packaging function, injects the packaging function into a virtual machine and other series of operations;

(4) to use these export interfaces in a game, a recompilation engine is required. After the compiling is finished, the game is started, and the engine function which is led out and injected into the virtual machine by the plug-in can be called.

The steps from (1) to (4) are in a game development period, but not in an actual running stage of the game, the configuration file can be continuously and perfectly exported in the development period, the processes from (1) to (4) are continuously repeated, engine interfaces required by the game are all imported into the Lua, the Lua script calls the interfaces to complete the realization of game logic in the game running period, and if the engine interfaces which are not imported into the Lua are called, the dynamic engine calling mode can be used, so that the Lua development of the game logic is completely realized.

(5) The game begins to run, this stage taking place on the player's gaming device;

(6) initializing WLua system in game item initialization function, the WLua system will create Lua virtual machine, execute the code of injection engine function to virtual machine, set exception capture function, etc

After the initialization is finished, the engine function can be called in the Lua code of the game, and various game functions are realized.

(7) Various game functions can be realized by calling pre-injected engine functions or corresponding interfaces in the Lua, and the advantage of high execution speed is achieved

(8) Through two calling modes of static calling and dynamic calling, developers can completely use Lua to complete the development work of game projects.

(9) When the game is finished, the WLua is closed, the closing process comprises cleaning engine objects recorded in the WLua system, closing the Lua virtual machine and the like, and then the game exits.

Additionally, referring to FIG. 11, FIG. 11 schematically illustrates the workflow of exporting plug-ins, with the following steps:

1. the launch editor loads the export plug-in, which needs to work in the engine editor environment.

2. Xml, wherein the plug-in needs to analyze a configuration file, which describes which engine classes need to be exported, and which engine functions and engine attributes are exported by each class;

3. traversing each export class, obtaining a UClass class pointer needing to be exported by using an engine interface FindObject < UClass > (null ptr, classname), then obtaining a UClass object by using the engine interface FindObject, wherein the UClass object is a reflection information class of the engine class needing to be exported, and only obtaining various information of the class through the UClass pointer, and then traversing each UFunction object of the UClass, wherein the UFunction represents the information of each engine function, obtaining a function name, a parameter number, a parameter name, a parameter type and a return value type, and generating a packaging function which can be used for injecting Lua virtualization. Traversing each attribute UProperty of the UClass to obtain the name, type, writing or reading of the attribute, generating set and get packing functions which can be injected into the Lua virtual machine, and generating registration codes for registering all the interface packing functions and the attribute packing functions. And finally, storing the generated codes into a cpp file, wherein each exported engine class generates a cpp file, and a Register interface and a SetMtLink interface are arranged in the cpp file. The Register interface is used for injecting each export interface and attribute access into the Lua virtual machine, and the SetMtLink interface is used for connecting Lua original tables of the engine classes with parent-child relationship in series, so that the subclasses can call the parent class interfaces.

4. And after each engine class needing to be exported is processed by 3, generating a final master control Register interface, and calling the Register interface and the SetMtLink interface in the cpp of each engine class.

5. The master control Register interface is written to the cpp file and these codes are part of the final game run, requiring the game to be recompiled. The WLua system calls the master control Register interface to complete interface registration when the game is initialized.

EXAMPLE III

Fig. 14 schematically shows a hardware architecture diagram of a computer device adapted to implement the media streaming method according to a sixth embodiment of the present application. In this embodiment, the computer device 10000 is a device capable of automatically performing numerical calculation and/or information processing according to a preset or stored instruction, and may be, for example, a rack server, a blade server, a tower server, a cabinet server (including an independent server or a server cluster composed of a plurality of servers), or an electronic device such as a smart phone, a tablet computer, or a notebook computer. As shown in fig. 14, computer device 10000 includes at least, but is not limited to: the memory 10010 and the processor 10020 may be communicatively linked to each other by a system bus. Wherein:

the memory 10010 includes at least one type of computer-readable storage medium including a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, and the like. In some embodiments, the storage 10010 may be an internal storage module of the computer device 10000, such as a hard disk or a memory of the computer device 10000. In other embodiments, the memory 10010 can also be an external storage device of the computer device 10000, such as a plug-in hard disk provided on the computer device 10000, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like. Of course, the memory 10010 may also include both internal and external memory modules of the computer device 10000. In this embodiment, the memory 10010 is generally used for storing an operating system and various application software installed on the computer device 10000, such as program codes for game development based on the Lua language. In addition, the memory 10010 may also be used to temporarily store various types of data that have been output or are to be output.

Processor 10020 may be a Central Processing Unit (CPU), a controller, a microcontroller, a microprocessor, or other data Processing chip in some embodiments. The processor 10020 is generally configured to control overall operations of the computer device 10000, such as performing control and processing related to data interaction or communication with the computer device 10000. In this embodiment, the processor 10020 is configured to execute program codes stored in the memory 10010 or process data.

It should be noted that fig. 14 only illustrates a computer device having components 10010 and 10020, but it is to be understood that not all illustrated components are required and that more or fewer components may be implemented instead.

In this embodiment, the method for developing a game based on Lua language stored in the memory 10010 can be further divided into one or more program modules, and executed by one or more processors (in this embodiment, the processor 10020) to complete the present application.

Example four

The present embodiment also provides a computer-readable storage medium, on which a computer program is stored, and the computer program, when executed by a processor, implements the steps of the method for developing a game based on the Lua language in the first embodiment.

In this embodiment, the computer-readable storage medium includes a flash memory, a hard disk, a multimedia card, a card type memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a Read Only Memory (ROM), an Electrically Erasable Programmable Read Only Memory (EEPROM), a Programmable Read Only Memory (PROM), a magnetic memory, a magnetic disk, an optical disk, and the like. In some embodiments, the computer readable storage medium may be an internal storage unit of the computer device, such as a hard disk or a memory of the computer device. In other embodiments, the computer-readable storage medium may be an external storage device of the computer device, such as a plug-in hard disk provided on the computer device, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like. Of course, the computer-readable storage medium may also include both internal and external storage devices of the computer device. In this embodiment, the computer-readable storage medium is generally used for storing an operating system and various application software installed in the computer device, for example, the program codes of the Lua language-based game development method in the second and third embodiments, and the like. Further, the computer-readable storage medium may also be used to temporarily store various types of data that have been output or are to be output.

It will be apparent to those skilled in the art that the modules or steps of the embodiments of the present application described above may be implemented by a general purpose computing device, they may be centralized on a single computing device or distributed across a network of multiple computing devices, and alternatively, they may be implemented by program code executable by a computing device, such that they may be stored in a storage device and executed by a computing device, and in some cases, the steps shown or described may be performed in an order different from that described herein, or they may be separately fabricated into individual integrated circuit modules, or multiple ones of them may be fabricated into a single integrated circuit module. Thus, embodiments of the present application are not limited to any specific combination of hardware and software.

The above description is only a preferred embodiment of the present application, and not intended to limit the scope of the present application, and all modifications of equivalent structures and equivalent processes, which are made by the contents of the specification and the drawings of the present application, or which are directly or indirectly applied to other related technical fields, are included in the scope of the present application.

Claims

1. A method for game development based on Lua language is characterized by comprising the following steps:

exporting pre-designated object code through a game engine interface, wherein the object code is packaged in the game engine;

2. The method of claim 1, wherein the object code is specified by a pre-created configuration file specifying engine functions and/or engine attributes that need to be exported.

3. The method of claim 2, wherein the configuration file further specifies an engine class in which the engine functions and/or engine attributes to be exported are encapsulated, and wherein exporting the pre-specified object code via the game engine interface comprises:

4. The method of claim 3, wherein the step of calling the game engine interface to obtain the reflection class of the engine class based on the name of the engine class specified by the configuration file comprises:

5. The method according to claim 3, wherein the step of acquiring, from the code information described in the reflection class, code information corresponding to the engine function and/or code information corresponding to the engine attribute that needs to be derived includes:

6. The method according to claim 1, wherein the step of generating an injection item according to an engine function and/or an engine attribute contained in the object code and injecting the injection item into the virtual machine comprises:

7. The method according to claim 1, wherein the step of generating an injection item according to an engine function and/or an engine attribute contained in the object code and injecting the injection item into the virtual machine comprises:

8. The method according to claim 7, wherein a package class of the engine function is defined in the injection item, and a relationship interface is further added to the package file in the packaging process, wherein the relationship interface is used for setting a meta table of the package class to restore parent-child relationships between engine classes in the game engine.

9. The method of claim 8, wherein after the step of encapsulating the injected item to form an encapsulated file, further comprising:

10. The method of claim 7, wherein encapsulating the injected item to form an encapsulated file further comprises: in the packaging process, the first object defined by the first type is created, and the injection item is embedded into the first object, wherein the first type is a preset type of the Lua language.

11. The method according to claim 1, wherein the step of searching for the injection item corresponding to the call instruction based on the written call instruction, and the step of calling the engine function corresponding to the injection item according to the injection item comprises:

12. The method according to claim 1, wherein the step of searching for the injection item corresponding to the call instruction based on the written call instruction, and the step of calling the engine function corresponding to the injection item according to the injection item comprises:

and calling the engine function according to the pointer of the engine function stored in the injection item, pressing the transmission parameter into the stack, and acquiring a calling return value from the stack top.

13. The method of claim 10, wherein the call instruction further specifies a name of the first object, and wherein the engine function specified by the call instruction is looked up from a meta table of the first object.

14. The method according to claim 1, wherein after the step of searching for the injection item corresponding to the call instruction based on the written call instruction and calling the engine function corresponding to the injection item according to the injection item, the method further comprises:

15. The method of claim 1, wherein said exporting a pre-specified object code through a game engine interface, said object code being encapsulated in said game engine prior to said step, further comprising:

16. The method according to claim 1, wherein after the step of searching for the injection item corresponding to the call instruction based on the written call instruction and calling the engine function corresponding to the injection item according to the injection item, the method further comprises:

17. The method according to claim 1, wherein after the step of searching for the injection item corresponding to the call instruction based on the written call instruction and calling the engine function corresponding to the injection item according to the injection item, the method further comprises:

18. A program development apparatus, characterized in that the apparatus comprises:

19. A computer arrangement comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor when executing the computer program being adapted to carry out the steps of the method of any of claims 1 to 17.

20. A computer-readable storage medium, in which a computer program is stored which is executable by at least one processor to cause the at least one processor to perform the steps of the method according to any one of claims 1 to 17.