Batch triggering method and system for reservation events based on monotone advancement of plot time

Abstract

This invention discloses a method and system for batch triggering scheduled events based on the monotonous progression of story time. It relates to the technical field of server-side event scheduling and real-time data synchronization of online virtual interaction platforms. The method involves the server receiving a time-progression instruction from the management terminal carrying the target story time. Within the time-progression transaction, the story time is embedded into a one-dimensional integer total order space through discrete-time integer mapping, and the global story time is monotonically updated. Within the same time-progression operation sequence, the event scheduling table is scanned with the updated global story time as the upper bound to assemble a set of events to be triggered. This set is actively pushed to the management terminal through a real-time communication channel. Then, based on the batch confirmation instruction, the event state is transformed and the character scene migration operation is performed on each scheduled event record in the set. The time progression and event triggering are reconstructed into a single causal operation sequence, realizing the automatic discovery, active push, and batch confirmation of multiple overdue scheduled events with a single progression.

Description

Technical Field

[0001] This invention relates to the field of server-side event scheduling and real-time data synchronization technology for online virtual interactive platforms, specifically to a method and system for batch triggering scheduled events based on the monotonous progression of storyline time. Background Technology

[0002] In multiplayer online virtual interaction platforms, users establish real-time communication connections with the server through clients, collaboratively advancing the narrative within a virtual story space. Taking an online tabletop role-playing game platform as an example, a typical game session includes a game host and multiple players, each controlling a virtual character to move and interact between multiple virtual scenes constructed by the game host. In such platforms, the progression of virtual story time and the triggering of scheduled events are two fundamental operations for maintaining narrative consistency: the game host advances the story time according to the narrative rhythm, while various scheduled events (such as a character moving to a specific scene at a designated story time) need to be triggered and executed when the story time reaches its scheduled point.

[0003] In existing technologies, the advancement of virtual storyline time typically employs one of three approaches. The first approach is real-time driven, where the virtual world's time is tied to the server's real clock, and events are triggered according to real-time schedules. This approach is suitable for continuously running online worlds in massively multiplayer online role-playing games (MMORPGs), but it cannot meet the needs of scenarios requiring the game master to manually control the narrative pace. The second approach is turn-based time-slicing, where each interactive turn automatically advances a fixed amount of time, and events are settled collectively at the end of the turn. This approach is suitable for strategy games, but lacks flexible narrative control. The third approach is manual event-by-event triggering by the game master, where after advancing the storyline time, the game master checks and triggers each pending event one by one based on memory or external records. This is the most common implementation method currently used on tabletop role-playing platforms.

[0004] At the server-side scheduling level, the most technically similar to the third solution mentioned above is the general scheduled task scanning mechanism. Chinese patent application CN105100259B discloses a distributed scheduled task execution method and system. This system stores the binding relationship between scheduled tasks and execution servers in a database through a task distribution module. A task loading module periodically scans the scheduled task table in the database, loads the scheduled tasks to be executed within that period onto the server, creates the scheduled tasks, and then the task execution module executes the scheduled task and modifies the corresponding task status in the database after execution. However, the task scanning in this solution is driven independently by a fixed-period timer. There is no causal relationship between the scanning action and any external time-progression operation. The tasks detected by the scan are automatically loaded and executed by the server. It neither actively pushes a set of tasks to be triggered to the management end nor supports batch confirmation of multiple tasks expiring at the same time by the management end. Therefore, it cannot solve the core technical problem of the lack of automatic causal relationship between time-progression operations and scheduled event triggering in online virtual story systems.

[0005] Specifically, the fundamental problem with existing technologies lies in treating time progression and event scheduling as two independent operational steps, failing to establish a causal relationship between them at the system architecture level. Time progression only updates a global timestamp variable; the system does not automatically discover and deliver scheduled events that meet the time conditions within the same operation. The acquisition of pending events either relies on the game host's active querying and memorization or on the periodic polling of independent timers. The server lacks the ability to automatically filter and actively push events to be triggered as a whole to the management end for batch confirmation when story time progresses. This decoupling at the architectural level leads to a high risk of missed scheduled events, low operational efficiency, and when multiple scheduled events need to be triggered simultaneously at the same story time point, they can only be manually approved one by one instead of being confirmed in batches with a single click.

[0006] It is particularly important to note that virtual storyline time differs from the continuous flow of a real clock. It is advanced by the game master through discrete jumps of arbitrary magnitude based on narrative needs. A single advancement often does not span a single point in time, but rather sweeps across a time interval, causing multiple events originally scheduled for different times within that interval to simultaneously reach their trigger conditions. Existing event-by-event triggering, periodic polling, or manual querying solutions all process each time point and event individually. This fails to establish an atomic causal relationship between a single storyline time advancement and all due events within the swept interval, and also fails to maintain the original temporal order of these events during batch execution, thus making it difficult to guarantee the temporal integrity of character trajectory data. There is an urgent need in this field for a method and system capable of automatically establishing a causal relationship between time advancement operations and scheduled event triggers within the same time advancement operation sequence. Summary of the Invention

[0007] To address the core technical bottleneck of existing online virtual interactive platforms—the lack of automatic causal correlation between time progression operations and the triggering of scheduled events—this invention provides a method and system for batch triggering scheduled events based on the monotonous progression of story time. By organizing time progression and event scanning within the same time progression operation sequence, and using the monotonous progression of discrete story time as the overall sequence benchmark, the system automatically scans and assembles a set of events to be triggered after each time progression and actively pushes them to the management terminal for batch confirmation. Under the constraint of the game host manually controlling the narrative rhythm, this invention achieves automatic causal driving of time progression operations on the triggering of scheduled events from the principle level of the discrete time overall sequence and the sweeping of single progression intervals.

[0008] The technical solution of this invention is as follows: a batch triggering method for scheduled events based on the monotonous progression of story time, applied to the server side of an online virtual story system with real-time collaboration among multiple users, including the following steps: receiving a time advancement instruction sent by the management terminal, the time advancement instruction carrying the target story time; within the time advancement transaction in the time advancement operation sequence, converting the current global story time and the target story time into story time integer values ​​respectively through discrete time integer mapping, and updating the global story time to the target story time when the story time integer value corresponding to the target story time is not less than the story time integer value corresponding to the current global story time; within the same time advancement operation sequence, scanning the event scheduling table with the updated global story time as the upper time bound, filtering all scheduled event records with the event status as pending trigger and the target trigger story time not later than the upper time bound, and assembling them into a set of events to be triggered; actively pushing the set of events to be triggered to the management terminal through a real-time communication channel; receiving a batch confirmation instruction sent by the management terminal for the set of events to be triggered, performing an event status transition on each scheduled event record in the set of events to be triggered, and performing a character scene migration operation associated with the scheduled event record.

