Game state control method, equipment, device and system and storage medium

Abstract

The embodiment of the invention provides a game state control method, equipment, device and system and a storage medium. In the embodiment of the invention, under the condition that a game role is expected to enter a target state, a game client and a game server can determine whether to enter the target state or not according to the relationship between the identifier of the existing state of the game client and the identifier of the target state; whether the game role is allowed to enter the target state or not can be determined by combining judgment results of the two parties. On the basis, the game state control method and the game state control device can support that asymmetric game states exist in the game client and the game server, and can accurately control the game state under the condition that the game states of the game client and the game server are asymmetric.

Description

[0001] The patent application for this invention is filed on June 18, 2020, with application number 202010561574.1 and name Divisional application for the Chinese invention patent application for "A game state control method, device, apparatus, system and storage medium". Technical Field

[0002] The present application relates to the field of data processing technology, and in particular to a game state control method, device, apparatus, system and storage medium. Background Art

[0003] In the game world, game characters have various game states such as walking, squatting, jumping, climbing, pushing boxes, skateboarding, etc.

[0004] Currently, the game server usually manages the game state in the game. However, this management method is not accurate enough, and the game client often fails to enter certain game states normally, which seriously affects the game experience. Summary of the invention

[0005] Multiple aspects of the present application provide a game state control method, device, apparatus, system and storage medium to improve the control accuracy of the game state.

[0006] The embodiment of the present application provides a game state control method, which is applied to a first game processing terminal, including:

[0007] Receiving a request for entering a game state, wherein the request for entering a game state includes an identifier of a state to be entered;

[0008] When it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition, providing the identifier of the state to be entered to the second game processing terminal;

[0009] When the second game processing end determines that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing end meets the second preset condition, the game character is controlled to enter the state to be entered.

[0010] The embodiment of the present application also provides a game state control method, which is applied to a second game processing terminal, comprising:

[0011] Receiving a state check request sent by the first game processing end, the state check request including an identifier of a state to be entered that the first game processing end determines to be allowed to enter the game character according to its existing state;

[0012] Determine the relationship between the identifier of the state to be entered and the identifier of the local existing state;

[0013] If the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the preset condition, a notification of allowing entry into the state is sent to the first game processing end so that the first game processing end can control the game character to enter the state to be entered.

[0014] The present application also provides a game state control device, including:

[0015] A receiving module, used for receiving a request for entering a game state, wherein the request for entering a game state includes an identifier of a state to be entered;

[0016] A processing module, configured to provide the identifier of the state to be entered to the second game processing terminal when it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets a first preset condition;

[0017] The control module is used to control the game character to enter the state to be entered when the second game processing end determines that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing end meets the second preset condition.

[0018] The embodiment of the present application also provides a computing device, including a memory, a processor, and a communication component;

[0019] The memory is used to store one or more computer instructions;

[0020] The processor is coupled to the memory and the communication component and is configured to execute the one or more computer instructions for:

[0021] Receiving a request for entering a game state, wherein the request for entering a game state includes an identifier of a state to be entered;

[0022] When it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition, providing the identifier of the state to be entered to the second game processing terminal through the communication component;

[0023] When the second game processing end determines that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing end meets the second preset condition, the game character is controlled to enter the state to be entered.

[0024] The present application also provides a game state control device, including:

[0025] A receiving module, configured to receive a state check request sent by the first game processing end, wherein the state check request includes an identifier of a state to be entered that the first game processing end determines to be allowed to enter the game character according to its existing state;

[0026] A processing module, used for determining the relationship between the identifier of the state to be entered and the identifier of the local existing state;

[0027] The sending module is used to send a notification of allowing entry to the first game processing end if the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the preset condition, so that the first game processing end can control the game character to enter the state to be entered.

[0028] The embodiment of the present application also provides a computing device, including a memory, a processor, and a communication component;

[0029] The memory is used to store one or more computer instructions;

[0030] The processor is coupled to the memory and the communication component and is configured to execute the one or more computer instructions for:

[0031] Receiving a state check request sent by the first game processing end, the state check request including an identifier of a state to be entered that the first game processing end determines to be allowed to enter the game character according to its existing state;

[0032] Determine the relationship between the identifier of the state to be entered and the identifier of the local existing state;

[0033] If the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the preset condition, a notification of allowing entry into the state is sent to the first game processing end so that the first game processing end can control the game character to enter the state to be entered.

[0034] The embodiment of the present application also provides a game state control system, including a first game processing end and a second game processing end that are communicatively connected;

[0035] The first game processing end is used to receive a request to enter a game state, wherein the request to enter a game state includes an identifier of a state to be entered; when it is determined that the relationship between the identifier of the state to be entered and the identifier of the existing state in the first game processing meets a first preset condition, the identifier of the state to be entered is provided to the second game processing end; if a notification of allowing the state to be entered is received from the second game processing end, the game character is controlled to enter the state to be entered;

[0036] The second game processing end is used to return a message allowing entry to the first game processing end when it is determined that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing end meets a second preset condition.

[0037] An embodiment of the present application also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the aforementioned game state control method.

[0038] In the embodiment of the present application, when the game character is expected to enter the target state, the game client and the game server can determine whether to allow the game character to enter the target state based on the relationship between the identifier of the existing state and the identifier of the target state; after combining the judgment results of both parties, determine whether to allow the game character to enter the target state. Based on this, the embodiment of the present application can support asymmetric game states in the game client and the game server, and can accurately control the game state when the game states of both parties are asymmetric. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0040] Figure 1 A schematic diagram of the structure of a mixing control system provided by an exemplary embodiment of the present application;

[0041] Figure 2 A schematic diagram of a state relationship table provided for an exemplary embodiment of the present application;

[0042] Figure 3 A logic diagram of a game state control solution provided for an exemplary embodiment of the present application;

[0043] Figure 4 A logical diagram of a solution for exiting / interrupting a game state provided for an exemplary embodiment of the present application;

[0044] Figure 5 A flowchart of a game state control method provided by an exemplary embodiment of the present application;

[0045] Figure 6 A schematic diagram of the structure of a state control device provided by an exemplary embodiment of the present application;

[0046] Figure 7 A schematic diagram of the structure of a computing device provided for an exemplary embodiment of the present application;

[0047] Figure 8 A flowchart of another game state control method provided by an exemplary embodiment of the present application;

[0048] Fig. 9A schematic diagram of the structure of another state control device provided by an exemplary embodiment of the present application;

[0049] Fig.10 A schematic diagram of the structure of another computing device provided as an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0050] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

[0051] In view of the technical problems such as insufficient accuracy in the existing way of managing all game states by the game server, in some embodiments of the present application: when the game character is expected to enter the target state, the game client and the game server can determine whether to allow the game character to enter the target state based on the relationship between the identifier of their own existing state and the identifier of the target state; after combining the judgment results of both parties, determine whether to allow the game character to enter the target state. Based on this, the embodiments of the present application can support asymmetric game states in the game client and the game server, and can accurately control the game state when the game states of both parties are asymmetric.

[0052] The technical solutions provided by various embodiments of the present application are described in detail below in conjunction with the accompanying drawings.

[0053] Figure 1 The following is a schematic diagram of a game state control system provided by an exemplary embodiment of the present application. Figure 1 As shown, the system includes: a first game processing terminal 10 and a second game processing terminal 20, and the first game processing terminal 10 and the second game processing terminal 20 are communicatively connected.

[0054] In this embodiment, the first game processing end 10 can be a game client, and the second game processing end 20 can be a game server; the two sides can also be interchangeable, that is, the first game processing end 10 can be a game server, and the second game processing end 20 can be a game client. That is, in this embodiment, both the game client and the game server can implement the function of the first game processing end 10 or the function of the second game processing end 20 in this embodiment according to the control requirements of the game state.

