CN117695623A

CN117695623A - Method and device for managing physical scene resources in virtual world and computer equipment

Info

Publication number: CN117695623A
Application number: CN202211103196.8A
Authority: CN
Inventors: 冯楚桓; 仇斌; 黄灏; 王煊; 胡小强
Original assignee: Shenzhen Tencent Network Information Technology Co Ltd
Current assignee: Shenzhen Tencent Network Information Technology Co Ltd
Priority date: 2022-09-09
Filing date: 2022-09-09
Publication date: 2024-03-15

Abstract

The application discloses a method and a device for managing physical scene resources in a virtual world and computer equipment, and belongs to the technical field of computers. According to the method and the system, the same static physical scene resource is multiplexed for all virtual scenes of the same scene type, and a dynamic physical scene resource is independently established for each virtual scene to support the service requirement of dynamically adding or deleting physical entities in different virtual scenes, so that the memory overhead occupied by the static physical scene resource which is originally stored repeatedly and repeatedly can be greatly saved through a dynamic and static separation mode, the related service of the externally provided physical scene is ensured not to be adversely affected through a dynamic and static combination mode, and the memory occupation of the physical scene resource on a game server is improved and the processing performance of the game server is optimized on the premise that the service requirement and the service are not limited.

Description

Method and device for managing physical scene resources in virtual world and computer equipment

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a method and an apparatus for managing physical scene resources in a virtual world, and a computer device.

Background

With the development of computer technology, MMOG (Massive Multiplayer Online Game, massively multiplayer online game) is a popular type of electronic game. The game server of the MMOG uses a physical engine in the background to maintain physical scene resources of the virtual scene involved in the game, wherein the physical scene resources are used for simulating physical characteristics of objects in the virtual scene in the real world, and relevant services related to calling the physical scene are provided on the basis of the physical scene resources.

At present, in MMOG games, a corresponding physical scene is maintained in a physical engine for each game copy, and memory is consumed to store physical scene resources of the game copies, so that under the condition that more game copies are involved in a large-scale game, memory resources of a game server are seriously occupied, and the processing performance of the game server is adversely affected.

Disclosure of Invention

The embodiment of the application provides a method and a device for managing physical scene resources in a virtual world and computer equipment, which can reduce the occupation of the physical scene resources in a game server to memory and improve the processing performance of the game server. The technical scheme is as follows:

in one aspect, a method for managing physical scene resources in a virtual world is provided, where the method includes:

For a plurality of virtual scenes with the same scene type in the virtual world, determining a static physical entity from physical entities contained in the plurality of virtual scenes, wherein the static physical entity is a physical entity shared by the plurality of virtual scenes and is static;

based on the static physical entity, constructing a static physical scene resource multiplexed by the virtual scenes;

respectively constructing a plurality of dynamic physical scene resources for the plurality of virtual scenes, wherein each dynamic physical scene resource is used for storing dynamic physical entities except the static physical entity in one virtual scene;

and providing related services related to calling physical scenes for any one of the virtual scenes based on the static physical scene resources and the dynamic physical scene resources constructed for the virtual scenes.

In one aspect, there is provided a management apparatus for physical scene resources in a virtual world, the apparatus comprising:

the determining module is used for determining static physical entities from physical entities contained in a plurality of virtual scenes with the same scene types in the virtual world, wherein the static physical entities are physical entities shared by the plurality of virtual scenes and are static;

The construction module is used for constructing the static physical scene resources multiplexed by the virtual scenes based on the static physical entity;

the building module is further configured to build a plurality of dynamic physical scene resources for the plurality of virtual scenes, where each dynamic physical scene resource is used to store dynamic physical entities except the static physical entity in one virtual scene;

and the service module is used for providing related services related to calling physical scenes for any one of the virtual scenes based on the static physical scene resources and the dynamic physical scene resources constructed for the virtual scenes.

In some embodiments, the providing service module includes:

a ray determination unit, configured to determine a ray to be detected in the virtual scene based on an operation instruction for calling the ray detection service, in a case where the related service is a ray detection service;

the blocking detection unit is used for carrying out blocking detection on the rays in a static scene formed by the static physical scene resources to obtain a static scene detection result;

the blocking detection unit is further configured to perform blocking detection on the ray in a dynamic scene formed by the dynamic physical scene resource, so as to obtain a dynamic scene detection result;

And the result determining unit is used for determining a blocking detection result of the rays in the virtual scene based on the static scene detection result and the dynamic scene detection result.

In some embodiments, the result determination unit includes:

setting a subunit, configured to set the blocking detection result as non-blocking if the static scene detection result and the dynamic scene detection result are both non-blocking;

the setting subunit is further configured to set the blocking detection result as blocked if at least one of the static scene detection result and the dynamic scene detection result is blocked;

and the return subunit is used for returning the blocking point determined based on the static scene detection result and the dynamic scene detection result.

In some embodiments, the return subunit is configured to:

if the static scene detection result is blocked and the dynamic scene detection result is unblocked, returning to a static blocking point of a static physical entity touched by the ray in the static scene;

and if the static scene detection result is non-blocking and the dynamic scene detection result is blocking, returning to a dynamic blocking point of a dynamic physical entity touched by the ray in the dynamic scene.

In some embodiments, the return subunit is configured to:

if the static scene detection result and the dynamic scene detection result are both blocked, acquiring a static blocking point of a static physical entity touched by the ray in the static scene and a dynamic blocking point of a dynamic physical entity touched by the ray in the dynamic scene;

and determining the returned target blocking point based on the static blocking point and the dynamic blocking point.

In some embodiments, the return subunit is further configured to:

determining the interface type used by the operation instruction when the ray detection service is called;

if the interface type is a single ray detection interface, determining a blocking point closest to the starting point of the ray from the static blocking point and the dynamic blocking point as the target blocking point;

and if the interface type is a multi-time ray detection interface, sequencing the static blocking points and the dynamic blocking points according to the sequence from the starting point of the ray to the far, obtaining a blocking point list, and determining the blocking point list as the target blocking point.

In some embodiments, the building block is to:

Constructing an empty dynamic physical scene resource for any virtual scene;

and adding a dynamic physical entity in the virtual scene into the dynamic physical scene resource, wherein the dynamic physical entity refers to a physical entity except the static physical entity in the virtual scene.

In some embodiments, the apparatus further comprises:

the storage module is used for storing scene type identifiers of the same scene type of the plurality of virtual scenes in an associated mode with the static physical scene resource;

the storage module is further configured to store a scene instance identifier of each virtual scene in the plurality of virtual scenes in association with a dynamic physical scene resource of each virtual scene.

In one aspect, a computer device is provided that includes one or more processors and one or more memories having at least one computer program stored therein, the at least one computer program loaded and executed by the one or more processors to implement a method of managing physical scene resources in a virtual world as described above.

In one aspect, a computer readable storage medium is provided, in which at least one computer program is stored, the at least one computer program being loaded and executed by a processor to implement a method of managing physical scene resources in a virtual world as described above.

In one aspect, a computer program product is provided that includes one or more computer programs stored in a computer-readable storage medium. The one or more processors of the computer device are capable of reading the one or more computer programs from the computer-readable storage medium, and executing the one or more computer programs, so that the computer device can perform the method for managing physical scene resources in the virtual world.

The beneficial effects that technical scheme that this application embodiment provided include at least:

the same static physical scene resource is multiplexed for all virtual scenes of the same scene type, and a dynamic physical scene resource is independently established for each virtual scene to support the service requirement of dynamically adding or deleting physical entities in different virtual scenes, so that the memory overhead occupied by the static physical scene resource which is originally stored repeatedly for many times can be greatly saved through a dynamic and static separation mode, the related service of the externally provided physical scene is ensured not to be adversely affected through a dynamic and static combination mode, and the memory occupation of the physical scene resource to a game server is improved on the premise of ensuring that the service requirement and the service are not limited, and the processing performance of the game server is optimized.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly introduced below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a diagram of a logical architecture of a virtual world in a physics engine according to an embodiment of the present application;

FIG. 2 is a schematic diagram of a conventional physical scene resource management scheme according to an embodiment of the present application;

FIG. 3 is a schematic view of an implementation environment of a method for managing physical scene resources in a virtual world according to an embodiment of the present application;

FIG. 4 is a schematic diagram of a novel physical scene resource management scheme provided in an embodiment of the present application;

FIG. 5 is a flowchart of a method for managing physical scene resources in a virtual world according to an embodiment of the present application;

FIG. 6 is a flowchart of a method for detecting rays based on a management scheme of physical scene resources in a virtual world according to an embodiment of the present application;

FIG. 7 is a logic diagram of a radiation detection scheme provided by an embodiment of the present application;

Fig. 8 is a schematic structural diagram of a management apparatus for physical scene resources in a virtual world according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of a computer device according to an embodiment of the present application.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

The terms "first," "second," and the like in this application are used to distinguish between identical or similar items that have substantially the same function and function, and it should be understood that there is no logical or chronological dependency between the "first," "second," and "nth" terms, nor is it limited to the number or order of execution.

The term "at least one" in this application means one or more, meaning "a plurality of" means two or more, for example, a plurality of first positions means two or more first positions.