[0009] In a preferred embodiment, before updating the global story time to the target story time, the global story time before the current time advance is recorded as the lower bound of the interval. Reservation event records with an event status of "pending trigger" and whose target trigger story time falls within a half-open time interval starting from the lower bound of the interval and ending at the upper bound of the time are selected from the event scheduling table. These are designated as newly expired event records. The newly expired event records constitute the set of events to be triggered, and the set of events to be triggered is pushed to the management terminal as a single batch confirmation unit. Further, the reservation event records in the set of events to be triggered are arranged in ascending order of the target trigger story time to obtain an ordered trigger sequence. The character scene migration operations associated with each reservation event record are executed sequentially according to the ordered trigger sequence. Further, for each reservation event record in the ordered trigger sequence, its event status is updated to "executed" based on whether its event status is "pending trigger" or "approved." For reservation event records where the atomic update condition is not met, their associated character scene migration operations are skipped.

[0010] In another preferred embodiment, the time-advancement operation sequence is implemented as two successive transactions with causal constraints established by the global story time version number. The batch confirmation instruction carries the expected time version number. An event state transition is performed only when the expected time version number matches the current global story time version number. If they do not match, the current execution is terminated and a time version mismatch prompt is returned to the management terminal. Further, the operation identifier carried in the batch confirmation instruction is used as the primary key to search the idempotent operation registration table. If the search is successful, the registered execution result is returned directly. If the search fails, a new operation registration record is created to record the operation content summary value before execution. Further, each time an event state transition is performed, an audit record is written to the operation audit log table, which only allows appending.

[0011] This invention also provides a method and system for batch triggering scheduled events based on the monotonous progression of story time, applied to the server side of an online virtual story system with real-time collaboration among multiple users. The system includes: a time progression module, used to receive a time progression instruction carrying a target story time sent by the management terminal; within a time progression transaction in the time progression operation sequence, converting the current global story time and the target story time into story time integer values ​​respectively via discrete-time integer mapping; and updating the global story time to the target story time when the story time integer value corresponding to the target story time is not less than the story time integer value corresponding to the current global story time; and an event scanning module, which works in conjunction with the time progression module. The block coupling module is used to scan the event schedule table within the same time advancement operation sequence, using the updated global story time as the upper time bound. It filters all scheduled event records with an event status of pending trigger and a target trigger story time no later than the upper time bound, assembles them into a set of events to be triggered, and actively pushes the set of events to be triggered to the management terminal through a real-time communication channel. The batch execution module, coupled with the event scanning module, is used to receive batch confirmation instructions sent by the management terminal for the set of events to be triggered, perform event status transformation on each scheduled event record in the set of events to be triggered, and perform character scene migration operations associated with the scheduled event record.

[0012] The beneficial effects of this invention are as follows: First, by organizing time progression and event scanning within the same time progression operation sequence, this invention establishes an automatic causal relationship between time progression operations and the triggering of scheduled events. The mechanism is as follows: the scanning action, with the updated global story time as its upper bound, is triggered within the same time progression operation sequence. A single time progression atomically completes the discovery and assembly of the event to be triggered, eliminating the need for the game host to rely on memory or for independent timer periodic polling. Compared to schemes where scanning actions are independently driven by fixed-period timers and have no causal relationship with external time progression, this invention eliminates the decoupling between time progression and event triggering, transforming the discovery of events from reactive querying or periodic polling into instantaneous automatic discovery as time progresses, fundamentally eliminating the risk of missed scheduled events.

[0013] Secondly, by actively pushing the set of events to be triggered as a single batch confirmation unit to the management terminal for batch confirmation, this invention achieves one-click batch triggering of multiple scheduled events at the same plot point. The mechanism is that the set of events to be triggered is a holistic representation of all consequences swept across a time interval during a narrative progression. Pushing and confirming it as a single unit allows the game master to make a single authorization decision on multiple consequences of a narrative progression, rather than approving each event individually. Compared to the scheme in the comparison file where the hit task is automatically executed by the server and lacks a batch confirmation step at the management terminal, this invention retains the narrative authority of the game master while merging multiple approvals into a single batch confirmation. Furthermore, this effect reinforces the first automatic discovery effect: automatic discovery ensures the integrity of the batch unit, and batch confirmation ensures one-time authorization of the complete unit. The operational efficiency improvement resulting from the combination of these two exceeds the simple sum of their individual effects.

[0014] Third, by embedding the three discrete story times into a one-dimensional integer total order space using discrete-time integer mapping, and defining a half-open time interval using the global story times before and after the current advancement, this invention reverses the time interval swept by a single time advancement into a batch discovery window. The mechanism is as follows: after mapping, the discrete story times become a monotonically non-decreasing sequence on a one-dimensional integer total order, causing the comparison across the three parts—that the target trigger story time is no later than the upper time bound—to degenerate into a single integer comparison. The two global story times before and after a single advancement precisely define a half-open interval, and the scheduled events falling into this interval are the new expiring events for this advancement. The elapsed time difference, usually considered useless and discarded, is reversed in this invention to define a batch query window. This principle-level reversal is the basis for the aforementioned automatic discovery and batch confirmation.

[0015] Fourth, by arranging the scheduled event records within the set of events to be triggered into an ordered trigger sequence in ascending order of the target trigger story time and executing them sequentially, and using the event status of "awaiting trigger" or "approved" as the atomic update condition for idempotent state transitions, this invention maintains narrative causality and concurrency safety while performing batch execution. The mechanism is as follows: a single large-scale advancement will collapse events scheduled at different times within a time interval into events expiring simultaneously. If executed out of order without distinction, it will disrupt temporal relationships such as entering a scene first and leaving later, leading to distorted trajectory data. Replaying the events in ascending order of the target trigger story time reconstructs the collapsed temporal order within the batch. Based on this, the idempotent transition using state guards as the atomic update condition ensures that repeated batch confirmation commands for the same set of events to be triggered will not repeatedly migrate records already in the executed state, thus guaranteeing that each event is executed only once in scenarios involving concurrent clicks or repeated submissions after disconnection and reconnection. Ascending replay solves the temporal collapse within a batch, while idempotent guards solve the problem of repeated execution within a batch. Together, they guarantee the determinism of the batch execution result, a determinism that no single feature can provide.

