CN116747512A

CN116747512A - Card game control method and related device

Info

Publication number: CN116747512A
Application number: CN202310757258.5A
Authority: CN
Inventors: 陈家增; 郑庭君
Original assignee: Beijing Amazgame Age Internet Technology Co ltd
Current assignee: Beijing Amazgame Age Internet Technology Co ltd
Priority date: 2023-06-26
Filing date: 2023-06-26
Publication date: 2023-09-15

Abstract

The application discloses a card game control method and a related device, which specifically comprise that after a client sends a request for opening a card game to a server, the server receives the request for opening the card game from the user sent by the client and generates metadata, the client can send the metadata to the client without adopting a polling mode to request the server, the client generates a fight scene by analyzing the metadata, the client analyzes and responds to the fight instruction set by acquiring the fight instruction set in the fight scene, so that the instant interaction between the server and the client is realized, the client can acquire the data sent by the server in real time, the data is not required to be requested to the server in a polling mode, and finally the real-time fight requirement of the user can be responded dynamically.

Description

Card game control method and related device

Technical Field

The application relates to the technical field of game design, in particular to a card game control method and a related device.

Background

Currently, with the rapid development of the game market, more and more game types can be converted into card type games. However, the conventional card game supports only two play methods of PVE (PlayerVS Environment, player against environment) and PVM (Player vs Player against offline Player), and no practical implementation is given for the implementation of PVP (Player vs Player against Player) play method.

Even if the PVP (PlayerVS Player) playing method can be realized, most of the conventional PVP (PlayerVS Player) playing method adopts a short connection mode, the server cannot push data to the client in real time, and the client must request data from the server in a polling mode, so that interaction between the client and the server is influenced by the polling time interval, the interval time is too short, the pressure of the server is too high, the interval time is too long, the client cannot obtain real-time data, and real-time combat requirements of real-time dynamic response users cannot be realized.

Disclosure of Invention

In view of the above, the present application provides a card game control method and related device, so as to dynamically respond to real-time combat demands of users in real time. The specific scheme is as follows:

a method of controlling a card game, comprising:

sending a request for starting the card game to a server by a user;

receiving and analyzing metadata, wherein the metadata is generated after a server receives a request of a user for starting a card game and is sent to a client;

generating a combat scene according to the metadata;

acquiring a combat instruction set in a combat scene;

And analyzing the combat instruction set and responding to the combat instruction set.

Optionally, before parsing the combat instruction set and responding to the combat instruction set, further comprising:

checking the correctness of the combat order in the combat order set;

and executing analysis of the fight instruction set and responding to the fight instruction set if the checking result of the correctness checking of the fight instruction in the fight instruction set is correct.

determining an executive party for a combat order in the combat order set;

and if the execution party of the combat command is the client, executing and analyzing the combat command set, and responding to the combat command set.

Optionally, performing correctness checking on the combat instructions in the combat instruction set includes:

and checking the correctness of the combat order ID, the combat order parameter and the combat order type corresponding to the combat order in the combat order set.

Optionally, parsing the combat instruction set includes:

analyzing a combat instruction set to generate presentation layer data for client presentation;

the combat instruction set is parsed to generate logical layer data indicating the time of impact of instructions in the combat instruction set including the time of instruction generation in the combat instruction set until the time of the end of the combat.

Optionally, acquiring a combat instruction set in a combat scene includes:

acquiring a combat instruction set corresponding to user operation in a combat scene;

or receiving a combat instruction set sent by the server.

A card game control method is applied to a server and comprises the following steps:

receiving a request sent by a client for a user to start a card game;

generating metadata, wherein the metadata is used for generating a combat scene;

metadata is sent to the client.

Optionally, after generating the metadata, the method further includes:

generating a combat instruction set and a combat result;

transmitting a combat instruction set and a combat result to the client; the combat instruction set and the combat result are used to generate a course of combat.

Optionally, after sending the metadata to the client, the method further includes:

receiving a combat result sent by a client;

and verifying the combat result according to the combat instruction set and the metadata.

Optionally, verifying the combat result according to the combat instruction set and the metadata includes:

generating a verification combat result according to the combat instruction set and the metadata;

judging whether the combat result is consistent with the verification combat result;

and if the combat result is judged to be consistent with the verification combat result, the verification is passed.

A client comprising at least one processor and a memory coupled to the processor, wherein:

the memory is used for storing computer programs or instructions;

the processor is used for executing the computer program or instructions to enable the server to realize the card game control method.

A server comprising at least one processor and a memory coupled to the processor, wherein:

the memory is used for storing computer programs or instructions;

A computer storage medium carrying one or more computer program instructions that, when executed by a server, enable a client to implement the method of controlling a card game described above, or enable the server to implement the method of controlling a card game described above.

By means of the technical scheme, in the card game control method, after the client sends the request for opening the card game to the server, the server receives the request for opening the card game from the user and generates metadata, the client can send the metadata to the client without adopting a polling mode to request the server, the client generates a battle scene by analyzing the metadata, the client analyzes and responds to the battle instruction set by acquiring the battle instruction set in the battle scene, and further, instant interaction between the server and the client is achieved, the client can acquire data sent by the server in real time, the client does not need to request the data to the server in a polling mode, and finally, the real-time battle requirement of the user can be responded dynamically.

Drawings

In order to more clearly illustrate the embodiments of the application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a signaling interaction diagram of a client and a server in a card game control method provided by an embodiment of the present application;

