I’ve been playing around with the Neverwinter Nights 2 Toolset – an IDE for the Electron Engine used to build modules to play within NWN2.
It’s buggy, crashes from time to time, and has lots of rough edges – but then you’d expect it to; it must have originally been developed as an in-house tool where the priority was on getting a game built rather than heavily testing the editor.
(Annoyingly, the latest patches cause both it and NWN2 itself to crash on my machine – I’ve had to revert to a couple of patches back, which may explain some of the bugs.)
The terrain, texturing and walkmesh editing tools seem solid and well thought out; and the library of ‘placeables’ works well. Where the whole thing seems to be ropey is around the scripting and conversation side. The interfaces are a bit obtuse; it’s difficult to find your way around, and there’s a monolithic feel to the coding system itself which means that the scripting feels clunkier than it really needs to be.
Granted, I’ve only just started getting to grips with it – the documentation is sparse – so there may be easier answers to some of the things I’m trying to do. But I have started to compile a short wishlist of ‘if I were rewriting this editor…’ things to do.
Some things I’d change:
- I’d allow multiple scripts to be assigned to events, rather than just one. At the moment only one script can be called for each event (events such as, for example, “On Use” for a lever). Since you tend to have a collection of objects which all behave in nearly the same way, you either end up with lots of small stub scripts, or with scripts that are parameterised to then call other scripts.
Switching it to accept a list of scripts – with a priority sort on the list – would make it much easier to create modular code. I suppose it’d be rather like Director’s old behaviours system. If this slows the actual runtime execution to a crawl, there’s nothing to stop the scripts being merged into a single script at compile time.
- The editor needs an ‘update my placed object from its blueprint’ button – for when you’ve edited something in the library and want the instance in the scene to be updated accordingly without manually copying over the changes.
- I’m really surprised by this one – it’s easy (via a library script) to add a condition to a line of dialogue so that the line is only available if – for example – a variable is set. But there’s no simple way to set a flag or variable when a line of dialogue is played without writing an entire script file to do so. Seems overkill. So I’d add a ‘when this line is played, set this variable/flag’ option.
- I’d have hierarchy of blueprints akin to class inheritance (“Sleeping Guard” derives from “Guard” derives from “Human”, for example). This would make it easy to modify generic behaviour (especially with stacked event handlers as noted above) and easy to apply changes to an entire set of objects. Again, this could be build time rather than runtime so should have little impact on speed.
- And the biggie: I’d do my best to allow a live test mode; to test the scripts and behaviours rather than the rendering. Because skipping out of the editor to load the _very_ chunky NWN2 game is slow, and must make level development and testing a complete nightmare.
That’s my list for now. It may well grow.
NWScript itself isn’t too bad – it’s sort of a subset of C.
Incidentally, trawling through library code I’ve discovered lots of comments by Naomi Novik, who wrote the quite excellent Temeraire. I’d no idea she was a coder, and no idea she’d worked for Obsidian/Bioware/Black Isle or whoever originally wrote those scripts. Interesting!