CN108854066B

CN108854066B - Method, device, computer equipment and storage medium for processing behavior state in game

Info

Publication number: CN108854066B
Application number: CN201810642701.3A
Authority: CN
Inventors: 张钧凯
Original assignee: Tencent Technology Shanghai Co Ltd
Current assignee: Tencent Technology Shanghai Co Ltd
Priority date: 2018-06-21
Filing date: 2018-06-21
Publication date: 2024-03-12
Anticipated expiration: 2038-06-21
Also published as: CN108854066A

Abstract

The application relates to a behavior state processing method, a behavior state processing device, computer equipment and a readable storage medium in a game, wherein the method comprises the following steps: acquiring a behavior execution request received in the running process of a current service module in a game; analyzing the behavior execution request to obtain a target behavior identifier; when the state detection interface is called, and the target behavior is determined to be in a locking state corresponding to the conflict of the current service module according to the target behavior identification, terminating the target behavior corresponding to the execution behavior execution request. And detecting the target behavior state by calling the state detection interface, when the target behavior is in a locked state, indicating that the target behavior conflicts with the current service module, and stopping executing the target behavior, thereby avoiding game faults caused by continuously executing the target behavior and improving the stability and fluency of game operation.

Description

Method, device, computer equipment and storage medium for processing behavior state in game

Technical Field

The present invention relates to the field of game technologies, and in particular, to a method and apparatus for processing behavior states in a game, a computer device, and a readable storage medium.

Background

With the rapid development of computer technology, electronic games have been accepted by more and more people as a recreational way. The electronic game is characterized in that virtual game scenes are set, and a user controls virtual roles to perform task operation according to a certain rule so as to achieve the purposes of entertainment and interaction.

In game development, based on different service divisions, there are a large number of different service modules, and state conflicts of some game behaviors occur between a large number of service modules, so that game faults occur, for example: while the task of wearing equipment is not allowed to be performed when the combat module is operated, if the behavior of wearing equipment is performed when the combat module is operated, there is a problem in that a game malfunction is caused by a state conflict. However, because of the large scale of the game items, the related service modules are numerous, so how to effectively avoid the state conflict in the game is a current problem to be solved urgently.

Disclosure of Invention

Based on this, it is necessary to provide a method, an apparatus, a computer device and a readable storage medium for processing behavior states in a game, aiming at the technical problem of game faults caused by state conflicts.

A method of behavior state processing in a game, the method comprising:

acquiring a behavior execution request received in the running process of a current service module in a game;

analyzing the behavior execution request to obtain a target behavior identifier;

and when the state detection interface is called and the target behavior is determined to be in the locking state corresponding to the conflict of the current service module according to the target behavior identification, terminating executing the target behavior corresponding to the behavior execution request.

An in-game behavior state processing apparatus, the apparatus comprising:

the request module is used for acquiring a behavior execution request received in the running process of the current service module in the game;

the analysis module is used for analyzing the behavior execution request to obtain a target behavior identifier;

and the execution module is used for terminating execution of the target behavior corresponding to the behavior execution request when the state detection interface is called and the target behavior is determined to be in the locking state corresponding to the conflict of the current service module according to the target behavior identification.

A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor when executing the computer program performs the steps of:

A computer readable storage medium storing a computer program, wherein the computer program when executed by a processor performs the steps of:

In the game running process of the current service module, when the behavior execution request is received, the target behavior identification is obtained by analyzing the behavior execution request, and when the state detection interface is called, the target behavior is determined to be in the locking state corresponding to the conflict of the current service module according to the target behavior identification, the execution of the target behavior corresponding to the behavior execution request is terminated. And detecting the target behavior state by calling the state detection interface, when the target behavior is in a locked state, indicating that the target behavior conflicts with the current service module, and stopping executing the target behavior, thereby avoiding game faults caused by continuously executing the target behavior and improving the stability and fluency of game operation.

Drawings

FIG. 1 is a diagram of an application environment for a behavior state processing method in a game in one embodiment;

FIG. 2 is a flow chart of a method of behavior state processing in a game according to one embodiment;

FIG. 3 is a flow chart illustrating steps for terminating execution of a target behavior in one embodiment;

FIG. 4 is a flowchart illustrating a step of displaying a lock hint in one embodiment;

FIG. 5 is a block diagram of a lock behavior state table in one embodiment;

FIG. 6 is a flow chart of a target behavior lock step in one embodiment;

FIG. 7 is a flow chart of a target behavior unlocking step in one embodiment;

FIG. 8 is a flow chart of a target behavior unlocking step in one embodiment;

FIG. 9 is a flow diagram of a method for behavior state processing in a game in one embodiment;

FIG. 10 is a flow diagram of a method for behavior state processing in a game in one embodiment;

FIG. 11 is an interface diagram showing lock hint information in one embodiment;

FIG. 12 is a block diagram of an in-game behavior state processing device in one embodiment;

FIG. 13 is a block diagram of the execution module in one embodiment;

FIG. 14 is a partial block diagram of an in-game behavior state processing device in one embodiment;

FIG. 15 is a block diagram of a computer device in one embodiment.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application.

FIG. 1 is a diagram of an application environment for a behavior state processing method in a game in one embodiment. Referring to fig. 1, the in-game behavior state processing method is applied to an in-game behavior state processing system. The in-game behavior state processing system includes a request terminal 110 and a server 120. The request terminal 110 may be a desktop terminal or a mobile terminal, and the mobile terminal may be at least one of a mobile phone, a tablet computer, a notebook computer, and the like. Specifically, the requesting terminal 110 has game software installed therein, and a user can perform a game operation through an input device of the requesting terminal 110, the requesting terminal 110 receives data and/or instructions input by the user, and feeds back and displays a response to the input data and/or instructions. The input device may be a keyboard, a touch screen, or the like, which may perform an input operation. The server 120 may be implemented as a stand-alone server or as a server cluster composed of a plurality of servers. The server 120 is used to respond to game requests sent by the requesting terminal 110 to perform related operations in the game, such as behavior state processing in the game.

As shown in FIG. 2, in one embodiment, an in-game behavior state processing method is provided. The present embodiment is mainly exemplified by the application of the method to the server 120 in fig. 1. Referring to fig. 2, the in-game behavior state processing method specifically includes the following steps:

s202, a behavior execution request received in the running process of a current service module in the game is obtained.

The service module refers to a logic code based on service function division in the game development process, for example, the service module can be specifically a combat module, a map module, a knapsack module, a role module and the like. The current service module refers to a currently running service module, and the current service module includes one or more currently running service modules. In an electronic game, an action refers to an operation that can be implemented by a game runtime in response to an action execution request, for example, the action may specifically be a scene jump, equipment replacement, active attack, etc. It may be understood that the action execution request refers to a request instruction for requesting to execute the target action, for example, the action execution request may be a scene jump request initiated by a user through a request terminal, a co-click request initiated by a teammate, a prompt request initiated by other service modules, and the like.