[0055] In the game world, game characters not only have basic movement states, such as walking, squatting, jumping, swimming, etc., but also many functional states, such as climbing, pushing boxes, lifting jars, picking herbs, skateboarding, exploring items, etc. In this article, these states are described as game states. It is worth noting that the game characters in this article can include not only player characters created by players, but also non-player characters such as NPCs or monsters.

[0056] In this embodiment, the first game processing terminal 10 and the second game processing terminal 20 can respectively maintain the identification of the existing state locally, and the existing state refers to the game state that the game character is in. The identification can be the name, code and other information of the game state, and this embodiment is not limited thereto.

[0057] In this embodiment, the identifiers of the existing states in the first game processing terminal 10 and the second game processing terminal 20 may be asymmetric. Asymmetry can be understood as the identifier of the existing state in the first game processing terminal 10 and the identifier of the existing state in the second game processing terminal 20 are different. The difference here refers to the identifier of the game state that may exist in the first game processing terminal 10 and the second game processing terminal 20 that the other party does not have, that is, the identifier of the second type of game state mentioned above. For example, the identifier of the existing state in the first game processing terminal 10 may include lifting a jar and jumping; the identifier of the existing state in the second game processing terminal 20 may include jumping and walking; in this case, the identifiers of the existing state in the first game processing terminal 10 and the second game processing terminal 20 are asymmetric.

[0058] Based on this, in this embodiment, the game state can be divided into two categories: the first type of game state is a game state that needs to be synchronized between the first game processing terminal 10 and the second game processing terminal 20. For example, in the aforementioned jar-raising state, when the game character is in the jar-raising state in the game client, the jar-raising state needs to be synchronized to the game server, so that the game server can synchronize the jar-raising state of the game character to other game clients, and then synchronously present the jar-raising state of the game character in other game clients. The second type of game state is a game state that does not need to be synchronized. For example, in the aforementioned herb-picking state, when the game character is in the herb-picking state in the game client, other game characters should not be allowed to see the state, otherwise it will cause other game players to mistakenly pick the herbs. In this case, the herb-picking state of the game character does not need to be synchronized to the game server. For another example, the artificial intelligence AI state of the NPC, etc., can only exist in the game server without being synchronized to the game client.

[0059] Thus, in this embodiment, the first game processing terminal 10 and the second game processing terminal 20 do not need to provide their own game states that do not need to be synchronized to each other. That is, for the above-mentioned second type of game state, the first game processing terminal 10 and the second game processing terminal 20 do not need to consume computing resources to integrate the game states, but can each have a part of the unique state (the above-mentioned second type of game state) separately. For example, the above-mentioned herbal medicine picking state can only exist in the game client and no longer need to be provided to the game server.

[0060] The game control solution provided in this embodiment can support game state control when the identifiers of the existing game states in the first game processing terminal 10 and the second game processing terminal 20 are asymmetric. However, it should be understood that in some cases, the identifiers of the existing states in the first game processing terminal 10 and the second game processing terminal 20 can also be symmetric, which does not affect the implementation of the game state control solution in this embodiment.

[0061] In this embodiment, the first game processing terminal 10 can receive a request to enter a game state, wherein the request to enter a game state includes an identifier of a state to be entered.

[0062] In practical applications, a state control device can be deployed in the first game processing terminal 10. The state control device in the first game processing terminal 10 can provide a call interface, and an external device can initiate a request to enter the game state to the state control device through the call interface. In addition, the state control device can also provide a callback interface for the external device to call the game state control result. Here, the external device can be any game module in the game. For example, the human-computer interaction module in the game client can initiate a request to enter the game state after receiving the player's operation, so as to request to enter the game state that the game character expected by the player's operation enters. At this time, the game client serves as the first game processing terminal 10, and its human-computer interaction module serves as the initiator of the request to enter the game state. Of course, the initiator of the request to enter the game state in this embodiment is not limited to this, and will not be exhaustive here.

[0063] The first game processing terminal 10 can determine the relationship between the identifier of the local existing state and the identifier of the state to be entered. Among them, the relationship between the identifiers of the game states is various. For example, if the game character is in the state of exploring items, if the game character is expected to enter the walking state, the state of exploring items needs to be interrupted. For another example, if the game character is in the state of lifting a jar, if the game character is expected to enter the water state, the state of lifting the jar needs to be interrupted. For another example, if the game character is in the state of swimming, if the game character is expected to enter the state of lifting a jar, the state of lifting a jar cannot be entered, and so on.

[0064] Based on this, in this embodiment, the relationship between the identifiers of the game states can be pre-configured, and the relationship between the identifiers of the game states includes but is not limited to coexistence, mutual exclusion or interruption. Among them, the coexistence relationship means that the game states can exist at the same time without affecting each other. If the relationship between the identifier of the state to be entered and the identifier of the existing state is coexistence, it means that the existing state does not affect the entry of the state to be entered. The mutually exclusive state means that the game states are mutually exclusive and cannot exist at the same time. If the relationship between the identifier of the state to be entered and the identifier of the existing state is mutually exclusive, it means that the existing state hinders the entry into the state to be entered, that is, it is impossible to enter the state to be entered. Interruption means that the game states are mutually exclusive, but interrupting one of the game states can enter another game state. If the relationship between the identifier of the state to be entered and the identifier of the existing state is interruption, it means that the state to be entered can be entered after interrupting the existing state.

[0065] In this embodiment, a state relationship table may be used to represent the relationship between the identifiers of the game states. Figure 2 A schematic diagram of a state relationship table provided by an exemplary embodiment of the present application. Figure 2 , a state relationship table can be maintained according to the game relationships that may appear in the game, and the names of the rows and columns of the state relationship table can be configured as game states as needed. In this way, when a game state needs to be added or deleted in the game, the game state can be added or deleted directly by adding rows and columns in the state relationship table, without having to search for the code location that needs to be modified like the hard-coding method. Therefore, the method of using the state relationship table to manage the relationship between game states in this embodiment can reduce the configuration error rate of the relationship between game states, thereby effectively ensuring the accuracy of game state control.

[0066] The first game processing terminal 10 can determine the relationship between the identifier of its local existing state and the identifier of the state to be entered based on the state relationship table. Specifically, the first game processing terminal 10 can determine the identifier of the local existing state, and look up the state relationship table to determine the relationship between the identifier of its local existing state and the identifier of the state to be entered. Among them, the table lookup rule can be determined according to the correspondence between the names of the rows and columns in the state relationship table and the identifier of the existing state and the identifier of the state to be entered. For example, if the name of the row in the state relationship table corresponds to the identifier of the existing state, and the name of the column corresponds to the identifier of the new state, then the table lookup rule can be configured to query the identifier of the local existing state from the row name of the state relationship table, and query the identifier of the state to be entered from the column name of the state relationship table. Reference Figure 2, the first game processing terminal 10 can determine the relationship between the identifier of the existing state and the identifier of the state to be entered according to the value at the intersection of the row and column where the identifier of the existing state and the identifier of the state to be entered are located. In practical applications, the value here can be set to 1, 2, 3, etc., and the relationship represented by the value can be configured, for example, 1 represents a coexistence relationship, 2 represents a mutually exclusive relationship, 3 represents an interruption relationship, etc., which is not limited in this embodiment.

[0067] Following the several exemplary relationships between the game states provided above, the first game processing terminal 10 can determine that the relationship between the state to be entered and its local existing state meets the first preset condition when the relationship between the state to be entered and its local existing state is coexistence or interruption. Of course, the specific configuration of the first preset condition provided here is exemplary. In actual applications, with the change of the type, quantity, etc. of the relationship between the identifiers of the configured game states, the first preset condition can also be adaptively adjusted. The first preset condition is essentially a condition that allows the game character to enter the state to be entered.

