A method and system for recording the process of volleyball matches based on rule events.

Abstract

This application provides a method and system for recording the process of volleyball matches based on rule events, relating to the field of sports recording technology. The method includes: constructing a global state machine for the volleyball match, including a finite set of states such as normal match state, challenge ruling state, and substitution process state, and configuring a corresponding set of allowed event types and a set of prohibited event types for each state; obtaining the current global state of the system and receiving rule events submitted by any terminal from multiple terminals, including score change events, substitution events, challenge events, and libero substitution events; performing a first-level filtering on the received rule events according to the set of allowed event types corresponding to the current global state; in the second-level processing, performing inter-event mutual exclusion arbitration on the rule events and deciding whether to execute or reject them based on the arbitration result; when any rule event is successfully executed, if the rule event triggers a state transition condition, updating the global state according to a preset state transition rule.

Description

Technical Field

[0001] This invention belongs to the field of sports recording technology, specifically relating to a method and system for recording the process of volleyball matches based on rule events. Background Technology

[0002] In the digital recording of volleyball matches, existing systems typically employ multi-terminal input, allowing referees, scorekeepers, or statisticians to submit rule events (such as score changes, substitutions, and challenges) in parallel from different terminals. However, due to the strict state dependencies and timing constraints of volleyball rules (e.g., substitutions are prohibited during challenge decisions, or score changes are not allowed until the substitution process is complete), the system lacks a unified verification mechanism based on the current overall match state when events are submitted independently by each terminal. This leads to the following prominent technical problems: When multiple terminals simultaneously or sequentially submit mutually exclusive rule events at the boundary state of the competition process, existing methods only rely on the event reception timestamp for post-event sequential recording. They cannot perform pre-filtering and real-time conflict arbitration based on the legal state-event association relationship defined by the competition rules. This can easily lead to erroneous records that contradict the actual competition process (e.g., incorrectly executing a substitution event before the challenge result is determined). This results in inconsistent data recorded by multiple terminals, high post-event error correction costs, and failure of real-time synchronization. Summary of the Invention

[0003] In view of the above-mentioned defects or deficiencies in the prior art, a method and system for recording the process of volleyball matches based on rule events are provided.

[0004] Firstly, this application proposes a method for recording the process of a volleyball match based on rule events, comprising the following steps: Construct a global state machine for volleyball matches. The global state machine defines a finite set of states including normal match state, challenge ruling state, and substitution process state, and configures a corresponding set of allowed event types and a set of prohibited event types for each state. The system can obtain the current global status of the system in real time and receive rule events submitted by any terminal from multiple terminals. The rule events include score change events, substitution events, challenge events, and free agent substitution events. Based on the set of allowed event types corresponding to the current global state, perform the first level of filtering on the received rule events: If the event type of the rule event belongs to the set of allowed event types in the current state, then the event is sent to the second level of processing; If the event belongs to the prohibited event type set, the event will be refused to be executed, a rejection message will be returned to the submitting terminal, and the event will not be recorded as an executed event. In the second-level processing, mutual exclusion arbitration is performed on the submitted rule events, and the decision to execute or reject is made based on the arbitration result; When any rule event is successfully executed, if the rule event triggers the state transition condition, the global state is updated according to the preset state transition rule, and the state change notification is broadcast to all terminals so that each terminal synchronizes the current global state.

[0005] According to the technical solution provided in this application, the mutual exclusion arbitration between submitted rule events includes the following steps: Establish an event mutual exclusion matrix, which is an N×N Boolean matrix, where N is the total number of event types, and the matrix element M[i][j]=1 indicates that the i-th type of event and the j-th type of event are mutually exclusive; When two rule events from different terminals are received in the same global state, it is determined whether they are mutually exclusive by querying the mutual exclusion matrix: If the corresponding element of the mutex matrix is ​​0, then the two events will be executed in the order they are received. If the corresponding element of the mutual exclusion matrix is ​​1, the concurrent arbitrator is triggered.

[0006] According to the technical solution provided in this application, the concurrent arbitrator includes: Each arriving event is appended with a globally incrementing sequence number based on an atomic counter, which serves as the total sequence identifier for the event; The two mutually exclusive events are temporarily stored in a thread-safe blocking queue, and the execution order is determined according to the globally incrementing sequence number, with the one with the smaller sequence number being executed first. When executing a priority event, set a mutex semaphore to lock the resource group associated with that event type; After the priority event is completed, the mutex semaphore is released, and the first type of state parameters on which the subsequent event depends are re-verified to be still valid. The first type of state parameters include the player's on-field position identifier, the libero's available number of times counter, and the substitution number of times counter. If the verification passes, the next event is executed; if the verification fails, the event is discarded and a status code containing the reason for the failure is generated and returned to the source terminal.

[0007] According to the technical solution provided in this application, before determining the execution order based on the globally incrementing sequence number, the concurrent arbitrator further includes the following steps: A basic priority weight is pre-configured for each type of mutually exclusive event. The basic priority weight is set according to the volleyball game rules, wherein the basic priority of the libero substitution event is higher than that of the normal substitution event. When two mutually exclusive events are temporarily stored in the blocking queue, the system obtains the current second type of status parameters, which include the current score, the remaining challenge attempts in the current round, the remaining available attempts for the free agent, and the remaining attempts for substitution. Based on the basic priority weights and the second type of state parameters, the dynamic priority value of each mutual exclusion event is calculated using a weighted formula. Determining the execution order based on the globally incrementing sequence number includes the following steps: If the dynamic priority values ​​of each mutual exclusion event are equal, the execution order is determined according to the global incrementing sequence number.

[0008] According to the technical solution provided in this application, after calculating the dynamic priority value of each event using a weighted formula, the method further includes the following steps: If the dynamic priority values ​​of two mutually exclusive events are not equal, the following priority arbitration steps are performed: Events with higher dynamic priority values ​​are designated as priority events, while those with lower values ​​are designated as delayed events. Before executing the priority event, an immutable snapshot copy is created for the first type of state parameters on which the delayed event depends, the snapshot copy including the field values ​​corresponding to the first type of state parameters; Execute the priority event and update the first type of state parameters in real time; After the priority event has been executed, the portion of the updated first type of status parameters related to the delayed event is compared field by field with the snapshot copy: If the values ​​of all first-class state parameters are the same as the field values ​​corresponding to the snapshot copy, then the delayed event is executed directly.

[0009] According to the technical solution provided in this application, after comparing the portion of the updated first type of state parameters related to the delayed event with the snapshot copy field by field, the method further includes the following steps: If at least one first-class state parameter has a value that is different from the field value corresponding to the snapshot copy, then these first-class state parameters are marked as target state parameters and input into the rule engine; The rule engine determines, based on the volleyball rules, whether the target state parameters on which the delayed event depends still meet the execution conditions. If the execution conditions are met, then the delayed event is executed; If the execution conditions are not met, the delayed event is discarded and a structured log entry is generated. The structured log entry includes: the event identifier of the priority event, the event identifier of the delayed event, the failure reason code, and the values ​​of the target state parameter before and after the change. This structured log entry is appended to the competition event log chain to form a priority causal record.

[0010] According to the technical solution provided in this application, before comparing the part of the updated first type of state parameters related to the delayed event with the snapshot copy field by field, the following steps are also included: Based on the event type of the delayed event, the dependency parameter mask corresponding to the event type is read from the pre-stored dependency parameter mask table. The dependency parameter mask is a binary vector, with each bit corresponding to a first type of state parameter. A mask bit of 1 indicates that the parameter is depended on by the delayed event. Based on the dependency parameter mask, a subset of dependent parameters is selected from the updated first type of state parameters; The step of comparing the portion of the updated first type of state parameters related to the delayed event with the snapshot copy field by field includes the following steps: Each parameter in the subset of parameters to be relied upon is compared one by one with the value of the corresponding parameter in the snapshot copy.

[0011] According to the technical solution provided in this application, the step of executing the delayed event if the execution conditions are met includes the following steps: After determining that the delayed event meets the execution conditions, the original event parameter set carried by the delayed event is obtained. The original event parameter set includes the event operation object identifier and the expected value of resource consumption. Based on the difference between the changed value of the target state parameter and the corresponding value in the snapshot copy, a state offset mapping table is generated. The state offset mapping table records the identifier of each type of first-class state parameter that has changed and its mapping relationship before and after the change. Based on the state offset mapping table, a parameter semantic redirection operation is performed on the original event parameter set to eliminate the semantic conflict between the original event parameter set and the current global state caused by the change of the first type of state parameters due to the execution of priority events. The delayed event is executed using the parameter set corrected by the parameter semantic redirection operation.

