Scene passing control method and device, equipment and medium

By using a unified framework of scene access mechanism template classes and business logic modules, the problems of code redundancy and inconsistent interaction in scene access mechanisms in large-scale video games are solved, achieving efficient development and a consistent player experience.

CN121623326APending Publication Date: 2026-03-10GUANGZHOU KULUO SHUJIE TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-12-25
Publication Date
2026-03-10

AI Technical Summary

Technical Problem

In traditional large-scale video games, the independent development of scene access mechanisms leads to code redundancy, high maintenance costs, poor design flexibility, and inconsistent player interaction experience.

Method used

It adopts a unified framework of scene-based mechanism template classes and business logic modules. By listening to the player's position, mechanisms are generated in real time. The mechanism configuration data is instantiated and bound to the business logic to achieve unified visual and control logic processing.

Benefits of technology

It reduced redundant development work, increased the speed of game content expansion and design freedom, optimized game performance, and ensured the consistency and immersion of the player's interactive experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121623326A_ABST
    Figure CN121623326A_ABST
Patent Text Reader

Abstract

The invention relates to a scene passing control method and device, equipment and a medium. The method comprises the following steps: monitoring a real-time position of activity generation of a player character in a game scene; when the real-time position reaches a mechanism loading area for the first time, invoking mechanism configuration data predefined in the area to instantiate a mechanism template class to obtain a scene fast arrival mechanism, and binding corresponding business logic by the scene fast arrival mechanism corresponding to a mechanism type in the mechanism configuration data; when the real-time position enters an entrance response area set by a scene speed arrival mechanism, running first control logic in the business logic to generate a visual prompt effect; and operating a second control logic in the business logic to correspond to the scene fast arrival mechanism, and controlling the player character to execute the visual performance of the passing process. According to the method, the unified framework and data driving are provided for various passing paths in the game scene, so that the development efficiency, the runtime performance and the game design flexibility are remarkably improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of game interaction technology, and in particular to a scene passage control method, device, equipment, and medium thereof. Background Technology

[0002] In large-scale video games, especially open-world or large-scale games, providing players with efficient, fun, and context-appropriate means of fast movement is crucial for enhancing the gaming experience and freedom of exploration. Traditional techniques typically rely on pre-placed, single-function, and fixed interaction points or teleportation devices within the game world to create access mechanisms. For example, ziplines or swing points can be deployed independently for walking characters, while acceleration tracks or special surfaces can be deployed in specific areas for vehicles. Implementing these techniques often requires developing a complete technical implementation for each specific mode of movement. From a software engineering perspective, this means maintaining multiple functionally similar but completely separate modules within the game, each requiring independent handling of its triggering conditions, movement logic, online synchronization, and state management.

[0003] This approach, based on independent development of functions, reveals significant technical problems as game content becomes more complex. First, it leads to severe code redundancy and escalating maintenance costs. Many fast-moving mechanisms share common underlying logic, such as requiring triggering based on player position, moving along a predetermined path, and managing process states. However, independent implementations necessitate repeatedly writing and debugging this common logic across different codebases. When optimizing path-following algorithms or unifying online interaction rules, developers must perform repetitive work across multiple scattered modules, easily resulting in errors and inconsistencies. Second, this technical architecture limits the flexibility and iteration efficiency of game design. If designers want to add a new mode of passage or adjust parameters of existing modes, programmers often need to start from scratch or deeply modify specific functional modules, making it impossible to quickly respond to design requirements. Consequently, passage mechanisms in the game world become discrete, hard-coded functional silos, hindering rapid functional expansion, unified performance optimization, and a consistent worldview.

[0004] Therefore, there is an urgent need in this field for a technical solution that can fundamentally unify the management of access mechanisms in diverse scenarios and achieve efficient reuse of resources and logic. Summary of the Invention

[0005] The purpose of this application is to solve the above-mentioned problems by providing a scene access control method and corresponding devices, equipment, non-volatile readable storage media, and computer program products.

[0006] According to one aspect of this application, a scene access control method is provided, comprising: Monitor the real-time location generated by the player character's activities in the game scene; When the real-time location first reaches the mechanism loading area in the game scene, the mechanism template class is instantiated by calling the predefined mechanism configuration data of the area to obtain the scene quick-access mechanism. The scene quick-access mechanism is bound to the corresponding business logic according to the mechanism type in the mechanism configuration data. When the real-time location enters the entrance response area set by the scene speed-up mechanism that has been loaded into the game scene, the first control logic in the business logic is executed to generate a visual prompt effect in the entrance response area. In response to the interactive execution event triggered by the player, the second control logic in the business logic is run to control the visual performance of the player character in the passage process corresponding to the scene's quick access mechanism.

[0007] According to another aspect of this application, a scene access control device is provided, comprising: The location monitoring module is configured to monitor the real-time location generated by the player character's activities in the game scene; The mechanism implementation module is configured to, when the real-time location first arrives at the mechanism loading area in the game scene, call the predefined mechanism configuration data of that area to instantiate a mechanism template class to obtain a scene quick-access mechanism. The scene quick-access mechanism is bound to the corresponding business logic according to the mechanism type in the mechanism configuration data. The entry display module is configured to run the first control logic in the business logic when the real-time location enters the entry response area set by the scene speed-up mechanism loaded into the game scene, so as to generate a visual prompt effect in the entry response area. The passage performance module is configured to respond to interactive execution events triggered by the player, run the second control logic in the business logic, and control the visual performance of the player character's passage process in accordance with the scene's quick access mechanism.

[0008] According to another aspect of this application, an electronic device is provided, including a central processing unit and a memory, wherein the central processing unit is configured to invoke and run a computer program stored in the memory to perform the steps of the method described in this application.

[0009] According to another aspect of this application, a non-volatile readable storage medium is provided, which stores a computer program implemented according to the scene access control method in the form of computer-readable instructions, wherein the computer program is invoked by a computer to execute the steps included in the method.

[0010] According to another aspect of this application, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method.

[0011] Compared to traditional technologies, this application brings significant benefits to both game development and operation. Specifically, on the development side, by reusing mechanism templates and configuring business logic modules, different types of mechanisms no longer require writing separate, overlapping runtime logic code. Developers can quickly implement new mechanism types based on a unified framework, focusing only on their unique interaction and performance logic, thereby significantly reducing repetitive development work, lowering code maintenance complexity, and improving the responsiveness of feature iteration and content expansion. During runtime, because all mechanism instances can share the same management and scheduling mechanism, the memory usage and computational overhead of the game client and server are optimized, avoiding resource overlap and performance degradation caused by multiple independent systems coexisting. Simultaneously, the unified triggering, response, and state management process ensures a high degree of consistency and smoothness in the player's interaction experience across different types of mechanisms, avoiding operational delays or performance differences caused by system switching, significantly enhancing the immersion of the game world and the overall stability of operation. Furthermore, this application enables game designers to flexibly define or optimize mechanism behavior by adjusting configuration data without recoding the program, thereby greatly improving the design freedom and dynamic adjustment capability of game content while ensuring game performance. Attached Figure Description

[0012] Figure 1 This is an exemplary network architecture used in this application to run the game; Figure 2 This is a flowchart illustrating one embodiment of the scene access control method of this application; Figure 3 A graphical user interface for an exemplary game scene of this application is shown, in which a cableway mechanism is constructed between the ground and a highway; Figure 4 A graphical user interface for an exemplary game scene of this application is shown, in which a sliding mechanism built between buildings is illustrated; Figure 5 This is a schematic block diagram of the scene access control device of this application; Figure 6 This is a schematic diagram of the structure of an electronic device used in this application. Detailed Implementation

