CN118469343A - Command decision acquisition method, system and device for confrontation system simulation model - Google Patents

Abstract

The application relates to a command decision acquisition method, a system and equipment of an countermeasure system simulation model, which are characterized in that current request data output by a business logic model in the countermeasure system simulation model are acquired, the data are subjected to condition classification, corresponding category conditions are determined according to the classified request data, corresponding internal judgment conditions are generated, corresponding conclusions are obtained through calculation of command decision rules and the internal judgment conditions, wherein the command decision rules are obtained through loading a command decision database, the data in the command decision database are modified to realize dynamic update of the command decision rules, and finally corresponding action instructions obtained according to the conclusions are sent to the business logic model, so that the business logic model generates new request data. By adopting the method, the command decision model is separated from the command decision data, the development quantity of the code of the command decision model is greatly reduced, and the operation efficiency and expandability are improved.

Description

Command decision acquisition method, system and device for confrontation system simulation model

Technical Field

The present application relates to the field of computer simulation technology, and in particular to a method, system and device for acquiring command decisions of a confrontation system simulation model.

Background Art

When simulating an adversarial system, the command decision system mainly consists of experts in related fields who first define the command decision logic, and then developers implement the command decision. It has low reusability and takes a long time to modify. The data and model are coupled together, and the command decision cannot be modified independently. The command decision often requires multiple adjustments during the training and deduction process, and its scientific nature and reusability cannot be verified.

Summary of the invention

Based on this, it is necessary to provide a command decision acquisition method, system and equipment for a highly reusable confrontation system simulation model to address the above technical problems.

A command decision acquisition method for a confrontation system simulation model, the method comprising:

Obtaining current request data output by the business logic model in the adversarial system simulation model;

Conditionally classifying the current request data, and determining conditions of corresponding categories according to the classified request data, and generating corresponding internal determination conditions;

According to the internal judgment condition, a corresponding conclusion is calculated using a command decision rule, wherein the command decision rule is obtained by loading a command decision database, and the data in the command decision database is modified to realize dynamic update of the command decision rule, wherein the command decision database includes a rule type and a rule condition corresponding to each rule type, wherein the rule type includes a condition classification type of the current request data, and the rule condition is composed of a logical symbol and a condition identifier;

A corresponding action instruction is obtained according to the conclusion, and the action instruction is sent to the business logic model, so that the business logic model generates new request data.

In one embodiment, the current request data includes confrontation events, confrontation environments, and superior and subordinate instructions;

The conditional classification of the current request data, and determining the conditions of the corresponding categories according to the classified request data, and generating the corresponding internal determination conditions include:

Classifying different data in the current request data according to our condition type, the opponent's condition type, the meteorological condition type, and the terrain condition type;

The classified data is judged according to the specific contents of the plurality of preset conditions of corresponding types, the preset conditions to which the data belongs are determined, and the preset conditions are converted into the internal determination conditions.

In one embodiment, the internal determination condition is composed of: an identifier representing a condition category and an identifier representing a specific condition content of the condition category.

In one embodiment, the command decision rule is a set including a plurality of conditional decision rules;

Each of the conditional decision rules comprises a condition part and a corresponding conclusion part, wherein the condition part and the conclusion part are an atomic condition and an atomic action respectively;

Each of the atomic conditions and atomic actions is identified by a corresponding symbol, wherein each of the condition parts includes an atomic condition plus a logic symbol, and each of the atomic actions is a preset id.

In one embodiment, when loading command decision rules through the command decision database:

Define an array std::vector<tagCal> for storing loaded command decision rules, where tagCal includes three fields: type, mainId, and subId;

The decision rule character string to be loaded is traversed, and different data is added to the array according to the character content to obtain the loaded command decision rule.

In one embodiment, the calculation of the corresponding conclusion using the command decision rule according to the internal determination condition includes:

Obtain a decision type, and traverse the command decision rules according to the decision type to find a conditional decision rule corresponding to the internal determination condition;

According to the conditional decision rules found, the corresponding conclusions are obtained.

In one embodiment, the internal decision conditions generated by the current request data include multiple internal decision conditions, and at most one conclusion is obtained according to the multiple internal decision conditions.

In one embodiment, the corresponding action instructions obtained according to the conclusion include: instruction issuing instructions, situation uploading instructions and task execution instructions, wherein each of the action instructions includes a plurality of sub-actions.

The present application also provides a command decision acquisition system for a confrontation system simulation model, the system comprising:

A command decision input module is used to obtain current request data output by the business logic model in the confrontation system simulation model, conditionally classify the current request data, determine the conditions of the corresponding category according to the classified request data, generate corresponding internal judgment conditions, and send the internal judgment conditions to the command decision rule module;

The command decision rule module includes a rule calculation unit and a rule loading unit. The rule calculation unit calculates a corresponding conclusion based on the internal judgment condition using the command decision rule loaded into the rule loading unit, and sends the conclusion to the command decision result output module;

The command decision result output module is used to obtain corresponding action instructions according to the conclusion, and send the action instructions to the business logic model so that the business logic model generates new request data;

The system also includes a command decision database, and the rule loading unit loads command decision rules from the command decision database, and modifies the data in the command decision database to realize dynamic update of the command decision rules. The command decision database includes rule types and rule conditions corresponding to each rule type, wherein the rule type includes the condition classification type of the current request data, and the rule conditions are composed of logical symbols and condition identifiers.

A computer device comprises a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

Obtaining current request data output by the business logic model in the adversarial system simulation model;

Conditionally classifying the current request data, and determining conditions of corresponding categories according to the classified request data, and generating corresponding internal determination conditions;

According to the internal judgment condition, a corresponding conclusion is calculated using a command decision rule, wherein the command decision rule is obtained by loading a command decision database, and the data in the command decision database is modified to realize dynamic update of the command decision rule, wherein the command decision database includes a rule type and a rule condition corresponding to each rule type, wherein the rule type includes a condition classification type of the current request data, and the rule condition is composed of a logical symbol and a condition identifier;

A corresponding action instruction is obtained according to the conclusion, and the action instruction is sent to the business logic model, so that the business logic model generates new request data.

A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the following steps:

Obtaining current request data output by the business logic model in the adversarial system simulation model;

Conditionally classifying the current request data, and determining conditions of corresponding categories according to the classified request data, and generating corresponding internal determination conditions;

According to the internal judgment condition, a corresponding conclusion is calculated using a command decision rule, wherein the command decision rule is obtained by loading a command decision database, and the data in the command decision database is modified to realize dynamic update of the command decision rule, wherein the command decision database includes a rule type and a rule condition corresponding to each rule type, wherein the rule type includes a condition classification type of the current request data, and the rule condition is composed of a logical symbol and a condition identifier;

A corresponding action instruction is obtained according to the conclusion, and the action instruction is sent to the business logic model, so that the business logic model generates new request data.

The command decision acquisition method, system and device of the above-mentioned confrontation system simulation model obtains the current request data output by the business logic model in the confrontation system simulation model, classifies the current request data by conditions, and determines the conditions of the corresponding categories according to the classified request data, generates corresponding internal judgment conditions, and calculates the corresponding conclusions according to the internal judgment conditions using command decision rules, wherein the command decision rules are obtained by loading the command decision database, and the data in the command decision database are modified to realize the dynamic update of the command decision rules, and finally the corresponding action instructions are obtained according to the conclusions, and the action instructions are sent to the business logic model, so that the business logic model generates new request data. Such a method separates the command decision model from the command decision data, and when the command decision rules need to be dynamically updated, only the data in the database needs to be modified, which greatly reduces the amount of code development of the command decision model and improves the operation efficiency and scalability.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a flow chart of a method for acquiring command decisions of a confrontation system simulation model in one embodiment;

FIG2 is a schematic diagram of the calculation process of the command decision rule (1_3 & 1_5) in one embodiment;

FIG3 is a schematic diagram of a command decision acquisition system of a confrontation system simulation model in one embodiment;

FIG4 is a schematic diagram of the internal structure of a command entity in one embodiment;

FIG5 is a schematic diagram of call logic in a command component in one embodiment;

FIG. 6 is a diagram showing the internal structure of a computer device in one embodiment.

DETAILED DESCRIPTION

In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

In view of the existing confrontation system simulation model technology, the decision logic in the command decision system is usually pre-defined by experts in the field, and then the command decision is implemented by developers. Its reusability is low, the modification takes a long time, the data and the model are coupled together, and the command decision cannot be modified separately. The command decision often needs to be adjusted many times during the training and deduction process, and its scientificity and reusability cannot be verified. In this paper, as shown in Figure 1, a command decision acquisition method for a confrontation system simulation model is provided, including the following steps:

Step S100, obtaining current request data output by the business logic model in the adversarial system simulation model.

