CN118170634A - Game debugging method and device, electronic equipment and readable storage medium - Google Patents

Abstract

The application relates to a game debugging method, a game debugging device, electronic equipment and a readable storage medium, wherein the method comprises the following steps: establishing communication connection with a game client, and running a game program to be debugged in the game client; sending a breakpoint setting instruction to the game client to set a breakpoint at least one node to be debugged of the game program; when the game runs to a certain breakpoint, at least one breakpoint debugging instruction is sent to the game client, so that the game client executes corresponding operation on source code information associated with the breakpoint according to the breakpoint debugging instruction. The application realizes the rapid debugging of the game under the condition of the internal and external network isolation, provides a rapid, convenient and low-cost method for positioning and checking the fault of the game, greatly improves the debugging efficiency of the online game, remarkably saves the labor and time cost, and has simple implementation mode and strong practicability.

Description

Game debugging method and device, electronic equipment and readable storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a game debugging method, a game debugging device, an electronic device, and a readable storage medium.

Background

In the current game industry, the development and operation debugging of games are separated by adopting an internal and external network isolation mode, so that game products on the external network cannot be connected with a code editor of an internal network, and the debugging efficiency of the games is low.

Disclosure of Invention

Aiming at the situation, the embodiment of the application provides a game debugging method, a device, electronic equipment and a readable storage medium.

In a first aspect, an embodiment of the present application provides a game debugging method, which is executed by a debugging server, the method including:

establishing communication connection with a game client, wherein a game program to be debugged is run in the game client;

Sending a breakpoint setting instruction to the game client to set a breakpoint at least one node to be debugged of a game program;

when the game runs to a certain breakpoint, at least one breakpoint debugging instruction is sent to the game client, so that the game client executes operations corresponding to the breakpoint debugging instructions on the source code information according to the breakpoint debugging instructions.

In a second aspect, the embodiment of the present application further provides a game debugging method, where the method is executed by a game client, and the game client runs a game program to be debugged; the method comprises the following steps:

Establishing communication connection with a debugging server;

receiving and setting a breakpoint in at least one node to be debugged in the game program according to a breakpoint setting instruction;

when the game program runs to a certain breakpoint, receiving at least one breakpoint debugging instruction, and executing corresponding operation on source code information associated with the breakpoint according to the breakpoint debugging instruction.

In a third aspect, the embodiment of the present application further provides a game debug apparatus, where the apparatus may be used to implement the foregoing game debug method.

In a fourth aspect, an embodiment of the present application further provides an electronic device, including: a processor; and a memory arranged to store computer executable instructions that, when executed, cause the processor to perform the method of any of the above.

In a fifth aspect, embodiments of the present application also provide a computer-readable storage medium storing one or more programs, which when executed by an electronic device comprising a plurality of application programs, cause the electronic device to perform any of the methods described above.

The method adopted by the embodiment of the application at least has the following beneficial effects:

According to the application, the debugging server is additionally arranged between the internal network and the external network, and the debugging server can be in communication connection with the game client side to the outside so as to obtain the running condition of the game; when debugging a game program, a communication connection between a debugging server and a game client is established, after the connection is successful, the breakpoint setting instruction can be sent to the game client, and one or more breakpoints are deployed in the game program; when the game program runs to a certain breakpoint, a tester or a developer can input one or more breakpoint debugging instructions into the debugging server, and the debugging server sends the breakpoint debugging instructions to the game client, so that the game client executes operations corresponding to the received breakpoint debugging instructions on source code information associated with the breakpoint, such as outputting the values of context variables, stepping in functions in a single step and the like, so that the game program is debugged quickly. The application realizes the rapid debugging of the game program under the condition of the internal and external network isolation, provides a rapid, convenient and low-cost game program debugging method for development or testers, greatly improves the debugging efficiency of the online game program, remarkably saves the labor and time cost, and has simple implementation mode and strong practicability.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute a limitation on the application. In the drawings:

FIG. 1 shows a flow diagram of a game debugging method according to one embodiment of the application;

FIG. 2 shows a schematic diagram of a game debugging system according to one embodiment of the present application;

FIG. 3 shows a flow diagram of a game debugging method according to another embodiment of the present application;

FIG. 4 shows a schematic structural view of a first game debugging device according to an embodiment of the present application;