The term "comprising at least one of a or B" in this application relates to the following cases: only a, only B, and both a and B.

User-related information (including, but not limited to, user equipment information, personal information, behavioral information, etc.), data (including, but not limited to, data for analysis, stored data, presented data, etc.), and signals referred to in this application, when applied to a particular product or technology in the methods of embodiments of the present application, are subject to user approval, consent, authorization, or substantial authorization by parties, and the collection, use, and processing of the related information, data, and signals requires compliance with relevant laws and regulations and standards of the relevant country and region. For example, the requests related to invoking a service of a physical scenario referred to in this application are all acquired with sufficient authorization.

Hereinafter, terms related to embodiments of the present application will be explained.

Massive multiplayer online game (Massive Multiplayer Online Game, MMOG): a game in which a large number of players can be simultaneously online can be provided on a server which generally refers to any network game, namely a massive multiplayer online game.

Game engine: refers to the core components of some compiled editable computer game systems or some interactive real-time image applications. These systems provide game designers with the various tools required to write games in order to allow the game designer to easily and quickly make game programs without starting from zero. The game engine comprises the following systems: rendering engines, physics engines, collision detection systems, sound effects, script engines, computer animations, artificial intelligence, network engines, and scene management.

Physical engine: refers to the game background, and the physical engine used to simulate the physical characteristics of the real world object can be implemented as various commercial or open source physical engine software, such as Physx, havok, bullet, etc. The physical engine calculates motion, rotation and collision reflection by means of giving the rigid object real physical properties, and provides related services to the outside through the interface.

Virtual world: is a virtual environment that an application displays (or provides) while running on a terminal. The virtual world may be a simulation environment for the real world, a semi-simulation and semi-fictional virtual environment, or a pure fictional virtual environment. The virtual world may be any one of a two-dimensional virtual world, a 2.5-dimensional virtual world, or a three-dimensional virtual world, and the dimensions of the virtual world are not limited in the embodiments of the present application. For example, the virtual world may include sky, land, sea, etc., the land may include environmental elements such as deserts, cities, etc., and the user may control the virtual objects to move within the virtual world, which also provides virtual resources available to the virtual objects.

Game map: refers to the scene that a user's own virtual character is in the virtual world provided by the game after logging into the game, similar to a block of space in the real world. In conventional games, a continuous virtual world is typically segmented into a plurality of game maps, each of which provides a portion of the virtual scene in the virtual world, and new map resources need to be loaded when switching between game maps.

Seamless world: the method is characterized in that a continuous virtual world is different from a traditional game map in implementation, the scene range of the traditional game map is smaller, the continuous virtual world is manufactured into a plurality of game maps, a new game map needs to be loaded between different game maps, the scene range of a seamless large world is larger, the continuous virtual world is realized by using a seamless large map, and no new map needs to be loaded when the continuous virtual world moves in the seamless large map.

The game server: the game server is responsible for the game base play logic and also for the actual execution of the map instance creation. For example, the game server creates a GameSvr process to provide the basic play logic of the game.

And (3) main thread: the main logic thread refers to a GameSvr process and is used for running main play logic of a game.

Simulation thread: the simulation thread refers to a physical engine used by a GameSvr process and is used for running simulation calculation of the physical world.

Game copy: the game copy refers to a virtual place where players and teammates can explore, adventure or complete tasks without being interfered by others, and non-teammates cannot enter the same game copy. Upon completion of a certain type of task, players of different teams are able to enter the same type of game copy but not the same copy instance, in other words, multiple game copies of the same type do not interfere with each other.

Physical scene (physxscreen): a physical scene is a concept involved in a physical engine and is generally in one-to-one correspondence with game copies, i.e., each game copy in a virtual world corresponds to a physical scene in the physical engine. The physical scene consists of basic physical bodies, one physical scene is an independent physical world, and a plurality of physical scenes are not interfered with each other.

And (3) ray detection: in a physical scene, judging whether rays from a certain starting point to a certain end point are communicated or not. Typically, the physics engine and the external provision of a radiation detection interface, i.e. the computation on radiation detection, is implemented in the physical scene maintained by such physics engine. In the application scenario of the game, the ray detection interface may be used to determine whether the virtual character is able to move between two points in the virtual world (detect the validity of movement), and the ray detection interface may also be used to determine whether the emission of the virtual character can hit a target when the virtual character initiates shooting, and so on.

Currently, in an MMOG game, a background of a game server maintains a physical scene for each game copy, that is, the number of game copies and the number of physical scenes are in one-to-one correspondence, so that each game copy can be ensured to be capable of independently adding its own dynamic objects (such as refreshing a little monster, creating a physical entity of a player call, etc.) in the physical scene, and certain parallel independence exists between the game copies of the same type.

As shown in fig. 1, the logical architecture of the physical engine for the virtual world will be described below in conjunction with fig. 1.

In the game background of the MMOG, the virtual world of the game can be abstracted into one physical world 110 (PhysxWorld) through a physical engine, a plurality of physical scenes 120 (PhysxScene) are arranged under the physical world 110, each physical scene 120 corresponds to one game copy and is used for representing the physical scenes of the associated game copy, and the physical scenes 120 are parallel to each other and do not interfere with each other.

Taking a single physical scene 120 as an example, the basic constituent elements of the physical scene 120 are physical entities 130 (PhysxActor), the physical entities 130 relate to two parameters of entity types and entity shapes (shapes), the entity types represent the physical characteristics of which type of entity the physical entities should have when participating in the operation, and the entity shapes represent the geometric shapes and surface textures of the physical entities.

The entity types of the physical entity 130 include: rigid Body 1311 (rib Body), particle 1312 (Particle), cloth 1313 (close), character controller 1314 (Character), carrier 1315 (Vehicle), and the like, and generally, two types of physical entities, rigid Body 1311 and carrier 1315, need to be handled in the background.

The physical shape of the physical entity 130 includes: materials (materials) that characterize the surface friction and coefficient of elasticity of a physical entity, and Geometry that characterizes the spatial Geometry of the physical entity. Generally, the shape types of the geometry include: sphere 1321 (Sphere), capsule 1322 (Capsule), rectangular 1323 (Box), plane 1324 (Plane), convex polygon Plane 1325 (Convex Mesh), triangle Plane 1326 (Triangle Mesh), height map 1327 (Height Field), and the like.

In the game background, one game copy corresponds to one physical scene 120 one by one, the virtual characters controlled by the player move in the game copy, the virtual monsters controlled by the game background move in the game copy, the skills of the player are released, the player fires and shoots, and other actions can call a ray detection interface provided by a physical engine, and the ray detection interface can detect whether the rays are blocked or intersected with all physical entities 130 contained in the physical scene 120 corresponding to the game copy.

It is generally required in a game copy to support the dynamic addition or deletion of virtual objects, which requires the dynamic addition or deletion of physical entities in the physical scene 120 corresponding to the game copy, for example, a player controls a virtual character to newly summon a virtual carrier in the game copy, which requires the new addition of a physical entity 130 of the type carrier 1315 in the physical scene 120 corresponding to the game copy.

At present, when the game engine manages physical scene resources in the background, a corresponding physical scene 120 is configured for each game copy, so as to ensure the independence of the physical scene 120 and meet the service requirement of supporting dynamic addition or deletion of physical entities in the physical scene 120 of each game copy. As shown in fig. 2, a physical scene resource management manner under a conventional scheme is shown, for example, game copies A0, A1 and A2 are class a copies of the same type, and game copies B0, B1 and B2 are class B copies of the same type, where the game copies A0, A1 and A2 respectively use a scene instance (or referred to as a copy instance) created under a physical scene of the physxscreena type, and the game copies B0, B1 and B2 respectively use a scene instance created under a physical scene of the physxscreenb type.

In the physical scene resource management mode under the traditional scheme, since a physical scene is created and maintained for each game copy, the physical scene resource severely occupies the memory of the game server, which causes great waste to the memory of the game server.

In view of this, the embodiments of the present application provide a new physical scene resource management scheme for managing physical scenes and game copies by using a game background physical engine, so as to reduce the memory overhead occupied by the physical scene resources on the game server. In the new management scheme, when an actual game scene is considered, a situation that a large number of game copies of the same type are maintained in the background often exists, and the game copies of the same type can use different scene instances of the same physical scene, but because of the need to support the dynamic physical function of dynamically adding or deleting virtual objects in the game copies, separate physical scenes need to be maintained for each game copy.

In the embodiment of the application, each dynamic physical scene is split into a static scene and a dynamic scene, for all game copies with the same scene type, the same static scene is multiplexed, and a dynamic scene is independently established for each game copy to support dynamic addition or deletion of physical entities; under the management architecture, in order to ensure the correctness of external ray detection service, when ray detection is performed on each game copy, the ray detection is performed once in a public static scene, then the ray detection is performed once in a dynamic scene exclusive to the current copy, and the results of the two ray detection are combined to output a final result. Through the novel management scheme, on the premise of ensuring no influence on the service of the interface provided outside by calling a physical engine in the current game, such as movement, combat, garden construction and the like, the storage overhead caused by the physical scene resource for storing the game copy to the system memory is greatly reduced, so that the resource utilization rate of the game server is improved.

The system architecture of the embodiment of the present application is described in detail below.