[0068] When the first game processing terminal 10 determines that the relationship between the identifier of the existing state and the identifier of the state to be entered locally meets the first preset condition, the first game processing terminal 10 may provide the identifier of the state to be entered to the second game processing terminal 20. Optionally, the first game processing terminal 10 may generate a state check request according to the identifier of the state to be entered, and send the state check request to the second game processing terminal 20. In addition, when the first game processing terminal 10 determines that the relationship between the identifier of the existing state and the identifier of the state to be entered locally does not meet the first preset condition, the first game processing terminal 10 may refuse to enter the state to be entered.

[0069] As mentioned above, the identification of the current state of each of the first game processing terminal 10 and the second game processing terminal 20 may be asymmetric. In this embodiment, both parties do not need to pay attention to the identification of the current state of the other party, but independently determine whether to allow the game character to enter the waiting state.

[0070] The second game processing terminal 20 may receive the status check request and determine whether the relationship between its local existing status and the state to be entered meets the second preset condition. If so, the second game processing terminal 20 may return a notification of allowing the game character to enter the state to be entered to the first game processing terminal 10. If not, the second game processing terminal 20 may return a notification of refusing the game character to enter the state to be entered to the first processing terminal. That is, the second game processing terminal 20 may give a judgment result of whether to allow the game character to enter the state to be entered from its own perspective.

[0071] Following the several exemplary relationships between game states proposed above, the second game processing terminal 20 can determine that the relationship between the identifier of the state to be entered and the identifier of its local existing state meets the second preset condition when the relationship between the identifier of the state to be entered and the identifier of its local existing state is coexistence or interruption.

[0072] In addition, the second game processing terminal 20 can also determine the relationship between the identifier of its local existing state and the identifier of the state to be entered based on the state relationship table. The specific determination process can refer to the description of the first game processing terminal 10 side in the previous text, and will not be repeated here. However, it is worth noting that the first game processing terminal 10 and the second game processing terminal 20 can share the same state relationship table, that is, the contents of the state relationship table used by the first game processing terminal 10 and the second game processing terminal 20 can be the same. In this case, the shared state relationship table can contain the relationship between the identifiers of all game states in the game. The first game processing terminal 10 and the second game processing terminal 20 can also use different state relationship tables, and the difference in the content of the state relationship table used by both parties can be the second type of game state mentioned above, that is, the identifiers of those game states that do not need to be synchronized and can only exist locally. This embodiment does not limit this. Among them, the first game processing terminal 10 and the second game processing terminal 20 can store the used state relationship table locally, of course, the state relationship table can also be stored in other storage locations, and the first game processing terminal 10 and the second game processing terminal 20 can remotely call the state relationship table, which is not limited in this embodiment.

[0073] The first game processing terminal 10 can control the game character to enter the waiting state after receiving the entry permission notification returned by the second game processing terminal 20. And after receiving the entry rejection notification returned by the second game processing terminal 20, the game character can be rejected from entering the waiting state.

[0074] In this embodiment, the first game processing terminal 10 can first give a judgment result of whether to allow the game character to enter the waiting state from its own perspective. If it judges that the game character can enter the waiting state, it will combine the judgment result given by the second game processing terminal 20. When both parties judge that the game character can enter the waiting state, the first game processing terminal 10 will control the game character to enter the waiting state, which ensures the accuracy of the game state control. Based on this, the game state control scheme provided in this embodiment can support asymmetric game states in the game client and the game server, and can accurately control the game state when the game states of both parties are asymmetric.

[0075] Figure 3 A logical schematic diagram of a game state control scheme provided for an exemplary embodiment of the present application.

[0076] refer to Figure 3 In the above or below embodiments, the first game processing terminal 10 can also determine whether to allow the game character to enter the waiting state from at least the following two aspects.

[0077] First aspect:

[0078] The first game processing terminal 10 may check the currently received game state entry request for duplication when receiving the game state entry request. If it is determined that the currently received game state entry request is a non-duplicate request, the subsequent operation is performed. If it is determined that the currently received game state entry request is a duplicate request, the game state entry may be refused.

[0079] The entry status request is usually asynchronous. In this embodiment, the first game processing terminal 10 can maintain a request cache list locally, and record at least one entry game status request received within the preset duplication checking period in the request cache list. For example, the preset duplication checking period can be set to 2 minutes, and the request cache list can store information of at least one entry game status request received within 2 minutes before the current moment. Among them, the length of the preset duplication checking period can be flexibly set according to actual needs.

[0080] Based on this, the first game processing terminal 10 can query the request cache list when receiving the entry status request. If the entry status request currently received is not queried, it can be determined that the entry game status request currently received is a non-repeated request. If it is queried, it can be determined that the entry game status request currently received is a repeated request. Of course, this is only exemplary. In this embodiment, other methods can also be used to determine whether the entry game status request currently received is a repeated request, and this embodiment is not limited to this.

[0081] Second aspect:

[0082] The first game processing terminal 10 can also obtain game parameters related to the state to be entered. If there are no game parameters that do not meet the parameter conditions required for entering the state to be entered, a subsequent operation of determining whether the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition is performed. If there are game parameters that do not meet the parameter conditions required for entering the state to be entered, entering the state to be entered can be rejected.

[0083] The game parameters related to the waiting state may include game parameters that may hinder the entry into the waiting state. For example, the game parameters related to the aforementioned box-pushing state may include at least box state parameters, such as: damaged, intact, etc.

[0084] In this embodiment, the parameter conditions required for the state to be entered can be pre-configured based on the game rules, and the parameter conditions required for different states to be entered may not be exactly the same. For example, the parameter condition required to enter the state of pushing the box may be that the box is intact. In this case, if the state parameter of the box obtained by the first game processing end 10 is intact, it can be determined that there are no local game parameters that do not meet the parameter conditions required to enter the state to be entered, so that subsequent operations can continue to be performed; if the state parameter of the box obtained by the first game processing end 10 is damaged, it can be determined that there are local game parameters that do not meet the parameter conditions required to enter the state to be entered, so that entry into the state to be entered is refused.

[0085] It is worth noting that the present embodiment does not limit the execution order of the above two operations of determining whether the game character is allowed to enter the waiting state. In addition, combined with the above operation of determining whether the relationship between the identifier of the local existing state and the identifier of the waiting state meets the first preset condition, that is, the first game processing terminal 10 can at least perform the above three operations to determine whether the game character is allowed to enter the waiting state, and the present embodiment does not limit the execution order of the three operations.

[0086] Of course, the above three operations are only exemplary, and the present embodiment is not limited thereto. The first game processing terminal 10 can also determine whether to allow the game character to enter the waiting state from more aspects.

[0087] Continue to refer Figure 3 In the above or following embodiments, after receiving the entry-allowed status notification returned by the second game processing end 20, the first game processing end 10 may further determine whether to allow the game character to enter the waiting-to-enter status.

[0088] The judgment operation can be:

[0089] Obtain the game parameters related to the state to be entered again; if there are no game parameters that do not meet the parameter conditions required to enter the state to be entered, control the game character to enter the state to be entered; if there are game parameters that do not meet the parameter conditions required to enter the state to be entered, refuse to enter the state to be entered.

[0090] Here, considering that it takes time for the second game processing terminal 20 to perform the judgment operation of whether to allow the entry state, and the process of returning the judgment result also takes time, and during the time period, the game parameters in the first game processing terminal 10 may have changed. Therefore, in this embodiment, after receiving the running entry state notification returned by the second game processing terminal 20, the first game processing terminal 10 can perform the judgment operation on the game parameters in the above embodiment again to ensure the accuracy of the judgment result.

[0091] In this embodiment, the game parameters related to the waiting state may be different from the game parameters related to the waiting state obtained before receiving the notification of the allowed entry state returned by the second game processing terminal 20. Therefore, the first game processing terminal 10 will control the game character to enter the waiting state only when the result of the second judgment is the allowed entry state, otherwise, it will refuse to enter the waiting state. This can effectively improve the accuracy of game state control.

