Information processing method and device in game, electronic equipment and storage medium

Abstract

The application provides an information processing method and device in a game, an electronic device and a storage medium. The method comprises the following steps: receiving a trigger operation of a target player on a target virtual element in a virtual battle, the target player being a player in an associated team, the associated team comprising a master player and at least one slave player; in response to the trigger operation, performing a confirmation link for the target virtual element; when the target virtual element passes the confirmation link, generating a data record for the master player; and synchronizing the generated data record to each player in the associated team. According to the application, the logic of each link in the original game running logic does not need to be modified in the game process, and additional coding is reduced.

Description

Technical Field

[0001] This application relates to the field of computer application technology, and in particular to an information processing method, apparatus, electronic device and storage medium for games. Background Technology

[0002] Multiple players can operate on the same game data simultaneously, and depending on the settings, players can perform different actions, with each player's actions visible to the others in real time.

[0003] Taking the shared main city gameplay as an example: multiple players share character data to form a clan or faction and launch an attack from the same main city. Multiple players will share the territory, buildings, facilities, and internal affairs effects of the main city, and work together to configure troops, conquer lands, upgrade facilities, and construct buildings.

[0004] Taking the confirmation process in creating a unit as an example, each time a player uses character data, it needs to be confirmed whether the character data used belongs to that player. For situations where multiple players operate on game data simultaneously, taking the example of two players sharing a general to form a unit: General A belongs to player A, and player B uses General A to form unit 1. Since General A is not a general owned by player B, the above confirmation process needs to be processed additionally during the game. That is, it is necessary not only to confirm whether the character data used belongs to player B, but also to confirm whether the character data belongs to player A, in order to pass the confirmation process.

[0005] In the aforementioned confirmation process for multiple players simultaneously accessing game data, additional coding is required to modify the original confirmation logic. Furthermore, this confirmation process is executed every time a player uses game data, which increases the workload associated with the code modifications. Summary of the Invention

[0006] In view of this, embodiments of this application provide at least one information processing method, apparatus, electronic device, and storage medium in a game, which avoids changes to existing links in the game's operating logic and reduces additional coding through forward proxy.

[0007] In a first aspect, an exemplary embodiment of this application provides an information processing method in a game, the method comprising: receiving a trigger operation by a target player on a target virtual element in a current virtual battle, the target player being a player in an associated team, the associated team including a master player and at least one slave player; responding to the trigger operation, performing a confirmation step on the target virtual element; generating a data record for the master player when the target virtual element passes the confirmation step; and synchronizing the generated data record to each player in the associated team.

[0008] In one possible implementation, the confirmation step is used to determine the ownership of the target virtual element.

[0009] In one possible implementation, the step of performing the verification process for the target virtual element includes: determining whether the target virtual element is owned by the controlling player.

[0010] In one possible implementation, the target virtual element is confirmed to belong to the controlling player through a verification process.

[0011] In one possible implementation, the virtual elements owned by the master player include all virtual elements in the virtual element set corresponding to the associated team, the virtual element set includes the virtual elements owned by all players in the associated team, and / or, the virtual elements owned by each slave player include all virtual elements in the virtual element set corresponding to the associated team.

[0012] In one possible implementation, the method further includes: appointing each slave player in the associated team as the master player, so that each slave player plays the game as the master player in this virtual battle.

[0013] In one possible implementation, the step of generating data records for the controlling player when the target virtual element passes through the confirmation stage includes: when the target virtual element passes through the confirmation stage, executing game stages for the triggered operation according to the game operation logic in this virtual battle, so as to generate data records for the controlling player corresponding to each stage.

[0014] In one possible implementation, the game segment includes at least one of the following: performing operation settlement for the triggered operation; issuing task rewards for the triggered operation; and determining whether the virtual game settlement conditions for this virtual battle are met.

[0015] In one possible implementation, the step of generating a data record for the master player in response to the triggering operation includes: inserting the data record into a master table in response to the triggering operation, the master table being a data table used to record the master player's game operations in this virtual battle; wherein, the step of synchronizing the generated data record to each virtual character in the associated team includes: creating a slave table corresponding to each slave player; inserting the data record into the master table while simultaneously inserting a corresponding data record into each slave table.

[0016] In one possible implementation, the data record inserted in the master table is used to represent the record of the master player using the target virtual element, and the data record inserted in each slave table is used to represent the record of the slave player corresponding to that slave table using the target virtual element.

[0017] In one possible implementation, the method further includes: sending the data records to be inserted into the main table to the first game terminal corresponding to the main player, so that the first game terminal directly adds the received data records to the main player's character data table.

[0018] In one possible implementation, the method further includes: for each slave player, sending the data record inserted into the slave table corresponding to that slave player to the second game terminal corresponding to that slave player, so that the second game terminal updates the slave player's character data table according to the received data record.