When a behavior execution request is received in the process of running the current service module by the game, the behavior execution request is acquired so as to respond to the behavior execution request. In particular, the behavioral execution request may be initiated by a game player or other business module. For example, when the current game is in a combat state, a game player initiates a scene jump request through a touch screen of a request terminal, and the server receives the initiated scene jump request to execute subsequent response operations, wherein the response operations specifically can include obtaining scene jump logic to judge whether to execute scene jump; for another example, when a role is executing a set task, the prop module initiates a prompt request about whether to purchase a new prop, the server itself receives the prompt request, and in response to the request, the response operation may specifically include obtaining the prompt implementation logic, and determining whether the prompt may be performed.

S204, analyzing the behavior execution request to obtain the target behavior identification.

The target behavior refers to a behavior requested to be executed by the behavior execution request. It is understood that the target behavior identification refers to a marking for identifying the target behavior. Specifically, the target behavior identifier may be a name or a unique code number of a preset target behavior.

When a behavior execution request is received, the behavior execution request is acquired, and the request is analyzed to obtain a target behavior identifier corresponding to the request. Further, based on the obtained target behavior identification, the realization logic for executing the target behavior is obtained to execute the subsequent operation. Wherein the implementation logic is specific implementation code.

S206, when the state detection interface is called, and the target behavior is determined to be in the locking state corresponding to the conflict with the current service module according to the target behavior identification, terminating the target behavior corresponding to the execution behavior execution request.

The state detection interface is an API (Application Programming Interface ) set by a game developer and used for detecting the current state of the behavior, and the interface is independent of the logic code of the original service module and has good reusability, so that the state detection of any target behavior can be realized by calling the state detection interface.

Wherein the behavioral states include a locked state and an unlocked state. The locked state refers to a state in which the target behavior is not allowed to be executed, and the opposite state is an unlocked state. When the target behavior conflicts with the current business module, the target behavior is locked, so that the target behavior is in a locked state and is not allowed to be executed.

Specifically, the state detection interface is called to detect the current state of the target behavior identification, and when the target behavior is determined to be in the locking state corresponding to the conflict with the current service module according to the target behavior identification, the target behavior corresponding to the execution behavior execution request is terminated. For example, when the game is in a combat state, scene hopping is not allowed, when an initiated scene hopping request is received, the current state of scene hopping behavior is detected, and when the current state of scene hopping behavior is a locked state, execution of scene hopping is terminated.

The detection of the behavior state is realized by calling the state detection interface in a non-invasive programming mode, complex modification of the original game code is not needed, and the interface is independent of the logic code of the original service module, so that the maintainability and the expandability are strong.

Further, a state detection logic is embedded in the realization logic of the game behavior, so that the state detection of the behavior which needs to be executed currently is performed through the state detection logic. Specifically, the realization logic corresponding to the target behavior is obtained according to the analysis to obtain the target behavior identification, the realization logic is executed, the state detection interface is called based on the state detection logic in the realization logic to detect the current state of the target behavior so as to detect whether the target behavior is currently locked or not, and then whether the target behavior is executed or not is determined according to the detection result. And when detecting that the target behavior is in the locking state currently, terminating the execution of the target behavior corresponding to the request.

According to the behavior state processing method in the game, in the running process of the current service module in the game, when the behavior execution request is received, the target behavior identification is obtained through analyzing the behavior execution request, and when the state detection interface is called, the target behavior is determined to be in the locking state corresponding to the conflict with the current service module according to the target behavior identification, the target behavior corresponding to the execution behavior execution request is terminated. And detecting the target behavior state by calling the state detection interface, when the target behavior is in a locked state, indicating that the target behavior conflicts with the current service module, and stopping executing the target behavior, thereby avoiding game faults caused by continuously executing the target behavior and improving the stability and fluency of game operation.

In one embodiment, as shown in fig. 3, when the state detection interface is invoked and it is determined that the target behavior is in the locked state corresponding to the conflict with the current service module according to the target behavior identifier, terminating the target behavior corresponding to the execution behavior execution request includes:

s302, calling a state detection interface to acquire a locking behavior state table.

The locked behavior state table refers to a data table in which the current locked behavior and the related information thereof are recorded. For example, the data table records a behavior identification currently in a locked state. Specifically, based on a preset state detection logic, when the behavior state detection is needed, a state detection interface is called to acquire a locking behavior state table.

S304, when the locking behavior state table comprises the target behavior identification, determining that the target behavior is in a locking state corresponding to the conflict with the current service module.

In this embodiment, the target behavior identifier is compared with the data recorded in the lock behavior state table, and when the lock behavior state table includes the target behavior identifier, it is determined that the target behavior is in the lock state. That is, as long as the target behavior identification is recorded in the lock behavior state table, it is indicated that the target behavior is locked, and execution is not currently permitted.

S306, terminating the target behavior corresponding to the execution behavior execution request.

When the target behavior is determined to be in the locked state, the target behavior is stated to be in conflict with the current service module, in this case, the target behavior is not allowed to be executed, and then the target behavior corresponding to the execution behavior execution request is terminated, so that game faults caused by executing the target behavior in the running process of the current service module are avoided.

Further, the processing method further comprises: when the target behavior identification is not included in the locked behavior state table, determining that the target behavior is in an unlocked state.

Specifically, based on preset state detection logic, when behavior state detection is needed, a state detection interface is called to acquire a locked behavior state table, target behavior identification is compared with data recorded in the behavior state table, and when the locked behavior state table does not comprise the target behavior identification, the target behavior is determined to be in an unlocked state. That is, as long as the target behavior identification is not recorded in the lock behavior state table, it is indicated that the target behavior is not locked, and execution is currently permitted.

In one embodiment, when the target behavior is in the locked state, the processing method further includes: acquiring locking prompt information; and generating display information carrying locking prompt information based on a preset display rule.

The locking prompt information is used for prompting the locking state of the target behavior of the user. For example, when it is determined that the target behavior is in the locked state, a prompt box is popped up on the display interface, and locking prompt information is displayed in the prompt box to prompt the game player that the target behavior is locked and execution is not allowed. In one embodiment, the lock hint information may be a warning hint, such as displaying "target behavior (e.g., map transfer) is locked" on a user's display interface. In another embodiment, the lock hint information may also be a lock status and a lock reason, i.e., a business module identifier that hint the target behavior to be locked and conflict with the target behavior. The preset display rule refers to a preset display method. Specifically, a display manner, a display position, and the like may be included. For example, the display is displayed in the middle of the display interface in the form of a prompt box.

Specifically, when the target behavior is detected to be in the locked state, locking prompt information corresponding to the target behavior is obtained, display information carrying the locking prompt information is generated according to preset display rules, the display information is sent to the terminal, and the terminal displays the locking prompt information on a display interface according to the display information.

Specifically, as shown in fig. 4, there is provided a step of displaying a lock prompt message, including:

s402, acquiring a service module identifier corresponding to the target behavior identifier in the locking behavior state table.

