Powerpoint presentation given by Obsidian Entertainment's Erik Novales. Thanks to Challseus for the link. Here's the contents as text.
The Neverwinter Nights 2 Toolset: A Case Study in Tools Development
Erik Novales
Obsidian 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
Posted by Anonymous ( 12.221.xxx.xxx ) at 2006-05-03 10:34:04
WOW Neverwinter Nights looks Great and that is all
If you haven�t seen the new videos and new interviews you should check them out.
The single player game looks like they spent a lot of time and effort on their Single Player Campaign. That is probably why there will be no mounts in NWN2. Too much time and resources spent on Single Player and not Multiplayer.
I didn�t want hybrid BG/NWN I wanted Neverwinter Nights 2 with all the promises made to community from the get go.
Oh the uncontained Joy I have at the fact I will have to control a whole party and play all by myself. I think that it is obvious that Obsidian has neglected Multiplayer. Fergus him self stated that they just worked on the graphics and the Single Player Campaign. The load times for outdoor areas from what I could tell is horrible and that in it self is really going to be a thorn in the side for us who run Persistent Worlds.
The combat Animations from what I could tell were crappy like WOW generic canned animations with attack and no animations for parry and block like in NWN and KOTOR and KOTOR2. With all the eye candy you think they could have worked on the animations some more. This is really a HUGE disappointment.
I am interested in setting up this thread so that we can get a definitive Pros� and Cons� list going on here.
Here is a start
Pros�
Updated Graphics
Updated Rule Set
Updated Party Control
Updated Outdoor Maps
Updated Sub races
Direct X better Graphics in Windows
Updated toolset
Cons�
Crappy Combat Animations
Loss of Epic Levels
Loss of Individualism of PC Identity
Huge Load Times
Loss of the Community that use Mac/Linux
No Mounts Paladins still Nerfed
Severe limits to customizable Content
To me this game is looking more and more like NWN with updated graphics, crappy combat animations and a new Single player module.
I think that Obsidian is in denial of the fact that the community of NWN has the power to make or break this game and with virtually no improvement for multiplayer this game has a good chance of being a BIG FLOP.
Don�t get you hopes up too high people because the only thing Obsidian has ever done is a improve graphics of existing Single player games.
With that in mind expect to loose allot from multiplayer because they didn�t improve it at all and HW requirements are going to be disproportional to performance and expect awful long load times of areas.
If it comes with no mounts then it is incomplete, But that aside, If they have to push the release date back 2 more years to get it right then do it. Don't give use a game that "sux roxors" because it was rushed so much that they couldn�t keep their original promises to the community.
The only thing Obsidian has ever done is a improve graphics of existing Single player games and that is all they have done here.
Don�t set us up with unrealistic expectations only to turn around and say "Here is NWN with better eye candy" and a new Single Player Module with No real advances over the original like KOTOR2.
It seems he is on the right track here. The use of external "plug-ins" has me a bit worried, but hopefully this is just for the development process and not for the Builder or End-User. Keeping the familiarity of the previous toolset is very good, this should decrease the "learning curve" and increase productivity. It looks like this project is also focussed on one of the "bigger" problems with the present tool set, "conversation" trying to figure out talking "backwards" has been a real pain. Realizing this is due to how the Aurora Engine reads the data is why this is. Overall it looks like the new toolset will address alot of issues we are presently facing with the Aurora Toolset. _________________________ Link
You must be Logged In to post comments in this section.