If you want to script a game engine, do you embed the script in the engine, or the engine in the script?

Question

I'm new to scripting and combining languages with each other, so I have a question about something that confuses me. If you want to script a game engine, do you embed the script in the engine, or the engine in the script?

If you embedded the script in the engine, I can't really wrap my head around how that would work. Would you have this big script function you called every time you went through the game loop, passing along the inputs and etc.?

If you embedded the engine in the script, I could see how it would be convenient to just treat the whole engine just like a object in the script, and call a simple function each time you wanted to create something. On the other hand, how would the game loop inside the engine work? Having an extra thread for that seems like it could complicate things.

I haven't really found any good information that deals with scripting game engines. My engine is written in C++, and I am planning to script in Python 2.7.

Answer 1

You embed the scripting engine inside the game engine.

I've never used this but you probably want boost::python

Answer 2

Do you really need to script things?

If the project is just you, and you're not making a sprawling RPG you arent really going to gain much in the way of productivity by using a scripting language. But what about recycle time and ease of programming I hear people chime in with. Well.

• C++ has a slew of excellent tools and debuggers (visual studio), scripting langauges often do not have such tools, making error tracking and debugging difficult, especially as script code often increases in complexity over time
• You will have no performance issues with interop code
• Your state will be contained in a single place, with no duplicity that often occurs with scripting code
• If your recompile/re-boot time is longer than a few seconds, you should fix how your engine is compiling.

If you really absolutely must use a scripting language (and there are reasons it makes sense, for example, a sprawling RGP will have a lot of scenario logic that may be difficult to express in pure data) Its a good idea to push the scripting interfaces all the way out to the edges of your code. And only query single functions which contain no state.

You want to avoid building parts of your engine in script, and you certainly want to avoid duplicity of state at all points. You want to use script calls to answer "Questions", eg: "how do I react when I see the player", or "what sound do I play when I die". You dont want to be implementing your entire AI layer in script!.

Answer 3

For my implementation, I embed the script in the engine (I'm using Lua and my engine is C++). I use Lua to define the contents of the game, e.g. monsters, items, map generation, and maybe using it to script the enemy AI (haven't reached that part yet).

What I do is I have functions in my engine that are used to register these definitions into the engine, which are called during the initialization stage. When I need to create a new instance of, say a monster, I simply refer to the definition of the monster, e.g. its stats, graphics and instantiate it with those values.