When would I use "scripts" or "scripting" in a game, as opposed to the core language?

Question

The terms scripts and scripting appear to be used interchangeably on the Game Development Stack Exchange, but other than reading questions about a scripting language choice, I don't understand the relationship between scripts and scripting, and the core language. What does a script typically do, when would it be used, and are scripts in some contexts (as defined by game programmers) different than a scripting language?

Answer 1

Scripts are written for a scripting language. People can use the words in slang sentences to get the muddling that you are referring to but ask anyone for the definitions of Script, Scripting and Scripting Language and you will get something like: Scripting is the act of writing Scripts using a Scripting Language.

When you embed a scripting language into a game engine, or core language as you are referring to, you are exposing not only the objects within the game engine but also allowing logic to be written for the game engine. One other thing of note is that this turns your game into kind of a virtual machine, as scripting languages seldom compile down to machine language and are instead put into a form of byte code and interpreted at run time by your game engine.

This has some huge benefits to the development team, a few of which you can find listed next:

• Scripting languages are usually memory managed so you do not have to worry about allocations
• They are usually a loosely typed language that removes the need to make sure you are using the variable type for what you are doing, just make a variable and go with it.
• The languages themselves are often very simplistic while delivering quite a bit of control to people who are not programmers
• Altering scripts does not require the core engine to be recompiled.
• Scripting vs Coding often reduces the time required for very iterative tuning of game logic.
• Depending on design and language, you can often reload a script while the game is running for even easier tuning/testing.

I am sure the list can keep going on and on I am sure, especially when you get into specialized game types and how scripting can help define group formation rules for moving groups of units in an RTS or how you can create a UI's logic in a scripting language to provide an extensible UI to your end-users and the like.

Answer 2

Using scripting has many advantages over "core language". Some of these include:

• Moving (more) of the content from core developers to artists, freeing the core developers to engine tasks from gameplay tasks
• Scripts tend to be sandboxed, can't do anything really dangerous in it
• Modifying scripts does not require recompilation and re-execution of the game

Answer 3

A script is usually a piece of code that runs outside your core engine. It is usually contained within text files wherever you like to keep them. Then it is usually loaded by the engine, parsed, and executed at runtime.

What generally happens is that whatever language you use (Lua, Angelscript for example), this language usually has some facilities that enable the engine programmer to expose engine-functions or even entire classes to the instance of the "scripting engine" that is currently running.

For example (totally stupid example, but just to get the point across) your game code might have a public function that spawns zombies somewhere:

void SpawnZombie(int x, int y, int hp /* whatever else */)
{
   //...
}

The scripting language that you use now enables you to expose this function to the scripting parser that is running. This effectively means that you can open a text file, write "SpawnZombie(200,300,1337)" and once your engine executes the code, a Zombie will spawn at that location.

The other answers already list a couple of good examples of how this is typicaly used, but they leave out one point which I find very important:

These kinds of scripts make it very easy to debug or test gameplay during runtime.

Let's say you want to figure out the perfect way to place a zombie in the map so it has the maximum scare effect on the player once they discover it. Without scripting support, you'd have to exit the application, change some magic numbers in the code, recompile and test it.

With scripting support (providing you already have some method of entering text during runtime, for example a debug console), you just type in "SpawnZombie(333,444,555)" and see how it looks.

In the same manner it could be possible for you to spawn weapons, vehicles, load different maps, change the values of some things in the game etc, instakill enemies because you don't want to waste time getting to the part that needs to be tested etc.

This will save you tons of times in more complex games.

Answer 4

1) Scripts are often much easier to modify than code.

2) Scripts are often field-modifiable. This permits modding the game.

Answer 5

Most scripting languages are a lot more expressive than the language in the core engine. Often the engine is written in a relatively low-level language (eg. C++) for performance reasons, but the gameplay code doesn't need to be as performant and so the priorities shift toward being able to express functionality easily.

For example, dynamic vs. static typing. Another example: garbage collection vs. manual memory management.

Answer 6

Scripting allow you to write logic at a higher level. In other word, you write less code with more functionality.

So an example, the following shows the difference between writing something in code and writing it in a script language.

Game Code

Update Loop
{
    if (CarExplodeAnimation.FinalFrame == true)
    {
        SceneGraph.Remove(Car);
        Message("You have destroyed the car.";
    }
    else
    {
        CarExplodeAnimation.AdvanceToNextFrame();
    }

}

Script Code

PlayAnimation(ShipExplode)  // blocks until animation completes
Message("You have destoryed the car.")

See how much less coding the designer have to do if you use a scripting language?

The reason is becase in game code, you have to split an event into multiple frames, and write code from a multiple frames perspective. On the other hand, scripting allow you to think of multiple frames event as a just a single line of code, because all the extra codes are abstracted behind an script function.

You may asked, but can't that function just be written in game code too? Well, yes, but that means the designers will have to open the source code of the game engine and write all the codes in there, and you don't want your designers going through the source code of the game engine (they might accidentally change some other code and the whole thing crash).

Instead, you want your designer to do something like this instead: Right-click a car in the Map Editor, click Insert Script, type in the script codes. There's no messing with the critical game engine source codes.