FIG. 2 is a signaling interaction diagram of a client and a server in another card game control method according to an embodiment of the present application;

FIG. 3 is a schematic diagram of a combat command generated by a command system according to an embodiment of the present application, the combat command corresponding to a user's drag-and-card-up operation;

FIG. 4 is a schematic diagram of a layer structure of a combat command according to an embodiment of the present application;

fig. 5 is a schematic structural diagram of a client and a server according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. The terminology used in the following examples is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in the specification of the application and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include, for example, "one or more" such forms of expression, unless the context clearly indicates to the contrary.

Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.

The plurality of the embodiments of the present application is greater than or equal to two. It should be noted that, in the description of the embodiments of the present application, the terms "first," "second," and the like are used for distinguishing between the descriptions and not necessarily for indicating or implying a relative importance, or alternatively, for indicating or implying a sequential order.

In order to more clearly clarify the technical scheme of the present application, the related concepts related to the present application are explained below.

1) PVE (Player VS Environment, player combat environment), i.e. monsters and BOSS that the player challenges the game program to control during play.

2) PVM (Player VS Mirror, player fight offline Player), i.e. the play mode of a live Player in online Player fight offline during play.

3) PVP (PlayerVS Player, player-to-Player), i.e., the play mode of a Player-to-Player during play, is typically an interactive competitive play mode in which players attack each other using game resources.

4) Playback system refers to replaying the combat processes of PVE, PVM and PVP once at the player's client.

5) The sightseeing system refers to a combat process in which any one online player can watch PVEs, PVMs, and PVPs of other players on the player's own clients.

6) State synchronization refers to synchronizing various states in a game at each player's client, such as a change in a character attribute of a player in the game, requiring that the change in character attribute of that player be synchronized to other players' clients. When a character in a game releases skill, it is also necessary to synchronize the effects of skill release to each player's client.

7) The short connection means that when the two communication parties have data interaction, the two communication parties can establish a connection, and after the data transmission is completed, the connection of the two communication parties can be automatically disconnected, namely, the connection of each communication party only completes the transmission of one service.

The conventional card game only supports two playing methods of PVEs (PlayerVS Environment, player combat environment) and PVMs (Player vs Mirror, player combat offline players), the PVPs (Player vs Player, player combat players) are implemented in a short connection mode, the server cannot push data to the client in real time, the client must request data from the server in a polling mode, interaction between the client and the server is influenced by polling time intervals, the interval time is too short, the pressure of the server is too high, the interval time is too long, and the client cannot obtain real-time data, so that real-time combat requirements of real-time dynamic response players cannot be achieved.

In order to solve the above problems, the present application provides a card game control method and related devices, and the following detailed description will explain the present application by referring to specific embodiments.

Example 1

The control method of the card game provided by the embodiment of the application realizes all operation flows in the card game by designing a complete instruction system. Specifically, when a user requests to start a card combat, after receiving a combat request of the user, the server generates corresponding metadata according to a specific combat scene, the server transmits the metadata to the client for creating the combat scene, the client can transmit the metadata to the client without requesting the client to the server, and after receiving the metadata transmitted by the server, the client analyzes the metadata and generates the combat scene.

At this time, the user can operate the fight character to fight, the instruction system can convert the operation behaviors of the user into corresponding fight instruction sets, and the script system can analyze the fight instruction sets needed in the fight process to generate presentation layer data for being presented at the client side, so that all operation behaviors of the user are realized. Meanwhile, with expansion of card game content, more different operations of users can be realized by writing more combat instructions.

The following describes a method for controlling a card game according to an embodiment of the present application with reference to a signaling interaction diagram between a client and a server in the method for controlling a card game shown in fig. 1.

As shown in fig. 1, the method for controlling a card game provided by the embodiment of the application includes the following steps:

s101, the client sends a request for opening the card game to the server.

Specifically, the user may request to start combat from the server by clicking a "start combat" button displayed in the client, and at this time, the client may obtain a request from the user to start the card game. After the client acquires the request of opening the card game by the user, the request of opening the card game by the user is sent to the server, so that the server can generate metadata according to the request of opening the card game by the user sent by the client.

S102, the server receives a request for starting the card game from the user sent by the client and generates metadata.

Specifically, after receiving a request sent by a client for a user to start a card game, the server generates corresponding metadata according to a specific battle scene, where the metadata includes battle scene data, user's battle data, non-user's battle data and some additional data, where the non-user's battle data may be battle data of a monster controlled by a game program, and some additional data may be buff data and some skill data.

S103, the server side sends the metadata to the client side.

Specifically, after metadata is generated according to a request sent by a client for a user to start a card game, the server sends the metadata to the client so that the client can generate a combat scene according to the metadata.

It should be noted that, because the interaction between the client and the server provided by the application is based on the connection established by the transmission control protocol (Transmission Control Protocol, TCP), the server can directly issue the metadata to the client, and the client does not need to request the data from the server in a polling way, thereby realizing the instant interaction between the client and the server and meeting the real-time combat requirement of the instant dynamic response user.

S104, the client analyzes the metadata and generates a fight scene.

Specifically, after receiving metadata generated according to a specific combat scene sent by a server, the client analyzes the metadata generated according to the specific combat scene, and mainly includes analyzing the combat scene data, so as to generate a combat scene used in a local combat; the fight character data is analyzed and used for generating fighter personnel of the battle in the field; and analyzing the random factor data for carrying out safety verification on the battle in the field.