The service module identifier is a mark for identifying the service module. Specifically, the service module identifier may be a preset name or unique code of the service module.

In this embodiment, the lock behavior state table further records a service module identifier for locking the behavior, and specifically, reference may be made to the lock behavior state table shown in fig. 5. In the game process, a plurality of service modules can be operated at the same time, one behavior can be locked by the plurality of service modules, as shown in fig. 5, the locked behavior identification and the service module identification for locking the behavior are stored in a correlated manner, and thus, a locked behavior state table in which behavior state information is cached is obtained.

In this embodiment, when the current state of the target behavior is the locked state, the service module identifier corresponding to the target behavior identifier is obtained based on the correspondence between the target behavior identifier and the service module identifier in the locked behavior state table. In other words, the service module identification of the target locking behavior is obtained.

The obtained service module identifier may be one of the service module identifiers of the locking target behavior, or may be a plurality of service module identifiers, and specific setting may be performed in advance according to the requirement. Meanwhile, which service module identifier is specifically obtained can be set. For example, only the first service module identification of the lock target behavior needs to be obtained.

S404, according to the service module identification, locking prompt information corresponding to the service module identification is obtained.

The locking prompt information corresponding to the service module identifier refers to a locking description of the service module locking target behavior. When a service module locks a behavior, a description of the locking operation is set at the same time, the locking description can be used as a locking prompt message, and the service module is popped up when detecting that the behavior is locked. For example, in one embodiment, map jump behavior may be locked by the team module, which may indicate "currently in team, not transferred to other maps".

In this embodiment, based on the obtained service module identifier, locking prompt information corresponding to the service module identifier is obtained, so as to respond to the current behavior execution request. Specifically, when the obtained service module identifier is only the first service module identifier of the locking target behavior, correspondingly, only the locking prompt information corresponding to the first service module identifier needs to be obtained.

S406, generating display information carrying locking prompt information based on preset display rules.

In this embodiment, when it is determined that the current state of the target behavior is a locked state, a service module identifier for locking the target behavior is further obtained, and locking prompt information for locking the target behavior of the service module is obtained based on the service module identifier, and display information carrying the locking prompt information is generated according to a preset display rule so as to display the locking prompt information.

Further, the processing method further comprises: and sending the display information to the request terminal. And sending the display information to the corresponding request terminal, and displaying the locking prompt information on the display interface by the request terminal according to the display rule so as to remind the game player that the target behavior is locked and cannot be executed.

In one embodiment, as shown in fig. 6, the in-game behavior state processing method further includes a step of targeting behavior, specifically including:

s602, when the operation is performed to a preset locking logic, a service module identifier in the locking logic and a target behavior identifier conflicting with the service module identifier are obtained.

Based on the state conflict to be avoided between the service module and the target behavior, the corresponding locking logic is preset in the service module so as to execute the preset locking logic when the service module runs. For example, if scene jump is not allowed when the game is in a combat state, adding a locking logic of 'scene jump' in the combat module; when a certain role in the role module is executing a certain task, the pop-up request information is not allowed, and then the lock logic of the pop-up request information is added in the realization logic of the role executing the task; when a character in the character module releases skills, and the player is not allowed to perform interactive operation, locking logic of 'interactive operation' is added in the realization logic of the character releasing skills.

Specifically, the locking logic includes a current service module identifier and a target behavior identifier to be locked, that is, a currently running service module identifier and a target behavior identifier conflicting with the currently running service module, and based on analysis of the locking logic, the service module identifier and the target behavior identifier conflicting with the service module are obtained.

S604, calling a state setting interface, and storing the conflict target behavior identification and the business module identification in a locking behavior state table in a related manner.

The state setting interface is an API (Application Programming Interface ) set by a game developer to set the current state of a behavior, and the interface is independent of the logic code of the original service module and has good reusability, so that the state setting of any target behavior can be realized by calling the state setting interface. Wherein the state settings include a locked setting and an unlocked setting. The lock setting means that the target behavior is locked so as not to be allowed to be executed, and the unlock setting means that the locked target behavior is unlocked so as to be allowed to be executed. When the target behavior conflicts with the current service module, the target behavior is locked, and when the locked target behavior does not conflict with the service module locked with the target behavior, the target behavior is unlocked.

After the target behavior identification and the service module identification to be locked are determined, the target behavior identification and the service module identification to be locked which are in conflict are associated by calling a state setting interface and are stored in a locking behavior state table. The locking behavior state table only needs to effectively represent the association relationship between the currently locked target behavior identifier and the service module identifier for executing locking. For example, a storage format as shown in fig. 5 may be employed.

And locking the target behavior by calling a state setting interface, caching the locked information into a locking behavior state table, and detecting the current state of the target behavior by searching the locking behavior state table when a behavior execution request is received, so as to determine whether to allow the target behavior to be executed according to a detection result. By locking the target behaviors which are not allowed to be executed at present, the problem that the locked target behaviors are still executed under the condition that a certain target behavior is not allowed to be executed, so that game faults are caused is avoided, and the stability and fluency of game running are improved.

According to the embodiment, the behavior is locked in a non-invasive programming mode by calling the state setting interface, complex modification of an original game code is not needed, and the interface is independent of a logic code of an original service module, so that maintainability and expandability are high.

Further, the behavior state processing method in the game further comprises the following steps: and acquiring and storing locking prompt information according to preset locking logic. And when the target behavior is detected to be locked by the corresponding service module, returning and displaying the locking prompt information to prompt the player that the target behavior is locked and cannot be executed currently. For example, in one embodiment, map jump behavior may be locked by the team module, and the lock hint may be "currently in team, not able to be transferred to other maps".

In one embodiment, as shown in fig. 7, the method for processing behavior states in a game further includes a step of unlocking a target behavior, and specifically includes:

s702, when the behavior unlocking condition is met, acquiring the service module identification meeting the behavior unlocking condition.

The behavior unlocking condition refers to a condition that the locked behavior is allowed to be executed, and is determined in advance based on the requirement of game running. Such as based on specific traffic boundaries. Taking a combat service module as an example, when the combat service module runs, the role is not allowed to change equipment, and when the combat service module runs to the boundary of the combat service module, the unlocking operation of the role changing equipment is executed. In short, the action of unlocking the character changing equipment at the end of the battle is the action.

Specifically, corresponding unlocking logic is embedded in the service module in advance, and when the service module runs to the preset unlocking logic, the service module identification meeting the behavior unlocking condition is obtained to meet the behavior unlocking condition. It will be appreciated that in this embodiment, the service module identifier refers to the service module identifier currently executing the unlocking logic.

S704, according to preset unlocking logic, the target behavior identification conflicting with the service module identification is obtained.

The unlocking logic comprises a target behavior identifier conflicting with the service module identifier, and the target behavior identifier conflicting with the service module identifier, namely the target behavior identifier to be unlocked currently, is obtained by analyzing the preset unlocking logic.

