|
|
|
|
||||||||||||
|
:: Dungeon Siege University - U207 :: Here is the 'U207' stuff: Siege University 207: Non-Interactive Sequences1. Introduction
Overview There are four gizmos that form the backbone of NIS construction, found in "/Game Objects/gizmos/commands/nis":
The "camera waypoint" (cmd_camera_waypoint) is an extension of the camera command-it must be linked AFTER a camera command, and cannot exist by itself. We'll talk more about these later (see Camera Commands vs. Camera Waypoints below). NIS Gizmo Properties Before we actually create a NIS, let's go over the properties of each gizmo, found on the "Template Properties" tab. Enter NIS (cmd_enter_nis)
Let's put together a simple NIS to become familiar with the motions involved. In this example, we'll use two camera commands to move the view around the player character. We'll leave all values at their defaults, but you're more than welcome to experiment with them. As previously mentioned, the NIS begins when the "nis enter" gizmo receives a "we_req_activate" message. This message can technically come from anywhere, but because we want our cameras to focus on the player character, we need to know where the character will be-so we'll send an activate message from a "party_member_within_sphere" trigger. Place the Gizmos 1. Open your test map and place the following gizmos nearby:Wire the Trigger 2. Place the trigger_generic somewhere your character will walk.Now we have our trigger gizmo that kicks off the NIS sequence. When a party member walks into that tiny circle, the "enter nis" gizmo is activated. Now we need to define what we see during the NIS, and that will be accomplished by placing our cameras. Place the Cameras There are multiple ways of placing and adjusting cameras (see Issues in Camera Placement below), but we'll start with the easiest way. 7. Move both camera commands near the trigger gizmo, so they will be visible for the next step.NOTE: If you saw the camera snap but don't see the gizmo when you zoom out, you may have run into a small bug. Mouse over the area where the camera should be, and you'll see a selection outline. Left click and hold on it, and move it slightly right or left. If the camera gizmo doesn't appear, increase the distance you move it. Sometimes you will have to zoom far away from the camera gizmo and move it a little for it to appear. In-game NISs may not work correctly if some camera gizmos are present but not visible in SE. 11. Now do the same with the second camera. Move your view to the desired camera location/orientation, select the second camera command, right-click on it, and select "Set Game Object to Camera". The camera will snap to the location of your current view.Link the NIS Cameras Our two cameras are now placed. All we need to do now is link them so our NIS knows in what order to use them. Right now, both cameras have default "duration" values of 5 seconds and "order" values of "cor_pan", so the NIS will last at least 10 seconds and will consist of the camera view panning from one camera to the other. 13. Select the "enter nis" gizmo (cmd_enter_nis), right-click on it, and select "Link Object".NOTE: All this really did was copy the SCID of the camera command into the "next_scid" field of the "enter nis" gizmo. It's a graphical and easier way to copy and paste the SCID for NIS gizmos. 17. Select the first camera command, right-click on it, select "Link Object", then left-click on the second camera command.Finish the NIS by Linking to the "Leave NIS" Gizmo 18. Link the second camera command to the "leave nis" gizmo (cmd_leave_nis).NOTE: Every NIS MUST end with the cmd_leave_nis gizmo. If not, the game will never transition out of wide-screen mode, the UI will never return, and the player will not be able to control anything. If the player hits ESC, the screen will go black while it tries to resolve all the actions of the NIS in compressed time… but since the last camera command isn't linked to anything, the game will seemingly hang on the black screen. Either way, the player must forcibly break out of the game or reboot. 19. Save Objects.Test the NIS Our NIS chain is now complete. Make sure you have saved (with objects), and load up your test map in the game. Walk your character to the party_member_within_sphere trigger and step inside. If you left all gizmo properties at defaults, the following should occur:
Didn't Work? If your NIS didn't work, check the following:
At first glance, it might not be obvious why camera waypoints are useful. In fact, after you use them, it STILL might not be obvious why they are useful. In further fact, we only used them once in Dungeon Siege: in the Chamber of Stars "activation" NIS (map_world/gd_a_r1). The camera waypoint essentially adds multiple camera positions (waypoints) to a single camera command gizmo, all of which share the same parameters of the "parent" camera command. To elucidate: Camera waypoints MUST be appended to a camera command, and the ENTIRE chain (camera command + all appended waypoints) share the same "duration". The entire chain also shares the same "order", which, to have any visual effect, must be "cor_pan" (if the entire chain is set to "cor_snap", then the NIS view will immediately snap to the last waypoint in the chain, which negates the purpose of the chain). The duration of the entire sequence is divided evenly between each gizmo: the camera command and its waypoints. So, if you have a camera command plus 4 waypoints, and the duration of the command is 5 seconds, then each gizmo in the chain is allocated a 1-second duration (command + 4 waypoints = 5. Five objects divided by 5 seconds is 1 second per object). The motion between such waypoints won't look smooth and continuous unless the command and waypoints are exactly equidistant from each other; otherwise, if the distances are different, the view will speed up and slow down in its quest to arrive at each gizmo at 1-second intervals. You can see this yourself by placing a cmd_camera_command and 4 cmd_camera_waypoints roughly equidistant from each other and running the NIS, then wildly changing the distances between the gizmos-some short, some long. So why use a camera waypoint? The biggest value in waypoints is in editing long camera sequences that contain cameras at equidistant separation. In the Chamber of Stars NIS, the camera slowly pans around the inside of a circular room, constantly focused on the center. The nine cameras that comprise this sequence are at even distances from each other for the circumference of the room. The timing of this circular sequence depended entirely on events happening in the Chamber, which were always changing during development. Every time the timing changed, the durations on 9 cameras had to be changed, which also pushed the timing off on the cameras further down the chain in this ~80 second NIS. Having to constantly change 9 camera durations, and also having to individually count them to re-figure the total duration of the entire NIS became tiresome. Changing the circular sequence to use a single camera command, with a single duration, and multiple waypoints, simplified editing just a little bit, and was slightly more efficient. That was a lot of text to explain a small increase in efficiency for a rare NIS case. If you can find better uses for the camera waypoint, don't hesitate to let us know. :) 3. Issues in Camera Placement One of the most difficult tasks in making NISs is placing the cameras "just right". As of now (SE v1.09b), our tools for placing and fine-tuning camera views leave a little to be desired. Placing cameras may be a bit clumsy and frustrating at first; but like anything else, if you stick with it, you'll develop your skills and learn your own tricks to make it work for you. Placing and Manipulating Cameras There are three basic ways to place and manipulate camera position:
Match View: Set Game Object to Camera This method consists of moving the SE camera view to the desired location using your mouse, then selecting a cmd_camera_command gizmo, right-clicking on it, and choosing "Set Game Object to Camera". The camera gizmo will snap to the exact location and orientation of your current SE camera view. Right Mouse Button (Hold): Move camera view on the horizontal plane (forward/back, left/right) SHIFT + RMB (Hold): Move camera view on the vertical plane (up/down) Middle Mouse Button (Roll): Zoom camera view in/out. MMB (Hold): Rotate the camera around a fixed point in space. Where this fixed point is actually located is sometimes a mystery. Camera Controller: This tool can be found under the "View" pull-down menu, allowing more accurate movement of the SE camera. Pros: Using the mouse is by far the easiest way to get the "perfect" position for a single camera, since all you need to do is snap a camera command to your view with the "Set Game Object to Camera" command. It's basically WYSIWYG (What You See Is What You Get). Note that the actual view in-game will be slightly higher and wider than the view in SE, especially since the cmd_enter_nis gizmo changes the FOV from 60 to 80 by default. Using the Camera Controller can offset some of the difficulties in placing multiple cameras after the first (see below). Cons: Using the mouse is the least precise method of placing multiple cameras. That is, if you need to place your next two cameras at the same exact height as the first, or at the same pitch angle but 20 feet forward and turned 90 degrees to the left; this is a difficult (if not impossible) way to do it. It is impossible to select another object immediately after the snap, since you are now "inside" the camera object, and are always clicking on it no matter what. You also can't hold down the right mouse button to pan the camera away, since you will be right-clicking on the camera object, bringing up its menu. You will usually have to use the mouse wheel to zoom out, or hold it down to rotate away, but since the rotation origin can be close or far away, you are rarely positioned well enough to place a second camera. Using the Camera Controller may assist in precisely placing multiple cameras in relation to the first, but otherwise it is a time-consuming way to choose a camera view. Bugs: The "Invisible" Camera: When snapping a camera object to the view location in SE, sometimes the camera object will be invisible after the snap, or it will only be visible when the SE camera is at a certain angle relative to it. If you run the NIS with a camera in this state, it may not function correctly-the duration may be incorrect, it may be pointing in a completely different direction, or it may travel along a different track than intended. To fix this, mouse over the position of the "invisible" camera, or, if you don't know its exact location, draw a box over the area you think it's in. You will see a wireframe selection box when the camera is selected, even if the gizmo itself is not visible. Left-click and hold on the selection box, and move it slightly to the right or left. If the gizmo suddenly becomes visible, it is "fixed", and you can return it to its original location. Sometimes you may have to zoom far away from the camera gizmo, then select and move it a little bit, or sometimes you may have to move the camera gizmo all over the screen before it appears. Once it appears, SE knows the camera is there, and the problem is corrected. NOTE: Some gizmos, including cameras, will vanish if the SE camera gets too close to them. This is normal, and doesn't indicate an "invisible camera" problem. Eyeball: The Mechanical Method This method consists of using the keyboard/mouse and the "Rotation" tab of the camera's Object Properties page to maneuver camera objects into position. To check the view of the camera, you can select the camera object, right-click, and choose "Set Camera to Game Object". Left-Click and Drag: Move the object on the horizontal plane (forward/back, left/right) SHIFT + Left-Click and Drag: Move the object on the vertical plane (up/down, left/right) Arrow Keys (Movement Mode + Rotation Mode ON): Left/Right controls YAW, Up/Down controls PITCH. SHIFT + Up/Down controls ROLL. Arrow Keys (Movement Mode ON + Rotation Mode OFF): Left/Right/Up/Down nudges camera on the horizontal plane. SHIFT + Up/Down nudges camera on vertical plane. Rotation tab: This tab is found on an object's Properties page. There are 4 different ways to set the pitch/yaw/roll of the object here. You can drag indicators around the circle, you can use the arrow buttons, you can use the drop-down list to select a number, or you can directly enter a number into the fields. The Rotation Snap Increment setting determines how many degrees of rotation are added per button press, AND keyboard arrow keypress. Pros: This is the easiest way to fine-tune the location/orientation of a camera object once it has been placed. You can tweak the values a bit, look through the camera to check position, and tweak it again. You won't screw up what you're doing if you move the SE camera view. Cons: The biggest problem is the fact that pitch/yaw/roll isn't measured from the front of the camera, like an airplane, but from a fixed vector in space. If you set the pitch/yaw/roll to 0/0/0, the camera will point to this vector. All pitch/yaw/roll values entered will always be relative to this vector, and not the current vector of the camera. This makes it extremely difficult to apply your desired adjustments to the camera object if it is pointing in a wildly different direction than the zero-vector. Define: The Mathematical Method This method consists of explicitly defining the position and orientation values found on the camera gizmo's Properties sheet. The above two methods ultimately provide values for these fields anyway, so sometimes it is easiest to directly enter values or copy/paste them from another camera. Orientation: This field has a 4-number value. According to James Loe, one of our engineers: "The 4 numbers represent a quaternion. You won't be able to type numbers in yourself and have them make any sense. Or probably even understand anything that comes out." Given that, how can we use this field? By copy/pasting the orientation value from another camera object. If your second camera needs to have the exact same orientation as the first, copy/pasting this value is as exact as you can get. Position: We can actually edit this field with some knowledge, and it is documented well on the tab. Each object has an XYZ position (in node-based meters) relative to a particular Node. Pros: Absolute precision on orientation and position. Cons: Directly editing orientation and position can be time-consuming and not very intuitive. Can only use "orientation" by copy/pasting from another object's "orientation" field. Bugs: When copy/pasting an orientation or position value into a new camera, something odd happens: the gizmo aspect (the actual camera mesh) will jump to the new location/orientation, but the selection box stays where it is. To further edit the camera in this session, you must use the selection box, not the visible camera object. To fix, save, quit SE and reload the region; and both the camera object and its selection box will be in the correct place. Copying and Pasting Camera Objects There are two other useful techniques that bear mentioning:
Performing the standard copy/paste on a camera object can be useful, but it's a little buggy. When you copy (CTRL-C) a camera object, and then paste it (CTRL-V), the new camera object will appear directly above the spot on the ground where the cursor rests, AT THE EXACT HEIGHT AND ORIENTATION AS THE FIRST CAMERA… usually. Sometimes the new camera will be located at the same height, but will be turned 90 or 180 degrees from the original. Sometimes the new camera will appear so far above or below the ground, you'll think you didn't paste it. Just be aware of these issues when using copy/paste and it should remain a useful operation. Drag Copy "Drag Copy" uses the default key "C" to 'clone' the object in place, on exactly the same spot. You can then move this clone relative to the first object. This is highly useful for placing secondary cameras with the same orientation as the first, with a specific relative position. However, "C" is too easily pressed for me, sitting as it does next to "V", which is the default key to bring up an Object's Properties. Therefore, you might find it safer to assign Drag Copy to "ALT+C" or something similar (View | Keyboard Shortcuts). Otherwise, you may accidentally populate your region with multiple superimposed copies of objects without realizing it. The only real problem with Drag Copy is that, after you clone the first object, you usually still have the first object selected-NOT the new clone. This can screw up your wiring if you're not careful. Pressing the "Objects - Rotate Selection" key (Q) will cycle your selection through multiple objects under your cursor, allowing you to select the clone. Technical Issues in Camera Placement Now that we know how to place camera objects with impunity, it would help to be aware of some technical issues and guidelines. We'll touch on five subjects:
During a NIS, you never want to show more objects on the screen than the engine was intended to handle. The easiest way to "get in trouble" with this is by flattening your camera angles toward the horizontal when outdoors. The effect of this is to exponentially increase the number of objects the engine is obliged to render, drastically slowing performance. A similar case occurs when the camera is looking down at the ground from a high elevation. When outdoors, it is best to use similar camera angles to the normal camera system. In addition, certain camera angles will destroy a sense of immersion in the world:
Fog Distance Every mood defines the neardist (near distance, or 1% fog) and fardist (far distance, or 100% fog) of the fog. The neardist is the distance, in meters, from the selected character to the beginning edge of the fog. When entering a NIS, the neardist/fardist is calculated from the position of the camera, not the character, so the fog travels WITH the camera. This is nice in that you don't have to worry about moving the camera into fog, but you DO have to worry about showing the edge of the frustum. Since the frustum is still centered on the selected character(s), the fog will no longer hide its edge if you get near it with the camera. You also have to worry about moving the camera too far above the terrain or away from a particular object, since those objects will eventually be covered by the fog. This is easily fixed, however, by using different moods with larger neardist/fardist values inside a NIS. The Fog Bug: Finally, there is an unfortunate bug with NISs and the neardist/fardist calculation, drastically reducing their values. The net effect is that the fog seems MUCH closer during a NIS than during normal gameplay. This can be fixed by calling a different mood during the NIS that has larger neardist/fardist values, if necessary. Out-of-Frustum Cameras When the NIS begins, the frustum is centered on the selected player character. It is okay to have camera objects in the NIS chain placed outside this frustum, AS LONG AS THEY WILL BE INSIDE THE FRUSTUM AT THE TIME OF THEIR ACTIVATION. This can occur when the player characters are commanded to move during the NIS, effectively moving the frustum. If a camera object is outside the frustum when the previous camera is finished, then the NIS will hang, exactly as if the previous camera did not have a "next_scid" value (i.e. it's not linked to anything). Essentially, this is true, since the next camera is unloaded and does not yet exist in the game world. Linking Cameras Across Regions As long as a camera object is in the frustum at the time of its activation, it doesn't matter what region it is in. However, since SE can only work on one region at a time, linking the two cameras that cross the region boundary is slightly more work:
Sound During normal gameplay, the "virtual ear" that determines the volume/location of a particular sound effect is relative to the party members. Volume is determined by how close the effect is to the party, and location is determined by where the effect is playing relative the camera's view of the party (e.g. if the sound origin is to the left of the party, as viewed by the camera and NOT their facing, the sound plays in the left speaker). During a NIS, the "virtual ear" becomes the camera itself. 99% of the time, this is the desired behavior, and what you see on screen and what you hear will seem to match. However, you might find yourself in a situation where you have a long shot of the action, and a loud noise is supposed to play from a sound emitter near the party. Instead of hearing the loud noise, you may barely hear it or not at all, since the camera is too far away from the sound origin. In these cases, you may have to move the sound emitter or create a new one at the position of the camera. This was done during the Gom NIS for the sound of the elevator hitting the ground (map_world/gom2). 4. Subtitles Subtitles are the scrolling blocks of text that appear at the bottom of the screen during certain NISs, like the intro NIS at the very beginning of the game, or the Merik NIS. Subtitles are Conversations Subtitles are extremely easy to accomplish, because they are simply normal conversations--the exact same kind of conversations that appear when you talk to any NPC in the game. The only difference between a normal conversation and a conversation that produces subtitles in a NIS is that the NIS conversation has the "nis = true;" flag contained in its [text*] block. For an example of this, see the [conversation_narrator] block in "\world\maps\map_world\regions\fh_r1\conversations\conversations.gas" What usually happens is that an Actor (some kind of NPC), with a NIS-only conversation assigned to him, receives a "we_req_talk_begin" message from a trigger instance. Sending this message to an actor with a conversation is the equivalent of clicking on a speaking NPC in the normal game. When the actor receives this message, the conversation .wav file begins playing and the conversation text begins scrolling at the bottom of the screen. The speed of the text scroll is determined by the "scroll_rate" value in the conversations.gas file. For more information on conversations, see Siege U 208: Non-Player Characters. The Narrator Late in the Dungeon Siege development process, NISs were added that were narrated by an off-screen voice. When it came time to add subtitles, we were in a bind, since there was no easy way to add subtitles to the NIS without an actor and conversation, and there was no time to implement a code solution. So, the "Narrator" was born. The Narrator is an invisible actor who simply provides a source for a conversation, which prints text to the screen and plays the voice file. Since the character narrating Dungeon Siege is the King of Ehb, we added the "narrator" template underneath "base_king" in the npc_king.gas file. When placing the Narrator in SE, you will see a gizmo aspect, not the King mesh. Otherwise, running a conversation with the Narrator is exactly the same as any other actor. The Narrator was used at the end of each Chapter (except Ch9), and at the very beginning of the game (fh_r1). See fh_r1 for a typical example of how the Narrator is used. 5. The Party Wrangler Solving the Death Problem There is a major problem with NISs that we haven't talked about yet. The problem lies in the fact that NISs are just normal gameplay with a wide-screen view, no UI, and lack of player control. Because it's normal gameplay, the party members can still attack monsters, monsters can still attack party members, and the packmule can run all over the earth. In addition, the party members can DIE during a NIS, and the player is powerless to help them. Obviously, you should never, ever put the player in a position where he has to watch his characters get hurt or die when he can't do anything about it. To solve this problem, the Party Wrangler was created (/Game Objects/gizmos/commands/specialized/cmd_party_wrangler). To avoid combat and character death during NISs, the Party Wrangler does the following:
To return the party's alignment to "Good", the Party Wrangler is sent a "we_req_deactivate" message, usually at the end of the NIS. Nearly every NIS in Dungeon Siege uses the Party Wrangler to cease hostilities for the duration of the NIS. Solving the Fidget Problem A less immediate problem was the fact that party members, when not attacking, run a "fidget" animation. This sometimes gives them the effect of looking bored or aloof, which is usually not a problem EXCEPT when they are supposed to be listening to a very important speaker, like Merik or the King. When the King is making his grand speech, and the NIS camera is panning around his cell, it looks extremely odd to see Farmgirl put her hand on her hip, tilt her head and look off to the side, like she couldn't wait until he was done with his yammering. Instead of creating a "standing still" animation for every character and explicitly running it during NISs that require listening, the Party Wrangler was given the ability to "freeze" characters in place. When done correctly, party members will be frozen looking directly forward, seemingly attentive to the speaker. The King NIS in "/map_world/cd_r1" is a good example of this. Using the Party Wrangler The Party Wrangler actually has three Properties, for three functions. Each function is activated as soon as the gizmo receives a "we_req_activate" message. Each function is immediately deactivated on reception of a "we_req_deactivate" message:
In almost every NIS, the Party Wrangler is activated at the same time as the cmd_enter_nis gizmo. It is deactivated at the very end of the NIS, AFTER the final delay of the cmd_leave_nis gizmo (if the Party Wrangler receives its deactivate at the same time the cmd_leave_nis gizmo is activated, there is usually a 1-2 second "delay" while the camera finishes transitioning back to the pre-NIS point. The player still has no control during this delay). There are many examples of the Party Wrangler being used in Dungeon Siege's NISs, but "/map_world/fh_r3" has a very simple implementation. 6. Other Stuff to Know We've covered most of the information necessary in understanding NISs, but there's a couple items you should know that don't fit anywhere else. Hitting ESC During the NIS NISs can be "bypassed" by hitting the ESC key. When the player does this, the screen turns black for a second or two, and the game resumes after the NIS would have ended. What really happens, from an engine perspective, is that the NIS keeps running, but is no longer rendered to the screen. The game pushes through the NIS as fast as it will go, and tells the game that .25 seconds elapsed each frame, even though it doesn't render any of them. When the NIS reaches the cmd_leave_nis gizmo, rendering resumes. Cameras Delete Themselves This was mentioned earlier, but just to be clear: cmd_camera_command gizmos automatically delete themselves after finishing. This makes it impossible to re-use camera objects again for the same or a different NIS. Triggering from Camera Objects As you should already know, a trigger instance can live inside any object, not just trigger_generic gizmos-including cameras. If you would like to trigger an Action from a cmd_camera_command gizmo, add a "receive_world_message" Condition that listens for the "we_camera_command_done" message. Every camera sends this message when it is finished, i.e. when its duration has elapsed. Several Dungeon Siege NISs trigger events from camera objects to ensure correct timing. The intro NIS does this (/map_world/fh_r1 and fh_r1a), and so does the Gom NIS (/map_world/gom2). MP Versions of NIS Areas If your map will be played in both SP and MP modes, you'll need a MP version of what is a NIS in SP. What form this takes is up to you. Some NISs in Dungeon Siege (like the camera pan over Castle Ehb) has no MP "version", since it was unnecessary. None of the narrated NISs had a MP counterpart (game intro plus all Chapter ends). What WAS necessary was to include MP versions of NISs that forwarded the plot in some way, like Merik, the Goblin Inventor, and Gom. In MP, the events that take place attempt to mimic the events in SP as closely as possible, or at least contain the most important elements. Creating a "MP version of events" is just making sure, through triggers, that what needs to happen will happen even through no NIS is taking place. You may need to have trigger gizmos that are only SP or only MP, or you may need trigger gizmos that exist in BOTH SP and MP but have trigger instances inside it that are either SP or MP. For examples of this, see the following NISs (locations listed in Appendix below): Intro, Gloern, Merik, Goblin Inventor, Gresh, King, Swanny, Chamber of Stars, Gom. 7. Final Thoughts We've covered everything we're going to cover in this lesson on Non-Interactive Sequences. You should have a basic understanding of building NISs and some of the related issues and concepts. By far, the best things you can do to further your understanding of the practical workings of NISs is to study each NIS in Dungeon Siege, and experiment on your own. Following this section is an Appendix that lists the location of all 19 NISs in the game, each of which has its unique properties. Even though you will encounter many gizmos and configurations you may not yet be familiar with, they will reveal themselves to you with investigation. Remember that there are FAR more possibilities for NISs than have been explored so far in Dungeon Siege. While the 19 NISs in the game are certainly good to learn from, you might find much better ways to create your own. New technologies may emerge to make NIS-building even easier and more powerful. Never hesitate to share what you learn with other aspiring movie-makers! Appendix A - The 19 Non-Interactive Sequences in Dungeon Siege All NISs take place in the map_world map ("Kingdom of Ehb"). The regions where these NISs appear and the trigger SCID(s) involved are listed below. You can search for the SCID in the designated region to find the start of the NIS.
|
|
||||||||||
|
||||||||||||
|
©2002 eXtensive Design |