S105, the client acquires a combat instruction set in a combat scene.

Specifically, after the user starts to fight, the user may operate the fighter to perform various actions, where the user's operation on the fighter is not limited to a series of actions that the user may operate the fighter by dragging the fighter to get on the scene and releasing skills at the client.

In the process that a user clicks a screen of a client to operate, the instruction system generates different fight instruction sets according to operation classifications of the user, and then generates performance layer data for client performance, such as performance fighter person release skills, fighter person movements, special effects and injuries, and the like, through processing of the different fighter instruction sets.

Specifically, the main operation behaviors of the user may form a set, and specifically may include: setting automatic combat, setting combat play speed, discarding combat, dragging card matrix, PVP request data, PVP check data, command execution, setting a card to enter a hand, selecting a principal skill, setting a pause game, user online reconnection, user disconnection, unit action, unit increase of anger, generating cards, drawing cards, dragging card matrix and the like, and each operation action of a user corresponds to a combat instruction in the instruction system.

The format of each combat instruction in the instruction system includes: ID of the combat directive, type of combat directive, parameters of the combat directive, and debug information of the combat directive.

Wherein the ID of the combat directive is used to identify the uniqueness of each combat directive, and includes an int value or string describing the type of operation, or any other combination of sequences that can identify a unique signature for that combat directive in a field of combat, without specific limitation. Different combat orders have different combat order IDs, and the uniqueness of the combat orders is ensured.

The type of the combat order is used for identifying the specific application of the combat order in the combat process, specifically, the operation behaviors of the users are uniquely corresponding to the operation behaviors of the users, the operation behaviors of the users represent the specific application of the combat order, for example, the users set automatic combat, the users set up the card and the users set up the release skills, and the type of the combat order is used for uniquely corresponding to the operation behaviors of the users.

Parameters of the combat command are determined according to logic content corresponding to the combat command, each combat command has corresponding execution content, such as a card dragging and matrix loading command, corresponding execution content is to drag one card matrix loading, and the parameters of the card dragging and matrix loading command can be the ID of each card in the card library, so that which card matrix loading is dragged corresponding to the card matrix loading command can be determined. If the user drags the card A to be arranged, the parameter information of the card A arranging instruction is corresponding to the ID information of the card A.

The debugging information of the combat command is the same as the information of the current combat command in the combat process. For example, the debug information of the battle instruction may include information of which round the card game is played, and since each round of the card game is used for the battle instruction for dragging the card array, the debug information of the battle instruction for dragging the card array contains information for recording which round the card game is played. Debug information for a combat command may also include time information to record the current card game executing the combat command, as well as various status information in the card game.

Before the fight command is processed, the fight command needs to be preprocessed, and the preprocessing process of the fight command is actually a process of verifying whether the fight command can be executed.

The preprocessing process of the combat order comprises two processes of checking the correctness of the combat order and judging the execution object of the combat order.

The correctness checking of the fight command mainly checks the ID of the fight command, the type of the fight command, the parameters of the fight command, and the debug information of the fight command.

Taking the drag card array operation of the user as an example, the generation of drag card array instructions and the correctness checking are described in detail.

When a user drags cards in a hand area to a combat scene in a game picture of a client, the instruction system generates combat instructions corresponding to the drag card array operation of the user, and the combat instructions need to be subjected to preprocessing correctness checking and execution position judging before entering into the processing process of the instructions.

A schematic diagram of a combat command generated by the command system for a drag card array operation of a user is shown in fig. 3. As shown in fig. 3, the combat command of the drag card array operation of the user includes an ID of the combat command, a type of the combat command, parameters of the combat command, and debug information of the combat command. Wherein "cmdrid=8" represents a combat command ID of the drag card matrix operation, "cmdType" represents a type of combat command of the drag card matrix operation, "spin", "battleId", "playerId" represents three parameters of the combat command of the drag card matrix operation, specifically, the parameter "spin" represents a unique ID referred to by a card of the drag card matrix, the parameter "battleId" represents a unique ID of the present combat, the parameter "playerId" represents a unique ID of a user who performs the present operation, and "Debuginfo" represents debug information of the combat command of the drag card matrix operation.

Specifically, since each combat command generates a unique ID and IDs are arranged in ascending order, if the combat command ID "cmdrid=8" of the drag card array operation is checked to see if the last executed command is "cmdrid=7", the instruction IDs are arranged in ascending order only when the last executed command ID is "cmdrid=7". If the ID of the last executed instruction is "cmdrid=9", it represents that the current instruction is already an executed instruction, and the instruction does not need to be repeatedly executed, so the instruction can be discarded. If the ID of the last executed instruction is "cmdrid=6", this indicates that the instruction to be executed is lost, and thus the present instruction does not continue to execute. Only when the last executed instruction ID is "cmdrid=7", it represents that the correctness check of the instruction passes, and the instruction can be executed.

The checking of the correctness of the combat order includes not only checking the ID of the combat order but also checking the parameters of the combat order. The card dragging method comprises the steps of checking the position of a card dragging, and when other cards exist in the position of the card dragging by a user, checking the correctness of a combat command is not passed, and the user needs to drag the card to the other positions again.