[0092] In the above or following embodiments, the first game processing terminal 10 may also determine the control action on the local existing state based on the relationship between the identifier of the state to be entered and the identifier of the local existing state when receiving the entry permission notification sent by the second game processing terminal 20; and control the local existing state according to the control action.

[0093] As mentioned above, the relationship between the identifiers of the game states is varied. Under different relationships, the control actions that need to be performed on the local existing state may not be exactly the same. For example, for mutually exclusive relationships and coexistence relationships, it is not necessary to change the local existing state, but for interruption relationships, it is necessary to interrupt the local existing state. For this reason, in this embodiment, the corresponding relationship between the relationship between the identifiers of the game states and the control actions on the existing state can be pre-configured.

[0094] Based on this, the first game processing terminal 10 can determine the control action for the local existing state according to the relationship between the identifier of the state to be entered and the identifier of its local existing state; while controlling the game character to enter the state to be entered, the local existing state is controlled according to the control action. For example, in the case where the existing state includes a can-lifting state, if the state to be entered is an entering-water state, and the relationship between the can-lifting state and the entering-water state is to interrupt the existing state to enter a new state, then the first game processing terminal 10 can interrupt the can-lifting state and control the game character to enter the entering-water state. In this case, the control action for the existing state is interruption. For another example, in the case where the existing state includes a walking state, if the state to be entered is an eating state, and the walking state and the eating state are in a coexistence relationship, then the first game processing terminal 10 can control the game character to enter the eating state, and there is no need to process the walking state. In this case, the control action for the existing state is empty.

[0095] That is, the first game processing terminal 10 can interrupt the existing state that needs to be interrupted locally while controlling the game character to enter the waiting state.

[0096] Similarly, the second game processing terminal 20 may also determine the control action for its local existing state based on the relationship between the identifier of the state to be entered and the identifier of its local existing state when it determines that the relationship between the identifier of its local existing state and the identifier of the state to be entered meets the second preset condition; control its local existing state according to the control action, and send a notification of allowing entry to the first game processing terminal 10.

[0097] The process of the second game processing terminal 20 determining the control action for the local existing state is similar to the process in the first game processing terminal 10, and will not be repeated here. That is, the second game processing terminal 20 can interrupt the existing state that needs to be interrupted locally on the second game processing terminal 20 while returning the notification of allowing entry to the first game processing terminal 10.

[0098] In addition, the execution result of the control action on the local existing state can also be used as the basis for both parties to judge whether to allow entry into the waiting state, that is, if the execution of the control action on the local existing state fails, both parties can give a judgment result of refusing to enter the state. This can ensure accurate control of the game state.

[0099] Accordingly, in this embodiment, the first game processing terminal 10 and the second game processing terminal 20 can each perform a control action on the local existing state to interrupt the existing state that needs to be interrupted while allowing the game character to enter the waiting state. The processing processes of both parties on their own local existing states are independent and do not interfere with each other, which can effectively reduce the complexity of game state control, especially can greatly reduce the computing resource consumption of controlling the game state in the game server.

[0100] In the above or following embodiments, the first game processing terminal 10 may send an entry status success message to the second game processing terminal 20 when determining that the identifier of the to-be-entered state needs to be synchronized to the second game processing terminal 20, so that the second game processing terminal 20 can synchronously enter the to-be-entered state.

[0101] That is, if the state to be entered is the first type of game state mentioned above, that is, a game state that needs to be synchronized between the first game processing terminal 10 and the second game processing terminal 20, the first game processing terminal 10 can control the game character to enter the state to be entered while notifying the second game processing terminal 20 to execute the process of entering the state to be entered, so as to keep the state to be entered synchronized between the first game processing terminal 10 and the second game processing terminal 20.

[0102] In addition, in the aforementioned embodiment, after both parties perform control operations on the local existing state, if the changed existing state belongs to the aforementioned second type of game state, both parties may also initiate state synchronization requests to each other. The state synchronization request may include an identifier of the state to be synchronized and its corresponding control action to maintain the synchronization of this type of existing state between the first game processing terminal 10 and the second game processing terminal 20.

[0103] In this embodiment, in the process of controlling the game state, the first game processing end 10 and the second game processing end 20 can synchronize the game state that needs to be kept synchronized between the two parties to ensure the accuracy of the existing state of each party and avoid the control accuracy of the game state caused by untimely update of the existing state.

[0104] In addition to receiving an entry status request, the first game processing terminal 10 may also receive an exit / interrupt game status request. Figure 4 A logical diagram of a solution for exiting / interrupting a game state is provided for an exemplary embodiment of the present application. Figure 4 Describes the process of exiting / interrupting the game state.

[0105] refer to Figure 4 In the above or below embodiments, the first game processing terminal 10 may also receive a request to exit the game state, which includes an identifier of the state to be exited; if the state to be exited is entered in the first game processing terminal 10, the game character is controlled to exit the state to be exited. If the state to be exited is not entered in the first game processing terminal 10, the state to be exited may be rejected.

[0106] refer to Figure 4 In addition to judging whether to allow the game character to exit the waiting state based on whether the waiting state is entered at the first game processing terminal 10, judging can also be performed from other aspects, such as game parameters.

[0107] In this regard, the first game processing terminal 10 may obtain game parameters related to the state to be exited when the state to be exited is entered in the first game processing terminal 10; if there are no game parameters that do not meet the parameter conditions required for exiting the state to be exited, the game character is controlled to exit the state to be exited. If there are game parameters that do not meet the parameter conditions required for exiting the state to be exited, the state to be exited may be refused.

[0108] Of course, the operation order of the above two aspects can be swapped, and this embodiment does not limit this.

[0109] In addition, while the first game processing terminal 10 controls the game character to exit the waiting state, if the identifier of the waiting state needs to be synchronized to the second game processing terminal 20, the first game processing terminal 10 can send an exit state success message to the second game processing terminal 20 so that the second game processing terminal 20 can synchronously exit the waiting state.

[0110] refer to Figure 4 The first game processing terminal 10 can also receive a request to interrupt the game status, which includes an identifier of the state to be interrupted; if the state to be interrupted is entered in the first game processing terminal 10, the state to be interrupted is interrupted; if the state to be interrupted needs to be synchronized to the second game processing terminal 20, an interrupt status success message is sent to the second game processing terminal 20, so that the second game processing terminal 20 can synchronously interrupt the state to be interrupted.

[0111] In addition, if the state to be interrupted is entered in the first game processing terminal 10, the first game processing terminal 10 can obtain game parameters related to the state to be interrupted; if there are no game parameters that do not meet the parameter conditions required for interrupting the state to be entered, the state to be interrupted is interrupted.

[0112] The process of interrupting the game state is similar to the process of exiting the game state mentioned above. In order to save space, it will not be described in detail here.

[0113] In this embodiment, the first game processing end can determine whether to allow the game character to exit / interrupt the game state, and can synchronize the processing results to the second game processing end if necessary to ensure timely update of the local existing state of the second game processing end, thereby ensuring the control accuracy of the game state.

[0114] Figure 5 The following is a flowchart of a game state control method provided by an exemplary embodiment of the present application. Figure 5 As shown, the method can be applied to the aforementioned first game processing end, and the method includes:

[0115] Step 500: receiving a request to enter a game state, wherein the request to enter a game state includes an identifier of a state to be entered;

[0116] Step 501: When it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition, the identifier of the state to be entered is provided to the second game processing terminal;

[0117] Step 502: When the second game processing terminal determines that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing terminal meets the second preset condition, control the game character to enter the state to be entered.

[0118] The identifier of the local existing state is different from the identifier of the existing state in the second game processing terminal.