[0012] According to the technical solution provided in this application, the step of performing parameter semantic redirection operation on the original event parameter set specifically includes at least one of the following processing logics: The first redirection logic, in response to the delayed event being a substitution event, and the state offset mapping table indicating that the target on-field position identifier of the substituted player has been modified by the priority event, then according to the changed position identifier in the state offset mapping table, queries the on-field player identifier corresponding to the position identifier in the current global state, and replaces the replaced player identifier in the original parameter set of the event with the queried on-field player identifier. The second redirection logic, in response to the delayed event being a free agent replacement event and the state offset mapping table indicating that the free agent's remaining available count counter has been decremented to zero, marks the expected resource consumption value in the original parameter set of the event as an invalid value and attaches a prohibition flag, so that in the step of executing the delayed event using the parameter set corrected by the parameter semantic redirection operation, in response to the recognition of the prohibition flag, the execution operation of the delayed event is skipped.

[0013] Secondly, this application proposes a volleyball match process recording system based on rule events, used to implement the above-described method, including: The construction module is configured to build a global state machine for volleyball matches. The global state machine defines a finite set of states, including normal match state, challenge ruling state, and substitution process state, and configures a corresponding set of allowed event types and a set of prohibited event types for each state. The acquisition module is configured to acquire the current global status of the system in real time and receive rule events submitted by any terminal among multiple terminals. The rule events include score change events, substitution events, challenge events, and free agent substitution events. The filtering module is configured to perform first-level filtering on the received rule events based on the set of allowed event types corresponding to the current global state. If the event type of the rule event belongs to the set of allowed event types in the current state, then the event is sent to the second level of processing; If the event belongs to the prohibited event type set, the event will be refused to be executed, a rejection message will be returned to the submitting terminal, and the event will not be recorded as an executed event. An arbitration module is configured to perform inter-event mutual exclusion arbitration on the submitted rule events in the second-level processing, and decide whether to execute or reject the event based on the arbitration result. The update module is configured to update the global state according to the preset state transition rules when any rule event is successfully executed, if the rule event triggers the state transition condition, and broadcast the state change notification to all terminals so that each terminal synchronizes the current global state.

[0014] Compared with the prior art, the beneficial effects of this application are as follows: I. Enhancing the Compliance and Accuracy of Rule Event Recording: By constructing a global state machine encompassing normal match status, challenge ruling status, and substitution process status, and pre-setting allowed / prohibited event types for each status, the system can perform pre-rule verification immediately upon event submission. Any event that does not conform to the current legal match status is rejected at the entry point, fundamentally eliminating the recording of violations due to status oversight, and ensuring that the recorded event sequence strictly adheres to the volleyball competition rules.

[0015] II. Resolving Logical Conflicts Under Multi-Terminal Concurrent Operations: A mutual exclusion arbitration mechanism is introduced in the second-level processing to further verify the compatibility of events that have passed the first-level filtering with submitted pending events or currently executing processes. Even if multiple terminals submit seemingly permitted events within a very short period, the system can make the correct ruling based on the implicit priority and mutual exclusion relationships of the volleyball rules, avoiding logical contradictions that may arise from simply relying on timestamp order and ensuring the unique correctness of the match process record.

[0016] III. Achieving Strong Consistency and Low-Latency Synchronization Across Multiple Terminal Views: The global state is updated and a broadcast notification is generated only after a rule event is successfully executed and the triggering of a state transition is confirmed. This mechanism ensures that all terminals obtain the latest state and event sequence, which has been arbitrated and is causally consistent. Even in high-concurrency data entry scenarios, the competition progress and statistics displayed on each terminal interface remain strictly synchronized, eliminating operational confusion and secondary data entry errors caused by delayed state updates or rollbacks in traditional methods. Attached Figure Description

[0017] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A flowchart illustrating the steps of the volleyball match rule-based event process recording method provided in this application.

[0018] Figure 2 A schematic diagram of the structure of the volleyball match process recording system based on rule events provided in this application.

[0019] The text labels in the image represent: 1. Acquisition module; 2. Filtering module; 3. Arbitration module; 4. Update module. Detailed Implementation

[0020] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0022] Example 1 As mentioned in the background section regarding technical problems, this application proposes a method for recording the process of volleyball matches based on rule events, such as... Figure 1 As shown, it includes the following steps: S1. Construct a global state machine for volleyball matches. The global state machine defines a finite set of states including normal match state, challenge ruling state, and substitution process state, and configures a corresponding set of allowed event types and a set of prohibited event types for each state. S2. Real-time acquisition of the current global status of the system, and receipt of rule events submitted by any terminal among multiple terminals, including score change events, substitution events, challenge events and free agent substitution events; S3. Based on the set of allowed event types corresponding to the current global state, perform the first level of filtering on the received rule events: S31. If the event type of the rule event belongs to the set of allowed event types in the current state, then the event is sent to the second level of processing. S32. If the event belongs to the prohibited event type set, the event will be refused to be executed, and a rejection message will be returned to the submitting terminal. The event will not be recorded as an executed event. S4. In the second-level processing, mutual exclusion arbitration is performed on the submitted rule events, and the execution or rejection is decided based on the arbitration result. S5. When any rule event is successfully executed, if the rule event triggers the state transition condition, the global state is updated according to the preset state transition rule, and the state change notification is broadcast to all terminals so that each terminal synchronizes the current global state.

[0023] Specifically, step one: Construct the global state machine for a volleyball match: First, it's necessary to clarify the components of the global state machine. The global state machine consists of three parts: a finite set of states, a set of allowed event types for each state, and transition rules between states. The finite set of states is determined based on the time periods in a volleyball match that have specific rule constraints. After analyzing the volleyball rules, it was determined that it must include at least the following three states: Normal match status: refers to all periods during the game or when the ball is dead, excluding challenges and substitutions. During this period, the referee can blow the whistle and take various actions.

[0024] Challenge Status: This refers to the period from when the team captain or coach submits a video challenge request until the referee makes the final decision and notifies both parties. During this period, the game is suspended, and personnel changes and score records are frozen.

[0025] Substitution procedure status: This refers to the period from when the referee blows the whistle to allow a substitution until the substitute player completes the entry and exit procedures and the referee blows the whistle again to indicate that play should continue. During this period, no other substitution requests or free agent substitutions may be made.

[0026] Next, we configure the set of allowed event types for each state. This configuration is done by going through each volleyball rule one by one, with the specific logic as follows: During normal play, the rules allow substitutions and free player replacements during dead ball situations, as well as challenges in case of disputes. Score recording for valid points is also completed during this period. Therefore, the set of allowed event types during normal play includes: score changes, substitutions, challenges, and free player replacements.

[0027] Regarding the challenge-decision status, the rules explicitly state that the match is suspended during a challenge, and any personnel changes and score recordings must await the determination of the decision. Therefore, the set of permitted event types for the challenge-decision status includes only the challenge event itself (used to record the decision or withdraw the challenge); the other three types of events are prohibited.

[0028] Regarding the substitution process, the rules stipulate that no other batch of substitutions may be inserted during a single substitution, nor may a free agent substitution be made or the score recording for the next round be started. Therefore, the set of allowed event types for the substitution process only includes substitution events (used to complete or cancel the current substitution); other events are prohibited.

[0029] The aforementioned correspondences are fixed in the system's configuration data in the form of tables or rule bases. The set of prohibited event types does not need to be established separately; a prohibition conclusion can be reached by determining whether an event type belongs to the allowed set.

[0030] The state transition rules are also based on the following rules: when a challenge event is successfully executed in the normal match state, the state transitions to the challenge adjudication state; when a challenge result confirmation event is successfully executed in the challenge adjudication state, the state returns to the normal match state; when a substitution event is successfully executed in the normal match state, the state transitions to the substitution process state; when a substitution confirmation completion event is successfully executed in the substitution process state, the state returns to the normal match state.

[0031] Step 2: Obtain the current global state of the system in real time and receive rule events: During operation, the system maintains a global state variable whose value can only be one of the three states mentioned above. When any terminal submits a rule event, the terminal needs to package the event type and related parameters (such as player numbers, score changes, etc.) and send them to the system. The specific types of rule events have been defined in step one, and each type of event carries different parameter fields. For example, a score change event carries the scoring team's identifier and the score value; a substitution event carries the numbers of the player being substituted and the player coming on; a challenge event carries the challenge type and the requesting team's identifier; and a libero substitution event carries the libero's number and the number of the player being substituted in the back row.

[0032] Step 3: Perform the first level of filtering: Upon receiving an event, the system first reads the current global state variable. Then, it retrieves the set of allowed event types corresponding to that state from the configuration data constructed in step one. If the event type is within this allowed set, the event is submitted to the second-level processing module for further inter-event mutual exclusion arbitration. If the event type is not in the allowed set, the event is directly rejected. Rejection handling includes: returning a rejection message to the terminal that submitted the event, stating that the rejection is due to the current state not allowing such an operation; simultaneously, the event will not be written to any list of executed events or the database, ensuring that no violation occurs in the match history.

