A three-stage role migration control method and system based on a state machine

Abstract

The application discloses a three-stage role migration control method and system based on a state machine, relates to the technical field of virtual role state management, and is characterized in that a role template data and role instance data are stored in separate tables and are associated through a role identifier; a verification step only determines an output decision and creates a to-be-approved migration record when approval is required; an initialization step generates role instance data by deriving attribute values according to a formula derived from a target session and can be rolled back; an execution step updates a current space scene identifier and writes a position history record in a determined sequence after leaving the scene; a state transition guard step updates a transition among a to-be-approved, approved, executed and cancelled state according to a single atomic condition and represents a rejection by taking the number of affected records as zero, decouples the migration into three stages of read-only, roll-back and idempotent, and applies state machine constraints, thereby ensuring data consistency, concurrent determinacy and static data isolation under conditions of verification failure, concurrent approval cancellation and associated record cleaning.

Description

Technical Field

[0001] This invention relates to the field of virtual character state management technology, specifically to a control method and system for decoupling the migration process of virtual characters between different virtual scenes in a multi-user virtual interaction system and applying finite state machine constraints. Background Technology

[0002] In multi-user virtual interaction systems, virtual characters typically reside within a virtual scene space constructed by the platform. A complete session comprises multiple scenes, and virtual characters need to move between these scenes to advance the interaction process. Each virtual character maintains a runtime state within the session, including the current scene identifier, derived attribute values ​​calculated from basic attributes, temporary effects, equipment list, and skill progression records. Virtual characters also share a set of static data determined at creation time between sessions, including basic attributes, skill values, rule set identifiers, and background stories. When a virtual character migrates from one scene to another, the server needs to simultaneously complete three tasks: validity verification, runtime state construction, and the actual scene switching, while updating multiple records associated with that virtual character. The correctness of the above process under conditions of multi-user concurrent access, approval delays, and abnormal service interruptions directly determines the data consistency of the system's runtime state and the determinism of the interaction process.

[0003] In existing technologies, the scene migration of virtual characters is generally executed as an atomic operation, that is, permission verification, runtime state construction, and scene identifier update are completed sequentially within the same execution function, and the static data and runtime data of the virtual character are read and written as a single record. US Patent No. 8066571B2 discloses a system and method that enables virtual characters to be presented in multiple different virtual spaces. This method transfers the record of the virtual character between instances of multiple virtual spaces. Some information in the record is persistently retained between virtual spaces, while other information is specific to a certain virtual space. When the virtual character first enters a certain virtual space, the server configures the information specific to that virtual space and writes it back to the record. When the virtual character leaves, the changes are stored back in the record so that they can be reflected in other virtual spaces. However, this scheme treats the migration of virtual characters as a whole configuration and write-back of a single record, without decoupling the migration process at the architectural level into independent stages with different side effect boundaries. Therefore, when the migration process fails at a certain stage, the modifications to the record made in the previous stage cannot be rolled back without loss. Furthermore, since the read and write operations are performed on a single record basis and the configuration actions occur before entering the target virtual space, it is impossible to independently calculate the runtime data based on the derivation formula configured by the target session at the correct time. Also, it does not impose deterministic state transition constraints on the progress of the migration process to cope with competition under multi-user concurrency conditions.

[0004] Chinese patent application CN114768260A discloses a data processing method, apparatus, and electronic device for virtual characters in games. The method involves a client encapsulating the game state data of a virtual character into state frames and uploading them to a server. The server identifies other virtual characters in the same game scene based on scene identifiers and forwards the state frames. It then assigns game scenes to virtual characters according to the priority of multiple game scene allocation dimensions. However, this solution focuses on reducing the client's computational burden and improving state forwarding efficiency. It treats the determination and switching of the virtual character's scene as a single step, failing to distinguish the essential differences in failure semantics and side effect boundaries between legality judgment, runtime state construction, and scene switching during the migration process. Therefore, it lacks architectural solutions to issues such as verification failures leaving partially modified states, static data being polluted by runtime writes, concurrent approval and cancellation operations producing uncertain results, and omissions in cleaning up associated records during scene switching.

[0005] The common shortcoming of the aforementioned existing technologies lies in treating the scene migration of virtual characters as an indivisible atomic operation and reading and writing it as a single record. This forcibly couples three fundamentally different failure semantics: legality determination, runtime state construction, and scene switching. Consequently, under multiple uncertain conditions such as verification failure, concurrent approval and cancellation, and associated record cleanup, it is impossible to simultaneously guarantee data consistency of runtime state, concurrent determinism of the migration process, and prevention of cross-session static data contamination. Therefore, in multi-user virtual interaction systems, how to maintain data consistency of runtime state and concurrent determinism of the migration process during cross-scene migration of virtual characters under the aforementioned multiple uncertain conditions, while avoiding contamination of cross-session static data during the migration process, is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] To address the core bottleneck of existing multi-user virtual interaction systems that treat virtual character scene migration as a single atomic operation and read / write as a single record, thus failing to simultaneously ensure runtime state data consistency, migration process concurrency determinism, and cross-session static data integrity under multiple uncertain conditions such as verification failure, concurrent approval and cancellation, and associated record cleanup, this invention provides a three-stage role migration control method and system based on a state machine. By decoupling the migration process into a read-only verification step, a rollbackable initialization step, and an idempotent execution step, and applying atomic constraints to the state transitions of the migration record using the allowed source state set of a finite state machine, and under the premise of hierarchical storage of role template data and role instance data, this invention achieves data consistency and concurrency determinism in the migration process from the principle level of stage side effect boundaries and state transition constraints.