[0119] When the second game processing end determines that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing end meets the second preset condition, in addition to controlling the game character to enter the state to be entered, the control action for the local existing state can also be determined based on the relationship between the identifier of the state to be entered and the identifier of the local existing state; the local existing state is controlled according to the control action.

[0120] In a possible design, a state relationship table may be used to represent the relationship between the game state identifiers. The relationship between the game state identifiers includes, but is not limited to: coexistence, mutual exclusion, or interruption.

[0121] Based on this, before step 501, the method may include:

[0122] Obtain a state relationship table, the state relationship table containing the relationship between the identifiers of the game states;

[0123] Get the identifier of the local existing state;

[0124] According to the state relationship table, the relationship between the identifier of the state to be entered and the identifier of the local existing state is determined.

[0125] Following the several exemplary relationships between the aforementioned game relationships, step 501 may include:

[0126] If the relationship between the identifier of the state to be entered and the identifier of the local existing state is coexistence or interruption, it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition.

[0127] In addition to judging whether to allow entry into the state to be entered based on the relationship between the identifier of the state to be entered and the identifier of the local existing state, judgment can also be made based on the following two aspects.

[0128] In one aspect, a duplicate check may be performed on a currently received request to enter a game state; when it is determined that the currently received request to enter a game state is a non-duplicate request, an operation is performed in which the identifier of the state to be entered is provided to a second game processing terminal when it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets a first preset condition.

[0129] The process of checking for duplicate content in the request to enter the game state may include:

[0130] Obtain a request cache list, where the request cache list includes at least one request to enter a game state received within a preset duplication checking period;

[0131] If the currently received request to enter the game state is not found in the request cache list, it is determined that the currently received request to enter the game state is a non-duplicate request.

[0132] In another aspect, game parameters related to the state to be entered can be obtained; if there are no game parameters that do not meet the parameter conditions required to enter the state to be entered, an operation is performed in which the identifier of the state to be entered is provided to the second game processing end when it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition.

[0133] It is worth noting that the execution order of the operations in the above three aspects is not limited to this, and other execution orders can also be adopted for implementation, which is not limited in this embodiment.

[0134] In addition, when the second game processing end determines that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing end meets the second preset condition, the method may further include:

[0135] Get game parameters related to the state to be entered;

[0136] If there are no game parameters that do not meet the parameter conditions required for entering the waiting-to-enter state, the game character is controlled to enter the waiting-to-enter state.

[0137] By re-performing the judgment operation on the game parameters, the problem of inaccurate judgment results caused by changes in game parameters at the first game processing end during the time period consumed by the second game processing end can be avoided.

[0138] In addition, after controlling the game character to enter the waiting state, the method further includes:

[0139] If it is determined that the waiting-to-enter state needs to be synchronized to the second game processing end, a successful entry state message is sent to the second game processing end so that the second game processing end can synchronously enter the waiting-to-enter state.

[0140] In addition to processing the aforementioned game state entry request, the game state control method provided in this embodiment can also process game state exit / interrupt request.

[0141] To this end, the method may further include:

[0142] Receive a request to exit the game state, where the request to exit the game state includes an identifier of a state to be exited;

[0143] If the waiting-to-exit state is entered in the first game processing terminal, controlling the game character to exit the waiting-to-exit state;

[0144] If the pending exit state needs to be synchronized to the second game processing end, an exit state success message is sent to the second game processing end so that the second game processing end can synchronously exit the pending exit state.

[0145] Among them, if the waiting-to-exit state is entered in the first game processing terminal, the game parameters related to the waiting-to-exit state are obtained; if there are no game parameters that do not meet the parameter conditions required for exiting the waiting-to-exit state, the game character is controlled to exit the waiting-to-exit state.

[0146] It is worth noting that the execution order between the judgment operation of whether the above-mentioned pending exit state is entered in the first game processing terminal and the judgment operation of whether there are game parameters that do not meet the parameter conditions required for exiting the pending exit state is not limited to this.

[0147] The method further includes:

[0148] Receive a request to interrupt the game status, where the request to interrupt the game status includes an identifier of the status to be interrupted;

[0149] If the state to be interrupted is entered in the first game processing terminal, the state to be interrupted is interrupted;

[0150] If the to-be-interrupted state needs to be synchronized to the second game processing end, an interruption state success message is sent to the second game processing end so that the second game processing end can synchronously interrupt the to-be-interrupted state.

[0151] Among them, if the state to be interrupted is entered in the first game processing end, the game parameters related to the state to be interrupted are obtained; if there are no game parameters that do not meet the parameter conditions required for interrupting the state to be entered, the state to be interrupted is interrupted.

[0152] The process of interrupting the game state is similar to the process of exiting the game state, so I will not go into details here.

[0153] It is worth noting that, in this embodiment, the first game processing end is a game client, and the second game processing end is a game server; or, the first game processing end is a game server, and the second game processing end is a game client.

[0154] In addition, the technical details in each embodiment of the above-mentioned game state control method can refer to the description of the first game processing end in the aforementioned game state control system. In order to save space, they will not be described in detail here, but this should not cause loss of the protection scope of this application.

[0155] The game state control method can be executed by a state control device, which can be implemented as software or a combination of software and hardware. Figure 6 A schematic diagram of a state control device provided by an exemplary embodiment of the present application, referring to Figure 6 , the state control device may include:

[0156] A receiving module 60, configured to receive a request to enter a game state, wherein the request to enter a game state includes an identifier of a state to be entered;

[0157] The processing module 61 is used to provide the identifier of the state to be entered to the second game processing terminal when it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition;

[0158] The control module 62 is used to control the game character to enter the state to be entered when the second game processing end determines that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing end meets the second preset condition.

[0159] The identifier of the local existing state is asymmetric with the identifier of the existing state in the second game processing terminal.

[0160] When the second game processing end determines that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing end meets the second preset condition, the control module 62 can not only control the game character to enter the state to be entered, but also determine the control action for the local existing state based on the relationship between the identifier of the state to be entered and the identifier of the local existing state; and control the local existing state according to the control action.

[0161] In a possible design, a state relationship table may be used to represent the relationship between the game state identifiers. The relationship between the game state identifiers includes, but is not limited to: coexistence, mutual exclusion, or interruption.

[0162] Based on this, the processing module 61 can be used to:

[0163] Obtain a state relationship table, the state relationship table containing the relationship between the identifiers of the game states;

[0164] Get the local existing status;

[0165] According to the state relationship table, the relationship between the identifier of the state to be entered and the identifier of the local existing state is determined.

[0166] Based on the several exemplary relationships between the aforementioned game relationships, the processing module 61 may be used to:

[0167] If the relationship between the identifier of the state to be entered and the identifier of the local existing state is coexistence or interruption, it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition.

[0168] In addition to determining whether to allow entry into the to-be-entered state based on the relationship between the identifier of the to-be-entered state and the identifier of the local existing state, the processing module 61 may also determine based on the following two aspects.

[0169] In one aspect, the processing module may check for duplicates in the currently received request to enter the game state; when it is determined that the currently received request to enter the game state is a non-duplicate request, the operation of providing the identifier of the state to be entered to the second game processing end is performed when it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition.

[0170] The process of checking the duplicate of the request to enter the game state by the processing module 61 may include:

[0171] Obtain a request cache list, where the request cache list includes at least one request to enter a game state received within a preset duplication checking period;

[0172] If the currently received request to enter the game state is not found in the request cache list, it is determined that the currently received request to enter the game state is a non-duplicate request.

[0173] In another aspect, the processing module 61 can obtain game parameters related to the state to be entered; if there are no game parameters that do not meet the parameter conditions required to enter the state to be entered, then the operation of providing the identifier of the state to be entered to the second game processing end is performed when it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition.

[0174] It is worth noting that the execution order of the operations in the above three aspects is not limited to this, and other execution orders can also be adopted for implementation, which is not limited in this embodiment.