S706, calling a state setting interface to release the locking relation between the service module identifier and the target behavior identifier conflicting with the service module identifier.

The locking relation refers to the association relation between the target behavior identification locked and the service module identification locked by the behavior identification.

Specifically, after the service module identifier meeting the behavior unlocking condition and the corresponding target behavior identifier are obtained, the locking relationship between the service module identifier and the target behavior identifier conflicting with the service module identifier is relieved through the state setting interface. When all the locking relations of a certain target behavior identification are released, the target behavior corresponding to the target behavior identification is allowed to be executed.

According to the embodiment, the behavior is unlocked by calling the state setting interface in a non-invasive programming mode, complex modification of an original game code is not needed, and maintainability and expandability are high.

In one embodiment, as shown in fig. 8, the step of unlocking the target behavior specifically includes:

s802, when the behavior unlocking condition is met, acquiring a service module identifier meeting the behavior unlocking condition.

S804, according to preset unlocking logic, the target behavior identification conflicting with the service module identification is obtained.

Based on the unlocking logic, the target behavior identification conflicting with the service module identification is obtained, namely the target behavior identification to be unlocked currently.

Further, the method further comprises the step of calling a state setting interface to release the locking relation between the service module identifier and the target behavior identifier conflicting with the service module identifier, and the step specifically comprises the following steps:

S806, calling a state setting interface to acquire a locking behavior state table.

The locking behavior state table is stored with a target behavior identifier in a locking state in an associated mode, and a service module identifier for locking the target behavior. And when the behavior unlocking condition is met, calling a state setting interface based on preset unlocking logic, and acquiring a cached locking behavior state table.

S808, deleting the service module identification stored in association with the target behavior identification conflicting with the service module identification from the locking behavior state table.

When the behavior unlocking condition is met, based on preset unlocking logic, acquiring a target behavior identifier and a service module identifier to be unlocked, which meet the behavior unlocking condition, further calling a state setting interface, acquiring a locking behavior state table, and deleting the target behavior identifier and the service module identifier to be unlocked, which are stored in a related manner, from the locking behavior state table.

Specifically, in the lock behavior state table, when the service module identifiers associated with the target behavior identifiers to be unlocked are plural, the service module identifiers associated with the target behavior identifiers to be unlocked and satisfying the unlocking condition are deleted from the lock behavior state table. And when the service module identifier associated with the target behavior identifier to be unlocked is one, deleting the target behavior identifier to be unlocked and the service module identifier associated with the target behavior identifier from the locking behavior state table.

In one embodiment, as shown in fig. 9, the method for processing behavior states in a game further includes:

s902, acquiring a behavior execution request received in the running process of a current service module in the game.

And in the running process of the current business module in the game, when a behavior execution request is received, acquiring the behavior execution request so as to respond to the behavior execution request. In particular, the behavioral execution request may be initiated by a game player or other business module. For example, the current game is in a battle state, at this time, a game player initiates a scene jump request through a touch screen of the terminal, and the server receives the initiated scene jump request to perform a subsequent response operation.

S904, analyzing the behavior execution request to obtain the target behavior identification.

When a behavior execution request is received, the behavior execution request is acquired, and the request is analyzed to obtain a target behavior identifier corresponding to the request. Further, based on the obtained target behavior identification, the realization logic for executing the target behavior is obtained to execute the subsequent operation. Wherein the implementation logic is a specific implementation code.

S906, when the state detection interface is called and the target behavior is determined to be in an unlocked state according to the target behavior identification, executing the target behavior corresponding to the request.

Specifically, the state detection interface is called to detect the current state of the target behavior identification, and when the target behavior is determined to be in an unlocked state according to the target behavior identification, the target behavior corresponding to the behavior execution request is executed.

Further, a state detection logic is embedded in the realization logic of the game behavior, so that the state detection of the behavior which needs to be executed currently is performed through the state detection logic. Specifically, the corresponding realization logic is obtained according to the analysis to obtain the target behavior identification, the realization logic is executed, the state detection interface is called based on the state detection logic in the realization logic to detect the current state of the target behavior, when the target behavior is detected to be in the non-locking state, the condition that the target behavior conflicts with the target behavior does not exist currently is indicated, the target behavior is allowed to be executed, and then the target behavior is executed according to the realization logic of the target behavior.

The method for processing behavior states in the game of the present application will be described below with reference to an example in which scene jumps are not allowed during combat. The fight module is provided with scene jump locking logic and scene jump unlocking logic in advance, and the jump logic of the scene module is provided with state detection logic in advance. As shown in fig. 10, the method comprises the following steps:

S1001, when the operation is performed to a preset locking logic, a service module identifier in the locking logic and a target behavior identifier conflicting with the service module identifier are obtained.

Specifically, the locking logic includes a current service module identifier and a target behavior identifier to be locked, that is, a currently running service module identifier and a target behavior identifier conflicting with the currently running service module, and the target behavior identifier conflicting with the service module is obtained based on analysis of the locking logic. In this embodiment, the target behavior is identified as "scene hop".

S1002, calling a state setting interface, and storing the conflict target behavior identification and the business module identification in a locking behavior state table in a related manner.

After the behavior identification 'scene jump' to be locked and the business module identification 'fight module' are acquired, the scene jump 'and the fight module' are associated through a state setting interface and stored into a locking behavior state table. The locking behavior state table only needs to effectively represent the association relationship between the currently locked target behavior identifier and the service module identifier for executing locking. For example, a storage format as shown in fig. 5 may be employed.

S1003, obtaining a behavior execution request received in the running process of the current service module in the game.

In this implementation, the current service module may be a currently running combat module, or other service modules running simultaneously with the combat module, and the received behavior execution request is a "scene jump" execution request.

S1004, analyzing the behavior execution request to obtain the target behavior identification.

When receiving the execution request of 'scene jump', acquiring the execution request of the behavior, and analyzing the request to obtain a target behavior identification 'scene jump' corresponding to the request. Further, the jump logic of the map module is obtained, and whether to execute map jump is determined based on the detection result of the state detection logic in the jump logic.

S1005, calling a state detection interface to acquire a locking behavior state table.

The locked behavior state table refers to a data table in which the currently locked target behavior and the related information thereof are recorded. For example, the data table records the target behavior identification currently in the locked state. In this implementation, the lock behavior state table records the "scene hop" behavior identification, and the "fight module" identification that locks the "scene hop".

S1006, when the locking behavior state table comprises the target behavior identification, determining that the target behavior is in the locking state corresponding to the conflict with the current service module.

Specifically, the target behavior identification is compared with the data recorded in the locking behavior state table, and when the target behavior identification is included in the behavior state table, the target behavior is determined to be in the locking state. That is, as long as the target behavior identification is recorded in the lock behavior state table, it is indicated that the target behavior is locked, and execution is not currently permitted.

For example, the "scene jump" behavior identifier is compared with the data recorded in the lock behavior state table, and when the lock behavior state table includes the "scene jump" behavior identifier, it is determined that the "scene jump" behavior is in the lock state.

