Game Engine analysis (9)

Original Author: Jake Simpson
Translator: Xianghai

Part 1: ready-to-use products and customized game engine design tools, game-specific themes

Ready-made products and customized design tools
We have come to many topics in this section from Part 1 of the script engine, and we think those Hardcore gamers and those who want to become game developers will find them quite interesting. We will begin to discuss off-the-shelf products and custom design tools.

The choice of your tool is a very important part of your engine design, because it is the most time-consuming part that you will use to produce content for your game. Anything that helps save time and resources in this process is good. Those things are terrible. That's easy.

Of course it is not that easy. More things may be noticed immediately. Your toolkit selection is much more skillful than the asset path from a tool to a game, and is affected by many factors, such as whether it is suitable for hand-hand work, costs, familiar with content producers, market penetration, tool support, etc. If you want to select a spot finished tool, or even when developing your own tool, remember that the developer is actually doing the work, it is best to do what needs to be done by using the tool. Some spot finished tools are available at a price. When you get into multiple copy licenses, fees soar.

Then there is an attractive possibility to create your own tools from the ground up to design your game and engine needs. Of course, it takes time and a lot of effort from programmers to produce what is needed in a developer friendly way. Creating a window-based file converter quickly is one thing. Building a complete level design tool from scratch is another thing. On the other hand, if you do choose this path, you will end up with game developers taking tools that others don't have, so your stuff will look unique. Today, being different is a very promising thing, and highlighting from the masses from these days is a very desirable thing that produces all the competition.

Of course, because of internal tool development, you need someone to make all the inevitable small changes and corrections. But the true meaning here is that this is possible. With ready-made tools, tool developers rarely change their output file formats based on the features you need. In this way, your things seem to be more common at the end, otherwise you must use additional steps to use another tool to get the desired results, of course, it will take more time for developers.

It is worth remembering that many famous 3D tools have been around for a period of time, and there is no error in product production. More importantly, I already have some experience with what they have done.

If you choose to build your own tools, most of you are, a) recreate the wheel to some extent B) fall into the same problems that people who build ready-made tools have encountered, but they have solved these problems. It often takes considerable time and effort to build a single, specific tool and produce a tool that is far beyond your individual needs. In addition, they include characteristics that you think are useless or have no time to implement. Coupled with the typical characteristics of absorbing them, you may not want to be useful, or you may not have time to implement yourself. This cannot be argued by third-party software.

Plug-ins and target building tools
Generally, most game development processes end up with such a mix: self-developed File Converter tools and ready-made content creation tools, and some additional plug-ins of tools that require some special features. Ready-made tools have been providing functions you may need for a long time, but as inevitable, there are always some useful and helpful tools, or you cannot get anything that is absolutely necessary. A small plug-in may be a good alternative, and it is often the path that has taken. Preprocessing programs built for specific purposes are also available, such as converting a TGA file into a PS2-friendly format or something.

If you or your company is planning to build tools for a certain type of game, these tools are generally evolved from a project to a project, rather than being re-built from scratch every time. If you change the game type, it's good that tools that generate high-resolution models with each polygon hit capability are clearly not required for an RTS (instant Strategy) style game.

Gil gribb, the technical leader of rave software, said this to the question of 'ready-made tools' and 'self-built:

"Self-developed tools have the advantage of being customized according to the needs of your products. You have code that can correct any errors or add any improvements.

The disadvantage of self-made tools is that they are very expensive to build and maintain, and the cost is usually much higher than that of ready-made tools. In many cases, it is impossible to build your own tools due to the application scope, such as 3D modeling and animation software packages or Bitmap Editing Software. "

Of course, if you want gamers to be able to modify your game and you have built all the tools on your own, you must publish these tools to the world. This may cause a little doubt. Remember that part of the reason for creating your own tools is that you can lead your competitors. Sometimes releasing the source code of these tools may even benefit you a lot. This does provide a way to create content. Again, Gil gribb elaborated on this topic:

"I support releasing almost all source code. I don't think we are afraid of anything from our competitors. Legitimate businesses don't want to steal intellectual property rights. Game fans, amateur game makers, and the popularity of games can all benefit from the released source code. "

Well, our game engine profiling series is here. Of course we have already discussed many engine-related topics. Let's continue to discuss some specific game-related topics.

Game control mechanism
The control mechanism can bring a huge difference to the game in development, and sometimes even shows the type or style of the game you are creating.

Try to play a real-time strategy game with gamepad at some point-it is not just fun. Sometimes it is exhausting to invent new control methods for your game when you are limited to a specific input device, such as the mouse and keyboard. When Raven started developing heretic II, one of the first things they decided to do was to use the third-person camera with the mouse to try and find an intuitive way. In the past, most games used Tomb Raider-style cameras (chasing by third-person oments). They found that this often fails to work correctly and in many cases can bring setbacks to players. The camera often gets any angle of view. If possible, it moves the camera and sometimes changes the player's direction.

