Shulou(Shulou.com)11/24 Report--

Many games build levels from the white box, build the white box, and then beautify the scene.

But is there a lot of repetition in such steps?

The white box is built to see the effect quickly, which is understandable, but it seems to have many drawbacks. For example, after all, he is not the final game to the player's hands, so he is likely to be meaningless, at least for the player, the player can not see. Do less may not reflect the effect of the game, do more and go against the concept of quick look at the effect, where the card is not up or down.

The most embarrassing thing is that after finishing the white box, the beautification level often needs to delete all the white box, basically no dependence, once you need to modify something later, how to change it? Go to the white box and change it again, and then modify it again in the final scene?

In fact, the role of the white box is not only here, but also depends on how much each team attaches importance to the game development itself.

1. The significance of white box to the game development process is, first of all, why white box is needed in the game development process? This contradiction occurs at two extremes:

One kind of game map that people think is "perfect", like many 3A masterpieces, the whole map is a whole map, and the so-called "super-large map" that UE is trying to solve also refers to this kind of map. We have played many so-called "top 3A games". The repetition of the scenes and buildings in them is very low. except for some houses, most of them, especially in the maze, are very serious, such as the Tomb Raider trilogy, the "FarCry" series and so on. This does not mean that some of the Doodad in their scenes are not repeated. But the layout of the whole level (map), etc., is hard, not reused. In the words of Hideo Kojima, "when Europeans and Americans play games, they are reckless and hard against manpower."

In this understanding, the role of white box in the whole process is mostly "auxiliary scene original painting" and "communication confirmation level design". How do you understand this? That is, when we play a game, when we make a scene, we need to have the original painting of the scene to determine the art style of the scene, including architecture, terrain, hue, and other elements, and then what the scene looks like. Because the design to lighting, small objects, brush strange position, combat area, etc., but also have a white box to adjust, so the scene original painting + white box = determine how the whole scene should be done. If you savagely understand this process, it can be understood as "making a draft". Of course, this "draft" is very necessary, because it is very difficult to do well without a draft, but why is this process derogated to "making a draft"? first of all, there are a lot of conflicts between the 3D original painting and the model, especially some of the details you originally drew, but it is not easy to make a model. But these details are very important (important in the sense of art design) The same is true of level design. Very often, the hope of white box will break the performance of the model, or there are high requirements for model making. At this time, people compromise with each other through the white box. So don't underestimate the importance of this "draft". After all, once there are too many people involved in this barbaric and labor-intensive thing, it is difficult to unify a good direction and standard in every detail. So we have to make a draft to minimize the number of failed productions (mainly a waste of time).

Another kind of people think that the game map is a "combination of components". Of course, this understanding is right. In fact, this is also the "old way" of the game industry, that is, you make a lot of models, such as houses. Then you put it in different areas on the map, turn around different angles, and then there are some small details on these houses and other things that are removable, such as the last room in this house. There are many spires in the house over there, and there is a slight gap. In this case, it is really appropriate to go directly from the original painting to the 3D model and then put the levels, just like the map editor where we play a lot of games. For example, the series of "Heroes of Magic" and "Age of Empire" are all the same. And because the model is easy to mass production, or even if the quantity is not reached, because this kind of replication idea is in, so I have several representative models, I can directly do the level, and then adjust the details. In this case, it is true that the white box is of little significance, and there is little need for the white box in the whole process.

If purely in the sense of art, then whether to do a white box, whether a waste of time, completely look at the game project map (level) production ideas and tonality, the above two extreme styles and intermediate integration, in fact, are reasonable, so you say that white boxes are a waste of time, without specific design needs can not be seen.

But for this reason, it is inappropriate for you to say that white box work is pure waste, because game development, that is to say, in the production of this map (level), art is only part of the work, and it can even be considered to be the work of plus. The core content is that the map can be played, so you have to keep reading:

2. White box is a part of game data. Why do we need to make white box? A very important reason is that white-box data, for teams who understand game development, can be the final map data, yes, Map data, but not complete scenario data. Map data is the terrain and other information in the map.

Back to the most primitive logic, for example, we are now going to do a standard JRPG, then his map data can be a two-dimensional array, and the data in each cell is the information of a cell. Another example is the standard SLG game "Fire stripe Series". Even if it renders 3D, he still needs data in a grid:

1, what kind of terrain it is: forest, flat land or river, which is directly related to UI.

2, how much is its dodge: we know that different cells in the fire grain will bring dodge bonus, this is the rule of the game.

3, whether it heals or not: the characters standing on some cells in the fire stripes will restore health each time they turn.

4, its Cost array: that is, how much movement force will be consumed by each unit of action.

This information forms a Struct MapGrid, and then the map information is an Array. Why such information is needed is also to deal with the fact that the characters in the game have to act on the map.

As shown in the picture, the "grid" in the fire pattern is the same, any type of game will need such a structure, we assume that this 3D game is a magic ring-like soul game, or a ninja dragon, or a monster hunter game. Then the character in this game can walk, play skills (skills will lead to displacement) and jump; as a difference between classes, some classes can climb the wall, but others can't, and some classes kick the wall and bounce back (just like Chunli jumping to the edge of the page in the street bully can jump back). So when we do character movement, we need a series of map information.

Speaking of which, there may be a rookie who will say, "then we can use NavMesh and then directly use the finished model as Mesh." Then think carefully about whether these problems can be solved:

