Tools Development Case Study: Innovation in Neverwinter Nights 2 Toolset

2. The Neverwinter Nights 2 Toolset: A Case Study in Tools Development Erik Novales Obsidian Entertainment

3. Overview

4. 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

5. Tool Expectations • Answer community/licensee needs where possible

6. 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

7. 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.

8. (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.

9. (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.

10. 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.

11. 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 = $$$

12. The Neverwinter Nights 2 Experience

13. 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++)

14. 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

15. C#/.NET • Used for the majority of the code in NWN2’s toolset • Compiles really, really fast • Tight visual designer integration

16. 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?

17. Managed C++ Usage • Renderer interface • Script compiler • Some macro tricks to share game enums with the toolset • “It (pretty much) Just Works”

18. 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

19. 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

20. 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.”

21. 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.

24. Why buy UI? • Because we’re supposed to be making a game, not making fancy UI widgets.

25. But money can’t buy you… • Modeless UI • A UI that makes it easier to deal with huge worlds • An intuitive UI

26. 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…

27. 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

29. Data Visibility • Try and show related data together. • Trees and tables. • Reduce time spent cycling through items. • Better search capabilities

32. 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…

33. 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.

34. 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.

35. 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?

36. Example

37. 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.

38. Tools for Data Analysis • Visualization • Metrics • Export to common file formats (Office) • Crunch numbers in external tools. • Game statistics, asset information, dialogue information, etc.

39. Multithreading • Games are moving to ubiquitous multithreading • Tools should, as well

40. 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

41. Multithreading • Even more useful stuff: • Rendering thread • Running the game in the background • Faster data munging (path tables, visibility) • Automatic verification

42. 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

43. 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

44. Questions?

45. Thank you! • Contact information: • enovales@obsidianent.com