S1007, the target behavior corresponding to the execution behavior execution request is terminated.

For example, in the present embodiment, the current state of the "scene jump" behavior is detected as the lock state, and at this time, execution of the "scene jump" behavior is terminated.

S1008, obtaining a service module identifier corresponding to the target behavior identifier in the locking behavior state table.

The obtained service module identifier may be one of the service module identifiers of the locking target behavior, or may be a plurality of service module identifiers, and specific setting may be performed in advance according to the requirement. Meanwhile, which service module identifier is specifically obtained can be set. For example, only the first service module identification of the lock target behavior needs to be obtained. Assuming that the first business module of the lock action state table locks the "scene jump" action is the "fight module", the "fight module" mark is obtained at this time.

S1009, according to the service module identification, obtaining the locking prompt information corresponding to the service module identification.

The locking prompt information corresponding to the service module identifier refers to a locking description of the service module locking target behavior. When a behavior is locked, the service module can set a description of the locking operation at the same time, the locking description can be used as a locking prompt message, and the locking prompt message is popped up and displayed when the behavior is detected to be locked. As shown in fig. 11, a prompt message of the fight module locking scene skip behavior, specifically, "currently fight, cannot skip scene" is preset.

S1010, generating display information carrying the locking prompt information based on a preset display rule.

S1011, the display information is transmitted to the requesting terminal.

When the current state of the target behavior is determined to be a locking state, further acquiring a service module identifier for locking the target behavior, acquiring locking prompt information of the service module for locking the target behavior based on the service module identifier, generating display information carrying the locking prompt information according to a preset display rule, and sending the display information to a request terminal. The request terminal displays the locking prompt information on a display interface according to the display rule so as to remind the game player that the target behavior is locked and cannot be executed. As shown in fig. 11, a lock instruction message "currently in battle, unable to jump to scene" is displayed on the display interface. S1012, when the behavior unlocking condition is met, acquiring the service module identification meeting the behavior unlocking condition.

Specifically, corresponding unlocking logic is embedded in the service module in advance, and when the service module runs to the preset unlocking logic, the service module identification meeting the behavior unlocking condition is obtained to meet the behavior unlocking condition. It will be appreciated that in this embodiment, the service module identifier refers to the service module identifier currently executing the unlocking logic. Still taking a fight module as an example, when the fight module runs to the boundary of the fight module, the behavior unlocking condition is satisfied, and at this time, the 'fight module' identifier satisfying the behavior unlocking condition is obtained.

S1013, according to preset unlocking logic, the target behavior identification conflicting with the service module identification is obtained.

Based on the unlocking logic, the target behavior identification conflicting with the service module identification is obtained, namely the target behavior identification to be unlocked currently. It will be appreciated that in this embodiment, the target behavior identification that conflicts with the "fight module" when running to the fight module boundary includes a "scene hop" behavior identification.

S1014, calling a state setting interface to acquire a locking behavior state table.

The locking behavior state table is stored with a target behavior identifier in a locking state in an associated mode, and a service module identifier for locking the target behavior. And when the behavior unlocking condition is met, calling a state setting interface based on preset unlocking logic to acquire a locking behavior state table.

S1015, deleting the service module identification stored in association with the target behavior identification conflicting with the service module identification from the locking behavior state table.

When the behavior unlocking condition is met, based on preset unlocking logic, acquiring a target behavior identifier and a service module identifier to be unlocked, which meet the behavior unlocking condition, and further calling a state setting interface to acquire a locking behavior state table, and deleting the target behavior identifier and the service module identifier to be unlocked, which are stored in a related manner, from the locking behavior state table.

Specifically, when the service module currently locking the "scene jump" behavior only comprises a "fight module", deleting the "scene jump" behavior identifier in the behavior state table and the associated "fight module" identifier thereof; when the service module currently locking the scene jump behavior also comprises other service modules except the fight module, deleting the fight module identifier associated with the scene jump behavior identifier in the locking behavior state table.

Further, the behavior state processing method in the game further comprises the following steps:

s1016, when the target behavior identification is not included in the locking behavior state table, determining that the target behavior is in an unlocking state.

In this embodiment, based on preset state detection logic, when behavior state detection is required, a state detection interface is called to obtain a behavior state table, the target behavior identifier is compared with data recorded in a locked behavior state table, and when the behavior state table does not include the target behavior identifier, it is determined that the target behavior is in an unlocked state. That is, as long as the target behavior identification is not recorded in the lock behavior state table, it is indicated that the target behavior is not locked, and execution is currently permitted.

S1017, executing the target behavior corresponding to the request.

When the current state of the target behavior is an unlocked state, the condition that the conflict with the target behavior does not exist currently is indicated, the target behavior is allowed to be executed, and then the target behavior is executed according to the realization logic of the target behavior.

According to the behavior state processing method in the game, the target behavior is locked and/or unlocked by calling the state setting interface, the state detection interface is further called to detect the current state of the target behavior when a behavior execution request is received, and execution of the target behavior is terminated when the current state of the target behavior is detected to be the locked state. And detecting the target behavior state by calling the state detection interface, when the target behavior is in a locked state, indicating that the target behavior conflicts with the current service module, and stopping executing the target behavior, thereby avoiding game faults caused by continuously executing the target behavior and improving the stability and fluency of game operation. And the detection and the setting of the behavior state are realized by calling the state detection interface and the state setting interface in a non-invasive programming mode, complex modification of the original game code is not needed, and the logic code of the original service module is not relied on, so that the maintainability and the expandability of the game are further improved.

FIG. 10 is a flow chart of a method of behavior state processing in a game in one embodiment. It should be understood that, although the steps in the flowchart of fig. 10 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in fig. 10 may include multiple sub-steps or stages that are not necessarily performed at the same time, but may be performed at different times, or the order in which the sub-steps or stages are performed is not necessarily sequential, but may be performed in rotation or alternatively with at least a portion of the sub-steps or stages of other steps or steps.

In one embodiment, as shown in fig. 12, there is provided an in-game behavior state processing device, the device comprising: a request module 1202, a parse module 1204, and an execute module 1206.

The request module 1202 is configured to obtain a behavior execution request received during a running process of a current service module in the game.

During the running of the current business module in the game, when a behavior execution request is received, the request module 1202 obtains the behavior execution request so as to respond to the behavior execution request. In particular, the behavioral execution request may be initiated by a game player or other business module. For example, when the current game is in a combat state, a game player initiates a scene jump request through a touch screen of the terminal, and the server receives the initiated scene jump request to execute subsequent response operations, wherein the response operations specifically can include obtaining scene jump logic to judge whether to execute scene jump; for another example, when a role is executing a set task, the prop module initiates a prompt request about whether to purchase a new prop, the server receives the prompt request, and responds to the request, where the responding operation specifically may include obtaining the prompt implementation logic, and determining whether the prompt is possible.

And the parsing module 1204 is used for parsing the behavior execution request to obtain the target behavior identification.