[0016] Fifth, by writing time-stamped messages carrying monotonically increasing message identifiers and migration broadcast messages into the same message stream, and using the monotonically increasing message identifiers as the positioning benchmark for reconnection compensation, while simultaneously filling isolated dwell records in the position history table with the current global story time, which is guaranteed to be no less than any entry story time through monotonically advancing, this invention further ensures message reliability and the integrity of character trajectory data. The mechanism is as follows: the monotonically invariant formula of the global story time and the monotonically increasing nature of the message identifier share the same monotonically structure, allowing time-stamped messages generated for auditing purposes to be reused as anchor points for accurately resending missing message segments during reconnection; similarly, it is precisely this monotonically increasing formula of the global story time that ensures that when writing back the departure story time of isolated dwell records with the current global story time, the written-back value is no earlier than the corresponding entry story time, thus completing the character trajectory without violating the story time sequence constraints. The aforementioned reliability and integrity are all based on the same monotonically property, and together with the aforementioned features, constitute an automated batch triggering closed loop driven by discrete-time monotonically advancing.

[0017] Sixth, by using an optimistic lock established with a global story time version number to constrain the causal relationship between time progression and batch execution between two consecutive transactions, and an idempotent operation registry table with the operation identifier as the primary key to intercept duplicate submissions at the instruction level, and an operation audit log table that only allows append writes to retain all state change trajectories, this invention maintains the determinism and traceability of batch triggering while relaxing the boundaries of a single transaction. Its mechanism is as follows: version number comparison migrates the causal constraint between time progression and batch execution from the transaction boundary to the data version, allowing them to reside in independent transactions without losing causal consistency, thus adapting to the actual deployment scenario where management confirmation time is uncontrollable and long transactions are infeasible; the instruction-level idempotency composed of the operation identifier and the operation content summary value intercepts network retransmissions and repeated clicks on the management end before the batch execution process, forming a two-level idempotency of instruction and record together with the event state guard, and the return result of repeated submissions is completely consistent with the first submission; the append-written audit record makes every state change, including automatic invalidation due to the failure of the scheduled object, traceable afterward. Together with the aforementioned features, these three elements constitute a traceable, replayable, and concurrently secure batch triggering closed loop. Attached Figure Description

[0018] Figure 1 This is a flowchart of the method for batch triggering scheduled events based on the monotonous progression of the plot time in this invention; Figure 2 This is the architecture diagram of the system for automatically triggering batches of appointment events based on the monotonous progression of virtual storyline time, which is based on the present invention. Detailed Implementation

[0019] The present invention 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 for illustrative purposes only and are not intended to limit the scope of the invention.

[0020] The method of this invention is applied to the server side of a multi-user real-time collaborative online virtual story system. This online virtual story system includes a client layer, a communication layer, a server processing layer, and a persistent storage layer. The client layer includes a management terminal and at least one player client. The management terminal is operated by the game host, and the player clients are operated by the players. Each client establishes a long connection with the server through a real-time communication channel. The persistent storage layer stores at least the global story time, an event schedule table, a position history table, and a message stream. In one specific implementation, the real-time communication channel uses a namespace-based WebSocket long connection. The global story time is stored in the global story time field of the campaign table. The event schedule table is implemented as a `scheduled_moves` data table, the position history table is implemented as a `position_history` data table, and the message stream is implemented as a `chat_messages` data table. The following is combined with... Figure 1The steps of each embodiment of the method of the present invention will be described in detail below.

[0021] Step S1: Receive Time Advancement Command. The server receives a time advancement command sent by the management terminal through a real-time communication channel. The time advancement command carries the target story time. In one specific implementation, the time advancement command is implemented as a real-time communication message named gm_advance_time, whose message body carries a target time tag. The target time tag is represented in a combination of hours and minutes, such as 14:00. After receiving the time advancement command, the server parses the target time tag into hour and minute components, and combines it with the day component of the current global story time to construct the target story time.

[0022] It should be noted that the management terminal and player client referred to in this invention can both be physical terminals such as browsers, desktop applications, or mobile applications. The difference lies in the operator's identity and the operating permissions they possess. The management terminal is operated by the game host and has the authority to advance the story timeline and confirm appointment events in batches; the player client is operated by the player and only has the authority to submit appointment events and receive broadcasts. This step only receives time advancement instructions sent by the management terminal; any messages sent by the player client do not trigger subsequent time advancement processes. In a preferred implementation, after receiving the time advancement instruction but before performing discrete-time monotonic advancement calculations, the server first verifies the host's identity and permissions of the management terminal that sent the time advancement instruction, that is, verifies whether the user identity bound to the real-time communication connection is the game host registered for the current battle; if the host's identity and permissions verification is successful, the subsequent steps are executed; otherwise, the time advancement is rejected and a message indicating insufficient permissions is returned to the management terminal. Through pre-verification of identity, the narrative rhythm is prevented from being disrupted by non-host operators advancing the global story timeline.

[0023] Step S2: Perform discrete-time monotonic progression operation. Within the time progression transaction in the time progression operation sequence, the server reads the current global story time from persistent storage, converts the current global story time and the target story time into story time integer values ​​respectively through discrete-time integer mapping, and updates the global story time to the target story time when the story time integer value corresponding to the target story time is not less than the story time integer value corresponding to the current global story time.

[0024] In this embodiment, the story time is represented as a discrete time structure containing a day component, an hour component, and a minute component, where the day component is an integer not less than 0, the hour component is an integer between 0 and 23, and the minute component is an integer between 0 and 59. The discrete time integer mapping maps this three-component structure to an integer value of story time in a one-dimensional integer space, and the mapping relationship is shown in formula (1): (1), in: is an integer value for story time, is a scalar, and its value range is an integer not less than 0. The unit is min. It is calculated by this formula for a given discrete time structure and represents the total number of minutes accumulated from zero point in the story time. It is used to unify the three components of story time into a one-dimensional integer total order space so as to make time sequence comparisons. The day component is a scalar with values ​​ranging from integers not less than 0. Its unit is d, and it is determined by the day field in the story time structure, representing the number of days in the story. The hour component is a scalar with an integer value ranging from 0 to 23, and its unit is h. It is determined by the hour field in the story time structure and represents the number of hours in the story within the same day. The minute component is a scalar with a value ranging from 0 to 59, and its unit is min. It is determined by the minute field in the story time structure and represents the number of minutes in the current hour of the story time. The constant 1440 is the number of minutes in a day, with the unit being min / d. The constant 60 is the number of minutes in an hour, with the unit being min / h.

[0025] Let the integer value of the story time corresponding to the current global story time be... The integer value of the story time corresponding to the target story time is Both are calculated using formula (1) from their respective discrete-time structures. This represents the total number of minutes of the overall story time accumulated from midnight prior to this advancement. This represents the total number of minutes accumulated since midnight, representing the story's progress towards the current objective. (Server-side comparison) and :when Not less than When that time comes, update the global story time to the target story time.