[0175] In addition, when the second game processing end determines that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing end meets the second preset condition, the processing module 61 can also be used to:

[0176] Get game parameters related to the state to be entered;

[0177] If there are no game parameters that do not meet the parameter conditions required for entering the waiting-to-enter state, the game character is controlled to enter the waiting-to-enter state.

[0178] By re-performing the judgment operation on the game parameters, the problem of inaccurate judgment results caused by changes in game parameters at the first game processing end during the time period consumed by the second game processing end can be avoided.

[0179] In addition, after controlling the game character to enter the waiting state, the control module 62 can also be used to:

[0180] If it is determined that the waiting-to-enter state needs to be synchronized to the second game processing end, a successful entry state message is sent to the second game processing end so that the second game processing end can synchronously enter the waiting-to-enter state.

[0181] In addition to processing the aforementioned game entry status request, the status control device provided in this embodiment can also process game exit / interrupt status request.

[0182] In this regard, the receiving module can also be used to receive a request to exit the game state, where the request to exit the game state includes an identifier of the state to be exited;

[0183] The processing module 61 may also be used to control the game character to exit the waiting state if the waiting state is entered in the first game processing terminal;

[0184] The control module 62 may also be used to send an exit status success message to the second game processing end if the waiting exit state needs to be synchronized to the second game processing end, so that the second game processing end can synchronously exit the waiting exit state.

[0185] Among them, the processing module 61 can also be used to obtain game parameters related to the state to be exited if the state to be exited is entered in the first game processing terminal; if there are no game parameters that do not meet the parameter conditions required for exiting the state to be exited, control the game character to exit the state to be exited.

[0186] It is worth noting that the execution order between the judgment operation of whether the above-mentioned pending exit state is entered in the first game processing terminal and the judgment operation of whether there are game parameters that do not meet the parameter conditions required for exiting the pending exit state is not limited to this.

[0187] The receiving module 60 may also be used to receive a request to interrupt the game status, where the request to interrupt the game status includes an identifier of the status to be interrupted;

[0188] The processing module 61 may also be used to interrupt the to-be-interrupted state if the to-be-interrupted state is entered in the first game processing terminal;

[0189] The control module 62 may also be used to send an interruption status success message to the second game processing end if the to-be-interrupted state needs to be synchronized to the second game processing end, so that the second game processing end can synchronously interrupt the to-be-interrupted state.

[0190] Among them, if the state to be interrupted is entered in the first game processing end, the processing module 61 can obtain game parameters related to the state to be interrupted; if there are no game parameters that do not meet the parameter conditions required for interrupting the state to be entered, the control module 62 interrupts the state to be interrupted.

[0191] The process of interrupting the game state is similar to the process of exiting the game state, so I will not go into details here.

[0192] It is worth noting that, in this embodiment, the first game processing end is a game client, and the second game processing end is a game server; or, the first game processing end is a game server, and the second game processing end is a game client.

[0193] In addition, the technical details in each embodiment of the above-mentioned state control device can refer to the description of the first game processing end in the aforementioned game state control system. In order to save space, they will not be described in detail here, but this should not cause loss of protection scope of this application.

[0194] The above-mentioned state control device can be integrated into a computing device, such as the aforementioned first game processing terminal. Figure 7 A schematic diagram of a computing device provided by an exemplary embodiment of the present application, referring to Figure 7 The computing device includes: a memory 70, a processor 71 and a communication component 72.

[0195] The processor 71 is coupled to the memory 70 and the communication component 72, and is used to execute the computer program in the memory to:

[0196] Receive a request to enter a game state, where the request to enter a game state includes an identifier of a state to be entered;

[0197] When it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition, the identifier of the state to be entered is provided to the second game processing terminal through the communication component 72;

[0198] When the second game processing end determines that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing end meets the second preset condition, the game character is controlled to enter the state to be entered.

[0199] In an optional embodiment, the identifier of the local existing state and the identifier of the existing state in the second game processing terminal are asymmetric.

[0200] In an optional embodiment, the processor 71 is further configured to:

[0201] When the second game processing terminal determines that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing terminal meets the second preset condition, determining a control action for the local existing state according to the relationship between the identifier of the state to be entered and the identifier of the local existing state;

[0202] Control the local existing state according to the control action.

[0203] In an optional embodiment, the processor 71 is further configured to:

[0204] Obtain a state relationship table, the state relationship table containing the relationship between the identifiers of the game states;

[0205] Get the local existing status;

[0206] According to the state relationship table, the relationship between the identifier of the state to be entered and the identifier of the local existing state is determined.

[0207] In an optional embodiment, the relationship between the identifiers of the game states includes: one or more of coexistence, mutual exclusion, or interruption.

[0208] In an optional embodiment, the processor 71 is further configured to:

[0209] If the relationship between the identifier of the state to be entered and the identifier of the local existing state is coexistence or interruption, it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition.

[0210] In an optional embodiment, the processor 71 is further configured to:

[0211] Check the duplication of the currently received request to enter the game state;

[0212] When it is determined that the currently received request to enter the game state is a non-repetitive request, an operation is performed in which the identifier of the state to be entered is provided to the second game processing end when it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition.

[0213] In an optional embodiment, when checking for plagiarism in a request to enter a game state, the processor 71 is used to:

[0214] Obtain a request cache list, where the request cache list includes at least one request to enter a game state received within a preset duplication checking period;

[0215] If the currently received request to enter the game state is not found in the request cache list, it is determined that the currently received request to enter the game state is a non-duplicate request.

[0216] In an optional embodiment, the processor 71 is further configured to:

[0217] Get game parameters related to the state to be entered;

[0218] If there are no game parameters that do not meet the parameter conditions required to enter the state to be entered, an operation is performed in which the identifier of the state to be entered is provided to the second game processing end after determining that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition.

[0219] In an optional embodiment, when the processor 71 determines at the second game processing end that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing end meets the second preset condition, when controlling the game character to enter the state to be entered, it is used to:

[0220] When the second game processing end determines that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing end meets the second preset condition, obtaining game parameters related to the state to be entered;

[0221] If there are no game parameters that do not meet the parameter conditions required for entering the waiting-to-enter state, the game character is controlled to enter the waiting-to-enter state.

[0222] In an optional embodiment, after controlling the game character to enter the waiting state, the processor 71 is further configured to:

[0223] If it is determined that the waiting-to-enter state needs to be synchronized to the second game processing end, a successful entry state message is sent to the second game processing end so that the second game processing end can synchronously enter the waiting-to-enter state.

[0224] In an optional embodiment, the processor 71 is further configured to:

[0225] Receive a request to exit the game state, where the request to exit the game state includes an identifier of a state to be exited;

[0226] If the waiting-to-exit state is entered in the first game processing terminal, controlling the game character to exit the waiting-to-exit state;

[0227] If the pending exit state needs to be synchronized to the second game processing end, an exit state success message is sent to the second game processing end so that the second game processing end can synchronously exit the pending exit state.

[0228] In an optional embodiment, if the waiting-to-exit state is entered in the first game processing terminal, the processor 71 is used to:

[0229] If the state to be exited is entered in the first game processing terminal, obtaining game parameters related to the state to be exited;

[0230] If there are no game parameters that do not meet the parameter conditions required for exiting the waiting state, the game character is controlled to exit the waiting state.

[0231] In an optional embodiment, the processor 71 is further configured to:

[0232] Receive a request to interrupt the game status, where the request to interrupt the game status includes an identifier of the status to be interrupted;

[0233] If the state to be interrupted is entered in the first game processing terminal, the state to be interrupted is interrupted;

[0234] If the to-be-interrupted state needs to be synchronized to the second game processing end, an interruption state success message is sent to the second game processing end so that the second game processing end can synchronously interrupt the to-be-interrupted state.

[0235] In an optional embodiment, if the waiting-for-interruption state is entered in the first game processing terminal, the processor 71 is used to:

[0236] If the state to be interrupted is entered in the first game processing terminal, then obtaining game parameters related to the state to be interrupted;

[0237] If there are no game parameters that do not meet the parameter conditions required for interruption of the waiting state, the waiting state is interrupted.

[0238] In an optional embodiment, the first game processing end of the processor 71 is a game client, and the second game processing end is a game server; or, the first game processing end is a game server, and the second game processing end is a game client.

[0239] It is worth noting that the technical details in each embodiment of the above-mentioned computing device can refer to the description of the first game processing end in the aforementioned game state control system. In order to save space, they will not be described in detail here, but this should not cause loss of the protection scope of this application.

[0240] Further, if Figure 7 As shown, the computing device also includes: a power supply component 73 and other components. Figure 7 Only some components are shown schematically, and it does not mean that the computing device only includes Figure 7 Components shown.

[0241] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, which, when executed, can implement the steps that can be executed by a computing device in the above method embodiment.

[0242] Figure 8 A flowchart of another game state control method provided by an exemplary embodiment of the present application is shown in FIG. Figure 8 The method can be applied to the aforementioned second game processing terminal, and the method includes:

[0243] Step 800: receiving a state check request sent by the first game processing end, the state check request including an identifier of a state to be entered that the first game processing end determines to be allowed to enter the game character according to its existing state;

[0244] Step 801: determine the relationship between the identifier of the state to be entered and the identifier of the local existing state;

[0245] Step 802: If the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the preset condition, a notification of allowing entry into the state is sent to the first game processing end so that the first game processing end can control the game character to enter the state to be entered.

[0246] The identifier of the local existing state and the identifier of the existing state in the second game processing terminal may be asymmetric.

[0247] In this embodiment, when the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the preset conditions, in addition to returning a notification of allowing entry to the first game processing end, the control action for the local existing state can also be determined based on the relationship between the identifier of the state to be entered and the identifier of the local existing state; the local existing state is controlled according to the control action.

[0248] After controlling the local existing state according to the control action, it can also be determined whether the identifier of the target state that has changed in the local existing state needs to be synchronized to the first game processing end. If so, the identifier of the target state and its corresponding control action can be sent to the first game processing end so that the first game processing end can synchronously control the target state.

[0249] In a possible design, a state relationship table may be used to represent the relationship between the game state identifiers. The relationship between the game state identifiers includes, but is not limited to: coexistence, mutual exclusion, or interruption.

[0250] Based on this, step 801 may include:

[0251] Obtain a state relationship table, the state relationship table containing the relationship between the identifiers of the game states;

[0252] Get the identifier of the local existing state;

[0253] According to the state relationship table, the relationship between the identifier of the state to be entered and the identifier of the local existing state is determined.

[0254] Following the several exemplary relationships between game states provided above, step 802 may include:

[0255] If the relationship between the identifier of the state to be entered and the identifier of the local existing state is coexistence or interruption, it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the preset condition.

[0256] In addition to judging whether to allow entry into the state to be entered based on the relationship between the identifier of the state to be entered and the identifier of the local existing state, the following aspects may also be used to judge whether to allow entry into the state to be entered. The method may also include:

[0257] Check the duplication of the currently received status check request;

[0258] In the case where it is determined that the currently received state check request is a non-repetitive request, an operation of determining a relationship between an identifier of the state to be entered and an identifier of the locally existing state is performed.

[0259] The process of checking the duplication of the currently received status check request may include:

[0260] Obtain a request cache list, where the request cache list includes at least one status check request received within a preset duplication check period;

[0261] If the currently received status check request is not found in the request cache list, it is determined that the previously received status check request is a non-duplicate request.

[0262] Additionally, the method may further include:

[0263] Receiving a state synchronization request sent by the first game processing terminal, wherein the state synchronization request includes an identifier of a state to be synchronized and a control action;

[0264] The state to be synchronized is controlled according to the identification and control action of the state to be synchronized.

[0265] The control action includes one or more of: entering, exiting or interrupting.

[0266] It is worth noting that the technical details in each embodiment of the above-mentioned game state control method can be referred to the description of the second game processing end in the aforementioned game state control system. In order to save space, they will not be described in detail here, but this should not cause loss of the protection scope of this application.

[0267] The game state control method can be executed by a state control device, which can be implemented as software or a combination of software and hardware. Fig. 9 A schematic diagram of another state control device provided by an exemplary embodiment of the present application, referring to Fig. 9 , the state control device may include:

[0268] A receiving module 90 is used to receive a state check request sent by the first game processing end, wherein the state check request includes an identifier of a state to be entered that the first game processing end determines to be allowed to enter the game character according to its existing state;

[0269] A processing module 91, used to determine the relationship between the identifier of the state to be entered and the identifier of the local existing state;

[0270] The sending module 92 is used to send a notification of allowing entry to the first game processing end if the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the preset condition, so that the first game processing end can control the game character to enter the state to be entered.

[0271] The identifier of the local existing state and the identifier of the existing state in the second game processing terminal may be asymmetric.

[0272] In this embodiment, when the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the preset conditions, the processing module 91 can not only return a notification of allowing entry into the state to the first game processing end, but also determine the control action for the local existing state based on the relationship between the identifier of the state to be entered and the identifier of the local existing state; and control the local existing state according to the control action.

[0273] After controlling the local existing state according to the control action, the processing module 91 can also determine whether the identifier of the target state that has changed in the local existing state needs to be synchronized to the first game processing end. If so, the identifier of the target state and its corresponding control action can be sent to the first game processing end so that the first game processing end can synchronously control the target state.

[0274] In a possible design, a state relationship table may be used to represent the relationship between the game state identifiers. The relationship between the game state identifiers includes, but is not limited to: coexistence, mutual exclusion, or interruption.

[0275] Based on this, the processing module 91 can also be used to:

[0276] Obtain a state relationship table, the state relationship table containing the relationship between the identifiers of the game states;

[0277] Get the identifier of the local existing state;

[0278] According to the state relationship table, the relationship between the identifier of the state to be entered and the identifier of the local existing state is determined.

[0279] Based on the several exemplary relationships between the game states provided above, the processing module 91 can be used for:

[0280] If the relationship between the identifier of the state to be entered and the identifier of the local existing state is coexistence or interruption, it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the preset condition.

[0281] In addition to judging whether to allow entry into the state to be entered based on the relationship between the identifier of the state to be entered and the identifier of the local existing state, the following aspects can also be used to judge whether to allow entry into the state to be entered. The processing module 91 can also be used to:

[0282] Check the duplication of the currently received status check request;

[0283] In the case where it is determined that the currently received state check request is a non-repetitive request, an operation of determining a relationship between an identifier of the state to be entered and an identifier of the locally existing state is performed.

[0284] The processing module 91 may be used to:

[0285] Obtain a request cache list, where the request cache list includes at least one status check request received within a preset duplication check period;

[0286] If the currently received status check request is not found in the request cache list, it is determined that the previously received status check request is a non-duplicate request.

[0287] In addition, the state control device may further include a control module 93; the receiving module 90 may also be used to receive a state synchronization request sent by the first game processing terminal, the state synchronization request including an identifier of the state to be synchronized and a control action;

[0288] The control module 93 may be used to control the state to be synchronized according to the identification of the state to be synchronized and the control action.

[0289] The control action includes one or more of: entering, exiting or interrupting.

[0290] It is worth noting that the technical details in each embodiment of the above-mentioned state control device can be referred to the description of the second game processing end in the aforementioned game state control system. In order to save space, they will not be described in detail here, but this should not cause loss of the protection scope of this application.

[0291] The above-mentioned state control device can be integrated into a computing device, for example, the aforementioned second game processing terminal. Fig.10 A schematic diagram of the structure of another computing device provided in an exemplary embodiment of the present application. Fig.10 , the computing device includes: a memory 100, a processor 101 and a communication component 102;