[0019] In one possible implementation, the character data table corresponding to each slave player is updated by the second game terminal in the following manner: determining the offset value corresponding to the slave player; determining a recovery key value based on the key value in the received data record and the determined offset value; using the determined recovery key value to update the key value in the received data record, and adding the updated data record to the character data table of the slave player.

[0020] In one possible implementation, the offset values ​​corresponding to different slave players are different, and the offset value corresponding to each slave player is determined based on the storage area pre-set for each slave player.

[0021] In one possible implementation, the master player is a player randomly selected from the associated team, or the master player is a player determined based on the selection operations of each player in the associated team; the at least one slave player is another player in the associated team besides the master player.

[0022] Secondly, embodiments of this application also provide an information processing device for a game, the device comprising: a receiving module for receiving a trigger operation by a target player on a target virtual element in a virtual battle, the target player being a player in an associated team, the associated team including a master player and at least one slave player; a confirmation module for performing a confirmation step on the target virtual element in response to the trigger operation; a generation module for generating a data record for the master player when the target virtual element passes the confirmation step; and a synchronization module for synchronizing the generated data record to each player in the associated team.

[0023] Thirdly, embodiments of this application also provide an electronic device, a processor, a storage medium, and a bus. The storage medium stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the above method.

[0024] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the above-described method.

[0025] The information processing method, apparatus, electronic device, and storage medium for games provided in this application embodiment do not require modification of the logic of the original links during the game process, thus reducing additional coding.

[0026] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 A flowchart illustrating an exemplary embodiment of this application shows a method for processing information in a game.

[0029] Figure 2 A schematic diagram of the existing confirmation process is shown.

[0030] Figure 3 This application illustrates a data interaction flowchart provided by an exemplary embodiment.

[0031] Figure 4 A flowchart illustrating the steps of updating the character data table corresponding to the slave player provided in an exemplary embodiment of this application;

[0032] Figure 5 This invention provides a schematic diagram of the structure of an information processing device in a game according to an exemplary embodiment of this application.

[0033] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0035] The terms “a,” “an,” “the,” and “the” are used in this specification to indicate the presence of one or more elements / components / etc.; the terms “including” and “having” are used to indicate an open-ended inclusion and to mean that there may be other elements / components / etc. in addition to the listed elements / components / etc.; the terms “first” and “second” are used only as markings and are not a limitation on the number of objects.

[0036] It should be understood that in the embodiments of this application, "at least one" means one or more, and "more than one" means two or more. "And / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the related objects before and after it are in an "or" relationship. "Contains A, B and / or C" means containing any one, two, or three of A, B, and C.

[0037] It should be understood that in the embodiments of this application, "B corresponding to A", "B corresponding to A", "A corresponds to B" or "B corresponds to A" means that B is associated with A, and B can be determined based on A. Determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0038] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0039] In the game, multiple players can operate on the same game data at the same time, and according to the settings, players can perform different operations, and each player's operation is visible to each other in real time.

[0040] The following is an example of the main city sharing gameplay: multiple players use character data to form a family force, start an army in the same main city, and multiple players will share the territory, buildings, facilities and internal affairs effects of the main city, and jointly complete tasks such as configuring troops, conquering land, upgrading facilities and constructing buildings.

[0041] Taking the confirmation step (Check step) in creating a unit as an example, whenever a player uses character data, it is necessary to confirm whether the character data used belongs to that player.

[0042] For situations where multiple players simultaneously manipulate game data, consider the example of two players sharing a general to form a unit: General A belongs to player A, and player B uses General A to form unit 1. Since General A is not owned by player B, additional processing is required during the game's confirmation process. That is, it's necessary to confirm not only whether the character data used belongs to player B, but also whether the character data belongs to player A, in order to pass the Check step.

[0043] In the aforementioned confirmation process for multiple players simultaneously accessing game data, additional coding is required to modify the logic of the original confirmation process. Furthermore, this confirmation process needs to be executed every time a player uses game data, which also increases the amount of processing required for the code modifications.

[0044] To address the aforementioned issues, this application proposes an information processing method, apparatus, electronic device, and storage medium for games. This method can transform a subordinate player into a controlling player through forward proxying, thereby avoiding modifications to existing aspects of the game's operational logic and reducing additional coding.

[0045] First, a brief introduction to the names involved in the embodiments of this application will be given.

[0046] In this embodiment of the application, a graphical user interface can be provided through a terminal device to display the game scene, wherein:

[0047] Terminal equipment:

[0048] The terminal device involved in this application mainly refers to an intelligent device used to provide game scenes and control virtual characters. The terminal device can be, but is not limited to, any of the following: smartphones, tablets, laptops, desktop computers, game consoles, personal digital assistants (PDAs), e-book readers, MP4 (Moving Picture Experts Group Audio Layer IV) players, etc. This terminal device has an application installed and running that supports the game scene, such as an application supporting 3D game scenes. This application can be, but is not limited to, any of the following: virtual reality applications, 3D map applications, military simulation applications, MOBA games, multiplayer shooting survival games, and third-person shooter (TPS) games. Optionally, the application can be a standalone application, such as a standalone 3D game application, or an online multiplayer application.