[0013] The technical solution of this application can be widely deployed in distributed computing architectures that support large-scale interactive virtual worlds. In a typical implementation environment, such as Figure 1As shown, the player's client device 80 connects to a service cluster 81 composed of game server nodes via a network. This cluster is responsible for maintaining the global state of the game world, physical rules, and the adjudication and synchronization of various game logics. A computer program implementing the method of this application, i.e., a game program, runs on the client device. This program communicates with the service cluster via the network, receives and renders the game scene, and uploads the player's operation commands to the server. The player controls their character in the game world to explore, move, and interact within a vast environment by using an input device.

[0014] This application is particularly suitable for open-world or large-scale games with complex terrain, vast exploration areas, and a need for efficient movement mechanisms to connect different regions. In such applications, the game world is divided into multiple logical areas, and scene-based access mechanisms, as key elements connecting different areas or providing unique movement experiences, are strategically pre-placed in specific locations. For example, cableways for quickly traversing canyons might be deployed between mountain ranges or on top of buildings, while railroad tracks for high-speed vehicle passage might be laid in abandoned industrial areas or along riverbanks. These mechanisms aim to provide players with a sense of speed beyond conventional movement methods, guidance along specific paths, or visually impactful movement sequences, thereby enriching the rhythm and experience of the exploration process.

[0015] To facilitate understanding of the following embodiments, some basic concepts involved in this application are uniformly explained here. A player character refers to a virtual avatar directly controlled by the player and performing various actions in the game world. A scene-based quick-access mechanism is a special interactive element pre-set in the game world, whose main function is to enable the player character to quickly move from one point to another in a preset manner, usually at high speed or along a specific path. A mechanism template class refers to a reusable code structure or prefab defined at the program implementation level; in this application, it describes the general attributes and behavioral framework of the scene-based quick-access mechanism. Mechanism configuration data is external data independent of the program code, used to specifically define the type, appearance, location, behavioral parameters, and other attributes of a scene-based quick-access mechanism. Business logic is a program module that encapsulates specific interaction rules and control flows; in this application, it specifically refers to the control logic related to the prompts, triggers, and movement behavior of the scene-based quick-access mechanism. Instantiation refers to the process by which the program creates a specific, interactive scene-based quick-access mechanism object in memory at runtime based on the template class and configuration data.

[0016] After providing a general overview of the technical architecture, application scenarios, and basic concepts of this application, the specific implementation methods of this application will be described in detail below with reference to the accompanying drawings.

[0017] Please see Figure 2The scene access control method of this application can be installed and run on the player's electronic device as a computer program product. In some embodiments, it includes the following steps: Step S3100: Monitor the real-time location generated by the player character's activity in the game scene; To facilitate understanding, let's first introduce an exemplary game scenario. This scenario can be a comprehensive open world encompassing modern urban complexes, hills, and industrial facilities. Within this scenario, players can control their character or drive vehicles such as motorcycles to freely move and explore between different areas. To enhance movement efficiency and the exploration experience, various rapid-access mechanisms are strategically placed throughout the game world. For example, cable car mechanisms can be installed on the upper floors and rooftops of tall buildings, and at the foot and summit of hills, allowing player characters to quickly move across vertical elevation differences. Figure 3 As shown, a cableway mechanism is constructed between the lower and upper levels of a building, with a flashing cableway path indicator in the middle and entrances / exits on either side. Each entrance can have a corresponding response area. In relatively flat road networks or within specific parks, as well as along the banks of canyons or ponds, sliding rail mechanisms that allow vehicles to move laterally at high speeds can be laid. For example... Figure 4 As shown, a sliding mechanism is constructed between the balcony on the left and the passageway on the right, with the two sides serving as entrances and exits to each other, while the middle is suspended in the air and represented by tracks and flashing visual elements. These mechanisms serve as special interaction points in the game scene, designed to provide players with a rapid passage capability that transcends conventional methods of movement.

[0018] During game operation, the real-time position generated by the player character's movements within the game scene can be continuously monitored. This real-time position is typically driven by player actions via input devices, and its data originates from the game engine's continuous tracking and updating of spatial transformation information such as the player character's coordinates and rotation. In one embodiment, the monitoring process can be implemented by the game engine calling a specific update function every frame, which acquires the player character's world coordinates in real time. In another embodiment, for online games, this real-time position may require initial calculation on the client side followed by synchronization verification with the server to ensure consistency of position information in a multi-player environment.

[0019] The real-time location data acquired through monitoring provides a unique and continuous spatial basis for subsequently determining whether a player character has entered a specific functional area, such as a mechanism loading area or an entrance response area. This entire monitoring mechanism ensures that the game system can promptly and accurately perceive the player's dynamics within the vast game world, thus laying a solid data foundation for the on-demand loading and interactive triggering of scene-based mechanisms.

[0020] Step S3200: When the real-time location first reaches the mechanism loading area in the game scene, the mechanism template class is instantiated by calling the predefined mechanism configuration data of the area to obtain the scene quick-access mechanism. The scene quick-access mechanism is bound to the corresponding business logic according to the mechanism type in the mechanism configuration data. When a player character's real-time position is detected to enter a pre-defined mechanism loading area in the game scene for the first time, the instantiation process of a scene access mechanism is triggered. This allows for the dynamic creation of interactive entities with specific functions and behaviors for the game scene based on data-driven principles. The mechanism loading area is a predefined, usually invisible space within the game scene. Its extent is set according to game logic requirements and is used to identify where and when specific scene access mechanisms need to be loaded into the game world, enabling on-demand resource loading and optimizing runtime performance. Scene access mechanisms created after the player character first enters the mechanism loading area can reside in memory according to a pre-defined mechanism, allowing the player character to reuse the mechanism upon returning to the scene, avoiding repeated instantiation and loading.

[0021] Upon the player character's first entry into the mechanism loading area, the pre-configured mechanism configuration data associated with the target mechanism loading area is invoked. Mechanism configuration data is an external data asset stored in the game project resources, independent of the program code, and its function is to define the various attributes of the scene's achievable mechanisms. In this application, a typical mechanism configuration data set contains at least two key parts. The first is a type identifier, a data field used to uniquely distinguish the mechanism category; for example, it can be an enumeration value or a string, indicating whether the mechanism is a cableway mechanism or a sliding mechanism. The second is layout parameters, which define the specific spatial attributes of the mechanism instance in the game world, typically including coordinates in world space, rotation angle, scaling ratio, and a possible set of spline path points, used to determine the appearance and spatial location of the mechanism model.

[0022] After obtaining the mechanism configuration data, specific instance of the scene-accessible mechanism is created based on a standardized, predefined mechanism template class. The mechanism template class in this application is a programmable blueprint or component class developed within the game engine, encapsulating the common basic behaviors and attributes of scene-accessible mechanisms. The mechanism template class provides a common functional framework for all types of mechanisms, such as initialization and destruction logic, basic collision detection boxes, and a common interface for interacting with the game world. The instantiation process involves creating a new object instance in memory based on the structure of the mechanism template class, and using the layout parameters read from the mechanism configuration data to spatially locate and initialize the instance, thereby loading it into the specified position in the game scene.

