|Engine Module Type String||Script|
|Module Type Usage||Single Type|
Scripting modules provide the connection between a game and the Drag[en]gine game engine. Only one Scripting module can drive the game engine at each time therefore this is a Single Type module. Launchers typically search missing Scripting modules for you so you have only those installed that your games really use. Scripting modules are often based on existing programming or scripting languages and can require installation of additional software.
Scripting modules are your gateway into the Drag[en]gine game engine and are therefore the most important modules for you. You have to choose one Scripting module to use for your entire game hence it is important to pick the right one. There are a couple of questions to take into consideration before choosing a particular Scripting module.
What programming/scripting language do I want to program my game in?
The chose of Scripting module forces you to use a given programming or scripting language. Chose the one which best suits your skills and experience as well as the one which provides the best performance for the kind of game code you plan to use.
How much abstraction do I require?
Scripting modules vary in the level of abstraction they provide of the game engine. Match the abstraction level with your knowledge to get the best result. Scripting modules with a high level of abstraction take over a lot of tasks so you can just give the major directions without having to bother about the details. Other Scripting modules can provide a very low level of abstraction to give you full control over even the smallest details of the engine. It is as bad to choose a too simplistic Scripting module as it is to choose a too complex one.
Do I required 'closed' code?
Open code is always better but sometimes you can not use open code like on game consoles. Some Scripting modules provide support for running compiled code against the engine while others do not require linking. The game engine is L-GPL which is rather open but in some situations this might still give troubles. Best to use are Script Modules not requiring linking (most of them are) as there you are totally free what kind of license you want to use and therefore closed code is not a problem there.
Once you have chosen a Scripting module you have to list it in your Game Definition File. Launchers ensure that your chosen Scripting module is available on the end user system. Once loaded control is headed over to your game code. See the documentation of the your chosen Scripting module about how the code has to be written in order to run.
Scripting modules are a crucial part which is why in their development you have to pay attention to a lot of things. The main problem is how to wrap engine objects. The Drag[en]gine game engine provides resource management using reference counting. This avoids memory problems but can also be rather tricky. Except a few cases there are no callbacks coming back from engine modules to your Scripting module. If you require certain feedback you have to write intelligent wrappers. Consider the engine and its modules as a sort of dump worker which operates on your calls. Except managing resources your Scripting module is in charge of directing the flow of operation from the scripts to the engine.
Since this module is very complex it is best to consider the entire documentation to learn about the various parts of the engine you have to control. To get you started though you can have a look at the deBaseScriptingModule for the beginning. More informations will be provided in the future.
Note: The scripting module definition is still worked on. More stuff will be added until the first release.