The big question of how much control and access to give to scripters/content creators, is something that I suspect we will continue to ask in game developement for a while.

Reasons to Expose More: Reasons to Expose Less:
    
  • Decouples maintanance and responsibility from the programmer - Script can implement more of their work and experiment without talking to programmers.
  • Less turnaround time, more 'content creator' efficiency.
  • Higher expectations - the more flexibility scripters have, the more that can be expected from them. Empowering them appropriately leads to higher quality games!
  • Reduces overall robustness, increases complexity - the more you expose the more that can be broken, and must be supported / validated / maintained in the future.
  • Is the code ready to be used in this way?
  • Should it be? Is the added work required to provide a proper interface to this feature worth the effort? Will script use it, or ignore it?
    • Example of Use: Example of Abuse:

    You are exposing matrix transformation functionality to scripts. You provide functions to build rotational, translational, scaling, projection and concatenated matrices. But you go further - you let scripters specify and modify the matrix row / column elements themselves.

    In this way they can also implement their own transforms that are not part of the 'pre-defined palette'. For example shearing, orthographic projection, mirroring etc. Its possible to create broken matrices, but this is acceptable given the extra flexibility.

    You are exposing GUI functionality to scripts. You provide functions to open and close screens. But you go further - you let scripters run scripts that position and scale the elements on the screen, provide support for non 'wide' strings to be displayed in them, and functions to manage the resources associated with the screen - dynamically allocated memory, file locks, and database connections.

    You also write functions to adjust pixel and vertex shader constants directly, rather then wrapping this up in more intuitive functions like SetGlowAmount().
    Script Empowerment: Script Obfuscation:
  • Scripts safely expose functionality, hiding encapsulation details and providing conceptual simplicity. Scripts remain robust! Exposed script functions are rarely refactored in terms of there names and parameters. 'Under the hood' they may be changed freely.
  • Un-needed functionality is are not exposed, and proposed script functionality is evaluated to justify its cost, likelyhood of use.
  • Descisions about what to expose are lead by mainly by design requirements, and clear distinction is drawn between exposing functionality and creating new functionality.

  • If you’re on a small team there may not be much point defining a hard interface between script and game code.
  • Scripts can easily crash or break the game. Instead of being 'black boxes' so much functionality is exposed to scripts that the classes they access become 'glass boxes' - intrinsically linked with the code that calls them, and therefore fragile. Changing and refactoring code is obstructed because the scripts know too much about it. Encapsulation is broken.  
  • Functionality is exposed more often then not. Lots of it remains unused, unknown and untested. Exposing functionality is seen as the right thing to do regardless of how appropriate it is to the game design.
  • Descisions about what to expose mainly lead by individual's requests and assumptions. Functionality creation becomes driven by script rather then by Design. Time is spent creating functionality that isn't needed, at the expense of functionality that is.
  • If you’re talking about the situation most game teams are in now (big teams with the bulk of code written in C++), I think the scripting interface should be as sandboxed (safely limited in what it can do)as possible.
    		•