Fig. 3 is an implementation environment schematic diagram of a method for managing physical scene resources in a virtual world according to an embodiment of the present application. Referring to fig. 3, the implementation environment includes: a terminal 301 and a game server 302.

Terminal 301 installs and runs a gaming application that supports the virtual world. Optionally, the game application includes: MMOG, MMORPG (Massive Multiplayer Online Role-Playing Game), MOBA (Multiplayer Online Battle Arena, multiplayer online tactical Game) games, shooting games, virtual reality applications, three-dimensional map programs, multiplayer appliance survival games, etc., or the Game application may also be a cloud Game application.

In some embodiments, the terminal 301 is a terminal used by a user, and when the terminal 301 runs a game application, the terminal 301 loads and displays a virtual world and various virtual objects located in the virtual world in response to an opening operation triggered by the user in the game application, and at the same time, the background of the game server 302 maintains physical scene resources of various game copies provided by the virtual world through a physical engine.

Terminal 301 is directly or indirectly connected to game server 302 by wired or wireless communication, and the present application is not limited thereto.

The game server 302 includes at least one of a server, a plurality of servers, a cloud computing platform, or a virtualization center. The game server 302 is used to provide background services for applications that support the virtual world, and the game server 302 is capable of providing the basic play logic of a game. Optionally, the game server 302 takes over primary game logic operations and the terminal 301 takes over secondary game logic operations; alternatively, the game server 302 takes on secondary game logic operations and the terminal 301 takes on primary game logic operations; alternatively, a distributed computing architecture is employed between game server 302 and terminal 301 for collaborative game logic.

Optionally, the game server 302 is a stand-alone physical server, or a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network ), and basic cloud computing services such as big data and artificial intelligence platforms.

In some embodiments, game server 302 creates a GameSvr process to provide the basic play logic of the game, the GameSvr process involving a main thread for running the subject play logic of the game and a simulation thread for implementing simulated computation of the physical world by a physics engine.

In one exemplary scenario, when a virtual object (which may be a virtual character operated by a player or a virtual character not operated by a player, such as a monster, a accompanying robot, etc.) in a virtual world of a game moves, a main thread may initiate a call to a radiation detection interface provided outside by a physical engine in an analog thread, so as to determine whether a barrier exists between a start point and an end point of the current movement through a service provided by the radiation detection interface, so as to determine whether the current movement is legal.

In another exemplary scenario, when a certain virtual object in the virtual world of the game shoots (or releases directional skills in a certain direction, or throws a certain target, etc.), the main thread may also initiate a call to a radiation detection interface provided outside by a physical engine in the analog thread, so as to determine whether there is a blockage between the starting point of the current shooting and the target through a service provided by the radiation detection interface, so as to determine whether the current shooting hits the target.

Note that the device types of the terminal 301 include: at least one of a smart phone, a tablet computer, a smart speaker, a smart watch, a smart palm phone, a portable game device, a vehicle-mounted terminal, a laptop portable computer, and a desktop computer, but is not limited thereto. For example, terminal 301 is a smart phone, or other handheld portable gaming device. The following embodiments are illustrated with terminal 301 comprising a smart phone.

Those skilled in the art will recognize that the number of terminals described above may be greater or lesser. Such as only one of the terminals, or tens or hundreds of terminals, or more. The number of terminals and the device type are not limited in the embodiment of the present application.

In the following, the principles of the new physical scenario resource management scheme according to the embodiment of the present application will be described with reference to fig. 4 by taking an MMOG game as an example. In the novel scheme, when the game background manages physical scene resources, a plurality of game copies of the same scene type can use the same static scene PhysxScene, and meanwhile, a dynamic scene MainlandScene is additionally created for each game copy to manage the physical entities dynamically added or deleted in a single game copy in the dynamic scene.

It should be noted that, the static scene is loaded by the static physical scene resource, the static scene only changes with different scene types, but does not change with different scene instances, in other words, all scene instances in the same scene type have the same static scene, so that different scene instances in the same scene type can multiplex the same static scene, in other words, once the scene type is determined, the static scene is fixed, and the background cannot add or delete physical entities in the static scene.

As shown in FIG. 4, as game copies A0, A1, and A2 are the same type of class A copy, game copies B0, B1, and B2 are the same type of class B copy. In the novel scheme, game copies A0, A1 and A2 belonging to the class A copy share the same static scene PhysxSceneA, namely, all scene instances under the class A copy are multiplexed with the static physical scene resources of the static scene PhysxSceneA; similarly, the game copies B0, B1 and B2 belonging to the class B copy will share the same static scene physxscreenb, i.e. all the scene instances under the class B copy above are multiplexed with the static physical scene resources of the static scene physxscreenb.

Further, for the class a copies A0, A1, and A2 and the class B copies B0, B1, and B2, the game server background creates a dynamic scene for each game copy (including class a copies and class B copies) separately through the simulation thread to support dynamically adding or deleting physical entities in the scene instance of each game copy, typically, in the initial case, the dynamic scene of each game copy is left empty. For example, the class a copy A0 has a single dynamic scene mainland scenea0, the class a copy A1 has a single dynamic scene mainland scenea1, and so on, which are not described herein.

As can be seen by comparing fig. 4 and fig. 2, compared with the conventional scheme, after the novel scheme is applied, the memory space of 2 physxscreena and 2 physxscreenb is obviously saved in the memory of the game server, which has extremely important application value for the MMOG scene of a large number of game copies of the same type.

According to the novel scheme for managing physical scene resources, multiple game copies of the same scene type access the static scene constructed by the same static physical scene resources, and independent dynamic physical scene resources are created for each game copy, so that physical entities dynamically added or deleted by each game copy are managed in the dynamic scene constructed by the dynamic physical scene resources, and because the multiple game copies of the same scene type multiplex the static scene constructed by the same static physical scene resources, the memory space of a game server is greatly saved.

The following will simply describe the process flow of the above-described novel scheme for managing physical scene resources.

Fig. 5 is a flowchart of a method for managing physical scene resources in a virtual world according to an embodiment of the present application. Referring to fig. 5, this embodiment is performed by a computer device, and is described taking the computer device as a game server as an example, and includes the steps of:

501. the game server determines a static physical entity for a plurality of virtual scenes with the same scene type in the virtual world from physical entities contained in the plurality of virtual scenes, wherein the static physical entity is a physical entity common to the plurality of virtual scenes and static.

In some embodiments, a variety of game copies are provided in the virtual world, a game copy being a virtual scene that a single person or team enters in the virtual world, similar to a block of space in the virtual world, without interfering with each other between different game copies.

In the conventional MMOG, the game map entered by the player on the different lines may be regarded as a game copy, for example, the player accessing the game server through the line 1 may enter the novice 1, the player accessing the game server through the line 2 may enter the novice 2, at this time, the novice 1 and the novice 2 are two different game copies belonging to the same copy type (same as the novice), and the virtual scene of the novice 1 and the virtual scene of the novice 2 are two different scene instances belonging to the same scene type. For another example, when a player enters other game maps (e.g., a main city) from a novice village, the novice village and the main city are two different game copies belonging to different copy types, and the virtual scene of the novice village and the virtual scene of the main city are two different scene instances belonging to different scene types.

In a seamless large world MMOG, the game map itself is a seamless large world rather than a game copy, as the virtual world is not divided into multiple game maps, but different types of game copies are typically provided in the virtual world for a player to challenge by a single person or team. For example, when players of different teams enter the same game copy, the players of the different teams actually enter different scene instances of the same game copy, so that the players of the different teams do not meet in the virtual scene of the game copy, i.e. the different scene instances of the same game copy do not interfere with each other, and stated another way, the players of the different teams are in scene instances of different virtual scenes of the same scene type. For another example, when players of different teams enter different game copies, their respective virtual scenes are different scene instances belonging to different scene types.

In some embodiments, the game server groups all virtual scenes in the virtual world of the MMOG game according to scene types of the virtual scenes, divides each virtual scene having the same scene type into the same scene group, and constructs static physical scene resources for multiplexing each virtual scene in the scene group for each scene group by using the scene group as a unit through the following step 502.

In some embodiments, one scene attribute information is stored for each virtual scene in the game server, and the scene attribute information is used to record a scene type ID (Identification) of the virtual scene and a scene instance ID of the virtual scene.

The scene type ID is determined by the copy type of the game copy corresponding to the virtual scene, and the same type of scene type ID is shared by the same kind of game copy, for example, class a copies A0, A1 and A2 of the same kind of scene type ID such as scenea_id in fig. 4, and class B copies A0, A1 and A2 of the same kind of scene type ID such as sceneb_id.

The scene instance ID is determined by the virtual scene itself, and different virtual scenes have different scene instance IDs no matter whether the scene types are the same or not, in other words, different virtual scenes with the same scene type in the same scene group have different scene instance IDs, and virtual scenes among different scene groups also have different scene instance IDs. For example, class a copies A0, A1 and A2 of the same type in fig. 4 have the same scene type ID such as scenea_id, but have mutually different scene instance IDs such as scenea_cd0 for the scene instance ID of game copy A0, scenea_cd1 for the scene instance ID of game copy A1, scenea_cd2 for the scene instance ID of game copy A2.