Step S110 , conditionally classify the current request data, determine the conditions of the corresponding categories according to the classified request data, and generate corresponding internal determination conditions.

Step S120, according to the internal judgment conditions, the corresponding conclusion is calculated using the command decision rules, wherein the command decision rules are obtained by loading the command decision database, and the data in the command decision database is modified to realize the dynamic update of the command decision rules. The command decision database includes rule types and rule conditions corresponding to each rule type, wherein the rule type includes the condition classification type of the current request data, and the rule conditions are composed of logical symbols and condition identifiers.

Step S130, obtaining corresponding action instructions according to the conclusion, and sending the action instructions to the business logic model, so that the business logic model generates new request data.

In this embodiment, the above method is implemented in a command decision model or system. The model and the business logic model are both components of the adversarial system simulation model. The business logic model performs corresponding actions according to the action instructions output by the command decision model, generates real-time request data through internal logic, and then the command decision model calculates the corresponding action based on the new request data.

In this embodiment, a method of separating the command decision model from the command decision data is adopted, which has the effects of reducing development complexity, improving maintenance efficiency, enhancing system scalability, realizing dynamic updates, facilitating rule management, improving operation efficiency, data-driven decision-making, and reducing coupling. Among them, reducing development complexity: the command decision rules are stored in the database instead of being directly written into the code, so that when the rules need to be updated, there is no need to modify the model code, only the rule data in the database needs to be modified. This greatly reduces the development workload and complexity and reduces the probability of errors. Improving maintenance efficiency: when business requirements change and command decision rules need to be modified or added, the database can be directly operated to update the rule data without recompiling and deploying the code. This greatly improves the maintenance efficiency and response speed of the system. Enhancing system scalability: separating the rules from the model, so that when the system adds new functions or expands existing functions, it only needs to update the rule data in the database without modifying the existing model code. Such a design makes the system have good scalability and flexibility. Realizing dynamic updates: Since the rules are stored in the database, real-time or scheduled rule updates can be realized without downtime maintenance, thereby ensuring the high availability and continuity of the system. Facilitate rule management: Centrally manage the rules through the database, which makes it easier to view, modify, version control and rollback the rules, improving the efficiency and standardization of rule management. Improve operational efficiency: Since the rules are stored in the database, the command decision model can directly obtain the latest rule data from the database during operation, avoiding the additional calculation and judgment overhead caused by hard-coded rules in the code, thereby improving the operational efficiency of the system. Data-driven decision-making: Separating rules from data makes command decisions more data-driven. By analyzing and mining data, rules can be continuously optimized and adjusted to improve the scientificity and accuracy of decisions. Reduce coupling: This design method reduces the coupling between model code and rules, making the model more modular and clearly structured, which is conducive to collaborative development and continuous evolution of the system. This method separates the command decision model from the command decision data, which brings significant advantages in development, maintenance, expansion and operation, and helps to build an efficient, flexible and easy-to-maintain command decision system.

In step S100, the current request data can be classified into three types: confrontation events, confrontation environments, and superior-subordinate instructions. Further, in step S110, the current request data is conditionally classified, and the conditions of the corresponding categories are determined according to the classified request data, and the corresponding internal judgment conditions are generated, including: different data in the current request data are classified according to our condition type, the opponent's condition type, the meteorological condition type, and the terrain condition type, and then the classified data is judged according to the specific contents of multiple preset conditions of the corresponding type, the preset conditions to which the data belongs are determined, and converted into internal judgment conditions.

In this embodiment, step S110 is actually a process of converting the current request data into conditions in a preset command decision rule.

Specifically, according to the four condition types, the three types of request data in the request data, namely, confrontation events, confrontation environments, and superior-subordinate instructions, are first classified into our condition type, the opponent's condition type, the meteorological condition type, and the terrain condition type. Among them, the conditions in our condition type specifically describe the decision points of our strength conditions during the confrontation process, and the conditions in the opponent's condition type mainly describe the decision points of the opponent's strength conditions during the confrontation process. The meteorological condition type and the terrain condition type respectively describe the decision points of meteorological-related conditions such as temperature, humidity, rain, and snow during the confrontation process, as well as the decision points of terrain conditions such as plains, swamps, and mountains.

Next, the specific conditions under various condition types are determined based on the specific condition contents under the various condition types, and the specific conditions under a certain condition type are converted into internal judgment conditions.