[0033] Step Four: Second-level processing and inter-event mutual exclusion arbitration: For events that pass the first-level filtering, the system enters the second-level processing stage. The core task of this stage is to arbitrate multiple events that may conflict concurrently. The specific arbitration logic will be described later. There are two possible arbitration results: allow execution or refuse execution.

[0034] Step 5: State Transition and Broadcasting: When any rule event is successfully executed, the system checks whether the event meets the preset state transition conditions in step one. For example, if the executed event is a challenge event and it is executed successfully, the system determines whether the current state is a normal match state. If so, it triggers a state transition, updating the global state from normal match state to challenge adjudication state. After the state update, the system sends the new global state to all terminals associated with the match in the form of a notification message. Upon receiving the notification, each terminal synchronously updates its locally displayed status indicator and operation permission interface, thereby ensuring that all operators see a unified match progress status.

[0035] The technical principle of this method lies in using a pre-built finite state machine model to transform the rules governing permitted operations at different times in volleyball into computer-executable filtering conditions. The effect is that any operation request that does not conform to the current stage of the match is intercepted at the entry point, fundamentally preventing errors in match recording caused by differences in rule understanding or misoperation, and ensuring the consistency and compliance of match data during multi-terminal collaborative recording.

[0036] In a preferred embodiment, the step of performing inter-event mutual exclusion arbitration on the submitted rule events includes the following steps: Establish an event mutual exclusion matrix, which is an N×N Boolean matrix, where N is the total number of event types, and the matrix element M[i][j]=1 indicates that the i-th type of event and the j-th type of event are mutually exclusive; When two rule events from different terminals are received in the same global state, it is determined whether they are mutually exclusive by querying the mutual exclusion matrix: If the corresponding element of the mutex matrix is ​​0, then the two events will be executed in the order they are received. If the corresponding element of the mutual exclusion matrix is ​​1, the concurrent arbitrator is triggered.

[0037] Specifically, step one: establish an event mutual exclusion matrix: First, determine the total number N of event types that need to be included in the mutual exclusion judgment. In this method, the event types include score change events, substitution events, challenge events, and libero substitution events, so N equals 4.

[0038] Next, create an N x N Boolean matrix. The row and column numbers of the matrix each correspond to an event type, and the correspondence between rows and columns is fixed in advance. For example, the first row and first column correspond to the score change event, the second row and second column correspond to the substitution event, the third row and third column correspond to the challenge event, and the fourth row and fourth column correspond to the libero substitution event.

[0039] Each element in the matrix can only take the value 0 or 1. A value of 1 indicates that there is a mutual exclusion relationship between the event type corresponding to the row and the event type corresponding to the column, that is, the two events cannot be executed simultaneously or sequentially in the same global state; a value of 0 indicates that the two can coexist and can be executed sequentially.

[0040] The values ​​assigned to each element in the matrix are based on an in-depth analysis of the rules of volleyball. The specific assignment logic is as follows: First, substitution events are mutually exclusive. Volleyball rules stipulate that a team can only make one substitution during a dead ball situation and cannot request multiple substitutions consecutively. Therefore, the elements in the matrix corresponding to substitutions in rows and columns are assigned a value of 1.

[0041] Second, substitutions and free substitutions are mutually exclusive. The rules state that while both free substitutions and regular substitutions can occur during a dead ball situation, they involve different methods of recording player movement, and the rules do not allow them to be mixed within a single interruption. Therefore, the element at the intersection of the substitution event row and the free substitution event column is assigned a value of 1, and the element at the symmetrical position is also assigned a value of 1.

[0042] Third, challenge events and score change events are mutually exclusive. When a challenge occurs, the score of the round in question is pending, and no new score change can be recorded at this time. Therefore, the element at the intersection of the challenge event row and the score change event column is assigned a value of 1, and the element at the symmetrical position is also assigned a value of 1.

[0043] Fourth, challenge events and substitution events are mutually exclusive. The match is paused during a challenge, and personnel changes are prohibited. Therefore, the element at the intersection of the challenge event row and the substitution event column is assigned a value of 1, and the element at the symmetrical position is also assigned a value of 1.

[0044] Fifth, challenge events and free player replacement events are mutually exclusive. Similarly, free player replacement is not allowed during a challenge. Therefore, the element at the intersection of the challenge event row and the free player replacement event column is assigned a value of 1, and the element at the symmetrical position is assigned a value of 1.

[0045] Other unmentioned combinations are defaulted to 0, indicating no mutual exclusion. For example, score change events and substitution events can occur sequentially in certain stages of the game, so their corresponding matrix elements are 0.

[0046] Step 2: Use the mutual exclusion matrix to determine and trigger the concurrent arbitrator: When the system receives two rule events from different terminals in the same global state, it first obtains the event types of the first and second events, and then finds their corresponding row and column indices in the mutual exclusion matrix based on their types.

[0047] Then, the system queries the element value in that row and column of the matrix. If the value is 0, it means that the two events are not mutually exclusive. The system places them into the execution queue in the order they were received and executes them sequentially. The event received first is executed first, and the event received later begins to execute.

[0048] If the value of the matrix element retrieved is 1, it means that the two events are mutually exclusive. In this case, they cannot be simply processed according to the order of receipt, because the event executed first may cause the event executed later to lose its execution conditions. The system then triggers a dedicated concurrent arbitrator to submit the two events to the arbitrator for more in-depth conflict analysis and adjudication.

[0049] Triggering the concurrent arbitrator means that the system suspends the regular queuing process for these two events, and the arbitrator decides which event to execute and whether the other event can still be executed, according to the method described later.

[0050] The effect of this method is that the system can quickly identify combinations of conflicting events that require special handling with extremely low computational overhead, providing clear triggering conditions for subsequent fine-grained arbitration and ensuring that mutually exclusive events will not lead to rule-level errors due to simple time sorting.

[0051] In a preferred embodiment, the concurrent arbitrator includes: Each arriving event is appended with a globally incrementing sequence number based on an atomic counter, which serves as the total sequence identifier for the event; The two mutually exclusive events are temporarily stored in a thread-safe blocking queue, and the execution order is determined according to the globally incrementing sequence number, with the one with the smaller sequence number being executed first. When executing a priority event, set a mutex semaphore to lock the resource group associated with that event type; After the priority event is completed, the mutex semaphore is released, and the first type of state parameters on which the subsequent event depends are re-verified to be still valid. The first type of state parameters include the player's on-field position identifier, the libero's available number of times counter, and the substitution number of times counter. If the verification passes, the next event is executed; if the verification fails, the event is discarded and a status code containing the reason for the failure is generated and returned to the source terminal.

[0052] Specifically, step one: append a globally incrementing sequence number: Before processing events, the concurrent arbitrator first assigns a globally unique sequence number to each event entering the system. This sequence number is generated by a global counter, which increments by one for each new event processed, starting from an initial value. Therefore, the sequence number strictly reflects the order in which events arrive at the system. As a unique identifier for each event, the sequence number is used to determine the basic temporal relationship of events during subsequent arbitration.

[0053] Step 2: Temporarily store the mutex event in the blocking queue: Once the mutex matrix determines that two events are mutually exclusive and triggers the concurrent arbitrator, the arbitrator places these two mutually exclusive events into a dedicated temporary queue. This queue manages events according to the first-in, first-out (FIFO) principle and supports data safety during multi-threaded concurrent access. The purpose of this temporary queue is to provide the arbitrator with a centralized place to process pairs of mutually exclusive events, preventing subsequent events from being inserted and causing interference due to processing delays.

[0054] Step 3: Determine the execution order based on the sequence number: The arbitrator retrieves the pair of mutually exclusive events from the temporary queue and compares their globally incrementing sequence numbers. The event with the smaller sequence number is designated as the priority event, and the event with the larger sequence number is designated as the subsequent event. The logic behind this is to respect the objective chronological order of event submission; in the absence of other priority rules, the event submitted first has priority in execution.

[0055] Step 4: Execute priority events and lock resource groups: Before executing a priority event, the arbitrator determines the scope of shared resources that need to be modified during its execution, based on the event type. These shared resources include player position information on the field, various counters, etc. The arbitrator sets a mutex semaphore for these resources, i.e., a locking operation. After locking, any other operation attempting to modify the same resource group will be blocked until the lock is released. This ensures that the relevant data is not interfered with by other concurrent operations during the execution of the priority event.

[0056] Then, the system executes the priority event according to normal business logic, including updating the score, recording substitutions, and deducting attempts.

[0057] Step 5: Release the semaphore and verify the parameters dependent on the next event: After the priority event is completed, the arbitrator releases the previously set mutex semaphore, allowing other waiting operations to continue.

[0058] Next, the arbitrator needs to re-verify whether the subsequent event can continue. The object of this verification is the first type of state parameters. The first type of state parameters refers to the preconditions that must be met for the event to proceed, specifically including: Player position identifiers: These refer to the six players currently playing for each team and their corresponding positions, such as outside hitter, middle blocker, setter, opposite hitter, libero, etc.