The execution object of the combat order refers to whether the combat order is executed at a local client, at a server, or at a remote client. According to different types of playing methods selected by the user, the execution objects of the combat instructions corresponding to the operation behaviors of the user are different.

Specifically, if the user selects PVE (Player VS Environment, player combat environment) play, the combat instructions corresponding to the user's operational behavior are executed at the local client. Therefore, the above operation of dragging the card to the array is described as an example, and the combat command corresponding to the operation of dragging the card to the array is directly executed at the local client, and the subsequent combat command processing stage is directly executed at the local client.

If the user selects PVP (Player VS Player) playing method, the fight command corresponding to the operation action of the user needs to be sent to the server for verification, the fight command is sent to the local client after the verification of the server is passed, and after the local client receives the fight command returned by the server, the fight command is judged to be allowed to be executed, and then the fight command is directly executed at the local client. Meanwhile, because the method is a playing method of users in fight, the server side can forward the fight instruction sent by the local client side to the remote client side corresponding to the opposite user, and after the remote client side receives the fight instruction sent by the server side, the remote client side judges that the fight instruction is allowed to be executed, the fight instruction is executed directly on the remote client side, so that the user positioned on the remote client side can see the operation behavior of the opposite user on the remote client side.

If the user selects PVM playing method, namely, the online player fights the game mode of the offline real player, the fight command corresponding to the operation behavior of the online player needs to be sent to the server for verification, the fight command is sent to the local client after the verification of the server is passed, and the local client determines that the fight command is allowed to be executed after receiving the fight command returned by the server, and then the fight command is directly executed at the local client. And the combat command corresponding to the operation behavior of the offline real player is directly generated in the server, the generated combat command set is sent to the client corresponding to the offline player, and the client of the offline player is sequentially executed after receiving the combat command set sent by the server.

S106, the client analyzes the combat instruction set and responds to the combat instruction set.

Specifically, the process of the client parsing the combat instruction set and responding to the combat instruction set is the process of the client processing the combat instructions in the combat instruction set.

If the combat order passes through the preprocessing of the combat order during execution, the combat order is formally entered into the processing of the combat order. The processing procedure of the combat command mainly comprises two parts of generating presentation layer data and modifying current logic data.

Specifically, the processing procedure of generating the presentation layer data is to convert the operation behavior of the user into the data for presentation at the client, and describing the operation of dragging the card to the matrix by the user as an example, when the user drags one card from the card hand area to leave the card hand area, the client presents to generate a 3D presentation model corresponding to the card for the card dragged by the user, and places the model at a designated position in the combat scene. If the card dragged by the user is a card that can release skills, the client appears to be an effect on the card that releases skills after being dragged into the combat scene.

Therefore, the process of generating performance layer data may correspond to two types of performance data on the client, one being data that represents when a user drags a card to generate a 3D performance model for the card and drop the model to a specified location in the combat scene, and one being data that represents when the card releases skill.

The processing procedure of modifying the logic layer data is that after the surface layer data is generated, the corresponding logic layer data is required to be modified according to the operation of a user, the operation of dragging the cards to the matrix is taken as an example for introduction, the user drags the cards in one hand area to the battle scene, at the moment, the cards dragged by the user are more in the battle scene, after the user drags the cards to the matrix, the card game can release corresponding skills according to the cards dragged by the user to cause damage to the matrix of the opposite party, which is equivalent to modifying the related data of the opposite party user, and the damage to the matrix of the opposite party caused by dragging the card to the matrix at the moment is required to be stopped along with the ending of the operation of dragging the cards to the matrix, but can continuously influence the matrix of the opposite party until the battle is ended.

In the processing of the instruction, all the processing of the logic layer data is persistent, that is, after the creation of the fight scene is started, the processing of the logic layer data continues until the fight scene is ended, and the effect generated by the processing of the logic layer data always affects the user. By taking the operation of dragging the card matrix by the user as an example, the operation of dragging the card matrix by the user not only leads to the change of the presentation layer data, but also leads to the change of the logic layer data, for example, the card matrix is dragged by the user, which indicates that the card dragged by the user is added in a combat scene, if the card dragged by the user causes harm to the opponent user through releasing skills, such as the modification of the blood volume of the opponent user, the modification of the anger value of the opponent user or the death of the opponent user, and the like, the harm to the opponent user is caused by the modification of the logic layer data, so the fight is ended continuously.

Fig. 4 shows a schematic diagram of the structural form of presentation layer data of a combat order.

As shown in fig. 4, the performance layer data of the combat instruction contains four pieces of data, respectively, "BehaviorData", "BehaviorStageData", "ImpactGroupData" and "ImpactData", wherein "BehaviorData" represents the performance layer data, which contains data representing the type of combat instruction and some preparation data before combat, "BehaviorStageData" represents an array of performance layer data, which contains parameter data "ImpactGroupData" and "ImpactData" for various combat display, "ImpactData" represents a set of behavior parameters expressed in a specific combat, and "chapget" represents attribute variation data, "BuffData" represents buff variation data, "HitShield" represents special protection data variation, "deaddinfo" represents combat person death notification data, "addt" represents augmentation person data, "comingedata" represents extraction card data "represents extraction facility change person data.

After receiving the "BehaviorData" in the presentation layer data, the client of the user parses out parameter information contained therein, for example, data for playing actions of the fighter, special effects of the fighter, etc., through the script system, where the "ImpactData" contained therein is used for presenting a specific moving position, whether the fighter is knocked, whether the fighter is dead, whether the fighter is newly added, etc., and a specific presentation of the effects.

