Rebuilding the script interface for NLS
Back when the NLS Game Engine was the school project, named “Saturn V” after the rocket of the same same, Adam and I pretty much threw the scripting interface together at the last minute just to get our game demo put together - the team that was assigned the task had no programmers, leaving all of us in a bit of a bind; one of the hazards of taking school courses. When we rebuilt the code and created NLS we kept a lot of the same hodgepodge scripting interfaces, putting in more as needed to get our final game projects produced. This is what version 1 of SAM:DATA vs Dr. Mal Ware II runs on. But now it’s time to take what we’ve learnt, organize it, make it consistent, and apply it - and this is what I’m currently working on.
Things I’ve learnt:
- The global properties object (we call it “gprops” after the common variable name used in both scripting and C++,) never grew out of being a hack. It was supposed to be a repository for things like player stats, etc. However, simple global variables or object structures in the scripting itself are more than able to handle this use case. It also was being used to store parameters for/from various modules: the window handle and the fog settings being primary culprits. The former was a hack as there seemed to be no “nice” way of passing that handle to the various modules that needed it. The latter were only ever stored in the global properties object as a hack anyway: I needed a fast, simple way to control fog in the DX9 module and slamming in a set of gprops was a TON faster than setting up a set of message handlers. Which leads into the next point:
- The message router and entire messaging system is not needed. It was originally designed around the idea that any module needed to be able to communicate with any other module directly. It turns out that this is an invalid concept: modules only every need to communicate with scripting. If a module needs information from another module directly, there’s a coupling issue. Better to have each module interface with scripting directly and let the game programmer decide what needs what when. In the situations where the script needs to get information from the engine on an event-driven model the modules that provide the information can set up callbacks for that task.
- Scripting CANNOT be a module*. By placing it in a module, in an attempt to try and make it so that different scripting engines could be used, we locked ourselves into a nasty hole: the entire interface registration had to be done in the scripting module. This meant that the moment any module needed to add something module-specific to the script language an instant dependency was made between modules. Try as we might, by using the global properties and messaging systems to provide “abstract” interfaces, the idea of having a modular scripting system never got any closer. So, after some discussion, I took the initiative and brought the scripting system into the main engine core.
Refactoring the script module into the engine core was not terribly difficult. Didn’t even change much, if anything, from the game programmer’s perspective. Now that that is in place, it’s time to chew on the design of the scripting system. Based on the experience I’ve developed over the course of developing and using the engine, I’ve determined that scripting needs to fill two major categories: first and foremost it should be the one and only glue system that turns a collection of modules into a game; secondly the scripting system should be capable enough to prototype new engine features. To accomplish these goals I’ve started a new scripting interface design document. This document has been taking some time to build (half a week or so of “free” time thus far,) but it has seriously helped me refine the over-all concept. Let me know what you think!