FIG. 5 shows a schematic structural diagram of a second game debugging device according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be clearly and completely described below with reference to specific embodiments of the present application and corresponding drawings. It will be apparent that the described embodiments are only some, but not all, embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

The following describes in detail the technical solutions provided by the embodiments of the present application with reference to the accompanying drawings.

In the prior art, game development is usually performed on an intranet, and online products are all operated on an extranet, and because the intranet and the extranet are separated, and a game program is debugged, if a fault is positioned, the extranet cannot directly access source codes of the intranet, so that after the online products have problems, the online products can only gradually check the problems in a log mode, and the like, and the online products are time-consuming and labor-consuming.

Therefore, the application provides a game debugging method, which is additionally provided with a debugging server, realizes the butt joint of the intranet source code information and the extranet game through the debugging server, and simultaneously introduces a debugging command into the intranet source code information and the extranet game, thereby realizing the rapid debugging of online game products.

The LUA language is flexibly embedded into the application program so as to provide flexible expansion and customization functions for the application program, and many games are developed in the LUA language. Fig. 1 shows a schematic flow chart of a game debugging method according to an embodiment of the present application, and the present application is applicable to a debugging server, and as can be seen from fig. 1, the present application at least includes steps S110 to S130:

step S110: a communication connection is established with a game client in which a game program to be debugged is run.

Firstly, an application scene of the application is described, in order to find problems or faults in the game when the game is on line or in the development process, usually a tester or a developer can debug the game, and if the problems are found, the problems can be processed in time.

The game debugging method of the present application may be implemented by a game debugging system, fig. 2 shows a schematic diagram of a game debugging system according to an embodiment of the present application, and as can be seen from fig. 2, the game debugging system 200 includes a debugging server 210 and a game client 220, wherein the game client 220 installs and runs a game program, and the game client 220 may be, but is not limited to, a mobile phone or a PC. Wherein, the debug server 210 may establish a communication connection with the game client 220 to obtain the running situation of the game. The game program runs on the game client 220, and a tester or developer can input various instructions at the debug server 210 to enable debugging of the game.

One of the main objectives of game debugging is to locate a game fault, and the following embodiments of the present application will be described with respect to locating a game fault. When the game is debugged, a communication connection between the debug server 210 and the game client 220 is first established, for example, the debug server 210 may send a connection request to the game client 220 and receive consent information returned by the game client 220, so that a communication connection between the debug server 210 and the game client 220 is established.

In other embodiments of the present application, the establishing a communication connection with a game client includes: reading a starting success log, and determining a monitoring address and a monitoring interface; responding to a game management connection instruction, and establishing communication connection with the game client according to the monitoring address and the monitoring interface, wherein the game management connection instruction is formed by a game manager; and if the connection is successful, outputting a log of connection success with the game client.

When game debugging is to be performed, starting a debugging server, and after starting, seeing an output log of the debugging server, wherein the output log comprises a monitoring address and a monitoring port for connecting monitoring; and starting the game client, calling out a game management (GAME MASTER, GM) interface at the debugging server, and enabling the debugging server to be connected to the game client by inputting a GM command at the game management interface, wherein the connection address and the connection port are the monitoring address and the monitoring port in the log output by the debugging server. After the client is successfully connected to the debugging server, the debugging server can be seen to output a log of the successful connection of the game client, and the game can be formally entered for debugging.

Step S120: and sending a breakpoint setting instruction to the game client to set a breakpoint at least one node to be debugged of the game program.

Because the LUA virtual machine supports various debug commands, various debug commands of the LUA virtual machine can be introduced into the LUA virtual machine, and breakpoint positioning is realized, and in particular, in some embodiments of the application, a debug server provides a command line interface which facilitates the input of debug commands, and a tester or a developer can input breakpoint setting commands on the command line interface of the debug server; in other embodiments, the breakpoint setting instruction may also be preset, i.e., within the debug server. After receiving or reading the breakpoint setting instruction stored locally, the debug server sends the breakpoint setting instruction to the game client 220, and the game client 220 executes the breakpoint setting instruction, so that embedding of the breakpoint at one or more nodes to be debugged of the game program can be realized. In some embodiments of the present application, the breakpoint setting instruction is formed based on LUA language, and specifically, but not limited to, a b command based on LUA language.