[0059] Libero Usable Numbers Counter: This refers to the remaining number of times a Libero can substitute in each game.

[0060] Substitution Counter: This refers to the number of normal substitutions each team has remaining in each game.

[0061] The specific verification process is as follows: The arbitrator rereads the latest value of the current first-type state parameter, and then checks whether the parameters it depends on still meet the execution conditions based on the event type of the subsequent event. For example, if the subsequent event is a substitution event, it checks whether the substitution count counter is still greater than zero, and whether the player specified in the event is still on the field (i.e., the player exists in the on-field position identifier).

[0062] If the verification passes, it means that the execution of the priority event did not cause the preconditions of the subsequent event to become invalid, and the arbitrator will then execute the subsequent event.

[0063] If the verification fails, it means that the execution of the priority event has made it impossible for the subsequent event to be legally completed (for example, the substitution attempts have been exhausted by the priority event, or the player to be substituted has already been substituted by the priority event). In this case, the arbitrator discards the subsequent event, does not record it as an executed event, and generates a status code containing the reason for the failure. This status code is then returned to the terminal that initially submitted the event, informing the operator of the specific reason why the event was rejected.

[0064] The technical principle of this method lies in establishing a global timing benchmark through sequence numbers, protecting atomic modifications of shared resources through mutex semaphores, and handling potential state changes caused by priority events through post-execution secondary verification. Its effect is that, in complex scenarios where multiple terminals simultaneously raise mutually exclusive events, the system can ensure that the final executed event sequence not only conforms to the inherent logic of volleyball rules but also promptly provides feedback to the operator regarding the reasons for failure, guaranteeing the accuracy of match records and the understandability of operations.

[0065] In a preferred embodiment, before determining the execution order based on the globally incrementing sequence number, the concurrent arbitrator further includes the following steps: A basic priority weight is pre-configured for each type of mutually exclusive event. The basic priority weight is set according to the volleyball game rules, wherein the basic priority of the libero substitution event is higher than that of the normal substitution event. When two mutually exclusive events are temporarily stored in the blocking queue, the system obtains the current second type of status parameters, which include the current score, the remaining challenge attempts in the current round, the remaining available attempts for the free agent, and the remaining attempts for substitution. Based on the basic priority weights and the second type of state parameters, the dynamic priority value of each mutual exclusion event is calculated using a weighted formula. Determining the execution order based on the globally incrementing sequence number includes the following steps: If the dynamic priority values ​​of each mutual exclusion event are equal, the execution order is determined according to the global incrementing sequence number.

[0066] Specifically, step one: pre-configure basic priority weights: During system initialization, a basic priority weight value is pre-set for each type of mutually exclusive event. The weight values ​​are set based on the importance and urgency of various events as defined in volleyball rules. The specific configuration is as follows: Free agent substitutions: Because free agent substitutions are usually required to be completed quickly to maintain the pace of the game and do not use up a regular substitution slot, referees typically prioritize free agent substitution requests according to the rules. Therefore, their base priority weight is set to a high value, such as 80.

[0067] Regular substitution events: Regular substitutions involve tactical adjustments, but the procedures are relatively complicated. They have a slightly lower priority than free agent substitutions and a weight of 50.

[0068] Challenge Events: Challenges involve referee arbitration procedures and must be submitted to immediately stop the match. They have the highest urgency and are weighted at 90.

[0069] Score Change Event: Score changes are a natural outcome of the match, but their recording usually occurs at the end of the event and is weighted at 70.

[0070] These weight values ​​are stored in the form of a configuration table and can be adjusted according to the requirements of different events.

[0071] Step 2: Obtain the second type of state parameters: After two mutually exclusive events are placed in the blocking queue, the arbitrator needs to obtain the current second-type state parameters before calculating the dynamic priority. These second-type state parameters are indicators reflecting the current macro-level progress of the competition; they do not directly determine whether an event can be executed, but they influence the appropriate timing of event execution. The second-type state parameters specifically include: Current game score: This refers to the current game number and the score of both players in the current game.

[0072] Remaining challenge attempts in the current round: This refers to the number of challenges each team can still initiate in the current round.

[0073] Remaining available number of times a flex player can be substituted: This refers to the remaining number of times a flex player can be substituted in the current round.

[0074] Remaining substitution attempts: This refers to the remaining number of normal substitution attempts in the current game.

[0075] The values ​​of these parameters are obtained by reading real-time statistics from the match.

[0076] Step 3: Calculate the dynamic priority value: The arbitrator calculates the dynamic priority value of each mutually exclusive event based on the basic priority weights and the second type of state parameters using a preset weighted formula. The design principle of the weighted formula is to ensure that the priority reflects the actual urgency of the event in the current game situation.

[0077] For example, the weighted formula can be designed as follows: the dynamic priority value equals the basic priority weight multiplied by a local urgency coefficient, plus a resource surplus coefficient.

[0078] The calculation logic for the set urgency coefficient is as follows: if the current set score is in the critical final stage (e.g., both sides have more than 20 points and the score difference is within 2 points), then the coefficient takes a larger value, such as 1.5; the coefficient for ordinary periods is 1.0. This allows challenge events or substitution events raised at critical moments to receive higher processing priority.

[0079] The calculation logic for the resource surplus coefficient is as follows: if the resources required for an event (such as the number of personnel changes) are less remaining, the urgency of the event may be higher, and the coefficient value can be increased appropriately. The specific formula can be defined according to actual needs.

[0080] Step 4: Determine the execution order based on dynamic priority values: After calculating the dynamic priority values ​​of the two mutually exclusive events, the arbitrator compares these two values.

[0081] If two events have the same dynamic priority value, it means that they are equally important in the current game situation. At this time, the arbitrator will return to the basic rules, that is, compare their global incrementing sequence numbers, and the event with the smaller sequence number will be executed first.

[0082] If the dynamic priority values ​​of two events are not equal, the event with the higher dynamic priority value is determined as the priority event, and the event with the lower dynamic priority value is determined as the delayed event. In this case, the sequence number is no longer used as the sorting basis; instead, the execution order is determined by the dynamic priority value. After the order is determined, the arbitrator proceeds to the further arbitration steps described in the subsequent claims.

[0083] The technical principle of this method lies in quantifying the real-time situation of the game into a calculable adjustment factor, which, combined with the inherent priority of events, dynamically adjusts the processing order of mutually exclusive events. The effect is that the arbitration result no longer rigidly depends on the physical time sequence of event submissions, but rather, like an experienced referee, prioritizes handling more critical operational requests based on the current tension and resource availability of the game, making the game recording process more consistent with the actual operational logic of volleyball.

[0084] In a preferred embodiment, after calculating the dynamic priority value of each event using a weighted formula, the method further includes the following steps: If the dynamic priority values ​​of two mutually exclusive events are not equal, the following priority arbitration steps are performed: Events with higher dynamic priority values ​​are designated as priority events, while those with lower values ​​are designated as delayed events. Before executing the priority event, an immutable snapshot copy is created for the first type of state parameters on which the delayed event depends, the snapshot copy including the field values ​​corresponding to the first type of state parameters; Execute the priority event and update the first type of state parameters in real time; After the priority event has been executed, the portion of the updated first type of status parameters related to the delayed event is compared field by field with the snapshot copy: If the values ​​of all first-class state parameters are the same as the field values ​​corresponding to the snapshot copy, then the delayed event is executed directly.

[0085] Specifically, step one: determine priority events and delayed events: Once the weighted formula is calculated, the arbitrator obtains the dynamic priority values ​​for each of the two mutually exclusive events. The arbitrator compares these two values, designating the one with the larger value as the priority event and the one with the smaller value as the delayed event. The priority event will immediately enter the execution process, while the delayed event will wait for the priority event to complete before further judgment and processing. This distinction aims to ensure that events with a greater impact on the game's progress or those that are more urgent are completed first, avoiding disruption to the game's rhythm due to waiting.

[0086] Step 2: Create an immutable snapshot copy of the first type of state parameter for the delayed event: Before a priority event begins execution, the arbitrator needs to create an immutable snapshot copy of the first type of state parameters upon which the delayed event depends. The first type of state parameters, previously defined, includes player position identifiers, a libero availability counter, and a substitution counter. Player position identifiers describe the correspondence between the six players currently on the field for each team and their respective positions, typically represented as a mapping between position numbers and player numbers. The libero availability counter records the remaining number of libero substitutions that can be performed in the current set. The substitution counter records the remaining number of normal substitutions that can be performed in the current set.

[0087] The specific steps for creating a snapshot copy are as follows: The arbitrator reads the current values ​​of the first type of state parameters mentioned above, saves these values ​​as read-only copies, and binds them to delayed events. Once a snapshot copy is generated, it will not change during subsequent priority event execution because it is a faithful record of the state before execution. Each parameter field in the snapshot records its complete value; for example, if the current value of the free agent's available count counter is 3, it will be recorded as 3 in the snapshot.