[0023] During instantiation, the game system binds the corresponding business logic to the newly created mechanism instance based on the type identifier in the mechanism configuration data. To this end, the game system can maintain a pre-built logic resource library, storing pre-written business logic modules corresponding to different mechanism types. When the type identifier indicates a cable car mechanism, the system retrieves the business logic module encapsulating cable car-specific behaviors from the library; if it indicates a slide mechanism, it retrieves the slide mechanism-specific business logic module. These business logic modules can exist as script components or dynamic link libraries, encapsulating the specific logic of how the mechanism responds to player interactions and how to control the movement process. They can be further subdivided into multiple specific control logic parts to correspond to different control requirements. After obtaining the correct business logic module, the game system dynamically binds it to the newly created scene access mechanism instance through a component system or a similar dependency injection mechanism. At this point, a fully functional scene access mechanism in an interactive, ready-to-use state is instantiated, awaiting the player's entry into its next stage of interaction.

[0024] In one embodiment, the game system's management page provides a visual configuration interface for level designers or planners to generate mechanism configuration data. Designers can select a specific area in the game scene editor and activate the mechanism placement tool. Through mouse clicks and drags, they can intuitively define the spatial boundaries of the mechanism loading area and the trigger range of the entrance response area in the 3D scene. In the attribute panel, they can select the mechanism type, such as a cableway or a slide, through a drop-down menu to set a type identifier. At the same time, they can precisely set layout parameters, including spatial coordinates, rotation angles, and spline curve control points used to define the movement path, through numerical input boxes or curve editors. All configuration parameters are serialized into structured data files in real time and stored in the project resource library, thus forming mechanism configuration data that can be loaded and parsed during game runtime.

[0025] Step S3300: When the real-time location enters the entrance response area set by the scene speed-up mechanism that has been loaded into the game scene, the first control logic in the business logic is run to generate a visual prompt effect in the entrance response area. When a player character's real-time position enters the entrance response area of ​​a scene-based quick-access mechanism loaded into the game scene, the first control logic in the business logic bound to that mechanism instance will be executed to generate visual cues within the entrance response area to guide player interaction. The entrance response area is a pre-defined, usually invisible spatial range surrounding the scene-based quick-access mechanism instance, used to detect whether the player has entered a close-range area where interaction can be triggered. The shape and size of this area can be configured according to the mechanism type and design requirements; for example, it can be a spherical area surrounding the cableway entrance or an area expanded from the entrance, or a rectangular area extending along the starting point of the slide rail.

[0026] When the first control logic is executed, the target interaction method corresponding to the type of expedited mechanism in the current scene is first determined. This can be determined based on the type identifier in the mechanism configuration data and the pre-bound business logic module. For example, if the mechanism type is a cableway mechanism, its target interaction method can be defined as using a hook for displacement interaction; if the mechanism type is a sliding rail mechanism, its target interaction method can be defined as driving a vehicle for suction interaction. The business logic module encapsulates the mapping rules between types and interaction methods.

[0027] After determining the target interaction method, the first control logic can immediately activate the matching visual cue element within the entrance response area. A visual cue element is a visual feedback component in a user interface or game scene, its function being to clearly and intuitively indicate to the player what action can be performed to trigger the passage process of the scene's quick-access mechanism. In one embodiment, for example... Figure 3 The visual cue element for activating the cableway mechanism shown could be a continuously flashing grappling hook icon floating in the air, or a guiding beam of light shooting from the mechanism's entrance towards the player. In another embodiment, for example... Figure 4 The sliding mechanism shown can be activated with visual cues such as displaying a highlighted arrow at the start of the track or giving the track a glowing effect. These visual elements are designed to attract the player's attention and clearly indicate the next action to be taken.

[0028] The technical implementation of generating visual cues can be diverse. In one embodiment, it can be achieved by attaching a specific particle system component to an instance of a scene's quick-access mechanism, which is activated when the player enters the area. In another embodiment, it can be achieved by dynamically generating a two-dimensional icon or cue text on a specific layer of the user interface. The display of visual cues is typically accompanied by smooth fade-in animations or subtle pulsations to enhance their guidance without appearing abrupt. This entire process ensures that players receive clear, timely, and functionally appropriate interactive guidance when approaching scene quick-access mechanisms.

[0029] Step S3400: In response to the interactive execution event triggered by the player, the second control logic in the business logic is run to control the visual performance of the player character in the passage process corresponding to the scene speed-up mechanism.

[0030] When a player is within the entrance response area of ​​a scene's quick-access mechanism, in one embodiment, after completing the execution of the first control logic, the second control logic of this step can be automatically executed, making the player character's passage process smoother and more efficient. In another embodiment, to enhance the interactive experience, the player can trigger predefined interactive execution events, such as pressing a specific button or clicking an interactive control on the screen. The game system will respond to the event and execute the second control logic in the business logic bound to the mechanism instance. The second control logic is used to take over the player character's control and drive it to execute a complete passage process visual presentation corresponding to the current scene's quick-access mechanism type.

[0031] The second control logic first determines the movement mode corresponding to the current mechanism type based on the type identifier in the mechanism configuration data. The movement mode defines the movement rules and visual style followed by the player character to complete the passage. In one embodiment, if the mechanism type is a cableway mechanism, the movement mode is determined to be the first mode, which requires switching the player character's normal visual appearance to a more visually impactful or high-speed movement-appropriate alternative. In another embodiment, if the mechanism type is a sliding mechanism, the movement mode is determined to be the second mode, which emphasizes the player character and their associated vehicle moving as a whole along a constrained track.

[0032] When the movement mode is determined to be the first mode, the second control logic executes the control flow for cable car movement. This flow initially switches the player character's visual representation from a regular solid model to a specific visual substitute, such as replacing it with particle effects, flowing light trails, or other abstract graphic representations symbolizing high-speed movement. Subsequently, this visual substitute is driven to move along a predefined cable car path. The cable car path can be pre-defined in 3D space by level designers using splines, representing a spatial curve connecting the starting and ending points. The driving process involves continuously updating the position and rotation of the visual substitute based on path data, and can be combined with speed curve control to achieve acceleration, constant speed, or deceleration effects, thus visually presenting the player character as if gliding or flying at high speed along the cable car, completing the movement from one spatial point to another based on elevation differences.

[0033] When the movement mode is determined to be the second mode, the second control logic executes the control flow for sliding along the track. This flow first treats the player character and their controlled vehicle, such as a motorcycle, as an indivisible composite motion unit. Then, through physical constraints or kinematic calculations, this motion unit is locked onto a predefined track path. The track path is also defined by splines, typically representing a relatively flat or curvatured spatial trajectory. Once locked, the game system drives the motion unit to move automatically along the track path. During the movement, additional control rules can be applied, such as ignoring external physical disturbances, to ensure stability and specific visual effects, thus visually presenting a scene of the vehicle gliding at high speed and stably on the track, completing lateral movement along a specific path.

[0034] The execution of the visual presentation throughout the passage process is the climax and final presentation of the scene's rapid access mechanism interaction. The second control logic, through precise control of character performance, movement trajectory, and time sequence, transforms the preset movement plan into smooth, believable, and visually appealing in-game events, ultimately achieving the design goal of rapid passage and providing players with a brief but memorable gaming experience.