And S107, the client transmits a combat instruction set to the server after the combat is finished.

Specifically, after meeting the conditions of the end of the battle, for example, the upper limit of the number of rounds is reached, the upper limit of the total rounds is reached, or the conditions of the end of the battle such as the user knockdown the designated role of the other user are met, the client side stops generating the battle instruction, stores all the battle instructions generated in the battle process as a battle instruction set, and then uploads the battle instruction set to the server side.

S108, the service end verifies the fight process based on the fight instruction set and the metadata.

Specifically, after the combat is finished, after receiving the combat instruction set sent by the client, the server side invokes the verification system to verify the stored metadata and the combat instruction set data sent by the client, and the purpose of verification is to judge whether the user completes all operations of customs through the verification of the server side, whether the user has cheating behaviors and whether combat rewards can be issued to the user or not, and a series of operations such as the like can be performed, and only after the verification of the verification system of the server side is passed, the user can obtain the corresponding rewards.

Specifically, a verification system is further designed in the card game control method provided by the embodiment of the application, and is used for preventing cheating behaviors of the client, guaranteeing fairness of a combat result and improving safety of the game.

The verification system provided by the embodiment of the application comprises strong verification and weak verification, wherein the weak verification can be divided into two modes of random verification and non-verification, and in the control method of the card game provided by the application, a strong verification mode is adopted for a designated gate in the card game, and although the strong verification mode is adopted, a combat sample is randomly extracted to carry out the strong verification, and a non-verification mode can be adopted for some non-core gates.

Specifically, the specific flow of the strong verification includes:

the user requests to start the fight to the server, and the server generates metadata according to specific fight scenes after receiving the fight request of the user and transmits the metadata to the client for creating the fight scenes and other data.

After the client receives the metadata sent by the server, the client analyzes the metadata and generates a fight scene, a user starts to operate a fight character in the fight scene to fight, an instruction system generates fight instructions according to the operation behaviors of the user in the fight process and stores all the fight instructions as a fight instruction set after the fight process is finished, the client uploads the fight instruction set to the server and generates original fight result data after the fight process is finished.

When the server checks the fight process, the server generates check fight result data according to the stored metadata and a fight instruction set sent by the client, and the check fight result data is used for the server to perform check operation.

The server side can judge whether the user has cheating behaviors by comparing the original combat result data with the verification combat result data. If the server side finds that the two pieces of combat data are different by comparing the original combat result data with the verification combat result data, the server side indicates that the user has cheating behaviors, and at the moment, the server side can prevent the user from continuing cheating by blocking the user account and other behaviors. If the server side finds that the two pieces of combat data are completely consistent by comparing the original combat result data with the verification combat result data, the user is indicated that no cheating behavior exists.

The weak verification provided by the embodiment of the application can be divided into two modes of random verification and non-verification.

The random verification is to randomly extract a sampling sample for a specified fight to be verified through a fight sampling algorithm, wherein the extracted specified fight is verified by a strong verification mode through the fight sampling algorithm, and the fight process is verified by a strong verification mode instead of all specified fight to be verified.

Another way of weak verification is that the fight process is not selected to be verified, and for non-core checkpoints in card games or checkpoints that are relatively easy for users to deal with, the possibility of cheating by users is small, and at this time, the server can not verify the fight result of the client, but select to trust the fight result of the client, and directly issue a clearance reward to the client.

In the card game control method of the card game, only the appointed combat randomly extracted is subjected to the strong verification by adopting the weak verification mode for the non-core level in the card game or the level relatively easy to pass for the user, so that the computing power of the server is greatly saved compared with the traditional verification method, the server can better support the number of orders of concurrent combat, the experience of the card game is not influenced, and the game safety is further improved.

It should be noted that, in the card game control method provided by the embodiment of the present application, interactions between the client and the server in the card game control method are slightly different for different playing methods.

The following describes another card game control method according to the embodiment of the present application with reference to a signaling interaction diagram between a client and a server in another card game control method according to the embodiment of the present application shown in fig. 2.

As shown in fig. 2, another card game control method provided by the embodiment of the application includes the following steps:

s201, the client sends a request for opening the card game to the server.

The specific implementation of step S201 can be referred to the content of step S101 in the foregoing embodiment, and will not be described herein.

S202, the server receives a request for starting the card game from the user sent by the client and generates metadata.

The specific implementation of step S202 may be referred to the content of step S102 in the foregoing embodiment, and will not be described herein.

S203, the server side generates a combat instruction set and a combat result.

Specifically, due to the specificity of the PVM playing method, one fight player is online in the PVM playing method, and the other fight player is offline, so that the server side can automatically fight with the online player according to mirror image data of the offline player, the online player does not need to operate the fight process in the fight process, and the server side automatically generates a fight instruction set and a fight result, which are needed in the fight process.

S204, the server side sends the metadata, the combat instruction set and the combat result to the client side.

Specifically, the server side sends metadata, a fight instruction set and a fight result generated in the fight process to the client side, so that the client side can generate the fight process according to the metadata and the fight instruction set.

S205, the client analyzes the metadata and generates a combat scene.