In a practical scenario, the data interaction format between debug server 210 and game client 220 is different from the data format executable by the game client. Generally speaking, the data interaction between the debug server and the game client is in a first format, such as Json format, and the real breakpoint setting instruction executed at the game client is a LUA virtual machine, so the game client needs to convert the received instruction into a second format instruction recognized by the LUA virtual machine, such as a specific binary format, and thus there is a problem of data format conversion in the breakpoint deployment process.

In some embodiments of the present application, the sending a breakpoint setting instruction to the game client to set a breakpoint at least one node to be debugged in the game program includes: converting the breakpoint setting instruction into a first format instruction; and sending the first format instruction to the game client side so that the game client side converts the first format instruction into a second format instruction, and enabling the game program to execute the second format instruction so as to realize breakpoint deployment on at least one node to be debugged of the game.

Specifically, a tester or a developer forms a breakpoint setting instruction according to a game function to be debugged through a b command, after receiving or reading the breakpoint setting instruction, the debugging server converts the breakpoint setting instruction into a first format instruction, such as a Json format, and sends the first format instruction to a game client, the game client converts the first format instruction into a second format instruction, such as a specific binary format, the second format instruction is a language which can be understood by the LUA virtual machine, at the moment, the game client gives the second format instruction to the virtual machine for execution, and after the execution, the breakpoint is buried at the corresponding position of one or more nodes to be debugged of the game program.

Step S130: when the game program runs to a certain breakpoint, at least one breakpoint debugging instruction is sent to the game client, so that the game client executes corresponding operation on source code information associated with the breakpoint according to the breakpoint debugging instruction.

When the game program runs to a breakpoint, the game client pauses the running of the game program, and here, taking one breakpoint as an example, when the game program runs to the breakpoint, pauses, and then a tester or a developer can debug the breakpoint by inputting a breakpoint debug instruction at the debug server, wherein the number of the breakpoint debug instructions is usually a plurality of, and in some embodiments, the breakpoint debug instructions are all formed based on a debug command in LUA language.

Since the debug server does not contain any source code information, after receiving the breakpoint debug instruction, the debug server sends the breakpoint debug instruction to the game client 200, so that the game client 200 performs corresponding operations on the source code information, and debugging of the game is realized. Specifically, for fault location, two forms are generally adopted, one is to output the values of the context variables, and whether the fault exists at the breakpoint or not can be determined through the values, and particularly, a problem occurs to a certain value, so that the problem occurs; the second is a single step trial, i.e., a single step into each function, which can determine if each function has problems.

Specifically, in some embodiments, the plurality of breakpoint debug instructions includes: a context variable print instruction, a run to breakpoint next line instruction, and a run to next breakpoint instruction, wherein in some embodiments the context variable print instruction is formed based on a p command in LUA language, the run to breakpoint next line instruction is formed based on an n command in LUA language, and the run to next breakpoint instruction is formed based on a c command in LUA language; the sending at least one breakpoint debug instruction to the game client, so that the game client executes corresponding operations on source code information associated with the breakpoint according to the breakpoint debug instruction, including: sending the context variable obtaining instruction to the game client to obtain the value of the context variable corresponding to the breakpoint in the game program; transmitting the instruction of running to the next line of breakpoint to the game client to run to the next line of the current breakpoint in the source code information in the game program; and sending the instruction from the running to the next breakpoint to the game client so as to resume the running of the game until the next breakpoint of the current breakpoint.

When the fault location is performed by adopting the manner of outputting the value of the context variable, a context variable print instruction, a run-to-break point next line instruction, and a run-to-next break point instruction can be sequentially input respectively, wherein the context variable print instruction is formed based on a p command in LUA language, the run-to-break point next line instruction is formed based on an n command in LUA language, and the run-to-next break point instruction is formed based on a c command in LUA language.

After receiving the context variable printing instruction, the adjustable server sends the context variable printing instruction to the game client, and the game client reads the corresponding source code information and prints the value of the context variable in the source code information according to the context variable printing instruction; after printing, if the tuning server receives an instruction for running to the next line of the breakpoint, the instruction is sent to the game client, after the game client is connected to the instruction for running to the next line of the breakpoint, the game program is controlled to run to the next line of the breakpoint, and usually related personnel use the instruction after removing the fault in the breakpoint; if the tuning server receives the instruction from the running to the next breakpoint and sends the instruction to the game client, the game client controls the game program to continue to run to the next breakpoint after the game client receives the instruction from the running to the next breakpoint, and when the current breakpoint is processed, the instruction can be used to run to the next breakpoint. In the above process, whether a fault exists or not may be determined by a tester or a developer according to the values of the context variables.