[0035] As can be seen from the above embodiments, this application has achieved significant technical advantages over traditional technologies in terms of technical architecture, development efficiency, and runtime performance, including but not limited to: Firstly, at the technical architecture level, this application fundamentally solves the architectural redundancy problem caused by independent functional development in traditional technologies by introducing a unified framework of data-driven and template instantiation. In traditional technologies, different access mechanisms such as cableways and slides need to be developed as completely independent entities, each maintaining a complete logic chain from triggering and movement to rendering, resulting in code duplication and scattered logic. This application, however, decouples the behavior definition and code implementation of scene access mechanisms by defining a unified mechanism template class, configurable business logic modules, and external mechanism configuration data. This allows different types of mechanisms to share the same core instantiation, management, and scheduling framework, differentiating their behavior only through configuration data. This achieves a high degree of architectural uniformity and reusability, eliminates redundant code, and brings better maintainability and scalability to the game system.

[0036] Secondly, in terms of development efficiency, this application significantly improves the speed of game content production and iteration. In the traditional model, adding or modifying a new mechanism requires programmers to engage in in-depth coding, resulting in high costs and long development cycles for collaboration between designers and programmers. This application externalizes and configures the type, path, parameters, and other attributes of mechanisms, allowing designers to directly define and adjust mechanism behavior through visual tools, requiring no recoding or only minimal programming support. This data-driven approach shifts some of the control over content creation forward, decoupling designers and programmers, significantly reducing the complexity and time cost of feature iteration, and enabling rapid prototype design and gameplay verification.

[0037] Furthermore, at the runtime performance level, this application effectively optimizes the game client's performance and the player's interactive experience. Since all mechanism instances share the same underlying management and rendering resources, the cumulative memory and computational overhead caused by multiple independent mechanisms coexisting is avoided, thereby reducing runtime resource consumption and helping to maintain a stable game frame rate. Simultaneously, the unified interaction triggering, state management, and visual feedback process ensures that players receive a highly consistent, smooth, and responsive operating experience when interacting with different types of mechanisms, avoiding stuttering and disconnect caused by switching mechanism systems or differences in logic, significantly enhancing the immersion of the game world and the overall smoothness of its operation.

[0038] Based on any embodiment of the method in this application, a mechanism template class is instantiated by calling the predefined mechanism configuration data of the region to obtain the scene quick-access mechanism, including: Step S3210: Read the mechanism configuration data. The mechanism configuration data includes a type identifier for identifying the type of mechanism, and layout parameters for defining the spatial position and spatial form of the scene speed-access mechanism in the game scene. When the game system determines that a scene access mechanism needs to be instantiated, it first performs the operation of reading the mechanism configuration data. The mechanism configuration data can be implemented as a structured data file stored in the game project resource directory, such as JSON, XML, or a specific binary format. Its purpose is to define all the static properties of the scene access mechanism in a data-driven manner.

[0039] This data contains at least two core parts. The type identifier is a crucial data field whose value uniquely distinguishes the behavior category of a mechanism within the program logic. For example, an enumeration value of 1 could represent a cableway mechanism, and an enumeration value of 2 could represent a sliding mechanism, or strings such as "Zipline" and "Rail" could be used for identification. The layout parameters define the specific spatial attributes of the mechanism instance in the 3D game world. Typically, this can include a transformation matrix in world space, containing specific data such as position coordinates, rotation Euler angles or quaternions, scaling ratios, and an optional set of path points used to describe the motion trajectory splines of the cableway or sliding mechanism.

[0040] The reading process can be completed through the game engine's resource management system. Based on the unique identifier of the mechanism loading area, the corresponding configuration file is loaded and deserialized into a data structure in memory, providing parameter basis for subsequent instantiation.

[0041] Step S3220: Based on the type identifier, obtain a business logic module that matches the type of organization from a preset logic resource library. The business logic module encapsulates the first control logic and the second control logic. After acquiring the mechanism configuration data, the game system matches and loads the corresponding business logic based on the read type identifier. The game program in this application maintains a pre-built logic resource library, which can be a directory containing various script files, a collection of dynamic link libraries, or a registry containing various logics. The game system uses the type identifier as a key to search for and load the corresponding business logic module from this library. For example, when the type identifier indicates a cableway mechanism, a script module named ZiplineLogic is loaded; if it indicates a rail mechanism, a script module named RailLogic is loaded. These business logic modules are pre-developed code units that encapsulate the complete behavioral logic of a specific mechanism, internally encapsulating the first control logic responsible for interactive prompts and the second control logic responsible for the passage process. The loading method can be dynamically interpreting and executing the script at runtime, or instantiating the compiled logic components through a dependency injection framework.

[0042] Step S3230: Based on the layout parameters, generate an instance of the mechanism template class at the corresponding position in the game scene to load the corresponding scene quick access mechanism, and bind the obtained business logic module to the instance to complete the instantiation of the scene quick access mechanism.

[0043] After obtaining the business logic module and parsing the layout parameters, the game system begins the instantiation process of the mechanism template class. The mechanism template class contains prefabs or base classes of common basic components for scene-accelerating mechanisms (such as transformation components, mesh renderer components, and basic colliders). Instantiation involves calling the engine's instance creation interface to create a new game object in memory based on the template.

[0044] Subsequently, the game system sets the world transformation of the new instance based on the position, rotation, and scaling information provided in the layout parameters, ensuring it is correctly placed in the game scene. Additionally, if the layout parameters include pathpoint data, it assigns it to the instance's corresponding attributes.

[0045] Finally, the game system can bind the previously loaded business logic modules to this newly created scene express mechanism instance through dependency injection, component addition, or message registration, so that the instance can execute specific interaction and performance logic at runtime.

[0046] At this point, a scene-based rapid response mechanism instance with a specific type, a designated location, and full behavioral capabilities has been officially created and entered standby mode.

[0047] Through the above embodiments, this application organically integrates the agency configuration data, agency template classes, and business logic modules to construct a complete data-driven instantiation process. This process enables the creation of scenario-based rapid access agencies to no longer rely on hard coding, but rather dynamically combines their types, forms, and behaviors by parsing external configuration data. This fundamentally solves the code redundancy and maintenance difficulties caused by independent functional development in traditional technologies, achieving high resource reuse and complete decoupling of development, significantly improving development efficiency and reducing maintenance complexity.

[0048] Based on any embodiment of the method in this application, the first control logic in the business logic is run to generate a visual cue effect in the entry response area, including: Step S3310: Determine the target interaction method corresponding to the current agency type based on the first control logic in the business logic bound to the scenario-based rapid access agency; When a player character enters the entrance response area of ​​a scene's quick-access mechanism and triggers the execution of the first control logic, this logic first determines the target interaction method. The target interaction method refers to the specific operation command the player needs to execute to trigger the scene's quick-access mechanism function. Its determination process directly depends on the business logic module bound to the mechanism instance in previous steps. Since the business logic module is dynamically matched and loaded based on the type identifier in the mechanism configuration data, the first control logic bound to different types of mechanisms inherently encapsulates the interaction rules corresponding to their functions.

[0049] Specifically, the first control logic internally maintains or has access to a mapping relationship that associates mechanism types with desired interaction methods. In one embodiment, when the business logic module is configured for a cableway mechanism type, the rules defined within its first control logic determine the target interaction method as a grappling hook interaction, corresponding to the player pressing a specific function key or clicking a specific screen control to launch a grappling hook and pull the character forward. In another embodiment, when the business logic module is configured for a sliding rail mechanism type, its first control logic can determine the target interaction method as a vehicle attraction interaction, corresponding to the player pressing a specific button while riding to automatically attract and lock the vehicle onto the track. The determination process can be automatic and instantaneous; the game system reads predefined interaction type constants or configuration items from the logic module bound to the current mechanism instance, without requiring complex runtime judgments.