[0049] Graphical User Interface:

[0050] A graphical user interface (GUI) is a human-computer interaction display format that allows users to manipulate icons, icons, or menu options on the screen using input devices such as a mouse or keyboard. It also allows users to manipulate icons or menu options on the touchscreen of a touch terminal to select commands, launch programs, or perform other tasks. Here, the GUI displays a game scene.

[0051] Virtual scene:

[0052] A virtual scene is a virtual environment displayed (or provided) by an application while it is running on a terminal or server. Optionally, this virtual scene can be a simulation of the real world, a semi-simulated / semi-fictional virtual environment, or a purely fictional virtual environment. A virtual scene can be either a two-dimensional or three-dimensional virtual scene, and can include elements such as sky, land, or ocean. The land element can include environmental elements such as deserts and cities. The virtual scene is a scenario where the user controls virtual objects and other complete game logic.

[0053] Virtual characters:

[0054] Virtual characters refer to virtual roles within a virtual environment. These virtual characters can be player-controlled, including but not limited to at least one of virtual characters, virtual animals, and anime characters. They can also be non-player-controlled virtual characters (NPCs) or virtual objects. Static characters within a virtual scene include, for example, virtual props, virtual quests, locations, terrain, houses, bridges, and vegetation. Static characters are often not directly controlled by the player but can respond to interactions with other virtual characters in the scene (e.g., attacking, demolishing, etc.), exhibiting corresponding behaviors. For example, a virtual character can demolish, pick up, drag, and build structures. Optionally, virtual objects may not respond to virtual character interactions. For example, virtual objects can be buildings, doors, windows, and vegetation in a game scene, but virtual characters cannot interact with them. For instance, a virtual character cannot destroy or demolish a window. Optionally, when the virtual environment is a three-dimensional virtual environment, the virtual character can be a three-dimensional virtual model. Each virtual character has its own shape and volume within the three-dimensional virtual environment, occupying a portion of the space within it. Optionally, the virtual character is a three-dimensional character constructed based on three-dimensional human skeleton technology, and the virtual character achieves different external appearances by wearing different skins. In some implementations, the virtual character can also be implemented using a 2.5D or 2D model, and this application embodiment does not limit this.

[0055] Multiple virtual characters can exist in a virtual scene. These virtual characters can be player-controlled (i.e., characters controlled by the player through input devices) or artificial intelligence (AI) trained and configured for virtual battles. Optionally, the virtual character is a virtual figure competing in a game scene. Optionally, the number of virtual characters in the game scene battle is preset or dynamically determined based on the number of terminal devices joining the virtual battle; this application embodiment does not limit this. In one possible implementation, the user can control the virtual character to move within the virtual scene, for example, controlling the virtual character to run, jump, crawl, etc., and can also control the virtual character to use skills and virtual items provided by the application to fight against other virtual characters.

[0056] In an alternative implementation, the terminal device can be a local terminal device. Taking a game as an example, the local terminal device stores the game program and is used to display the game screen. The local terminal device is used to interact with the player through a graphical user interface, that is, conventionally downloading, installing, and running the game program via an electronic device. The local terminal device can provide the graphical user interface to the player in various ways, such as rendering it on the terminal device's display screen, or providing it to the player through holographic projection. For example, the local terminal device can include a display screen for displaying the graphical user interface, which includes game scene images, and a processor for running the game, generating the graphical user interface, and controlling the display of the graphical user interface on the display screen.

[0057] This application describes the applicable scenarios. It can be applied to the field of game technology, where multiple players participate in a virtual battle within the same game.

[0058] Before entering a virtual battle, players can choose different character attributes for their virtual characters, such as identity attributes. These attributes determine different factions, allowing players to complete game-assigned tasks at different stages of the battle to win. For example, multiple virtual characters with attribute A can win by eliminating virtual characters with attribute B during a match. Alternatively, character attributes can be randomly assigned to each virtual character upon entering the battle.

[0059] An implementation environment provided in one embodiment of this application may include: a first terminal device, a server, and a second terminal device. The first terminal device and the second terminal device communicate with the server respectively to achieve data communication. In this embodiment, the first terminal device and the second terminal device are each equipped with an application program that executes the information processing method in the game provided in this application, and the server is a server-side application that executes the information processing method in the game provided in this application. Through the application program, the first terminal device and the second terminal device can communicate with the server respectively.

[0060] Taking the first terminal device as an example, the first terminal device establishes communication with the server by running an application. In an optional implementation, the server establishes a virtual battle based on the game request from the application. The parameters of the virtual battle can be determined based on the parameters in the received game request; for example, the parameters may include the number of participants and the character level. When the first terminal device receives a response from the game server, it displays the game scene corresponding to the virtual battle through its graphical user interface. The first terminal device is a device controlled by the first user, and the virtual character displayed in the graphical user interface is the player character controlled by the first user (i.e., the first virtual character). The first user inputs operation commands through the graphical user interface to control the player character to perform corresponding operations in the game scene.

