Core Architecture: Major System: Behaviours - UA-ScriptEase/scriptease GitHub Wiki
Overview
Behaviours in SEII are largely based off Behaviours in SEI. As of Nov.22, 2013 the work on them is incomplete and much is to be done. I have documented the major systems used so far and the systems that will require implementation below.
Read this paper to get a better understanding: An Architecture for Game Behavior AI: Behavior Multi-Queues - Cutumisu, Szafron. Important points to take note of are interruptions and priorities.
Library
Behaviours are part of the SE Library model along with causes, effects, etc... If you do not see them in one of the library tabs, it is because it is hidden for release. Simply re-add them by uncommenting the two lines in LibraryPanel class:
- // this.add("Behaviours", this.createTab(behavioursList));
- // this.setMnemonicAt(6, KeyEvent.VK_7);
Composition
At its highest level, Behaviours are separated into two types; Independent Behaviours and Collaborative Behaviours. Whether a Behaviour is independent or collaborative is dependent on the tasks it comprises of. There are also Independent Tasks and Collaborative Tasks. These components can all be found in the model.
Independent vs. Collaborative
Independent behaviours represent an interaction attached to one subject of interest. No other subject is required to carry out the behaviour. Tasks are executed immediately after the other. Collaborative behaviours on the other hand is an interaction between two subjects of interest. Only when both subject's have completed their actions in the CollaborativeTask, is the next Task executed.
Tasks
Tasks are simply a container that can contain effects, notes, descriptions, and controls. There have been talk about moving them to Activities (ActivityIt) since they have many common functionality. The difference between a IndependentTask and a CollaborativeTask model-side is that a IndependentTask has one container, and a CollaborativeTask has two containers.
Tasks can have many successors so a question becomes, which Task should be executed next? Right now there is partial implementation of a probability model, but this model may be abandoned soon. It would make more sense for the successor task to be executed based on a condition that the user can specify. This complicates the creation process which is described more in the Library Editor section.
Behaviours in Stories
Behaviours can get very large, so for simplicity they are represented similarly to a effect with a modification button beside them. There has been talk of adding a B label next to them to increase visibility that it is a behaviour. Clicking the modifcation button then brings up the BehaviourEditorPanel which allows bindings to be dragged into the components in the tasks.
Library Editor
The creation of Behaviours are being done in the Library Editor right now. Since it isn't clear when the library editor will be released to the public (if ever; it may only be for developers), we should move the functionality to a separate builder in the near future.
Layout:
- Type panel: specify here whether this behaviour should be independent or collaborative, the rest of the view will change accordingly.
- Name panel: specify name and priority here
- Graph panel: Each node represents a task. Click a node to modify the task panel below.
- Implicit panel: This represents the behaviour initiator / responder KnowItBindingUninitialized. Drag these into components below to link it to components dragged into the intiator / responder slots in the story view.
- Task panel: Drag story components into here.
Work To Be Done
- As mentioned above, there should be support for tasks to be selected based on condition.
- Code generation is a big challenge. A priority queue should be used. Look into i_se_behav.nss in NWN translator -> resources -> includes for the SEI NWN-side implementation. A lot of functionality can probably be reused.
- Priorities are implemented model side, but they will need to play a part in the queue.
- Interruptions need to be implemented, and when returning to the prior behaviour, the start of the task that was interrupted needs to be resumed.