[0007] The technical solution of this invention is: a three-stage role migration control method based on a state machine, applied to the server side of a multi-user virtual interaction system. The server side stores role template data and role instance data, which are stored in different data tables and associated through role identifiers. The method includes: a verification step, in response to a migration request for a virtual role, sequentially performing read-only migration legality checks without modifying any persistent data, outputting a migration allow decision, a migration deny decision, or a decision requiring approval, and creating a migration record with a current status of pending approval when an approval decision is output; and an initialization step, after obtaining a migration allow decision, reading basic attributes from the role template data, calculating derived attribute values ​​according to the derivation formula configured in the target session, and generating role instance data. The initialization step synchronizes the global story time of the target session with the personal story time of the virtual character and creates a scene participation record. If the initialization step fails, it rolls back the created temporary record without touching the character template data. The execution step performs cascading exit processing on the old scene where the virtual character is located in a deterministic order, updates the current spatial scene identifier of the character instance data to the target scene identifier, and writes it into the location history. The state transition guard step checks and updates the current state of the migration record based on the source state set allowed by the target state, using a single atomic condition update, when the migration record is transferred between the states of pending approval, approved, executed, and canceled. The number of affected records is zero to indicate that the current state does not allow the transfer or that the migration record has been concurrently modified.

[0008] Furthermore, the allowed sources of the state set satisfy the following conditions: pending approval is not allowed to be transitioned from any state; approved is only allowed to be transitioned from pending approval; executed is allowed to be transitioned from pending approval or approved; cancelled is allowed to be transitioned from pending approval or approved, and both executed and cancelled are final states; the cascading departure process is executed in a deterministic order of updating the departure time of the scene participation record, writing back the departure plot time of the location history record, and updating the current spatial scene identifier.

[0009] This invention also provides a three-stage role migration control system based on a state machine, applied to the server side of a multi-user virtual interaction system. The server side stores role template data and role instance data located in different data tables and associated through role identifiers. The system includes: a verification module, used to respond to migration requests for virtual roles, sequentially performing read-only migration legality checks without modifying any persistent data, outputting a migration allow decision, a migration deny decision, or a decision requiring approval, and creating a migration record with a current status of pending approval when an approval decision is output; and an initialization module, used to read basic attributes from the role template data after obtaining a migration allow decision, calculate derived attribute values ​​according to the derivation formula configured in the target session, generate role instance data, and initialize the target session's full... The scene's timeline is synchronized with the virtual character's personal timeline. Scene participation records are created, and temporary records are rolled back without affecting the character's template data in case of initialization failure. The execution module is used to perform cascading exit processing on the old scene where the virtual character is located in a deterministic order, update the current spatial scene identifier of the character instance data to the target scene identifier, and write it to the location history record. The state transition guard module is used to check and update the current state of the migration record based on the set of source states allowed by the target state when the migration record is transferred between the states of pending approval, approved, executed, and canceled. The current state of the migration record is checked and updated with a single atomic condition update, and the number of affected records is zero to indicate that the current state does not allow the transfer or that the migration record has been concurrently modified.

[0010] The beneficial effects of this invention are as follows: Firstly, by decoupling the migration process into a read-only verification step, a rollbackable initialization step, and an idempotent execution step, no modified persistent state is left behind when verification fails. The mechanism is that the verification step is constrained to a read-only determination that does not modify any persistent data; the temporary record generated in the initialization step is rolled back upon failure; and the execution step is constrained to a repeatable idempotent operation. Each of the three steps has a clear and non-interfering boundary for side effects, thus fundamentally eliminating the problem of partially modified state left behind due to atomic operations failing midway in existing technologies. Compared to treating migration as a holistic configuration and write-back of a single record, the phase decoupling of this invention allows failures in any phase to be handled locally without affecting other phases, avoiding the generation of dirty states.

[0011] Secondly, by storing role template data and role instance data in a hierarchical manner and calculating derived attribute values ​​according to the derivation formula configured in the target session during the initialization step, the migration process does not touch the static data across sessions, and the derived attribute values ​​are correctly generated according to the rule set of the target session at runtime. The mechanism is that role template data and role instance data are stored in different data tables and linked by role identifiers. The migration process only modifies the role instance data, thus preventing static data across sessions from being corrupted by runtime writes. Simultaneously, the calculation of derived attribute values ​​is postponed to the initialization step after entering the target session, allowing calculation based on the derivation formula configured in the target session rather than the source session's derivation formula. This solves the problem in existing technologies where the derivation attribute values ​​cannot be calculated at the correct time according to the target session's rule set due to the overall reading and writing of a single record.

[0012] Third, by imposing constraints on the state transitions of the migration records through the allowed source state set of the finite state machine, and merging state checks and updates with a single atomic conditional update, deterministic results are produced under concurrent approval and cancellation operations. The mechanism is that the allowed source state set stipulates that each target state can only be transitioned into from a specific source state, and executed and cancelled states are constrained to be final states from which transitions are not allowed, thus excluding illegal transitions at the state diagram level. The single atomic conditional update merges the current state check and update into the same conditional update statement, using zero affected records as a unified signal that the current state does not allow the transition or has been concurrently modified, eliminating the read-modify-write contention window inherent in checking the current state before updating, so that the final result of concurrent approval and cancellation operations no longer depends on the execution order of the two.