[0061] Taking a second terminal device as an example, the second terminal device establishes communication with the server by running an application. In an optional implementation, the server establishes a virtual battle based on the game request from the application. The parameters of the virtual battle can be determined based on the parameters in the received game request; for example, the parameters may include the number of participants and the character levels. When the second terminal device receives a response from the server, it displays the game scene corresponding to the virtual battle through its graphical user interface. The second terminal device is a device controlled by a second user, and the virtual character displayed in the graphical user interface of the second terminal device is the player character controlled by the second user (i.e., the second virtual character). The second user inputs operation commands through the graphical user interface to control the player character to perform corresponding operations in the virtual scene.

[0062] The server receives game data reported by the first terminal device and the second terminal device, performs data calculations, and synchronizes the calculated game data to the first terminal device and the second terminal device, so that the first terminal device and the second terminal device control the graphical user interface to render the corresponding game scene and / or virtual character according to the synchronized data sent by the game server.

[0063] In this embodiment, the first virtual character controlled by the first terminal device and the second virtual character controlled by the second terminal device are virtual characters in the same virtual battle. The first virtual character controlled by the first terminal device and the second virtual character controlled by the second terminal device may have the same character attributes or different character attributes; they may belong to the same faction or different factions.

[0064] It should be noted that virtual battles can include two or more virtual characters, and different virtual characters can correspond to different terminal devices. In other words, in virtual battles, there are two or more terminal devices that send and synchronize game data with the game server.

[0065] To facilitate understanding of this application, the following provides a detailed description of the information processing methods, apparatus, electronic devices, and storage media in games provided in the embodiments of this application.

[0066] Please see Figure 1 The flowchart illustrates an information processing method in a game provided as an exemplary embodiment of this application. This information processing method specifically includes:

[0067] Step S101: Receive the target player's trigger operation on the target virtual element in this virtual battle.

[0068] In the exemplary embodiment of this application, the target player is a player in an associated team, which includes a master player and at least one slave player. That is, the target player can be either the master player or a slave player.

[0069] For example, the aforementioned team formation can be a faction formed based on the character attributes of each virtual character participating in this virtual battle, or it can be a team formed by players actively choosing before entering this virtual battle or during this virtual battle.

[0070] In addition, after forming a linked team, a master player can be identified, and at least one slave player can be identified as another virtual character in the linked team besides the master player. In this case, each slave player in the linked team can act as the master player, so that each slave player can play the game as the master player in this virtual battle.

[0071] The following describes how to identify the controlling player from associated teams, but it should be understood that this application is not limited to this, and other methods can also be used to identify the controlling player from associated teams.

[0072] In one scenario, the controlling player is a player randomly selected from the associated team.

[0073] For example, in each associated team, the number of master players is 1. After the associated team is formed, a player can be randomly selected from the multiple players in the associated team to be the master player, and the other players from the multiple players other than the randomly selected player can be designated as slave players.

[0074] Similarly, in the above situation, only one player can be allowed to select their identity in the associated team through the terminal device. For example, a player can be randomly selected from the associated team, and the selected player has the right to select their identity. Alternatively, the player can refer to the first player to select the main player.

[0075] In this way, multiple players in a linked team are divided into one master player and at least one slave player. Each player in the linked team can operate on a single set of game data at the same time, and each player's operation is visible to the others in real time.

[0076] In another scenario, the controlling player is determined based on the choices made by other players in the associated team.

[0077] For example, after forming a team, each player in the team needs to select their role within the team through their terminal device.

[0078] In one optional example, the controlling player can be a player elected by a vote among multiple players in the associated team. For example, the controlling player can be determined by identifying the player based on the voting results among the players in the associated team. Here, the controlling player is the player in the associated team who receives the most votes.

[0079] For example, the process of calculating the voting results for each player can be as follows: For each player's corresponding player identifier within the associated team, display a voting control for the player indicated by that player identifier in the associated area. In response to each player's voting operation on the voting control within the associated team, execute the corresponding voting instruction and calculate the voting results for each player.

[0080] Here, the player identifiers corresponding to each player can be displayed in the preset display interface. For example, the preset display interface can be a static display interface, such as a configuration interface for setting / modifying game parameters, or it can be a dynamic display interface, such as a game screen for presenting real-time game scenes.

[0081] In one example, you can manipulate the voting control corresponding to a player to complete the voting process.

[0082] In another example, voting can also be done based on an invitation request.

[0083] For example, the receiving terminal device receives a player's voting action on their own voting control, executes the corresponding voting instruction based on the voting action on their own voting control, generates an invitation request, and sends it to other terminal devices corresponding to other players in the associated team, so that other terminal devices can vote based on the feedback of the invitation request.

