This is the idea of our graduation papers. In a specific practice, the idea is mainly responsible for other game systems other than the objects and GUI. The idea is to learn to be ignorant, and the predecessors are expected to be enlightened. Due to the low quality of code, the environment is difficult to configure, the resource package is too large, and the idea does not provide code and program, and organize these once the code is organized when there is time in the future, and then release it out.
Wen in March, there are some new ideas, will come slowly with everyone in the future, welcome to shoot bricks ^ _ ^.
Keywords and terminology:
Games, Game Engines, High-rise Engines, Rules, Scenes, Items, Terrain, Interpreters, Application Framework, GUI (GRAPHICS User Interface Drawing), Manager (Specific Manager in this article) ,trigger,
Design mode,
Singleton (single-mode, a design pattern, making some classes within a program, there is only one instance, and you can get this instance at any time.),
Adapter (Adapter Mode, a design pattern, converts a class interface into another interface of customers),
Factory (factory mode, a design pattern, providing an interface to create a series of related or interdependent objects without specifying their specific classes),
Thanatos (dead instinct, representing hate and destruction, death can be projected to the hope as the hope of killing, showing the root cause of violations and hatred; if the dead can be frustrated, it is "suicide tendency", including self Condemn, self-punishment, embarrassment of the enemy and the opposition of authority, etc.),
Object-Oriented Graphics Rendering Engine Object-Oriented Graphic Rendering Engine
Abstract:
The abstraction of game engine is an important question in game programming, and the kernel of the question is "How could we give the game engine more adaptability?" In the paper we attempt to deduce the form which our game engine must be from our daily -lives. with the help of oogre, i Completed The Game Engine Which Has The Form That We Have Just Deduced.
The major questions of this paper are:??. First, why we make game engine Second, how we make a game engine The first question was answered in Part1, while the second in Part3 And the Preview gives us a theoretic conclusion to the second Question. at the end of this paper, we buy the game, we... Just Been completed to make a simple game.
The main idea of the paper is to take game engine as a combination of the high-level game engine and the low-level game engine. We use the high-level game engine to support game logic, and low-level game engine to support Device and Platform API. Summary:
The abstraction of the game engine and frame has always been a key issue in game production, and its core problem is how to make abstract wells better adaptability. This article attempts to use interpretation methods from the world we live in order to maintain the high-level engine in order to adapt to game needs, and complete a simple high-rise engine that meets this form by using OGRE.
There are two key issues in this article: First, why do you have a game engine, and I have to architecture a game engine. In the first part and the third part we have answered this question, and the introduction is the interpretation and derivation of the second question. At the end of this article, we have made a simple game with the completed game engine.
The game engine should be divided into two parts of the package for the high-level logic to provide packages, which is the central argument of this article.
table of Contents
Introduction Game Form and Its Decided Procedures ... 5
The essence of computer games is the simulation reality ... 5
Procedures determined by electronic competitive reality ... 8
First part of the game engine technology brief ... 10
Engine Overview ... 10
High-rise engine overview ... 11
The basic composition of the second part OGRE graphics engine ... 14
Part III POLICY: Game Framework Based on OGRE Graphics Engine ... 18
Scene system: Separation and recombination of OGRE Scene System ... 18
Scene: The game of the game ... 20
Rules: Script System ... 22
Part assembly: the construction process of the specific game layer ... 26
Section 4 Conclusion and Prospects ... 27
Appendix ... 28
Terrain Example. 28
Reference ... 33
Preview Game Form and Procedural Form
The essence of computer games is the simulation reality
"The game is in human beings, many scholars have found a lot of game behavior in natural mammals in nature ...
"Although the history of the game is long long, mankinding it as a theoretical research object is something in modern times. German poets and dramatic Schille in studying art origins have the origin of 'art The game 'is bold and said. He believes that human beings must be bound by the spirit and material in real life. In these two constrains, they often lose their ideals and freedom in these two constrains, and people try to create the remaining spirit. A freedom world, this free world is the game. "
- "The King of the Game · Game Civilization"
"The game is in human beings, many scholars have found a lot of game behavior in natural mammals in nature ...
"Although the history of the game is long long, mankinding it as a theoretical research object is something in modern times. German poets and dramatic Schille in studying art origins have the origin of 'art The game 'is bold and said. He believes that human beings must be bound by the spirit and material in real life. In these two constrains, they often lose their ideals and freedom in these two constrains, and people try to create the remaining spirit. A freedom world, this free world is the game. "
- "The King of the Game · Game Civilization"
Human research has originated from modern times. Regarding the problem of the origin of the game, there are various theories from modern times: such as Schiller's "instinctory", Springset's "remaining energy theory", Gugus's "practice theory", Freud "Pavilion theory", etc.
However, what is the game? What is the essence of the game? Let's take a look at the following game forms and see if you can get some inspiration.
The chess seems to be the earliest pure intelligence game form that can be listed; and when the game rules begin with physical strength, there have been many sports projects; since the 1960s, with the improvement of chip processing capacity, Produces new game forms of video games. Throwing so many games, the existence form is not to say, the spirit is the material map, how is the objective existence of this human spiritual product? Chess, military flags and Go, have found inspiration from human war. War is a thing that can contact and understand in humans.
Figure 0-2 Chess is likely to come from human understanding and understanding of war
Most of the rules of modern strategic tactical computer games, many of the military executions in modern times, this military deduction can be accurately said to be inspired by the war.
Figure 0-3 Left: "Civilization" screenshot Right: In 1894, the Qing government sent people to participate in the US military military programs
Figure 0-4 Left: "Earth Empire" screenshot Right: 1910, a Various War Decrection of the US Naval Military Academy
Figure 0-5 Left: "Time 2" of the Imperial Times Right: Modern Title War Game Packaging Box
The earliest video game was 1962 on the PDP-1 electronic computer, "Space War" developed by college students named Steve Russell, who can see this game from the name. It is the fantasy of human beings for space, and the experience of war.
Figure 0-6: On this computer, the first video game right in human history is born: the space fantasy map drawn by computer.
Figure 0-7 Left: Tactical FPS game "CS" right: Austrian psychologist with Thanatos and EROS Freud
Figure 0-8 Left: Traditional diagram RPG game character attribute form: playing version rpg can stimulate players rich imagination
Figure 0-9 Left: A network RPG game scene screen shot right: playing the player version RPG game player, the lower right is the referee
The crown of crown is "violent", especially those who are eye-catching QUAKE and HALFLIFE, seem to be to meet the human beings that Freud's human beings of Thanatos have often come from real killing scenes. These killing scenes are in some websites, literature, news and TV series.
Let's take a look at another game type - RPG game. The American RPG of Europe and the United States is Tolkin's famous "ring king". As a literary work, "Refers to the Rings" seems to be inspired by the interaction of human beings, and it is reflected in this. A fantasy world and fantasy world view. Since then, the "Dragon and Dungeon" rules are inherited and carry forward this system, and portrait the political, economic, philosophical and war system between various groups. Fantasy things, as well as things that humans can contact, becoming the inspiration of game developers to develop games. "Dragon and Dungeon" has been made before the computer game appears. Later, computer games involved in this rule system, reappearing with a new look of the tutoring and changing world in the past.
From the above description, we can see that the development of the game is inseparable from "Things that humans can contact", including the objective world and spirit (art, fantasy) world that can be exposed to human beings. "The King of Computer" said: "The essence of computer games is analog reality", which is also the essential characteristics of the computer revealed by the Tuling: "Simulating human thinking".
Procedures determined by electronic competitive reality
Since the game is an understanding and understanding of the objective world, you can stand in the most abstract angle to decompose this understanding and understanding.
First, there is a world that has existed in ancient times: landscape, forest ..., so, they have a common feature, very little or almost no change because of human spiritual activities, basically think that there are few times during the game Or there is no change. This part we use a word to draw a map or terrain. Generally, it is called a terrain in three-dimensional, and it is called a map. The second is the world's residents and the various tools they use: people, animals, cars ... They have a common feature that there is a strong relationship between interactions. Due to the obvious change, this part of the object often changes. In this part we also use a word to portray the object. In additional categories, the map and terrain are often treated as an object, but in most games, both attributes and methods are different, so we will have a map independently.
The combination of the first two worlds has become the material world that we can perceive in our flesh, and the image of this world is called the scene. In other words, the generalized scene is a collection of objects above the terrain and terrain. Considering from a simple perspective, we can think of scenes as a stage set, stage background, etc. is terrain, while actors and some debris on the stage are objects.
The Third World is a world that is more difficult to perceive, and its naked eye is unable to see, but it is in a relatively stationary state in a long time period. For example, "There will be too much life of life", "With the same premise in other conditions, the efficient person is more than the non-efficient person in the unit time", and so on. This part is very large to affect the "First Second Part World", and we use a word to describe it is rules or law. This part has an important content is the activities in the human spirit, including the World and Emotional World, we can think of this activity as a special rules and law.
As a means of interaction, there is a layer of level interaction. In the interaction, it is the first to be accepted by everyone to enter the game system through all possible ways of this person to receive output from the game system. Therefore I / O control is a system necessary for a gaming system. For example, when we are chess, our hand can think that the input device of the game system, the visible chessboard and chess pieces send output from the game system to us, which can be considered to be the output device of the game system.
On the other hand, in the computer game. In addition to the basic devices of the keyboard mouse display, there is an important component of interaction is the GUI interface. For now increasingly complex gaming systems, a mouse and keyboard are maintained by entering commands. I / O is hard to imagine. Therefore, GUI uses its power to compensate for the lack of standard I / O equipment, because the importance of the GUI system, so we must also take it into account this time.
Through the above discussion we can conclude that a game can be broken down into a map, object, rule, I / O control, and GUI collection. As a game, items, objects, I / O and GUI partial degradation, and ranging from the rules, and the ancient system has no powerful system to perfectly reflect maps, objects, so the rules are relatively powerful. A modern military deduction in modern times is already a full map, objects and rules. As a GUI, it seems that only video games have such something, it is for convenience of interaction.
In most game engines, the first part maps into a terrain (map) system, supports at least: read, export, rendering of map files, etc.
In the second part, the implementation of each different games is not the same, and the general engine supports the support in addition to rendering, at least the following support: object collision detection, model editing, etc.
Part III, this is a large part of the limitations of the game type, and even in the same game type, different results will be different due to the different personal division of the programmer. Compare basic technologies include state machines, etc.
The fourth part, GUI and control have a lot of reference, and MFC is very good, so this is usually not often discussed. The main discussion of this paper is to use an existing underlying engine to architecture high-level engine and borrow a general idea of high-rise engine architecture.
First part of the game engine technology
All pictures required for the first part
Engine overview
For a period, game developers care about how to develop new games as much as possible and sell them to players. Although the game is mostly simple, the average development cycle of each game has to reach 8 to 10 months. This aspect is due to the reason, on the other hand, because almost every game must be written from the head. The code has caused a lot of repetitive labor. Gradually, some experienced developers have explored a lazy way, they borrow a basic framework for new games in a game similar to the theme to save development time and development. So slowly generate the game engine. People's concept of game engine is gradually understanding, this process is similar to other technologies - after all, the game engine is also a program. This understanding is based on the understanding of "encapsulation". In fact, the concept of the engine is more under the concept of each person's different understanding of the engine: the game engine is just a statement, so there is no recognized definition.
In recent years, some beginners understand the engine "Simple Package for the underlying function", this underlying function includes platform API, rendering API, Audio API, streaming API, etc., such engine is often a kind of C language era. It is divided into "function" relationship between different parts, not "logical" relationship. Classics include: rendering core, memory management, skeletal animation, frame animation, file operation, physical library, network library, etc. This is the most clear system division in the broad network "Game Engine Analysis" (reference 4):
1, "Rendering and construct 3D world, 3D environment light and texture". Rendering is always the most technical part of the engine, and does not say the graphics card that is thousands of dollars. Single is the progress rate of graphical rendering related technologies, it is already enough to gain it. "What is the renderer, why is it so important? Well, if you don't have it, you will not see it. It allows the game scene to visualize, so that the player / audience can see the scene, so that the player can be based on the screen The things you see have made appropriate decisions. "The main underlying function required for rendering is to support OpenGL and DirectX's latest technologies. Since these technologies continue to change, the replacement of the renderer is also quite obvious. It is a very clever renderer that hides a lot of renderer, allowing us to perform graphic processing in a near natural language.
2, "memory usage, special effects and API". Graphics research to high levels have to take into account some of the characteristics of the chip: such as memory and memory management, shader, and other important parameters. This is also the content that is a must-have referring to the engine.
3, "Model and Animation, Detail Level LOD". The game engine should support the common model file format and rendeze them well. If the game engine needs to use its own data format, it needs to export plugins for several major model file formats to meet the needs of art.
4, "Physics, Sports, Effect". Physical systems allow games as much as possible. "As a game developer, no matter what we do, we need to be able to detect walls, test the floor, in the world's collision. These are essential for modern game engines." Advanced physical system such as Ode, Precise physical and kinematic theory and formulas are precisely handled under the premise of ensuring efficiency, including fluid mechanics.
5, "Sound System, Audio APIS". Ears are also an important sensation and information of people to get organs, this should be very well understood.
6, "Network and Connection Game Environment". Online game essential. Today, most of the games that have a long-lasting life have at least some connection components. "The purest single game is easy to play once, maybe twice, or even three times if it is a very good game, but once the game is over, it is a high cabinet. If you want any long life, then many people connected The game is the core of the situation. "7," Script System ". You can think of the game script is a movie script, both substantially the same.
8, "Artificial Intelligence and Navigation".
After establishing your own engine according to this idea, our engine is just a functional engine, which does not have any logical relationship. Including a series of game logics such as scenes, maps, objects, rules, etc., it can't provide it directly. At this time, the engine we have is as shown in the following figure:
Figure 1-1 Basic underlying engine core structure
A terrible tiled structure, there is no association between each other or few associations. That is to say, it is basically logical, and each game you can reuse these underlying functions. In addition, you need to rewrite all logic, even if the two games are basically the same. Foreign game engines have allowed you to get out of the code, you can do games with scripts and editors (this development means called MOD), this simple tile structure, no depth, simply unable to make such a full Logical building!
High-rise engine overview
Let's take 2D map to do an example. Under such engine thinking, the map is just a plurality of primitives, BLT (pronunciation BLIT, bitmap block transmission) and intercom. This idea does reflect the essence of the map, but for game logic, it is too fine. Because the game logic does not need to take you on how your map is stitched, BLT and occlusion. The following figure is for this design idea, and the following picture is right, it provides the design idea of the high-rise engine. Through comparison, the design idea on the right is more in line with the principle of OO, and the left side is mainly ancient process filling.
Figure 1-2 On the left side is directly encoded under the application, the right side is to establish an abstraction layer between the application and the underlying engine, which has the abstract layer divided and assumes the basic logic of the game. Which method do you use in today?
Here we understand the engine except for functional elements, including some logical components, that is, "Game Layer" or "High-Level Engine" in some developers, why does this part of this engine? The answer is to facilitate our upper layer logic of the game. The underlying game engine is based on the platform API, which is strictly related to the API. The purpose is to let the outside world can't see the API, concentrate on the logical part of the outside world, but the underlying engine completes only a purpose is to complete a certain function by encapsulating the API, whether the packaged API does indicate certain to adapt to the requirements of the upper layer logic? This is impossible, because it does not exist for this purpose, such as the relationship between the bone animation and the upper logic? Therefore, people put forward the concept of high-rise engine. This answered the problem, and the skeletal animation should be included in the logical inside of the object, which should be transparent to the outside. If the game logic needs to be refined to "Who, according to the skeleton action 'Walk2' to walk", it is too much trouble. In this case, the more common practice is that we have implemented one item, then set a state for it. Called with State_walk2, when the object itself is discovered that the article is in this state, it began to trigger "Walk2" action. In this way, the last game logic only uses simplified to say "who, take a step forward". . The actual processing is that after the engine layer gets this message, send a message to the object "Who", "Who"), and after obtaining this message, automatically perform the state machine according to the current state. For logic developers, all this is good, transparent, they only need to know "When I said 'a forward', A will go forward", this engine is not A simple summary is a bungalow with a function, but a building with a certain logic guarantee. State_walk2 to WALK2 correspondence can be implemented in different ways in different game engines, and the simplest method is hardcoded. This method is fast, but sacrifices the maintenance of the program, will give the test belt Come a lot of trouble. Most of the game engines can solve this problem through configuration files or even editors, as well as this similar problem, this data-driven way makes the encoding logic easier, and also makes designers and director work more convenient. The following picture shows the scene when we use a foreign engine editor, in this editor, existing item editor, and scene editor, including scripts - this editor with it to achieve what we said Rule - editor:
Figure 1-4 Looking at a game editor like 3dmax, China is currently not working hard to develop this highly integrated editor.
Toping the topic, comparing the conclusions we have drawn in front, do a game, actually in the scene (map object), rule system, GUI system, and I / O control system. So what should we do? Building a high-level system that is too centralized and implemented all features will only reduce the adaptability of the high-level engine, so it belongs to the high-level engine to support them, including: basic data structure and organization. For example, the object linked list and query operation, special file data), tool set, etc. Through this layer, the highest layer logic only needs to be written: Place a few flying birds in the scene, fly according to the SIN function route. As for how the bird flying is rumored, how is it yaw, which is a specific object of the object system - here is a flying bird - can be decided. For the logic needs of the final product, we can't wait a "high-level game engine", which is from a very important idea, and the basic idea of software engineering: "Software is generated in demand." The partial engine level is completely from the platform and API limit, because the game we have to do must be related to a platform. The high-level engine structure is strictly related to the desired purpose, because this is its presence motivation. In fact, most of the engine now includes a high-rise engine part, but the division of the high-rise engine is not easy. Most engines are or more fps type, which is a universal adaptive engine. It is difficult to increase because the high levels required for different games are different.
Our basic purpose of this article is how to build a high-level engine when you have an existing underlying engine, and how this high-level engine is more adaptable.
Now we have the engine structure as follows:
Figure 1-4 Basic framework of the high-rise engine layer in accordance with the current division
The basic composition of the second part OGRE graphics engine
All pictures required for the second part
OGRE (Object-Oriented Graphics Rendering Engine, object-oriented graphics rendering engine) is an internationally known open source graphic rendering engine. OGRE is an object-oriented and flexible 3D engine developed with C . Its purpose is to let developers can develop applications or games based on 3D hardware devices more easily and directly. The class library in the engine has abstracted all the use details of the lower system library (such as Direct3D and OpenGL) and provides interfaces and other classes based on real world objects.
The OGRE system mainly includes: render system and render plug-in, Material system and material scripts, Entity (mainly object system), GUI system, and overlay scripts, Texture, and Picture decoders, Archive systems, and file decoders, Scene plugins (mainly topography System), particle system, log, DLL dynamic import and plugin system, etc. And the last system is all managed by a general manager, this general manager is OGRE :: root.
The picture below is the relationship of root, and root is the core part of the entire OGRE, which is associated with all other components and packages these components.
Figure 2-2 Ogre core partial block diagram (Reference Since OGRE Development Block)
Figure 2-2 is a core component block diagram of the entire OGRE. Below we reference the Mage Group's Description of this block diagram in the OGRE Usage Guide:
"
ROOT: The entry point and manager of the entire OGRE system, it must be first created, the last one is destroyed. You can configure the system through the root object, and you can get other objects within the system.
Rendersystem: 3D API abstraction, it is responsible for setting all rendering properties and calls 3D API to perform rendering operations. SceneManager: Scene Manager, which is responsible for organizing organizational scenes, including Material, Light, Movable Object (Entity) and scene itself in the scene.
Material: Define the surface properties of the geometry in the scene.
Entity: Availability in the scene.
SceneNode: represents the location and direction, and EntTach to Scenenode can inherit its position and direction. SceneNode in the scene is organized in the form of a tree.
Camera: Viewpoint in the scene.
"
Using OGRE is simple, because OGRE provides its own Application Framework. If you are interested, you can refer to the standard code using Ogre Application Framework in the appendix: (Example From OGRE Subject) Demo: Terrain)
However, the detail is developed using Application Framework. The code that needs to be written is mainly concentrated in three aspects: initialization, processing input, and runtime frame cycles. Most of the time, what we need to do is mainly initialized and input, and almost unnecessary to frame cycles.
Since Application Framework itself is so good, why can't I use Application Framework to do games directly? Take a look at what applied in Application Framework:
Figure 2-3 Ogre Application Framework Project
We can see that high-level packages include: some object classes (AppBox, Appball, etc.), object collision detection support (ODE, an internationally renowned open source physics engine), as well as a simple to refapprdworld (this World is similar to the scene system we discussed earlier), which is difficult to meet our requirements. However, it seems that the author of OGRE seems to be noticed that the scene system of OGRE itself cannot meet the needs, so in the Application Framework, we re-build the scene system in our sense, this scenario system is enough for a single scene. But in the multi-scenes of the game, even a large number of scenes, this architecture seems to have lack of persuasiveness. Moreover, ODE and OGRE are in this hierarchy, the actual effect is not good, and there is often a collision detection error leads to the wall of the wall, hitting. We have prepared to build your own game frame, and finally find more and more influences to ogre for our frame. After all, OGRE is developed for the purpose of OGRE developers, not for game development, not for our purposes.
Now, we are ready to completely abandon this architecture, turn your own new architecture, to practice the "high-level engine" derived by the previous pure theory. Of course, the idea we use is not exceeded, and the "Scene = Terrain Items" thinking in Application Framework, but our architecture needs to take into account more, because the game we have to do is not just "First Second World" (scene), and it also includes "Third World" (rules), this is OGRE no support.
Part III Press: Game Framework Based on OGRE Graphics Engine
Part III Pictures
Scene system: Separation and recombination of OGRE Scene System
First we find that the OGRE scene system seems to be a bit uncomfortable with the scene system we understand. OGRE is a rendering understanding of the scene, and as a game seems to take into account more. "The game needs to be rendered, but the game is not just rendering." To integrate into the OGRE graphics system, you need the adjustment of the program structure and habits, and all the code written needs to be limited to OGRE, so that the high-rise game engine written in OGRE is likely to be left OGRE. Can't do something. And even if we don't leave the OGRE framework, when OGRe is refurbished, when you do a big system, we do the high-level game engine needs to make great adjustments, this is of course not what we want to see. The high-rise engine is based on the demand. OGRE is changed, as long as the demand has no change, it should ensure that the high-rise engine should not be changed, this is the principle of software engineering.
How to do it? We first derive the connection relationship between the OGRE engine and our previous hierarchical engine system.
Under existing engagement, we have a lot of framework security problems, and if a component in OGRE forces us to change the upper architecture, it will be dangerous, because the upper structure is not for OGRE. In addition, these things should be packaged to the bottom. We hope that people who ultimately use this framework can't see something related to OGRE, he only needs to consider his own things: game logic. Just sending a love letter for A, and the problem that D is hit by the car that is hit by C. If the highest layer has forced the user to consider OGRE - the envelope of C and D - So can only say that we have no more divided, build our engine, in other words, our work is ended in failure. This is our minimum requirement for our framework. Because only when the high-level engine is not a little marks, our uppermost demand and the most underlying platform are completely isolated by the high-rise engine, that is, regardless of how the underlying platform changes, the specific game logic does not need to be changed. It is only a high-level engine that needs to be made. Figure:
As shown in theory, the high-rise engine completely isolated underlying and application layers, which will affect the high-level modification, but will not affect the modification of the application layer. This is critical to the engine. When the engine changes, if all the application layers of this engine need to be modified, then do you know how many studios in the world, or even the company will make a ghost crying. Therefore, modular, hierarchical ideas is long, a consensus of the software engineering industry.
Under our existing division, the high-rise engine needs to complete the following work:
Figure 3-2 Basic high-rise engine structure
We enumerate the functions provided by OGRE itself, all of which provide black blocks, partially provided with light green blocks.
Figure 3-3 Cutting and relationship between the basic high-level engine structure and OGRE
In this division, I am responsible for the main terrain system, terrain, scene and rule system, and the GUI and I / O control systems, objects and object systems, and applications are mainly responsible for another classmate. Here I mainly only describe scenes, terrain, terrain systems, and rule systems.
Scenario: the stage of the game
In the scene, the stage is supported by the terrain system, and the vitality of the scene is the object system. The organization between the object system and the scene system is contacted, such as the material system data structure required by the oversized scene manager and the ordinary outdoor scenario manager, the former may not store massive objects, there may be Partition processing; and the latter is different, so it may be managed with a unified table (MAP) or hashmap. The correlation of the object and the terrain system can be solved at the level of the scene. When the scene is raised, it is necessary to transfer the appropriate object system. What kind of object system is most suitable for a certain terrain system? This is a problem that the benevolent seeing the wisdom of the benevolence, there is no one of the only answers. The object system is the most efficient difference: own logic and search algorithm, each frame of the object system will take your own logic, and the outside world will often stroke a specific object from the object data structure, or even a frame index of more than ten times. Items, these both have high requirements for the data structure of the object system. Ogre's support for terrain is relatively large. In fact, Ogre itself is no specific terrain system, but we can add Plugin to add helping to the original OGRE system. The existing Plugin includes: BSP Manager (Plugin_BspsceneManager), large scene manager (plugin_naturescenemanager), and our four-tree outdoor scene manager used to test, Plugin_OCTREESCENEMANAGER. OGREs are almost notice that the differences between the high-level code levels are almost noticeable, which is of course convenient for our abstraction. Just the OGRE terrain system is integrated in root, can't break, so that the topographical system we provide is equivalent to a "shell", just re-encapsulating the scene management function of the OGRE, this is Adapter in the design mode (Adapter )mode.
Therefore, this TERRAIN written is equivalent to the first layer of Adapter on Ogre :: SceneManager, there is basically no new function, which is also the reason why this system is already completely processed in Figure 2-3.
One of Scene is used to manage Terrain, which is usually in the case of multi Terrain, requires unified management of many TERRAIN resources, and Scene is in charge of Terrain's bachelor's power, just as the stage of the stage determines how the set is placed. In fact, there is also some of the functions in the OGRE: SceneManager to do these things. Since the required function is relatively small, Scene has mastered the following basic methods: including loading Terrain, destroy Terrain and replacing Terrain.
With Adapter mode, TERRAIN rises to an interface class, which will be made in the future for SceneManager's change in the OGRE, and Terrain is only necessary to change the implementation of the interface. Scene has become the management class of this part and is logically logically with the underlying OGRE. To this time, our Scene-Terrain structure is a simple scene system, and the existing part of the existing parties and the interface are as follows:
Another important part of the object system in Scene, and another classmate tells you that this is just a little more about some basic object design ideas. As mentioned earlier, the object is a system that is more difficult to divide, as the properties of the object are more, and whether the properties can be formed. For example, "organisms or non-organisms", "life growth is still short", etc. For example, for items for a general life period, you can store it according to the MAP or Vector, so that since the data structure is not transferred from the data structure, and the query algorithm is relatively fast, so that this The data structure is more advantageous; but the items very short in the life period are different, such as sparks splashing on the wall, the existence time of sparks is often 1/10 seconds, and there may be a lot of sparks, If you use vector or map, it will be a very horrible thing, and don't say how much time loss will be transferred to the callout. It is not necessary to perform query operations at all, Map and Vector. The only advantage is no longer available. Therefore, for items that are very short in this life period, LIST is obvious than using MAP. This division is only from the "life-long short" attribute, and what is the properties of the object? ! Even if you are stored in Map or MultiMap, there is also a name store, and you can store it according to item properties, and so on. How to abstract an object system for the game, which is a common problem in many people's minds. There are also many current methods about this system, but it is difficult to unify, after all, the rules system of the object is too complicated. Rule: Script system
Although the rule system is not difficult to divide, it is a system that is more difficult to grasp. As mentioned earlier, the rule system is a world that is not able to feel the body, so that only the world that can be perceived with consciousness is full of many variable. In fact, the rule system is not a forming system, but all of all "game logic". These logic or homemade systems, or distributed in other systems, constitute a tight and rigorous logical system.
From functional understanding of this system is a universal method, because regardless of the rules, it will always affect the sensory world, this impact is the function of these rules. But this division is not all all of the rules system, but is just a direction. Use the vernaleth to say: "No matter how you divide this system, you can finalize this feature."
When doing the engine, few people will know where this engine will use, not to say which logic should meet which logic and which functions should be satisfied. So most of these features are final developers to take into account when the developer gets the engine. For engine developers, it is invisible, full of variables, so this is an important reason why the rule system is difficult to grasp. Most game logic is written outside the engine, and many Chinese game Demo logic is implemented by hardcodes.
But this does not indicate that the engine's developers can do, because you have to support the rule system, and some things are absent. This mainly includes: message system, game script, path finding algorithm and state machine, etc., most of them are identification research topics of artificial intelligence. I think the most important thing is the scripting system and message system. For foreign game engines, the powerful scripting system has long been a must-have, and domestic developers are still difficult to find the textbooks and materials in the script system.
Here our engine will provide a set of script support for the rule system. In the back assembly, you will see how this script is used as a rule in the game. There are also many other supports for rule systems, such as state machines, etc., well in each logic system, which can be increased in the future.
The script is divided into compilation script and interpretation. It is a compilation script analyzer for foreign many game engines. What I provide is a set of interpretable script analyzers. First, because developing a compilation analyzer is often too long; the other is for our Demo, the interpretation type is already enough, and the speed is not slow . The basic functionality provided by the script analyzer is to analyze scripts, which involves the lexical analysis and grammar analysis of compilation principles. After reading a row, the remaining part transferred in the Bank, the remaining part transferred to the lexical analysis, and further discontinued into a separate meaningful word, and finally explained the meaning of these words through grammatical analysis. . Here our grammar is relatively simple, each independent statement is as follows:
INDEX:
Funciton (PARAM1, STRING PARAM 2);
The first statement is a label statement, primarily for jump, such as Goto (INDEX), can jump from any location of the program to INDEX, so in our grammatical analysis, when the word ":" When the word exists independently, this independent word is stored in an Index table for jump. And if "(", the previous independent word is used as function, each Function is unique corresponding to a C program, from "" to ")" partial press "," to do multiple param, do not bring "It is a constant parameter." "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" " Here we can use IF to process:
Strcmd = parseline () // Analysis
IF (strcmd == "function")
{
Dofunction (GetStrParam2 ());
}
It is best to readability of IF, but slow, because String is more slower than constants. Therefore, the method is to make a comparison by mapping the script function as a unique number.
For example, we establish the following correspondence: Function: 101, store this correspondence into the script interpreter, so that when the interpreter finds the word function for the function, it will translate him into 101, and then carry out match:
NCMD = parseline () // Analysis, pay attention to the return value is different
Switch (NCMD)
{
Case 101:
{
Dofunction (GetStrParam2 ());
}
}
This is much faster than the original. Just a step of trouble is to need one by one to correspond to these numbers in advance. These are actually running in the interpreter's Run () function, where required, only need to call the Run (Script file name), Run will detect different script names and then achieve their respective functions.
The script analyzer also needs to have a functionality that "function registration". When the development engine, we have little way to write the specific script function. If you do the game, you need to write some specific script functions after getting the engine. At this time, you need to provide them a registration mechanism to make the script function name and function. Correspondingly. Here we provide the only registration mechanism is this Switch (NCMD). If you add something new script, you need to add new implementations to the corresponding number. For example, in addition to Function adds a new function Walkto, corresponding number 102, the grammat is Walkto (PARAM1, PARAM2, PARAM3), then what we need to do is: Switch (NCMD)
{
Case 101: // function
{
Dofunction (GetStrParam2 ());
}
Case 102: // walkto
{
Walkto (GetInTparam1 (), GetIntParam2 (), GetInetParam3 ());
}
}
Now the registration machine is part of the engine code level, every addition of new scripts will cause engine changes and changes, before we said, should try to avoid the engine change, how to solve this problem? The better implementation of the script registra is through C polymorphism. This way we can implement the Command as an abstract class, and each specific Commond is inherited and implements the corresponding interface. E.g:
Class command {Virtual void do () = 0;}; // abstract class
Class Function: Public command {// Concrete a Command
Virtual void do ()
{
Dofunction (GetStrParam2 ());
}
}
But how these new classes register to the interpreter? Because when doing an interpreter, I can't know which classes will come in! There is a way, Factory, Factory, which provides us with a clear guide. We can implement a set of factory and indicate the Factory type:
Class commandFactory {Virtual string gettype () = 0; Virtual command * create () = 0;
Class FunctionFactory: Public commandfactory {
Virtual string gettype () {return "function";
Virtual void create () {return new function;} // generate specific Command with Factory
}
Finally, we need to register Factory through Std :: Map in Run, associate Type and the specific factory. Here we connect "function" and FunctionFactory through std :: map. Finally, we only need: (pseudo code) when the function is matched.
// Analyze a line to get strcmd
Strcmd = parseline ();
// Look from Map to the corresponding strcmd's factory, assuming that strCMD is "function", IT-> SECOND will be stored in FunctionFactory
Iterator it = map.find (strcmd);
IF (it! = map.end ())
{
/ / Generate a Command object via Factory
Command * cmd = it-> second-> create (); // Execute a DO method for the Command object
CMD-> DO ();
// Destroy the Command object
Delete (cmd);
}
OK, now there is no way to add Factory and the specific Command in this way, this intermine is not need to change! Great. Let's draw this step:
Figure 3-6 Using the factory mode solved interpreter function matching map, there will be changed black marks, it can be seen that this set of engines will almost change, and it is necessary to write in other ways, robustness is quite high!
Ok, here, the script interpreter itself is basically solved. The rest of the work is to constantly register new script features as needed.
How does the script ultimately applied to the rules? Under our existing interpresers, who wants to use scripts, reserved the name of the script file, and then call CScript :: Run (const string & filename) to complete the task. In this way, we need to hang a member for each class that needs to walk scripts: std :: string m_strfile to store the name of the script file. Moreover, in the Logic of these classes, we need to manually call CScript :: run to run the stored script:
IF (m_strfile! = "")
{
Cscript :: getsingleton (). Run (m_strfile);
}
If everything is correct, the script will run. For our script, there is a speedy means. Every run of our script will be transferred to a file, and then turn the file again. If a frame requires 10 items to walk script logic, then each frame will have 10 disk operations, which is a serious thing for a large number of objects, especially triggers (later mentioned). This is a serious thing. The means of speeding up is to extract the file in a buffer in accordance with the file name. When you walk the script logic, you will not take the disk operation, but read data from the memory buffer, for a scene There are dozens of objects that this speed is already universal. However, each frame is not a disk operation, and it is sometimes necessary to change the script file frequently during debugging. For the case of time being transferred, you must restart the game after each modification, and you will not rereading a disk for each frame. I have encountered this problem. How to choose the right way of operation, this needs to see what is running.
Part assembly: the construction process of the specific game layer
After the frame is finished, a specific thing is required to prove whether our framework has achieved the expected goal. In summary, our requirements for this framework are:
1. Using the developers developed by the framework unnecessary attention to the bottom details of the frame, it is not necessary to pay attention to OGRE, just pay attention to the logical relationships and existence of each component. That is to meet the framework of the frame.
2, the upper layer logic is allowed and only allows you to deal with the frame. At the same time, the framework can contain important components that cannot be wrapped in OGRE.
3. If it is the function of the frame, it should be able to complete the task through a good completion task through the temporary extension of the frame. If you really need to modify the framework structure, the interface should also avoid modification. That is to meet the security of the interface.
Here is an exception that the function that is not completed is the function of OGRE, because this situation needs to be handed over to OGRE maintenance personnel to extend the OGRe library or to extend the OGRe library. In addition, if our test does not complete the established goals, I can think that I have failed.
Let's take a look at our needs:
1. Create an outdoor scene. That is, we have a map system.
2, there is a Player. That is, we have an object system and at least one item. 3, there are several monsters, the monsters have certain intelligence, this smart we will use the script histed on the monster. That is, we can hill the monster rules system for monsters.
4. When Player kills all monsters, the game is successful, otherwise the game failure is over when Player is killed. That is, we have a world rule system for the world.
First we build the Application class, its main function is to manage the initialization and deletion of all important components at the time of the application. All Singleton single pieces create and assign a stack memory when Application is starting, and destroyed at the end of the Application. This Application is similar to the overall tube root of OGRE. Then there are some of the preparations for some game layer objects, such as Player classes, monsters, etc., and register these classes and class factories to the ObjectManager object manager. These tasks are based on the extension and will not modify the original code. The Player class focuses on the control of the keyboard and the mouse, allowing the camera to move with these control, while Monster focuses on implementing some basic AI logic, such as "Search", "So", "Attack" for status Machine or script needs.
When Application is initialized, we are created in Scene to load the Scene.cfg scene configuration file, including the Terrain.cfg terrain configuration file and Object.cfg object profile, and some other related content related to the scene, For example, mist and Light, etc. Terrain.cfg is an OGRE's topographic configuration file, and Object.cfg determines the rule system hidden by each item. The key to these rules is the script file as a member of the object.
Below is a standard script file:
Objectnumber = 1
# Object-1
ObjectType = 7
ObjectPositionX = 220
ObjectPositionY = 220
ObjectPositionz = 220
Objectscript = insanity.ai
The ObjectScript = insanity.ai here is the "Crazy" rule system (AI) for the object.
By changing terrain.cfg and Scene.cfg we created an outdoor scene, then add a Player and several monsters to the scene by changing Object.cfg, and hang an AI rule for every monster. This first three steps are satisfied.
So where should the world's rules system should be connected? Hang up to SCENE?
Many people do this, and this is very simple, but I don't decide to adopt this method. Because Scene's function is clear, it is "management" objects and terrain, and Scene should be a strong road to make an administrator instead of game logic participants. So I decided to adopt another method: the trigger provided by the object system.
The idea of the trigger comes from a discussion: "It is an objective thing that is invisible to the naked eye." That is to say, it cannot be performed with a flesh, but the objective law of the role is in the dark. For our programmer, the trigger is white to say that the surface is unknown, detecting the current conditions while satisfying the condition, and feeds back to the system according to the pre-set setting. Another reason for using the trigger is that it has been used in the original works that the transplantability and modularization reflected in the trigger is better than directly hanging on the scene, and the performance has nothing more.
Leave from the imaginary argument, returning to our practice. Since the trigger belongs to the object system, each frame detects the condition of the inside, and generates corresponding results according to the conditions. There are two conditions here, one is IF (Player kills all MONSTER), the result is "The success of the game", the other is IF (PLAYER's health is less than 0), the result is "game failure". These two conditions we have connected to the trigger through the object script system so that each frame of the trigger detects whether he meets the condition, when satisfying the condition: "Bang!" When the trigger plus the trigger and registered to the object After the system, the 4th point of our demand is satisfied, and the final work is to constantly test and debug. When everything is correct, you can make it meet with you.
Section 4 Conclusion and Prospects
Through the interpretation of the game world, the summary of game logic, and the integration of the game underlying tools, our current framework is gradually born. In order to make the frame more can be tested, we use some methods provided by some design patterns to ensure the safety of the framework. Now the top game engine describes a little, for this game, our framework is standard. But do you develop a new game with this framework? the answer is negative. If you use this frame to develop an RPG game, then we still have a short skill, props and other systems; if we go to develop a card game, it seems that our framework is not too convenient for rule support; if we go to develop a football game, it seems that our The framework supports AI is too much ... and the OGRe itself is constantly updating, providing new features, and even denying the original classes and interfaces. But let's talk back, what game engine doesn't have this problem? Write the underlying engine is easy, but written a universal high-rise engine layer is very complicated because the underlying engine is only related to the slow platform technology, but the high-level engine layer is related to a colorful game. Not only that, but the presence of the high-level engine is limited by the functional limit of the underlying engine.
The road to walk is still very long, even for internationally renowned big companies, it is also in constant exploration and practice. But this does not show that the future is embarrassing. We have made a process of summarizing and interpretation from the bottom and self-discipline through this practice, looking for a engine in the middle of the change of multiple specific games and slow-moving engines. Layer fit. The content is complicated, and the expression of the performance means has a colorful game world, even if it is more complex, it is also possible to adapt to the rules and performance of the rules and performance through a certain degree of summary interpretation.
appendix
TERRAIN EXAMPLE
/ *
-------------------------------------------------- ---------------------------
This Source File Is Part of Ogre
(Object-Oriented Graphics Rendering Engine)
For the late info, see http://www.ogre3d.org/
Copyright? 2000-2003 The OGRE TEAM
Also See Acknowledgements in Readme.html
You may use this sample code for anything you like, it is not cost by The IT IS Not Covered by the
LGPL LIKE The REST of the Engine.
-------------------------------------------------- ---------------------------
* /
/ **
/ file
TERRAIN.H
/ brief
Specialisation of Ogre's Framework Application To Show To
Terrain Rendering Plugin
* /
#include "exampleapplication.h"
#include "OgrestringConverter.h"
#define flu_speed 0.2
#define flow_height 0.8
Class TerrainListener: Public Exampleframelistener
{
PUBLIC:
TerrainListener (Camera * Cam): Exampleframelistener (Win, CAM) {};
// Override Framestarted Event To Process That (Don't Care About Frameded)
Bool FrameStarted (Const FrameEvent & Evt)
{
Float Movescale;
Float Rotscale;
Float waterflow;
Static float flowamount = 0.0f;
Static Bool Flowup = True;
// Local Just to Stop Toggles Flipping TOW FAST
Static real timeuntilnextToggle = 0;
IF (TimeuntilnextTogle> = 0)
TimeuntilnextToggle - = evt.timesincelastframe;
// if this is the first frame, pick a speed
IF (est.timesincelastframe == 0)
{
Movescale = 1;
Rotscale = 0.1;
Waterflow = 0.0f;
}
// Otherwise Scale Movement Units by Time Passed Since Last Frame
Else
{
// Move About 100 Units Per Second,
Movescale = 10.0 * evt.timesincelastframe;
// Take About 10 Seconds for Full Rotation
Rotscale = 36 * evt.timesincelastframe;
// set a nice waterflow rate
Waterflow = flow_speed * evt.timesincelastframe;
}
// Grab Input Device State
MINPUTDEVICE-> Capture ();
SceneNode * waternode = static_cast
McAmera-> getSceneManager () -> getRootscenenode () -> getChild ("waternode"));
IF (WaterNode)
{
IF (Flowup)
Flowamount = Waterflow;
Else
Flowamount - = Waterflow;
IF (Flowamount> = flow_height)
Flowup = false;
ELSE IF (FlowAmount <= 0.0F)
Flowup = True;
Waternode-> Translate (0, (Flowup? Waterflow: -waterflow), 0);
}
STATIC vector3 vec; vec = Vector3 :: zero;
IF (MINPUTDEVICE-> IskeyDown (KC_A))
{
// Move Camera Left
Vec.x = -Movescale;
}
IF (MINPUTDEVICE-> IskeyDown (KC_D))
{
// Move Camera Right
Vec.x = movescale;
}
IF (MINPUTDEVICE-> IskeyDown (KC_UP) || MINPUTDEVICE-> IskeyDown (kc_w))
{
// Move Camera Forward
Vec.z = -Movescale;
}
IF (MINPUTDEVICE-> IskeyDown (KC_DOWN) || MINPUTDEVICE-> IskeyDown (kc_s))
{
//Move Camera Backward
VEC.Z = MoveScale;
}
IF (MINPUTDEVICE-> IskeyDown (KC_PGUP))
{
// Move Camera Up
Vec.y = movescale;
}
IF (MINPUTDEVICE-> IskeyDown (KC_PGDOWN))
{
//Move Camera Down
Vec.y = -Movescale;
}
IF (MINPUTDEVICE-> IskeyDown (KC_Right))
{
McAmera-> YAW (-ROTSCALE);
}
IF (MINPUTDEVICE-> IskeyDown (KC_LEFT))
{
McAmera-> YAW (Rotscale);
}
IF (MINPUTDEVICE-> IskeyDown (KC_ESCAPE))
{
Return False;
}
// rotate view by mouse relative position
Float RotX, Roty;
RotX = -MinputDevice-> getMouseRelativeX () * 0.13;
Roty = -MinputDevice-> getMouseReLATIVEY () * 0.13;
// Make All the changes to the camera
// Note That YAW Direction IS Around A Fixed Axis (Freeelook Stylee) Rather Than Natural YAW (E.g. AirPlane)
McAmera-> YAW (ROTX);
McAmera-> Pitch (Roty);
McAmera-> MoveRelative (VEC);
// Rotate Scene Node if Required
SceneNode * node = mcamera-> getSceneManager () -> getrootscenenode ();
IF (MINPUTDEVICE-> IskeyDown (KC_O))
{
Node-> YAW (ROTSCALE);
}
IF (MINPUTDEVICE-> IskeyDown (KC_P))
{
Node-> YAW (-ROTSCALE);
}
IF (MINPUTDEVICE-> IskeyDown (kc_i))
{
Node-> Pitch (Rotscale);
}
IF (MINPUTDEVICE-> IskeyDown (KC_K))
{
Node-> Pitch (-ROTSCALE);
}
IF (MINPUTDEVICE-> IskeyDown (KC_F) && TimeuntilNextToggle <= 0) {
Mstatson =! mstatson;
//Root :::Getsingleton().Showdebugoverlay(); MSTATSON
Showdebugoverlay (MSTATSON);
TimeuntilNextToggle = 1;
}
// return true to Continue Rendering
Return True;
}
}
Class TerrainApplication: Public ExampleApplication
{
PUBLIC:
TERRAINApplication () {}
protected:
Virtual Void Createframelistener (Void)
{
Mframelistener = New TerrainListener (MWindow, Mcamera);
Mframelistener-> Showdebugoverlay (true);
MROOT-> AddFramelistener (Mframelistener);
}
Virtual Void ChooseSceneManager (Void)
{
// Get The SceneManager, in this case a generic one
Mscenemgr = MROOT-> getSceneManager (ST_EXTERIOR_CLOSE);
}
Virtual Void Createcamera (Void)
{
// Create the Camera
Mcamera = mscenemgr-> createcamera ("Playercam");
// Position IT 500 in z Direction
McAmera-> setPosition (Vector3 (128, 25, 128);
// Look back Along -z
Mcamera-> Lookat (Vector3 (0,0, -300));
Mcamera-> setnearClipDistance (1);
McAmera-> setfarclipdistance (384);
}
Virtual Void CreateViewPorts (Void)
{
// Create ONE Viewport, Entire Window
ViewPort * vp = mwindow-> addviewport (mcamera);
VP-> setBackgroundColour (ColourValue :: White);
}
// Just Override The Mandatory Create Scene Method
Void Createscene (Void)
{
Entity * Waterentity;
Plane Waterplane;
// set Ambient Light
Mscenemgr-> Setambientlight (ColourValue (0.5, 0.5, 0.5));
// Create a water plane / footnen
Waterplane.NORMAL = Vector3 :: Unit_y;
Waterplane.d = -1.5;
MeshManager :: getsingleton (). CreatePlane
"Waterplane",
Waterplane,
2800, 2800,
20, 20,
True, 1,
10, 10,
Vector3 :: Unit_Z
);
Waterentity = mscenemgr-> createentity ("Water", "waterplane"); Waterentity-> setMaterialName ("Examples / Textureeffect4);
Scenenode * waternode =
Mscenemgr-> getrootscenenode () -> CreateChildscenenode ("waternode");
Waternode-> attachObject (waterEndity);
Waternode-> Translate (1000, 0, 1000);
// Create a Light
Light * L = mscenemgr-> CreateLight ("Mainlight");
// Accept Default Settings: Point Light, White Diffuse, Just Set Position
// NB I Could Attach The Light to a Scenenode if I Wanded It To Move Automatically with
// Other Objects, But I don't
L-> setPosition (20, 80, 50);
Mscenemgr -> setWorldGeometry ("Terrain.cfg");
Mscenemgr-> setfog (fog_exp2, colorue :: White, .008, 0, 250);
// MROOT -> Showdebugoverlay (TRUE);
}
}
/ *
-------------------------------------------------- ---------------------------
This Source File Is Part of Ogre
(Object-Oriented Graphics Rendering Engine)
For the late info, see http://www.ogre3d.org/
Copyright? 2000-2003 The OGRE TEAM
Also See Acknowledgements in Readme.html
You may use this sample code for anything you like, it is not cost by The IT IS Not Covered by the
LGPL LIKE The REST of the Engine.
-------------------------------------------------- ---------------------------
* /
/ **
@file
TERRAIN.CPP
@brief
Shows Ogre's Terrain Rendering Plugin.
* /
#include "ogre.h"
#include "terrain.h"
#ifangre_platform == Platform_Win32
#define Win32_Lean_and_mean
#include "windows.h"
#ENDIF
#ifangre_platform == Platform_WIN32
Int WinApi Winmain (Hinstance Hinst, Hinstance, LPSTR STRCMDLINE, INT)
#ELSE
Int main (int Argc, char * argv [])
#ENDIF
{
// CREATE Application ObjectTerrainapplication APP;
Set_term_handler;
Try {
app.go ();
} catch (OGRE :: EXCEPTION & E) {
#ifangre_platform == Platform_Win32
MessageBox (NULL, E.GETFullDescription (). C_str (), "An Exception Has Occured!", MB_OK | MB_ICONERROR | MB_TASKMODAL);
#ELSE
Std :: CERR << "An Exception Has Occured:" <<
E.GETFullDescription (). c_str () << std :: endl;
#ENDIF
}
Return 0;
}
reference
(1) "King of Game" - Sun Baing, edited, scientific popularization publishing house, ISBN: 7-110-04493-9
(2) "Design Mode" --Rich Gamma, etc., Machinery Industry Press, ISBN: 7-11-07575-7
(3) OGRE Documentation and Source Code - GRE Production Group (UK)
(4) "Analysis of Game Engine" --jake Simpson
(5) "Sword Queen British" Document and Source Code - Gold Point Studio (China)
(6) "OGRE User Guide" - Mage Studio (China)