[0013] Fourth, the synergy of stage decoupling, hierarchical storage, and state machine constraints produces a technical effect that exceeds the sum of the individual effects of each feature. The mechanism lies in the fact that stage decoupling provides the necessary stage boundaries for the initialization step to independently calculate derived attribute values ​​based on the target session rule set, provides clear guard objects for state machine constraints, and provides independent execution opportunities for the execution steps to perform cascading exit processing in a deterministic order; state machine constraints impose determinism on the advancement between stages, allowing pending migration records created for approval decisions to be safely advanced or canceled after crossing the approval time window; and hierarchical storage ensures that static data remains untouched during stage decoupling. These three elements support each other, forming a complete technical means to simultaneously guarantee data consistency, concurrent determinism, and static data isolation under multiple uncertain conditions. This synergistic effect is unattainable by existing technologies that treat migration as a single atomic operation. Attached Figure Description

[0014] Figure 1 This is the overall flowchart of the three-stage role transition control method based on state machine of the present invention; Figure 2 This is an architecture diagram of the three-stage role transition control system based on a state machine according to the present invention; Figure 3 This is a schematic diagram of the state machine transition of the migration record in this invention. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below 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 are not intended to limit the invention.

[0016] The state machine-based three-stage role migration control method described in this embodiment is applied to the server side of a multi-user virtual interaction system. The multi-user virtual interaction system includes a client layer, a server layer, and a data layer. The client layer includes a host client and several player clients, which interact with the server via a communication gateway. The server is configured with at least a cooperating verification module, initialization module, execution module, and state transition guard module. The data layer stores at least role template data, role instance data, rule set configurations, migration records, scene participation records, and location history records.

[0017] In this embodiment, the server splits the virtual character's data into two independent entities and stores them in different data tables. The first entity is the character template data, which stores static data of the virtual character that remains unchanged between sessions, including basic attributes, skill values, rule set identifiers, equipment lists, and background stories. This character template data is written when the virtual character is created and can only be modified through explicit template update operations, remaining untouched during migration. The second entity is the character instance data, which stores dynamic data of the virtual character during runtime within a session, including the current spatial scene identifier, current values ​​of derived attributes, maximum values ​​of derived attributes, temporary effects, personal story duration, and skill growth markers. This character instance data is calculated and generated by the server based on the character template data when the virtual character first joins the session and is continuously updated during migration. The character template data and the character instance data are linked through a character identifier, which is a field that uniquely identifies a virtual character. The character template data table contains fields such as character identifier, character code, user identifier, rule set identifier, name, basic attributes, skill values, equipment list, and background story. The character instance data table contains fields such as record identifier, character identifier, session identifier, current space scene identifier, personal story time, current value of derived attributes, temporary effects, equipment list, and skill growth marker. The rule set configuration contains derived formulas. The two data tables are linked through the character identifier, and the migration operation only modifies the character instance data table without affecting the character template data table.

[0018] This embodiment explicitly divides the process of a virtual character migrating from one scene to another into three independent stages with clear failure semantics: a verification stage implemented by a verification step, an initialization stage implemented by an initialization step, and an execution stage implemented by an execution step. A finite state machine constraint is imposed on the lifecycle of the migration record by a state transition guard step that runs through all three stages. See also Figure 1 The method, upon responding to a migration request for a virtual character, first enters a verification step to determine the read-only legality of the migration. After obtaining permission, it enters an initialization step to construct character instance data, followed by an execution step to complete the actual scene switching and associated record updates. During this process, each state change of the migration record is constrained by a state transition guard step with a single atomic condition update. Of the three phases, the verification phase is constrained to be a read-only phase that does not modify any persistent data; the initialization phase is constrained to be a rollback phase that generates temporary records and rolls back in case of failure; and the execution phase is constrained to be an idempotent phase that can be executed repeatedly. The specific implementation process of each step is described in detail below.

[0019] The verification step responds to migration requests for virtual characters by sequentially performing read-only migration validity checks without modifying any persistent data. It outputs a decision to allow migration, reject migration, or require approval. If an approval-required decision is output, a migration record with a current status of "pending approval" is created. The migration request includes at least a character identifier and a target scene identifier; in some implementations, it also includes the migration type and the identity identifier of the migration initiator. The core characteristic of this read-only migration validity check is that all checks are read-only queries on the data layer. It does not write to or modify any persistent data in character template data, character instance data, scene participation records, or location history records. Therefore, regardless of the verification result, the verification step itself does not leave any side effects on the data layer.

[0020] In this embodiment, the read-only migration legality determination includes multiple checks performed sequentially from high to low priority. These checks include a forced migration exemption check, a session membership check, a duplicate entry check, and a scene access policy check. See also Figure 1 The verification steps are performed one by one in the order described above. Once any check results in a rejection decision, the subsequent checks are terminated and the process is returned, thus ensuring the completeness of the judgment while avoiding unnecessary query overhead.

[0021] The forced migration exemption check is the highest priority check. The server reads the migration type of the migration request. When the migration type is forced migration, it skips all subsequent checks and directly outputs a decision to allow migration. The forced migration is used to represent a migration initiated by the host with the highest authority. Its significance lies in the fact that the host may need to move the virtual character to a specified scene without being bound by the regular access policy when advancing the interaction process. Therefore, forced migration is given the highest priority of exempting subsequent checks.