[0088] The purpose of this snapshot mechanism is to provide a reference benchmark for subsequent determination of whether the execution of a priority event violates the premise of the execution of a delayed event.

[0089] Step 3: Execute priority events and update the first type of state parameters in real time: The arbitrator executes priority events according to normal business logic. The execution process of priority events includes verifying the legality of the event's own parameters, modifying the corresponding match status data, and recording the event log. For example, if the priority event is a substitution event, the execution process includes: verifying whether the substituted player is indeed on the field, verifying whether the substituted player is on the substitute list and not suspended, and verifying whether the substitution count counter is greater than zero; after successful verification, the player's on-field position identifier is modified, replacing the substituted player's position with the substituted player's number, and the substitution count counter is decremented by one. If the priority event is a libero substitution event, the libero's available substitution count counter is modified, and the substitution records between back-row players and the libero are updated.

[0090] During the execution of priority events, all modifications to the first type of state parameters take effect in real time. This means that after the priority event is completed, the values ​​of the first type of state parameters may have changed compared to the values ​​in the snapshot copy created in step two.

[0091] Step 4: Field-by-field comparison after priority events are completed: After the priority events have been processed, the arbitrator begins processing the delayed events. The arbitrator does not directly execute the delayed events; instead, it first performs a comparison. This comparison involves comparing the updated first-class state parameters with the original values ​​recorded in the snapshot copy created in step two.

[0092] The comparison is limited to the portion of the first type of state parameters related to the delayed event. "Related to the delayed event" means that changes in this parameter will affect whether the delayed event can be legally executed. For example, if the delayed event is a substitution event, the relevant parameters include the substitution count counter and the specific position of the substituted player in the player's on-field position identifier. If the delayed event is a libero substitution event, the relevant parameters include the libero's available substitution count counter and the specific back row position involved in the libero substitution in the player's on-field position identifier.

[0093] The comparison is performed field by field. For each parameter included in the comparison, the arbitrator obtains its updated current value and compares it with the original value recorded in the snapshot to determine if the two are the same.

[0094] Step 5: Determine the subsequent handling of the delayed event based on the comparison results: If the comparison results show that the values ​​of all relevant parameters are the same as the corresponding field values ​​in the snapshot copy, it means that the execution of the priority event did not affect any state prerequisites on which the delayed event depends. In this case, the execution conditions of the delayed event are completely unaffected, so the arbitrator executes the delayed event directly without any additional checks or corrections.

[0095] If the comparison results show that the value of at least one relevant parameter differs from the corresponding field value in the snapshot copy, it indicates that the execution of the priority event has changed the state on which the delayed event depends. In this case, the delayed event cannot be executed directly; instead, further judgment and processing are required.

[0096] The technical principle of this method lies in accurately detecting the degree of interference of the priority event on the execution premise of the delayed event by comparing the snapshot before execution with the state after execution. If the state remains unchanged, the delayed event can be executed directly, saving unnecessary repeated verification overhead; if the state changes, a more in-depth rule compliance judgment is triggered. Its effect is to maximize processing efficiency in non-conflict scenarios while ensuring the correctness of arbitration, and to retain a complete traceability and correction mechanism for conflict scenarios.

[0097] In a preferred embodiment, after comparing the portion of the updated first type of state parameters related to the delayed event with the snapshot copy field by field, the method further includes the following steps: If at least one first-class state parameter has a value that is different from the field value corresponding to the snapshot copy, then these first-class state parameters are marked as target state parameters and input into the rule engine; The rule engine determines, based on the volleyball rules, whether the target state parameters on which the delayed event depends still meet the execution conditions. If the execution conditions are met, then the delayed event is executed; If the execution conditions are not met, the delayed event is discarded and a structured log entry is generated. The structured log entry includes: the event identifier of the priority event, the event identifier of the delayed event, the failure reason code, and the values ​​of the target state parameter before and after the change. This structured log entry is appended to the competition event log chain to form a priority causal record.

[0098] Specifically, step one: identify and label the target state parameters: After the field-by-field comparison is completed, if at least one Category 1 status parameter is found to have an updated value that differs from its original value in the snapshot copy, the arbitrator marks all these changed parameters as target status parameters. Target status parameters are those whose values ​​have changed due to the execution of priority events and may affect the legitimacy of delayed events. The purpose of marking these parameters is to filter them out from all Category 1 status parameters, making them the focus of subsequent analysis by the rule engine.

[0099] Step 2: Input the target state parameters into the rule engine: The arbitrator contains a rules engine module. This rules engine is an independent functional unit that has a series of pre-defined conditional judgment logics based on volleyball match rules. The arbitrator inputs all the target state parameters marked in step one, along with their values ​​before and after the changes, into the rules engine. The input also includes the event type of the delayed event and its original parameters.

[0100] Step 3: The rule engine determines whether the delayed event still meets the execution conditions: After receiving input, the rule engine initiates the corresponding rule analysis process based on the event type of the delayed event. The core question of rule analysis is: given that the target state parameters have undergone specific changes, is it still possible for the delayed event to be executed according to the volleyball rules?

[0101] The specific judgment logic is designed based on the actual rules, as shown in the following example: If the delayed event is a substitution event, and the target status parameter shows that the substitution count counter has changed from 1 to 0, the rule engine determines that the delayed event no longer meets the execution conditions according to the principle that the number of substitutions cannot be overdrawn in volleyball rules, because no substitution operation can be performed when the remaining substitution count is zero.

[0102] If the delayed event is a substitution event, and the target status parameter indicates that the substituted player's on-court position has changed (i.e., the player is no longer in the position specified when the event was submitted), the rule engine needs to further determine whether the player is still on the court. If the player has already been substituted by a priority event, the player specified by the delayed event is not on the court, and the execution condition is not met. If the player has only changed position due to rotation but is still on the court, and volleyball rules do not strictly require players to be in a specific rotation position for substitutions, the rule engine may determine that the execution condition is still met, but semantic correction of the event parameters is required in subsequent steps.

[0103] If the delayed event is a free agent replacement event, and the target status parameter shows that the free agent available count counter has changed from 1 to 0, the rule engine determines that the delayed event does not meet the execution conditions because the free agent replacement count has been exhausted.

[0104] If the delayed event is a challenge event, and the target status parameter shows that the remaining challenge count for the current round has changed from 1 to 0, the rule engine will also determine that the execution conditions are not met.

[0105] Step 4: Execute different branches based on the rule engine's judgment results: The rule engine outputs a clear judgment result, with only two possibilities: the execution conditions are met or the execution conditions are not met.

[0106] If the determination result is that the execution conditions are met, the arbitrator will perform possible parameter semantic redirection operations on the original parameter set of the delayed event according to the method described later, correct the parameter referencing deviation caused by the state change, and then execute the delayed event.

[0107] If the arbitrator determines that the execution conditions are not met, it discards the delayed event, meaning it is not recorded as an executed event and has no further impact on the match data. Simultaneously, the arbitrator generates a structured log entry. This structured log entry contains at least the following four components: Event identifier of priority event: used to trace which priority event's execution caused the delayed event to fail.

[0108] Event identifier for delayed events: Used to identify the delayed event itself that was rejected.

[0109] Failure reason code: Use predefined codes to indicate the specific rule reason for rejection. For example, code 301 means that the substitution limit has been reached, code 302 means that the free player substitution limit has been reached, and code 303 means that the target player is no longer on the field.

[0110] Before and after the change of target state parameters: Record in detail the specific numerical changes of each marked target state parameter before and after the execution of the priority event, such as the change of personnel counter changing from 1 to 0.

[0111] Step 5: Append the structured log entries to the competition event log chain: After generating a structured log entry, the arbitrator appends the entry to the permanent event log chain for that match. The match event log chain is a complete historical record of all executed events and rejected key events, arranged chronologically. Recording events discarded due to priority arbitration in a structured log format creates a clear priority causal record. When post-match reviews are needed or disputes arise, the referee team and technical representatives can consult this log chain to fully reconstruct the context in which the system made the rejection decision and understand why a certain operation failed to execute.

[0112] The technical principle of this method lies in using the state changes caused by the execution of priority events as input to drive the rule engine to perform a secondary legality review, and recording and retaining events that fail the review in the form of structured logs. The effect is that the system can not only correctly reject expired delayed events, but also provide complete auditable and traceable information, making conflicts arising from concurrent operations across multiple terminals traceable, thus improving the transparency and credibility of the competition recording system.