Specifically, after receiving metadata generated according to a specific combat scene sent by a server, the client analyzes the metadata generated according to the specific combat scene, and mainly includes analyzing the combat scene data, so as to generate a combat scene used in a local combat; the fight character data is analyzed and used for generating fighter personnel of the battle in the field; and analyzing the random factor data for carrying out safety verification on the battle in the field. It should be noted that, when the client analyzes the metadata to generate the battle scene, the battle result is already confirmed in the server, and the battle scene generated by the client is for the playback system to play back the battle scene in the battle process.

S206, the client generates a fight process.

Specifically, after the battle ends, the client uploads the battle instruction set generated in the battle process to the server, the battle server will first invoke the verification system to verify the correctness of the battle instruction set uploaded by the client, the process of verifying the instruction set is described in the process of verifying the battle instruction by the verification system, which is not repeated here, the battle server stores the verified battle instruction set and metadata and generates playback data required by the playback system, the user can apply for looking back to the battle in the field by clicking the 'apply for playback' button displayed in the client, that is, the client applies for the playback system data to the playback system, the playback system needs to verify the application authority of the user, and after the application authority of the user is verified by the playback system, the designated battle playback data is issued to the client.

After receiving the appointed combat playback data sent by the playback system, the client analyzes according to the metadata in the combat playback data to generate a combat scene for playback, and the client displays the past combat record so as to realize that a user can review the whole combat process through the playback system.

In the card game control method provided by the embodiment of the application, a skill script system is also provided, and is used for realizing the core combat content of the card game by editing the combat skill script by a developer. The developer writes the logic of all combat skills by using the Lua script, and provides some general external interfaces, and the external interfaces can be used for operating elements in the combat scene, such as cards in the combat scene, and data of camping data of two parties in the combat scene, and the like.

Specifically, the skill script system includes an event system, an environment variable, and a UnitAction system. The event system is the core of the whole skill script system, the realization of the core logic of the skill script system is driven by the event system, corresponding triggering conditions are marked for events possibly occurring in a fight scene, the triggering time of the fight event is marked generally, when the corresponding fight event occurs in the fight process, the server side can call corresponding functions in the script system, and the interaction of fight characters and skills in the fight scene is realized.

The card game provided by the embodiment of the application can support 49 events in total, and specifically can comprise: each time an injury trigger is received, each time an injury trigger is caused, a post-complete skill attack trigger is received, a post-treatment trigger is received, a post-riot trigger is received, a post-role death trigger is received, a post-blood volume change trigger is received, a combat start trigger is received, a role matrix trigger is received, a buff trigger is added, a buff trigger is removed, and the like combat events are received. It should be noted that the types of the combat events can be increased or decreased according to the design thought of the combat skill, so as to achieve random strain according to the skill change in the combat process, and achieve the combat process by increasing or decreasing the combat events.

Environmental variables are designed to handle some persistent events in the course of combat. The environment variable is equivalent to providing a communication mechanism for realizing interaction logic among fight characters, fight characters and fight scenes of the two parties and the camping and fight characters of the two parties.

For example, after the fighter of the user receives the notification of the apoptosis, the environment variable corresponds to the function of the counter, and is used for recording the number of the apoptosis of the fighter, when the number of the apoptosis of the fighter is recorded by the counter in an accumulated manner, the environment variable executes the logic of 50% of the blood return of the fighter, and when the server side executes the logic of 50% of the blood return of the fighter, the counter is cleared.

Through cooperation of the event system and the environment variables, developers of combat skills can flexibly write different combat events through the event system, and interaction logic between combat processes can be realized through the environment variables, so that various skill effects are realized.

The UnitAction system provides interfaces for operating the fighter in the card game, such as modifying the property of the fighter, adding or deleting the fighter, controlling the release skill of the fighter, adding the buff to the formulated fighter, and the like, and the UnitAction system actually provides an interface for directly modifying the logic property of the fighter.

The following describes different playing methods of the card game in detail in combination with the control method of the card game provided by the embodiment of the application.

For PVE play and PVM play, the logic of implementation of both plays is the same, since only one party to the battle is a real online user, the other party is either an offline user or a game-controlled monster, and is theoretically controlled by the game program.

Specifically, the user can request to start combat through clicking a "start combat" button displayed in the client to the server, at this time, the instruction system generates a corresponding combat instruction according to the clicking operation of the user, the local client sends the combat instruction to the server for verification after receiving the combat instruction generated by the instruction system, and the server performs the combat instruction after the verification of the combat instruction passes. The server generates corresponding metadata according to a specific battle scene, wherein the metadata comprises battle scene data, user's battle data, non-user's battle data and some additional data, the non-user's battle data may be battle data of monsters controlled by a game program, and some additional data may be buff data and some skill data, etc.

The server side can send corresponding metadata generated according to the specific combat scene to the local client side for creating the combat scene, combat task, combat skills and the like of the client side. After receiving metadata generated according to a specific fight scene sent by a server, the client analyzes the metadata generated according to the specific fight scene, and mainly comprises analyzing the fight scene data and generating a fight scene used in the field of fight; the fight character data is analyzed and used for generating fighter personnel of the battle in the field; and analyzing the random factor data for carrying out safety verification on the battle in the field.

After the user starts to fight, the user can operate the fighter to perform various actions, and the operation of the user on the fighter is not limited to a series of actions that the user can operate the fighter by dragging the fighter to get on the battle and releasing skills at the client.