[0084] It should be understood that in the above embodiments, the voting operation is performed based on the voting control, but this application is not limited to this. The voting operation can also be performed by directly clicking on the player's player icon.

[0085] In one embodiment of this application, the target virtual element can be a virtual element in the set of virtual elements corresponding to the associated team, and the virtual element can be a virtual resource in the game. For example, the virtual element can include, but is not limited to, at least one of the following: virtual character, virtual item, formed team, obtained task reward, virtual model.

[0086] For example, virtual characters can include the virtual characters used by each player in this virtual battle, or the virtual characters that each player owns in the game. In the game, virtual characters of the same or different types can be grouped into teams to perform game combat missions. Virtual items can refer to virtual items used to enhance the combat capabilities of virtual characters, such as virtual props and virtual weapons in the game. As an example, virtual items can include, but are not limited to, at least one of the following: virtual weapons held by virtual characters, virtual accessories equipped on virtual characters, or attached to virtual weapons. As an example, virtual accessories can refer to gems, gun stocks, and other accessories that can be attached to weapons. Virtual models can be various virtual buildings in the game, such as virtual cities, which players compete for control of through combat.

[0087] In one embodiment of this application, the triggering operation can be a control operation of a target player on a target virtual element, such as grouping virtual characters, using / allocating virtual items, or managing virtual buildings. The triggering operation can be of various types, including touch operations performed on a touchscreen display and non-touch operations performed via peripheral devices such as a mouse or gamepad.

[0088] Step S102: In response to the triggering operation, perform a confirmation step for the target virtual element.

[0089] In this embodiment, the confirmation step can be used to determine the ownership of the target virtual element, that is, to determine whether the target virtual element is a virtual element shared by an associated team. For example, it can be determined whether the target virtual element is owned by the controlling player.

[0090] Here, the virtual elements possessed by the controlling player include all virtual elements in the virtual element set corresponding to the associated team, which in turn includes the virtual elements possessed by all players in the associated team. Furthermore, the virtual elements possessed by each secondary player also include all virtual elements in the virtual element set corresponding to the associated team. In other words, the virtual elements possessed by each player within the associated team can be shared and used by all players.

[0091] The following is combined with Figure 2 This application aims to illustrate the differences between this application and existing technologies in the process of multiple players coordinating the operation of a single piece of game data.

[0092] Figure 2 This diagram illustrates the logical flow of the existing confirmation process.

[0093] In this example, assuming player B is not in an associated team and general A is owned by player B, then, if Figure 2 As shown, when player B creates a unit using general A in this virtual battle, a Check step is required. This step confirms the ownership of general A and whether it belongs to player B. If general A is a virtual character owned by player B in this game (or in this virtual battle), a data record is generated. The key value (army_id) in this data record is 1, the user is player B, and the virtual character (hero) used is general A.

[0094] If Player B and Player A enable shared gameplay in this virtual battle, the two players can share each other's game data. For example, suppose Player A owns General A, and Player B uses Player A's General A to create Unit 1. Since General A is not owned by Player B, additional processing is required during the game's confirmation process. That is, it needs to be confirmed not only whether the character data used belongs to Player B, but also whether the character data belongs to Player A, in order to pass the Check step.

[0095] In this embodiment of the application, the operations of each player in the associated team are delegated to the main player. In this case, the confirmation process only needs to confirm whether the target virtual element used belongs to the main player, thus avoiding modifications to the code.

[0096] Step S103: When the target virtual element passes the confirmation process, generate a data record for the controlling player.

[0097] For example, if the target virtual element passes the confirmation process, it means that the target virtual element belongs to the controlling player; if the target virtual element fails the confirmation process, it means that the target virtual element does not belong to the controlling player.

[0098] Here, the above-mentioned triggering operation can be performed by any player in the associated team. That is, the main player or the secondary player in the associated team can perform the triggering operation on the target virtual element, but the generated data record only points to the main player.

[0099] In other words, the actions of the slave players in the associated team during this virtual battle are proxied by the master player through forward proxying. In this embodiment, by forward proxying the slave players, the check process in the case of multiple players simultaneously operating game data in the prior art is reduced, and modifications to the check process code are also avoided.

[0100] When the target virtual element passes the confirmation stage, the game operation logic in this virtual battle is followed to execute the game steps for the triggered operation, so as to generate data records for the main player corresponding to each step.