[0022] The session member identity check is the second highest priority check. The server queries the role instance data to confirm that the virtual role has a role instance in the target session; if it does not exist, it outputs a migration rejection decision, using non-session member status as the rejection reason. The significance of this check is that only virtual roles that have joined the target session are eligible to migrate between scenarios within that session; virtual roles that have not joined the target session should not be allowed to migrate directly to the scenarios within that session.

[0023] The duplicate entry check is a secondary check. The server reads the current spatial scene identifier from the virtual character's role instance data and compares it with the target scene identifier of the migration request. If they are equal, it indicates that the virtual character is already in the target scene, and a migration rejection decision is output, using "already in the target scene" as the reason for rejection. The significance of this check is to avoid redundant association records generated by repeatedly performing migration for virtual characters already in the target scene.

[0024] The scenario access policy check is the lowest priority check and the one that ultimately determines the migration path. The server queries the access policy field of the target scenario and makes a decision based on the value of the access policy field. In this embodiment, the access policy field value is one of locked, requires approval, or is open. When the access policy field is locked, a migration rejection decision is output, with the scenario being locked as the reason for rejection; when the access policy field requires approval, an approval decision is output, and a migration record with the current status of pending approval is created for the host's approval; when the access policy field is open, a migration allow decision is output. The key here is that when the access policy field requires approval, the verification step does not immediately execute the migration, but instead materializes the migration decision into a migration record with the current status of pending approval and persists it. This allows the migration to proceed deterministically after the time window required for host approval has passed, through subsequent approval or cancellation operations, rather than synchronously waiting for the approval result within the verification step. This design transforms the migration from an instantaneous operation into a process that can be advanced across time windows, laying the foundation for deterministic constraints on subsequent state transition guarding steps under concurrent conditions.

[0025] In some implementations, the read-only migration legality determination also includes rule set matching verification, which compares the rule set identifier of the character template data with the rule set identifier of the target session when the virtual character first joins the session. If they are inconsistent, a migration rejection decision is output to prevent the virtual character with the mismatched rule set from entering the session. It is important to emphasize that all the above checks in the verification step are read-only queries. A migration record with a current status of pending approval is created only when the scene access policy check outputs an approval decision. The creation of this migration record is a registration of the migration process's own state and does not change the virtual character's runtime state. Therefore, the verification step does not modify the virtual character's character instance data, character template data, and their associated records, maintaining the side effect boundary of the verification phase as a read-only phase.

[0026] III. Specific Implementation of Initialization Steps The initialization step executes after the verification step outputs a migration decision that allows it. It is responsible for constructing the complete runtime state of the virtual role in the target session, i.e., generating role instance data. The core characteristic of the initialization step is that all records it generates are temporary. If any sub-operation of the initialization step fails, the server rolls back the created temporary records. Furthermore, the role template data is never touched throughout the entire initialization step, thus ensuring that the initialization phase serves as the side effect boundary of the rollback phase and preventing the contamination of static data across sessions.

[0027] In this embodiment, the initialization step performs a rule set comparison before calculating derived attribute values. The server reads the rule set identifier of the role template data and the rule set identifier of the target session, and compares whether they are consistent. If they are inconsistent, the migration is stopped and the created temporary records are rolled back, thereby avoiding the generation of incorrect role instance data based on mismatched derivation formulas; if they are consistent, the calculation of derived attribute values ​​proceeds. The significance of placing the rule set comparison before the calculation of derived attribute values ​​is that the calculation of derived attribute values ​​depends on the derivation formula configured by the target session. Only when the role template data and the target session use the same rule set is the calculation of the basic attributes of the role template data based on the target session's derivation formula meaningful. Therefore, rule set comparison is a prerequisite for ensuring the correctness of derived attribute value calculation.

[0028] After the rule set comparison passes, the server reads the basic attributes from the role template data and the derivation formula configured for the target session from the rule set configuration, and calculates the derived attribute value according to the derivation formula. The derived attribute value includes the maximum value of the derived attribute and the current value of the derived attribute. The server calculates the maximum value of the derived attribute according to the derivation formula, initializes the current value of the derived attribute to the maximum value of the derived attribute, and then writes a data structure consisting of the current value of the derived attribute and the maximum value of the derived attribute into the role instance data. In this embodiment, the data structure is organized in the form of attribute name as key and structure containing the current value of the derived attribute and the maximum value of the derived attribute as value.

[0029] Taking an exemplary rule set as an example, the derivation formula configured in the target session maps several basic attributes to the corresponding maximum values ​​of derived attributes. For example, the maximum health value is the sum of the Constitution and Body Type attributes divided by 10 and then rounded down (i.e., the sum of the Constitution and Body Type attributes is divisible by 10); the maximum mana value is the Willpower attribute divided by 5 and then rounded down (i.e., the Willpower attribute is divisible by 5); and the maximum sanity value is directly taken from the Willpower attribute value. These derivation formulas are inherent to the rule set configured in the target session. Different rule sets have different derivation formulas, thus postponing the calculation of derived attribute values ​​to the initialization step after entering the target session. This allows the same character template data, when added to sessions using different rule sets, to independently calculate derived attribute values ​​that conform to the rules of that session based on the derivation formula configured in each session. After calculation, each derived attribute is written to the current value field of the derived attribute in the character instance data, using the attribute name as the key and a structure containing the current value and maximum value as the value. For example, health is initialized with its current value equal to its maximum value, and other derived attributes follow the same pattern.

