A brief discussion on game scene management design

Game Scene Management Design

Author:freeknight_duzhi

Blog:http://hi.baidu.com/freedomknightduzhi

Data:2008-6-11

Allow reprint, reprint please retain the head information. Preface

As previously mentioned in the blog, has been busy in the Amateur game development project recently. I have been a relatively lazy guy, but this time the cat nest of the administrator (the only one of our group planning) but do not want to let me idle, almost daily QQ contact, repeatedly asked me about the project. All of a sudden some Japanese comic book writers have been the taste of the magazine reminders. However, dragging his blessing, the project progressed faster than I had expected. Although I was cruel cut off a large module down, still much faster than my original plan, thank him. Hope the project will come out soon.

Because we are doing 2D of SLG (Chess strategy game) for the sake of, and I have a subjective preference for some avg (Love formation game), so this article will consider the two types of game scene management, for 3D and not based on the map lattice scene management Design I'm afraid you need to consider further.

Intro

Scene management and scene object management, I think should be the core of the game logic module is not too, in fact, the complexity is very high, this article only from some parts of the simple description of some of the content. With the Hing and talk, for reference only. Scene Object

Friends familiar with COM mechanisms will know that the most basic class of COM is usually the IUnknown class, which typically includes the following four functions:

/** Constructor */

IUnknown (): M_nrefcount (1) {}

/** Increase Count */

void AddRef () {++m_nrefcount;}

/** false Release */

BOOL Release ()

{

ASSERT (M_nrefcount > 0);

--M_nrefcount;

if (M_nrefcount)

{delete this; return true;}

return false;

}

/** Interface Query */

void QueryInterface (const iid& Guid) = NULL;

Let's start by explaining this class.

1: There is a member M_nrefcount reference count in this class, and the reference count is added automatically each time we new a class member that inherits from this class. When releasing it, it is not really released, but rather a reference count is reduced, and when the reference count is 0 o'clock, it means that the class object is actually released when there is no class to reference such an object.

This is a great advantage, assuming a SLG game, a level with multiple archers enemy a,b,c, their property behavior is exactly the same, then nature is a class of objects. After an enemy a dies, this object will be deleted from the scene, but another enemy B is still using the class object, if the object is deleted directly, then as long as we have any other enemy processing is sentenced to null pointer call, Even the frame cannot be drawn (we will certainly draw each frame to the visible enemy on the map), and if we manually record how many of the new class objects will be a stupid, cumbersome and unreliable behavior. Inheriting this class for automatic reference counting would be a very sensible choice.

2: This class has an interface query function QueryInterface () is not very good to understand, in fact, this COM mechanism is not designed for the game, but for the Software library development design, so I implement the IUnknown () function I often design it as a template class, and this function will be changed.

String Getobjecttype () const;

Or maybe you should be.

Enum Eobjecttype

{

Eoj_saber,

Eoj_knight,

...

Eoj_oggsoundobj,

...

}

Eobjecttype Getobjecttype () const;

Whether this will understand a lot. Because this class is to be heavily inherited, the function is used to enforce subclass inheritance to obtain subclass types for easy identification. (Note: The GUID parameter in the prototype of the function is an out type, not an in parameter)

So, we first identified a most basic class. The next step is much better. The object is inherited heavily. I'm attaching a picture to let you know.

It is worth explaining that this scenario class inheritance diagram is not an absolute standard, we are better to improve and modify it according to the needs of the game.

For example, Soundobject we can inherit from Iobject or inherit from Irenderobject, which depends on your understanding of render. Whether props are allowed in the scene. The items that fall out are static or play animations. This will affect the composition of the class structure diagram, here is just a way to explain the idea.

(For friends who are not strong in English, attach a Chinese and English documentation)

RenderObject: Objects that need to be "rendered"

Logicobject: Logical Object. That is, objects that do not need to be "rendered."

Entity: Entities. What is actually present, usually refers to the object that can be seen to touch.

Triggerbox: Trigger block. For example: A step on a trap that triggers an event. Including map switching, security zone protection these can actually be implemented using trigger blocks. itself can usually not be rendered.

Interestedrect: Area of interest. For example: Player vision, enemy AI response range, expansion, including magical attack range, the range of movement can be counted. You can usually not render it yourself.

Animateobj: The object that plays the animation. For example: Dynamic water, the wind swaying trees, expansion, can include animation effects. In short, many of the images are switched from one image to the other, or the object needs to be processed dynamically.