1. If all the characters in my game can jump and there are characters that can fly, how can you NavMesh help my flying characters find their way? NavMesh essentially takes the triangular faces of Mesh as the Grid and the adjacent triangular faces as the AStar of "next" (AStar is usually used to use the rules of the Tilebased grid as a next, such as the fire series map we mentioned above), but my character does not stick to the ground, how do you do NavMesh? You said that projection to the ground, that person can not walk the low wall, I can not fly over it?

2, walls, floors, ceilings-this is also the most classic movement problem in action games, how to tell if it is a wall first? Can it be considered a wall if the angle with the world coordinate system (UE is XY plane, Unity is XZ plane) is greater than or equal to x degrees (for example, 60 degrees)? It's okay to climb a 60-degree wall. What about a 120-degree wall? Most of the time, in order to do the details, the walls of the actual model are still concave and convex:

The model of this small house is good, at least it can be seen. Excuse me, should the two seams in the wall be able to climb? According to navMesh, the bottom of this seam is 180 degrees flat, which can be regarded as a roof, right? so in actual combat, you can't use the Mesh of such a delicate model as the data of NavMesh.

So at this time, the value of the white model began to appear, and we can use the white model as the map data, at least the blocking data-- we use shapes (not limited to Cube, but preferably only to triangles) to spell out the map block, and then attach some attributes to these shapes, that is, the attributes needed by the map. Whether Unity or UE, we can attach Component to them to achieve additional attributes. Although UE and Unity's Component are very different.

3. Using a white mold can escape the two big pits of stairs and slopes, but by the way, normal movement will not be done with NavMesh, but with shape rays (such as sending out capsules, preferably upper and lower conical rays to do collision detection). If you use X-rays for collision detection, you will encounter the classic "slope trap" and "stair problem"

What is a slope trap? That is, normally we encounter a slope, and suppose we think that the climbing force of this character is 60 degrees (of course, each character can be different), that is, he can walk up the slope of < 60 degrees (can it be equal to you). But how do we go up when we do rays? Because there is also an oblique face that cannot go up, there will be the following picture:

Here we'll do the 2d section, and we can see that the blue one is the route of the actual movement (deliberately raised a little bit because. The painting is not good. Anyway, that's what it means)-- because we can get the uphill vector after the "turn" through the normal, and finally the translucent blue of the dotted line, which is the moving force of the character, that is, the moving distance of this frame (a deltaTime,Unity and a FixedUpdate in UE). The red arrow represents the "normal movement distance" of the character if it is flat, that is, the top angle of view, so the length of red = = the length of the blue dotted line, because it is the amount of movement of 1 frame. And then we can see-- from the gamer's point of view, "uphill speed is slower than normal movement speed". Why? Because in the game player's mind, the movement speed is only horizontal axis, so in the XY (XZ) direction, the player's expectation is that the character can still walk so many red lines, right, so we need to use mathematical methods to supply him with this distance (how to make up for it, I am embarrassed to say, most of the academic qualifications here are higher than me, I know that you …... )-- this is actually the classic "slope trap" in game development, so if his terrain slope here is a circle (definitely an elliptical formula circle) or even a sphere (countless such triangles), the operation pressure will be much higher. In the end, the exquisite model is likely to have such a high-precision shape, but the white model will not-- this is the key to using the white model as the map data.

The staircase problem is also caused by the wall. Let's take a look at the picture below.

It is also a cross-section where each small square is a low "small wall", so should the character be able to pass? This is in conflict with the slope, because for example, our climbing force is 60, the "wall edge" of this small wall and the ground must be 90 degrees, greater than 60 degrees, and the movement algorithm must refuse to go up, then the problem arises. Shall we directly raise the character to a "stair height"? So what if this height is really not allowed here (people can't walk, bullets can fly over)? Or it's just a small hole, as shown below:

Shouldn't we have gone over there? So stairs are often a very common headache-if we look at them from a real-world point of view, how do we best make stairs? Quite simply, the white mold is a bevel, colliding with the character IK and the visual layer (that is, the stair model that covers the bevel):

Guild Wars two characters and her little pet (toy car) standing on the stairs, the yellow is the "white box" of the stairs, that is, the terrain information, and the blue is the collision of the character (as to why 2 cones and 1 column is a better collision.) while the capsule is a "make-do" collision, which is another problem and will not be discussed further here, the collision box determines that the character can walk up the slope, and pay attention to the character's feet. It is because the collision between the model and the model is combined with the visual effects made by IK, and the separate operation of logic and vision produces the effect that we seem to have.

4. at this point, you can see the value of the white box, right? In fact, the white box should eventually be used as game map data, not only for collisions, but also to add attributes to each "box" when we put it up, such as what does this box represent (grass or what? maybe it's logical? (for example, can this box be on the ground? Can it be a wall? Can we have the same day's ceiling? This is another detailed topic, which will not be discussed here.

In terms of the development process of the project, when the white box is completed, model art and edge art can begin to do corresponding art resources (what UE calls "assets"), and the planner can make the model on this basis, and the function of the program can also operate directly on it. Finally, as long as you "put on" the model made by art (because it is not replacing the white box, but the white box is not displayed. This can be set not to be displayed in both Unity and UE, for example, UE's HideInGame does this. Three people work together, no one depends on each other, everyone depends on the white box-the project development process is decoupled.

So is it a waste of time to build a white box?

This article comes from the official account of Wechat: game Design of Thousand Monkeys and horses (ID:baima21th), author: monkey and Huaguo Mountain

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.