Game Engine analysis (8)

Original Author: Jake Simpson
Translator: Xianghai

Part 1: script System

Script System
We have come to the script system from Part 7 of the game network problem, because of the opportunity of presenting stories, it has recently formed a large game element. In a scenario that needs to be interpreted in a controlled manner, preprepared movie scripts are the solution to the problem. In a movie, this is usually used to handle or explain the situation to a partner, or the enemy to the hero. Of course, there are other ways to do this-narrative, reverse, and so on-but usually it is done by people and events in real-time scenarios. Of course, games are different. Game Developers should not do too much flashback in their normal FPS, because they usually need to load new environments or checkpoints, and new textures and/or models. All these extra processing and rendering can affect the performance of the major game sequence. You can reuse the scenario elements that are already stored in the memory for flashback, but that looks pretty crude.

Ravensoft's Star Trek Voyager: elite force makes extensive use of script sequences to generate events in the game and use the game engine's own editing scenarios.

An interesting trend in designing script plots in games is the use of the currently greatly improved 3D Game Engine to generate your own editing scenarios. This may seem quite obvious now, but a few years ago, when the 3D graphics card was still relatively simple, the editing scenario was usually made using a high-end 3D workstation, the obtained 3D animation is then recorded as a digital video file, which is stored in CD-ROM as a streaming file. It is rather unpleasant to say that you return to the relatively crude 3D scenes of real games from the beautiful images of the editing scene. But games like half-life and Star Trek Voyager: elite force make good use of their own engines to generate all the editing scenarios, the result is that the transition between the editing scene and the game is smoother.

Separating scripts from artificial intelligence may be a good idea. Script is an event that you have full control over a given scenario, and events that are barely controlled by players are created. Players 'move along tracking' to a given location, or create a situation that a game player needs to solve. A good example may be that the rock falls into the corridor and a new escape method needs to be found by game players.

Today there are some different types of script systems that can be used by programmers or artists, and they use very rational and logical ideas to properly do this. The first is a simple text-based, single-clue style, just like coding that our programmers are used. In many cases, it is actually based on C, although in a very simple form. There are a lot of things like "if this, then do that. Most scripts tend to be quite linear within the range-meaning they usually consist of many commands that are connected in order. In the world, move Role A to B. After that, let him speak. After that, move him to C. It's quite simple.

Then there is something complicated-Allow multiple clues, and actually allow variable situations. The variable scenario is that when the script starts, you don't actually know who will appear nearby, but you have to write the script in this way so that anyone nearby will work. For example, a normal simple script contains three guys, all of which are pre-defined and all of which will be discussed. There will be three people in a variable script. You cannot ensure that you are a specific person and must work in the same way. Or in an extreme situation, maybe only two or even one guy will be there, making it a little difficult for the third party to talk.

Raven faces a major problem in Star Trek Voyager: elite force: users may want to take a role from somewhere in a ship to another place, however, the path from point A to point B may change with each game. For example, they need to make Munro (the main role of the game you play) from the engine compartment to the transport compartment. Unfortunately, due to the non-linearity of the game, you may have damaged the turbine elevator before the event reaches this point, or maybe the Jeffries tube is damaged and cannot pass. Assuming that at the beginning of the script we do not know the status of the world, we have to write scripts for almost all possible things to apply to these 'If... What to do. And it just gets worse from there. Some of the situations we can establish provide so many possible combinations that it is almost impossible to accurately test every possible occurrence for a satisfactory conclusion. Please talk to anyone working in sin, Star Trek Voyager: elite force or deus ex. The QA department has traditionally hated these types of games because they have made their work 50 times more difficult than before.

You can imagine how difficult it is to write scripts for these situations. But that is what we need for today's non-linear game paths, and why it has won a lot of development support to achieve it.

Jim dose's discussion about the script System
At the end of last year, I interviewed Jim dose, a former developer of ritual, who is now a developer of id software and a designer of the doom3 script system (and other things. Although this interview has been around for a long time, it is still very insightful.

Jim talked about the script system and how to create an easy-to-use and robust system (opposite to containing all the features traditionally intended by the designer ):

The most difficult part of designing a script system is to know when to stop. Once you have finished and started running, you find many systems that can use it. For sin, the original idea was to have an easy way for the level designer to describe how the object moves dynamically in the environment. In the later stages of the project, we also used it to synchronize sound and game events with animations, track task targets in multiple levels, control the layout of HUD and the user interface of the computer console in the game, describes how artificial intelligence reacts to different situations and particle systems.

The complexity of control may also be quite difficult. When you put the power of scripts into the hands of creative people, they begin to explore what they can do. Often, they are inspired to do something that is just a little beyond the scope of system capabilities. It is easy to fall into this kind of incrementing 'only one more feature 'that allows them to do what they want to do. As the language grows, a language structure that may be meaningful to the initial specification has become significantly over-expanded. Sometimes it makes sense to rethink the system, but at that time you may have accumulated a huge number of scripts that must be rewritten. Like fakk2, sin suffered such losses. I don't have the chance to perform a large-scale thorough check on the script system until I overwrite the script system for rogue's 'Alice.

Amen, Jim. -- Raven has seen this happen in their Icarus system. Icarus is actually a script system of the same type as Jim described above, and is responsible for all script events in Star Trek: Voyager: elite force. It is used repeatedly in Soldier of Fortune II and Jedi Knight II: outcast. In order to solve the new problems that need to be handled by the system, these problems were not foreseen or unnecessary in the initial implementation, and many parts of the script system have been rewritten.

Visual script System
The second type of script is the visual script system. This method is not used to encode text files. In fact, you can use real roles to create your scripts in a real game environment. You can track the path of a role in the world, define the animation you use, and usually get a better idea about how your script actually looks. It doesn't really help much for the non-linear problem we have discussed, but it can indeed generate the initial script very quickly.

Next, Jim talked about the visual script system.

Visual script systems are useful, but they are often more difficult to implement. If they are poorly designed, developers may be confused when complexity increases. For example, artificial intelligence can be visually designed using a flowchart-like structure. It is very easy for you to visually express the way people behave. The box represents the State, the arrow represents the conversion to another State, and the role can be converted from one state to another.

A typical use of scripts is to control objects in the game world and instruct them how to move in the world. The ability to visually move an object to a critical position in an editor and play the entire motion may be more intuitive to a designer. However, it does have its limits, because it will need another interface to design any decision that an object must make in its movement. The ability is to differentiate the animated parts of a script from those produced by a program like 3DS MAX or Maya.

In some cases, users may need some ways to determine why a script does not do what they expect. Some form of debugging tools can make this work very easy. At least, some methods that determine which scripts are running and the current location of the scripts are required. It is also helpful to check variables, start, stop, and single-step execution in the script. Generally, a programmer can perform debugging in their debugger, but this process takes longer than if some built-in script debugger is available.

The above section is Part 1. In the next chapter, we will discuss the advantages and disadvantages of using ready-made products and custom game engine design tools, and then explore game control mechanisms to develop game objects, and some interesting things (weapon systems ).