The foregoing single-step debug method may also be employed to determine game faults, and in particular, in other embodiments, the plurality of breakpoint debug instructions include: a single step entry function instruction formed based on s-commands in LUA language, and a run to next breakpoint instruction formed based on c-commands in LUA language; the sending at least one breakpoint debug instruction to the game client, so that the game client executes corresponding operations on source code information associated with the breakpoint according to the breakpoint debug instruction, including: the single step function entering instruction is sent to the game client to sequentially enter a plurality of functions associated with the break points in the source code information and determine the running state of each function; and sending the instruction from the running to the next breakpoint to the game client so as to resume the running of the game and enable the game program to run to the next breakpoint of the current breakpoint.

When the step-in function instruction is received by the adjustable server, the step-in function instruction is sent to the game client, and after the step-in function instruction is received by the game client, each function in the source code information is stepped in one by one and related information is returned, so that a tester or a developer can determine whether a certain function has a problem or not; when the tuning server receives the instruction from the next breakpoint, the instruction from the next breakpoint is sent to the game client, and after the game client receives the instruction from the next breakpoint, the game client controls the game at the west of the city to continue to run to the next breakpoint. In the prior art, besides adopting a log output mode to locate game faults, the problem of searching the character string codes can be interpreted and executed through lua under partial conditions, and the method can well acquire the running state of the game, but can not acquire various states of a single function in the execution process, so that the problem inside the function is difficult to locate. The method for positioning the single-step entry function can easily avoid the problem and realize the positioning of the problem inside the function.

If the game is checked to have no fault or the fault has been removed, all the breakpoints set in the game may be deleted, so that the game continues to run or is re-run to verify the positioning result, where in some embodiments of the present application, the multiple breakpoint debug instructions further include: a delete breakpoint instruction formed based on an r command in LUA language; the sending at least one breakpoint debug instruction to the game client, so that the game client executes corresponding operations on source code information associated with the breakpoint according to the breakpoint debug instruction, including: and sending the breakpoint deleting instruction to the game client to delete the corresponding breakpoint in the game program so as to continue or rerun the game program.

The rerun game may check the fault location and the troubleshooting result, and if no problem or fault is found to be located, steps S120 to 130 may be repeatedly performed to locate the fault again until the fault is found.

In addition, firstly, corresponding to a game program developed by using the LUA language, in an actual scene, various debugging commands supporting the LUA language are introduced when the application is implemented, and the breakpoint debugging function is used for the functions of a LUA debugger and a LUA virtual machine; secondly, because breakpoint debugging can suspend game operation, the application can not directly perform online positioning when a player plays a game, and can perform positioning and debugging by terminal equipment of an internal staff.

As can be seen from fig. 1, in the application, a debug server is additionally arranged between the internal network and the external network, and the debug server can be connected with a game client in a communication way to obtain the running condition of the game; in addition, various debugging commands are introduced into the game client, a worker can firstly establish communication connection between a debugging server and the game client when debugging the game program in the form of a breakpoint setting command and various breakpoint debugging commands, and after the connection is successful, the breakpoint setting command can be sent to the game client, and one or more breakpoints are deployed in the game program; when the game program runs to a certain breakpoint, a tester or a developer can input one or more breakpoint debugging instructions into the debugging server, and the debugging server sends the breakpoint debugging instructions to the game client, so that the game client executes operations corresponding to the received breakpoint debugging instructions on source code information associated with the breakpoint, such as outputting the values of context variables, stepping in functions in a single step and the like, so that the game program is debugged quickly. The application realizes the rapid debugging of the game program under the condition of the internal and external network isolation, provides a rapid, convenient and low-cost game program debugging method for development or testers, greatly improves the debugging efficiency of the online game program, remarkably saves the labor and time cost, and has simple implementation mode and strong practicability.

Fig. 3 shows a flow chart of a game debugging method according to another embodiment of the present application, which can be executed by a game client 220, the game client 220 running a game program to be debugged, and as can be seen from fig. 3, the present embodiment at least includes:

Step S310: a communication connection is established with the debug server.

Specifically, the game management connection request sent by the debug server 210 may be received and agreed, and when the debug server 210 receives the feedback signal from the game client 220, a communication connection is established.

Step S320: and receiving and setting a breakpoint in at least one node to be debugged in the game program according to the breakpoint setting instruction.