[0026] In a preferred implementation, when Less than When the target story time is earlier than the current global story time, the server rejects the time advance or clamps the global story time to the current global story time, that is, determines the integer value of the story time corresponding to the updated global story time according to formula (2): (2), in: The updated global story time is an integer value corresponding to the story time. It is a scalar, and its value range is an integer not less than 0. The unit is min. It is calculated by this formula and represents the total number of minutes accumulated from 0:00 in the updated global story time. The definition is the same as the value of the target story time in formula (1). The definition is the same as the aforementioned integer value of the story time corresponding to the current global story time; The maximum value operation represents selecting the larger of the two operands. After processing by formula (2), the updated global story time corresponds to the integer value of the story time. The value of the material should not be less than that before this advancement. This ensures that the global story time remains monotonically constant as time progresses at the data structure level, avoiding time rollback due to misoperation and thus preventing the temporal logic of triggered events from becoming disordered.

[0027] At the implementation level, the server executes a time arithmetic function to complete the above calculation: the function receives the base story time and the increment, first expands the base story time and the increment into the total number of minutes according to formula (1) and adds them together. When the sum is less than 0, it is clamped to 0. Then the sum is restored to a discrete time structure by taking the quotient of 1440 for the day component, taking the remainder of 1440 for the hour component and then taking the remainder of 60 for the minute component. This way, the monotonicity and structural validity of the result are maintained while supporting incremental progress.

[0028] It should be noted that the time-advancement operation sequence referred to in this invention refers to a set of server-side operations triggered by the same plot time advance and bound by the same causal constraint. This sequence can be implemented as a single database transaction or as two independent transactions that are sequential in time and whose causal constraint is established by optimistic locking based on version numbers. In the first implementation, the operation of updating the global story time and the operation of scanning the event schedule table are within the same database transaction, and their causal relationship is directly guaranteed by the atomicity of the transaction. In the second implementation, the server maintains a separate global story time version number field in the campaign table: while updating the global story time within its own transaction, the time advancement operation increments the global story time version number by one, and pushes the incremented global story time version number along with the set of events to be triggered to the management end; when the management end sends back the batch confirmation command, it carries this version number as the expected time version number. Within the transaction executing the batch confirmation, the server first compares the expected time version number with the current global story time version number. If they match, the subsequent event state transition and character scene migration operations are executed. If they do not match, it indicates that a new time advancement has occurred between the push and the confirmation, or that concurrent batch execution has already been completed. The server terminates the current execution and returns a time version mismatch prompt to the management end, which then reconfirms based on the newly pushed set of events to be triggered. The reason for adopting the second implementation is that the batch confirmation process requires manual decision-making by the game host, and its time consumption is uncontrollable. If the scanning and execution are forcibly wrapped in a single long transaction, it will occupy the database connection and row-level lock for a long time. However, the optimistic lock, which uses the global story time version number as the carrier, moves the causal constraint from the transaction boundary to the data version. This ensures that even when the scanning and execution are in two independent transactions, the set of events to be triggered can still be guaranteed to be generated by the time progress of that transaction, achieving the same technical effect as the single transaction implementation.

[0029] Step S3: Insert a timestamp audit record. When the server updates the global story time to the target story time, it inserts a timestamp message into the message stream. This timestamp message carries a globally unique and monotonically increasing message identifier and the updated global story time. In one specific implementation, the message identifier is generated using the snowflake algorithm, and its value is formed by concatenating the high-order bits of the timestamp, the machine identifier, and the low-order bits of the sequence number, thus ensuring global uniqueness and monotonically increasing order of generation in a distributed deployment. The type field of the timestamp message is marked as a timestamp type, its content field is the timestamp corresponding to the updated global story time, and its time field is the updated global story time.

[0030] The time-stamped messages serve two purposes: firstly, as immutable audit records of time progression, ensuring a traceable record of each plot advancement in the message stream; secondly, because these time-stamped messages share the same message stream and carry monotonically increasing message identifiers within the same system, they are also reused as message compensation anchors during reconnection. Specifically, the management terminal or player client locally records the maximum message identifier it has received. When a disconnection occurs and the connection is reconnected, this maximum message identifier is reported to the server. The server then retrieves and resends time-stamped messages and reconnection broadcast messages with message identifiers greater than this maximum message identifier from the message stream, thus accurately filling in missing message segments without duplicating already received messages. The reuse of time-stamped messages, originally used for auditing, as a positioning benchmark for reconnection compensation leverages the monotonic structure shared by the monotonic invariance of global story time and the monotonically increasing nature of message identifiers.

[0031] Step S4: Scan for scheduled events that meet the time conditions. Within the same time-progressing operation sequence, the server scans the event scheduling table with the updated global story time as the upper time bound, filters all scheduled event records whose event status is pending triggering and whose target triggering story time is not later than the upper time bound, and assembles them into a set of events to be triggered.

[0032] In this embodiment, the event scheduling table stores several scheduled event records. Each scheduled event record includes at least an event identifier, a character identifier, a campaign identifier, a target scene identifier, a target trigger story time, and an event status. The target trigger story time is a discrete-time structure isomorphic to the global story time, representing the story time at which the scheduled event is triggered. The event status is taken from four values: pending trigger, approved, executed, and canceled. The event scheduling table is scanned according to formula (3) to determine the set of events to be triggered: (3), in: The set of events to be triggered is a set of scheduled event records, the number of which is an integer not less than 0. It is obtained by filtering by this formula and represents all scheduled event records that meet the time conditions after this advancement but have not yet been triggered. It is a set of all scheduled event records under the current campaign in the event scheduling table, and it is a set composed of scheduled event records; For set A single appointment event record in the collection is a collection element; Record appointment events The event status can be set to include: pending, approved, executed, and cancelled. Record appointment events The target trigger story time corresponds to the integer value of the story time, which is a scalar in minutes, and is determined by formula (1). The target trigger time is calculated, representing the total number of minutes accumulated since midnight when the scheduled event is triggered. The definition is the same as in formula (2), where represents the integer value of the story time corresponding to the updated global story time, in minutes; symbol This represents the logical AND operation, which requires both conditions on its left and right sides to be true simultaneously; the symbol... Indicates that an element belongs to a set; symbol This indicates that elements satisfying the subsequent condition are selected into the set; symbol It means not greater than.

[0033] In one specific implementation, the event schedule table is scanned using a structured query statement. The query conditions are: the campaign identifier equals the current campaign, the event status equals pending trigger, and the target trigger story time is not later than the updated global story time. The query is then sorted in ascending order by the target trigger story time. Since the target trigger story time is stored in a discrete time structure, the comparison operation is performed by converting it to an integer story time value according to formula (1) and then comparing it with the integer story time value corresponding to the updated global story time. The scan of the event schedule table is executed within the server-side time advancement operation sequence. That is, the scanning action and the action of updating the global story time are bound within the same time advancement operation sequence. They are either in the same database transaction or in two consecutive transactions with causal constraints established by optimistic locking of the global story time version number. This establishes an automatic causal relationship between the time advancement operation and the scheduled event trigger, rather than relying on the client's active query or the periodic polling of an independent timer.