[0030] After the derived attribute values ​​are calculated and written to the character instance data, the initialization step performs personal story time synchronization. The server reads the global story time of the target session and writes it as the virtual character's personal story time into the character instance data. The global story time is the shared story progression time during the interaction process of the target session, and the personal story time is the virtual character's own story progression time. Initializing the personal story time to the global story time at the moment of entering the target session ensures that the virtual character's story time when joining the session is consistent with the overall story progress of the session, providing a unified time reference for writing departure and entry story times in subsequent location history records.

[0031] The initialization step then creates a scene participation record. The server inserts a new record into the scene participation record, writing the joining time into the new record and setting the departure time to null, to indicate that the virtual character has joined the corresponding scene and has not yet left. In this embodiment, the initialization step also includes automatically joining the first spatial type scene, that is, the server queries the first spatial type scene in the target session sorted by creation time and adds the virtual character to the first spatial type scene. The spatial type scene is a scene with spatial attributes that the virtual character can actually occupy, while the non-spatial type scene does not carry the spatial location of the virtual character. The significance of automatically joining the first spatial type scene is that when the virtual character first joins the session, it needs a definite initial spatial location, and using the first spatial type scene as the initial location provides a definite starting point for subsequent scene migrations.

[0032] It is important to emphasize that the character instance data generated, the personal story time written, and the scene participation records created during the initialization step are all runtime records newly created or updated within the target session, and are rollbackable temporary records. If any sub-operation of the initialization step, such as rule set comparison, derived attribute value calculation, personal story time synchronization, or scene participation record creation or automatic addition to the first space type scene, fails, the server rolls back the aforementioned temporary records, restoring the data layer to its state before the initialization step was executed. Throughout this process, no character template data is written. Therefore, the initialization phase maintains the side effect boundaries of the rollbackable phase while ensuring the isolation of static data across sessions.

[0033] The execution step is executed after the initialization step is completed, or after a migration record requiring approval has been approved and advanced to the approved stage. It is responsible for completing the actual scene switching and updating the associated records. The core characteristic of the execution step is that it is constrained to be a repeatable idempotent operation. That is, when it is executed repeatedly due to abnormal interruption, it will not produce a final result different from the single execution, thus ensuring that the execution phase serves as the side effect boundary of the idempotent phase.

[0034] The execution steps first involve performing cascading exit processing on the old scene where the virtual character is located in a deterministic order. See also... Figure 1The cascading departure process executes three sub-operations in the following deterministic order. The first sub-operation is to update the departure time of the virtual character in the old scene recorded in the scene participation record to the current time, indicating that the virtual character has left the old scene. The second sub-operation is to query the global story time of the target session and write the obtained global story time back to the latest departure story time of the virtual character in the old scene recorded in the location history record, indicating the story time when the virtual character left the old scene. The third sub-operation is to update the current spatial scene identifier of the character instance data to the target scene identifier, indicating that the scene in which the virtual character is currently located has changed from the old scene to the target scene.

[0035] The order of the three sub-operations is strictly constrained as follows: first, update the departure time of the scene participation record; second, write back the departure plot time of the location history record; and finally, update the current spatial scene identifier. The significance of this deterministic order is that both the scene participation record and the location history record must complete the departure registration for the old scene before the current spatial scene identifier is updated. If the current spatial scene identifier is updated before departure registration, and an abnormal interruption occurs after updating the current spatial scene identifier but before departure registration, an inconsistent state will arise where the virtual character's current spatial scene identifier points to the target scene, while the scene participation record or location history record for the old scene has not yet registered departure—a state known as an isolated record. Placing departure registration before updating the current spatial scene identifier ensures that even if an interruption occurs after departure registration but before updating the current spatial scene identifier, subsequent operations can be re-executed based on idempotency when the execution steps are repeated, thus avoiding persistent inconsistencies.

[0036] In this embodiment, when the virtual character enters the target scene, the server first performs a complete cascading exit process on the old scene to ensure that the exit plot time recorded in the location history is correctly written, and then performs the relevant operations for entering the target scene. After completing the cascading exit process, the server inserts a new record for the virtual character in the target scene in the scene participation record and a new record for the virtual character in the target scene in the location history. The new record in the location history includes at least the target scene identifier, the entry plot time, and the migration type. The entry plot time is the plot moment when the virtual character arrives at the target scene, and the migration type is used to indicate whether this migration is one of joining, scheduled migration, or forced migration.

[0037] In this embodiment, the execution steps further include broadcasting a location change event. The server broadcasts the location change event to the online client via a message channel. The location change event includes the character identifier, source scene identifier, target scene identifier, and migration type, and inserts a system transition message into the chat stream. The message channel is used to transmit real-time events between the server and the online client. After receiving the location change event, the online client updates the scene where its locally displayed virtual character is located. The system transition message is used to record the migration in the chat stream for the interactive participants to be aware of. Broadcasting the location change event and inserting the system transition message are external notifications of the migration result, do not change the character instance data that has completed the switch, and are compatible with the idempotency of the execution steps.