[0050] The technical implementation of determining the target interaction method can be based on simple conditional judgments or lookup tables. Since the mechanism type is determined and bound to the corresponding business logic through configuration data during instantiation, the first control logic only needs to execute its internally preset code path strongly related to that type at runtime. For example, the first control logic code block in the business logic module of the cableway mechanism always outputs a hook-and-line interaction; while the code block corresponding to the sliding rail mechanism always outputs a vehicle adsorption interaction. This approach ensures the accuracy and immediacy of the interaction prompts, providing a clear instruction basis for subsequently activating the corresponding visual prompt elements.

[0051] Step S3320: Within the entrance response area, activate a visual cue element that matches the target interaction method, wherein the visual cue element is used to indicate to the player that the passage process of the scene speed-up mechanism can be triggered by performing the target interaction method.

[0052] After determining the target interaction method corresponding to the current mechanism type, the first control logic then activates the matching visual cue element within the entrance response area. The visual cue element clearly and intuitively conveys information to the player, indicating what specific actions can be performed in the current area to trigger the passage to the mechanism.

[0053] The specific form and presentation of visual cues can be flexibly designed according to different target interaction methods. In one embodiment, when the target interaction method is determined to be a grappling hook interaction, the activated visual cue element could be a grappling hook icon with a dynamic flashing effect floating near the entrance of the scene's quick-access mechanism, or a guiding beam particle effect shooting from the mechanism's starting point towards the player character. In another embodiment, when the target interaction method is determined to be a vehicle attraction interaction, the activated visual cue element could be a highlighted arrow projection displayed on the ground at the starting end of the rail, or a section of the rail itself emitting a pulsating halo within the entrance response area to suggest that the vehicle can travel along this path. These elements are designed to quickly attract the player's attention and clearly indicate the next action through non-textual visual language that aligns with the game's worldview.

[0054] There are various technical approaches to activating visual cues. In one embodiment, this can be achieved by attaching a dedicated particle system component or highlight outline component to the instance of the scene's quick-access mechanism. When the first control logic is triggered, the activation attribute of this component is set to true, causing it to begin rendering. In another embodiment, a 2D sprite or 3D control can be dynamically instantiated on the world space canvas or screen space overlay of the user interface, and its position can be associated and bound to the screen coordinates of the mechanism's entrance in the game world. The activation process of the visual cues can be accompanied by smooth animation effects, such as fade-in, scaling, or slight rotation, to enhance their visual guidance without appearing abrupt. The entire process ensures that players receive clear, eye-catching, and highly functional interactive guidance immediately upon entering the entrance response area, thereby reducing the learning cost of operation and improving the game's usability and immersion.

[0055] As can be seen from the above embodiments, this application organically combines the two aspects of automatic matching of mechanism type with target interaction method and dynamic activation of visual prompt elements that precisely correspond to the interaction method, thus constructing a highly automated, context-aware interactive guidance system. This system can generate visual guidance information that perfectly matches the specific functional type of the mechanism to be reached in the current scene in real time, thereby ensuring that players can always get accurate and intuitive operation prompts in front of different types of mechanisms, greatly reducing the cognitive load and probability of misoperation of players, and significantly improving the intuitiveness, ease of use and overall smoothness of the user experience of the game interaction.

[0056] Based on any embodiment of the method in this application, the second control logic in the business logic is run to control the player character to perform the visual performance of the passage process, corresponding to the scene speed-access mechanism, including: Step S3410: Determine the passage movement mode corresponding to the current mechanism type based on the second control logic in the business logic bound to the scene express mechanism; When a player triggers an interaction event, the second control logic within the business logic bound to the scene's quick-access mechanism begins to determine the movement mode corresponding to the current mechanism type. The movement mode defines the movement rules, visual style, and overall paradigm of the underlying control logic that the player character follows during the passage process. This mode determination process directly relies on the business logic module bound to the current scene's quick-access mechanism instance during its initialization phase, and this module is loaded from a pre-set logic resource library based on the type identifier in the mechanism configuration data.

[0057] The movement mode can be determined based on a mapping of type identifiers. Upon startup, the second control logic efficiently determines the movement mode by directly reading predefined movement mode constants or configuration items from its associated business logic module. Since the business logic module is type-specific, its internally encapsulated second control logic has pre-defined behavior modes matching that type of mechanism. In one embodiment, if the type identifier of the current mechanism indicates it is a cableway mechanism, the second control logic in its bound business logic module will pre-set the movement mode to the first mode. This mode replaces the player character's conventional visual appearance with a more abstract or expressive form, driving it to move along a pre-defined spatial path, suitable for scenarios involving rapid traversal of varying terrain. In another embodiment, if the type identifier indicates it is a sliding mechanism, its second control logic will pre-set the movement mode to the second mode. This mode emphasizes treating the player character and its vehicle as a whole and constraining its movement on a specific track, suitable for scenarios involving high-speed, automated vehicle movement on fixed paths.

[0058] Step S3420: When the passage movement mode is the first mode, switch the visual appearance of the player character to particle effects, and drive the particle effects to move along the predefined cableway path with height difference. When the travel mode is determined to be the first mode, the second control logic begins to execute the specific control process for cableway travel, replacing the player character's regular visual presentation with a more abstract or expressive visual form, and driving that form to move along a predetermined path to present a high-speed travel effect.

[0059] The process begins by switching the player character's visual appearance to particle effects. This switching involves hiding the player character's regular 3D model and instantiating a pre-defined particle system in its original location. This particle system is specifically designed to simulate high-speed motion, energy flow, or other visual effects consistent with fantasy or science fiction settings, such as a streak of light, a cloud of particles, or a trajectory line. In one embodiment, the switch can be instantaneous, achieved by setting the visibility properties of the model rendering components and the activation state of the particle system. In another embodiment, the switch can be accompanied by a short transition animation, such as the character model gradually breaking down into particles and converging into a new effect form, to enhance visual continuity.

[0060] Subsequently, the second control logic drives the particle effect to move along a predefined cableway path, where "elevation difference" refers to movement relative to the physical laws of the game world. The cableway path can be predefined in 3D space by level designers using splines. This path connects two or more spatial points and may include significant height changes to reflect the characteristics of elevation difference movement. The driving process involves calculating the particle effect's position and orientation in each frame update based on preset movement speed, acceleration curves, and the arc length of the path, and updating its position by setting its world transformation matrix. In one embodiment, the movement can be uniform. In another embodiment, the movement speed can vary dynamically, for example, accelerating at the starting point, maintaining a constant speed midway, and decelerating near the end point, to simulate a more realistic sense of motion. The entire movement process aims to visually create a strong sense of dynamism, as if the player character is gliding at high speed along the cableway or flying across a canyon, completing the elevation difference movement from one spatial point to another.

[0061] Step S3430: When the travel mode is the second mode, the player character and its associated vehicle are locked as the same motion unit to a predefined slide rail path, and the motion unit is driven to move laterally along the slide rail path.

[0062] When the travel mode is determined to be the second mode, the second control logic begins to execute the specific control process for rail travel, treating the player character and the vehicle they control as an indivisible composite motion unit, and constraining the motion trajectory of this motion unit to the predefined rail path, so as to present the visual effect of the vehicle gliding at high speed and stably on the rail.