On the basis of the above, the game server accesses the scene attribute information of all the virtual scenes in the virtual world, and can inquire all the virtual scenes with the same scene type ID in the virtual world, wherein the virtual scenes are different scene instances with the same scene type and belonging to the same scene group.

In some embodiments, for a plurality of virtual scenes with the same scene type included in each scene group, a physical entity common to the plurality of virtual scenes is determined first, and then a static physical entity is further determined from the common physical entity, so as to obtain a static physical entity common to the plurality of virtual scenes and static. Alternatively, the static physical entity may be determined first, and then the common physical entity may be determined, or the common and static physical entity may be directly determined, which embodiment of the present application does not specifically limit the implementation of this determination step.

502. The game server builds the static physical scene resources multiplexed by the virtual scenes based on the static physical entity.

In some embodiments, after the game server determines the static physical entities that are common and static in multiple virtual scenes with the same scene type, based on each static physical entity determined in step 501, static physical scene resources that can be used for multiplexing the multiple virtual scenes are constructed, so that multiple static physical scene resources that are required to be constructed in the original multiple virtual scenes can be compressed into a static physical scene resource that can be used for multiplexing all virtual scenes in the same scene group, memory overhead of the game server is greatly saved, and resource utilization rate of the game server is optimized.

For example, multiple game copies with the same copy type belong to the same copy group, correspondingly, multiple virtual scenes of each of the multiple game copies also have the same scene type, and multiple virtual scenes with the same scene type belong to the same scene group, then, from physical entities contained in multiple virtual scenes in the scene group, a static physical entity is determined, as if the static physical entity in the same copy group is a physical entity such as a building, a road, a tree and the like in the virtual scene, and then, a static physical scene resource multiplexed by the scene group is constructed based on each determined static physical entity.

Schematically, as shown in fig. 4, for class a copies A0, A1 and A2 of the same type, the game server only constructs a reusable static physical scene resource, and a shared static scene physxscreena can be formed by using the static physical scene resource, so as to provide physical characteristic operation of a static physical entity in the static scene physxscreena externally, for example, realize ray detection of the static physical entity in the static scene physxscreena. Similarly, for the same type of B-class copies B0, B1 and B2, the game server also constructs a reusable static physical scene resource, through which a shared static scene physxscreenb can be formed, and it can be seen that the type a copy and the type B copy have different scene types due to different copy types, so that the type a copy and the type B copy cannot realize multiplexing of the static physical scene resource, but the scene instances of different copies under the type a copy can realize multiplexing of the static physical scene resource of the static scene physxscreena, and the scene instances of different copies under the type B copy can also realize multiplexing of the static physical scene resource of the static scene physxscreenb.

In some embodiments, after constructing the reusable static physical scene resource for a plurality of virtual scenes having the same scene type, the game server may further store scene type IDs of the same scene type of the plurality of virtual scenes in association with the static physical scene resource. Optionally, the association relationship between each virtual scene and its static physical scene resource in the same scene group is managed in a KV (Key-Value) data structure in the game server.

In one example, in the scene attribute information of each virtual scene mentioned in the above step 501, the originally recorded scene type ID is modified into a static scene KV structure, where the static scene KV structure uses the scene type ID of the virtual scene as a Key (Key name) and uses a pointer to the memory address of the static physical scene resource as a Value (Key Value), which means that, for all virtual scenes in the same scene group, the same static physical scene resource is multiplexed and shared by the same scene type ID, and therefore, the same static scene KV structure is recorded in the scene attribute information of all virtual scenes in the same scene group.

503. The game server respectively builds a plurality of dynamic physical scene resources for the plurality of virtual scenes, wherein each dynamic physical scene resource is used for storing dynamic physical entities except the static physical entity in one virtual scene.

In some embodiments, since there is a service requirement for dynamically adding or deleting physical entities to a virtual scene in a game, for example, when a player calls out a virtual vehicle in a virtual scene, the physical entities of the virtual vehicle (the entity type is a carrier) need to be dynamically added to the virtual scene, and when the player withdraws the called virtual vehicle, the physical entities of the virtual vehicle need to be adaptively removed from the virtual scene, so as to meet the service requirement, the game server may separately construct a dynamic physical scene resource for each virtual scene of the same scene type, so as to separately manage the physical entities that need to be dynamically added or deleted in the corresponding virtual scene through the dynamic physical scene resource, so as to avoid adverse effects on externally provided game copy services.

In some embodiments, for any virtual scene involved in the multiple virtual scenes, in the initialization stage, the game server may construct an empty dynamic physical scene resource for the virtual scene, and as the game progress is executed, according to an operation instruction at the game client side, the main logic process of the game may determine whether the operation instruction involves adding/deleting a dynamic physical entity, where the dynamic physical entity refers to a physical entity other than the static physical entity in the virtual scene. Then, when the operation instruction relates to the dynamic physical entity to be added, the game server can add the dynamic physical entity in the virtual scene into the dynamic physical scene resource; when the operation instruction relates to the dynamic physical entity to be deleted, the game server can delete the dynamic physical entity from the dynamic physical scene resource of the virtual scene, so that flexible management of the dynamic physical entity is realized.

In the process, the dynamic physical scene resource is set to be empty in the initialization stage, and the decision of which processing is to be carried out on the dynamic virtual scene resource is made according to the operation instruction in the game process, so that the dynamic virtual scene resource can keep extremely high adaptation with the operation instruction at the game client side, and memory is hardly occupied in the initialization stage, thereby realizing flexible management of the dynamic physical entity.

Illustratively, as shown in fig. 4, for class a copies A0, A1 and A2 of the same type, although the static physical scene resources of the same static scene physoena can be multiplexed, there may be different service requirements for dynamically adding or deleting physical entities in the game copies A0, A1 and A2, for example, a player entering the game copy A0 calls a virtual vehicle, a player entering the game copy A1 calls a virtual aircraft, a player entering the game copy A2 does not call any virtual object, at this time, dynamic physical entities of different entity types need to be added in the game copies A0 and A1, and dynamic physical entities do not need to be added in the game copy A2. Therefore, the game server may separately create dynamic physical scene resources of the dynamic scene mainland scenea0 for the game copy A0, separately create dynamic physical scene resources of the dynamic scene mainland scenea1 for the game copy A1, separately create dynamic physical scene resources of the dynamic scene mainland scenea2 for the game copy A2, initialize the dynamic physical scene resources of each game copy to be empty in the initialization stage, and gradually add or delete dynamic physical entities in the dynamic scene as the game progresses, for example, in the previous example, a dynamic physical entity with an entity type being a carrier needs to be newly added to the virtual vehicle in the dynamic scene mainland scenea0 of the game copy A0, and similarly, a dynamic physical entity with an entity type being a carrier needs to be newly added to the virtual vehicle in the dynamic scene mainland scenea1 of the game copy A1.

In some embodiments, the game server may further store the scenario instance ID of each virtual scenario in the plurality of virtual scenarios in association with the dynamic physical scenario resource of each virtual scenario after individually constructing the dedicated dynamic physical scenario resource for each virtual scenario in the plurality of virtual scenarios having the same scenario type. Optionally, the association relationship between each virtual scene in the same scene group and the dynamic physical scene resource is managed in a KV data structure in the game server.

In one example, in the scene attribute information of each virtual scene mentioned in the above step 501, the originally recorded scene instance ID is modified into a dynamic scene KV structure, where the dynamic scene KV structure uses the scene instance ID of the virtual scene as a Key and uses a pointer pointing to the memory address of the dynamic physical scene resource as a Value, so that it is known that, for each virtual scene in the same scene group, although the same static scene KV structure is recorded in the scene attribute information, since the scene instance ID and the dynamic physical scene resource are different, different scene instances have different dynamic scene KV structures.

504. The game server provides relevant services related to calling physical scenes for any one of the virtual scenes based on the static physical scene resources and dynamic physical scene resources constructed for the virtual scenes.

In the steps 502-503, for any virtual scene provided by the virtual world of the MMOG game, a dynamic physical scene resource is created for the virtual scene separately, further, according to the scene type of the virtual scene, a static physical scene resource which can be reused by all virtual scenes with the scene type can be queried, thus, by combining the dynamic physical scene resource with the static physical scene resource, a physical scene resource complete with the virtual scene can be obtained, relevant parameters of static physical entities in the relevant virtual scene are stored in the static physical scene resource, relevant parameters of dynamic physical entities in the relevant virtual scene are stored in the dynamic physical scene resource, so that the multiplexing of the static physical scene resource of the virtual scene with the same scene type can be realized in a background of the game server in a mode of separating the dynamic and static physical scene resource, and for N (N is more than or equal to 2) virtual scenes with the same scene type, only the complete physical scene resource of N is needed to be stored, after the scheme is applied, the number of the static physical scene is obviously 1 static scene and N is more than or more than N is needed, namely, the number of the same physical scene is more than 1, and the memory cost is obviously more than the number of the same in the same physical scene is increased.