[0034] In a preferred implementation, before updating the global story time to the target story time, the server first records the global story time before the current time advance as the lower bound of the interval, and narrows the scanning condition to ensure that the target trigger story time falls within a half-open time interval starting from the lower bound of the interval and ending from the upper bound of the time interval. That is, the newly due event records are determined according to formula (4) and constitute the set of events to be triggered. (4), in: , , , , , The definitions are the same as in formula (3); is the integer value of the story time corresponding to the lower bound of the interval, is a scalar, and its value range is an integer not less than 0. The unit is min, which is calculated by formula (1) for the global story time before this time advance, and represents the total number of minutes of global story time accumulated from 0:00 before this advance; symbol This indicates less than, meaning the half-open time interval is less than. For the beginning without endpoints, The end includes the endpoint. The reservation event records obtained by filtering by formula (4) are the new overdue event records for this advancement. The set of events to be triggered, which consists of the new overdue event records, corresponds exactly to the time interval swept by a single time advancement. Thus, the usually discarded elapsed time difference is reversed into a query window that defines the batch, making the set of events to be triggered a holistic representation of all the new overdue consequences of a narrative advancement, i.e., a single batch confirmation unit.

[0035] Let's illustrate this step with a specific numerical example: Assume the global story time before this advancement is an integer value representing the story time. The value is 480, which corresponds to 8:00 AM on day 0; this is the integer value of the target story time for this advancement. The value is 2280, which corresponds to 14:00 on day 1. There are three scheduled event records to be triggered in the event scheduling table. The target trigger time corresponding to the story time integer values ​​are 630, 2280 and 2400, which correspond to 10:30 on day 0, 14:00 on day 1 and 16:00 on day 1, respectively. According to formula (4), the two scheduled event records with story time integer values ​​of 630 and 2280 fall within the half-open time interval starting at 480 without endpoints and ending at 2280 with endpoints, and are selected into the set of events to be triggered; the scheduled event record with story time integer value of 2400 is not selected because it exceeds the upper time limit. Thus, by advancing the time from 480 to 2280, two events scheduled within this interval are discovered at once, without the game host having to query once at each of the two time points of 10:30 and 14:00.

[0036] Step S5: Push the list of events to be triggered. The server assembles the set of events to be triggered obtained in Step S4 into structured data and actively pushes it to the management terminal through a real-time communication channel. In one specific implementation, each record in the pushed structured data includes an event identifier, a character name, a target scene name, and a target trigger story time. After receiving the push, the management terminal renders the set of events to be triggered into a list awaiting approval in the management panel.

[0037] The key to this step lies in proactive push, meaning the server actively sends the set of events to be triggered to the management end after completing the scan, rather than the management end initiating a query request. In this way, the game host can perceive all the events to be triggered at the current time without actively refreshing or querying after advancing the storyline; scheduled events that have met the time conditions will not remain in a silent waiting state simply because the game host has not actively queried them. Because the set of events to be triggered is pushed as a single batch confirmation unit, the management end can perform batch confirmation on it all at once, rather than obtaining and approving each event individually.

[0038] Step S6: Receive and execute batch confirmation instructions. The server receives the batch confirmation instructions sent by the management terminal for the set of events to be triggered, performs event state transitions on each appointment event record in the set of events to be triggered, and performs role scene migration operations associated with the appointment event records. In one specific implementation, the management terminal provides two operations: approval and full approval. The full approval operation collects all event identifiers in the set of events to be triggered and sends a batch confirmation instruction carrying the batch of event identifiers to the server.

[0039] During execution, the server first arranges the scheduled event records in the set of events to be triggered in ascending order of the target trigger story time, obtaining an ordered trigger sequence. Then, it executes the character scene migration operations associated with each scheduled event record sequentially according to this ordered trigger sequence. The reason for executing in ascending order of the target trigger story time is that a single large-scale time advance will collapse multiple events scheduled at different times within a half-open time interval into events expiring simultaneously after this advance. If executed indiscriminately in any order, situations may occur, such as a character leaving the scene before entering, disrupting the temporal order of character movement and causing trajectory data corruption. Replaying in ascending order of the target trigger story time reconstructs the temporal order collapsed by this advance within the batch execution, ensuring that character movements within the interval occur sequentially according to their original story time order.

[0040] Secondly, for each reservation event record within the ordered trigger sequence, the server updates the event status of the reservation event record to "executed" based on the atomic update condition that the event status is either "pending trigger" or "approved." For reservation event records where the atomic update condition is not met—that is, records whose event status is already "executed" or "cancelled"—the associated role / scene migration operation is skipped. In one specific implementation, the event status transition is achieved through a conditional structured update statement. The update condition is limited to the event identifier being equal to the target record and the event status being either "pending trigger" or "approved." Utilizing the atomicity of a single update statement in the database, it is ensured that when multiple batch confirmation commands arrive concurrently or when duplicate batch confirmation commands arrive due to disconnection and reconnection, only one update can change a reservation event record from the "pending trigger" or "approved" state to the "executed" state. The remaining duplicate updates have no effect because the condition is no longer met, and the corresponding role / scene migration operation is skipped. Thus, for the same set of pending events, duplicate batch confirmation commands do not generate duplicate role / scene migration operations for reservation event records already in the "executed" state, ensuring that each reservation event is executed only once.

[0041] In a further specific implementation, in addition to the idempotency guarded by the event state mentioned above, the server sets up an idempotent operation registry to intercept duplicate submissions at the instruction level. Each time the management terminal sends a batch confirmation instruction, it generates a globally unique operation identifier for the instruction and sends it along with the instruction. After receiving the batch confirmation instruction, the server first calculates the operation content digest value according to a digest algorithm. In this embodiment, the digest algorithm uses the SHA-256 secure hash algorithm, which outputs a 256-bit digest value for instruction content of any length. The server then searches the idempotent operation registry using the operation identifier as the primary key: if the search is successful, it means that the instruction has already been accepted, and the server does not repeat the event state transition and role scene migration operations, but directly returns the execution result cached in the operation registry record; if the search fails, the server creates a new operation registry record in the idempotent operation registry with the operation identifier as the primary key, recording the operation content digest value and the acceptance time, then executes the subsequent batch execution process, and writes the execution result back to the operation registry record after execution is completed. The purpose of the operation content summary value is to verify whether the instruction content is also the same when the operation identifiers are the same: if the operation identifiers are the same but the operation content summary values ​​are different, it is determined that the operation identifier reuse is abnormal and the execution is rejected. Compared with the aforementioned idempotency guarded by event state, the idempotency operation registration table improves the idempotency granularity from a single reservation event record to the entire batch confirmation instruction, so that duplicate submissions caused by network retransmission, repeated clicks on the management terminal, or disconnection and reconnection are intercepted before entering the batch execution process, and the returned result of the duplicate submission is completely consistent with the first submission.