The breakpoint setting instruction sent by the debug server 210 is received, and the breakpoint setting instruction is executed, so that one or more breakpoints can be deployed in the game program.

In an actual scenario, the breakpoint setting instruction sent by the debug server 210 may not be a language recognizable by the game client 220, and thus the format may need to be converted, specifically, the debug server 210 converts the breakpoint setting instruction into a first format instruction and sends the first format instruction to the game client 220, and the game client 220 receives the first format instruction sent by the debug server 210 and converts the first format instruction into a second format instruction, and makes the game program execute the second format instruction to deploy the breakpoint at least one node to be debugged of the game program.

Step S330: when the game program runs to a certain breakpoint, at least one breakpoint debugging instruction is received, and corresponding operation 5 is executed on source code information associated with the breakpoint according to the breakpoint debugging instruction.

When the game program runs to a certain breakpoint, the game program is controlled to pause running, various breakpoint debugging instructions sent by the debugging server 210 are received, and the received various breakpoint debugging instructions are executed based on source code information associated with the breakpoint, so that the game is debugged.

Specifically, the following description is made in the LUA language of the game program, and in some embodiments, the breakpoint debug instructions include: a context variable print instruction, a run-to-breakpoint next line instruction, and a run-to-next-breakpoint instruction, wherein the context variable print instruction is formed based on a p command in LUA language, and the run-to-breakpoint next line instruction is based on LUA

N-command formation in the language, the run-to-next breakpoint instruction being a c-command shape based on LUA language

To get final product; the game client 220 sequentially executes operations corresponding to 5 of the breakpoint debug instructions on the source code information specifically includes: printing a value of a context variable in response to the context variable print instruction;

Responding to the instruction of running to the next line of the breakpoint, and running to the next line of the current breakpoint in the source code information; and responding to the instruction from the running to the next breakpoint, and restoring the running of the game until the next breakpoint of the current breakpoint.

In other embodiments, the plurality of breakpoint debug instructions includes: a single step entry function instruction, 0, and a run-to-next breakpoint instruction, the single step entry function instruction formed based on an s-command in LUA language, the run-to-next breakpoint instruction formed based on a c-command in LUA language; the game client 220 sequentially executes operations corresponding to each breakpoint debug instruction on the source code information specifically includes: sequentially entering a plurality of the source code information associated with the breakpoint in response to the single-step entry function instruction

The running state of each function is determined in the functions; and in response to the run-to-next breakpoint instruction, 5 resumes the game's run until the next breakpoint of the current breakpoint.

In still other embodiments, the plurality of breakpoint debug instructions further comprise: a delete breakpoint instruction formed based on an r command in LUA language; the game client 220 sequentially executes operations corresponding to each breakpoint debug instruction on the source code information specifically includes: and deleting the corresponding breakpoint in the game in response to the breakpoint deleting instruction so as to continue or rerun the game.

Fig. 4 shows a schematic structural view of a first game debugging device according to an embodiment of the present application,

The game debugging device 400 may be deployed in the debugging server 210 (fig. 2), and as can be seen from fig. 4, the first game debugging device 400 includes:

A first connection unit 410 for establishing a communication connection with the game client;

a first breakpoint setting unit 420, configured to send a breakpoint setting instruction to the game client, so as to set a breakpoint at least one node to be debugged of the game program;

The first debug unit 430 is configured to send at least one breakpoint debug instruction to the game client when the game runs to a certain breakpoint, so that the game client executes operations corresponding to the breakpoint debug instructions on the source code information according to the breakpoint debug instructions.

In some embodiments of the present application, in the above-described first game debugging device, the first breakpoint setting unit 420 is configured to convert the breakpoint setting instruction into a first format instruction; and sending the first format instruction to the game client side so that the game client side converts the first format instruction into a second format instruction, and enabling the game program to execute the second format instruction so as to realize breakpoint deployment on at least one node to be debugged of the game.

In some embodiments of the present application, in the first game debugging device, the plurality of breakpoint debugging instructions include: the context variable obtains an instruction, runs to the next line of breakpoint instruction, and runs to the next breakpoint instruction; a first debug unit 430, configured to send the context variable obtaining instruction to the game client, so as to obtain, in the game program, a value of a context variable corresponding to the breakpoint; transmitting the instruction of running to the next line of breakpoint to the game client to run to the next line of the current breakpoint in the source code information in the game program; and sending the instruction from the running to the next breakpoint to the game client so as to resume the running of the game until the next breakpoint of the current breakpoint.