[0063] The process begins by locking the player character and their associated vehicle as a single motion unit to a predefined track path. Locking means the system takes over motion control of the unit, deviating it from conventional physics simulation or direct player control and instead guiding it according to specific motion rules defined by the track path. In one embodiment, locking can be achieved by applying a strongly constrained physical joint to the motion unit or setting its motion mode to a kinematic mode, allowing its position and rotation to be directly driven by the program based on the path, rather than calculated by the physics engine. In another embodiment, locking can be achieved by directly setting the motion unit's world coordinates to a calculated position on the path each frame, thus achieving precise track following. The track path can be predefined in the game world by level designers using splines; its shape can be a relatively gentle curve or a straight line, representing the track's central axis.

[0064] After successful locking, the second control logic drives the motion unit to move laterally along the slide path. This lateral movement refers to movement relative to the physical laws of the game world. The driving process involves calculating the precise position and orientation of the motion unit in each frame update, based on a preset movement speed curve and the arc length of the path. In one embodiment, the movement can be uniform to maintain a stable sense of speed. In another embodiment, the movement speed can be dynamically varied, for example, accelerating upon entering the slide, maintaining high speed during the journey, and decelerating near the finish line to enhance the realism and rhythm of the movement.

[0065] Throughout the movement, additional control rules can be applied to the motion unit to maintain specific performance effects. In one embodiment, the motion unit can be set to an invincible state and collisions with other game characters or the environment can be ignored to ensure that the movement process is not unexpectedly interrupted, thereby maintaining the smoothness of the performance and the continuity of the player experience. In another embodiment, in response to player-inputted track switching commands, when parallel sliding track paths exist, the motion unit can be controlled to smoothly switch from the current path to an adjacent path, increasing the interactivity of the operation and the variability of the route. The entire driving process aims to visually create a dynamic scene of the vehicle gliding at high speed close to the track, completing lateral movement on a specific path.

[0066] Through the above embodiments, this application organically integrates the automatic matching of mechanism types and passage movement modes, as well as the two distinct and highly specialized visual presentation and control logics adopted for different modes, to construct a unified passage process presentation framework that can adapt to different types of scenarios for quick access to mechanisms. This framework not only ensures a high degree of differentiation and immersion in the visual presentation and interactive experience of different functional mechanisms such as cableways and slides, but also achieves efficient reuse and unified management of diverse passage gameplay by encapsulating complex motion control, state management and visual rendering logic in configurable business modules. This significantly reduces the technical complexity and maintenance cost of content creation while providing a rich and high-quality player experience.

[0067] Based on any embodiment of the method in this application, driving the particle effect to move along a predefined cableway path with a height difference includes: Step S3421: Disable the team member switching function associated with the player character; Throughout the process of driving the particle effects along the cableway path, the game system performs a series of state management operations to maintain immersion and consistency in the gameplay. First, the player's team member switching function is disabled. Accordingly, during the particle effect's movement, the game system prevents the player from performing any actions to switch control of other team members. In one embodiment, this can be achieved by setting the interactive state of the team switching control in the user interface to non-clickable and disabling its corresponding keyboard shortcuts or gamepad button input events. In another embodiment, the player's permission to switch team members can be temporarily removed from the game's background logic. This measure ensures that the player's attention is focused on the current character's high-speed movement, avoiding logical conflicts or visual illusions caused by team member switching.

[0068] Step S3422: Disable the vehicle summoning function associated with the player character; Simultaneously, the game system can disable the vehicle summoning function associated with the player character. This prevents players from summoning new vehicles while moving. In one embodiment, this can be achieved by graying out the user interface icon for the vehicle summoning skill and disabling its triggering logic. In another embodiment, the vehicle summoning skill can be temporarily removed from the player's available skill list. This measure prevents players from illogically summoning vehicles while suspended in the air or moving at high speed, thereby maintaining the consistency of the game world's physics. Disabling teammate switching and vehicle summoning functions work together to create a temporary, focused state for the player character during travel, eliminating external operational interference that could disrupt the continuity of the experience.

[0069] Step S3423: In response to the received mid-game exit command, interrupt the movement of the particle effects and restore the normal visual appearance of the player character.

[0070] Throughout the movement, the game system continuously listens for and prepares to respond to any mid-journey exit commands. These commands can be triggered by the player through specific input actions, such as pressing the dodge button, jump button, or a dedicated cancel skill button. When the game system receives this command, it immediately interrupts the movement of particle effects along the cableway path. The interruption includes stopping the updating of particle effect positions based on the path and may also play a short exit animation, such as particles dissipating or shrinking. The game system can then restore the player character's normal visual appearance. The restoration includes hiding the particle effects representing the movement state and redisplaying the player character's original 3D model, placing it where the particle effects were when movement was interrupted. In one embodiment, the character may play a landing or balancing animation after resuming to smoothly transition to the normal state. This mechanism gives players control over actively exiting the journey, increasing the flexibility and fault tolerance of the interaction.

[0071] Through the above embodiments, this application organically combines the state locking function with the interruption recovery mechanism, constructing a controlled and closed interactive environment during particle effect movement. This effectively prevents accidental operations that may disrupt immersion and logical consistency. At the same time, by providing a clear interruption exit, it ensures the autonomy of player operation, thereby significantly improving the smoothness and controllability of the user experience during special movement processes while ensuring the integrity of the performance.

[0072] Based on any embodiment of the method in this application, driving the motion unit to move laterally along the slide rail path includes: Step S3431: Set the motion unit to an invincible state during its movement and ignore its collisions with other game characters; Throughout the lateral movement of the motion unit along the track path, the game system can execute a series of auxiliary logics to enhance the experience and provide interactive control. First, during the motion unit's movement, the game system sets the motion unit to an invincible state and ignores collisions with other game characters. The invincible state shields the motion unit from external influences; in this state, the motion unit is not affected by any hostile attacks or negative status effects. In one embodiment, this can be achieved by setting the motion unit's health component to be unmodifiable and disabling its hit detection logic. Simultaneously, the game system ignores physical collisions between the motion unit and other game characters. In one embodiment, this can be achieved by temporarily setting the motion unit's collider to trigger mode or by ignoring it in its collision matrix with other characters. This ensures that the high-speed movement of the motion unit on the track is not interrupted by combat or accidental physical collisions, maintaining the smoothness and stability of the movement animation and providing players with an undisturbed, cinematic experience.

[0073] Step S3432: In response to the track switching command, control the motion unit to switch from the current slide rail path to the adjacent parallel slide rail path; During movement, the game system continuously listens for and prepares to respond to player-inputted track-switching commands. These commands can be triggered by the player using directional keys, specific function keys, or screen gestures. When the game system receives this command, it controls the movement unit to switch from the current track path to an adjacent parallel track path. In one embodiment, the game system detects whether a suitable parallel track path exists near the current movement unit's position. If so, it calculates a smooth transition trajectory from the current path to the target path, which can be an interpolated curve. Subsequently, the movement unit's following path gradually transitions from the current track path to the new target path, updating its trajectory. In another embodiment, the switch can be represented by a rapid lateral jump animation, directly landing on the adjacent track. This feature provides players with limited route selection during fixed-path movement, increasing interactivity and strategy, making track movement more than just simple animation; it retains some operational space.

[0074] Step S3433: In response to the mid-way exit command, control the motion unit to detach from the slide rail path, and achieve the inertial motion effect of the motion unit based on the motion state at the time of detachment.

