embedded scripting language deep rationale

Question

My question refers to:

Scripting languages and Game Dev/Programming

What I'd like to ask about is the deep rationale for embedding scripting languages into games. If you check wikipedia:

http://en.wikipedia.org/wiki/Freescape

Then you can see that a 3D engine from the 80's used an embedded scripting language. A game running on the ZX Spectrum 48, say, had an embedded interpreter for a scripting language. That the embedding of scripting languages has remained popular so long, seems to imply, that there are deep-rooted reasons for embedding a scripting language into a game. What reasons to do so have remained from the 80's all the way to present times? Or have the reasons changed? The answers given in the referenced question cannot possibly all apply to the situation of the past eras of computing.

Answer 1

All of the benefits of scripting now applied equally then. So you can immediately award points for:

• separation of concerns — the level designer and the engine programmer almost needn't even be on talking terms as the specific game becomes a separate project from the main body of the code; and
• faster prototyping and experimentation — Freescape's scripting language is compiled into byte code but the scripts tend to be very short versus the weight of the entire game, so trying out changes is faster.

In addition, the Freescape engine was a huge, expensive development for the time — they spent 14 months on it versus the month or two that most contemporary products received. Scripting all game logic achieved a significant secondary goal for them: portability.

The first Freescape game, Driller, uses exactly the same data and scripts across all of its releases. They had to build that out for the Spectrum, the CPC, the C64, the Amiga and the PC (a total of four CPU architectures, for a project that will have needed to be written in assembly language), but once that was done the game logic was write once, run anywhere — it became very easy to build subsequent games and release them simultaneously across the board.

Counting the 3D Construction Kit, they managed to publish five major games and two minor ones (Total Eclipse II and Castle Master II, both to juice up rereleases of the main title) over the following four years.

Portability isn't so much of a problem now as people use higher level languages and are generally isolated from the hardware, but prototyping and separation are just as important as ever.

Answer 2

I don’t know very well all reasons in the past, but I can imagine that all reasons from present are applicable to a game development from 80’s hardware/tools. It’s easier and faster to reuse “components” and edit them and it would be easier accomplishment for different tasks.

Scripting allows make better game prototypes. Sometimes takes too long to make a compilation of your (prototype) game just for test some new feature or configuration. Scripts allow on-the-fly reprogramming and to (re)test what you need. It’s not much different now. Seems the reasons don’t changed a lot. The main reasons probably remain because games (in special "triple A" games) are much more complex than before.