Based on the above management scheme that the game server performs dynamic and static separation on physical scene resources, for each virtual scene in the virtual world, dedicated dynamic physical scene resources and static physical scene resources multiplexed by each virtual scene of the same scene type can be combined, related services for performing physical characteristic calculation on physical entities in the current virtual scene are provided for the outside through a physical engine, for example, the physical engine provides an interface for calling related services of the physical scene for the outside, a main logic process can call a certain interface (such as a ray detection interface) provided by the physical engine, a ray detection function is triggered to be started by the physical engine for the current virtual scene, and a ray detection mode will be described in detail in a next embodiment.

All the above optional solutions can be combined to form an optional embodiment of the present disclosure, which is not described in detail herein.

According to the method provided by the embodiment of the invention, the same static physical scene resource is multiplexed for all virtual scenes of the same scene type, and a dynamic physical scene resource is independently established for each virtual scene to support the service requirement of dynamically adding or deleting physical entities in different virtual scenes, so that the memory overhead occupied by the static physical scene resource which is originally stored repeatedly is greatly saved through a dynamic and static separation mode, the related service of the externally provided physical scene is ensured not to be adversely affected through a dynamic and static combination mode, and the memory occupation of the physical scene resource on a game server is improved and the processing performance of the game server is optimized on the premise that the service requirement and the service are not limited.

In the above embodiment, the process flow of the management scheme of the physical scene resource in the virtual world is described in detail, and in the embodiment of the present application, how the game server provides the radiation detection service to the outside through the physical engine will be described.

Fig. 6 is a flowchart of a ray detection method based on a management scheme of physical scene resources in a virtual world according to an embodiment of the present application. Referring to fig. 6, this embodiment is performed by a computer device, and is described taking the computer device as a game server as an example, and includes the steps of:

601. and the game server receives the operation instruction synchronized by the game client through the main thread of the GameSvr process.

In some embodiments, a GameSvr process is created in a game server to provide basic play logic for a game, wherein the GameSvr process involves a main thread for running the subject play logic for the game and a simulation thread for implementing simulated computation of the physical world by a physics engine.

In some embodiments, the player can control the virtual object to move in the virtual scene of the game copy on the game client on the terminal, for example, the player controls the virtual object to move from a designated starting point to a designated end point, or the player controls the virtual object to move from the designated starting point to a target azimuth by a designated distance, and the like, at this time, the game client responds to the moving operation of the player and sends an operation instruction for controlling the virtual object to move to the game server, wherein the operation instruction carries displacement indication information, and the displacement indication information is used for indicating the displacement starting point and the displacement end point of the current displacement.

In some embodiments, a player can also control a virtual object to fire in a virtual scene of a game copy by using a virtual prop on a game client, for example, the player controls the virtual object to fire to a designated target by using a shooting prop, or controls the virtual object to fire to the designated target by using a throwing prop, and the like, at this time, the game client responds to the firing operation of the player and sends an operation instruction for controlling the virtual object to fire to a game server, wherein the operation instruction carries interaction indication information, and the interaction indication information is used for indicating an interaction starting point and a designated target (the firing direction can be designated, or the shooting target can be designated, and the like) of the firing.

In some embodiments, the game server receives an operation instruction synchronized by the game client through the main thread of the GameSvr process, analyzes the operation instruction, determines whether the operation instruction needs to call a radiation detection interface provided by the physical engine, for example, when the operation instruction carries at least one of displacement indication information or interaction indication information, and represents that the operation needs to call the radiation detection interface to determine whether the displacement is legal or whether the firing target is hit, determines that the operation instruction shoots and calls the radiation detection interface, and performs step 602 described below, otherwise, does not need to call the radiation detection interface, and exits the process.

602. In the case that the operation instruction relates to a ray detection interface of a call physical engine, the game server determines rays to be detected in the virtual scene based on the operation instruction through a simulation thread of a GameSvr process.

In some embodiments, the game server determines a service type of the related service related to the invoked physical scene when detecting that an operation instruction of the game client relates to the related service of the invoked physical scene, and if the operation instruction relates to the invoked physical scene, invokes a ray detection interface provided by a simulation thread corresponding to a main thread to be passed through a GameSvr process, and then the simulation thread determines a ray to be detected in the virtual scene based on the operation instruction invoking the ray detection service.

In some embodiments, the game server analyzes the operation instruction to obtain displacement indication information, and then determines a displacement starting point and a displacement end point in the virtual scene according to the displacement indication information, then uses the displacement starting point as a ray starting point and the displacement end point as a ray end point, and determines a ray to be detected from the ray starting point to the ray end point in the virtual scene.

In some embodiments, the game server parses the operation instruction to obtain interaction indication information, and then determines an interaction starting point and a specified target in the virtual scene according to the interaction indication information, then uses the interaction starting point as a ray starting point, uses the specified target as a ray end point, and determines a to-be-detected ray from the ray starting point to the ray end point in the virtual scene.

In the process, the ray starting point and the ray end point of the ray to be detected in the virtual scene are determined by analyzing the operation instruction, so that the ray to be detected, which is sent from the ray starting point to the ray end point, can be determined in the virtual scene, the ray detection is realized in the dynamic scene and the static scene respectively, and the final blocking detection result is comprehensively determined by combining the detection results of the dynamic scene and the static scene, so that the high availability and the service accuracy of the external ray detection service under the dynamic-static separation physical scene resource management scheme are ensured.

603. And the game server performs blocking detection on the rays in the static scene formed by the static physical scene resources through the simulation thread to obtain a static scene detection result.

In some embodiments, the game server drives the physical engine to construct a static scene which can be used for detecting rays in common by all virtual scenes in one copy group based on the multiplexed static physical scene resources by simulating threads, the static scene comprises all static physical entities which are shared and static, then, in the static scene constructed by the physical engine, the blocking detection is performed once on the rays obtained in the step 602, namely, whether blocking static physical entities exist on a ray path from a ray starting point to a ray ending point is judged in the static scene, if blocking static physical entities exist on the ray path, the static scene detection result is set to be blocking, and the intersection points of all static physical entities with blocking and the ray path on the ray path are further obtained as static blocking points; accordingly, if there is no blocking static physical entity on the ray path, the static scene detection result is set to be non-blocking, and step 604 is entered.

604. And the game server performs blocking detection on the rays in the dynamic scene formed by the dynamic physical scene resources through the simulation thread to obtain a dynamic scene detection result.

In some embodiments, the game server drives the physical engine to construct a dynamic scene unique to the virtual scene based on the dynamic physical scene resource exclusive to the virtual scene by simulating the thread for each virtual scene in the copy group, wherein the dynamic scene comprises dynamic physical entities dynamically added for the virtual scene, and then, in the dynamic scene constructed by the physical engine, the ray obtained by the step 602 is subjected to another ray detection, namely, whether a blocked dynamic physical entity exists on a ray path from a ray starting point to a ray ending point is judged in the dynamic scene, if the blocked dynamic physical entity exists on the ray path, the dynamic scene detection result is set to be blocked, and the intersection points of all the dynamic physical entities with the ray path which are blocked on the ray path are further obtained as dynamic blocking points; accordingly, if there is no blocking dynamic physical entity on the ray path, the dynamic scene detection result is set to be non-blocking, and step 605 is entered.

Schematically, when the ray detection is performed on the virtual scene of any game copy, on one hand, one-time blocking detection is required to be performed on all static physical entities in the static scene PhysxScene multiplexed by the copy group to which the virtual scene belongs, and on the other hand, one-time blocking detection is also required to be performed on all dynamic physical entities in the dynamic scene MainlandScene exclusive to the current copy, so that whether the ray intersects with the static physical entity or the dynamic physical entity can be comprehensively detected, and the accuracy of the ray detection service under the dynamic and static separated physical scene resource management scheme is ensured.

It should be noted that, in the embodiment of the present application, only the blocking detection of the static scene is performed by the step 603 first, and then the blocking detection of the dynamic scene is performed by the step 604, alternatively, the simulation thread may also perform the blocking detection of the dynamic scene by the step 604 first, and then the blocking detection of the static scene is performed by the step 603, alternatively, the simulation thread may also perform the blocking detection of the static scene in the step 603 and the blocking detection of the dynamic scene in the step 604 simultaneously, and the execution timing of the steps 603 and 604 is not limited specifically in the embodiment of the present application.

In the process, by respectively performing blocking detection in the dynamic scene and performing blocking detection in the static scene, a ray detection mode with high availability and high accuracy under a dynamic-static separation physical scene resource management scheme is provided, and the blocking detection result for the whole virtual scene can be determined by combining the respective detection results of the dynamic scene and the static scene.

605. The game server determines a blocking detection result of the ray in the virtual scene based on the static scene detection result and the dynamic scene detection result through the simulation thread.

In some embodiments, after the static scene detection result is obtained in step 603 and the dynamic scene detection result is obtained in step 604, the game server determines a blocking detection result of the ray in the whole virtual scene based on the static scene detection result and the dynamic scene detection result.

Considering that the static scene detection result and the dynamic scene detection result have different processing logic in different cases, the following discussion will be given in terms of (1) and (2), respectively.

(1) The static scene detection result and the dynamic scene detection result are both unobstructed

If the static scene detection result and the dynamic scene detection result are both non-blocking, it is indicated that the ray has no blocking static physical entity in the reusable static scene PhysxScene and has no blocking dynamic physical entity in the exclusive dynamic scene MainlandScene, and the blocking detection result of the virtual scene on the ray can be set to be non-blocking because the ray has no blocking static physical entity and no blocking dynamic physical entity in the whole virtual scene.

