Skip to content

Concept

niv edited this page Jul 12, 2012 · 1 revision

All ingame objects are seen as actors, which are self-contained. This is a marked difference to traditinal NWScript: All actors are managing themselves, with no global script having access to other actors' internal state.

This results in a hugely simplified debugging environment and may be easier on the brain too.

Objects can communicate over simple messages sent to each other, which are acted upon in scripting.

While this will not cover all the required functionality for complex scripts, it's not (yet) meant to replace NWScript. Instead, it's meant to be a testbed for players to provide their own functionality; like selling scripted items that do cool stuff (this part of the concept still needs some work, admittedly).

There are a few requirements for this to work in a non-destructive, troll-resistant manner:

Sandboxing

The most obvious first: scripts need to be sandboxed and prevented from accessing any server resources outside of the script scope, or even the game server. Proper care needs to be taken regarding potential sidechannel exploits (like calling NWNX plugins by setting variables). However, this is fairly simple to do securely.

Resource limits

Scripts need to be (individually) limitable in resources, both in runtime and in memory usage. This should be also obvious, and is simple enough to do.

Permissions

There needs to be a permissions system in place that would limit script access to objects the player "owns". This will require a re-engineered object-orientied API for accessing, tasking and modifying objects.

Ingame objects need to be associated with player-owned scripts, such that permissions to objects, properties and methods can be exposed and limited accordingly. (TBD)

All exposed functionality needs to be "fair" in such a way that players cannot script what they cannot do ingame themselves. It also needs to be fairly exhaustive in order to be useful.

Fault Tolerance

The API needs to be structured in such a way that scripts can be stopped at any time, and that scripts state cannot be left in an undefined state. All script operations need to be atomic to the user (e.g. the ingame effect needs to either happen, or not), and all scripts need to be essentially state machines to be robust in the face of kills (due to resource limits or scripting errors).

Clone this wiki locally
You can’t perform that action at this time.