I'm looking for recommendations on books, blog posts, or articles about different ways in which game codebases use embedded scripts.

I am planning on using a scripting language embedded in the C++ implementation of the game I am currently working on but it occurs to me that there are many ways this could be done. The scripts could have lesser or greater scope relative to the C++ implementation.

I'd just like to read an overview of various common approaches to scripting but haven't really found much.

I know of no comprehensive book or resource for this. There's been a number of GDC talks over the years on the benefits of Python, Lua, LISP, and other systems. Also, I have personally used a number of different systems, everything from embedding Lua myself (and using it heavily at Roblox,) to building examples in Unreal Blueprint.

The consensus seems to be that there are two levels of “scripting:" Simple “player pulls lever, it opens the door,” and full-on gameplay-development behavior. The needs for these are vastly different! If you want to develop your game using “scripting,” then you will need support for things like type checking, debugging, ahead-of-time compilation, and so on. And, ideally, multi-threading!

If all you do is wire signal outputs to inputs, with some small amount of value conversion or timing or if statements in between, you may not need that – but, maybe it's better to build an editor that generates those “scripts,” rather than using a full scripting language.

For what it's worth, embedding Lua is really easy, and getting going in that path is easy, assuming your engine is largely C/C++. A set of macros and templates will help you bind to the Lua stack machine just fine, and you may even be able to run a separate Lua VM instance per major game object, to allow for threading. The big table you define that contains all the game engine interface functions, should probably be shared between the environments, and immutable once started, though. Also, Roblox is currently doing a lot of work on adding performance and type inference/annotations to Lua, which is an interesting future, although whether all of that will be open source or not, I don't know.

Finally, if I were to build a scripting language today for a game, I would take a long, hard, look at embedding a WASM interpreter library. The good part about that, is that you get most of the “compiler / editor / debugger” support for free, and you can use real languages like Rust (or even C++) to generate the “scripts.” Yet, you can compile and load code at runtime, if you want, without having to re-load the entire engine. The main challenge for you there, is defining a well-performing interface between the game engine, and the scripting environment, but that's a challenge you will have using any solution.

jwezorek said:
The scripts could have lesser or greater scope relative to the C++ implementation.

Which is also notable by itself a reason against it. People are still writing code, they're just using an additional language to do it.

You pay the costs to write the code either way. You write the main code in C++, or write the code in the scripting language, either way someone is writing the code in some language.

The EXTRA costs are:

• You are writing, debugging, and maintaining all the bindings between C++ and your scripting language.
• You now debugging in TWO languages, instead of debugging in just one.
• If non-programmers are programming, you typically get more bugs.

The big benefits are:

• The scripting language may have an easier solution to a problem than the C++ code.
• Non-programmers can modify the script, it doesn't need recompilation of the program.
• Potentially additional people like designers, possibly some artists, producers, and senior QA folks, can contribute to the code side of things.

If you're working solo or on a small team it often isn't worth the extra costs. On large teams with multi-year projects the extra costs are small relative to the potentially large benefits.