Scenario Management, discard scenario Diagram

Scenario diagrams have always been considered suitable for general Scenario Management of games.AlgorithmIt seems that the scene graph is not written into the engine. However

Test and analysis, I think the scenario diagram is not suitable as a general scenario organization method. I will explain the reasons below and propose an alternative

This method is suitable for managing MMORPG online games. If you have any different opinions, you can discuss them with me.

A scenario diagram is a data structure of a hierarchical organization scenario. To generate a scenario diagram, You must select a hierarchical relationship, or a parent-child relationship, or

Bearing relationship. For example, the cascading relationship of the ry transformation matrix, the surrounded relationship of the Space range, or the inheritance relationship of the rendering attribute. However, you choose

You have to give up another link, or you have to select different cascading relationships at different levels or between different branches to make the system

Complex and obscure. On the other hand, not all systems are hierarchical. For example, terrain is more suitable for grouping with a quad-tree or array structure.

Weaving (I think the array is good for the visible range of online games, and there is no need for a quad-tree). It is more suitable for indoor scenarios.

The area connected to the portal is organized in a structure similar to the graph. if you attach these structures to the scenario diagram of cascading, it will be difficult to design.

, Bring chaos. The implementation of many bad scene charts often leads to a flat scene structure. The scene map is like a linked list, and the hierarchical group is lost.

Benefits.

The following describes how to manage MMORPG online games:

First, define a scenario Manager interface iscenemgr, including the following interface functions (only list the functions required for the explanation ):
Class iscenemgr
{
Public:
Draw Functions
A set of Collision Detection Functions
}

Two scenario manager classes are derived from the iscenemgr interface, which are terrain manager iterrainmgr and indoor scenario manager.

Ibuildingmgr, the terrain manager organizes and manages the terrain patches through an array structure, and the indoor scenario Manager consists

Architecture management indoor scenarios similar to graphs.

Suppose there is a castle on a terrain. Let's see how the above structure completes the game function. The terrain Manager uses indoor scenarios

The largest surrounding box of the castle, the terrain patch area covered by the castle, and the portal connecting the indoor and outdoor areas to the indoor scene. First

First, let's take a look at the rendering process. If the camera is in the terrain area, the terrain manager will paint through the array structure, horizon algorithm, and PVS visibility level.

Optimization of sanction reduction and removal. If the castle's surrounding box is within the Cone range, it is handed over to the indoor scenario manager for rendering. Scenario manager MEETING

Optimize the rendering process by performing Occlusion Removal on the portal. If the camera is indoors, it is first drawn by the indoor scenario manager.

The host connects to the indoor and outdoor portal to see the outdoor scene and then submits the drawing to the terrain manager.

Let's take a look at the collision detection. Taking the collision detection of rays as an example, if the starting point of the rays is in an outdoor terrain, the terrain manager will first perform the detection,

We can also use all the characteristics of the terrain to optimize collision detection. If the ray interacts with the maximum envelope of the castle, the detection is handed over to the room.

The scenario manager can use the portal, BSP Tree, and other indoor scenario features to optimize the detection.

If the radiation start point is in the room, the indoor Scene Manager will first detect the radiation. If the radiation passes through a portal connected to the indoor and outdoor

Line to the terrain manager for detection.

It looks good. Maybe some people will ask what to do with the model system and special effect system. As a scenario manager, there will not be more and more

Manager, collision detection and rendering need to traverse more and more systems? Otherwise, we do not regard models and special effects as scenario managers,

As a lower-level underlying object, they must depend on a scenario manager object, that is, they must belong to a terrain.

In a system or an indoor area, their rendering and collision detection are driven by the scenario manager objects to which they belong. Different managers

Special Data structures are used to optimize model and special effect management. For example, the terrain patch where the terrain system records the model and the indoor scenario Manager records

The region (room) where the model is located ).

Everything is so simple and clear that you do not need to attach it to a unified structure. Each system has its own characteristics and has its own optimization organizer.

You will stay away from troubles by giving up the scenario diagram.

Find an article that is similar to my opinionArticleThe link is as follows. If you are interested, refer.

Http://home.comcast.net /~ Topic "scene Graphs-just say no" in tom_forsyth/blog.wiki.html