In the above process, by setting the final blocking detection result to be non-blocking under the condition that no blocking physical entity exists in both the static scene PhysxScene and the dynamic scene MainlandScene, the high-accuracy ray detection service under the dynamic-static separation physical scene resource management scheme can be realized by respectively executing the blocking detection twice in the dynamic scene and the static scene.

(2) At least one of the static scene detection result and the dynamic scene detection result is blocked

If at least one of the static scene detection result and the dynamic scene detection result is blocked, the ray is indicated to have a blocked static physical entity at least in the static scene, or to have a blocked dynamic physical entity at least in the dynamic scene, or to have both a blocked static physical entity in the static scene and a blocked dynamic physical entity in the dynamic scene, at this time, the simulation thread may directly set the blocking detection result as blocked, and return a blocking point determined based on the static scene detection result and the dynamic scene detection result.

In the above process, by setting the final blocking detection result to be blocked under the condition that at least one of the static scene PhysxScene and the dynamic scene MainlandScene has blocking physical entities, the high-accuracy ray detection service under the dynamic-static separation physical scene resource management scheme can be realized by respectively executing the blocking detection twice in the dynamic scene and the static scene.

Further, since the final blocking detection result is blocking, the simulation thread also needs to return the blocking point (such as the position coordinate of the returned blocking point) which is the intersection point between the physical entity with the blocking existing in the main thread and the ray path, and at this time, the simulation thread needs to determine one or more blocking points to be returned at this time based on the static scene detection result and the dynamic scene detection result, and then returns the one or more blocking points to the main thread.

Since in the case where at least one of the static scene detection result and the dynamic scene detection result is blocked, there are three possibilities: only the static scene detection result is blocked, only the dynamic scene detection result is blocked, and both the static scene detection result and the dynamic scene detection result are blocked, so three cases (2-1), (2-2) and (2-3) will be discussed below.

(2-1) the static scene detection result is blocked, and the dynamic scene detection result is unblocked

If the static scene detection result is blocked and the dynamic scene detection result is unblocked, it is described that only the static physical entity blocked in the static scene PhysxScene needs to be considered at this time, so that the static blocking point detected by the simulation thread in the static scene PhysxScene can be directly taken, that is, the simulation thread returns to the main thread the static blocking point of the static physical entity touched by the ray in the static scene PhysxScene.

In some embodiments, if a ray encounters only one static physical entity in the static scene physxscreen, the simulation thread directly returns, to the main thread, a blocking point where the static physical entity intersects the ray, for example, returns a position coordinate of the blocking point, or returns a vertex number of the blocking point on a three-dimensional model of the static physical entity, which is not specifically limited in the embodiment of the present application.

In some embodiments, if a ray encounters two or more static physical entities in the static scene PhysxScene, at this time, before invoking the ray detection interface, the main thread may determine whether to require returning all blocking points based on the operation instruction, if the service requested by the operation instruction requires returning all blocking points, the main thread may instruct the simulation thread to return all blocking points when invoking the ray detection interface, at this time, the simulation thread will acquire two or more static blocking points for the two or more static physical entities and return all static blocking points detected to the main thread, and optionally, return the distance between each static blocking point and the ray starting point to the main thread, so that the main thread performs additional game logic operation; if the service requested by the operation instruction does not need to return all the blocking points, the main thread does not need to additionally instruct or instruct the simulation thread to return only the blocking point closest to the ray detection interface when the ray detection interface is called, and at this time, the simulation thread calculates the distances between all the static blocking points and the ray starting point and returns the static blocking point closest to the ray starting point.

In one example, the ray detection interface provided by the simulation thread may configure an indication parameter for returning all blocking points, where the indication parameter may be binary data, for example, when the indication parameter is 1, indicating that all blocking points need to be returned, when the indication parameter is 0, indicating that all blocking points need not to be returned, and the technician may also configure a default value of the indication parameter, so that when the ray detection interface is called, the main thread may instruct the simulation thread to return a blocking point closest to the simulation thread, or return all blocking points, for example, when the indication parameter is 0, the main thread may transmit the indication parameter to the simulation thread to be 1, thereby indicating that all blocking points are returned by the simulation thread, and when the indication parameter is 0 or less, the main thread transmits the indication parameter to the simulation thread, thereby indicating that the simulation thread returns a blocking point closest to the simulation thread.

In another example, the above indication parameter may be boolean data, where when the indication parameter value is True, it means that all blocking points need to be returned, when the indication parameter value is False, it means that all blocking points need not to be returned, and the technician may also configure a default value of the indication parameter, so that when the main thread invokes the ray detection interface, the main thread may instruct the simulation thread to return to the blocking point closest to the main thread by assigning a value to the indication parameter, or return to all blocking points, if the indication parameter default value is False, the main thread may transmit the indication parameter True to the simulation thread, thereby instruct the simulation thread to return to all blocking points, and the main thread transmits the indication parameter False or lack thereof to the simulation thread, thereby instructing the simulation thread to return to the blocking point closest to the main thread.

(2-2) the static scene detection result is non-blocking, and the dynamic scene detection result is blocking

If the static scene detection result is non-blocking and the dynamic scene detection result is blocking, the method only needs to consider that a blocking dynamic physical entity exists in the dynamic scene mainland scene at the moment, so that a dynamic blocking point detected by a simulation thread in the dynamic scene mainland scene can be directly taken, namely, the simulation thread returns the dynamic blocking point of the dynamic physical entity, which is encountered by the ray in the dynamic scene mainland scene, to the main thread.

In some embodiments, if a ray encounters only one dynamic physical entity in the dynamic scene mainland scene, the simulation thread directly returns to the main thread a blocking point where the dynamic physical entity intersects the ray, for example, returns to a position coordinate of the blocking point, or returns to a vertex number of the blocking point on a three-dimensional model of the dynamic physical entity, which is not specifically limited in the embodiment of the present application.

In some embodiments, if a ray encounters two or more dynamic physical entities in the dynamic scene mainland scene, at this time, before the ray detection interface is invoked, the main thread may determine whether to require returning all blocking points based on the operation instruction, if the service requested by the operation instruction requires returning all blocking points, the main thread may instruct the simulation thread to return all blocking points when invoking the ray detection interface, at this time, the simulation thread will acquire two or more dynamic blocking points for two or more dynamic physical entities, and return all the detected dynamic blocking points to the main thread, and optionally, return the distance between each dynamic blocking point and the ray origin to the main thread, so that the main thread performs additional game logic operation; if the service requested by the operation instruction does not need to return all the blocking points, the main thread does not need to additionally instruct or instruct the simulation thread to return only the blocking point closest to the ray detection interface when the ray detection interface is called, and at this time, the simulation thread calculates the distances between all the dynamic blocking points and the ray starting point and returns the dynamic blocking point closest to the ray starting point.

In an example, the ray detection interface provided by the simulation thread may configure an indication parameter that returns all blocking points, so as to determine whether to return all blocking points according to the indication parameter that is transmitted by the main thread when the ray detection interface is called, and the configuration mode of the indication parameter is the same as that described in (2-1), which is not repeated here.

(2-3) both the static scene detection result and the dynamic scene detection result are blocked

If both the static scene detection result and the dynamic scene detection result are blocked, it is indicated that at this time, both a static physical entity blocked in the static scene PhysxScene and a dynamic physical entity blocked in the dynamic scene MainlandScene need to be considered, so that the simulation thread can respectively obtain a static blocking point of the static physical entity touched by the ray in the static scene and a dynamic blocking point of the dynamic physical entity touched by the ray in the dynamic scene, and then determine a target blocking point returned at this time based on the static blocking point and the dynamic blocking point, and return the determined target blocking point to the main thread.

In some embodiments, in the case that both the static scene detection result and the dynamic scene detection result are blocked, the number of target blocking points returned by the simulation thread is determined based on the interface type of the main thread calling the ray detection interface, for example, the simulation thread provides two types of ray detection interfaces to the outside, one is a single ray detection interface raycast single, which only needs to return the blocking point closest to the single ray detection interface raycast single, and the other is a multi-ray detection interface raycast multi, which needs to return a list of blocking points.

In some embodiments, if both the static scene detection result and the dynamic scene detection result are blocked, the simulation thread may determine the interface type used by the operation instruction of the game client when the ray detection service is invoked, i.e., the simulation thread determines which ray detection interface the main thread invokes in response to the operation instruction of the game client.

Optionally, if the interface type called at this time is a single-ray detection interface rayastsingle, the simulation thread may determine distances between each of all static blocking points and all dynamic blocking points and a ray starting point from all static blocking points detected in a static scene physconce and all dynamic blocking points detected in a dynamic scene mainland scene, determine a blocking point closest to the ray starting point as a target blocking point, and return the determined target blocking point to the main thread.

Optionally, if the interface type of the call is a multi-time ray detection interface raycast multi, the simulation thread may calculate distances between each of all static blocking points detected in the static scene physconce and all dynamic blocking points detected in the dynamic scene mainland scene and a ray starting point, then sort all static blocking points and all dynamic blocking points according to a sequence from near to far from the ray starting point, to obtain a blocking point list, determine each blocking point in the blocking point list as a target blocking point, and return the determined target blocking point, namely, the blocking point list, to the main thread.