Assuming their target audience is the FPS game crowd, Raven needs to find a way for FPS game players to control Corvus intuitively. They did, but it did take some time, and in some different ways-should they fix the camera in one direction or let it float? Most game development efforts-unless a definite type of game is implemented with no virtual decoration-tend to spend some R & D to find the most direct merger of physical control devices and internal control mechanisms required by the game. Here is a hint-once you find that a method works, stick to it. Using this method to control what is inside the game can completely change the vision, intuition, and even the focus of the game into something you never wanted. Find something that works, prove it works, and leave it alone. Over-design control can lead to feature deviations and perceived game concept issues.

A good example of such feature deviation can be seen in Independence War. This game has so many modes, buttons, and so on that it is impossible to be familiar with and manipulate the game.

The key here is simple. A good rule of thumb is that in a normal game, if your game requires more keys than normal gamepad keys or fingers on your hand, then some things need to be redone. Note: I am not saying that a game should not be flexible-Soldier of Fortune must have many possible key settings. However, when you think that most of them are actually not needed, the quake engine has a good way. Yes, you can choose what weapon you want to use, but you do not have. The game will automatically do that for you. This is the difference between flexibility and over-design. If the game requires you to press a key to select a weapon, the problem may occur. Do you understand this?

Control mechanisms cannot be overestimated-a game often succeeds or fails based on how much control the player feels about the event or the primary role. If control is changed, redirected, or simply removed from them, it can lead to a lack of participation in the game itself. Needless to say, that is a bad thing. It will be of great help to spend time and keep it simple.

Entity and camera
Now we have come to the unpleasant part of the engine, which is also the least defined part. When a game is running, the game becomes more error-prone, time-consuming, or thorough.

Here we are talking about the "game" part of the game engine. This part uses all other technologies to display things on the screen, move them around, let them respond to you, and let you respond to things. This system has many methods, but now I will stick to the quake method because it is my most familiar.

Let's start with the entity. These can be defined as 'game object '. Now it doesn't just mean the model you see on the screen, although the entity definitely controls this-the entity may be something else. Basically, it is everything that the game needs to know at any given time, such as a timer that allows things to continue, a collision detection box for the model, special effects, models, game players, and so on.

Even cameras may be entities (in almost all Raven products ). Cameras are assigned an angle origin in the world, each of which is refreshed and informs the Renderer of where to get its field of view data, and off we go. Typically, entities are stored and loaded to return to the previous state of the game. The usual method used during the loading process is to load the game map, as if you are re-starting a level, and then loading all the stored entities, in this way, they will return to their State during game storage. Voila immediately returns a stored game. When I understand the heretic II method, this is not that easy-loading/storage has almost more problems than anything else, especially in collaboration mode.

Cameras have many forms:

Free Form: camera can go anywhere
Script: the camera can forward along a set path
Game time: the camera has a defined behavior that must be followed

It is not enough to say "well, I will only follow the main role. This means that you may also need to let the camera pass through the wall, or let it move in some ways, which may even cause nausea. It is also helpful to move it along some defined upstream and downstream motion paths, as anyone playing descent games for more than an hour can tell you. The body and the head are used to being a static variable, and they do not like it when it is not. Mike Abrash, who made Quake 1, once told me that even when it was defined, he still handled the mckabrash earthquake 1 and once told me that even when it was defined, he still felt sick from the game they were making. He mentioned that, for him, he had to leave quake for one year to settle his stomach. Aha, the sacrifice we made.

Weapon System
Another part of the game module is the weapon system. Most games have weapon systems or something similar. This is something that affects other objects in the world and enables them to respond to a given situation, such as being fired. Generally, weapon systems are composed of many different types; Attack Scanning, missile-based, and range form.

Attack Scanning is a direct attack weapon. What they produce on the screen is just that. When using it, it has nothing to do with the actual operations of the weapon. When you open fire with a pistol, the bullet is considered to immediately pass through the world and directly hit anyone/thing on its trajectory.

A missile-based weapon has a real shot that takes a limited time to cross the world, thus giving the other party some time to escape.

A range-based weapon is something like a grenade or a bomb and can hurt you without hitting it; you just have to be in the explosion range. Players in that explosion range are affected by a splash. Lava is another form of range-based weapon.

So how do you decide what is hit and what is not hit? Well, this issue has brought us tracing. We will go over more contact tracing in the next chapter on physics and AI. This is a set of function routines. Given a straight line from point A to point B in the world, for example, from the end of the gun to the predefined distance, it tells the game What is hit. Tracking is great, but it is very expensive because they have to perform 'collision check' on all the Polygon on the line to see if there is any hit, not to mention the model and other objects. This is also the way physics works, with a straight-down trace from a given role to know where the floor is located. Misuse tracking-for example, using them multiple times in a game's primary node-is responsible for the speed reduction of many games today. At Jedi Knight II: outcast, they have encountered this problem in the Battle of light knives, because they not only need to know whether the light knife has hit something somewhere and its current position, and they had to do this for all the points between them, and they tracked the light knife multiple times.

Well, another chapter is over. There are only two chapters left. Next we will introduce more details about AI and search.