In the process that a user clicks a screen of a client to operate, the instruction system generates different fight instruction sets according to operation classifications of the user, and then generates performance layer data for client performance, such as performance fighter person release skills, fighter person movements, special effects and injuries, and the like, through processing of the different fighter instruction sets. When the conditions of the end of combat are met, for example, the upper limit of the number of rounds is reached, the upper limit of the time of the total rounds is reached, or the conditions of the end of combat such as the user knockdown the designated role of the other user are met, the client stops generating combat instructions, all combat instructions generated in the combat process are stored as a combat instruction set, and then the combat instruction set is uploaded to the server.

After the combat is finished, the server side can call the verification system to verify the stored metadata and combat instruction set data sent by the client side after receiving the combat instruction set sent by the client side, and the verification purpose is to judge whether the user completes all operations of customs through the verification of the server side, whether the user has cheating behaviors or not, whether combat rewards can be issued to the user or not, and the like, and only after the verification of the verification system of the server side is passed, the user can obtain the corresponding rewards.

For PVP playing, because the two parties are real online users, the implementation logic of PVP playing is different from that of PVE playing and PVM playing.

Specifically, the online users can request to match the appropriate online users to fight the online users by clicking a 'start matching' button displayed in the client, at this time, the command system generates a corresponding fight command for the clicking operation of the users, the client sends the fight command to the matching server for verification after receiving the fight command generated by the command system, and the matching server executes the fight command after the verification fight command passes. The matching server side can list online users applying PVP playing methods into a matching queue for real-time matching of different online users, when the matching server side matches the appropriate online users, the matching server side can send corresponding fight instructions to clients of the fight parties, the clients execute the fight instructions and inform the users of the fight parties that the matching is successful, after the users of the two parties agree with the matching result of the matching server side, the server side can generate metadata according to fight data of the fight parties, and send the metadata to the clients of the fight parties.

It should be noted that, the matching server may match one online user against another online user, may match one online user against a plurality of online users at the same time, and may match a plurality of users with the same number against a plurality of users, where the number of matching online users is not specifically limited.

After receiving metadata generated according to specific fight scenes of the fight parties sent by the server, the client analyzes the metadata generated according to the specific fight scenes of the fight parties, and mainly comprises the steps of analyzing the fight scene data of the fight parties, and generating a fight scene used in a local fight; analyzing the fighter character data of the two fighters, and generating fighters of the two fighters in the field; and analyzing the random factor data of the two parties of the fight, and performing safety verification on the fight in the field. In addition, after the metadata generated by specific combat scenes of the two parties are analyzed, the client side also generates a control instruction, and then the control instruction is uploaded to the combat server side to inform the combat server side of the self state of the clients of the two parties.

After receiving the control instruction sent by the client, the combat server analyzes the control instruction and is used for synchronizing the round combat between the clients of the two parties, so as to ensure the consistency of the combat pictures played in the clients of the two parties. Based on the specificity of PVP playing method, the fight service end needs to set a lock step operation for PVP playing method, wherein the lock step operation means that after the fight command is generated by the client ends of the fight parties, the client ends of the fight parties need to be synchronously transmitted to the fight service end, and the fight service end can determine whether the client ends of the fight parties can continuously execute the fight command transmitted by the client ends according to the performance progress of the fight parties in the fight process, so that the requirement of the client ends of the fight parties on the consistency is realized.

When the conditions of the end of combat are met, for example, the upper limit of the number of rounds is reached, the upper limit of the time of the total rounds is reached, or the conditions of the end of combat such as the user knockdown the designated role of the other user are met, the client stops generating combat instructions, all combat instructions generated in the combat process are stored as a combat instruction set, and then the combat instruction set is uploaded to the server.

For the playback system, the playback system is applicable to PVE play and PVM play as well as PVP play. The playback system means that after the battle is over, the user can review the entire complete battle process through the playback system.

Aiming at the sightseeing system, only the PVP playing method is supported at present, so that other players can watch the fight process among players in the PVP playing method through the sightseeing system. If one of the players in the fight process is sacrificed, the fight can be always performed as long as the sacrificed player does not exit the fight process. If the sacrificed player exits the present battle, the battle process between the remaining players in the PVP play can still be viewed through the viewing system.

Specifically, the user can upload metadata of the users of the two parties of the fight to the sightseeing service end in the fight process of the PVP playing method, and meanwhile, a fight instruction set of the users of the two parties of the fight can be uploaded to the sightseeing service end in the fight process of the two parties of the fight. In the fight process of the two parties, if one user of the two parties is sacrificed in the fight process, the sacrificed user can directly watch the fight process among the rest players in the PVP playing method. If other players want to watch the fight process of other PVP playing methods, the fight server can request to enter a fight state by clicking a 'fight' button, and after receiving the fight request sent by the client of the other players, the fight server can conduct authority verification on the fight request of the other players, and only after the authority verification of the fight server passes, the fight server can send metadata for creating a fight scene of the fight at the fight client.

Because the fight both sides of PVP playing method constantly fight, the client side of fight both sides can real-time generation fight instruction to fight the server side and can upload the fight instruction that fight both sides' client side produced to the sightseeing service side, the sightseeing client side that the sacrificial user corresponds can receive the fight instruction that is used for broadcasting the other side user operation that sightseeing service side down, sightseeing client side is through analyzing the fight instruction that is used for broadcasting the other side user operation, thereby realizes showing the operation of other side user at sightseeing client side.

