So last night I had a bit of a look at how a javascript thing might work for the game engine. It tempered some of my enthusiasm but I also need to adjust my expectations. Security is a pain, and JavaScript itself turns out a bit ugly, although i can probably do something about that. Strangely the script engine doesn't let you implement new functions for the script? That's probably the weirdest thing about it; you can add objects but not top-level functions. The fact the javascript engine keeps variables around between invocations also makes things a bit more interesting, and not all in a good way.
I had a look at how I might implement a simple existing item: absinthe (it's not a drink i'm a fan of btw so the choice is arbitrary).
The existing item is defined over multiple separate files: the item descriptor and one for each script - 3 total files for absinthe.
Object
Obvious is to implement it as a full object with methods. The object name would match the script name, and all objects could be loaded at once into the script engine.
var absinthe = { onUse: function(thing) { thing.emote('wails: oh, my head!'); if (thing.getInte() > 10) thing.incrInte(-1); thing.remove('absinthe'); }, onDrop: function(thing) { thing.order("get absinthe"); thing.remove('absinthe'); } };
Drawback here is the scaffolding required. It's almost to the point that you may as well just use Java directly. I will probably do that too.
If the script engine were a proper execution container then things could be very interesting - the state could live inside it too, but I don't want to go down that path.
Script fragments
This is similar to the existing system, separate standalone scripts define each action. They are referenced via names in the objects.
absinthe_use:
thing.emote('wails: oh, my head!'); if (thing.getInte() > 10) thing.incrInte(-1); thing.remove('absinthe');
absinthe_drop:
thing.order("get absinthe"); thing.remove('absinthe');
It has similar drawbacks and advantages to the existing system - lots of little files to manage, separated logic, but also isolation and simplicity. It does allow for pre-compiled scripts though.
Script of functions
Here the script just defines top-level functions. It makes it a bit easier for the user to develop as they don't need to include all the scaffolding.
var onUse =function(thing) { thing.emote('wails: oh, my head!'); if (thing.getInte() > 10) thing.incrInte(-1); thing.remove('absinthe'); }; var onDrop = function(thing) { thing.order("get absinthe"); thing.remove('absinthe'); };
This approach has the drawback that the script must be parsed and executed separately, and must be parsed and executed every time.
Scripted actions
A compromise between the first two is to have a single script but also pass the script action to the script and let it decide what to do. e.g. use a switch statement. i.e. lets one put all behaviour in one file, but 'simplifies' the scaffolding.
switch (action) { case 'use': thing.emote('wails: oh, my head!'); if (thing.getInte() > 10) thing.incrInte(-1); thing.remove('absinthe'); break; case 'drop': thing.order("get absinthe"); thing.remove('absinthe'); break; }
Problem is that it doesn't really simplify the scaffolding, although it allows for precompiled scripts.
Thoughts
One problem is i'm thinking about the scripting system from the wrong viewpoint - more of a library of potentially compiled functions rather than thinking of it as scripts. I need to shift my thinking because they really should just be scripts, and not self-contained applications. If I support Java classes to define behaviour as well then efficiency of the scripting language itself isn't of a primary concern.
The fact that Java can't directly define functions sucks a bit - for example the "thing." prefix to every call. But I guess i can hide that with some simple global functions I inject on my own which hide the details for the main target object.
At this point i'm leaning toward the second option - i.e. much the same as the existing system. But I will look at some techniques for simplifying their configuration such as convention-based lookup rather than needing a pile of settings for each object. A convention-based mechanism would let me support multiple mechanisms without needing to change the file formats.
I might need to let this stew a bit for the moment, and whilst that is coalescing have a look at the multi-map/layer stuff which will be more fun to hack on too.
No comments:
Post a Comment