[0042] Furthermore, before executing the role-scene migration operation one by one according to the ordered trigger sequence, the server performs a conflict determination on each reservation event record to handle the situation where the object it depends on has become invalid after the reservation is established. The conflict determination includes two parts: First, reading the activation status of the target scene pointed to by the reservation event record. When the target scene deactivation flag is in effect, it is determined that the target scene has been deactivated, and the migration destination required by this reservation event no longer exists. The server updates the event status of the reservation event record to "cancelled" and records the reason for invalidation as "target scene deactivation", skipping its associated role-scene migration operation. Second, reading the activation status of the role instance pointed to by the reservation event record. When the role instance deactivation flag is in effect, it is determined that the role instance has been deactivated, and the migration subject required by this reservation event no longer exists. The server also updates the event status of the reservation event record to "cancelled" and records the reason for invalidation as "role instance deactivation", skipping its associated role-scene migration operation. Reservation event records that are automatically invalidated by the above conflict determination will no longer enter the subsequent migration execution and broadcast process, and the other reservation event records in the same batch will not be affected. Therefore, a batch execution will not fail as a whole due to the failure of objects on which individual appointment events within the batch depend, and it also avoids the creation of dangling data by writing participation records to deactivated scenarios or location history records to deactivated role instances.

[0043] Next, for each successfully executed appointment event record, the server executes its associated character scene migration operation. This operation includes: ending the migration character's old scene stay record in the location history table and writing the departure story time; updating the current scene identifier in the migration character's runtime state; creating a new scene participation record and location history record and writing the entry story time. After execution, the server writes the execution results of each character scene migration operation as migration broadcast messages into the message stream. Each migration broadcast message carries its own monotonically increasing message identifier and is broadcast to all online clients via a real-time communication channel, along with location change messages and system transition messages, enabling all player clients and the management terminal to synchronously perceive the character's scene migration.

[0044] In one specific implementation, the server synchronously writes an audit record to the operation audit log table each time the above-mentioned event state transition is executed. The audit record includes the event identifier, the event state before the change, the event state after the change, the operator identifier, the operation type, and the global story time at the time of the change. The operation audit log table only allows appending; updating or deleting existing audit records is not permitted, thus completely preserving the state change trajectory of all scheduled events. The operation audit log table complements the time-stamped messages written to the message stream in step S3: the time-stamped messages are client-facing and used for narrative presentation and message compensation during disconnection and reconnection; the audit records are server-facing and used to retrospectively trace the complete state change path of any scheduled event from pending triggering through approval to execution or cancellation, including cases where events are automatically invalidated due to the target scene or character instance being deactivated, thereby providing a basis for dispute review and fault location.

[0045] Step S7: Location History Data Repair. The server scans the location history table for isolated stay records where the departure story time is empty, i.e., cases where the character has left the old scene but the departure story time has not been written. The server then writes back the departure story time of the isolated stay record using the current global story time.

[0046] The reason for isolated dwell records is that characters may enter or leave a scene through various means such as joining, scheduled migration, or forced migration. During a scheduled migration, the character's dwell record in the previous scene might not be closed synchronously when updating the character's current scene, leaving a dwell record with an empty departure story time. This step writes back the departure story time using the current global story time. Its correctness is guaranteed by the monotonic invariance of the global story time: since the global story time is guaranteed to monotonically not decrease with time through the monotonic progression operation in step S2, the integer value of the story time corresponding to the current global story time is never less than the integer value of the story time corresponding to any previously written entry story time in the position history table. Therefore, the departure story time obtained by writing back the current global story time will not be earlier than the corresponding entry story time. This completes the character trajectory data without violating the sequential constraint that the entry story time is earlier than the departure story time within the same dwell record, ensuring the temporal integrity of the trajectory data. In one specific implementation, this step periodically scans and writes back using a scheduled task, or triggers a scan and write back after each batch execution.

[0047] In one specific implementation, the main data structures involved in this invention are defined as follows. The global story time is represented by a story time structure, which includes a day field, an hour field, and a minute field, wherein the day field is an integer not less than 0, the hour field is an integer between 0 and 23, and the minute field is an integer between 0 and 59.

[0048] The reservation event record is represented by a reservation event structure, which includes an event identifier field, a character identifier field, a campaign identifier field, a target scene identifier field, a target trigger story time field, an event status field, and a creation time field. The event identifier field is a globally unique identifier, the target trigger story time field is a story time structure or a null value, and the event status field takes four values: pending trigger, approved, executed, and canceled.

[0049] The location history record is represented by a location history structure, which includes a record identifier field, a campaign identifier field, a character identifier field, a scene identifier field, an entry story time field, an exit story time field, and a migration type field. The entry story time field and the exit story time field are either story time structures or null values. The migration type field takes three values: join, scheduled migration, and forced migration.

[0050] Time-stamped messages and migration broadcast messages are represented using a message structure, which includes a message identifier field, a message type field, a content field, and a time field. The message identifier field is a globally unique and monotonically increasing identifier. The message type field is used to distinguish between time-stamped messages and migration broadcast messages. The time field is the global story time associated with the message.

[0051] Operation registration records are represented using an idempotent operation structure. This structure includes fields for operation identifier, campaign identifier, operation type, operation content digest value, execution result, and acceptance time. The operation identifier is a globally unique identifier and serves as the primary key. The operation content digest value is a 256-bit digest of the instruction content calculated using the SHA-256 secure hash algorithm. The execution result field caches the return result of the first execution for direct return during subsequent submissions. Audit records are represented using an audit log structure. This structure includes fields for audit record identifier, event identifier, pre-change event status, post-change event status, operator identifier, operation type, and global story time at the time of change. The pre-change and post-change event status fields are both derived from "pending trigger," "approved," "executed," and "cancelled." The operation type field distinguishes between batch confirmation, single approval, automatic cancellation, and manual cancellation.

[0052] The technical solution of the present invention can also be implemented by the following alternative methods, achieving essentially the same technical effect.

[0053] Alternative solution one is event triggering based on the publish-subscribe pattern: the time advance operation is published to the internal message bus as an event source, and the event scanning logic is used as a subscriber to asynchronously consume time change events and perform scanning. The difference from the previous embodiment is that the scanning operation is executed asynchronously outside the time advance transaction, which is suitable for high concurrency scenarios, but correspondingly sacrifices the real-time consistency between scanning and advance.

