FAQ: Scripting a game - 2 approaches

There are a variety of approaches you can take to this, broadly speaking you can split it into 'high level scripting' and 'low level scripting'.

Many games use high-level scripting, and expose a C-like interface which is extremely game-specific and easy for games designers to use e.g. addPlayerScore(100), moveObject(ID_MONSTER_1, 200, 100, 100). This means you have to add a 'facade' layer to your game which provides this simpler interface.

Pros:
- This is the simplest to integrate with a scripting engine (because C is easier to use than C++ with scripting languages).
- higher level interfaces means a less 'chatty' protocol between the script and the main game, which is more efficient
- more productive for the game in question, especially for non-programmers

Cons:
- Requires you to build a separate interface layer
- You can only get to functionality you choose to expose, if you forget something you have to go back and add it to the layer
- requires some identity mapping e.g. if you're talking about specific objects you need to identify them somehow using IDs, preferably numeric rather than strings because it's more efficient across the scripting language bridge. I recommend hard-coding some (like the player) and have others returned across the bridge on creation.

Low-level scripting is about exposing every method on every object and using the script just like C++. This is what the Python bridge does, and it's best when you want to prototype rather than drive game scripting.
- The layer you build is not completely reusable between games, because it is built for the game in question

Pros:
- You can get to anything and everything
- The script looks almost identical to C++ so turning a prototype into a real application is simple
- You don't have to invent a new layer of functionality, you just expose all the existing methods

Cons:
- It's less efficient, because doing a high-level game action will require multiple lines of script, each of which incurs the overhead of the bridge
- It's less productive, because you have to write more script to perform game actions. You can write reusable routines to turn engine calls into more game-specific functions, but these should really be in a compiled language rather than in script

So I would recommend using a high-level script interface for embedding in a game, and a low-level interface for prototyping or when the application is unknown (this is what we do with PythonInterface). I recommend either Python or Lua, both are well respected and have good info on their sites about embedding script in applications.

auf Englisch könnte ich hier 1000 gute Tips posten.
Mindestens