[0038] To further eliminate any remaining isolated records that may be caused by abnormal service interruptions, the method in this embodiment also includes a periodic repair step. The server periodically executes the periodic repair step, scanning the location history for records where the departure plot time is empty and the corresponding character is no longer in the corresponding scene, and then writing back the departure plot time using the global plot time of the target session. An empty departure plot time and the corresponding character no longer in the corresponding scene indicate that the virtual character corresponding to the record has actually left the scene, but due to an abnormal interruption, its departure plot time was not written, thus constituting an isolated record. The periodic repair step writes back the departure plot time of the isolated record using the current global plot time, thereby restoring the remaining isolated records to a consistent state. The periodic repair step works in conjunction with the deterministic order of the cascading departure processing in the execution step. The former avoids the generation of isolated records through sequence constraints during normal operation, while the latter eliminates generated isolated records through periodic scanning after an abnormal interruption. Together, they ensure the consistency of associated records.

[0039] The state transition guard step runs through the verification, initialization, and execution steps. When a migration record is transferred between the sets of states (pending approval, approved, executed, and canceled), it checks and updates the current state of the migration record using a single atomic conditional update, based on the set of source states allowed by the target state. A zero number of affected records indicates that the current state does not allow the transfer or that the migration record has been concurrently modified. See also Figure 3 The lifecycle of the migration record is controlled by a finite state machine that includes four states: pending approval, approved, executed, and canceled.

[0040] In this embodiment, the allowed sources of the state set satisfy the following constraints: The "Pending Approval" state cannot be transitioned from any other state; that is, "Pending Approval" is the initial state of a migration record and can only be assigned at creation time, not from other states. The "Approved" state can only be transitioned from the "Pending Approval" state; that is, only migration records in the "Pending Approval" state can be approved as "Approved." The "Executed" state can be transitioned from either the "Pending Approval" or "Approved" state; that is, a migration record can be executed directly from the "Pending Approval" state or after being approved as "Approved." The "Cancelled" state can be transitioned from either the "Pending Approval" or "Approved" state; that is, migration records in the "Pending Approval" or "Approved" state can be cancelled. Furthermore, both "Executed" and "Cancelled" states are final states and cannot be transitioned out; that is, once a migration record enters the "Executed" or "Cancelled" state, its state no longer changes. These asymmetric constraints on allowed sources exclude illegal state transitions at the state diagram level, such as prohibiting executed migration records from being revived as "Pending Approval" and prohibiting cancelled migration records from being executed again.

[0041] The single atomic conditional update combines the current state check and update of the migration record into a single conditional update statement. The conditional update statement assigns the target state to the current state based on the record identifier of the migration record and the set of source states allowed by the target state. Specifically, when the conditional update statement is executed, it assigns the target state to the current state of the migration record only if the current state of the migration record belongs to the set of source states allowed by the target state; if the current state of the migration record does not belong to the set of allowed source states, the conditional update statement does not apply to any record. After the conditional update statement is executed, it returns the number of affected records. When the number of affected records is zero, the current transfer is aborted. A zero number of affected records indicates that the current state does not allow the transfer or that the migration record has been concurrently modified; that is, either the current state of the migration record is not within the set of allowed source states, or the migration record has been modified to another state by another concurrent operation before the execution of this conditional update statement.

[0042] The significance of merging the current state check and update into a single conditional update statement lies in the fact that if a step-by-step approach is adopted—first querying the current state of the migration record, then determining whether the current state belongs to the allowed source state set, and finally updating the current state—a time window exists between the query and update. Within this window, another concurrent operation may have already modified the current state of the migration record, causing updates based on expired states to violate state machine constraints, i.e., generating read-modify-write contention. Taking the concurrent occurrence of the host's approval operation and the player's cancellation operation as an example, if a step-by-step approach is used, both operations may first query the pending approval state, then one updates it to approved, and the other updates it to cancelled. The final result depends on the execution order of the two, exhibiting non-determinism. However, with a single atomic conditional update, the approval operation updates it to approved with pending approval as an allowed source state, and the cancellation operation updates it to cancelled with pending approval as an allowed source state. The first execution removes the migration record from the pending approval state, while the second execution, because its current state no longer belongs to its allowed source state set, has zero affected records and is thus aborted. Therefore, the final result of concurrent approval and cancellation operations no longer depends on the execution order of the two, but is uniquely determined by the atomicity of a single atomic condition update.

[0043] In this embodiment, when the target session ends, the server performs session-level cascading cleanup. The server batch-transfers migration records currently in the pending approval or approved state to cancelled status via atomic condition updates. This batch transfer, executed via atomic condition updates, updates the current status of eligible migration records to cancelled status, using pending approval or approved status as the allowed source state set. This ensures that migration records still pending approval or approved but not yet executed at the end of the session are uniformly set to cancelled, preventing unresolved migration records from remaining after the session ends. Executing batch transfers via atomic condition updates also ensures consistency between session-end cleanup and other concurrent operations. That is, migration records that have been advanced to executed status before the batch transfer is executed will not be incorrectly changed by this batch transfer because their current status no longer belongs to the allowed source state set of pending approval or approved status.

[0044] As can be seen from the coordination of the above verification steps, initialization steps, execution steps and state transition guarding steps, this embodiment decouples the migration process into three stages with clear failure semantics and side effect boundaries, and imposes constraints on the state transition of the migration record with the allowed source state set of the finite state machine and a single atomic condition update. Under multiple uncertain conditions such as verification failure, concurrent approval and cancellation and associated record cleanup, it simultaneously ensures the data consistency of runtime state, the concurrent determinism of the migration process and the isolation of static data across sessions.