[0113] In a preferred embodiment, before comparing the portion of the updated first type of state parameters related to the delayed event with the snapshot copy field by field, the method further includes the following steps: Based on the event type of the delayed event, the dependency parameter mask corresponding to the event type is read from the pre-stored dependency parameter mask table. The dependency parameter mask is a binary vector, with each bit corresponding to a first type of state parameter. A mask bit of 1 indicates that the parameter is depended on by the delayed event. Based on the dependency parameter mask, a subset of dependent parameters is selected from the updated first type of state parameters; The step of comparing the portion of the updated first type of state parameters related to the delayed event with the snapshot copy field by field includes the following steps: Each parameter in the subset of parameters to be relied upon is compared one by one with the value of the corresponding parameter in the snapshot copy.

[0114] Specifically, step one: establishing and retrieving the pre-stored dependency parameter mask table: During the initialization phase, the system establishes a dependency parameter mask table. This table is indexed by event type and stores the dependency parameter mask corresponding to each event type. The dependency parameter mask is a binary vector, and the number of bits in the vector equals the total number of types of the first category of state parameters. In this implementation, the first category of state parameters includes three types: player on-field position identifier, free agent available attempts counter, and substitution attempts counter. Therefore, the mask is a 3-bit binary vector, with bit 0 corresponding to the player on-field position identifier, bit 1 corresponding to the free agent available attempts counter, and bit 2 corresponding to the substitution attempts counter.

[0115] The mask bits can be either 1 or 0. A value of 1 indicates that the corresponding first-type state parameter is dependent on this type of event; that is, changing this parameter will affect the validity of this type of event. A value of 0 indicates that it is not dependent.