[0054] Alternative solution two is to replace server-side push with client-side polling: the management terminal queries the server for the set of events to be triggered at fixed intervals, replacing the server-side proactive push in step S5. This alternative method is relatively simple to implement, but its real-time performance is relatively poor and it increases the query pressure on the server.

[0055] Alternative solution three is timed triggering based on a priority queue: the scheduled events are sorted according to the target trigger story time and inserted into the priority queue. As time progresses, the element at the head of the queue is checked to see if it meets the triggering conditions. This alternative is suitable for high-performance scenarios with a large number of scheduled events, but its implementation complexity is relatively high.

[0056] Alternative solution four is to add an automatic time progression mode: In addition to manual progression by the game host, an automatic progression mode is added, in which the system automatically advances one discrete time unit after a fixed interval in real time and automatically triggers scheduled events that meet the conditions, without the need for game host intervention. This is suitable for automated narrative testing or demonstration scenarios.

[0057] like Figure 2 As shown, this invention also provides a method and system for batch triggering scheduled events based on the monotonous progression of the storyline time. This system is applied to the server side of an online virtual storyline system with real-time collaboration among multiple users. The system includes a time progression module 1, an event scanning module 2, and a batch execution module 3. Each module is connected to the client layer via a communication gateway and reads and writes the global story time, event scheduling table, location history table, and message stream via a persistent storage layer. The functions of each module and their coupling relationships are described below.

[0058] The time advancement module 1 receives a time advancement instruction carrying a target story time from the management terminal. Within the time advancement transaction in the time advancement operation sequence, it converts the current global story time and the target story time into story time integer values ​​through discrete-time integer mapping. When the story time integer value corresponding to the target story time is not less than the story time integer value corresponding to the current global story time, it updates the global story time to the target story time. The time advancement module 1 corresponds to steps S1 and S2 in the method embodiment. Its specific implementation of receiving the time advancement instruction, verifying the host's identity and permissions, performing discrete-time monotonic advancement operations, and updating the global story time is consistent with the corresponding descriptions of steps S1 and S2 in the method embodiment, and will not be repeated here. In a preferred implementation, the time advancement module 1 also inserts a time-stamped message carrying a monotonically increasing message identifier into the message stream while updating the global story time, i.e., it performs the function of step S3 in the method embodiment.

[0059] Event scanning module 2, coupled with time advancement module 1, is used to scan the event schedule table within the same time advancement operation sequence, using the updated global story time as the upper time bound. It filters all scheduled event records whose event status is pending triggering and whose target triggering story time is not later than the upper time bound, assembles them into a set of events to be triggered, and actively pushes the set of events to be triggered to the management terminal through a real-time communication channel. Event scanning module 2 corresponds to steps S4 and S5 in the method embodiment. The coupling relationship between event scanning module 2 and time advancement module 1 is reflected in the following: the updated global story time of time advancement module 1 serves as the upper time bound input for event scanning module 2 to perform scanning, that is, the output of time advancement module 1 directly serves as the key input of event scanning module 2. The two are bound within the same time advancement operation sequence, thereby establishing an automatic causal relationship between time advancement and event scanning. Event scanning module 2 determines the set of events to be triggered and assembles it into structured data to be actively pushed to the management terminal in the manner described in formula (3) or formula (4) in the method embodiment. Its specific implementation method is consistent with the corresponding descriptions of steps S4 and S5 in the method embodiment.

[0060] Batch execution module 3, coupled with event scanning module 2, is used to receive batch confirmation instructions sent by the management terminal for the set of events to be triggered, perform event state transitions on each scheduled event record in the set of events to be triggered, and perform role scene migration operations associated with the scheduled event records. Batch execution module 3 corresponds to steps S6 and S7 in the method embodiment. The coupling relationship between batch execution module 3 and event scanning module 2 is reflected in the following: the set of events to be triggered pushed by event scanning module 2 and confirmed by the management terminal serves as the input for batch execution module 3 to perform batch state transitions and role scene migrations; that is, the output of event scanning module 2, after being batch confirmed by the management terminal, serves as the key input of batch execution module 3. As described in the method embodiment, batch execution module 3 first arranges the set of events to be triggered into an ordered trigger sequence to reconstruct the time sequence of the pushed-down collapse, then performs idempotent state transitions based on the event state being either pending triggering or approved as atomic update conditions, and finally performs role scene migration operations and writes the execution result as a migration broadcast message into the message stream. Its specific implementation is consistent with the corresponding descriptions of steps S6 and S7 in the method embodiment.

[0061] Furthermore, the time advancement module 1, event scanning module 2, and batch execution module 3 of the system described in this invention form a deeply coupled closed-loop collaborative relationship. On one hand, the output global story time of the time advancement module 1 serves as the upper time bound input of the event scanning module 2, and the output set of events to be triggered from the event scanning module 2, after batch confirmation, serves as the processing object input of the batch execution module 3. The three modules are coupled sequentially along the time advancement operation sequence, forming a coupling chain in which the output of the previous module serves as the key input of the next module. On the other hand, after the batch execution module 3 performs the character scene migration operation, it writes the entry and exit story times to the location history table. Simultaneously, when scanning isolated dwell records, it writes back the exit story time using the current global story time maintained by the time advancement module 1. This means the execution result of the batch execution module 3 is inversely dependent on the global story time maintained by the time advancement module 1, thus forming a feedback relationship between the batch execution module 3 and the time advancement module 1 where the subsequent module inversely depends on the state maintained by the preceding module. Simultaneously, the migration broadcast messages written to the message stream by the batch execution module 3 and the time tag messages written to the message stream by the time advancement module 1 share the same monotonically increasing message identifier, providing compensation for the management end and player client during reconnection. This coupling and feedback relationship enables the system to automatically complete the entire closed-loop process of event discovery, batch push, batch confirmation, batch execution, and data repair under the drive of a single time advancement. The automated batch triggering capability generated by the collaboration of each module exceeds the simple summation of the independent functions of each module.

[0062] It should be noted that the above module division is only an exemplary functional division. In other embodiments, the functions of each module can be further split or merged. For example, the function of inserting time tag messages in the time advancement module 1 can be split into an independent audit module, or the push function of the event scanning module 2 and the broadcast function of the batch execution module 3 can be merged into a unified communication module. Such changes are all within the protection scope of this invention. The modules of the system described in this invention can be implemented by software programs running on the server, or by dedicated hardware circuits or a combination of hardware and software. This invention does not limit this.