[0045] See Figure 2 The present invention also provides a three-stage role transition control system based on a state machine, applied to the server side of a multi-user virtual interaction system. The server side stores role template data and role instance data located in different data tables and associated with role identifiers. The system includes a verification module, an initialization module, an execution module, and a state transition guard module. Each module corresponds one-to-one with each step in the aforementioned method embodiments, and the specific implementation process can be referred to the corresponding descriptions in the aforementioned method embodiments.

[0046] The multi-user virtual interaction system to which the system resides structurally comprises a client layer, a server layer, and a data layer. The client layer includes a host client and several player clients. The server interacts with the client layer via a communication gateway and is configured with at least a migration request access module, a three-stage migration orchestration engine, and a cascading cleanup orchestration module. The three-stage migration orchestration engine includes the verification module, the initialization module, and the execution module. The state transition guard module works collaboratively with the three-stage migration orchestration engine. The data layer stores at least character template data, character instance data, rule set configurations, migration records, scene participation records, and location history records. The server can be deployed on electronic devices such as computers and servers. The data layer can be implemented using a relational database or other persistent storage. The character template data and the character instance data correspond to different data tables in the data layer.

[0047] The verification module responds to migration requests for virtual characters, performing read-only migration legality checks sequentially without modifying any persistent data. It outputs a decision to allow migration, reject migration, or require approval, and creates a migration record with a current status of "pending approval" when an approval decision is output. In this embodiment, the read-only migration legality checks performed by the verification module include mandatory migration exemption checks, session membership checks, duplicate entry checks, and scene access policy checks, performed sequentially from highest to lowest priority. The verification module completes these checks through read-only queries of the data layer, without writing to any persistent data, and only creates a migration record with a current status of "pending approval" when the scene access policy check indicates an approval decision. The specific implementation process of the verification module corresponds to the implementation process of the verification steps in the aforementioned method embodiment.

[0048] The initialization module, upon obtaining a migration permission decision, reads basic attributes from the character template data, calculates derived attribute values ​​according to the derivation formula configured in the target session, generates character instance data, synchronizes the global story time of the target session with the virtual character's personal story time, creates scene participation records, and rolls back the created temporary records without touching the character template data in case of initialization failure. In this embodiment, before calculating the derived attribute values, the initialization module compares the rule set identifier of the character template data with the rule set identifier of the target session. If they are inconsistent, the migration is stopped and the created temporary records are rolled back. If they are consistent, the maximum value of the derived attribute is calculated according to the derivation formula, and the current value of the derived attribute is initialized to the maximum value of the derived attribute. The character instance data generated, the written personal story time, and the created scene participation records by the initialization module are all rollbackable temporary records, and the initialization module never touches the character template data throughout the entire process. The specific implementation process of the initialization module corresponds to the implementation process of the initialization steps in the aforementioned method embodiment.

[0049] The execution module is used to perform cascading departure processing on the old scene where the virtual character is located in a deterministic order, updating the current spatial scene identifier of the character instance data to the target scene identifier and writing it into the location history record. In this embodiment, the cascading departure processing performed by the execution module is executed in a deterministic order of updating the departure time of the scene participation record, writing back the departure plot time of the location history record, and updating the current spatial scene identifier. After completing the cascading departure processing, a scene participation record and a location history record are created for the virtual character in the target scene. The execution module can also broadcast the location change event to the online client through a message channel and insert a system transition message into the chat stream. The server may also include a timed repair module that works in conjunction with the execution module, used to periodically scan the location history record for records where the departure plot time is empty and the corresponding character is no longer in the corresponding scene, and write back the departure plot time with the global plot time of the target session. The specific implementation process of the execution module corresponds to the implementation process of the execution steps and the timed repair steps in the aforementioned method embodiment.

[0050] The state transition guard module is used to check and update the current state of a migration record when it is transferred between a set of states consisting of pending approval, approved, executed, and cancelled. Based on the set of source states allowed by the target state, it checks and updates the current state of the migration record using a single atomic conditional update. A zero number of affected records indicates that the current state does not allow the transfer or that the migration record has been concurrently modified. In this embodiment, the allowed sources used by the state transition guard module satisfy the following constraints: pending approval does not allow transitions from any state; approved only allows transitions from pending approval; executed allows transitions from pending approval or approved; cancelled allows transitions from pending approval or approved, and both executed and cancelled are final states. The state transition guard module combines the current state check and update of the migration record into the same conditional update statement, using a zero number of affected records in this conditional update statement as a unified signal that the current state does not allow the transfer or has been concurrently modified, thereby producing a deterministic result under concurrent approval and cancellation operations. The specific implementation process of the state transition guard module corresponds to the implementation process of the state transition guard steps in the aforementioned method embodiment.

[0051] Those skilled in the art will understand that the aforementioned verification module, initialization module, execution module, and state transition guard module can be implemented by the server's processor executing corresponding computer programs, with each module cooperating with the others through scheduling by the three-stage migration orchestration engine. The output of the verification module serves as the input of the initialization module, and the role instance data generated by the initialization module serves as the processing object of the execution module. The state transition guard module applies constraints to each state transition of the migration record throughout the verification module, initialization module, and execution module, thereby achieving the technical effects described in the aforementioned method embodiments at the system level.