In the above process, whether to return a target blocking point closest to the current time or to return a blocking point list sequentially arranged from the near to the far order from the ray starting point is judged by judging the interface type of the ray detection interface called by the main thread, so that the main thread is not required to transfer indication parameters to the simulation thread, but different types of ray detection interfaces are provided, so that different types of target blocking points are returned for different interface types, and the communication overhead between the main thread and the simulation thread can be saved.

In other embodiments, the main thread may also configure whether to return a target blocking point or return a blocking point list under the situation that both the static scene detection result and the dynamic scene detection result are blocked by using the indication parameters described in the above (2-1), and the configuration mode of the indication parameters is the same and is not repeated here.

In the three cases (2-1), (2-2) and (2-3), the method for acquiring blocking points in the final blocking detection result under different conditions is discussed separately, the static scene is multiplexed for the same game copy, and the dynamic scene is independently created for different copy examples, and a secondary ray detection mechanism is introduced to perfect the ray detection mode under the dynamic and static separated physical scene resource management scheme, so that the memory resource configuration strategy of the game server can be optimized through the dynamic and static separated physical scene resource management scheme under the condition that the ray detection service is not limited.

Further, in each case of (2-1), (2-2) and (2-3), a blocking point closest to the blocking point can be flexibly returned according to service requirements, or all blocking points can be returned, so that the radiation detection service has wide applicability.

In other embodiments, when the simulation thread maintains the physical scene resource for each game copy, it may also determine whether the virtual scene to be detected has a service requirement of a dynamically added or deleted physical entity, if the service requirement does not exist, the dynamic physical scene resource is not required to be maintained separately for the game copy, and the dynamic scene mainland scene of the game copy is removed.

606. The game server returns the blocking detection result to the main thread through the simulation thread.

In some embodiments, after determining the final blocking detection result through the above step 605 by the simulation thread through two blocking detections performed in the dynamic scene and the static scene respectively, the blocking detection result may be returned to the main thread through the ray detection interface.

Optionally, when the blocking detection result is that there is a blocking, the detected blocking point may also be carried in the blocking detection result, for example, a position coordinate of the blocking point returned by the simulation thread, or a vertex number of the returning blocking point on the three-dimensional model of the static physical entity, which is not specifically limited in the method for returning the blocking point in the embodiment of the present application.

As shown in fig. 7, the logic principle of the above-mentioned ray detection scheme is shown, when the ray detection interface of the simulation thread is called by the main thread, the blocking detection is performed in the static scene physxscreen to determine whether there is a static physical entity blocked in the static scene physxscreen to obtain a static scene detection result, and then the blocking detection is performed in the dynamic scene mainland screen regardless of whether the static scene detection result is blocked or not to determine whether there is a dynamic physical entity blocked in the dynamic scene mainland screen to obtain a dynamic scene detection result. If the unobstructed blocking is detected in the static scene PhysxScene and the blocking is detected in the dynamic scene MainlandScene, a dynamic scene detection result of the dynamic scene MainlandScene is obtained; if blocking is detected in the static scene PhysxScene and unblocking is detected in the dynamic scene MainlandScene, a static scene detection result of the static scene PhysxScene is taken; if the results of the two blocking detection are both non-blocking, setting the final blocking detection result as non-blocking; if the structures of the two blocking detection are blocked, the two detection results are required to be combined to obtain a final blocking detection result, alternatively, the combination rule is that for a single ray detection interface RaycastSingle, a blocking point closest to a ray starting point is taken as a target blocking point returned in the blocking detection result, for a multi-ray detection interface RaycastMulti, all blocking points detected by the two blocking detection are formed into a blocking point list, all blocking points in the blocking point list are ordered according to the sequence from near to far from the ray starting point, and the ordered blocking point list is taken as a target blocking point returned in the blocking detection result.

In the above process, according to the dynamic and static separated physical scene resource management scheme provided in the previous embodiment, since static unchanged physical scene resources in each game copy with the same scene type are extracted to form a public static scene PhysxScene, and a dynamic scene MainlandScene is independently established for each game copy to manage dynamically added or deleted physical entities in the corresponding game copy, all scene instances (i.e. all virtual scenes in the same scene group) in the same game copy can multiplex the same static scene PhysxScene, and only two blocking detections are needed in the static scene PhysxScene and the dynamic scene MainlandScene respectively during ray detection, and then the detection results are combined, so that the memory overhead of the system can be greatly saved under the condition of ensuring that the ray detection service is not adversely affected.

607. The game server returns an operation response generated based on the blocking detection result to the game client through the main thread, wherein the operation response corresponds to the operation instruction.

In some embodiments, the main thread receives the blocking detection result returned by the emulation thread, but it is likely that some game logic operations will be performed based on the blocking detection result to generate a final operation response for the game client's operation instructions, so that after the operation response is generated, the main thread returns the operation response to the game client.

Schematically, the operation instruction is a displacement instruction for the virtual object, if the blocking detection result is non-blocking, an operation response indicating that the displacement is legal may be returned, and if the blocking detection result is blocking, an operation response indicating that the virtual object is automatically stopped after moving to the blocking point may be returned.

The operation instruction is an interactive instruction for controlling firing and shooting of the virtual object, if the blocking detection result is non-blocking, whether the emission object hits the shooting target along the original emission track can be further judged, an operation response indicating whether the emission object hits the shooting target is returned, if the blocking detection result is blocking, an operation response indicating that the emission object hits a physical entity to which the blocking point belongs in the middle of the movement of the emission track can be returned, whether the emission object is to continue to hit other physical entities is judged according to whether the emission object has penetrability or not, and the specific mode can be judged by game logic of the main thread, wherein the operation response is not expanded.

According to the dynamic and static separated physical scene resource management scheme provided by the embodiment of the application, static unchanged physical scene resources in all game copies with the same scene type are extracted to form a public static scene PhysxScene, and a dynamic scene MainlandScene is independently built for each game copy, so that all scene instances (namely all virtual scenes in the same scene group) under the same game copy can multiplex the same static scene PhysxScene for ray detection, and through a two-time ray detection mechanism, the detection results are combined only by respectively detecting in the multiplexed static scene PhysxScene and the dedicated dynamic scene MainlandScene, and the memory overhead of the system can be greatly saved under the condition that the ray detection service is not influenced.

In the following, an MMOG game will be taken as an example, and performance test results of a game server will be described before and after application of a dynamic and static separated physical scene resource management scheme. In the performance test scenario, the following categories of performance parameter indicators are considered for the game server: memory occupancy, CPU (Central Processing Unit ) occupancy, file handle number, VIRT (Virtual Memory Usage, virtual memory) and RES (Resident Memory Usage, resident memory). The file handle number is used for measuring the number of processes maintained by the system background, the file handle number is increased along with the increase of the number of processes, the VIRT refers to the virtual memory of the system background, the virtual memory size required by the GameSvr process is represented, the RES refers to the resident memory of the system background, and the memory size actually used by the GameSvr process at present is represented.

As shown in table 1, for an MMOG game in which there are a large number of similar game copies, there are 800 PVE (Player VS Environment, player challenge environment) type game copies in the test scenario, and it is assumed that 800 players enter 800 single copy instances respectively, the game server performance overhead of applying the conventional scheme is as follows:

TABLE 1

Performance parameters	Maximum value	Minimum value	Average value of	Median value	Value of 90%
						Memory occupancy (percentage)	24.62	13.05	23.67	23.94	24.35
CPU occupancy rate (percentage)	94.93	14.44	75.47	76.78	86.58
						Number of file handles	70	69	69	70	70
VIRT(KB)	40478844	37226740	40135988	40070932	40329320
						RES(KB)	16161236	8566040	15543777	15859932	16158332

As shown in table 2, after the application of the dynamic and static separated physical scene resource management scheme, the performance overhead of the game server is as follows:

TABLE 2

Performance parameters	Maximum value	Minimum value	Average value of	Median value	Value of 90%
						Memory occupancy (percentage)	21.92	13.24	21.34	20.33	21.90
CPU occupancy rate (percentage)	86.98	11.63	70.50	72.36	83.22
						Number of file handles	70	69	69	70	70
VIRT(KB)	38757988	37442272	38662584	38732144	38752796
						RES(KB)	14392124	8693292	14014347	14329768	14387900

Comparing tables 1 and 2, it can be seen that after the dynamic and static separated physical scene resource management scheme is applied, the memory overhead of about 1.5G in the game server is remarkably saved, and the CPU consumption of the game server is reduced.

As shown in table 3, for an MMOG game with a small number of similar game copies, it is assumed that 800 players are in the test scenario, 24 people need to be grouped into the same game copy to play the inter-Player countermeasure, and about 33 PVP (Player VS Player countermeasure) type game copies need to be maintained, and the performance overhead of the game server applying the conventional scheme is as follows:

TABLE 3 Table 3

Performance parameters	Maximum value	Minimum value	Average value of	Median value	Value of 90%
						Memory occupancy (percentage)	15.61	13.03	15.47	15.10	15.59
CPU occupancy rate (percentage)	48.19	5.20	31.79	37.58	43.18
						Number of file handles	71	69	69	70	71
