I posted the following on the Card Kingdom development blog.
One of the new features that I wanted for the engine this go-around was the ability to script the entire engine. Previously, any change to the game, be it game play, adding a new component, or what have you, required a full recompile of the code base. This takes time and we are constantly discovering that time is the one thing in short supply. Scripting the entire game would mean that any changes, updates, fixes, etc. would only require a restart of the application. Testing time would be drastically reduced. Problems could be resolved quickly and efficiently with minimal time wasted. Smaller applications, such as a model viewer or an in-engine editor, can be quickly created and aid in the development of the actual game.
A common scripting language used for games is Lua. Lua works all well and good, but I’ve heard horror stories of teams trying to bind Lua to their engines and it just not working how they thought or being scrapped because of time constraints. Usually the cause of the headaches were that the teams would start binding halfway through their development process with already established workflow and application structure.
Binding a scripting language to a pre-build engine has more nuance than just wrapping script-exposed objects around engine components. It works well with objects that can be isolated and run almost independently of the rest of the code base. Primitive objects, such as points, vectors and matrices, can be easily bound. More complex objects, such as game objects and components, require more work as their interactions are more dependent upon one another.
The Squirrel language takes notes from other languages such as Java, JavaScript and C++ for its syntax, and Lua and Python for its dynamic typing of variables. Support for classes, inheritance, threads, delegates, exception handling, reference counted and garbage collection resource management, and other features made Squirrel stand out to me. Binding engine components can also be done in a relative easy manner. It does help to have a third-party binding utility that wraps it all in a clean and organized way, of which there are a few to choose from for Squirrel.
So far, many of the Core components have been wrapped successfully. A window, console, game application, and game objects, managers and components can be created in Squirrel and combined together just as they would in C++. Other packages, such as Audio, Content and Input, are in the process of being bound. My goal is that by the end, any object that can be created in C++ will be exposed to the scripting language and the entire life-cycle of the game handled via scripts. This will lead to much less time spent rebuilding the entire project after changing one tiny thing.