In this embodiment, the internal judgment condition is composed of: an identifier representing the condition category and an identifier representing the specific condition content of the condition category. For example, our condition type is represented by the digital identifier "1", and a specific condition content under the condition type is also represented by the corresponding digital identifier, that is, different condition contents are represented by different data, and the internal judgment condition "1-3" is represented as: our condition 3. Different condition contents under various condition types can be stored in a table form, that is, the digital identifier "3" here can find the corresponding condition specific content according to the corresponding table. For example, the internal judgment condition "our condition 3" indicates whether the opponent is found, "our condition 4" indicates whether the opponent is in our strike area, and "our method condition 6" indicates whether we are defeated by the opponent, etc.

Therefore, when the current request data is subjected to conditional conversion, the form of the conditional type can be extracted according to the conditional category obtained by classification, and the consistent conditional content can be searched therefrom to obtain the corresponding specific conditional content identifier.

In step S120, the command decision rule is a set of multiple conditional decision rules, each conditional decision rule includes a condition part and a corresponding conclusion part, wherein the condition part and the conclusion part are atomic conditions and atomic actions respectively, and each atomic condition and atomic action are identified by corresponding symbols, wherein each condition part includes an atomic condition plus a logical symbol, and each atomic action is a preset id.

Specifically, according to the internal judgment conditions, the corresponding conclusion is calculated using the command decision rule, including: obtaining the decision type, traversing the command decision rule according to the decision type, finding the conditional decision rule corresponding to the internal judgment condition, and finally obtaining the corresponding conclusion according to the found conditional decision rule.

In this embodiment, in order to solve the problem that the command decision rules cannot be dynamically updated due to the coupling between the command decision model and the command decision rule data, in this method, additional command decision rule data is used. Before the model simulation, it can be loaded into the command decision model, and after one simulation is completed, the command decision rule data is updated according to the simulation results, and then the updated command decision rule data is loaded into the command decision rule, and the updated command decision rule data can be used in the next simulation process. This overcomes the problem that the coupling between codes will be reduced due to the separation of data and model, thereby greatly reducing the amount of command decision model code development and improving scalability. In addition, in the decision-making process, the corresponding command decision rule will be judged according to the specific message, which can improve the operating efficiency to a certain extent.

Specifically, the command decision database is divided into rule types and rule conditions. Among them, the rule type corresponds to the condition type of our side, the condition type of the opponent side, the meteorological condition type and the terrain condition type of the current request data, and defines different type identifiers respectively. The rule condition is mainly the specific conditions within each type of rule, which consists of a series of logical symbols and condition identifiers. The logical symbols are mainly composed of logical or (represented as | in the database), logical and (represented as & in the database), logical not (represented as ! in the database) and logical priority (represented as () in the database). The condition identifier is m_n, where m is the condition type and n is the condition id under the current type.

In this embodiment, the command decision database is divided into rule types and rule conditions, which enables the command decision database to have flexible rule management. By separating rule types and rule conditions, different types of rules can be flexibly managed and expanded. This structure allows new rule types to be added or existing rule types to be modified without changing the overall system architecture. At the same time, the rule conditions are composed of logical symbols and conditional identifiers, making the rule expression more intuitive and easy to understand. The command decision database can be dynamically updated. When business needs change, rule conditions can be added, deleted or modified directly in the database without changing the system code. This dynamic update capability enables the system to adapt to changes quickly and improves response speed. The database structure facilitates version management of rules, and can easily trace back to previous versions to ensure the security and reliability of rule updates.

Furthermore, through structured rule storage, the system can use efficient database query optimization strategies to reduce the computational overhead of rule matching, thereby improving the overall performance of the system. For commonly used rule conditions, a caching mechanism can be implemented to further improve the speed of rule query and execution.

When analyzing the conditional decision, the three fields ActionId, DescisionId, and Condition are loaded from tbl_decision_condition. ActionId indicates the action ID, DescisionId indicates the decision type, and Condition indicates the condition rule. Each data in this table corresponds to a specific conditional decision rule. When analyzing, the main thing is to decompose the string corresponding to Condition into rules and save them.

Specifically, an idea for loading decision rule data is provided. First, an array std::vector<tagCal> for storing the loaded command decision rules is defined, wherein tagCal includes three fields: type, mainId, and subId. Then, the decision rule string to be loaded is traversed, and different data is added to the array according to the character content to obtain the loaded command decision rules.