When a behavior execution request is received, the behavior execution request is acquired, and the request is analyzed through an analysis module 1204, so as to obtain a target behavior identifier corresponding to the request. Further, based on the obtained target behavior identification, the realization logic for executing the target behavior is obtained to execute the subsequent operation. Wherein the implementation logic is specific implementation code.

The execution module 1206 is configured to terminate the target behavior corresponding to the execution behavior execution request when the state detection interface is invoked and the target behavior is determined to be in the locked state corresponding to the conflict with the current service module according to the target behavior identifier.

Specifically, the execution module 1206 invokes the state detection interface to detect the current state of the target behavior identifier, and terminates the target behavior corresponding to the execution behavior execution request when it is determined that the target behavior is in the locked state corresponding to the conflict with the current service module according to the target behavior identifier. For example, when the game is in a combat state, scene hopping is not allowed, when an initiated scene hopping request is received, the current state of scene hopping behavior is detected, and when the current state of scene hopping behavior is a locked state, execution of scene hopping is terminated.

Further, a state detection logic is embedded in the realization logic of the game behavior, so that the state detection of the behavior which needs to be executed currently is performed through the state detection logic. Specifically, the execution module 1206 obtains the implementation logic corresponding to the target behavior according to the analysis to obtain the target behavior identifier, executes the implementation logic, and based on the state detection logic in the implementation logic, invokes the state detection interface to detect the current state of the target behavior, so as to detect whether the target behavior is currently locked, and further determines whether to execute the target behavior according to the detection result. And refusing to execute the target behavior corresponding to the request when detecting that the target behavior is currently in the locked state.

In the running process of the current service module in the game, the behavior state processing device in the game obtains the target behavior identification through analyzing the behavior execution request when the behavior execution request is received, and terminates the target behavior corresponding to the execution behavior execution request when the state detection interface is called and the target behavior is determined to be in the locking state corresponding to the conflict with the current service module according to the target behavior identification. And detecting the target behavior state by calling the state detection interface, when the target behavior is in a locked state, indicating that the target behavior conflicts with the current service module, and stopping executing the target behavior, thereby avoiding game faults caused by continuously executing the target behavior and improving the stability and fluency of game operation.

In an embodiment, the execution module 1206 is further configured to execute the target behavior corresponding to the request when the state detection interface is invoked and the target behavior is determined to be in the unlocked state according to the target behavior identifier.

Specifically, the execution module 1206 obtains the corresponding implementation logic according to the target behavior identifier obtained by parsing, executes the implementation logic, invokes the state detection interface based on the state detection logic in the implementation logic, and detects the current state of the target behavior, so as to indicate that the situation of conflict with the target behavior does not exist currently when the target behavior is detected to be in the unlocked state, and then the target behavior is allowed to be executed, so that the target behavior is executed according to the implementation logic of the target behavior.

In one embodiment, as shown in fig. 13, the execution module 1206 further includes: the state detection interface invokes module 1302, state determination module 1304, and execution submodule 1306.

The state detection interface calling module 1302 is configured to call the state detection interface to obtain a lock behavior state table.

The locked behavior state table refers to a data table in which the current locked behavior and the related information thereof are recorded. For example, the data table records a behavior identification currently in a locked state. The state detection interface is invoked by the state detection interface invocation module 1302 to obtain a lock behavior state table.

The state determining module 1304 is configured to determine that the target behavior is in a locked state corresponding to a conflict with the current service module when the target behavior identifier is included in the locked behavior state table.

In this embodiment, the state determination module 1304 compares the target behavior identifier with the data recorded in the lock behavior state table, and determines that the target behavior is in the lock state when the lock behavior state table includes the target behavior identifier. That is, as long as the target behavior identification is recorded in the lock behavior state table, it is indicated that the target behavior is locked, and execution is not currently permitted.

Further, the state determining module 1304 is further configured to determine that the target behavior is in an unlocked state when the target behavior identifier is not included in the locked behavior state table.

The execution submodule 1306 is configured to terminate a target behavior corresponding to the execution behavior execution request.

When the target behavior is determined to be in the locked state, the target behavior is stated to be in conflict with the current business module, and in this case, the target behavior is not allowed to be executed. Thus, the execution submodule 1306 terminates the target behavior corresponding to the execution behavior execution request, so as to avoid game faults caused by executing the target behavior in the running process of the current business module.

In an embodiment, the in-game behavior state processing device further includes a locking prompt module, where the locking prompt module is configured to obtain the locking prompt information, and generate display information carrying the locking prompt information based on a preset display rule. For example, the preset display rule is to display locking prompt information in the prompt box, and when it is determined that the target behavior is in a locked state, the display information carrying the locking prompt information is generated by the locking prompt module according to the preset display rule so as to pop up the prompt box on the display interface of the request terminal, and the locking prompt information is displayed in the prompt box so as to prompt the game player that the target behavior is locked and not allowed to be executed. In one embodiment, the lock hint information may be a warning hint, such as displaying "target behavior (e.g., map transfer) is locked" on a user's display interface. In another embodiment, the lock prompt information may also be a lock state and a lock reason, that is, a business module that prompts the target behavior to be locked and conflict with the target behavior.

In one embodiment, the lock hint module includes: the system comprises a state table searching module, a prompt information acquiring module and a display information generating module, wherein:

and the state table searching module is used for acquiring the service module identifier corresponding to the target behavior identifier in the locking behavior state table.

In this embodiment, when the current state of the target behavior is the locked state, the state table lookup module obtains the service module identifier corresponding to the target behavior identifier based on the correspondence between the target behavior identifier and the service module identifier in the locked behavior state table. In other words, the service module identification of the target locking behavior is obtained.

And the prompt information acquisition module is used for acquiring locking prompt information corresponding to the service module identifier according to the service module identifier. The locking prompt information corresponding to the service module identifier refers to a locking description of the service module locking target behavior.

And the display information generation module is used for generating display information carrying the locking prompt information based on a preset display rule.

When the current state of the target behavior is determined to be the locking state, further acquiring a service module identifier for locking the target behavior, acquiring locking prompt information of the service module for locking the target behavior based on the service module identifier, and generating display information carrying the locking prompt information according to a preset display rule so as to display the locking prompt information.

Further, the display information generating module is further configured to send the display information to the requesting terminal. The display information is sent to the corresponding request terminal, and the request terminal displays the locking prompt information on the display interface according to the display rule so as to remind the game player that the target behavior is locked and cannot be executed.

In one embodiment, the in-game behavior state processing device further includes: the locking identification acquisition module and the locking module.

The locking identification acquisition module is used for acquiring a service module identification in the locking logic and a target behavior identification conflicting with the service module identification when the locking logic is operated to a preset locking logic.

Based on the state conflict to be avoided between the service module and the target behavior, the corresponding locking logic is preset in the service module so as to execute the preset locking logic when the service module runs. For example, if scene jumps are not allowed while the game is in a combat state, then "scene jump" lock logic is added to the combat module.

