The Neverwinter Nights 2 Toolset: A Case Study in Tools Development

Erik NovalesObsidian Entertainment

Overview

Tool Expectations

WYSIWYG Make it easier to build and modify

densely-populated areas Reduce modal UI, and the length of

the change cycle Try and catch problems before the

game is run

Tool Expectations

Answer community/licensee needs where possible

Rendering

Use your game’s engine… …but you also have to have enough

flexibility to do things that you would never do in the game! Visualization of debug information “Actual” lighting versus “work” lighting Use of “scratch” data like temp lightmaps

Rendering

Client-server model Render to PC windows Render to console/TV Render to nothing – for testing purposes

Shorten the feedback cycle Things like color selection benefit greatly

from rapid feedback.

(Object) Population Explosion Game world population, much like

the real world, is steadily increasing. This rate of increase is probably

outstripping the growth rate of your design/art department.

(Object) Population Explosion Need to be able to quickly inspect

large numbers of objects. The fewer clicks, the better.

Need to be able to quickly add and modify large numbers of objects. The fewer clicks…you get the idea.

Modal UI

Modal UI is a productivity drain. At the bare minimum, it adds one

click or key press to an operation. If it’s a common operation, this adds

up really fast. NWN1 conversation/script/area

editors were effectively modal.

Verification/Data Analysis

Games in production tend to take a long time to start up.

Unless you can fix scripts/game logic at run-time, this becomes a big time sink.

Catching a bug at edit-time = $$$

The Neverwinter Nights 2 Experience

Early Experiments

Using old toolchain Written with Borland C++Builder Uncertainty of continued support Large amount of effort needed to make

even simple changes (C++)

Rewrite It?

Why? Cost of rewrite competitive with update. Opportunity to fix designer pet

peeves/productivity drains. Avoid becoming reliant on products that

are no longer supported. Only write what’s necessary

C#/.NET

Used for the majority of the code in NWN2’s toolset

Compiles really, really fast Tight visual designer integration

Oh, and Managed C++

Useful for integration with existing engine or game code

NOT recommended for anything other than glue code

Callbacks from unmanaged into managed code

C++/CLI?

Managed C++ Usage

Renderer interface Script compiler Some macro tricks to share game

enums with the toolset “It (pretty much) Just Works”

Where to start?

Programs are ephemeral – file formats are forever Targa

Nail down code to deal with your existing file formats Use testing tools like NUnit to check your code

Start by replacing infrequently used tools or offline tools

Rendering

Get your communications and resource interfaces working first.

Render on another thread, not in another process.

Managed C++ or C++/CLI can allow you to call your renderer directly Alternative: use tools like SWIG

User Interface

The user interface is the application. If a feature is awkward or difficult to

use…people will be reluctant to use it.

It’s no longer acceptable to say, “Just deal with it.”

User Interface

You can buy a lot of nice UI features nowadays: UI/docking managers Syntax-highlighting editors Toolbars Tree/grid views

This is exactly what we did.

Why buy UI?

Because we’re supposed to be making a game, not making fancy UI widgets.

But money can’t buy you… Modeless UI A UI that makes it easier to deal

with huge worlds An intuitive UI

Modeless UI

It’s really a data-dependency problem. If you have a deep understanding of

your data, you will understand where these dependencies exist.

Model-view (observer pattern) Unfortunately, it’s sometimes easy to

miss something in a big engine…

Multiple Selection and Editing The property grid Simple properties – piece of cake Composite properties – not a piece

of cake Try and define “normal behavior,” to

cover the most common cases. You may have to punt on the rest.

Example: creature inventory

Data Visibility

Try and show related data together. Trees and tables.

Reduce time spent cycling through items.

Better search capabilities

Other User Interface Tidbits Type reflection

Useful for enumerated types Have a standard notion of “processing”

a generic object, and build it into your UI. Handy for batch or one-off changes.

Ubiquitous preferences Users expect it now anyway…

Other User Interface Tidbits Plug-ins

Users are already familiar with the concept.

This is an easy way to remove functionality on ship, or for certain builds.

The All-Plugin Editor?

Project dependencies may start getting out of control

If you want to change things at that basic of a level…maybe it’s time to write another editor.

Verification

Can encompass a wide variety of checks

Golden rule: always state what is wrong (in a “non-programmer friendly” way), and, more importantly, how to try and fix it.

When there’s a bug, ask: can this be automatically detected?

Example

Verification

Scriptable tool? Technical designers can write their own

rules. Not limited to just preventing game

errors Check style/consistency Spell check!

Use plug-ins, so you can take out game specific stuff.

Tools for Data Analysis

Visualization Metrics

Export to common file formats (Office) Crunch numbers in external tools. Game statistics, asset information,

dialogue information, etc.

Multithreading

Games are moving to ubiquitous multithreading

Tools should, as well

Multithreading

Simple stuff: progress dialogs Little stuff like this makes people

happy. Never underestimate the power of

trickery like this. More useful stuff: background tasks

Word counter

Multithreading

Even more useful stuff: Rendering thread Running the game in the background Faster data munging (path tables,

visibility) Automatic verification

Perils of Multithreading

On Windows…UI updates VS 2005 is great for helping to catch

thread bugs Understand how Control.Invoke works Use an alternate communication

mechanism “Regular” multithreading bugs

Same type that you’ll see in the game Hyperthreading != Multi-core

Future Possibilities

Inductive UI (Web-like, task-oriented) Studies have shown that inductive UI is

more productive than deductive (menu-oriented) UI.

Better support for “tool languages” on consoles

Questions?

Thank you!

Contact information: enovales@obsidianent.com