Chapter 9. Scripting

"Life is like a B-picture script. It is that corny. If I had my life story offered to me to film, I'd turn it down."

—Kirk Douglas

KEY TOPICS

• Building a Scripting Language

• Embedded Languages

• Socket-Based Scripting

• In Closing

So far we have discussed how hard-coded AI systems can deal with many scenarios efficiently, from action to strategy and everything in between. Some games will work fine with small AI systems, whereas others will require tons of code to implement the AI feature set. However, as the AI grows in complexity, keeping it hard-coded will eventually become a problem. Hard-coded AIs are efficient, but are often limited in terms of flexibility. The internals of the AI are built into the game's source, so adding or changing anything requires recompiling the full source code, making the process tiring and troublesome. This is especially important in large-sized games, where many different AI types exist. Imagine a role-playing game with dozens of characters, each with his or her own personality, behavior patterns, and dialogs. Hard coding these AIs can create a bottleneck, can introduce bugs in the game's source code, and is overall a risky decision.

Under these circumstances, it would be great to externalize the AI so it could be run from separate modules that were "satellites" to the core engine. These satellite modules would be written in a specific programming language (often different from the one used in the main engine) and would run in a "safe" environment, so a faulty AI module would not cause problems for the main application. If these conditions were met, the AI modules could be coded by different people, such as AI designers, content production people, and so on rather than those coding the main engine. As a result, the benefits would not be limited to flexibility. These satellite modules would be useful for team management and program security issues as well.

Each of these satellite modules that externally implement AI (or, more generally, gameplay-related) routines in a specific language is called a script, and the global technique, scripting, is what this chapter is all about.

Scripting is a very popular method used these days where large teams work on even larger games. It streamlines the creation of the AI and logic content by placing that responsibility in the hands of people different from those actually coding the engine. It also allows for more creative AI design. Often, a dedicated AI programmer using a scripting language will come up with new ideas, and because the language will allow him to test them immediately, he will create more compelling and believable characters. It all boils down to selecting the right feature set for the scripting language so that it combines a powerful set of primitive calls with the ease of use your content team will demand.

Obviously, scripting languages will incur a significant performance hit, more so than a compiled, binary implementation done in a language such as C++. Here your mileage may vary greatly depending on your choice of language, because some scripts perform much better than others. Notice, however, that focusing on performance is actually missing the point concerning why scripting makes sense in the first place. A scripting language has more to do with extensibility and flexibility than it does with efficiency. But some of the more modern script engines, such as Lua, offer a small memory footprint and very good performance, so you get a "best of both worlds" solution.

There are many different approaches to using scripting languages. You can code your own, use an embedded language, or even communicate with the engine using a network connection. Although the goals are more or less identical, each approach has its advantages and disadvantages. For the rest of this chapter, we will analyze each approach in detail, so you can make an informed decision in your next game project.