Evaluation of Existing Toolset Interface

As discussed in section 2.3.4, a decision was made to design a suite of plugins for the NWN2 toolset, in line with the approach taken by the Adventure Author project. NWN2 is a computer role-playing game (RPG), in which players explore a large fantasy world and take part in a dramatic interactive story, with their own choices having an effect on how the plot progresses.

The game is part of the Dungeons & Dragons franchise, a series of ‘medieval fantasy’ RPGs.

Included in the NWN2 software package is the Electron Toolset: a game-development

application which was used by the developers, Obsidian Entertainment, to build the game itself.

This means that, in addition to playing through the included game, users can go on to build their own video games using the developers’ tools and art resources to design new 3D worlds and adventures. These user-created games feature new plots, dialogues, locations and challenges, but retain the same high-quality graphics and complex game mechanics one would expect from a commercial product.

The key in-game elements and objects which novice designers can create are summarised below:

Areas: These are the 3D areas which the player can travel through within a game. A game can have multiple areas, and these can be connected up through doors, triggers or scripted item interactions, as described below. The player must start within one area, at a location specified by the designer.

Creatures: This is the toolset’s term for the characters within a game. These can have greatly varying levels of importance and interaction potential. Designers can create a complex

conversation for a character and spend time customising their appearance and behaviours using

a properties window, or they can include a cluster of identical characters which act as extras, serving only to add to the atmosphere of an area.

Placeable Objects: These are objects which make up the scenery of an area, and they can also perform interactive functions causing events and actions to happen when a player interacts with them. These can be very large, such as a huge castle, or very small, such as a moss covered stone on the ground.

Items: These are objects which can be carried in the player’s inventory, and in some cases used by the player to some effect. These can be placed within an area like placeables, but they appear as an item bag, and can only be interacted with by being picked up. Items include things such as weapons and armour which can be equipped by the player and used in combat situations, things such as books which can give the author information on examination, and other usable artefacts such as scrolls and potions.

Doors: Doors are essentially a special type of placeable which can be opened, and if properly configured can be entered, leading the player to transition to a different area.

Triggers: Triggers consist of a polygon drawn on the floor of an area, which can cause actions to be carried out when the player enters them.

Waypoints: Waypoints are objects which appear invisible within the game, but which are used by designers to specify locations where events and actions should take place.

Sound Effects: Sound effects can be placed within an area to give background effects ranging from birdsong to people crying out for help.

Placed Effects: These visual effects can be placed within an area and give effects such as sunlight shining on to the ground or a fire burning in whichever location they are placed.

The key in-game events and actions which the designer can create for their games are:

Conversations: Designers can write interactive conversations for the player to have with the characters in the game. Each character can have only one conversation, but the designer can set up conditions for certain branches of conversations so that the lines a character says can change depending on what point of the game the player has reached.

Scripted Events: These are events which override the default inbuilt behaviours of characters and objects. By default certain behaviours are scripted, but these can be changed and/or added to by the designer specifying new behaviours which should be carried out in certain

circumstances. A specially designed visual scripting language, Flip, makes this activity possible for designers of a young age without programming skills.

Area Transitions: These cause the player to be transported from one in-game area to another, and they can be triggered by a player entering a door, entering a trigger, or using an item or placeable object.

Item Acquisition: Players can pick up items by clicking on them, resulting in them appearing in the player’s inventory.

Combat: Players can engage in combat with other characters. Sometimes this will happen automatically, as the inbuilt behaviour of hostile creatures is to attack the player as soon as they see her. The player can also start the attack by clicking on a character to attack them whilst still at a distance, or alternatively a fight can be triggered through a scripted event (commonly, when a conversation line is said that offends the other character).

Although there are many complexities to working with this toolset, around five minutes of instruction is enough to empower users to begin independently working on their own games, complete with interactive conversations, 3D landscapes, rivers, trees, buildings, characters, and other points of interest. As such, unlike most game-based programming environments such as AgentSheets (Repenning, Ioannidou and Zola 2000), Scratch (Maloney, Kafai, Resnick et al.

2008) and Alice (Kelleher, Cosgrove, Culyba et al. 2002), including those designed more specifically to support storytelling (Kelleher and Pausch 2007), it is not necessary to have programming or other technical skills in order to create something meaningful and impressive.