In order to prevent the sacrificed user from acquiring the fight data of the opposite user in real time through the sightseeing system to generate some cheating actions, the sightseeing service end generally delays for about 10s to update the fight command of the opposite user, so that the fight user can be protected. If the fight command of the opposite user is updated in real time by the sightseeing service end, the fight state of the opposite user can be obtained in real time by the victim user in the sightseeing system, and the fight state of the opposite user can be revealed to other users in the fight process by the victim user to form a cheating behavior. Therefore, the sightseeing service end needs to delay updating the fight command of the opposite user, and the time for delay updating is not particularly limited, and is generally about 10s and is most suitable.

Referring to fig. 5, a schematic diagram of a client and a server suitable for implementing an embodiment of the present application is shown. The electronic device corresponding to the client and the server in the embodiment of the present application may include, but is not limited to, a fixed terminal such as a mobile phone, a notebook computer, a PDA (personal digital assistant), a PAD (tablet personal computer), a desktop computer, and the like. The server side shown in fig. 5 is only an example, and should not be construed as limiting the functionality and scope of use of the embodiments of the present application.

As shown in fig. 5, the server may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 501 that may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 502 or a program loaded from a storage device 508 into a Random Access Memory (RAM) 503. In the state where the electronic device is powered on, various programs and data necessary for the operation of the electronic device are also stored in the RAM 503. The processing device 501, the ROM 502, and the RAM 503 are connected to each other via a bus 504. An input/output (I/O) interface 505 is also connected to bus 504.

In general, the following devices may be connected to the I/O interface 505: input devices 506 including, for example, a touch screen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; an output device 507 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 508 including, for example, memory cards, hard disks, etc.; and communication means 509. The communication means 509 may allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. While fig. 5 shows a server-side corresponding electronic device having various means, it should be understood that not all of the illustrated means are required to be implemented or provided. More or fewer devices may be implemented or provided instead.

Example IV

The embodiment of the application provides a computer readable storage medium which is applied to electronic equipment corresponding to a server. The computer-readable medium carries one or more programs that, when executed by a server, enable the server to implement the card game control method of the first embodiment.

It should be noted that the computer readable medium described in the present disclosure may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this disclosure, a computer-readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present disclosure, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, fiber optic cables, RF (radio frequency), and the like, or any suitable combination of the foregoing.

While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. It is therefore intended that the following claims be interpreted as including the preferred embodiment and all such alterations and modifications as fall within the scope of the embodiments of the invention.

Finally, it is further noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

Claims

1. A card game control method applied to a client, comprising the following steps:

sending a request for starting the card game to a server by a user;

receiving and analyzing metadata, wherein the metadata is generated after a server receives a request of a user for starting a card game and is sent to the client;

generating a combat scene according to the metadata;

acquiring a combat instruction set in the combat scene;

parsing the combat instruction set and responding to the combat instruction set.

2. The method of claim 1, wherein prior to parsing the combat instruction set and responding to the combat instruction set, further comprising:

performing correctness checking on the combat instructions in the combat instruction set;

and executing the analysis of the combat instruction set and responding to the combat instruction set if the checking result of the correctness checking of the combat instruction in the combat instruction set is correct.

3. The method of claim 1, wherein prior to parsing the combat instruction set and responding to the combat instruction set, further comprising:

Determining an executive party for the combat instructions in the combat instruction set;

and if the executing party of the combat instruction is determined to be the client, executing the analysis of the combat instruction set and responding to the combat instruction set.

4. The method of claim 2, wherein the checking for correctness of the combat instructions in the set of combat instructions comprises:

5. The method of claim 1, wherein said parsing the combat instruction set comprises:

analyzing the combat instruction set to generate performance layer data for client performance;

and analyzing the combat instruction set to generate logic layer data, wherein the logic layer data is used for indicating that the influence time of the instructions in the combat instruction set comprises the time of instruction generation in the combat instruction set to the end of combat.

6. The method of claim 1, wherein the acquiring a combat instruction set in the combat scene comprises:

Acquiring a combat instruction set corresponding to user operation in the combat scene;

or receiving a combat instruction set sent by the server.

7. The card game control method is applied to a server and is characterized by comprising the following steps:

receiving a request sent by a client for a user to start a card game;

and sending the metadata to the client.

8. The method of claim 7, further comprising, after generating the metadata:

generating a combat instruction set and a combat result;

the combat instruction set and the combat result are sent to a client; the combat instruction set and combat results are used to generate a course of combat.

9. The method of claim 7, further comprising, after the transmitting the metadata to the client:

receiving a combat result sent by the client;

10. The method of claim 9, wherein verifying the combat outcome based on the combat instruction set and the metadata, comprises:

11. A client comprising at least one processor and a memory coupled to the processor, wherein:

the memory is used for storing a computer program or instructions;

the processor is configured to execute the computer program or instructions to enable the server to implement the card game control method according to any one of claims 1 to 6.

12. A server comprising at least one processor and a memory coupled to the processor, wherein:

the memory is used for storing a computer program or instructions;

the processor is configured to execute the computer program or instructions to enable the electronic device to implement the method of controlling a card game as claimed in any one of claims 7 to 10.

13. A computer storage medium carrying one or more computer program instructions which, when executed by the server, enable the client to implement the method of controlling a card game as claimed in any one of claims 1 to 6 or enable the server to implement the method of controlling a card game as claimed in any one of claims 7 to 10.