Specifically, the locking logic includes a current service module identifier and a target behavior identifier to be locked, that is, a currently running service module identifier and a target behavior identifier conflicting with the currently running service module, and the locking identifier acquisition module acquires the service module identifier and the target behavior identifier conflicting with the service module based on analysis of the locking logic.

And the locking module is used for calling the state setting interface and storing the conflict target behavior identification and the business module identification in a locking behavior state table in a correlated mode.

After determining the target behavior identifier and the service module identifier to be locked, the locking module 1306 invokes a state setting interface, associates the target behavior identifier and the service module identifier to be locked, which are in conflict, and stores the target behavior identifier and the service module identifier in a locking behavior state table. The locking behavior state table only needs to effectively represent the association relationship between the currently locked target behavior identifier and the service module identifier for executing locking. For example, a storage format as shown in fig. 5 may be employed.

In one embodiment, as shown in fig. 14, the in-game behavior state processing device further includes: the business module identification acquisition module 1402, the target behavior identification acquisition module 1404, and the unlocking module 1406.

The service module identifier obtaining module 1402 is configured to obtain, when the behavior unlocking condition is satisfied, a service module identifier that satisfies the behavior unlocking condition.

Specifically, the corresponding unlocking logic is preset in the service module, and when the service module runs to the preset unlocking logic, the service module identifier obtaining module 1402 obtains the service module identifier meeting the behavior unlocking condition to meet the behavior unlocking condition. It will be appreciated that in this embodiment, the service module identifier refers to the service module identifier currently executing the unlocking logic.

The target behavior identification obtaining module 1404 is configured to obtain, according to a preset unlocking logic, a target behavior identification that conflicts with the service module identification.

The unlocking logic includes a target behavior identifier that conflicts with the service module identifier, and the target behavior identifier obtaining module 1404 analyzes a preset unlocking logic to obtain a target behavior identifier that conflicts with the service module identifier, that is, a target behavior identifier to be unlocked currently.

And the unlocking module 1406 is used for calling the state setting interface and releasing the locking relation between the service module identifier and the target behavior identifier conflicting with the service module identifier.

Specifically, after the service module identifier and the corresponding target behavior identifier that meet the behavior unlocking condition are obtained, the unlocking module 1406 releases the locking relationship between the service module identifier and the target behavior identifier that conflicts with the service module identifier through the state setting interface. When all the locking relations of a certain target behavior identification are released, the target behavior corresponding to the target behavior identification is allowed to be executed.

Further, the unlocking module 1406 also includes: the state setting interface calling module and the deleting module. The method comprises the steps of calling a state setting interface, wherein the state setting interface is used for acquiring a locking behavior state table; and the deleting module is used for deleting the service module identifier stored in a correlated mode and the target behavior identifier conflicting with the service module identifier from the locking behavior state table.

When the behavior unlocking condition is met, after the target behavior identifier and the service module identifier to be unlocked which meet the behavior unlocking condition are obtained, a state setting interface is called by a state setting interface calling module to obtain a locking behavior state table, and a deleting module deletes the target behavior identifier and the service module identifier to be unlocked which are stored in a related mode from the locking behavior state table.

Specifically, in the lock behavior state table, when the service module identifiers associated with the target behavior identifiers to be unlocked are plural, the deletion module deletes the service module identifier associated with the target behavior identifiers to be unlocked and satisfying the unlocking condition from the lock behavior state table. When the service module identifier associated with the target behavior identifier to be unlocked is one, the deleting module deletes the target behavior identifier to be unlocked and the associated service module identifier from the locking behavior state table.

According to the behavior state processing device in the game, the target behavior is locked and/or unlocked by calling the state setting interface, when a behavior execution request is received, the state detection interface is called to detect the current state of the target behavior, and when the current state of the target behavior is detected to be the locked state, execution of the target behavior is terminated. And detecting the target behavior state by calling the state detection interface, when the target behavior is in a locked state, indicating that the target behavior conflicts with the current service module, and stopping executing the target behavior, thereby avoiding game faults caused by continuously executing the target behavior and improving the stability and fluency of game operation. And the detection and the setting of the behavior state are realized by calling the state detection interface and the state setting interface in a non-invasive programming mode, complex modification of the original game code is not needed, and the logic code of the original service module is not relied on, so that the maintainability and the expandability of the game are further improved.

FIG. 15 illustrates an internal block diagram of a computer device in one embodiment. The computer device may be specifically the server 120 of fig. 1. As shown in fig. 15, the computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Wherein the processor is configured to provide computing and control capabilities. The memory includes a nonvolatile storage medium and an internal memory. The non-volatile storage medium of the computer device stores an operating system, and may also store a computer program that, when executed by a processor, causes the processor to implement a method for processing behavior states in a game. The internal memory may also store a computer program that, when executed by the processor, causes the processor to perform the method for processing behavior states in a game. The database of the computer device is used to store game data. The network interface of the computer device is used for communicating with an external terminal through a network connection.

It will be appreciated by those skilled in the art that the structure shown in fig. 15 is merely a block diagram of a portion of the structure associated with the present application and is not limiting of the computer device to which the present application is applied, and that a particular computer device may include more or fewer components than shown, or may combine certain components, or have a different arrangement of components.

In one embodiment, the in-game behavior state processing apparatus provided in the present application may be implemented in the form of a computer program, which may be executed on a computer device as shown in fig. 15. The memory of the computer device may store various program modules that make up the in-game behavior state processing means, such as the request module 1202, the parse module 1204, and the execute module 1206 shown in fig. 12. The computer program constituted by the respective program modules causes the processor to execute the steps in the in-game behavior state processing method of the respective embodiments of the present application described in the present specification.

In one embodiment, a computer device is provided comprising a memory and a processor, the memory having stored therein a computer program, the processor when executing the computer program performing the steps of:

when the state detection interface is called, and the target behavior is determined to be in a locking state corresponding to the conflict of the current service module according to the target behavior identification, terminating the target behavior corresponding to the execution behavior execution request.

In one embodiment, the processor when executing the computer program further performs the steps of:

calling a state detection interface to acquire a locking behavior state table;

when the locking behavior state table comprises a target behavior identifier, determining that the target behavior is in a locking state corresponding to the conflict of the target behavior and the current service module;

and terminating the target behavior corresponding to the execution behavior execution request.

when the target behavior identification is not included in the locked behavior state table, determining that the target behavior is in an unlocked state.

acquiring locking prompt information;

and generating display information carrying locking prompt information based on a preset display rule.

acquiring a service module identifier corresponding to a target behavior identifier in a locking behavior state table;

and acquiring locking prompt information corresponding to the service module identifier according to the service module identifier.

When the operation is performed to a preset locking logic, a service module identifier in the locking logic and a target behavior identifier conflicting with the service module identifier are obtained;

and calling a state setting interface, and storing the conflict target behavior identification and the business module identification in a locking behavior state table in a related manner.

