UI control method and device based on multi-platform game, medium and product
Through component design and Unity InputSystem underlying interface, the UI is dynamically adjusted to adapt to multi-platform games, solving the problem of insufficient support for the keyboard, mouse and controller input architecture of the Unity engine, and achieving efficient cross-platform UI layout management and visual effect consistency.
Patent Information
- Application Number
- CN202510535412.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-27
- Publication Date
- 2025-08-08
AI Technical Summary
In the prior art, the Unity engine has relatively weak support for input architectures such as keyboard, mouse, controller, etc. in multi-platform games, and lacks a higher-level business-oriented input architecture, resulting in high development costs and poor compatibility.
Using component design, the UI is dynamically adjusted to adapt to different platforms through pre-built key input distribution architecture and target components. Combined with the Unity InputSystem underlying interface, a unified input-UI interaction architecture is built to realize cross-platform UI layout management and dynamic regulation.
It improves user interaction experience, reduces development costs, enhances game compatibility and accessibility, and ensures consistency and visual effects of UI layouts on different platforms.
Smart Images

Figure CN120437578A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology, and in particular to a UI control method, device, medium, and product based on multi-platform games. Background Art
[0002] In the field of game development, UI layout and input architecture are key elements in building a high-quality gaming experience.
[0003] However, the inventors found that there are at least the following technical problems in the relevant technology: Although the Unity engine provides tools such as UGUI and UnityInputSystem, in actual applications, especially for long-term service games that support multi-platform login (iOS, Android, PC, PS5) and are compatible with multiple physical devices (touch screen, keyboard and mouse, controller), these tools have certain limitations.
[0004] As the Unity engine's built-in UI system, UGUI excels in UI layout and touchscreen input architecture, providing comprehensive UI layout solutions and a complete touchscreen input architecture. However, due to Unity's early focus on mobile development, its support for keyboard, mouse, and controller input architectures is relatively weak. This not only results in input compatibility issues across various controller models, but also fails to meet the key input distribution requirements in complex business scenarios.
[0005] Unity InputSystem, a new input system launched by Unity, boasts a robust underlying input library that can handle a wide range of inputs from keyboards, mice, controllers, and other external devices across multiple platforms, offering excellent compatibility. However, it is merely a low-level input library and does not provide a higher-level, business-oriented input architecture. In particular, controllers differ significantly from other platforms in their ability to interact with complex spatial sequential navigation, requiring appropriate infrastructure support.
[0006] In terms of development costs, considering that some long-term service games update their versions every once in a while, we hope that the input adaptation work for multiple platforms and multiple devices will be both economical and efficient without bringing too much additional burden to developers.
[0007] In summary, the related technologies have technical problems such as relatively weak support for input architectures such as keyboards, mice, and controllers, lack of provision of higher-level, business-oriented input architectures, and high development costs. Summary of the Invention
[0008] One purpose of this application is to provide a UI control method, device, medium and product based on multi-platform games, at least to solve the technical problems in related technologies that the input architecture support for keyboard, mouse, handle, etc. is relatively weak, there is no higher-level, business-oriented input architecture, and the development cost is relatively high.
[0009] To achieve the above objectives, some embodiments of the present application provide the following aspects:
[0010] In the first aspect, some embodiments of the present application also provide a UI control method based on a multi-platform game, the method comprising: determining a response result based on input information and a pre-built key input distribution architecture; the input information is generated based on the player's interaction with the game through a physical device, and the response result affects changes at the UI level; dynamically adjusting the UI based on the response result and the target component; the target component is used to control the differentiated performance of the UI layout in the game on different platforms.
[0011] In a second aspect, some embodiments of the present application further provide an electronic device comprising: one or more processors; and a memory storing computer program instructions, wherein the computer program instructions, when executed, cause the processor to perform the steps of the method described above.
[0012] In a third aspect, some embodiments of the present application further provide a computer-readable medium having computer program instructions stored thereon, wherein the computer program instructions can be executed by a processor to implement the method described above.
[0013] In a fourth aspect, some embodiments of the present application further provide a computer program product, comprising a computer program / instruction, which implements the steps of the above-described method when executed by a processor.
[0014] Compared with related technologies, the solution provided in the embodiment of the present application adopts a componentized design system. Under this system, step S101 can accurately determine the response result based on the input information generated by the player's interaction with the game through physical devices and the pre-built key input distribution architecture. The UI can change in time accordingly, and the player's operation can get real-time feedback, greatly improving the user interaction experience. Step S102 dynamically adjusts the UI based on the response result and the target component. The target component can accurately adjust the UI layout according to the characteristics of different platforms, greatly enhancing the compatibility and accessibility of the game. The entire componentized design process is closely linked, and components can be developed independently and reused repeatedly, which not only improves development efficiency, but also makes the code structure clear, maintenance and expansion more convenient, and comprehensively optimizes game performance and user experience.
[0015] At the same time, through clever tool infrastructure and workflow planning, UI design and program development work are independent and non-interfering with each other, allowing efficient work to be achieved without the need for developers to carry additional mental burdens. Understandably, UGUI has shortcomings in supporting input architectures such as keyboards, mice, and controllers, making it difficult to meet the key input distribution requirements in complex business scenarios; UnityInputSystem, as a low-level input library, lacks an upper-level business-oriented input architecture. When the target component dynamically adjusts the UI based on the response results, it can not only optimize the UI layout based on the characteristics of input devices on different platforms, making up for the shortcomings of UGUI, but also associate input information with UI layout to build an input-UI interaction architecture that meets business needs and improves the shortcomings of UnityInputSystem. Furthermore, the target component implements unified management and dynamic regulation of UI layouts for different platforms. Developers do not need to repeatedly develop UI layouts. By reusing some logic and flexibly adjusting the UI based on response results, they can reduce development costs and burdens. In addition, the target component ensures that the same UI space presents different scaling, positions, and visibility states on different platforms, showing better visual effects. It also provides UI artists with special tools and processes that are easy to operate. The final output nodes of the logic ends of different platforms are consistent. Program developers do not need to worry about the details of UI art editing, further reducing work pressure. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] One or more embodiments are exemplarily illustrated by pictures in the corresponding drawings. These exemplifications do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements. Unless otherwise stated, the figures in the drawings do not constitute proportional limitations.
[0017] Figure 1 An exemplary flow chart of a UI control method based on a multi-platform game provided in some embodiments of the present application;
[0018] Figure 2 An exemplary structural diagram of an electronic device provided for some embodiments of the present application. DETAILED DESCRIPTION
[0019] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.
[0020] The following terms are used in this document.
[0021] Multiplatform games: These are games that can be played on multiple different device platforms, each with its own varying screen sizes and input hardware.
[0022] UI: Abbreviation for User Interface. It refers to the interface through which users interact with systems, software, devices, and more, encompassing aspects such as the interface's layout, design, interactive elements, and visual effects.
[0023] UI interaction mode: refers to the way users manipulate and interact with game content with the help of physical devices.
[0024] A controller is an external physical device used by users to control electronic game consoles. Users can control characters in the game by clicking buttons on the controller.
[0025] Unity: is a cross-platform game engine.
[0026] Input architecture: This refers to a complete set of infrastructure that encapsulates user input and passes it to the business logic. For example, Unity's official UI system, UGUI, encapsulates a complete input architecture for touch screens.
[0027] UGUI: Unity GUI, is the built-in UI system of Unity engine since version 4.6, mainly used to create user interfaces in games.
[0028] Unity's MonoBehaviour component is the base class for all script components in Unity. Once added to a game object, it provides complete lifecycle control for that game object and provides common interface functions.
[0029] UI hot swapping: refers to the ability to instantly update and replace user interface elements and layouts while the game is running, without having to restart the game client.
[0030] Canvas: It is the root container of the UI and supports three rendering modes: screen space overlay, screen space camera, and world space. These three modes determine how UI elements interact with the scene.
[0031] Component-based design: This refers to providing pre-built components such as Button, Image, Text, and ScrollRect. These components' properties can be quickly configured through the Inspector panel. For example, to set a click event for a button, simply drag and drop a script method to bind it.
[0032] Unity InputSystem: The Unity engine provides a system for processing input. It allows developers to flexibly manage input from various physical devices (such as keyboards, mice, gamepads, touch screens, etc.). This system provides low-level interfaces that developers can use to capture, process, and respond to input events from different devices.
[0033] First embodiment
[0034] The first embodiment of the present application relates to a UI control method based on a multi-platform game. Figure 1 As shown, the method may include the following steps:
[0035] Step S101: Determine a response based on input information and a pre-built key input distribution architecture; the input information is generated based on the player's interaction with the game through a physical device, and the response affects changes at the UI level;
[0036] Step S102: dynamically adjust the UI according to the response result and the target component; the target component is used to control the differentiated performance of the UI layout in the game on different platforms.
[0037] Specifically, regarding step S101, input information typically comes from actions taken by the user when interacting with the game. Common UI interaction modes include touchscreen clicks, keyboard and mouse shortcuts, and gamepad navigation. For example, in a game, a player presses a key on the keyboard, clicks the mouse, touches the screen, and so on. These actions all generate corresponding input information. For example, in a shooting game, if a player presses the "Tab" key on the keyboard, the electrical signal generated by this key operation is captured by the driver of the physical device and converted into input information that the system can recognize.
[0038] The pre-built key input distribution architecture in the game system is used to respond to the input information, analyze and process the input information, and determine the corresponding response result. For example, in a role-playing game, the player presses the attack key, and the system determines the response result of the attack operation based on the character's current status (such as attack power, skill cooling time, etc.) and the rules of the game. It may cause certain damage to the enemy, and the character's skill cooling time starts, etc. Among them, the response result will directly or indirectly affect the changes at the UI level. Continuing with the above-mentioned attack operation as an example, after the attack is successful, the UI interface may display the enemy's blood volume reduction animation, the skill cooling progress bar starts counting down, etc., so that the player can intuitively understand the effect of the operation.
[0039] In game development, step S102 primarily focuses on adjusting the game UI based on the response to input information, ensuring that the UI remains synchronized with the game state. For example, when a player completes a mission, the game responds by granting them new items and experience points. The UI then needs to update the item bar to reflect the new item, while also updating the character's experience points and level.
[0040] Under different platform layouts, the same UI control will have differences in position, scaling, visibility, layout alignment, and some other scattered parameter settings. However, the inventors found that, in fact, under different platforms, only simple Transform and Layout parameters need to be modified to meet the UI editing needs, and the UI hierarchy and UI nodes can be completely consistent on each platform. Therefore, from the perspective of program developers, there is no need to worry about multi-platform layout differences at the logical level (because layout differences are mostly art-related parameters, and the program does not need to pay attention to them), and the same set of program logic can run smoothly on multiple platforms.
[0041] In this embodiment, the target component dynamically adjusts the UI based on the response results. Different platforms (such as PCs, mobile phones, and game consoles) have different screen sizes, input methods, and user operating habits. The target component can automatically adjust the UI layout and display mode based on the current platform. For example, on a mobile phone, due to the smaller screen, UI elements need to be appropriately scaled and rearranged for easier operation; on a PC, more detailed information can be displayed.
[0042] In the specific implementation, component design is carried out based on Unity's MonoBehaviour componentization idea, and a series of target components for multi-platform UI layouts are encapsulated. For example, it can be named MonoUIAdaptor component, which is used to control the differentiated performance of the in-game UI layout on different platforms. The target component supports UI designers to enter different parameter layout information for different UI layout platforms (such as touch screen, keyboard and mouse, and handle) during offline editing, so that different UI layouts can present different visual effects. During the program running stage, after the UI control is created, the system will select the corresponding parameter application based on the current UI layout platform and dynamically modify the UI node layout parameter value.
[0043] The system dynamically adjusts the UI based on the response results and target components. It first determines the UI elements that need to be updated based on the response results, and then uses the target components to adjust the layout and display of these UI elements according to the characteristics of the current platform, ensuring that players have a good visual and operational experience on different platforms.
[0044] Understandably, many games available on both PC and console platforms often adapt the keyboard, mouse, and controller to the same UI layout by simply modifying button prompts to ensure consistent logic and performance across multiple platforms. However, this approach presents problems: First, the interaction modes of the keyboard, mouse, and controller are not completely equivalent. The keyboard and mouse enable quick, full-screen interaction with mouse clicks, where what you see is what you click; the controller requires sequential spatial navigation through "up, down, left, right, and enter / return" buttons. Forcing these two different interaction modes into the same layout results in performance coupling, preventing the layout from achieving optimal usability. Second, in addition to the keyboard, mouse, and controller layout, games also have a "touchscreen" layout for mobile devices. Given the smaller screens on mobile devices, UI controls need to be appropriately scaled and repositioned, making it impossible to simply copy the keyboard, mouse, and controller layout.
[0045] It is not difficult to find that compared with related technologies, the componentized design system is adopted. Under this system, step S101 can accurately determine the response result based on the input information generated by the player's interaction with the game through physical devices and the pre-built key input distribution architecture. The UI can change in time accordingly, and the player's operation can get real-time feedback, greatly improving the user interaction experience. Step S102 dynamically adjusts the UI based on the response result and the target component. The target component can accurately adjust the UI layout according to the characteristics of different platforms, greatly enhancing the compatibility and accessibility of the game. The entire componentized design process is closely linked, and components can be developed independently and reused repeatedly, which not only improves development efficiency, but also makes the code structure clear, maintenance and expansion more convenient, and comprehensively optimizes game performance and user experience.
[0046] At the same time, in this embodiment, UI design and program development work are independent of each other and do not interfere with each other, efficient work can be achieved, and developers do not need to bear additional mental burdens. It is understandable that UGUI has shortcomings in supporting input architectures such as keyboards, mice, and handles, and it is difficult to meet the key input distribution requirements in complex business scenarios; UnityInputSystem, as the underlying input library, lacks an upper-level business-oriented input architecture. When the target component dynamically adjusts the UI in accordance with the response results, it can not only optimize the UI layout according to the characteristics of the input devices on different platforms to make up for the shortcomings of UGUI, but also associate input information with UI layout to build an input-UI interaction architecture that meets business needs and improve the shortcomings of UnityInputSystem. In addition, the target component realizes unified management and dynamic regulation of UI layouts on different platforms. Developers do not need to repeatedly develop UI layouts. By reusing part of the logic and flexibly adjusting the UI according to the response results, the development cost and burden are reduced. In addition, the target component ensures that the same UI space presents different scaling, positions, and visibility states on different platforms, showing better visual effects. It also provides UI artists with special tools and processes that are easy to operate. The final output nodes of the logic ends of different platforms are consistent. Program developers do not need to worry about the details of UI art editing, further reducing work pressure.
[0047] Second embodiment
[0048] The second embodiment of the present application relates to a UI control method based on a multi-platform game. The second embodiment is an improvement on the first embodiment, and the specific improvement is that: in this embodiment, a method for creating the key input distribution architecture is provided.
[0049] Optionally, in some embodiments, the key input distribution architecture is derived from the underlying interface of the Unity InputSystem. By cleverly building a key input distribution architecture based on the underlying interface of the Unity InputSystem and determining response results based on this architecture and input information, multiple beneficial effects are achieved. For example, in terms of compatibility, the Unity InputSystem itself supports a variety of input devices, such as keyboards, mice, and gamepads. Leveraging its underlying interface, the architecture enables games to easily adapt to different input devices, allowing players to operate smoothly regardless of their device. In terms of development efficiency, the Unity InputSystem provides a rich set of standardized interfaces and tools that developers can quickly build upon, reducing the workload and time cost of writing their own underlying code. Response results are more accurate and stable because the Unity InputSystem has a well-developed optimization and management mechanism for input event processing, effectively avoiding issues such as input delays and misjudgments, thereby providing players with a smoother and more accurate operational experience. Furthermore, this architecture facilitates subsequent functional expansion and maintenance. When new input methods or response logic need to be added, developers can modify and expand the existing architecture without significantly impacting the entire system.
[0050] In short, in this embodiment, based on the underlying interface of UnityInputSystem, a complete key input distribution architecture is encapsulated at the business layer. The input timing of multiple platforms (covering iOS, Android, PC, PS5) and multiple key physical devices (including keyboards, mice, and handles) is unified, ensuring the consistency of input logic across platforms and devices. At the same time, the timing of the entire input architecture, as well as the subsequent skill systems and animation systems related to the input architecture, are sorted out to ensure that the data generated by all platforms can be transmitted to the game logic with extremely low latency, effectively ensuring the immediacy of the player's operation feel, and making the player's operation almost synchronized with the game feedback.
[0051] Optionally, the method for creating the key input distribution architecture may include the following steps:
[0052] Step S201: creating a data structure; the data structure is used to determine target input information having a preset standard format based on the input information;
[0053] Step S202 , determining a callback response mechanism; the callback response mechanism is used to characterize how to send the target input information to a corresponding processing module; the processing module is a functional unit responsible for performing specific processing on the target input information.
[0054] Based on this, the step S101 of determining the response result according to the input information and the pre-built key input distribution architecture may include the following steps:
[0055] Step S1011, determining target input information according to the data structure and the input information;
[0056] Step S1012: sending the target input information to a corresponding processing module according to the callback response mechanism;
[0057] Step S1013: Determine the response result according to the target input information and the processing module.
[0058] Regarding step S201, specifically, and illustratively, the underlying interface of the Unity InputSystem can be encapsulated first. It is understood that the Unity InputSystem provides a rich set of underlying interfaces for the game to receive input from various physical devices (such as keyboards, mice, controllers, etc.), but these interfaces are relatively scattered and complex to use directly. In this step, these interfaces are integrated and simplified through encapsulation to better meet business logic requirements.
[0059] For example, a unified data structure can be created. The data structure is intended to describe and store input information from different physical devices (such as keyboards, mice, handles, etc.) and different types (key press, release, long press, etc.) in a unified and standardized manner. For example, a data structure called "InputData" can be designed, which contains a data structure with fields such as device type (using enumeration values to distinguish keyboards, mice, handles, etc.), key identifiers (specific key names or codes), input states (status identifiers such as press, release, long press, etc.) and timestamps, to ensure that all input information can be standardized according to the data structure, laying the foundation for subsequent input processing.
[0060] Through this step, the input information can be completely encapsulated in the data structure, providing a standard carrier for the subsequent transmission of the input information between different parts of the system.
[0061] For step S202, specifically, an overall architecture can be built first to coordinate the processing of input information by various parts in the system. At the same time, determine the callback response mechanism, that is, how to transfer the target input information from the input source to different processing modules. Here, the construction of an overall architecture to coordinate the processing of input information by various parts in the system can be implemented using traditional related technologies and is not the focus of this application. The processing module is a functional unit responsible for the specific processing of input information. For example, in a game, there are modules that control character movement, modules that handle UI interface interactions, modules that execute skill release logic, and so on. Each processing module has specific tasks and needs to perform corresponding operations based on the input information.
[0062] Exemplarily, when the physical device receives input information, the key input distribution architecture can first encapsulate and organize the input information through the data structure. Then, according to the callback response mechanism, the target input information is sent to the corresponding processing module, such as a UI control or a business logic module. For example, in a game, when a player presses a key on the keyboard, the system can first convert the input information into target input information with a preset standard format, and then determine whether the function associated with the key is business logic such as controlling character movement, or a control operation such as clicking a UI button, and then send the target input information to the corresponding processing module to trigger the corresponding processing flow of the processing module.
[0063] Optionally, after determining the callback response mechanism, the method for creating the key input distribution architecture also includes: step S203, determining the time interval and order of each frame processing of the processing module; correspondingly, determining the response result based on the target input information and the processing module includes: determining the response result based on the target input information and the time interval and order of each frame processing of the processing module.
[0064] Regarding step S203 , specifically, in order to ensure that input can be processed according to expected order and rules in complex input scenarios, it is necessary to set the time interval and order of each frame processed by the processing module.
[0065] Specifically, setting the frame processing interval ensures the system operates at a stable rhythm. If the interval is unstable, certain processing modules may be executed too frequently or too sparsely, affecting the performance and responsiveness of the entire system. For example, in a game, if the processing interval of the module controlling character movement is too short, the character's movement may be too abrupt and unnatural; if the interval is too long, the player will experience noticeable delays in the operation, affecting the gaming experience.
[0066] In practical applications, the time interval setting can be determined by taking into account a variety of factors. For one thing, hardware performance limitations can be considered, such as the computer's CPU and GPU processing power. If hardware performance is low, setting an overly short time interval may cause system overload and lag. On the other hand, the time interval can be determined based on the needs of the application. For example, for applications with high real-time requirements (such as competitive games), a relatively short time interval can be set to achieve a fast response. For applications with less demanding real-time requirements (such as simple casual games), the time interval can be appropriately extended to conserve resources.
[0067] Specifically, there may be dependencies between different processing modules, that is, the processing results of one processing module may affect the operation of other processing modules. Therefore, it is necessary to reasonably set the processing order of the processing modules. For example, in a game, you can first process the input information received by the physical device, determine the target input information, and then update the character's status (such as position, speed, etc.) according to the target input information, and finally update the game screen according to the character status. If the processing order is reversed, it may cause the screen display to be inconsistent with the actual operation, resulting in logical errors.
[0068] In some embodiments, the processing order can be determined by analyzing the logical relationships between the various processing modules. Processing modules with clear dependencies can be processed in the order of their dependencies. Processing modules without direct dependencies can be arranged in a different order based on performance optimization needs. For example, processing modules with larger computational loads can be processed later to avoid impacting the timely response of other processing modules.
[0069] In this step, by setting the time interval and order for each frame of processing by the processing module, the key input distribution architecture can be made more complete and stable. This step ensures that after receiving the target input information, each processing module can process it according to the predetermined rhythm and order, thereby achieving accurate distribution and effective processing of the input information. Those skilled in the art will understand that a key input distribution architecture with a properly set time interval and processing order can improve the overall performance of the system and user experience, ensuring that the system can operate stably and efficiently under various circumstances.
[0070] It is not difficult to see that the embodiment of this application provides a method for creating the key input distribution architecture. By creating a standardized data structure and an efficient callback response mechanism, the key input distribution architecture provided by this embodiment can not only improve the performance and stability of the system, but also enhance the scalability and maintainability of the system. It can achieve the goal of providing users with a smooth and natural interactive experience while reducing development and maintenance costs.
[0071] Third embodiment
[0072] The third embodiment of the present application relates to a UI control method based on a multi-platform game. The third embodiment is an improvement on the second embodiment, and the specific improvement is that: in this embodiment, a method for determining a data structure is provided.
[0073] Optionally, in some embodiments, the method for determining the data structure may include: determining the data structure based on UnityInputSystem; and establishing a mapping relationship between the input information and logical events required by the business logic through the data structure.
[0074] Specifically, through the data structure, a mapping relationship can be established between the underlying physical device input of UnityInputSystem and the logical events required by the upper-level business logic. Among them, in game development, the logical events required for business logic refer to those abstract events that are closely related to the core gameplay, functions and processes of the game. For example, logical events related to character control (such as "character movement", "character jump", "character attack", etc.), logical events related to game process control (such as "game start", "game pause", "game end", etc.), and logical events related to interaction (such as "dialogue with NPC", "pick up items", "open treasure chest", etc.).
[0075] For example, in a game, players can control the character's movement and jumping using the keyboard or controller. By defining a data structure, the input information (keyboard, controller, etc.) of the physical device (keyboard, controller) is mapped to the logical events (character movement, jumping, etc.) required by the business logic.
[0076] Optionally, in some embodiments, determining the data structure based on UnityInputSystem may include:
[0077] Based on the underlying library of the UnityInputSystem, physical events, action events, and logical events with independent structures are defined; the physical events, the action events, and the logical events form the data structure;
[0078] The physical event is used to obtain input information based on the physical device according to the underlying library;
[0079] The action event is used to describe the triggering method of the physical event;
[0080] The logic event is used to determine the event type sent to the business logic processing based on the action event.
[0081] For example, a data structure named ZZZInputEvent can be defined to determine target input information with a preset standard format based on the input information. The data structure may include the following fields:
[0082] The physical event (PhysicalEvent) is used to obtain input information based on the physical device according to the encapsulated underlying library of the Unity InputSystem.
[0083] The ActionEvent is an encapsulation of a physical event, used to describe how the physical event is triggered. For example, it can be triggered when a key is pressed, when a key is long pressed, or at intervals while a key is long pressed. As can be seen, the ActionEvent adds a time dimension and triggering condition to the input behavior. For example, in a game scene that requires continuous operation, the player can press and hold a key to make the character run continuously. The ActionEvent can describe this long-press-triggered behavior.
[0084] The logic event (LogicEvent) is associated with the action event, and when the action event meets the triggering condition, the event type passed to the logic business layer is determined. In this way, the business layer developer does not need to care whether the player uses the "A" key on the keyboard or a button on the handle to trigger the "move left" operation, but only needs to pay attention to the corresponding logic event. For example, in a role-playing game, no matter what device button the player uses to trigger the "release skill" operation, the business layer only needs to write the corresponding skill release logic for the "release skill" logic event. That is to say, according to the data structure provided by this embodiment, the business layer developer only needs to pay attention to the logic event, that is, the final event triggered by a specific key behavior, without worrying about which platform or which button triggered it. Therefore, the purpose of improving development efficiency can be achieved.
[0085] This design makes the above three layers (physical events, action events and logical events) independent of each other and uncoupled.
[0086] Optionally, in some embodiments, the physical event includes several subfields, each corresponding to a key input of a different physical device.
[0087] Optionally, in some embodiments, the number of the subfields is three, and the three subfields correspond to mouse-based key input events, keyboard-based key input events, and handle-based key input events, respectively.
[0088] Mouse-based key input events (MouseEvent), keyboard-based key input events (KeyboardEvent), and gamepad-based key input events (GamepadEvent) can all be directly connected to the underlying library enumeration classes in UnityInputSystem. This allows accurate access to the input status of the left and right mouse buttons, keyboard keys, and gamepad buttons. For example, in a shooting game, you can use MouseEvent to obtain mouse click input and determine whether the player has pressed the shooting button.
[0089] In actual games, in order to meet the operating habits of different players, you may need to set multiple keys to trigger the same logical event. For this case, you can configure multiple groups of ZZZInputEvent data structure instances to make different action events correspond to the same logical event, thereby achieving flexible key mapping. For example, you can use the "Space" key on the keyboard or a specific button on the controller to make the character jump. By configuring multiple groups of ZZZInputEvent, different action events (corresponding to the pressing of different keys) all point to the "jump" logical event, easily achieving multiple keys triggering the same function.
[0090] If a game needs to support key-changing functionality, since the structures of physical events, action events, and logical events are independent of each other, developers only need to modify the mapping relationship between different underlying device enumeration classes in the physical events, without having to change the configuration of action events and logical events, thus reducing the complexity of implementing key-changing functionality. For example, players are accustomed to using the "Up" key to control a character moving forward instead of the "W" key. Developers only need to modify the mapping relationship of the keyboard key enumeration class in the physical event, associating the "Up" key with the action event originally corresponding to the "W" key. The configuration of the action events and logical events does not need to be changed to complete the key-changing functionality, ensuring the stability and maintainability of the system.
[0091] It should be noted that this embodiment may also be an improvement based on the first embodiment.
[0092] It is not difficult to find that in the embodiment of the present application, a method for determining a data structure is provided. Through this method, based on the idea of layered design, a mapping relationship between the input of the physical device of the UnityInputSystem and the logical events required by the business logic can be established, which can make the system more flexible and scalable.
[0093] Fourth embodiment
[0094] The fourth embodiment of the present application relates to a UI control method based on a multi-platform game. The fourth embodiment is an improvement on the second embodiment, and the specific improvement is that: in this embodiment, a method for determining a callback response mechanism is provided.
[0095] Optionally, in some embodiments, the method for determining the callback response mechanism may include the following steps:
[0096] Step S401, determining a UI framework; the UI framework includes a fundamental base class of a UI control and a subclass of the fundamental base class; the subclass is used to identify a root node at the most basic level in the UI interface;
[0097] Step S402: Determine a callback response mechanism based on the UI framework and the data structure.
[0098] For example, the fundamental base class is UIBaseController, which is the fundamental base class for all UI controls and the smallest unit for processing input logic callbacks. All UIBaseControllers can have a common base class virtual function, such as bool OnInputAction(ZZZInputEvent inputEvent), which is specifically used to process input. In addition, UIBaseController can have the ability to create child UIBaseControllers. Once a child UIBaseController is created, the creator and the created child object form a tree-like parent-child relationship.
[0099] Exemplarily, the subclass of the fundamental base class takes RootLayerController as an example. The RootLayerController is a subclass based on UIBaseController, which is used to identify the root node of the most basic level in the UI interface. The UI interface in this embodiment can be a bottom page or a pop-up dialog box with complete functions. In the game, there may be multiple bottom pages and pop-up dialog boxes at the same time, which means that there can be multiple RootLayerControllers, which can be presented in a stacked form. RootLayerController is the smallest unit for input message distribution, and only the RootLayerController at the top can receive input information.
[0100] The entire UI framework presents a tree-like forest structure. For example, the UI framework's "forest" contains multiple "trees," each representing a UI interface's base page or pop-up dialog box. The root node of each "tree" is the RootLayerController, and the child nodes of each "tree" are UIBaseControllers.
[0101] Optionally, in some embodiments, sending the target input information to a corresponding processing module according to the callback response mechanism, that is, step S1012 may include the following steps:
[0102] Step S10121: determining a subclass at the top of the hierarchical structure in the UI framework, wherein the subclass is used to distribute target input information of the current frame, and the subclass is configured with a list for monitoring input events;
[0103] Step S10122: Send the target input information to a corresponding processing module according to the list and the data structure.
[0104] For example, taking the RootLayerController as an example, the RootLayerController currently at the top of the UI frame can be selected. The RootLayerController is used to distribute the target input information of the current frame. In the RootLayerController, a list named ListenInputEventList can be defined. This list can be configured by the designer and contains all the input information that needs to be monitored.
[0105] Furthermore, the input manager can traverse the list ListenInputEventList to determine whether each data structure ZZZInputEvent has target input information in this frame. If so, the input signal is sent to the corresponding subclass RootLayerController.
[0106] Furthermore, the subclass RootLayerController may send the input signal of the data structure ZZZInputEvent to each sub-root base class UIBaseController one by one through subsequent traversal according to the UI tree structure maintained by itself.
[0107] It can be found that in this embodiment, the ListenInputEventList list in the RootLayerController is used to determine which inputs need to be listened to at the current moment.
[0108] Optionally, in some embodiments, sending the target input information to a corresponding processing module according to the list and the data structure may include:
[0109] The target input information is sent to a corresponding processing module based on the list, the data structure, and a preset priority rule. The priority rule is as follows: within the entire class system, the later the base class is created, the higher its corresponding input response priority; and within the hierarchical structure of the UI framework, the closer a subclass is to the top level, the lower its input response priority.
[0110] That is, during the distribution process, the target input information may be sent to the corresponding processing module according to the list, the data structure and the preset priority rule.
[0111] For example, the priority rule can be: the later the root base class UIBaseController is created, the higher the priority of the input response; the top-level subclass RootLayerController has the lowest priority. According to this rule, when distributing input information, the logic callback of the UIBaseController with the highest priority will be triggered first.
[0112] For example, consider a role-playing game whose UI framework consists of multiple layers and distinct classes. There are various UI panels, such as the main menu panel, character information panel, and skill shortcut panel. Each panel has one or more subclasses that handle the relevant UI logic and input events. Furthermore, there are base classes that serve as superclasses for these subclasses and define common behaviors and properties.
[0113] Assume that the root base classes include: root base class 1, the earliest created root base class, which defines the basic properties and methods of the subclass UI that determines the top position of the hierarchical structure in the UI framework; root base class 2: the root base class created later, inherited from root base class 1, and added functions related to user interaction; root base class 3, the latest created root base class, inherited from the subclass root base class 2 that determines the top position of the hierarchical structure in the UI framework, and provides more advanced interaction features.
[0114] The subclasses (UI panels) include: subclass 1 at the top of the UI framework, which is located at the top of the hierarchical structure and is used to display the main menu options; subclass 2 at the middle level, which displays the character's detailed information; and subclass 3 at the bottom level, which displays the character's skill shortcut bar.
[0115] Each subclass is configured with a list for listening to input events. For example, subclass 1 listens to list 1, subclass 2 listens to list 2, and subclass 3 listens to list 3. The data structure is used to store the mapping between input events and corresponding processing modules.
[0116] Assume that the current player presses the "Enter" key (input information) on the keyboard to obtain the target input information, then:
[0117] In terms of root base class priority, root base class 3 is the last created root base class, so its subclasses will have the highest input response priority if they listen to the "Enter" event of the subclass that determines the top of the UI framework's hierarchy. If subclass 3 inherits from root base class 3 and listens to the "Enter" event of the subclass that determines the top of the UI framework's hierarchy, it will prioritize processing that input.
[0118] In terms of subclass hierarchy priority, subclass 1 is at the top layer, subclass 2 is at the middle layer, and subclass 3 is at the bottom layer. According to the rule that "the higher the subclass is at the top, the lower the priority of the input response" for determining the subclass at the top of the hierarchy in the UI framework, even if subclass 1 listens to the event of the subclass "Enter" that determines the subclass at the top of the hierarchy in the UI framework, it will only process the event when other lower-level subclasses do not process the event. Since other subclasses do not listen to the event of the subclass "Enter" that determines the subclass at the top of the hierarchy in the UI framework, subclass 1 will eventually send the input information of the subclass "Enter" that determines the subclass at the top of the hierarchy in the UI framework to the corresponding processing module to determine the subclass at the top of the hierarchy in the UI framework.
[0119] Furthermore, when the root base class UIBaseController obtains an input response, its OnInputAction method can be called to process the corresponding input business logic. That is to say, in this embodiment, the OnInputAction method is encapsulated as an interface. When the root base class UIBaseControlle obtains an input response, this method is called to process the input business logic, and its Boolean return value determines whether the input information continues to be distributed downward. Specifically, OnInputAction has a Boolean return value. If it returns true, it means that the input information InputEvent has been processed by the corresponding root base class UIBaseController and does not need to be distributed downward. The distribution traversal process stops here; if it returns false, it will continue to look for the next root base class UIBaseController for distribution.
[0120] It should be noted that this embodiment may also be an improvement based on the first embodiment and / or the third embodiment.
[0121] It's easy to see that the embodiments of this application provide a specific implementation method for sending the target input information output by a data structure to the corresponding UI control, thereby triggering its logical callback. By defining a UI framework that includes the fundamental base class of the UI control and its subclasses that identify the root node at the most basic level of the UI interface, a clear architectural foundation is established and scalability is improved. By determining the callback response mechanism based on the UI framework and data structure, precise input processing is achieved, interactivity and user experience are enhanced, and code maintenance and debugging are facilitated.
[0122] Fifth embodiment
[0123] The fifth embodiment of the present application relates to a UI control method based on a multi-platform game. The fifth embodiment is an improvement on the second embodiment. The specific improvement is that: in this embodiment, a specific implementation method for determining the response result based on the target input information and the processing module is provided.
[0124] Optionally, determining the response result according to the target input information and the processing module may include the following steps:
[0125] Step S10131, setting the update logic to the earliest execution position in the game engine's frame update process;
[0126] Step S10132: Determine the response result based on the update logic, the target input information and the processing module.
[0127] For example, the entire input sequence can be organized as follows:
[0128] To ensure that the existing input architecture (such as UGUI) and the key input architecture based on InputSystem encapsulation in this application are consistent in timing, in this embodiment, the update logic of both architectures is placed at the beginning of the game engine's frame update process. That is, when the game starts to update the logic at each frame, the first content processed is the input information. Afterwards, in the subsequent update process of this frame, subsequent logic such as the skill system and gameplay business will be processed based on the input information obtained in this frame.
[0129] For example, in a 2D horizontal scrolling game, the player controls a character to move around the level, attack, and dodge enemies. The existing UGUI input architecture in the game handles interface interactions, while the key input architecture encapsulated by InputSystem handles character movement and combat operations.
[0130] In the frame update process, at the beginning of the logic update of each frame of the game, the game will first process the input information. UGUI input architecture: Suppose there is a pause button on the game interface, and the player clicks this button in a certain frame. The UGUI input architecture will detect this click operation at the beginning of this frame update process. After detecting the click, it will record the input information and prepare for subsequent processing. Key input architecture based on InputSystem encapsulation: In this frame, the player presses the "right arrow" key on the keyboard to control the character to move to the right, and presses the "Z" key to attack. This key input architecture will detect these key operations at the same time and organize the input information.
[0131] Furthermore, after processing the input information, subsequent updates to the game frame will perform various logical processing based on this input information. For example, if the player presses the "Z" key to attack, the skill system will trigger the character's attack skill based on this input information. The skill system will also handle logic such as the skill cooldown time. If the player presses the "right arrow" key to control the character to move right, the gameplay service will update the character's position in the game scene based on this input information, adjusting the character's coordinates on the level map to move the character right on the screen.
[0132] Through the above method, whether it is the interface interaction handled by the UGUI input architecture or the character operation handled by the key input architecture based on InputSystem encapsulation, the input information can be uniformly processed at the beginning of each frame, ensuring the timing consistency of the two architectures, allowing the game to run smoothly and orderly.
[0133] It should be noted that this embodiment may also be an improvement based on any one or more of the first embodiment, the third embodiment, and the fourth embodiment.
[0134] It is not difficult to find that in the embodiment of the present application, the update logic is set at the earliest execution position in the update process of each frame of the game engine, and then the response result to the input information is determined based on the update logic, the target input information and the time interval and order of each frame processing of the processing module. This can achieve consistency in the input timing of InputSystem and UGUI, ensure that the input content can act on the current frame logic without delay, and be reflected on the game screen, thereby ensuring instant response of the game operation feel.
[0135] Sixth embodiment
[0136] The sixth embodiment of the present application relates to a UI control method based on a multi-platform game. The sixth embodiment is an improvement on the first embodiment, and the specific improvement is that: in this embodiment, a method for determining a target component is provided.
[0137] Optionally, in some embodiments, dynamically adjusting the UI according to the response result and the target component may specifically include: adjusting the layout parameters of the UI elements according to the type of the platform, the response result and the target component to achieve dynamic adjustment of the UI.
[0138] Exemplarily, the type of the platform may include but is not limited to: any one of iOS, Android, PC, PS5, and XBOX.
[0139] Exemplarily, the layout parameters may include but are not limited to at least one of the following: position, size, scaling ratio, visibility status, and layout mode.
[0140] Those skilled in the art can understand that in game development, the same UI control will show differences in position, scaling, visibility, alignment and other miscellaneous parameters under different platform layouts. The inventors have analyzed and found that: the multi-platform UI layout requirements may seem complex, but in fact, only simple transformations and layout parameters need to be adjusted to achieve differentiation of UI visual effects, and the UI hierarchy and nodes can remain consistent across platforms. This feature can bring significant advantages to development: for program developers, UI layout differences essentially belong to the category of art parameters, and there is no need to pay attention to the logic segments. The same set of logic can run smoothly on different platforms; through reasonable tool infrastructure and workflow, the UI and program modifications are isolated, making the two independent and uncoupled from each other, greatly improving development efficiency and reducing the workload of developers.
[0141] Based on the above analysis, in this embodiment, a target component is designed. UI designers can use the target component to enter differentiated parameter layout information for different UI layout platforms such as touch screen, keyboard and mouse, and handle during the offline editing stage, giving each platform UI a unique performance effect. Moreover, when the program is running, when the UI control is instantiated, the system can automatically select and apply the parameters of the corresponding platform according to the current UI layout platform, dynamically modify the layout parameter values of the UI nodes, and realize adaptive presentation of the UI on different platforms.
[0142] Optionally, the method for determining the target component may include the following steps:
[0143] Step S501, creating various subclasses inherited from a base class; the target base class is used to provide a virtual function interface, and the virtual function interface is used to be triggered when a preset condition is met;
[0144] Step S502: According to the subclass, the UGUI component function is replaced to obtain the target component.
[0145] Exemplarily, through step S501, a basic framework can be built for subsequent functional implementations. The target base class and its virtual function interface are the core basic parts of the entire system, providing a reusable and extensible functional foundation for subclasses.
[0146] For example, in step S502, it is clarified that each subclass is used to replace the functionality of a specific UGUI component. That is, each subclass is used to replace the functionality of a UGUI component. The subclass is generated based on the inheritance of the target base class in step S501. After inheriting the target base class, the subclass not only obtains the virtual function interface and other features provided by the target base class, but also can implement and customize the specific UGUI component functionality based on this.
[0147] That is to say, the subclass inherits the target base class and uses the virtual function interface and other properties of the target base class to replace the UGUI component function. When the preset conditions are met, the subclass can be triggered through the virtual function interface inherited from the target base class to perform operations related to the replacement of the UGUI component function, thereby replacing and expanding the function of the UGUI component. Exemplarily, the target components can all inherit from the base class MonoUIAdaptorBase.
[0148] Optionally, in some embodiments, the preset condition is at least one of the following: when the UI control is initialized and created, or when the UI layout in the game changes.
[0149] Optionally, in some embodiments, the replacing of the UGUI component function according to the subclass to obtain the target component, that is, step S502 may include the following steps:
[0150] Step S5021: Construct a dictionary data structure in each subclass; the dictionary data structure is used to store information related to multiple platforms;
[0151] Step S5022, determining the layout setting method of the base class in the subclass;
[0152] Step S5023: According to the dictionary data structure and the layout setting method, the UGUI component function is replaced to obtain the target component.
[0153] Exemplarily, a dictionary data structure (Dictionary) is created in each subclass. The function of this dictionary data structure is to store information related to multiple platforms. Exemplarily, the information related to multiple platforms may include, but is not limited to: layout parameters of UI components on different platforms, such as the position, size ratio, and other different layout settings of a button on the screen on a mobile platform and a PC platform; and display styles, such as the font, color, and background style of text on different platforms.
[0154] For example, a subclass needs to implement the base class's SetLayout method. The key to implementing this method is to determine how to apply the relevant parameters based on the platform's override data (OverrideData) at runtime. First, the override data must be parsed, and then, based on the parsed information, the UI component's layout parameters, such as position and size, and style parameters, such as color and transparency, must be set accordingly.
[0155] In the actual game scenario, once the corresponding UI component of the subclass is created, or when it needs to be updated later, the SetLayout method is called. At this time, the method will apply the relevant parameters based on the OverrideData of the current platform to complete the adjustment of the UI component. After the adjustment is completed, the application effect will be checked to confirm that the multi-platform information is correctly presented in the UI component. This ensures that the desired multi-platform adaptation effect is achieved and provides players with a good visual and operational experience on different platforms.
[0156] Optionally, in some embodiments, constructing a dictionary data structure in each subclass, that is, step S5021, may include the following steps:
[0157] Step S50211, determining the dictionary key in the dictionary data structure; the key corresponds to the enumeration class of the UI layout platform.
[0158] Step S50212, determining the value of the dictionary in the dictionary data structure; the value corresponds to the coverage data of multiple platforms.
[0159] For example, the dictionary key is an enumeration class corresponding to the UI layout platform, named "corresponding Layout". Through this enumeration class, different UI layout platforms can be clearly distinguished, such as touch screen, keyboard and mouse, gamepad, etc.
[0160] For example, the dictionary value is "Corresponding Multi-Platform OverrideData". This data needs to be designed individually for each subclass, and its content depends on the parameters of the UGUI components that the subclass overrides. Since each subclass replaces different UGUI components and needs to override different component parameters, the design of the corresponding multi-platform OverrideData will also vary.
[0161] Take the Transform function as an example:
[0162] In UGUI, the position and size parameters are controlled by the RectTransform component.
[0163] In the multi-platform architecture of this application, the MonoUIAdaptorTransform component based on the MonoUIAdaptorBase base class is used.
[0164] You can configure different RectTransform parameters for multiple platforms in the MonoUIAdaptorTransform Dictionary, where the Value type is OverrideRectTransformData.
[0165] In MonoUIAdaptorTransform, you need to implement the SetLayout method and apply OverrideRectTransformData to the modification of the RectTransform parameters.
[0166] Other UGUI components: For other UGUI components, such as LayoutGroup, etc., multi-platform parameter coverage is also supported by creating corresponding MonoUIAdaptor subclasses.
[0167] It should be noted that this embodiment may also be an improvement based on any one or more of the first to fifth embodiments.
[0168] It is not difficult to find that in the embodiment of the present application, a method for determining a target component is provided. The logic of multi-platform layout switching is implemented at the bottom layer by a unified target component, rather than writing adaptation code separately in the business logic. Therefore, the present application can achieve hot switching of layouts during UI runtime at a very low cost. Specifically:
[0169] 1. When the layout needs to be switched, just call the SetLayout interface in all MonoUILayoutAdaptor and the system will automatically refresh the parameters of the new layout.
[0170] 2. Since the program logic remains consistent under different layouts, no additional work is required for program development, and the UI layout and program logic are completely decoupled.
[0171] The step division of the above various methods is only for the purpose of clear description. During implementation, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application; adding insignificant modifications or introducing insignificant designs to the algorithm or process without changing the core design of the algorithm and process are all within the scope of protection of this application.
[0172] In addition, some embodiments of the present application further provide an electronic device. The electronic device may be various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device may also be various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices.
[0173] The electronic device includes: one or more processors; and a memory storing computer program instructions, wherein the computer program instructions, when executed, enable the processor to perform the steps of the method provided in any one or more of the above embodiments. Figure 2 An exemplary structural diagram of the electronic device is disclosed. The electronic device includes: one or more processors 1101, a memory 1102, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations. Among them, the components shown in this article, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or required herein.
[0174] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, the memory 1102, the input device 1103 and the output device 1104 may be connected via a bus or other means, with the bus connection being used as an example in the figure.
[0175] The input device 1103 can receive input digital or character information and generate key signal input related to user settings and function control of the electronic device, such as input devices such as a touch screen, a keypad, a mouse, a trackpad, a touch pad, an indicator stick, one or more mouse buttons, a trackball, and a joystick. The output device 1104 may include a display device, an auxiliary lighting device (e.g., an LED), and a tactile feedback device (e.g., a vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.
[0176] To provide interaction with a user, the electronic device may be a computer. The computer may include a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user, and a keyboard and pointing device (e.g., a mouse) through which the user can provide input to the computer. Other types of devices may also be used to provide interaction with the user. For example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback), and input from the user may be received in any form (e.g., voice input or tactile input).
[0177] In the embodiments of the present application, a computer program / instruction is stored on a computer-readable medium. When executed by a processor, the computer program / instruction implements the steps of the method provided in any one or more of the above embodiments. The computer-readable medium may be included in the electronic device described in the above embodiments, or it may exist independently and not be incorporated into the device. The computer-readable medium carries one or more computer-readable instructions.
[0178] The memory 1102 can be used as a non-transitory computer-readable storage medium to store non-transitory software programs, non-transitory computer executable programs, and modules. The processor 1101 executes the non-transitory software programs, instructions, and modules stored in the memory 1102 to execute various functional applications and data processing of the server, thereby implementing the program instructions / modules corresponding to the method provided in any one or more of the above embodiments of the present application.
[0179] The memory 1102 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device, etc. In addition, the memory 1102 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 1102 may optionally include a memory remotely located relative to the processor 1101, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.
[0180] It should be noted that the computer-readable medium described in this application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above. Computer-readable media may be, for example, but not limited to: electrical, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or components, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, an optical fiber, a portable compact disk read-only memory, an optical storage device, a magnetic storage device, or any suitable combination of the above. In this application, a computer-readable medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or device.
[0181] Computer-readable media includes both permanent and non-permanent, removable and non-removable media, and can be implemented using any method or technology for information storage. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technology, compact discs, digital versatile discs or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device.
[0182] Computer program code for performing the operations of the present application can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as C or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network or a wide area network, or can be connected to an external computer (e.g., through the Internet using an Internet service provider).
[0183] In the above-described embodiment, can realize wholly or in part by software, hardware, firmware or its arbitrary combination.For example, can adopt application-specific integrated circuit, general-purpose computer or any other similar hardware device to realize.In certain embodiments, the software program of the present application can be carried out to realize above steps or function by processor.Similarly, the software program of the present application (comprising relevant data structure) can be stored in computer-readable recording medium, for example, RAM memory, magnetic or optical drive or floppy disk and similar device.In addition, some steps or functions of the present application can adopt hardware to realize, for example, as the circuit that cooperates with processor to perform each step or function.
[0184] The computer program product provided by the embodiment of the present application includes one or more computer programs / instructions, and when the computer program / instructions are executed by the processor, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instruction can be stored in a computer-readable storage medium, or transmitted from a computer-readable storage medium to another computer-readable storage medium. For example, the computer instruction can be transmitted from a website, a computer, a server or a data center by wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) mode to another website, a computer, a server or a data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server, a data center that includes one or more available media integrations. The available medium can be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid-state hard disk) etc.
[0185] The flowcharts or block diagrams in the accompanying drawings illustrate the possible architectures, functions and operations of the devices, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment or part of code, and the module, program segment or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, as well as the combination of boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-specific system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.
[0186] The scope of this application is defined by the appended claims rather than the foregoing description and is therefore intended to encompass within this application all changes that come within the meaning and range of equivalents of the claims. Any reference signs in the claims should not be construed as limiting the claims to which they relate. In addition, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices stated in a device claim may also be implemented by one unit or device through software or hardware. Words such as "first" and "second" are only used to distinguish the description and do not indicate any particular order, nor should they be understood as indicating or implying relative importance.
[0187] The above descriptions are merely specific embodiments of the present application, but the scope of protection of the present application is not limited thereto. Any person skilled in the art may easily propose variations or substitutions within the technical scope disclosed in the present application, and such variations or substitutions shall be encompassed within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be subject to the scope of protection of the claims, and the above descriptions shall be regarded as exemplary and non-limiting.
Claims
1. A UI control method based on multi-platform games, characterized in that: The method comprises: Determine a response based on input information and a pre-built key input distribution architecture; the input information is generated based on the player's interaction with the game through physical devices, and the response results affect changes at the UI level; The UI is dynamically adjusted based on the response result and the target component; the target component is used to control the differentiated performance of the in-game UI layout on different platforms.
2. The method according to claim 1, characterized in that The method for creating the key input distribution architecture includes: Creating a data structure; the data structure is used to determine target input information having a preset standard format based on the input information; Determine a callback response mechanism; the callback response mechanism is used to characterize how to send the target input information to the corresponding processing module; the processing module is a functional unit responsible for specifically processing the target input information.
3. The method according to claim 2, characterized in that Determining a response result based on the input information and the pre-built key input distribution architecture includes: determining target input information according to the data structure and the input information; According to the callback response mechanism, the target input information is sent to the corresponding processing module; The response result is determined according to the target input information and the processing module.
4. The method according to claim 2, characterized in that The method for determining the data structure includes: The data structure is determined based on UnityInputSystem; through the data structure, a mapping relationship between the input information and the logical events required by the business logic can be established.
5. The method according to claim 4, characterized in that Determining the data structure based on Unity InputSystem includes: Based on the underlying library of the UnityInputSystem, physical events, action events, and logical events with independent structures are defined; the physical events, the action events, and the logical events form the data structure; The physical event is used to obtain input information based on the physical device according to the underlying library; The action event is used to describe the triggering method of the physical event; The logic event is used to determine the event type sent to the business logic processing according to the action event.
6. The method according to claim 5, characterized in that The physical event includes several subfields; the several subfields correspond to key inputs of different physical devices respectively.
7. The method according to claim 6, characterized in that The number of the plurality of subfields is three, and the three subfields respectively correspond to: a mouse-based key input event, a keyboard-based key input event, and a handle-based key input event.
8. The method according to claim 3, characterized in that The method for determining the callback response mechanism includes: Determine a UI framework; the UI framework includes a fundamental base class of UI controls and subclasses of the fundamental base class; the subclasses are used to identify the root node of the most basic level in the UI interface; A callback response mechanism is determined based on the UI framework and the data structure.
9. The method according to claim 8, characterized in that The sending of the target input information to the corresponding processing module according to the callback response mechanism includes: Determine a subclass at the top of the hierarchical structure in the UI framework, the subclass being used to distribute target input information of the current frame, and the subclass being configured with a list for listening to input events; According to the list and the data structure, the target input information is sent to a corresponding processing module.
10. The method according to claim 9, characterized in that The sending the target input information to the corresponding processing module according to the list and the data structure includes: Sending the target input information to a corresponding processing module according to the list, the data structure and a preset priority rule; The priority rule is as follows: in the entire class system, the later the base class is created, the higher its corresponding input response priority; and in the hierarchical structure of the UI framework, the closer the subclass is to the top layer, the lower its input response priority.
11. The method according to claim 3, characterized in that After determining the callback response mechanism, the method for creating the key input distribution architecture further includes: determining the time interval and order of each frame processed by the processing module; Correspondingly, determining the response result according to the target input information and the processing module includes: The response result is determined according to the target input information and the time interval and sequence of each frame processing of the processing module.
12. The method according to claim 3, characterized in that The determining the response result according to the target input information and the processing module includes: Set the update logic to the earliest execution position in the game engine's frame update process; The response result is determined based on the update logic, the target input information and the processing module.
13. The method according to claim 1, wherein Dynamically adjusting the UI based on the response result and the target component includes: According to the type of the platform, the response result and the target component, the layout parameters of the UI elements are adjusted to achieve dynamic adjustment of the UI.
14. The method according to claim 13, characterized in that The layout parameters include at least one of the following: position, size, scaling ratio, visibility status, and layout mode.
15. The method according to any one of claims 1 to 14, characterized in that The method for determining the target component includes: Creating subclasses that inherit from a base class; the target base class is used to provide a virtual function interface, and the virtual function interface is used to be triggered when a preset condition is met; According to the subclass, the UGUI component function is replaced to obtain the target component.
16. The method according to claim 15, characterized in that The subclass is used to replace the UGUI component function, and the target component is obtained, including: Constructing a dictionary data structure in each subclass; the dictionary data structure is used to store information related to multiple platforms; Determine the layout method of the base class in the subclass; According to the dictionary data structure and the layout setting method, the UGUI component function is replaced to obtain the target component.
17. The method according to claim 16, characterized in that The dictionary data structure is constructed in each subclass: Determine a dictionary key in the dictionary data structure; the key corresponds to an enumeration class of a UI layout platform; Determine the value of the dictionary in the dictionary data structure; the value corresponds to the coverage data of multiple platforms.
18. An electronic device, characterized in that: The electronic device comprises: one or more processors; and A memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method according to any one of claims 1 to 17.
19. A computer readable medium having a computer program / instruction stored thereon, characterized in that: When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 17 are implemented.
20. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 17 are implemented.