[0292] The memory 100 is used to store one or more computer instructions;

[0293] The processor 101 is coupled to the memory 100 and the communication component 102 for executing one or more computer instructions for:

[0294] receiving a state check request sent by the first game processing end, the state check request including an identifier of a state to be entered that the first game processing end determines to be allowed to enter the game character according to its existing state;

[0295] Determine the relationship between the identifier of the state to be entered and the identifier of the local existing state;

[0296] If the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the preset condition, a notification of allowing entry to the state is sent to the first game processing end through the communication component 102, so that the first game processing end can control the game character to enter the state to be entered.

[0297] In an optional embodiment, the identifier of the local existing state is asymmetric to the identifier of the existing state in the second game processing terminal.

[0298] In an optional embodiment, the processor 101 is further configured to:

[0299] If the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the preset condition, then the control action for the local existing state is determined according to the relationship between the identifier of the state to be entered and the identifier of the local existing state;

[0300] Control the local existing state according to the control action.

[0301] In an optional embodiment, after controlling the local existing state according to the control action, the processor 101 is further configured to:

[0302] If it is determined that the identifier of the target state that has changed in the local existing state needs to be synchronized to the first game processing end, the identifier of the target state and its corresponding control action are sent to the first game processing end so that the first game processing end can synchronously control the target state.

[0303] In an optional embodiment, when determining the relationship between the identifier of the state to be entered and the identifier of the local existing state, the processor 101 is configured to:

[0304] Obtain a state relationship table, the state relationship table containing the relationship between the identifiers of the game states;

[0305] Get the identifier of the local existing state;

[0306] According to the state relationship table, the relationship between the identifier of the state to be entered and the identifier of the local existing state is determined.

[0307] In an optional embodiment, the relationship between the identifiers of the game states includes: one or more of coexistence, mutual exclusion, or interruption.

[0308] In an optional embodiment, the processor 101 is further configured to:

[0309] If the relationship between the identifier of the state to be entered and the identifier of the local existing state is coexistence or interruption, it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the preset condition.

[0310] In an optional embodiment, the processor 101 is further configured to:

[0311] Check the duplication of the currently received status check request;

[0312] In the case where it is determined that the currently received state check request is a non-repetitive request, an operation of determining a relationship between an identifier of the state to be entered and an identifier of the locally existing state is performed.

[0313] In an optional embodiment, when performing a duplicate check on a currently received status check request, the processor 101 is configured to:

[0314] Obtain a request cache list, where the request cache list includes at least one status check request received within a preset duplication check period;

[0315] If the currently received status check request is not found in the request cache list, it is determined that the previously received status check request is a non-duplicate request.

[0316] In an optional embodiment, the processor 101 is further configured to:

[0317] Receiving a state synchronization request sent by the first game processing terminal, wherein the state synchronization request includes an identifier of a state to be synchronized and a control action;

[0318] The state to be synchronized is controlled according to the identification and control action of the state to be synchronized.

[0319] In an optional embodiment, the control action includes: one or more of: entering, exiting or interrupting.

[0320] It is worth noting that the technical details in each embodiment of the above-mentioned computing device can be referred to the description of the second game processing end in the aforementioned game state control system. In order to save space, they will not be described in detail here, but this should not cause loss of protection scope of this application.

[0321] Further, if Fig.10 As shown, the computing device also includes: a power supply component 103 and other components. Fig.10 Only some components are shown schematically, and it does not mean that the computing device only includes Fig.10 Components shown.

[0322] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, which, when executed, can implement the steps that can be executed by a computing device in the above method embodiment.

[0323] Above Figure 7 and 10 The memory in the computer is used to store computer programs and can be configured to store various other data to support operations on the computing platform. Examples of such data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, pictures, videos, etc. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0324] Above Figure 7 and 10 The communication component in is configured to facilitate wired or wireless communication between the device where the communication component is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G and other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0325] Above Figure 7 and 10 The power supply component in the device provides power to various components of the device where the power supply component is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device where the power supply component is located.

[0326] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0327] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0328] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0329] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

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

[0331] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0332] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media 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 disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0333] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0334] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A game state control method, applied to a first game processing terminal, It is characterized in that include: Receiving a request for entering a game state, wherein the request for entering a game state includes an identifier of a state to be entered; When it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition, providing the identifier of the state to be entered to the second game processing terminal; When the second game processing end determines that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing end meets the second preset condition, obtaining game parameters related to the state to be entered; If there are no game parameters that do not meet the parameter conditions required for entering the waiting-to-enter state, the game character is controlled to enter the waiting-to-enter state.

2. The method according to claim 1, It is characterized in that Also includes: When the second game processing end determines that the relationship between the identifier of the state to be entered and the identifier of the existing state in the second game processing end meets the second preset condition, determining a control action for the local existing state according to the relationship between the identifier of the state to be entered and the identifier of the local existing state; The local existing state is controlled according to the control action.

3. The method according to claim 1, It is characterized in that Also includes: Obtaining a state relationship table, wherein the state relationship table contains relationships between identifiers of game states; Get the identifier of the local existing state; According to the state relationship table, the relationship between the identifier of the state to be entered and the identifier of the local existing state is determined.

4. The method according to claim 1, It is characterized in that Also includes: Check the duplication of the currently received request to enter the game state; When it is determined that the currently received request to enter the game state is a non-repetitive request, the operation of providing the identifier of the state to be entered to the second game processing end is performed when it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition.

5. The method according to claim 4, It is characterized in that The checking for duplicates on the request to enter the game state includes: Obtain a request cache list, wherein the request cache list includes at least one request to enter a game state received within a preset duplication checking period; If the currently received request to enter the game state is not found in the request cache list, it is determined that the currently received request to enter the game state is a non-duplicate request.

6. The method according to claim 1 or 4, It is characterized in that Also includes: Acquire game parameters related to the state to be entered; If there are no game parameters that do not meet the parameter conditions required to enter the state to be entered, the operation of providing the identifier of the state to be entered to the second game processing end is performed when it is determined that the relationship between the identifier of the state to be entered and the identifier of the local existing state meets the first preset condition.

7. The method according to claim 1, It is characterized in that Also includes: Receive a request to exit the game state, wherein the request to exit the game state includes an identifier of a state to be exited; If the waiting-to-exit state is entered in the first game processing terminal, controlling the game character to exit the waiting-to-exit state; If the identifier of the pending exit state needs to be synchronized to the second game processing end, a successful exit state message is sent to the second game processing end so that the second game processing end can synchronously exit the pending exit state.

8. The method according to claim 7, It is characterized in that If the waiting-to-exit state is entered in the first game processing terminal, controlling the game character to exit the waiting-to-exit state includes: If the pending exit state is entered in the first game processing terminal, obtaining game parameters related to the pending exit state; If there are no game parameters that do not meet the parameter conditions required for exiting the waiting-to-exit state, the game character is controlled to exit the waiting-to-exit state.

9. The method according to claim 1, It is characterized in that Also includes: Receiving a request for interrupting a game state, wherein the request for interrupting a game state includes an identifier of a state to be interrupted; If the to-be-interrupted state is entered in the first game processing terminal, interrupting the to-be-interrupted state; If the to-be-interrupted state needs to be synchronized to the second game processing end, an interruption state success message is sent to the second game processing end so that the second game processing end can synchronously interrupt the to-be-interrupted state.

10. The method according to claim 9, It is characterized in that If the to-be-interrupted state is entered in the first game processing terminal, controlling the game character to exit the to-be-interrupted state includes: If the to-be-interrupted state is entered in the first game processing terminal, obtaining game parameters related to the to-be-interrupted state; If there are no game parameters that do not meet the parameter conditions required for interrupting the state to be entered, the state to be interrupted is interrupted.

Images