[0075] In addition, the game system also listens for mid-game exit commands from the player. These commands can be triggered by pressing specific keys such as the jump key, dodge key, or a dedicated cancel key. Upon receiving this command, the game system controls the motion unit to disengage from the track path. Disengagement involves releasing the motion unit from the track path and stopping its automatic movement along the path. Then, inertial motion effects can be implemented based on the motion unit's state at the time of disengagement.

[0076] In one embodiment, the inertial motion effect can be achieved by assigning the motion unit an initial velocity at the moment of disengagement, consistent with the magnitude and direction of its last velocity on the track, and then allowing it to re-enter the game's normal physics simulation state. The motion unit will continue to slide a distance in that direction, affected by physical factors such as gravity and friction, until it stops. This mechanism ensures that the termination of movement is not an abrupt stop, but a smooth transition consistent with physical intuition, enhancing the realism and feel of the game.

[0077] By organically combining damage immunity and collision ignore during movement, controllable track switching capabilities, and an inertial exit mechanism that conforms to the laws of physics, this embodiment cleverly introduces player interaction and physical realism while ensuring smooth and undisturbed sliding motion. This transforms a pre-set automatic movement into a high-quality interactive experience that combines cinematic expressiveness, player engagement, and physical realism, significantly enhancing the fun and technical sophistication of sliding.

[0078] Based on any embodiment of the method in this application, after instantiating a mechanism template class by calling the predefined mechanism configuration data of the region to obtain the scene quick-access mechanism, the method includes: Step S4100: When a player character is detected to have started the passage process visual display, the state of the scene quick access mechanism is marked as occupied. Once a scene access mechanism instance is successfully created and enters an interactive state in the game world, the game system can immediately begin continuous management of its usage status to ensure the orderly interaction of mechanisms in a multiplayer environment. Once the game system detects that any player character has officially begun the visual process associated with that mechanism—for example, a character particle-like movement along a cableway or a vehicle locked to a rail and beginning to slide—it can immediately mark the internal state of that scene access mechanism as occupied. This status marking can be achieved by modifying a state variable within the mechanism instance, for example, changing it from the enumerated value Available to Occupied. This operation indicates that the mechanism resource is currently occupied and cannot provide services to other players.

[0079] Step S4200: When the scene speed-access mechanism is occupied, block the triggering of the first control logic and the second control logic for any other player character; During the entire period when a scene-accessible mechanism is occupied, the game system can block any other player character attempting to interact with it. Specifically, it can block the triggering of the first and second control logics. In one embodiment, when another player character enters the mechanism's entrance response area, the game system will not run the first control logic, thus generating no visual cue, making the mechanism appear unavailable to other players. In another embodiment, even if another player character attempts to send an interaction execution event through unconventional means, the game system will check the mechanism's status at the initial stage of event handling. If the status is occupied, the event will be ignored, thereby preventing the execution of the second control logic. This blocking mechanism completely eliminates logical conflicts, animation glitches, or state synchronization errors that may occur when multiple players use the same mechanism simultaneously, ensuring the independence and integrity of each interaction.

[0080] Step S4300: After the player character finishes the passage process visually, set the state of the scene speed-access mechanism to a cooldown state and start a timer; When a player character occupying a scene's quick-access mechanism completes their passage through a visual sequence—such as particle effects moving to the endpoint and the character returning to their original state, or a vehicle gliding to the end of the track and unlocking—the game system can change the mechanism's status from occupied to cooldown. Simultaneously, a timer associated with the mechanism instance can be started to calculate the cooldown time. This cooldown time can be flexibly preset according to the actual game scenario, for example, set to 1 to 3 seconds. Entering the cooldown state means that while the scene's quick-access mechanism is idle, it is not yet ready for the next interaction, representing the brief recharging or reset time required after continuous use.

[0081] Step S4400: When the timer reaches the preset cooling time, the state of the scene speed-access mechanism is restored to the interactive state.

[0082] The timer runs independently, and the game system continuously checks its count. When the timer reaches a preset cooldown period, the game system restores the interactive mechanism from its cooldown state to an interactive state. The preset cooldown period can be a fixed value or part of the mechanism's configuration data, allowing level designers to configure different cooldown times for different types of mechanisms. After the state is restored, the mechanism can once again respond to the player's approach and interaction, and a new usage cycle begins.

[0083] By clearly dividing the lifecycle of mechanisms into three states—interactive, occupied, and cooldown—and supplementing this with state-driven logic masking and timer control, this embodiment constructs a robust mechanism resource management scheme for multiplayer environments. This scheme ensures that only one player can use a specific mechanism at a time, avoiding logical errors caused by resource contention. Simultaneously, the cooldown mechanism controls the frequency of mechanism usage, conforming to certain scenario logic and providing a means of adjusting game balance. Ultimately, it creates a fair, orderly, and stable interactive experience in multiplayer online games.

[0084] Please see Figure 5According to one aspect of this application, a scene access control device includes a location monitoring module 3100, a mechanism implementation module 3200, an entrance display module 3300, and a access display module 3400. The location monitoring module 3100 is configured to monitor the real-time location generated by a player character's activity in a game scene. The mechanism implementation module 3200 is configured to, when the real-time location first reaches a mechanism loading area in the game scene, instantiate a mechanism template class using predefined mechanism configuration data for that area to obtain a scene quick-access mechanism. The scene quick-access mechanism is bound to corresponding business logic based on the mechanism type in the mechanism configuration data. The entrance display module 3300 is configured to, when the real-time location enters the entrance response area set by the scene quick-access mechanism loaded in the game scene, run a first control logic in the business logic to generate a visual prompt effect in the entrance response area. The access display module 3400 is configured to, in response to an interactive execution event triggered by the player, run a second control logic in the business logic to control the player character to perform a visual display of the access process corresponding to the scene quick-access mechanism.

[0085] Based on any embodiment of this device, the mechanism implementation module 3200 includes: a configuration reading module, configured to read the mechanism configuration data, the mechanism configuration data including a type identifier for identifying the mechanism type, and layout parameters for defining the spatial position and spatial form of the scene-accessible mechanism in the game scene; a logic configuration module, configured to obtain a business logic module matching the mechanism type from a preset logic resource library according to the type identifier, the business logic module encapsulating the first control logic and the second control logic; and a configuration execution module, configured to generate an instance of the mechanism template class at a corresponding position in the game scene according to the layout parameters to load the corresponding scene-accessible mechanism, and bind the obtained business logic module to the instance to complete the instantiation of the scene-accessible mechanism.

[0086] Based on any embodiment of this device, the entrance display module 3300 includes: an interaction determination module, configured to determine a target interaction method corresponding to the current mechanism type according to the first control logic in the business logic bound to the scene quick access mechanism; and a visual prompt module, configured to activate a visual prompt element matching the target interaction method within the entrance response area, wherein the visual prompt element is used to indicate to the player that the passage process of the scene quick access mechanism can be triggered by executing the target interaction method.

[0087] Based on any embodiment of this device, the passage performance module 3400 includes: a mode determination module, configured to determine a passage movement mode corresponding to the current mechanism type according to the second control logic in the business logic bound to the scene speed-access mechanism; a cableway performance module, configured to switch the visual performance of the player character to particle effects when the passage movement mode belongs to the first mode, and drive the particle effects to perform height difference movement along a predefined cableway path; and a sliding rail performance module, configured to lock the player character and its associated vehicle as the same movement unit to a predefined sliding rail path when the passage movement mode belongs to the second mode, and drive the movement unit to perform lateral movement along the sliding rail path.

