Scripting Languages: They Aren’t ALL Bad

Scripting languages have really fallen out of favor in modern game development. It’s easy to rile a working programmer up to a lather about poor debuggers, lack of threading or slow compile times related to a scripting language they were saddled with on a given project.

That said, the pendulum has swung too far in the anti-scripting direction.

The beginning of a console cycle is epitomized by a need for compatibility: “how can we ship on multiple prototype hardware platforms?” and tool efficiency: “how can we reduce the spiralling cost of development inherent in expanding horizons?” These questions led developers to make scripting plays in their engines.

In contrast, we are near the traditional end of a console cycle. We understand how to get a lot out of the hardware so the focus is free to move towards code execution efficiency in order to exceed the experiences players have had on the fixed hardware to date.

Looking past the consoles, memory latency is forcing us towards cache-friendly approaches to implementation which avoids indirection inherent in runtime bytecode interpretation and vtable lookups. Even if we push the CPU Ghz up, we aren’t going back to peppering our runtimes with vtables anytime soon thanks to memory latency overhead.

In this environment, it’s fully understandable that we would deign to avoid developing in languages like UnrealScript where only the rote engine-level loops are not bytecode interpreted. None of this means that scripting languages should be cut out of game development.

I see two places where scripting still beats out compiled code by providing new experiences for players:

First, scripting can be for one-off level scripting events. Scripts will always have a place as glue code. If you are nesting your loops in a level script, you have probably gone too far. Because you are not attempting to implement large parts of the game world in script and beacuse they do not run on tick, the performance impact is minimal.

A few lines of script is a natural alternative to abstract event firing systems. Visual scripting languages, ironically, are rarely informative at a glance. It’s much easier to see all of the code in one place than to click around a 3D blueprint looking for wires between entities and still need to guess at execution order.

The second use for scripts is more interesting. Right now, a big trend in games is towards online.

If you send state updates to your clients, the only way to add new behavior to your game is to patch your client. If you send script code for interpretation, you are only limited by the assets in the local cache and the hardcoded simulation to what your players experience.

The first version of Capture the Flag for Quake was written by Zoid before QuakeWorld. He took advantage of the fact that, before QuakeWorld, the Quake client was mostly a dumb terminal sending a subset of QuakeC over the pipe. Players could connect to his unique server without any mods and play CTF. This low barrier helped make Threewave Capture the Flag the first really popular Internet teamplay game.

If you are sending script over the pipe in 2011, please remember to fuzz your interpreter… and don’t drop in an off-the-shelf language that wasn’t designed with unsafe code in mind. Thanks.