(bad)Magical game scripting

I have been picking through the quest scripting interface for oblivion and honestly I'm shocked that it works at all.  I get that it's implemented as a fun little dynamic language that anyone can pick up and use... but its also a giant stick to beat yourself with.  Horrible unstructured spagetti code sprayed with pretend objects, magic numbers, state fragments and every other crappy artifact of bad programming you can imagine.  There is only nominal encapsulation, no compile time checking... magic numbers are the order of the day... basically all the bad things that every paid programming tool set has been trying to help prevent for the past 50 years...

It's frustrating that each game platform re-invents the wheel with their scripting languages and re-creates the same set of bugs and flaws. 

That said, I sympathise with the system designers who are tying to balance accessibility and flexibility with function and some measure of protection for their runtime.

If only level designers were highly skilled programmers... lol.

This train of thought leads down the slipper slope of ... "If only..."... and "We could make it better if...".  However, everything has a price.  Raise the feautures and we raise the complexity for the users.  Feature creep in the scripting languages will only increase the debbuging costs and the chance of exploits. 

Look at matlab, labview, eprime, maxscript, (those are just the ones I have used in the past week) etc etc etc... every one of them started with the idea that they could make a simple runtime with a scripting interface and a few tools that would allow novice users to build ... stuff. 

They all have varying learning curves... varying degrees of depth, various mechanisms to help with bug management and usually user scripts with bug counts up the whazoo. (If the ones I have seen are anything to go by...)

I think the problem has been well described in many other places, the users are ignorant, the tools are unfriendly and the language is full of traps.  (Oh and the runtime is probably buggy as a termite nest.)

So... we have a problem... whats the solution? Better educated users? Tools that check and identify common classes of errors (static script analysis anyone?) and a less fragile language.  All the things every language community has been arguing about for years.... Nice to know I'm not cutting any new ground today...

Think laterally... make a graphical programming environment... drag and drop... boilerplate script... templates.. generics... maybe let the users do their own memory allocation... add raw pointers to the scripting language ...lol.  ...hmmmm no.  Is this a hopeless... fluffly problem that has too many dimensions?  No.

The thing is that the scripting languages are not trying to solve low level programming problems.  Usually they're pushing around high level constructs with very clearly defined abstractions.  The game world is very rigidly defined and the need for magic numbers is pretty limited.  Incrementing and decrementing a skill number can be done through a function call to increment() or decrement() rather than passing a raw int to a setter method.  This forces the script writer to play by some clearly defined rules that the interface designer has laid down and write their script at a level of abstraction and in terms of the "game" world... not at the level of raw numbers. 

A scripting language for a defined interface should not support lower level abstractions than are defined in the interface. 

This also means that patching the runtime does not break scripts.  As long as the abstractions in the interface do not change... everyone is fairly happy.  You can even write tests in the scripting language.


If a scripter wants to do something fancy.... let them write it up in a doc, generalise some cases and request a change to the interface... but for Oblivions sake, don't hand the tools and the responsibility to the scripters... its not their job to make the runtime safe.