[0088] Based on any embodiment of this device, the cableway performance module includes: a switching disable module, configured to disable the team member switching function associated with the player character; a summoning disable module, configured to disable the vehicle summoning function associated with the player character; and an exit response module, configured to interrupt the movement of the particle effects and restore the normal visual performance of the player character in response to a received mid-game exit command.

[0089] Based on any embodiment of this device, the slide rail performance module includes: a state setting module, configured to set the motion unit to an invincible state during movement and ignore collisions with other game characters; a track switching module, configured to control the motion unit to switch from the current slide rail path to an adjacent parallel slide rail path in response to a track switching command; and a disengagement processing module, configured to control the motion unit to disengage from the slide rail path in response to a mid-way exit command and to achieve an inertial motion effect for the motion unit based on its motion state at the time of disengagement.

[0090] Based on any embodiment of this device, following the mechanism implementation module 3200, this device further includes: an occupancy marking module, configured to mark the state of the scene quick-access mechanism as occupied when a player character is detected to begin executing the passage process visual performance; an exclusion processing module, configured to block the triggering of the first control logic and the second control logic from any other player character when the scene quick-access mechanism is occupied; a cooldown processing module, configured to set the state of the scene quick-access mechanism to a cooldown state and start a timer after the player character finishes the passage process visual performance; and a recovery processing module, configured to restore the state of the scene quick-access mechanism to an interactive state after the timer reaches a preset cooldown duration.

[0091] Another embodiment of this application also provides an electronic device. For example... Figure 6The diagram illustrates the internal structure of an electronic device. This electronic device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. The computer-readable, non-volatile storage medium stores an operating system, a database, and computer-readable instructions. The database can store information sequences, and when executed by the processor, these computer-readable instructions enable the processor to implement a scene access control method.

[0092] The processor of this electronic device provides computing and control capabilities to support the operation of the entire device. The memory of this electronic device can store computer-readable instructions, which, when executed by the processor, cause the processor to perform the scene access control method of this application. The network interface of this electronic device is used for communication with a terminal.

[0093] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0094] In this embodiment, the processor is used to execute... Figure 5 The specific functions of each module are described, and the memory stores the program code and various data required to execute the above modules or sub-modules. The network interface is used to realize data transmission between user terminals or servers. In this embodiment, the non-volatile readable storage medium stores the program code and data required to execute all modules in the scene access control device of this application, and the server can call the server's program code and data to execute the functions of all modules.

[0095] This application also provides a non-volatile readable storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the scene access control method of any embodiment of this application.

[0096] This application also provides a computer program product, including a computer program / instructions that, when executed by one or more processors, implement the steps of the method described in any embodiment of this application.

[0097] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a computer-readable storage medium such as a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM).

Claims

1. A method of controlling passage through a scene, characterized by, The method comprises: monitoring a real-time position of a player character generated in a game scene in real time; when the real-time position reaches a trap loading area in the game scene for the first time, instantiating a trap template class by invoking predefined trap configuration data of the area to obtain a scene speed trap, the scene speed trap being bound to corresponding business logic according to a trap type in the trap configuration data; when the real-time position enters an entry response area set by the scene speed trap loaded in the game scene, running first control logic in the business logic to generate a visual prompt effect in the entry response area; running second control logic in the business logic to control the player character to perform visual performance of a passing process according to the scene speed trap.

2. The method according to claim 1, wherein The method of instantiating a trap template class by invoking predefined trap configuration data of the area to obtain a scene speed trap comprises: reading the trap configuration data, the trap configuration data containing a type identifier for identifying a trap type and layout parameters for defining a spatial position and a spatial form of the scene speed trap in a game scene; according to the type identifier, obtaining a business logic module matched with the trap type from a preset logic library, the business logic module encapsulating the first control logic and the second control logic; according to the layout parameters, generating an instance of the trap template class at a corresponding position in the game scene to load a corresponding scene speed trap, and binding the obtained business logic module to the instance to complete instantiation of the scene speed trap.

3. The method according to claim 1, wherein The method of running first control logic in the business logic to generate a visual prompt effect in the entry response area comprises: determining a target interaction mode corresponding to a current trap type according to the first control logic in the business logic bound to the scene speed trap; activating a visual prompt element matched with the target interaction mode in the entry response area, wherein the visual prompt element is used to indicate to a player that the passing process of the scene speed trap can be triggered by performing the target interaction mode.

4. The method according to claim 1, wherein The method of running second control logic in the business logic to control the player character to perform visual performance of a passing process according to the scene speed trap comprises: determining a passing motion mode corresponding to a current trap type according to the second control logic in the business logic bound to the scene speed trap; when the passing motion mode belongs to a first mode, switching visual performance of the player character to a particle special effect, and driving the particle special effect to implement elevation difference movement along a predefined cableway path; when the passing motion mode belongs to a second mode, locking the player character and an associated vehicle as a same motion unit to a predefined slide rail path, and driving the motion unit to implement lateral movement along the slide rail path.

5. The method according to claim 4, wherein The method of driving the particle special effect to implement elevation difference movement along a predefined cableway path comprises: disabling a teammate switching function associated with the player character; disabling a vehicle summoning function associated with the player character; In response to the received midway exit instruction, interrupt the movement of the particle special effect and restore the normal visual presentation of the player character.

6. The method according to claim 4, wherein Driving the movement unit to implement lateral movement along the slide rail path, including: Setting the state of the movement unit to invincible during its movement and ignoring its collision with other game characters; In response to the track switching instruction, controlling the movement unit to switch from the current slide rail path to an adjacent parallel slide rail path; In response to the midway exit instruction, controlling the movement unit to leave the slide rail path, and realizing inertia movement effect for the movement unit based on the movement state at the time of leaving.

7. The method according to claim 1, wherein After calling the instance of the pre-defined trap configuration data of the area to instantiate the trap template class to obtain the scene speed trap, including: When it is detected that a player character starts to perform the passing process visual presentation, marking the state of the scene speed trap as an occupied state; When the scene speed trap is in the occupied state, shielding the triggering of the first control logic and the second control logic for any other player character; After the player character ends the passing process visual presentation, setting the state of the scene speed trap to a cooling state and starting a timer; When the timer reaches a preset cooling time length, restoring the state of the scene speed trap to an interactive state.

8. A passage control device for a scene, characterized by Including: A position monitoring module configured to monitor the real-time position of a player character generated in a game scene in real time; A trap implementation module configured to, when the real-time position first reaches a trap loading area in the game scene, call the instance of the pre-defined trap configuration data of the area to instantiate the trap template class to obtain a scene speed trap, the scene speed trap corresponding to the trap type in the trap configuration data being bound to corresponding business logic; An entrance presentation module configured to, when the real-time position enters an entrance response area set by the scene speed trap loaded into the game scene, run the first control logic in the business logic to generate visual prompt effects in the entrance response area; A passing presentation module configured to, in response to a player triggered interaction execution event, run the second control logic in the business logic to control the player character to perform a passing process visual presentation corresponding to the scene speed trap.

9. An electronic device comprising a central processing unit and a memory, characterized in that The central processor is configured to call and run a computer program stored in the memory to perform the steps of the method of any one of claims 1 to 7.

10. A non-volatile readable storage medium, characterized by The computer readable instructions store a computer program implemented according to the method of any one of claims 1 to 7, and when the computer program is called and run by a computer, the steps included in the corresponding method are performed.