[0101] For example, the game process may include, but is not limited to, at least one of the following: performing operation settlement for the triggered operation (e.g., settling the virtual character's virtual combat power, health, and damage after the triggered operation); distributing task rewards for the triggered operation; and determining whether the virtual match settlement conditions for this virtual battle are met. In other words, a corresponding data record can be generated for the confirmation stage and at least one game stage.

[0102] return Figure 1 Step S104: Synchronize the generated data records to each player in the associated team.

[0103] In existing technology, taking the example of two players sharing a general to form a unit, after player B uses general A to form unit 1, player B's data record is directly generated, such as... Figure 2 The data records shown are as follows. However, since General A is a general owned by Player A, an additional protocol is needed to synchronize the data records with Player A.

[0104] Furthermore, when synchronizing data records with player A, the data records need to be modified. For example, if player B uses player A's general A to form unit 1, the data records need to be modified as follows: Figure 2 After a data record is shown, when synchronizing it to player A, the user (user) needs to be changed from B to A. That is, the player's data record needs to be spliced, which makes it less intuitive.

[0105] In this embodiment, all data records that need to be synchronized in the associated team depend on changes made by the master player. Each modification to the master's data records is synchronized to the slave players, ensuring the accuracy and timeliness of their data records. Furthermore, the slave players' data records are only used by the client; the actual game logic uses the master's data records.

[0106] The specific data recording and synchronization process in the embodiments of this application is described below.

[0107] In this embodiment, a master table can be created for the Master, and slave tables can be created for each Slave. For example, in step S103 above, data records can be inserted into the master table when the target virtual element passes the confirmation process. Here, the master table is a data table used to record the game operations of the master player in this virtual battle.

[0108] In this case, for each slave player, a slave table corresponding to that slave player is created. While inserting data records into the main table, a corresponding data record is also inserted into each slave table.

[0109] The following is combined with Figure 3 This section will introduce the process of data record synchronization and the process of the client reading data records.

[0110] Figure 3 This document illustrates a data interaction flowchart provided by an exemplary embodiment of this application.

[0111] In this example, we take two players sharing a general to form a unit: Player A, Player B, General A, and Unit 1. General A belongs to Player A, Player A is selected as the Master, and Player B is the Slave. Player B uses General A to form Unit 1.

[0112] In this scenario, player B can act as the agent for Master player A, and player B can use Master's data to play the game.

[0113] Player B uses Player A's general A to form a unit 1 belonging to Player A (this unit 1 also belongs to Player B). This avoids the extra processing required in the Check phase in the existing solution. It also ensures that all data operations are performed on the main table, facilitating subsequent data synchronization.

[0114] After forming Unit 1, generate Army_Slave (from the table) for player B. For example... Figure 3 As shown, Army is the master table, and Army_Slave is the slave table. All data operations in the related group are performed on the master table, and then synchronized to the slave table via a logical hook. The purpose of the logical hook is to shield the reasons for data modification, making data synchronization simple.

[0115] The following example uses the main table `Army` and the subordinate table `Army_Salve` to illustrate the logic hook: After player B forms unit 1 using general A, taking the generation and confirmation of data records as an example, a data record is inserted into the `Army` table for player A. The key value (`army_id`) of this data record is 1, the user is player A, and the virtual character (hero) used is general A. Through the logic hook, a data record is also inserted into the subordinate table for player B. The key value (`army_id`) of this data record is 1, the user is player B, and the virtual character (hero) used is general A. During the above synchronization process, the reason for inserting this data record is not important; it is only necessary to add the data record and modify the ID for the corresponding player during the synchronization process.

[0116] As can be seen from the above example, the data records inserted in the main table represent the records of the master player using the target virtual element, and the data records inserted in each sub-table represent the records of the slave player corresponding to that sub-table using the target virtual element.

[0117] In a preferred example, the aforementioned forward proxy phase, confirmation phase (and other phases related to game functionality), and data synchronization process can be executed on the game server. In this case, in the exemplary embodiment of this application, the data records inserted into the main table can also be sent to the first game terminal corresponding to the controlling player, so that the first game terminal directly adds the received data records to the controlling player's character data table.

[0118] In other words, the first game terminal corresponding to the main player can read the data records in the main table and directly add them to the main player's character data table without conversion or modification.

[0119] Furthermore, for each slave player, the data records inserted into the slave table corresponding to that slave player can be sent to the second game terminal corresponding to that slave player. This allows the second game terminal to update the slave player's character data table based on the received data records. In other words, the second game terminal corresponding to the slave player needs to transform the data records received from the Army_Slave slave table before adding them to the slave player's character data table.

[0120] Figure 4 A flowchart illustrating the steps of updating the character data table corresponding to the slave player provided in an exemplary embodiment of this application.

[0121] like Figure 4 As shown, in step S201, the offset value corresponding to the slave player is determined.

[0122] Here, the offset values ​​corresponding to different slave players are different, and the offset value corresponding to each slave player is determined based on the storage area pre-set for each slave player.

[0123] For example, the storage area can be pre-divided, and the game data corresponding to each player can be stored in different storage areas. Then, the offset value corresponding to the slave player can be determined based on the address difference (such as the number difference) between the storage area corresponding to the slave player and the storage area corresponding to the master player.

[0124] In step S202, the recovery key value is determined based on the key value in the received data record and the determined offset value.

[0125] Here, the army_id in the slave table of the slave player represents the key value of the data record. The sum of this key value and the offset value corresponding to the slave player is determined as the recovery key value.

[0126] In step S203, the determined recovery key value is used to update the key value in the received data record, and the updated data record is added to the character data table of the slave player.

[0127] In other words, the above process only requires offsetting the key values ​​in the table, avoiding the need to concatenate the player's data records.

[0128] In this embodiment of the application, by using logic hooks, player data can be synchronized without adding new protocols, which also solves the problem of player data not being intuitive.

[0129] Based on the same application concept, this application also provides an information processing device in the game corresponding to the method provided in the above embodiments. Since the principle of the device in this application to solve the problem is similar to the information processing method in the game in the above embodiments of this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0130] Figure 5 A schematic diagram of the structure of an information processing device in a game provided as an exemplary embodiment of this application. (e.g.) Figure 5 As shown, the information processing device 300 in the game includes:

[0131] The receiving module 310 receives the trigger operation of the target player on the target virtual element in this virtual battle. The target player is a player in the associated team, and the associated team includes a master player and at least one slave player.

[0132] The confirmation module 320, in response to the triggering operation, performs a confirmation step for the target virtual element;

[0133] The generation module 330 generates a data record for the main player when the target virtual element passes the confirmation process.

[0134] The synchronization module 340 synchronizes the generated data records to each player in the associated team.

[0135] In one possible implementation of this application, the confirmation step is used to determine the ownership of the target virtual element.

[0136] In one possible implementation of this application, the confirmation module 330 is further configured to: determine whether the target virtual element is owned by the controlling player.

[0137] In one possible implementation of this application, the target virtual element is confirmed to be owned by the controlling player through a verification process.

[0138] In one possible implementation of this application, the virtual elements owned by the master player include all virtual elements in the virtual element set corresponding to the associated team, the virtual element set includes the virtual elements owned by all players in the associated team, and / or, the virtual elements owned by each slave player include all virtual elements in the virtual element set corresponding to the associated team.

[0139] In one possible implementation of this application, the receiving module 310 is further configured to: appoint each slave player in the associated team as the master player, so that each slave player plays the game as the master player in this virtual battle.

[0140] In one possible implementation of this application, the generation module 330 is further configured to: when the target virtual element passes the confirmation stage, execute the game stage for the triggered operation according to the game operation logic in this virtual battle, so as to generate data records for the main player corresponding to each stage.

[0141] In one possible implementation of this application, the game segment includes at least one of the following: performing operation settlement for the triggered operation; issuing task rewards for the triggered operation; and determining whether the virtual game settlement conditions for this virtual battle are met.

[0142] In one possible implementation of this application, the generation module 320 is further configured to: in response to the triggering operation, insert the data record into the main table, wherein the main table is a data table used to record the game operations of the master player in this virtual battle; wherein the synchronization module 340 is further configured to: create a slave table corresponding to each slave player; while inserting the data record into the main table, insert a corresponding data record into each slave table.

[0143] In one possible implementation of this application, the data record inserted in the main table is used to represent the record of the master player using the target virtual element, and the data record inserted in each sub-table is used to represent the record of the slave player corresponding to that sub-table using the target virtual element.

[0144] In one possible implementation of this application, it further includes: a sending module that sends the data records inserted in the main table to the first game terminal corresponding to the main player, so that the first game terminal directly adds the received data records to the main player's character data table.

[0145] In one possible implementation of this application, the sending module is further configured to: for each slave player, send the data record inserted into the slave table corresponding to the slave player to the second game terminal corresponding to the slave player, so that the second game terminal updates the slave player's character data table according to the received data record.

[0146] In one possible implementation of this application, the character data table corresponding to each slave player is updated by the second game terminal in the following manner: determining the offset value corresponding to the slave player; determining the recovery key value based on the key value in the received data record and the determined offset value; using the determined recovery key value to update the key value in the received data record, and adding the updated data record to the character data table of the slave player.

[0147] In one possible implementation of this application, the offset values ​​corresponding to different slave players are different, and the offset value corresponding to each slave player is determined based on the storage area pre-set for each slave player.

[0148] In one possible implementation of this application, the master player is a player randomly selected from the associated team, or the master player is a player determined based on the selection operations of each player in the associated team; the at least one slave player is another player in the associated team besides the master player.

[0149] The aforementioned information processing device eliminates the need to modify the logic of the original confirmation process during gameplay, reducing additional coding. Furthermore, logic hooking enables the synchronization of player data without adding new protocols.

[0150] Please see Figure 6 , Figure 6 A schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application. For example... Figure 6 As shown, the electronic device 400 includes a processor 410, a memory 420, and a bus 430.

[0151] The memory 420 stores machine-readable instructions executable by the processor 410. When the electronic device 400 is running, the processor 410 communicates with the memory 420 via the bus 430. When the machine-readable instructions are executed by the processor 410, the steps of the information processing method in the game as described in any of the above embodiments can be performed, as follows:

[0152] The system receives a trigger operation from a target player targeting a target virtual element during the virtual battle. The target player is a player in an associated team, which includes a master player and at least one slave player. In response to the trigger operation, the system generates a data record for the master player. It then performs a confirmation process for the target virtual element. If the target virtual element passes the confirmation process, the system synchronizes the generated data record to each player in the associated team.

[0153] This application also provides a computer-readable storage medium storing a computer program. When the computer program is run by a processor, it can execute the steps of the information processing method in the game as described in any of the above embodiments, as follows:

[0154] The system receives a trigger operation from a target player targeting a target virtual element during the virtual battle. The target player is a player in an associated team, which includes a master player and at least one slave player. In response to the trigger operation, the system generates a data record for the master player. It then performs a confirmation process for the target virtual element. If the target virtual element passes the confirmation process, the system synchronizes the generated data record to each player in the associated team.

[0155] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0156] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0157] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0158] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0159] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An information processing method in a game, characterized in that, The method includes: The system receives trigger operations from a target player on a target virtual element during this virtual battle. The target player is a player in an associated team, which includes a master player and at least one slave player. Each slave player in the associated team is proxied as the master player, so that each slave player plays the game as the master player in this virtual battle. In response to the triggering operation, a confirmation step is performed for the target virtual element; When the target virtual element passes the confirmation process, a data record for the controlling player is generated. Passing the confirmation process for the target virtual element includes the target virtual element being owned by the controlling player. The generated data records will be synchronized to each player in the associated team.

2. The method according to claim 1, characterized in that, The virtual elements possessed by the controlling player include all virtual elements in the virtual element set corresponding to the associated team, and the virtual element set includes the virtual elements possessed by all players in the associated team. And / or, the virtual elements owned by each slave player include all virtual elements in the set of virtual elements corresponding to the associated team.

3. The method according to claim 1, characterized in that, The step of generating a data record for the controlling player when the target virtual element passes the confirmation process includes: When the target virtual element passes the confirmation stage, the game operation logic in this virtual battle is followed to execute the game steps for the triggered operation, so as to generate data records for the main player corresponding to each step.

4. The method according to claim 3, characterized in that, The game segment includes at least one of the following: Perform operation settlement for the aforementioned triggering operation; Task rewards will be issued in response to the aforementioned triggering operation; Determine whether the virtual match settlement conditions for this virtual battle are met.

5. The method according to claim 1, characterized in that, The steps for generating data records for the controlling player include: In response to the triggering operation, the data record is inserted into the main table, which is a data table used to record the game operations of the main player in this virtual battle; The step of synchronizing the generated data records to each player in the associated team includes: For each slave player, create a slave table corresponding to that slave player; While inserting the data record into the main table, insert a corresponding data record into each of the subsidiary tables.

6. The method according to claim 5, characterized in that, The data records inserted in the main table represent the records of the master player using the target virtual element, and the data records inserted in each slave table represent the records of the slave player using the target virtual element corresponding to that slave table.

7. The method according to claim 5, characterized in that, Also includes: The data records to be inserted into the main table are sent to the first game terminal corresponding to the main player, so that the first game terminal can directly add the received data records to the main player's character data table.

8. The method according to claim 5, characterized in that, Also includes: For each slave player, the data record inserted into the slave table corresponding to that slave player is sent to the second game terminal corresponding to that slave player, so that the second game terminal updates the slave player's character data table according to the received data record.

9. The method according to claim 8, characterized in that, The character data table for each slave player is updated by the second game terminal in the following way: Determine the offset value corresponding to the player being controlled; The recovery key value is determined based on the key value in the received data record and the determined offset value; Use the determined recovery key value to update the key value in the received data record, and add the updated data record to the character data table of the slave player.

10. The method according to claim 9, characterized in that, The offset values ​​for different slave players are different, and the offset value for each slave player is determined based on the storage area pre-set for each slave player.

11. The method according to claim 1, characterized in that, The controlling player is a player randomly selected from the associated team, or the controlling player is a player determined based on the selection operations of each player in the associated team; The at least one slave player is any player in the associated team other than the master player.

12. An information processing device for games, characterized in that, The device includes: The receiving module receives the target player's trigger operation on the target virtual element in this virtual battle. The target player is a player in an associated team. The associated team includes a master player and at least one slave player. Each slave player in the associated team is proxied as the master player, so that each slave player plays the game as the master player in this virtual battle. The confirmation module, in response to the triggering operation, performs a confirmation step for the target virtual element; The generation module generates a data record for the controlling player when the target virtual element passes the confirmation process, wherein the target virtual element passing the confirmation process includes the target virtual element being owned by the controlling player; The synchronization module synchronizes the generated data records to each player in the associated team.

13. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is in operation, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the method as described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the method as described in any one of claims 1 to 11.

Images