Specifically, first define a std::vector<tagCal> array A (the tagCal structure has a total of 3 fields (type, mainId, subId), and the array A is the modified command decision rule. type 0 represents ‘(’, type 1 represents ‘)’, type 2 represents ‘&’, type 3 represents ‘|’, and type 4 represents ‘!’), and traverse the decision rule string;

If the current character is ‘(’, add a data {0,0,0} to the end of array A;

If the current character is ‘)’, add a data {1,0,0} to the end of array A;

If the current character is ‘&’, add a piece of data {2,0,0} to the end of array A;

If the current character is '|', add a piece of data {3,0,0} to the end of array A;

If the current character is ‘!’, add a piece of data {4,0,0} to the end of array A;

Otherwise, find the string m_n, where m and n can contain multiple characters but must be all numbers, and add a data {5,m,n} to the end of the A array, where m represents the condition type and n represents the condition id corresponding to the condition type. When m is 1, it means it is our condition, when m is 2, it means the opponent's condition, when m is 3, it means the terrain condition, and when m is 4, it means the weather condition. For example, 1_4 is {5,1,4} in the A array, which means [our situation 4] whether the opponent is in our strike area.

Furthermore, the command decision rule is judged whether it is achieved. According to the incoming message (condition), the decision type corresponding to the message is obtained, and the corresponding decision rule is judged according to the decision type. After calculation, at most one decision action is obtained, that is, the corresponding conclusion. If there is a decision action, the corresponding decision action is executed, otherwise it is returned directly.

In this embodiment, a main idea for determining whether a decision rule is achieved is also provided, as shown in FIG2 :

1. Use two stacks to maintain the calculation process: a ‘bool’ stack to store conditional flags; an operator stack to store the four operators ‘&’, ‘|’, ‘(’ and ‘)’;

2. Traverse the std::vector<tagCal> array A;