Instead, users are able to explore the possibilities of the toolset, and use it to build something which appeals to their own sensibilities and which they feel ownership over, approaching game building first and foremost as a creative task.

This initially shallow learning curve is invaluable for motivation and gives users the confidence to persevere with the activity. When pupils do eventually need to engage with programming in order to create more complex behaviours for characters and objects within their game, a visual programming language specifically designed for young people is available (Good 2011).

I chose to use the NWN2 toolset because it provides a way for young people to create their own games with commercial quality 3D graphics, has a good plugin architecture, and because tools to support other key aspects of game creation were either already available or being developed for this toolset (Robertson and Nicholson 2007; Good 2011). However, in repurposing a commercial tool in this way, and based on my previous experiences with the tool I was aware that there were likely to be elements which were less than supportive of the specific goal of supporting narrative-based game creation with a view to improving writing skills. Furthermore,

the design model drawn from the synthesis of literature and early inputs from classroom design work described at a broad level the interface support which would be required to meet this goal.

Therefore, the next stage in the design of the supporting tools was to evaluate the NWN2 toolset interface against the design model for representational support, and the narrative theory

established as most appropriate to narrative-based games in section 2.3.2, Chatman’s ‘story and discourse’ model of narrative structure (Chatman 1978).

3.4.2.2 Assessment of Toolset Support

In keeping with most game authoring tools, the NWN2 toolset interface centres on a 3D area view, as can be seen in Figure 3.2. The inbuilt mechanisms and representations in the NWN2 toolset encourage users to focus on 3D area design, whilst the storyline being developed is invisible. This is most evident in two key areas: in the creation of characters and other game objects, and in the overall visual representation of the game.

Character and Object Creation. Following Chatman’s theory of narrative, the ‘story existents’

in a game narrative are primarily implemented through the characters and objects within the game. The toolset contains a number of ‘blueprints’ or readymade versions of characters, objects and scenery items. The inbuilt method of character creation involves users clicking on a name in the blueprints list and moving the mouse into the 3D area editor to see a 3D

representation of their chosen character. They can then either place that character somewhere in the world or cancel the operation and choose another blueprint to preview. After the user creates a character they can open a properties window with over a hundred editable fields and

customise the character. However, important fields (in the sense that they affect the character’s interactions with other characters) such as those which define traits, skills and the character’s

Properties window

‘Blueprints’

list 3D area editor

Figure 3.2: Neverwinter Nights 2 Toolset Interface

disposition towards the player are not salient amongst a variety of obscure fields which users are unlikely to understand or want to change. There is no support for the important storytelling task of defining characters’ personalities; the focus is on the character properties which are relevant to the game engine. The process is the same for creation of other in-game objects.

This drag-and-drop based interaction method encourages a habit of adding multiple readymade characters into a game under creation, with elements sometimes left in the game simply by default. Since characters and objects are the key underlying components of a game-narrative, this unreflective approach is not beneficial. It can also encourage young people to add purely functional characters which have a gameplay role (such as increasing challenge) but no relation to the plot.

Visual Representation of Game. In the existing toolset interface the only visual representation of the game under creation is a 3D area view, which shows the level the designer is currently working on. The objects added to the game (representing story existents) are visible, but there is nothing to indicate whether a given object has a crucial role in the story (performing at least one plot-significant action and thus being a ‘character’ under Chatman’s definition), or has simply been added as scenery (an element of setting). Similarly, there is no indication of where story events will take place within the game areas. There are lists of conversations and scripts which the designer has written, and lists of character and object properties which can be used to deduce potential events are available, but none of this information is connected to the visual representation in any way.

There are no visual representations of the underlying narrative events (actions and happenings), or of the structure of narrative transmission. A journal editor is provided, which allows quest outcomes to be reflected through the player’s in-game journal, but it does not give a visual representation of the overall game narrative, and it is hard for young designers to use as it requires them to keep track of the numerical variables which represent different plot states. At present, attempting to consider the branching plot of a game involves the user keeping higher-level ideas about the narrative structure in their mind.

This lack of representation of story existents and events could potentially cause users to focus on the areas which are better supported by interface representations, as is reflected in the large amount of time given to visual area design according to participant estimates at previous workshops (Robertson and Good 2005).