Staticobj: Static objects, static non-animated objects are intended for animated objects. For example: surface, props. Usually do not change pictures. (Special needs special treatment)

Moveableobj: The object that can be moved. Should include objects that can be moved subjectively and passively. Of course, you're willing to use a passive object (like the one that pushes the box) as a static object.

NPC: Non-player control role.

SPC: The player can control the character. In fact, it usually switches to each other and can even be unified into a class. For example, the player role has a "chaotic" state, which is not controlled by the role, but is handled by the computer. And to have the MPC between the two, for example, some pets can accept the player command for event processing, but when the player moves, it will automatically follow, at this time belong to the computer processing, or like a teammate in the FF12, can only under the macro AI instruction object also belongs to the MPC column. (Good like FF >_<)

In fact, even if there are loopholes in this design, we routinely understand that only moveableobj has the ability to attack, so the Attack () function should be designed to moveableobj class, so there is no mistake. But our scheming brother suddenly is very curious, a static tree also has attack ability, how to do.

We have the following treatment methods:

1: Move the tree class under the moveableobj.

2: Tree classes carry multiple inheritance, while inheriting moveableobj and Staticobj

2: Move the attack () function up, and place it in the IEntity class.

Then, the result would be:

1: The first method will disrupt the structure. Trees do not implement Animateobj's playanimate () function to play the animation. Because it is static, and does not have animation frames. It also cannot accept the Moverect attribute of the moveable because it is not movable.

2: The second method will more strongly destroy the inheritance relationship, with the inspiration of planning friends, multiple inheritance will be unimaginable. (--Think of the gameres on a friend's words "do not challenge our imaginative imagination." "Residual thoughts. ORZ)

3: The third method with more requirements, we will move more functions up, resulting in almost all of the functions are lost in the Iobject, because in this structure, a class function position of the move up will be very easy to drive the other related classes move up, eventually top-heavy, so that the class lost its cohesion, a bad code design.

Then what to do. with components.

(...>_< is finished, write far, here simply mention the good .... See design patterns or other book articles ... ）

We assume that what we need is a machine, so we don't have to design it and make it complete, so we just have to match each part of the group together. For example, in a car, we want it to fly, so it can be equipped with an aircraft engine. I hope it can eat, then give it a mouth to put a stomach on it. Diagram of the component I don't draw ... Poor people without Visio don't like to draw with a touchscreen Windows accessory, forgive me. Here is a code, hoping to understand:

Class Ctree

{

Private

cmoveableobj* M_pobj;

Cinteresterect M_rect;

Public

void Attack (iobject* obj) {m_pobj->attack (obj);}

}

That's all you can do. This tree class not only implements the attack function, but also has its own area of interest, only when the other side into the range to attack. Of course, this is not completely detailed in the component mode, detailed can refer to other books.

What I want to make out here is that even if we can't perfectly construct our class inheritance tree, we can let the "parts" inherit IUnknown, and then assemble them to implement these functions.

Well, for the object in the scene, here it is. Here is the scene management.

Scene Management

1: Resource Manager

First of all, I want to start with resource management. This resource manager should be global and unique, it is very convenient to use, then we design for Singleton single-key mode is very suitable, for example: Soundmanager,imagemanager, etc., they are responsible for the object container management control.  For example AddObject (soundobj* obj,const String ID); DeleteObject (imageobj* obj), the insertion and deletion of objects, the object query, data acquisition and other management operations. It is important to note that each resource object should have a unique ID. Here are some people like to use GUIDs (globally unique identifiers), personal not recommended, first, trouble--see a bunch of garbled I'm very big head. Second, notional unknown. The use of Ogre-like custom string real name words, there is no obvious difference in efficiency, and easier to understand, top.

It's not complicated, but the point is that if you can design a good isingleton with a template to provide other classes of inheritance. (It's not too easy to think about multithreading), in addition, there is a small problem, the order of the single-bond destruction is not well mastered. Take a little bit of time.

2: Object Container

Objectcontainer is easy to understand and easy to do, STL provides a lot of containers, vertor,list are good, because to store each obj ID, with map.

It is still recommended to use a template to design a common object container class, then we just add two functions on it, Getobjtype (), Setobjtype () just fine. Note: Do type checking when pressing, do not let other types of objects into the wrong container oh.