3. If the current number is (5, m, n). If the operator stack is empty or the top element is ‘(’, push the current condition flag into the ‘bool’ stack; if the top element of the operator stack is ‘&’ or ‘|’, pop a flag from the ‘bool’ stack and perform ‘&’ or ‘|’ operation with the current condition flag, and push the result into the ‘bool’ stack; if the current operator is ‘!’, the current condition flag is negated, the result is used as the condition flag, and the execution jumps to the third step;

4. If the current symbol is ‘&’ (2,0,0), push the current symbol into the symbol stack;

5. If the current symbol is ‘|’(3,0,0), push the current symbol into the symbol stack;

6. If the current symbol is ‘!’(4,0,0), push the current symbol into the symbol stack;

7. If the current symbol is ‘(’(0,0,0), push the current symbol into the symbol stack;

8. If the current value is ‘)’ (1, 0, 0), pop the top ‘(’ symbol from the symbol stack. If the symbol stack is not empty and the top symbol is ‘&’, pop 2 flags from the bool stack, pop the top symbol from the symbol stack, perform ‘&’ operation, and push the result into the bool stack; if the symbol stack is not empty and the top symbol is ‘|’, pop 2 flags from the bool stack, pop the top symbol from the symbol stack, perform ‘|’ operation, and push the result into the bool stack; if the symbol stack is not empty and the top symbol is ‘!’, pop the top element from the bool stack for inversion operation, use the result of the operation as the conditional flag, and jump to the third step to execute.

Specifically, referring to Figure 4, when both our condition 3 and our condition 5 are met, the specific calculation process of the command decision rule (1_3&1_5) is shown; in the first step, the flag ‘true’ of 1_3 is pushed into the ‘bool’ stack; in the second step, the ‘&’ symbol is pushed into the symbol stack; in the third step, an element (‘true’) is popped from the ‘bool’ stack and the flag ‘true’ of 1_5 is & operated, where the (‘&’) symbol is popped from the symbol stack and the operation result is pushed into the ‘bool’ stack; finally, the result in the ‘bool’ stack is returned.

In this embodiment, the command component receives a message from the command entity, obtains the decision type corresponding to the current message, judges each internal judgment condition to determine whether the internal judgment condition is true, traverses the command decision rule list corresponding to the decision type, calculates at most one action, and sends it to the corresponding entity for execution.

In this embodiment, the internal decision conditions generated by the current request data include multiple ones, and at most one conclusion is obtained according to the multiple internal decision conditions.

In step S130, the corresponding action instructions obtained according to the conclusion include: instruction issuing instructions, situation uploading instructions and task execution instructions, wherein each of the action instructions includes a plurality of sub-actions.

Specifically, the conclusion library of the command decision database module mainly corresponds to action identifiers. The action identifiers are mainly divided into three categories: command issuance actions, task execution actions, and situation upload actions. Each category is identified by a special identifier, and each category of actions can be divided into several specific actions. Action representations are usually letters or symbols with special meanings.

Therefore, the action identifier of the conclusion library consists of an action class identifier and an action identifier, which are usually connected by "_". The action identifier appears in pairs with the conditions in the rule library, that is, one conditional expression corresponds to one action identifier.

Furthermore, after obtaining the action instruction corresponding to the conclusion, it is input into the business logic model so that it executes the action instruction and performs corresponding logical operations to obtain new request data, and the command decision model generates new action instructions based on the request data.

In the command decision acquisition method of the above-mentioned confrontation system simulation model, by acquiring the current request data output by the business logic model in the confrontation system simulation model, the current request data is conditionally classified, and the conditions of the corresponding categories are determined according to the classified request data, and the corresponding internal judgment conditions are generated. According to the internal judgment conditions, the command decision rules are used to calculate the corresponding conclusions, wherein the command decision rules are obtained by loading the command decision database, and the data in the command decision database is modified to realize the dynamic update of the command decision rules. Finally, the corresponding action instructions are obtained according to the conclusions, and the action instructions are sent to the business logic model, so that the business logic model generates new request data. The use of such a method separates the command decision model from the command decision data. When the command decision rules need to be dynamically updated, only the data in the database needs to be modified, which greatly reduces the development of the command decision model code and improves the operation efficiency and scalability.

It should be understood that, although the various steps in the flowchart of FIG. 1 are shown in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a portion of the steps in FIG. 1 may include a plurality of sub-steps or a plurality of stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

As shown in FIG3 , in this embodiment, a command decision acquisition system for a confrontation system simulation model is also provided, and the system includes: a command decision input module, a command decision rule module, and a command decision result output module.

Among them, the command decision input module is used to obtain the current request data output by the business logic model in the confrontation system simulation model, classify the current request data by conditions, determine the conditions of the corresponding category according to the classified request data, generate the corresponding internal judgment conditions, and send the internal judgment conditions to the command decision rule module.

The command decision rule module includes a rule calculation unit and a rule loading unit. The rule calculation unit calculates the corresponding conclusion based on the internal judgment conditions using the command decision rules loaded into the rule loading unit, and sends the conclusion to the command decision result output module.

The command decision result output module is used to obtain the corresponding action instructions according to the conclusion, and send the action instructions to the business logic model, so that the business logic model generates new request data.

The system also includes a command decision database, and a rule loading unit loads command decision rules from the command decision database, and modifies the data in the command decision database to realize dynamic update of the command decision rules. The command decision database includes rule types and rule conditions corresponding to each rule type, wherein the rule type includes the condition classification type of the current request data, and the rule conditions are composed of logical symbols and condition identifiers.

In this embodiment, command decision data is stored in the sqlite relational database. The sqlite database is a lightweight embedded database. It is open source, free, cross-platform, robust and efficient. It is one of the most widely used databases in the field of stand-alone database development. It is easy to deploy and only needs to copy the corresponding database file to the specified place. The program can load the sqlite database information through the file.

Specifically, the command decision data storage includes our condition table, opponent condition table, terrain condition table, weather condition table, action table and command decision rule table. Among them, our condition table, opponent condition table, terrain condition table, weather condition table and action table are composed of ID number and corresponding specific content. The decision rule table includes ID number, action ID number, decision ID number, rules, and corresponding content, for example:

ID number: 1; Action ID number: 1; Decision ID number: 1; Rules: 1_1&2_1&3_1;

Corresponding content: [[Our situation 1] We are on the march] & [[Weather condition 1] Heavy fog] -> Fast movement route (60%).

ID: 2; Action ID: 2; Decision ID: 1; Rules: 1_1&2_1&3_2;

Corresponding content: [[Our situation 1] I am on the march] & [[Weather condition 1] Heavy snow] -> Fast movement route (50%).

ID: 3; Action ID: 3; Decision ID: 2; Rule: 1_2;

Corresponding content: [Our situation 2] -> Give subordinates orders to attack the enemy.

ID: 4; Action ID: 4; Decision ID: 2; Rule: 1_3;

Corresponding content: [Our situation 3] -> Issue maneuvering instructions to subordinates according to the path points.

In this embodiment, the command decision rule module can be displayed by the command decision entity shown in Figure 4. The command decision component module is triggered by a message and selects the corresponding decision type for decision making according to the message. The conditional decision rules contained in the current decision type are traversed and judged, and at most one decision result is generated. Each message has a corresponding decision type, which will improve performance to a certain extent.

The decision result is generally various combat instructions for the action entity that has a command relationship with the command entity. For example, maneuver instructions, strike instructions, etc. The issuance of this instruction needs to go through the internal command business flow of the command entity model, and then be sent to the corresponding action entity model, that is, the business logic model, for execution. This process is a continuous cycle. The flow of external command business drives the operation of the entire confrontation system model back and forth, and forms new confrontation situations and decision conditions through different entity models. These confrontation situations further drive the flow logic of the command decision business of the command entity model, and constantly make the command entity model produce new decision content.

The command entity module is used to load the decision model component, receive external interactions and timed planning events, call the decision component to make decisions, and send corresponding interactions to other entities based on the decision message.

The component in FIG4 is the command decision component, which can be understood as the rule calculation unit in the command decision rule module, and its workflow is shown in FIG5 .

Specifically, the command decision component is mounted on the command entity, and the command decision rule module is called by the command decision component.

Example 1: The command entity schedules the event Tick and sends a tick message to the command decision component. After receiving the tick message, the command decision component reads some attributes of the entity and updates the corresponding internal condition status according to the attributes. Suppose that our condition 1 is met, the opponent's condition 1 is met, and the terrain condition 2 is met. Because the internal definition of the tick message is input decision type 1, it will traverse decision rules 1 and 2, and finally calculate that the decision id 2 is met, and the action with actionId 2 will be executed.

Example 2: When the command entity receives a mobile command from its superior, it will send a move message to the command decision component. When the command decision component receives the move message, it will update the corresponding condition status. Assume that when the move message is received, our condition 3 will be set to true. Because the internal definition of the move message belongs to decision type 2, it will traverse decision rules 3 and 4, and finally find that decision 4 is reached, and will execute the action with actionId 4.

In this embodiment, the command decision input module actually implements the specific contents of step S100 and step S110 in the command decision acquisition method of the above-mentioned confrontation system simulation model, while the command decision rule module implements the specific contents of step S120 in the above-mentioned method, and the command decision result output module implements the specific contents of step S130 in the above-mentioned method. For the specific limitations of the command decision acquisition system of the confrontation system simulation model, please refer to the limitations of the command decision acquisition method of the confrontation system simulation model in the above text, which will not be repeated here.

Each module in the command decision acquisition system of the above-mentioned confrontation system simulation model can be implemented in whole or in part by software, hardware and their combination. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the corresponding operations of each of the above modules.

In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be shown in FIG6. The computer device includes a processor, a memory, a network interface, a display screen, and an input device connected via a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a command decision acquisition method for a confrontation system simulation model is implemented. The display screen of the computer device may be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device may be a touch layer covered on the display screen, or a key, trackball or touchpad provided on the housing of the computer device, or an external keyboard, touchpad or mouse, etc.

Those skilled in the art will understand that the structure shown in FIG. 6 is merely a block diagram of a partial structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

In one embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:

Obtaining current request data output by the business logic model in the adversarial system simulation model;

Conditionally classifying the current request data, and determining conditions of corresponding categories according to the classified request data, and generating corresponding internal determination conditions;

According to the internal judgment condition, a corresponding conclusion is calculated using a command decision rule, wherein the command decision rule is obtained by loading a command decision database, and the data in the command decision database is modified to realize dynamic update of the command decision rule, wherein the command decision database includes a rule type and a rule condition corresponding to each rule type, wherein the rule type includes a condition classification type of the current request data, and the rule condition is composed of a logical symbol and a condition identifier;

A corresponding action instruction is obtained according to the conclusion, and the action instruction is sent to the business logic model, so that the business logic model generates new request data.

In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

Obtaining current request data output by the business logic model in the adversarial system simulation model;

Conditionally classifying the current request data, and determining conditions of corresponding categories according to the classified request data, and generating corresponding internal determination conditions;

According to the internal judgment condition, a corresponding conclusion is calculated using a command decision rule, wherein the command decision rule is obtained by loading a command decision database, and the data in the command decision database is modified to realize dynamic update of the command decision rule, wherein the command decision database includes rule types and rule conditions corresponding to each rule type, wherein the rule type includes a condition classification type of the current request data, and the rule condition is composed of a logical symbol and a condition identifier;

A corresponding action instruction is obtained according to the conclusion, and the action instruction is sent to the business logic model, so that the business logic model generates new request data.

Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application may include non-volatile and/or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

The technical features of the above embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims (10)

1. A command decision acquisition method for a confrontation system simulation model, characterized in that the method comprises: Obtaining current request data output by the business logic model in the adversarial system simulation model; Conditionally classifying the current request data, and determining conditions of corresponding categories according to the classified request data, and generating corresponding internal determination conditions; According to the internal judgment condition, a corresponding conclusion is calculated using a command decision rule, wherein the command decision rule is obtained by loading a command decision database, and the data in the command decision database is modified to realize dynamic update of the command decision rule, wherein the command decision database includes a rule type and a rule condition corresponding to each rule type, wherein the rule type includes a condition classification type of the current request data, and the rule condition is composed of a logical symbol and a condition identifier; A corresponding action instruction is obtained according to the conclusion, and the action instruction is sent to the business logic model, so that the business logic model generates new request data. 2. The command decision acquisition method according to claim 1, characterized in that the current request data includes confrontation events, confrontation environments, and superior and subordinate instructions; The conditional classification of the current request data, and determining the conditions of the corresponding categories according to the classified request data, and generating the corresponding internal determination conditions include: Classifying different data in the current request data according to our condition type, the opponent's condition type, the meteorological condition type, and the terrain condition type; The classified data is judged according to the specific contents of the plurality of preset conditions of corresponding types, the preset conditions to which the data belongs are determined, and the preset conditions are converted into the internal determination conditions. 3. The command decision acquisition method according to claim 2 is characterized in that the internal judgment condition is composed of: an identifier representing the condition category and an identifier representing the specific condition content of the condition category. 4. The command decision acquisition method according to claim 3, characterized in that the command decision rule is a set of multiple conditional decision rules; Each of the conditional decision rules comprises a condition part and a corresponding conclusion part, wherein the condition part and the conclusion part are an atomic condition and an atomic action respectively; Each of the atomic conditions and atomic actions is identified by a corresponding symbol, wherein each of the condition parts includes an atomic condition plus a logic symbol, and each of the atomic actions is a preset id. 5. The command decision acquisition method according to claim 4, characterized in that when loading command decision rules through the command decision database: Define an array std::vector<tagCal> for storing loaded command decision rules. Among them, tagCal includes three fields: type, mainId, and subId; The decision rule character string to be loaded is traversed, and different data is added to the array according to the character content to obtain the loaded command decision rule. 6. The command decision acquisition method according to claim 5, characterized in that the step of calculating the corresponding conclusion using the command decision rule according to the internal judgment condition comprises: Obtain a decision type, and traverse the command decision rules according to the decision type to find a conditional decision rule corresponding to the internal determination condition; According to the conditional decision rules found, the corresponding conclusions are obtained. 7. The command decision acquisition method according to claim 6 is characterized in that the internal decision conditions generated by the current request data include multiple internal decision conditions, and at most one conclusion is obtained based on the multiple internal decision conditions. 8. The command decision acquisition method according to claim 7 is characterized in that the corresponding action instructions obtained according to the conclusion include: command issuance instructions, situation upload instructions and task execution instructions, wherein each of the action instructions is composed of multiple sub-actions. 9. A command decision acquisition system for a confrontation system simulation model, characterized in that the system comprises: A command decision input module is used to obtain current request data output by the business logic model in the confrontation system simulation model, conditionally classify the current request data, determine the conditions of the corresponding category according to the classified request data, generate corresponding internal judgment conditions, and send the internal judgment conditions to the command decision rule module; The command decision rule module includes a rule calculation unit and a rule loading unit. The rule calculation unit calculates a corresponding conclusion based on the internal judgment condition using the command decision rule loaded into the rule loading unit, and sends the conclusion to the command decision result output module; The command decision result output module is used to obtain corresponding action instructions according to the conclusion, and send the action instructions to the business logic model so that the business logic model generates new request data; The system also includes a command decision database, and the rule loading unit loads command decision rules from the command decision database, and modifies the data in the command decision database to realize dynamic update of the command decision rules. The command decision database includes rule types and rule conditions corresponding to each rule type, wherein the rule type includes the condition classification type of the current request data, and the rule conditions are composed of logical symbols and condition identifiers. 10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein the processor implements the steps of the method according to any one of claims 1 to 8 when executing the computer program.