Neverwinter Nights - Bioware Q&A

Remove all ads!

(Originally posted by Tiamat)

Interview with Preston Watamaniuk, Designer, and Mark Brockington, Lead Research Scientist

Q: Would it be misleading (or even plain wrong) to think of a finished and compiled NWN game to be like the main function in a C-Program?

A: If by the "game" you means a script, then yes, it is very similar.

Q: When using #include files, does the compiled game just take the code for the functions the game creator has typed into the script, or does it take the whole include file?

A: The compiled scripts take the entire file when reading it into the compiler. Think of an include as a file to be added, in its entirety, at that point in the script.
Let's say the included file (quick.nss) had the following pieces of text in it.
quick brown
fox jumped
If the main code looked like this:
The
#include "quick"
over the lazy dog.
The script compiler would attempt to compile:
The
quick brown
fox jumped
over the lazy dog.

Q: Does this impact performance in any way, and if so, should any include files be stripped so as to only include the functions your game has been coded to potentially call?

A: The short answer is that it doesn't really impact performance. The script compiler maintains a call graph that determines which of the functions (from the include files) can actually be called by main() and removes any compiled functions that couldn't possibly be called, through any possible inputs. We have a 1200-line "design" include file that contains all sorts of nice functions that our designers use on a frequent basis. If we had to include the compiled version of all of these functions into every script, each "compiled" script would be over 20 KB in size.

Q: Is it good design (or even possible) to put a switch case on a creatures/NPC's heartbeat event?

A: Not a problem.
The Switch statement in this case would look at a variable, one that is meant to represent what 'chapter' the party is in. So that in chapter 1, my recurring NPC's heartbeat would run a certain set of script commands and environment checks only, and when the party progresses to later chapters, the NPC/creatures/whatever wouldn't run the 'chapter 1' script anymore, instead it would run 'chapter 2' script, or script pertinent to whatever the current chapter is, only? There would be like a variable intChapter, and the switch statement on the heartbeat something like:
Switch (intChapter)
Case 1 : RunAllThisScript1();
Break;
Case 2 : RunAllThisScript2();
? Break;
case 50 : RunallThisScript50()
Break; etc.
My idea being to make things complex, but not have to run all the script all of the time.

Q: What scope would a variable like intChapter have to have, or asked another way, where would/should I declare this variable and increment it?

A: All variables and functions are public in the scripting language. There is no concept of Private and Public. However you can store local variables on pretty well any object within the game (Module, Area, NPC etc)

Q: How many case statements can be in one switch, in NWN?

A: Any integer value.

Q: I found the following three looping structures (For, While, Do) in my book on C. Would you be able to tell me which of them is the NWN language likely to contain?

A: All three are available in scripting. They are basic programming tools common to most, if not all, scripting languages.

Q: Will I also have to have function prototypes at the top of my script like in regular C?

A: Yes, you will. In NWScript (just as in regular C),you do not need function prototypes if the script is ordered so that the function is implemented before it is called)..

Q: Will NWN use semi-colons to terminate statements?

A:v Yes.

Q: Can we get any further information about placeable object properties (or even tiles) and NWScript? For instance, if we use GetNextObjectInArea() to loop thru objects around us, suppose we want to see if a chest is in the area, can we detect if it is locked/unlocked/trapped? How about a portal? Can we detect properties about the portal? Description, open/closed,etc.

A: You can check the properties on placable objects, open doors, lock them. The same goes for chests.

Q: How about tile properties - we've seen SetTileProperty(), any clues about what we can modify using that?

A: SetTileProperties is cut, you will be unable to modify tile props on the fly

Q: Here's another dangling thread from Mark B... Java-style classes (with member functions) within the scripting language are still not supported yet...are they supported -- yet? Will they be?

A: No, not at this time.

Q: It's been 6 months since we got the game-of-life example, and gathered as complete a list of constants & functions as we could from E3... any chance of a constant/function-list dump anytime soon?

A: No, this is constantly changing and fuels too much speculation. If we give a list of functions then we will be spending a week or more just answering questions about the various functions. People will try scripting before they can actually script, which will be unproductive for both content designers and our programming staff.