What is scripting, and what is a scripting API? Is scripting the process of writing the game program, and is the scripting API (such as the Unity scripting API) the API provided by the game engine, which we use to create games?
Some of the answers are very convoluted, so I will make it brief.
Programming languages can be divided in two categories: compiled and interpreted.
In compiled languages (e.g. C) the source code go through a compiler and produces an executable file that can be run on a compatible machine.
Therefore an script is the source code for an interpreted language. That means that the code needs an interpreter to be run.
In the context of games, some engines provide an API that represents the language that you write to use the functionalities of that engine.
Answering your question, usually games are written in compiled languages, limiting the scripts to very specific behavior (e.g. AI).
The principal difference between a script or a program is that the script is completely dependent of the API its scripting engine exposes to it.
If I code a game in C++ using a C++ game engine, I'm not doing any scripting, my resulting binaries are standalone and are not limited by the engine's API. I can use the virtual filesystem (if any) of the engine to read files, or I can completely bypass it and use calls to the operating system API.
Usually, when the game engine support scripting, I only can do what the scripting language syntax + game engine API allow.
Given that definition, If I'm coding a game engine and I want to support scripting, simply distribute a Python installer with the game engine and an API to allow the scripts to interact with the game engine may not count as scripting, as a Python program can do pretty much what a standalone program can. To adjust to my definition of scripting, a modified version of Python may be required, with many modules removed or somehow not allowed to use, then you can say the user of the engine is doing scripting, and not a full program that interact with the engine.
There are game engines that have their own scripting language and others that implements an existing one.
First, what are our goals? We want a lot of people to use the engine as effectively and as quickly as possible to prototype and make full blown games.
- Ease of use -> We need to abstract complexity
- Time needed to add and test a change -> We would like to avoid compilation
- Debugging -> We don't want people to touch our tested code; we need them to write their code separately from ours.
- Learning curve -> We may not want our users to need to know C++ for various reasons and prefer they'd use a simpler language.
I think a more precise metaphor would be this:
The Engine, the body, the lights of the car and all that stuff you probably should never touch (if all you want is to get somewhere) are the Engine.
The API is the keyhole in the starter, the wheel, the break pedal, the stick, the gas pedal, the clutch and little plastic handle that you use to turn on the lights and the one for the windscreen wipers and air-conditioner's knob and the radio buttons are the API.
You don't need to know anything about the Engine, air-conditioning, radio signal or the light bulb in your headlights to get the car running, playing music, air-conditioned and functioning really well enough to get yourself from point A - to point B. You also don't need to build anything new or modify any of the parts of the car itself.
So the car is like the Engine, the Scripting API is like all the controls you take for granted when you ride the car that help you forget how complex the technology behind them is, abstraction.
So in short, a scripting API is an hopefully easy way, to control a very complex system you possibly have little to no knowledge of by the use of abstraction, a preferably easy to learn interface and sparing you the need to build these services yourself.
You can however still modify things "inside" with some Engines depending on the contract between the company (creator) and the end user.
If a game uses scripting, it means it has a system of reading in a secondary language and converting that code into something it can run. For example Legend Of Grimrock, the main engine is written in C/C++, but it uses Lua as a scripting language to manage in-game events and monsters.
The main purpose of scripting is to be able to change a game's behaviour without having to recompile the game itself. This is especially useful for things such as monsters' stats - you wouldn't want to recompile the entire game engine every time you changed a spider's attack stat.
A scripting API (application programming interface) is the way a scripting language interfaces with a game engine. The game engine exposes functions that can be called from the scripting language to do things like spawn monsters, give the player items or just display messages for the player to read.
Scripting for games can range from simple operations with home grown languages to writing the entire game in high level languages like Lua or C#.
If we take a car analogy, a game engine is like a real engine, and scripts are everything else. Scripts are the fuel, body, wheels, steering, paint job and so on. Scripts are what make the engine run, and tell it how to run. Even though a car may have the same engine, they can drive and look completely different. Which is how we can have the same game engine under the hood, but have completely different games on the outside.
Scripting APIs are the connection points with the game engine that allow us to control it. API stands for Application Programming Interface. It's the interface between the game engine and the scripting language. These APIs go both ways, they allow us to get information from the game engine and allow us to provide information/instructions to the game engine.
Some engines are flexible enough that they give you the power to create an entire game with scripts alone. Some engines are just part of the solution and are available to build upon to create a game.