when the behavior unlocking condition is met, acquiring a service module identifier meeting the behavior unlocking condition;

according to preset unlocking logic, a target behavior identification conflicting with the service module identification is obtained;

and calling a state setting interface to release the locking relation between the service module identifier and the target behavior identifier conflicting with the service module identifier.

calling a state setting interface to acquire a locking behavior state table;

and deleting the service module identifier stored in association with the target behavior identifier which conflicts with the service module identifier from the locking behavior state table.

when the state detection interface is called and the target behavior is determined to be in an unlocked state according to the target behavior identification, the target behavior corresponding to the request is executed.

In one embodiment, a computer readable storage medium is provided having a computer program stored thereon, which when executed by a processor, performs the steps of:

In one embodiment, the computer program when executed by the processor further performs the steps of:

calling a state detection interface to acquire a locking behavior state table;

Acquiring locking prompt information;

calling a state setting interface to acquire a locking behavior state table;

Those skilled in the art will appreciate that all or part of the processes in the methods of the above embodiments may be implemented by a computer program for instructing relevant hardware, where the program may be stored in a non-volatile computer readable storage medium, and where the program, when executed, may include processes in the embodiments of the methods described above. Any reference to memory, storage, or other medium used in the various embodiments provided herein can include non-volatile and/or volatile memory. The nonvolatile memory can include Read Only Memory (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), memory bus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), among others.

The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.

The above examples only represent a few embodiments of the present application, which are described in more detail and are not to be construed as limiting the scope of the present application. It should be noted that it would be apparent to those skilled in the art that various modifications and improvements could be made without departing from the spirit of the present application, which would be within the scope of the present application. Accordingly, the scope of protection of the present application is to be determined by the claims appended hereto.

Claims

1. A method for processing behavior states in a game, the method comprising:

acquiring a behavior execution request received in the running process of a current service module in a game; the current service module comprises one or more currently running service modules; the service module refers to a logic code based on service function division in the game development process; the business module comprises a combat module, a map module, a knapsack module and a role module;

calling a state detection interface to acquire a locking behavior state table; the locking behavior state table is used for recording behavior identifiers of behaviors in a locking state and service module identifiers for locking the behaviors; the behavior refers to an operation which can be realized in the game running process; the behavior comprises scene jump, equipment replacement and active attack;

when the locking behavior state table comprises the target behavior identifier and the service module identifier for locking the target behavior represented by the target behavior identifier comprises the service module identifier of the current service module, determining that the target behavior is in a locking state corresponding to the conflict with the current service module;

terminating execution of the target behavior corresponding to the behavior execution request;

according to preset unlocking logic, a target behavior identifier conflicting with the service module identifier is obtained;

and calling a state setting interface to remove the locking relation between the service module identifier and the target behavior identifier conflicting with the service module identifier.

2. The method according to claim 1, wherein the method further comprises:

and when the target behavior identification is not included in the locking behavior state table, determining that the target behavior is in an unlocking state.

3. The method according to claim 1, wherein the method further comprises:

acquiring locking prompt information;

and generating display information carrying the locking prompt information based on a preset display rule.

4. The method of claim 3, wherein the obtaining the lock hint information comprises:

acquiring a service module identifier corresponding to the target behavior identifier in a locking behavior state table;

5. The method according to claim 1, wherein the method further comprises:

and calling a state setting interface, and storing the conflicting target behavior identification and the business module identification in a locking behavior state table in a correlated way.

6. The method of claim 1, wherein the invoking the state settings interface to release the locked relationship between the service module identification and the target behavior identification that conflicts with the service module identification comprises:

calling a state setting interface to acquire the locking behavior state table;

and deleting the service module identifier stored in an associated mode and the target behavior identifier conflicting with the service module identifier from the locking behavior state table.

7. The method according to any one of claims 1 to 6, further comprising:

and when the state detection interface is called and the target behavior is in the non-locking state according to the target behavior identification, executing the target behavior corresponding to the request.

8. An in-game behavior state processing apparatus, characterized by comprising:

the request module is used for acquiring a behavior execution request received in the running process of the current service module in the game; the current service module comprises one or more currently running service modules; the service module refers to a logic code based on service function division in the game development process; the business module comprises a combat module, a map module, a knapsack module and a role module;

the state detection interface calling module is used for calling the state detection interface to acquire a locking behavior state table; the locking behavior state table is used for recording behavior identifiers of behaviors in a locking state and service module identifiers for locking the behaviors; the behavior refers to an operation which can be realized in the game running process; the behavior comprises scene jump, equipment replacement and active attack;

the state determining module is used for determining that the target behavior is in a locking state corresponding to the conflict of the current service module when the target behavior identifier is included in the locking behavior state table and the service module identifier for locking the target behavior represented by the target behavior identifier includes the service module identifier of the current service module;

the execution sub-module is used for terminating execution of the target behavior corresponding to the behavior execution request;

the service module identification acquisition module is used for acquiring service module identifications meeting the behavior unlocking conditions when the behavior unlocking conditions are met;

the target behavior identification acquisition module is used for acquiring a target behavior identification conflicting with the service module identification according to preset unlocking logic;

And the unlocking module is used for calling the state setting interface and releasing the locking relation between the service module identifier and the target behavior identifier conflicting with the service module identifier.

9. The apparatus of claim 8, wherein the state determination module is further configured to determine that a target behavior is in an unlocked state when the target behavior identification is not included in the locked behavior state table.

10. The apparatus of claim 8, wherein the apparatus further comprises:

the locking prompt module is used for acquiring the locking prompt information and generating display information carrying the locking prompt information based on preset display rules.

11. The apparatus of claim 10, wherein the lock hint module comprises:

the state table searching module is used for acquiring a service module identifier corresponding to the target behavior identifier in the locking behavior state table;

and the prompt information acquisition module is used for acquiring locking prompt information corresponding to the service module identifier according to the service module identifier.

12. The apparatus of claim 8, wherein the apparatus further comprises:

the locking identification acquisition module is used for acquiring a service module identification in the locking logic and a target behavior identification conflicting with the service module when the locking logic is operated to a preset locking logic;

And the locking module is used for calling a state setting interface and storing the conflicting target behavior identification and the business module identification in a locking behavior state table in a correlated way.

13. The apparatus of claim 8, wherein the unlocking module comprises:

the state setting interface calling module is used for calling a state setting interface and acquiring the locking behavior state table;

and the deleting module is used for deleting the service module identifier stored in a correlated manner and the target behavior identifier conflicting with the service module identifier from the locking behavior state table.

14. The apparatus according to any one of claims 8 to 13, wherein the execution sub-module is further configured to execute the target behavior corresponding to the request when the target behavior is determined to be in the unlocked state according to the target behavior identification by calling a state detection interface.

15. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor implements the steps of the method of any of claims 1 to 7 when the computer program is executed.

16. A computer readable storage medium storing a computer program, characterized in that the computer program when executed by a processor implements the steps of the method according to any one of claims 1 to 7.