[0116] The specific values ​​assigned to the dependency parameter mask table are based on the volleyball rules. For example: For substitution events, their execution depends on whether the substituted player is on the field (related to the player's on-field position identifier) ​​and whether there are remaining substitution attempts (related to the substitution attempt counter), and is unrelated to the free agent's available attempts counter. Therefore, the dependency parameter mask for substitution events is set to binary 101, that is, bits 0 and 2 are 1, and bit 1 is 0.

[0117] The execution of the free agent substitution event depends on whether the free agent is waiting in the substitute zone and whether the player being substituted is in the back row (related to player position indicators), as well as whether there are remaining free agent substitution attempts (related to the free agent available attempts counter), and is unrelated to the regular substitution attempts counter. Therefore, the dependency parameter mask for the free agent substitution event is set to binary 110, that is, the 0th and 1st bits are 1, and the 2nd bit is 0.

[0118] For challenge events, their execution is typically not directly dependent on personnel location or various count counters, but only on the current remaining challenge count (this parameter belongs to the second type of state parameter and is not within the scope of the first type of state parameter). Therefore, the dependency parameter mask for challenge events is set to binary 000, meaning it does not depend on any first type of state parameter.

[0119] For score change events, their execution does not depend on the three types of first-class state parameters mentioned above, so their dependency parameter mask is also 000.

[0120] When the arbitrator needs to process a delayed event, it first obtains the event type of the delayed event, and then reads the corresponding dependency parameter mask from the pre-stored dependency parameter mask table using the type as the key.

[0121] Step 2: Filter the subset of dependent parameters based on the dependency parameter mask: After obtaining the dependency parameter mask, the arbitrator uses this mask to filter the updated first-type state parameters. The filtering process involves iterating through each bit of the mask; for bits with a value of 1, the corresponding first-type state parameter is included in a subset of dependent parameters. For bits with a value of 0, the corresponding parameter is excluded from the subset and does not participate in subsequent comparisons.

[0122] For example, when the delayed event is a substitution event, the mask is 101. The arbitrator uses the mask to filter out the player's on-court position identifier and substitution count counter, forming a subset of the parameters that are relied upon. The libero's available substitution count counter is excluded because the corresponding bit in the mask is 0.

[0123] Once the filtering is complete, the subset of parameters that are relied upon represents the entire range of state parameters that the delayed event is concerned with.

[0124] Step 3: Compare the subset of parameters that will be depended upon with the snapshot copy one by one: The updated first type of state parameters related to delayed events are compared field by field with the snapshot copy. This step is specified as: only each parameter in the subset of parameters to be depended on is compared one by one with the value of the corresponding parameter in the snapshot copy.

[0125] Taking the delayed substitution event as an example, the arbitrator retrieves the current value of the player's on-field position identifier from the subset of dependent parameters and compares it with the original value of the player's on-field position identifier recorded in the snapshot copy. Next, it retrieves the current value of the substitution count counter and compares it with the original value of the substitution count counter recorded in the snapshot. The free agent available substitution count counter is not read or compared at all.

[0126] This mask-based filtering mechanism offers two main benefits. First, it reduces unnecessary parameter reading and comparison operations, improving the efficiency of the arbitration process, especially when dealing with large amounts of match data and diverse state parameters. Second, it avoids misjudging changes in irrelevant parameters as changes in conditions affecting delayed event execution. For example, the free agent's available attempts counter might change during a priority event, but this change is insignificant for a substitution event. If all parameter changes are treated as target state parameters without filtering, substitution events will be incorrectly sent to the rules engine for unnecessary review, potentially leading to misjudgments.

[0127] Step 4: Post-processing of comparison results Based on the comparison results of the subset of dependent parameters, the arbitrator continues with subsequent steps. If the values ​​of all dependent parameters are consistent with the snapshot, the delayed event is executed directly. If the value of at least one dependent parameter differs from the snapshot, the changed parameter is marked as the target state parameter and input into the rule engine for processing.

[0128] Technical principles and effects The technical principle of this method lies in pre-defining a parameter mask for each event type, enabling on-demand filtering of state parameters during the comparison phase. This precisely limits the comparison scope to the set of parameters that substantially affect the legality of the event. The effects are twofold: firstly, it improves the efficiency of the arbitration process and reduces redundant state reading operations; secondly, it enhances the accuracy of arbitration judgments, avoiding erroneous rejections due to changes in irrelevant parameters, and making the system behavior more consistent with the inherent logic of volleyball rules and practical operational practices.

[0129] In a preferred embodiment, the step of executing the delayed event if the execution condition is met includes the following steps: After determining that the delayed event meets the execution conditions, the original event parameter set carried by the delayed event is obtained. The original event parameter set includes the event operation object identifier and the expected value of resource consumption. Based on the difference between the changed value of the target state parameter and the corresponding value in the snapshot copy, a state offset mapping table is generated. The state offset mapping table records the identifier of each type of first-class state parameter that has changed and its mapping relationship before and after the change. Based on the state offset mapping table, a parameter semantic redirection operation is performed on the original event parameter set to eliminate the semantic conflict between the original event parameter set and the current global state caused by the change of the first type of state parameters due to the execution of priority events. The delayed event is executed using the parameter set corrected by the parameter semantic redirection operation.

[0130] Specifically, step one: Obtain the original set of event parameters carried by the delayed event: Once the rules engine determines that the delayed event still meets the execution conditions, the arbitrator first extracts the original event parameter set carried by the delayed event object. The original event parameter set contains all the operation-related data included when the delayed event was initially submitted by the terminal. The content of the original event parameter set varies depending on the event type, but all include the following two basic fields: event operation object identifier and expected resource consumption value.

[0131] The event object identifier is used to specify the specific object to which the event applies. For example, in a substitution event, the object identifier includes the number of the player being substituted and the number of the player coming on. In a libero substitution event, the object identifier includes the number of the libero performing the substitution and the number of the back-row player being substituted. In a challenge event, the object identifier includes the challenge type and the identifier of the requesting team. In a score change event, the object identifier includes the identifier of the scoring team.

[0132] The expected resource consumption value indicates the amount of game resources that are expected to be consumed after the event is executed. For example, the expected resource consumption value for a substitution event is typically one substitution attempt. The expected resource consumption value for a libero substitution event is typically one libero substitution attempt. The expected resource consumption value for a challenge event is one challenge opportunity.

[0133] These raw parameters are constructed by the terminal when the delayed event is submitted, reflecting the operation that the operator intends to perform at that time in the game.

[0134] Step 2: Generate a state offset mapping table: While obtaining the original set of event parameters, the arbitrator needs to generate a state offset mapping table. This state offset mapping table is used to record the details of changes in the first type of state parameters caused by the execution of the priority event.

[0135] The state offset mapping table is generated based on the difference between the changed values ​​of the target state parameters and the corresponding values ​​in the snapshot copy. The specific generation process is as follows: The arbiter iterates through each marked target state parameter, extracting its identifier, its original value in the snapshot copy, and its latest value in the current global state. These three pieces of information are then added as a mapping record to the state offset mapping table. The mapping table ultimately contains the complete before-and-after mapping relationships for all changed Class 1 state parameters.

[0136] For example: Suppose the priority event is a normal substitution event, after which the substitution count counter changes from 2 to 1, and the player number corresponding to the main attacking position in the player's on-field position identifier changes from 8 to 12. The delayed event is another substitution event. Then the state offset mapping table will contain two records. The parameter identifier of the first record is the substitution count counter, which was 2 before the change and is 1 after the change. The parameter identifier of the second record is the player's on-field position identifier, specifically describing the player number changing from 8 to 12 for the main attacking position.

[0137] Step 3: Perform parameter semantic redirection operation based on the state offset mapping table: After the state offset mapping table is generated, the arbitrator enters the parameter semantic redirection operation. The purpose of this operation is to eliminate the semantic conflict between the original parameter set of delayed events and the current global state caused by the change of the first type of state parameters due to the execution of priority events.

[0138] Semantic conflict specifically refers to a situation where the identifier of the operation object or the expected value of resource consumption referenced in the original parameter set of a delayed event no longer points to the correct object or value in the current global state. For example, a delayed event might have intended to substitute player number 8, but player number 8 has already been substituted in a priority event. If the delayed event is still executed according to the original parameters, the system will not be able to find player number 8 on the field, resulting in an execution error. Parameter semantic redirection is precisely to correct these semantically biased parameters to valid parameters consistent with the current global state before the delayed event is actually executed.

[0139] The parameter semantic redirection operation is implemented as follows: the arbitrator takes the state offset mapping table as input, compares it with the event type of the delayed event, and redirects or reassigns the corresponding fields in the original parameter set of the event. The specific redirection logic depends on the event type and the state offset content; at least two typical processing logics are given later. After the parameter semantic redirection operation, the delayed event obtains a corrected parameter set.

[0140] Step 4: Execute the delayed event using the revised parameter set: After the parameter semantic redirection operation is completed, the arbitrator no longer uses the original old parameter set of the delayed event, but instead uses the modified parameter set to execute the delayed event. The execution process is consistent with the execution flow of a normal event, including verifying the validity of the modified parameters, updating the corresponding match state data, and recording the event log. Since the parameters have undergone semantic redirection, the modified parameters match the current global state, so the execution process can usually pass the verification smoothly and complete successfully.

[0141] The technical principle of this method lies in recording the state changes triggered by priority events through a state offset mapping table. Then, based on this mapping table, the original parameters of delayed events are semantically corrected, allowing the corrected parameters to re-establish the correct referential relationship with the changed game state. The effect is that even if the object on which the delayed event depends changes during the waiting period, as long as the event is still executable according to the rules, the system can automatically adjust the event parameters to adapt to the current state, without requiring the operator to resubmit the event. This significantly improves the smoothness of operation and user experience in multi-terminal concurrent scenarios.

[0142] In a preferred embodiment, performing parameter semantic redirection on the original event parameter set specifically includes at least one of the following processing logics: The first redirection logic, in response to the delayed event being a substitution event, and the state offset mapping table indicating that the target on-field position identifier of the substituted player has been modified by the priority event, then according to the changed position identifier in the state offset mapping table, queries the on-field player identifier corresponding to the position identifier in the current global state, and replaces the replaced player identifier in the original parameter set of the event with the queried on-field player identifier. The second redirection logic, in response to the delayed event being a free agent replacement event and the state offset mapping table indicating that the free agent's remaining available count counter has been decremented to zero, marks the expected resource consumption value in the original parameter set of the event as an invalid value and attaches a prohibition flag, so that in the step of executing the delayed event using the parameter set corrected by the parameter semantic redirection operation, in response to the recognition of the prohibition flag, the execution operation of the delayed event is skipped.

[0143] Specifically, the implementation of the first redirection logic is as follows: The first redirection logic applies to the following scenario: the delayed event is a substitution event, and the state offset mapping table indicates that the target on-field position identifier of the substituted player has been modified by the priority event. The target on-field position identifier refers to the on-field position number occupied by the substituted player at the time the event is submitted, as set in the original parameter set of the delayed event. In this scenario, the specific implementation steps of the first redirection logic are as follows: The first step is for the arbitrator to read change records related to player on-field position identifiers from the state offset mapping table. The arbitrator then identifies mapping entries that record player changes to specific on-field position identifiers.

[0144] The second step involves the arbitrator identifying the player's number from the original parameter set of the delayed event. Next, the arbitrator determines whether the substituted player is the same player recorded in the state offset mapping table who was substituted due to a priority event. If so, it means the player the delayed event originally intended to substitute is no longer on the field.

[0145] The third step involves the arbitrator redirecting players based on the changed position identifiers in the state offset mapping table. Specifically, it reads the changed position identifiers recorded in the mapping table, which are the new player numbers occupying those positions after being replaced by the priority event. Then, using these position identifiers as the query criteria, it searches the current global state's player position identifier data to find the player number currently actually occupying that position. Since the mapping table already records who replaced whom in that position, the search result is the player number that came on as a substitute in the priority event.

[0146] Fourth, the arbitrator uses the currently active player identifier found in the query to replace the substituted player identifier in the original parameter set of the delayed event. In other words, the player number substituted in the delayed event is changed from the old number (which is no longer on the field) to the player number currently occupying that position.

[0147] After the above correction, the target of the delayed event changes from the player who has been substituted to the player who has newly occupied that position. Since the core semantics of a substitution event is to replace a player in a certain position on the field, the substitution operation can continue as long as there is still a player in that position. This redirection logic allows the delayed event to automatically adapt to dynamic changes in the players on the field, without requiring the operator to re-identify and submit a new substitution request.

[0148] Specific implementation of the second redirection logic: The second redirection logic is applicable to the following scenario: the delayed event is a free agent replacement event, and the state offset mapping table indicates that the free agent's remaining available count has been decremented to zero. In this scenario, the specific implementation steps of the second redirection logic are as follows: The first step is for the arbitrator to read the change record of the free agent's remaining available attempts counter from the state offset mapping table. The arbitrator finds that the changed value of the counter is zero.

[0149] In the second step, since the remaining available free agent attempts are zero, any new free agent replacement event is not ready for execution. Therefore, no matter what semantic redirection is applied to the original event parameter set, the fact that the event cannot be executed cannot be changed. Thus, the second redirection logic does not perform any substantial parameter modification operation, but instead marks the original event parameter set.

[0150] Third, the arbitrator marks the expected resource consumption values ​​in the original parameter set of the event as invalid. An invalid value is a special identifier used to indicate that the resources on which the event depends have been exhausted, and there is no need to continue processing the event itself.

[0151] Fourth, the arbitrator attaches a non-execution flag to the delayed event. The non-execution flag is a Boolean flag attached to the event object, used to indicate that subsequent execution steps should skip the actual execution operation for that event.

[0152] In the subsequent step of executing delayed events using the parameter set corrected by the parameter semantic redirection operation, the execution module first checks whether the event object has a prohibited execution flag before attempting to execute the event. If the flag is detected, the execution module skips the normal execution operation for the delayed event and does not perform any database writes or status updates.

[0153] It should be noted that skipping the execution operation does not mean silently discarding it. The system still needs to return a rejection message to the terminal that submitted the delayed event, informing the operator of the reason for the failure of the free agent replacement, and record the corresponding structured entry in the match event log. This follow-up processing has been fully defined above.

[0154] The technical principle of this method lies in designing differentiated semantic redirection strategies for different event types and different state offset types. For events that can be salvaged through parameter correction (such as changes in personnel at the target location in a personnel replacement event), proactive redirection and parameter correction are used to facilitate event execution. For events that are absolutely unexecutable due to resource exhaustion (such as the free agent replacement count reaching zero), a flag-skip execution method is used to quickly terminate the process. The effect is that the parameter semantic redirection operation is both flexible, automatically resolving semantic conflicts when possible, and avoids unnecessary complex calculations when impossible, making the arbitration process both intelligent and efficient.

[0155] Example 2 This embodiment proposes a volleyball match process recording system based on rule events, used to implement the method described in Embodiment 1, such as... Figure 2 As shown, it includes: The construction module is configured to build a global state machine for volleyball matches. The global state machine defines a finite set of states, including normal match state, challenge ruling state, and substitution process state, and configures a corresponding set of allowed event types and a set of prohibited event types for each state. Acquisition module 1 is configured to acquire the current global status of the system in real time and receive rule events submitted by any terminal among multiple terminals. The rule events include score change events, substitution events, challenge events, and free agent substitution events. Filtering module 2 is configured to perform first-level filtering on received rule events based on the set of allowed event types corresponding to the current global state. If the event type of the rule event belongs to the set of allowed event types in the current state, then the event is sent to the second level of processing; If the event belongs to the prohibited event type set, the event will be refused to be executed, a rejection message will be returned to the submitting terminal, and the event will not be recorded as an executed event. Arbitration module 3 is configured to perform inter-event mutual exclusion arbitration on the submitted rule events in the second-level processing, and decide whether to execute or reject based on the arbitration result; Update module 4 is configured to update the global state according to the preset state transition rule when any rule event is successfully executed and the rule event triggers the state transition condition, and broadcast the state change notification to all terminals so that each terminal can synchronize the current global state.

[0156] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A method for recording the process of a volleyball match based on rule events, characterized in that, Includes the following steps: Construct a global state machine for volleyball matches. The global state machine defines a finite set of states including normal match state, challenge ruling state, and substitution process state, and configures a corresponding set of allowed event types and a set of prohibited event types for each state. The system can obtain the current global status of the system in real time and receive rule events submitted by any terminal from multiple terminals. The rule events include score change events, substitution events, challenge events, and free agent substitution events. Based on the set of allowed event types corresponding to the current global state, perform the first level of filtering on the received rule events: If the event type of the rule event belongs to the set of allowed event types in the current state, then the event is sent to the second level of processing; If the event belongs to the prohibited event type set, the event will be refused to be executed, a rejection message will be returned to the submitting terminal, and the event will not be recorded as an executed event. In the second-level processing, mutual exclusion arbitration is performed on the submitted rule events, and the decision to execute or reject is made based on the arbitration result; When any rule event is successfully executed, if the rule event triggers the state transition condition, the global state is updated according to the preset state transition rule, and the state change notification is broadcast to all terminals so that each terminal synchronizes the current global state.

2. The volleyball match process recording method based on rule events according to claim 1, characterized in that, The process of performing inter-event mutual exclusion arbitration on the submitted rule events includes the following steps: Establish an event mutual exclusion matrix, which is an N×N Boolean matrix, where N is the total number of event types, and the matrix element M[i][j]=1 indicates that the i-th type of event and the j-th type of event are mutually exclusive; When two rule events from different terminals are received in the same global state, it is determined whether they are mutually exclusive by querying the mutual exclusion matrix: If the corresponding element of the mutex matrix is ​​0, then the two events will be executed in the order they are received. If the corresponding element of the mutual exclusion matrix is ​​1, the concurrent arbitrator is triggered.

3. The volleyball match process recording method based on rule events according to claim 2, characterized in that, The concurrent arbitrator includes: Each arriving event is appended with a globally incrementing sequence number based on an atomic counter, which serves as the total sequence identifier for the event; The two mutually exclusive events are temporarily stored in a thread-safe blocking queue, and the execution order is determined according to the globally incrementing sequence number, with the one with the smaller sequence number being executed first. When executing a priority event, set a mutex semaphore to lock the resource group associated with that event type; After the priority event is completed, the mutex semaphore is released, and the first type of state parameters on which the subsequent event depends are re-verified to be still valid. The first type of state parameters include the player's on-field position identifier, the libero's available number of times counter, and the substitution number of times counter. If the verification passes, the next event is executed; if the verification fails, the event is discarded and a status code containing the reason for the failure is generated and returned to the source terminal.

4. The volleyball match process recording method based on rule events according to claim 3, characterized in that, Before determining the execution order based on the globally incrementing sequence number, the concurrent arbitrator also includes the following steps: A basic priority weight is pre-configured for each type of mutually exclusive event. The basic priority weight is set according to the volleyball game rules, wherein the basic priority of the libero substitution event is higher than that of the normal substitution event. When two mutually exclusive events are temporarily stored in the blocking queue, the system obtains the current second type of status parameters, which include the current score, the remaining challenge attempts in the current round, the remaining available attempts for the free agent, and the remaining attempts for substitution. Based on the basic priority weights and the second type of state parameters, the dynamic priority value of each mutual exclusion event is calculated using a weighted formula. Determining the execution order based on the globally incrementing sequence number includes the following steps: If the dynamic priority values ​​of each mutual exclusion event are equal, the execution order is determined according to the global incrementing sequence number.

5. The volleyball match process recording method based on rule events according to claim 4, characterized in that, After calculating the dynamic priority value of each event using the weighted formula, the process further includes the following steps: If the dynamic priority values ​​of two mutually exclusive events are not equal, the following priority arbitration steps are performed: Events with higher dynamic priority values ​​are designated as priority events, while those with lower values ​​are designated as delayed events. Before executing the priority event, an immutable snapshot copy is created for the first type of state parameters on which the delayed event depends, the snapshot copy including the field values ​​corresponding to the first type of state parameters; Execute the priority event and update the first type of state parameters in real time; After the priority event has been executed, the portion of the updated first type of status parameters related to the delayed event is compared field by field with the snapshot copy: If the values ​​of all first-class state parameters are the same as the field values ​​corresponding to the snapshot copy, then the delayed event is executed directly.

6. The volleyball match process recording method based on rule events according to claim 5, characterized in that, After comparing the portion of the updated first type of state parameters related to the delayed event with the snapshot copy field by field, the method further includes the following steps: If at least one first-class state parameter has a value that is different from the field value corresponding to the snapshot copy, then these first-class state parameters are marked as target state parameters and input into the rule engine; The rule engine determines, based on the volleyball rules, whether the target state parameters on which the delayed event depends still meet the execution conditions. If the execution conditions are met, then the delayed event is executed; If the execution conditions are not met, the delayed event is discarded and a structured log entry is generated. The structured log entry includes: the event identifier of the priority event, the event identifier of the delayed event, the failure reason code, and the values ​​of the target state parameter before and after the change. This structured log entry is appended to the competition event log chain to form a priority causal record.

7. The volleyball match process recording method based on rule events according to claim 6, characterized in that, Before comparing the portion of the updated first type of state parameters related to the delayed event with the snapshot copy field by field, the following steps are also included: Based on the event type of the delayed event, the dependency parameter mask corresponding to the event type is read from the pre-stored dependency parameter mask table. The dependency parameter mask is a binary vector, with each bit corresponding to a first type of state parameter. A mask bit of 1 indicates that the parameter is depended on by the delayed event. Based on the dependency parameter mask, a subset of dependent parameters is selected from the updated first type of state parameters; The step of comparing the portion of the updated first type of state parameters related to the delayed event with the snapshot copy field by field includes the following steps: Each parameter in the subset of parameters to be relied upon is compared one by one with the value of the corresponding parameter in the snapshot copy.

8. The volleyball match process recording method based on rule events according to claim 6, characterized in that, If the execution conditions are met, the delayed event will be executed, including the following steps: After determining that the delayed event meets the execution conditions, the original event parameter set carried by the delayed event is obtained. The original event parameter set includes the event operation object identifier and the expected value of resource consumption. Based on the difference between the changed value of the target state parameter and the corresponding value in the snapshot copy, a state offset mapping table is generated. The state offset mapping table records the identifier of each type of first-class state parameter that has changed and its mapping relationship before and after the change. Based on the state offset mapping table, a parameter semantic redirection operation is performed on the original event parameter set to eliminate the semantic conflict between the original event parameter set and the current global state caused by the change of the first type of state parameters due to the execution of priority events. The delayed event is executed using the parameter set corrected by the parameter semantic redirection operation.

9. The volleyball match process recording method based on rule events according to claim 8, characterized in that, The parameter semantic redirection operation performed on the original parameter set of the event specifically includes at least one of the following processing logics: The first redirection logic, in response to the delayed event being a substitution event, and the state offset mapping table indicating that the target on-field position identifier of the substituted player has been modified by the priority event, then according to the changed position identifier in the state offset mapping table, queries the on-field player identifier corresponding to the position identifier in the current global state, and replaces the replaced player identifier in the original parameter set of the event with the queried on-field player identifier. The second redirection logic, in response to the delayed event being a free agent replacement event and the state offset mapping table indicating that the free agent's remaining available count counter has been decremented to zero, marks the expected resource consumption value in the original parameter set of the event as an invalid value and attaches a prohibition flag, so that in the step of executing the delayed event using the parameter set corrected by the parameter semantic redirection operation, in response to the recognition of the prohibition flag, the execution operation of the delayed event is skipped.

10. A volleyball match process recording system based on rule events, used to implement the method described in any one of claims 1-9, characterized in that, include: The construction module is configured to build a global state machine for volleyball matches. The global state machine defines a finite set of states, including normal match state, challenge ruling state, and substitution process state, and configures a corresponding set of allowed event types and a set of prohibited event types for each state. The acquisition module (1) is configured to acquire the current global status of the system in real time and receive rule events submitted by any terminal among multiple terminals. The rule events include score change events, substitution events, challenge events and free agent substitution events. Filtering module (2), configured to perform first-level filtering on received rule events based on the set of allowed event types corresponding to the current global state: If the event type of the rule event belongs to the set of allowed event types in the current state, then the event is sent to the second level of processing; If the event belongs to the prohibited event type set, the event will be refused to be executed, a rejection message will be returned to the submitting terminal, and the event will not be recorded as an executed event. Arbitration module (3), the arbitration module (3) is configured to perform inter-event mutual exclusion arbitration on the submitted rule events in the second-level processing, and decide whether to execute or reject based on the arbitration result; The update module (4) is configured to update the global state according to the preset state transition rule when any rule event is successfully executed, if the rule event triggers the state transition condition, and broadcast the state change notification to all terminals so that each terminal can synchronize the current global state.

Images