Upload
randell-brown
View
218
Download
0
Tags:
Embed Size (px)
Citation preview
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: [email protected]