[0063] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for batch triggering scheduled events based on the monotonous progression of the storyline, applied to the server side of an online virtual storyline system with real-time collaboration among multiple users, characterized in that... include: Receive a time advance instruction sent by the management terminal, the time advance instruction carrying the target story time; Within the time-advancement transaction in the time-advancement operation sequence, the current global story time and the target story time are respectively converted into story time integer values ​​through discrete time integer mapping, and when the story time integer value corresponding to the target story time is not less than the story time integer value corresponding to the current global story time, the global story time is updated to the target story time; Within the same time-advancement operation sequence, the event scheduling table is scanned with the updated global story time as the upper bound of time. All scheduled event records with an event status of pending triggering and a target triggering story time no later than the upper bound of time are selected and assembled into a set of events to be triggered. The set of events to be triggered is actively pushed to the management terminal through a real-time communication channel; The system receives a batch confirmation instruction sent by the management terminal for the set of events to be triggered, performs an event state transition for each scheduled event record in the set of events to be triggered, and performs a role scene migration operation associated with the scheduled event record.

2. The method for batch triggering of appointment events based on the monotonous progression of plot time as described in claim 1, characterized in that, Before updating the global story time to the target story time, the global story time before this time advancement is recorded as the lower bound of the interval; the scanning event scheduling table includes: selecting scheduled event records from the event scheduling table whose event status is pending triggering and whose target triggering story time falls within a half-open time interval starting from the lower bound of the interval and ending from the upper bound of the time, as new overdue event records, the new overdue event records constitute the set of events to be triggered, and the set of events to be triggered is pushed to the management terminal as a single batch confirmation unit.

3. The method for batch triggering of appointment events based on the monotonous progression of plot time as described in claim 2, characterized in that, The execution of the character scene migration operation associated with the scheduled event record includes: arranging each scheduled event record in the set of events to be triggered in order from earliest to latest according to the target trigger story time, to obtain an ordered trigger sequence; and executing the character scene migration operation associated with each scheduled event record in sequence according to the ordered trigger sequence.

4. The method for batch triggering of appointment events based on the monotonous progression of plot time as described in claim 3, characterized in that, The event status of the reservation event record is taken from pending trigger, approved, executed, and canceled; the execution event status transition includes: for each reservation event record in the ordered trigger sequence, with its event status being pending trigger or approved as the atomic update condition, the event status of the reservation event record is updated to executed; for reservation event records where the atomic update condition is not met, the associated role scene migration operation is skipped.

5. The method for batch triggering of appointment events based on the monotonous progression of plot time as described in claim 4, characterized in that, When updating the global story time to the target story time, a timestamp message is inserted into the message stream. The timestamp message carries a globally unique and monotonically increasing message identifier and the updated global story time. The execution results of each character scene migration operation are written into the message stream as migration broadcast messages, and each migration broadcast message carries its own monotonically increasing message identifier; when the management terminal or player client disconnects and reconnects, based on the maximum message identifier it has received, a time tag message with a message identifier greater than the maximum message identifier and a migration broadcast message are retrieved from the message stream and resent.

6. The method for batch triggering of scheduled events based on the monotonous progression of plot time as described in claim 5, characterized in that, The character scene migration operation includes: ending the old scene stay record for the migrating character in the location history table and writing the departure story time; creating a new scene participation record and writing the entry story time; scanning the isolated stay records in the location history table where the departure story time is empty, and writing back the departure story time of the isolated stay record with the current global story time.

7. The method for batch triggering of scheduled events based on the monotonous progression of plot time as described in claim 1, characterized in that, In the step of updating the global story time to the target story time, if the story time integer value corresponding to the target story time is less than the story time integer value corresponding to the current global story time, the current time advance is rejected, or the global story time is clamped to the current global story time.

8. The method for batch triggering of appointment events based on the monotonous progression of plot time as described in claim 1, characterized in that, After receiving the time advance instruction and before updating the global story time to the target story time, the host's identity and permissions of the management terminal that sent the time advance instruction are verified. If the host's identity and permissions are verified, the subsequent steps are executed; otherwise, the time advance is rejected. The discrete time integer mapping is as follows: the story time is represented as a discrete time structure containing a day component, an hour component, and a minute component. The story time integer value is equal to the day component multiplied by 1440, plus the hour component multiplied by 60, plus the minute component.

9. The method for batch triggering scheduled events based on the monotonous progression of plot time as described in claim 1, characterized in that, The time-advancement operation sequence includes a time-advancement transaction and a batch execution transaction. Within the time-advancement transaction, while updating the global story time to the target story time, the global story time version number is incremented. The incremented global story time version number is pushed to the management terminal along with the set of events to be triggered. The batch confirmation instruction carries the expected time version number. Before executing the event state transition within the batch execution transaction, the expected time version number is compared with the current global story time version number. If they match, the event state transition and the character / scene migration operation are executed; if they do not match, the current execution is terminated, and a time version mismatch is returned to the management terminal. Note: The batch confirmation instruction carries an operation identifier. Before executing the event state transition, the operation content summary value is calculated based on the instruction content of the batch confirmation instruction using a digest algorithm, and the operation identifier is used as the primary key to search the idempotent operation registration table. If the search is successful, the execution result registered in the idempotent operation registration table is returned, and the event state transition and role scene migration operation are skipped. If the search is unsuccessful, an operation registration record is created in the idempotent operation registration table with the operation identifier as the primary key and the operation content summary value recorded. The event state transition and role scene migration operation are executed, and the execution result is written back to the operation registration record. Each time the event state transition is executed, an audit record is written to the operation audit log table. The audit record includes the event identifier, the event state before the change, the event state after the change, the operator identifier, the operation type, and the global story time at the time of the change. Only append-only writes are allowed to the audit records in the operation audit log table.

10. A batch automatic triggering system for scheduled events based on the monotonous progression of virtual storyline time, applied to the server side of an online virtual storyline system with real-time collaboration among multiple users, characterized in that... include: The time advancement module is used to receive the time advancement instruction carrying the target story time sent by the management terminal, and within the time advancement transaction in the time advancement operation sequence, convert the current global story time and the target story time into story time integer values ​​respectively through discrete time integer mapping, and update the global story time to the target story time when the story time integer value corresponding to the target story time is not less than the story time integer value corresponding to the current global story time. The event scanning module, coupled with the time advancement module, is used to scan the event scheduling table within the same time advancement operation sequence with the updated global story time as the upper time bound, filter all scheduled event records with the event status as pending trigger and the target trigger story time not later than the upper time bound, assemble them into a set of events to be triggered, and actively push the set of events to be triggered to the management terminal through a real-time communication channel. The batch execution module, coupled with the event scanning module, is used to receive the batch confirmation instruction sent by the management terminal for the set of events to be triggered, perform event state transformation on each scheduled event record in the set of events to be triggered, and perform role scene migration operation associated with the scheduled event record.

Images