VIRT(KB)	37435884	37292812	37427132	37431332	37435300
						RES(KB)	10250504	8558196	10161048	10204084	10244476

As shown in table 4, after the application of the dynamic and static separated physical scene resource management scheme, the performance overhead of the game server is as follows:

TABLE 4 Table 4

Performance parameters	Maximum value	Minimum value	Average value of	Median value	Value of 90%
						Memory occupancy (percentage)	15.85	13.54	15.74	15.30	15.84
CPU occupancy rate (percentage)	46.37	5.19	30.67	36.99	42.82
						Number of file handles	70	69	69	70	70
VIRT(KB)	37523268	37516200	37522448	37518504	37523136
						RES(KB)	10409552	8888308	10338024	10378200	10404572

As can be seen from comparing table 3 and table 4, after the dynamic and static separated physical scene resource management scheme is applied, the memory overhead and CPU consumption of the game server are also reduced.

It can be seen that the dynamic and static separated physical scene resource management scheme can reduce the memory overhead and the CPU consumption of the game server for the MMOG games with fewer similar game copies, and can obviously reduce the memory overhead and the CPU consumption of the game server for the MMOG games with more similar game copies.

Fig. 8 is a schematic structural diagram of a management apparatus for physical scene resources in a virtual world according to an embodiment of the present application, where, as shown in fig. 8, the apparatus includes:

a determining module 801, configured to determine, for a plurality of virtual scenes with the same scene types in the virtual world, a static physical entity from physical entities included in the plurality of virtual scenes, where the static physical entity is a physical entity that is common to and static by the plurality of virtual scenes;

A construction module 802, configured to construct a static physical scene resource multiplexed by the multiple virtual scenes based on the static physical entity;

the building module 802 is further configured to build a plurality of dynamic physical scene resources for the plurality of virtual scenes, where each dynamic physical scene resource is used to store a dynamic physical entity except the static physical entity in one virtual scene;

a service module 803 is provided for providing, for any one of the plurality of virtual scenes, a related service related to invoking a physical scene based on the static physical scene resource and the dynamic physical scene resource constructed for the virtual scene.

According to the device provided by the embodiment of the application, the same static physical scene resource is multiplexed for all virtual scenes of the same scene type, and a dynamic physical scene resource is independently established for each virtual scene to support the service requirement of dynamically adding or deleting physical entities in different virtual scenes, so that the memory overhead occupied by the static physical scene resource which is originally stored repeatedly can be greatly saved through a dynamic and static separation mode, the related service of the externally provided physical scene is ensured not to be adversely affected through a dynamic and static combination mode, and the memory occupation of the physical scene resource on a game server is improved and the processing performance of the game server is optimized on the premise that the service requirement and the service are not limited.

In some embodiments, based on the apparatus composition of fig. 8, the providing service module 803 includes:

a ray determination unit, configured to determine a ray to be detected in the virtual scene based on an operation instruction for calling the ray detection service, in a case where the related service is the ray detection service;

the blocking detection unit is further used for blocking detection of the ray in a dynamic scene formed by the dynamic physical scene resource to obtain a dynamic scene detection result;

and the result determining unit is used for determining a blocking detection result of the ray in the virtual scene based on the static scene detection result and the dynamic scene detection result.

In some embodiments, based on the apparatus composition of fig. 8, the result determination unit includes:

In some embodiments, the return subunit is to:

if the static scene detection result is non-blocking and the dynamic scene detection result is blocking, returning to a dynamic blocking point of a dynamic physical entity which is touched by the ray in the dynamic scene.

In some embodiments, the return subunit is to:

In some embodiments, the return subunit is further to:

and if the interface type is a multi-ray detection interface, sequencing the static blocking points and the dynamic blocking points according to the sequence from the starting point of the ray to the far, obtaining a blocking point list, and determining the blocking point list as the target blocking point.

In some embodiments, the building block 802 is configured to:

constructing an empty dynamic physical scene resource for any virtual scene;

and adding the dynamic physical entity in the virtual scene into the dynamic physical scene resource, wherein the dynamic physical entity refers to physical entities except the static physical entity in the virtual scene.

In some embodiments, the apparatus based on fig. 8 is composed, the apparatus further comprising:

It should be noted that: the management device for physical scene resources in the virtual world provided in the above embodiment only illustrates the division of the above functional modules when managing physical scene resources, and in practical application, the above functional allocation can be completed by different functional modules according to needs, that is, the internal structure of the computer device is divided into different functional modules to complete all or part of the functions described above. In addition, the device for managing physical scene resources in the virtual world provided in the above embodiment belongs to the same concept as the embodiment of the method for managing physical scene resources in the virtual world, and the specific implementation process of the device is detailed in the embodiment of the method for managing physical scene resources in the virtual world, which is not described herein.

Fig. 9 is a schematic structural diagram of a computer device provided in an embodiment of the present application, as shown in fig. 9, the computer device 900 may be provided as a game server or other server cluster supporting a physical engine, where the computer device 900 may be greatly different due to configuration or performance, and the computer device 900 includes one or more processors (Central Processing Units, CPU) 901 and one or more memories 902, where at least one computer program is stored in the memories 902, and the at least one computer program is loaded and executed by the one or more processors 901 to implement the method for managing physical scene resources in the virtual world provided in the above embodiments. Optionally, the computer device 900 further includes a wired or wireless network interface, a keyboard, an input/output interface, and other components for implementing the functions of the device, which are not described herein.

In an exemplary embodiment, a computer readable storage medium is also provided, for example a memory comprising at least one computer program executable by a processor in a computer device to perform the method of managing physical scene resources in a virtual world in the respective embodiments described above. For example, the computer readable storage medium includes ROM (Read-Only Memory), RAM (Random-Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, optical data storage device, and the like.

In an exemplary embodiment, a computer program product is also provided, comprising one or more computer programs, the one or more computer programs stored in a computer readable storage medium. The one or more processors of the computer device are capable of reading the one or more computer programs from the computer-readable storage medium, and executing the one or more computer programs, so that the computer device is capable of executing to perform the method of managing physical scene resources in the virtual world in the above embodiment.

Those of ordinary skill in the art will appreciate that all or a portion of the steps implementing the above-described embodiments can be implemented by hardware, or can be implemented by a program instructing the relevant hardware, optionally stored in a computer readable storage medium, optionally a read-only memory, a magnetic disk or an optical disk, etc.

The foregoing description of the preferred embodiments is merely exemplary in nature and is in no way intended to limit the invention, since it is intended that all modifications, equivalents, improvements, etc. that fall within the spirit and scope of the invention.

Claims

1. A method for managing physical scene resources in a virtual world, the method comprising:

2. The method of claim 1, wherein providing related services related to invoking a physical scene based on the static physical scene resources and dynamic physical scene resources built for the virtual scene comprises:

determining rays to be detected in the virtual scene based on an operation instruction for calling the ray detection service under the condition that the related service is the ray detection service;

performing blocking detection on the rays in a static scene formed by the static physical scene resources to obtain a static scene detection result;

performing blocking detection on the rays in a dynamic scene formed by the dynamic physical scene resources to obtain a dynamic scene detection result;

and determining a blocking detection result of the rays in the virtual scene based on the static scene detection result and the dynamic scene detection result.

3. The method of claim 2, wherein the determining a blocking detection result of the ray in the virtual scene based on the static scene detection result and the dynamic scene detection result comprises:

if the static scene detection result and the dynamic scene detection result are both unobstructed, setting the obstruction detection result to be unobstructed;

If at least one of the static scene detection result and the dynamic scene detection result is blocked, the blocking detection result is set to be blocked, and a blocking point determined based on the static scene detection result and the dynamic scene detection result is returned.

4. The method of claim 3, wherein the returning the blocking point determined based on the static scene detection result and the dynamic scene detection result comprises:

5. The method of claim 3, wherein the returning the blocking point determined based on the static scene detection result and the dynamic scene detection result comprises:

6. The method of claim 5, wherein determining the target blocking point for the current return based on the static blocking point and the dynamic blocking point comprises:

7. The method of claim 1, wherein the building a plurality of dynamic physical scene resources for each of the plurality of virtual scenes comprises:

constructing an empty dynamic physical scene resource for any virtual scene;

8. The method according to claim 1, wherein the method further comprises:

storing scene type identifiers of the same scene type of the plurality of virtual scenes in an associated mode with the static physical scene resource;

and storing the scene instance identification of each virtual scene in the plurality of virtual scenes in association with the dynamic physical scene resource of each virtual scene.

9. A device for managing physical scene resources in a virtual world, the device comprising:

10. A computer device comprising one or more processors and one or more memories, the one or more memories having stored therein at least one computer program loaded and executed by the one or more processors to implement the method of managing physical scene resources in a virtual world as claimed in any of claims 1 to 8.

11. A computer readable storage medium, wherein at least one computer program is stored in the computer readable storage medium, the at least one computer program being loaded and executed by a processor to implement the method of managing physical scene resources in a virtual world as claimed in any one of claims 1 to 8.

12. A computer program product, characterized in that it comprises at least one computer program that is loaded and executed by a processor to implement the method of managing physical scene resources in a virtual world according to any of claims 1 to 8.