[0052] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A three-stage role transition control method based on a state machine, characterized in that, A server-side application for a multi-user virtual interaction system, wherein the server stores role template data and role instance data, the role template data and the role instance data are stored in different data tables and associated through a role identifier, the method comprising: The verification step, in response to a migration request for a virtual character, sequentially performs read-only migration legality checks without modifying any persistent data, outputting a decision to allow migration, a decision to reject migration, or a decision requiring approval, and creating a migration record with a current status of pending approval when an approval decision is output; The initialization step involves, after obtaining permission to migrate, reading basic attributes from the character template data, calculating derived attribute values ​​based on the derivation formula configured for the target session, generating character instance data, synchronizing the global story time of the target session with the personal story time of the virtual character, and creating scene participation records; if the initialization step fails, it rolls back the created temporary records without affecting the character template data. The execution steps involve performing cascading exit processing on the old scene where the virtual character is located in a deterministic order, updating the current spatial scene identifier of the character instance data to the target scene identifier, and writing it into the location history record. The state transition guard step involves checking and updating the current state of the migration record based on the set of source states allowed by the target state, when the migration record is transferred between states consisting of pending approval, approved, executed, and canceled. The current state of the migration record is checked and updated with a single atomic condition update, and the number of affected records is zero to indicate that the current state does not allow the transfer or that the migration record has been concurrently modified.

2. The three-stage role transition control method based on a state machine according to claim 1, characterized in that, The read-only migration legality determination includes multiple checks performed sequentially from high to low priority. These checks include a forced migration exemption check, a session membership check, a duplicate entry check, and a scene access policy check. The scene access policy check makes a decision based on the access policy field of the target scene. When the access policy field is locked, a migration rejection decision is output. When the access policy field requires approval, an approval decision is output and a migration record with the current status of pending approval is created. When the access policy field is open, a migration allow decision is output.

3. The three-stage role transition control method based on a state machine according to claim 2, characterized in that, The allowed sources of the state set satisfy the following condition: the state to be approved is not allowed to be transitioned from any state. The "approved" status can only be transferred from the "pending approval" status; the "executed" status can be transferred from either the "pending approval" status or the "approved" status; the "cancelled" status can be transferred from either the "pending approval" status or the "approved" status; both the "executed" and "cancelled" statuses are final states and cannot be transferred out.

4. The three-stage role transition control method based on a state machine according to claim 3, characterized in that, The single atomic conditional update combines the current state check and update of the migration record into the same conditional update statement. The conditional update statement assigns the target state to the current state based on the record identifier of the migration record and the set of source states allowed by the target state. The transfer is terminated when the number of affected records is zero.

5. The three-stage role transition control method based on a state machine according to claim 4, characterized in that, Before calculating the derived attribute value, the initialization step compares the rule set identifier of the character template data with the rule set identifier of the target session. If they are inconsistent, the migration is stopped and the created temporary record is rolled back. If they are consistent, the maximum value of the derived attribute is calculated according to the derivation formula configured in the target session, and the current value of the derived attribute is initialized to the maximum value of the derived attribute. The data structure consisting of the current value of the derived attribute and the maximum value of the derived attribute is written into the character instance data.

6. The three-stage role transition control method based on a state machine according to claim 5, characterized in that, The cascading departure process is executed in a deterministic order: the departure time of the scene participation record is updated to the current time; the global story time of the target session is queried and written back to the departure story time of the location history record; the current spatial scene identifier of the character instance data is updated; and the method also includes a timed repair step, scanning the location history record where the departure story time is empty and the corresponding character is no longer in the corresponding scene, and writing back the departure story time with the global story time.

7. The three-stage role transition control method based on a state machine according to claim 1, characterized in that, The initialization step further includes: querying the first space type scene in the target session sorted by creation time, adding the virtual character to the first space type scene, writing the joining time into the scene participation record and setting the departure time to null.

8. The three-stage role transition control method based on a state machine according to claim 1, characterized in that, The execution steps also include: broadcasting a location change event to the online client through a message channel, the location change event including the role identifier, source scene identifier, target scene identifier and migration type, and inserting a system transition message into the chat stream.

9. The three-stage role transition control method based on a state machine according to claim 1, characterized in that, When the target session ends, migration records with current status of pending approval and current status of approved are batch-transferred to canceled via atomic condition update.

10. A three-stage role transition control system based on a state machine, used to implement the three-stage role transition control method based on a state machine as described in any one of claims 1-9, characterized in that, A server-side application for a multi-user virtual interaction system, wherein the server-side stores role template data and role instance data located in different data tables and associated through role identifiers, and the system includes: The verification module is used to respond to migration requests for virtual characters. Without modifying any persistent data, it sequentially performs read-only migration legality judgments and outputs a decision to allow migration, reject migration, or require approval. When an approval decision is output, it creates a migration record with the current status of pending approval. The initialization module is used to read basic attributes from the character template data after obtaining a migration permission decision, calculate derived attribute values ​​according to the derivation formula configured in the target session and generate character instance data, synchronize the global story time of the target session with the personal story time of the virtual character, create scene participation records, and roll back the created temporary records without touching the character template data when initialization fails. The execution module is used to perform cascaded exit processing on the old scene where the virtual character is located in a deterministic order, update the current spatial scene identifier of the character instance data to the target scene identifier, and write it into the location history record; The state transition guard module is used to check and update the current state of the migration record based on the set of source states allowed by the target state when the migration record is transferred between the set of states consisting of pending approval, approved, executed and cancelled. The current state of the migration record is checked and updated with a single atomic condition update, and the number of affected records is zero to indicate that the current state does not allow the transfer or that the migration record has been concurrently modified.

Images