In some embodiments of the present application, in the first game debugging device, the plurality of breakpoint debugging instructions include: a single step entering function instruction and a running to next breakpoint instruction; a first debug unit 430, configured to send the single step entry function instruction to the game client, so as to sequentially enter into a plurality of functions associated with the breakpoint in the source code information and determine an operation state of each of the functions; and sending the instruction from the running to the next breakpoint to the game client so as to resume the running of the game and enable the game program to run to the next breakpoint of the current breakpoint.

In some embodiments of the present application, in the first game debugging device, the plurality of breakpoint debugging instructions further include: deleting a breakpoint instruction; the first debug unit 430 is configured to send the breakpoint deleting instruction to the game client to delete a breakpoint corresponding to the game program, so as to continue or rerun the game program.

Fig. 5 shows a schematic structural diagram of a second game debugging device according to an embodiment of the present application, and a game debugging device 500 may be deployed in the game client 220 (fig. 2), and as can be seen from fig. 5, the second game debugging device 500 includes:

a second connection unit 510 for establishing a communication connection with the debug server;

A second breakpoint setting unit 520, configured to receive and set a breakpoint at least one node to be debugged in the game program according to a breakpoint setting instruction;

and the second debug unit 530 is configured to receive at least one breakpoint debug instruction when the game program runs to a certain breakpoint, and execute a corresponding operation on source code information associated with the breakpoint according to the breakpoint debug instruction.

In some embodiments of the present application, in the above second game debugging device, the second breakpoint setting unit 520 is configured to receive a first format instruction sent by the debugging server, convert the first format instruction into a second format instruction, and make the game program execute the second format instruction, so as to deploy a breakpoint at least one node to be debugged of the game program.

It should be noted that the first or second game debugging device may implement the corresponding game debugging method, which is not described herein.

Fig. 6 is a schematic structural view of an electronic device according to an embodiment of the present application. Referring to fig. 6, at the hardware level, the electronic device includes a processor, and optionally an internal bus, a network interface, and a memory. The Memory may include a Memory, such as a Random-Access Memory (RAM), and may further include a non-volatile Memory (non-volatile Memory), such as at least 1 disk Memory. Of course, the electronic device may also include hardware required for other services.

The processor, network interface, and memory may be interconnected by an internal bus, which may be an ISA (Industry Standard Architecture ) bus, a PCI (PERIPHERAL COMPONENT INTERCONNECT, peripheral component interconnect standard) bus, or EISA (Extended Industry Standard Architecture ) bus, among others. The buses may be classified as address buses, data buses, control buses, etc. For ease of illustration, only one bi-directional arrow is shown in FIG. 4, but not only one bus or type of bus.

And the memory is used for storing programs. In particular, the program may include program code including computer-operating instructions. The memory may include memory and non-volatile storage and provide instructions and data to the processor.

The processor reads the corresponding computer program from the nonvolatile memory into the memory and then runs, and forms the first or second game debugging device on the logic level. And the processor is used for executing the program stored in the memory and particularly used for executing the method.

The method performed by the first or second game debugging device disclosed in the embodiment of fig. 4 or 5 of the present application may be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip having signal processing capabilities. In implementation, each step of the above method may be implemented by an integrated logic circuit of hardware in a processor or an instruction in a software format. The processor may be a general-purpose processor, including a central processing unit (Central Processing Unit, CPU), a network processor (Network Processor, NP), etc.; but may also be a digital signal Processor (DIGITAL SIGNAL Processor, DSP), application SPECIFIC INTEGRATED Circuit (ASIC), field-Programmable gate array (Field-Programmable GATE ARRAY, FPGA) or other Programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be embodied directly in the execution of a hardware decoding processor, or in the execution of a combination of hardware and software modules in a decoding processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory, and the processor reads configuration information in the memory and, in combination with its hardware, performs the steps of the above method.

The electronic device may further execute the method executed by the first or second game debugging device in fig. 4 or 5, and implement the functions of the first or second game debugging device in the embodiment shown in fig. 4 or 5, which are not described herein again.

The embodiments of the present application also provide a computer-readable storage medium storing one or more programs, the one or more programs including instructions, which when executed by an electronic device including a plurality of application programs, enable the electronic device to perform a method performed by the first or second game debugging apparatus in the embodiment shown in fig. 4 or 5, and in particular to perform the foregoing method.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include non-volatile memory in a computer-readable medium, random Access Memory (RAM) and/or non-volatile memory, etc., in a format such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both permanent and non-permanent, removable and non-removable media, may implement configuration information storage by any method or technology. The configuration information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store configuration information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The foregoing is merely exemplary of the present application and is not intended to limit the present application. Various modifications and variations of the present application will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. which come within the spirit and principles of the application are to be included in the scope of the claims of the present application.

Claims (10)

1. A game debugging method, the method being performed by a debugging server, the method comprising:

establishing communication connection with a game client, wherein a game program to be debugged is run in the game client;

sending a breakpoint setting instruction to the game client to set a breakpoint at least one node to be debugged in the game program;

When the game program runs to a certain breakpoint, at least one breakpoint debugging instruction is sent to the game client, so that the game client executes corresponding operation on source code information associated with the breakpoint according to the breakpoint debugging instruction.

2. The method of claim 1, wherein the sending a breakpoint setting instruction to the game client to set a breakpoint at least one node to be debugged in the game program comprises:

converting the breakpoint setting instruction into a first format instruction;

and sending the first format instruction to the game client side so that the game client side converts the first format instruction into a second format instruction, and enabling the game program to execute the second format instruction so as to realize breakpoint deployment on at least one node to be debugged of the game.

3. The method of claim 1, wherein the plurality of breakpoint debug instructions comprises: a context variable fetch instruction, an instruction to run to the next line of breakpoints, and an instruction to run to the next breakpoint,

The sending at least one breakpoint debug instruction to the game client, so that the game client executes corresponding operations on source code information associated with the breakpoint according to the breakpoint debug instruction, including:

Sending the context variable obtaining instruction to the game client to obtain the value of the context variable corresponding to the breakpoint in the game program;

Transmitting the instruction of running to the next line of breakpoint to the game client to run to the next line of the current breakpoint in the source code information in the game program;

And sending the instruction from the running to the next breakpoint to the game client so as to resume the running of the game until the next breakpoint of the current breakpoint.

4. The method of claim 1, wherein the plurality of breakpoint debug instructions comprise: a single step entering function instruction and a running to next breakpoint instruction;

The sending at least one breakpoint debug instruction to the game client, so that the game client executes corresponding operations on source code information associated with the breakpoint according to the breakpoint debug instruction, including:

The single step function entering instruction is sent to the game client to sequentially enter a plurality of functions associated with the break points in the source code information and determine the running state of each function;

and sending the instruction from the running to the next breakpoint to the game client so as to resume the running of the game and enable the game program to run to the next breakpoint of the current breakpoint.

5. The method of claim 3 or 4, wherein the plurality of breakpoint debug instructions further comprise: deleting a breakpoint instruction;

The sending at least one breakpoint debug instruction to the game client, so that the game client executes corresponding operations on source code information associated with the breakpoint according to the breakpoint debug instruction, including:

and sending the breakpoint deleting instruction to the game client to delete the corresponding breakpoint in the game program so as to continue or rerun the game program.

6. A game debugging method, the method being performed by a game client running a game program to be debugged, the method comprising:

Establishing communication connection with a debugging server;

receiving and setting a breakpoint in at least one node to be debugged in the game program according to a breakpoint setting instruction;

when the game program runs to a certain breakpoint, receiving at least one breakpoint debugging instruction, and executing corresponding operation on source code information associated with the breakpoint according to the breakpoint debugging instruction.

7. The method of claim 6, wherein receiving and setting a breakpoint at least one node to be debugged in the game program according to a breakpoint setting instruction comprises:

Receiving a first format instruction sent by the debugging server, converting the first format instruction into a second format instruction, and enabling the game program to execute the second format instruction so as to deploy a breakpoint at least one node to be debugged of the game program.

8. A game debugging device for implementing the game debugging method of any one of claims 1-5 or any one of claims 6-7.

9. An electronic device, comprising:

a processor; and

A memory arranged to store computer executable instructions which, when executed, cause the processor to perform the method of any of claims 1 to 5 or any of claims 6 to 7.

10. A computer readable storage medium storing one or more programs, which when executed by an electronic device comprising a plurality of application programs, cause the electronic device to perform the method of any of claims 1-5 or any of claims 6-7.