Originally posted on Runegame.com by Dave Halsted
Mirrored here for archival purposes
You start a cinematic by triggering a SpecialEventRune whose IntialState is StartCinematicSmooth (or StartCinematic - there's a subtle difference in how these two start up, but they're the same in function). Under this SER's Event property, enter the Tag that all the camera points will share. I always put this tag under SER->SE->ObjectTag as well, to be sure, but I think it's only necessary in the SER->Event slot.
Under this same SER, you'll also find Cinematic->bAllowSkip. This dictates whether the player will be able to skip the cinematic or not.
Now you want to lay down your camera path. You do this by placing CineInterpolationPoints (Under Keypoint->InterpolationPoint).
Highlight this in the Classes browser and go about placing them in your map, using "Add CineInterpolationPoint at Camera point here" by right-clicking in the 3D window. Let's say you lay down ten of these to make up your cinematic. Make sure that all 10 have the same Tag, and that this Tag is the Event of the SER that's starting the cinematic.
If you insert that tag on the first CineInterPoint you place, RuneEd will remember and name subsequently-placed points accordingly. Also, RuneEd will automatically enter the appropriate "Position" value as you place them. As you place them, you can turn on View->ShowSplines and your camera spline will be shown in green in any window. This updates in real-time if you move your points about or renumber their position.
"Position" tells the editor what order to build the spline in. 0 (zero) is the first point on a path.
Note that when you go to make a separate camera path in the same map, RuneEd will be a bit confused at first and try to auto-name/number the new CineInterpolationPoint into the existing path. Just change the info on the first one you place, delete it, and start again, and RuneEd will work fine building a new, separate path for you [because you can, obviously, have multiple distinct cinematics in the same level].
Other CineInterpolationPoint properties:
bSplineThroughPaths: If set to TRUE, the spline path is forced to go through each point you place; if set to FALSE, you'll get a smoother curve that uses the points as 'anchors'. Check the spline path view to see the difference. This setting takes effect on the first point in a path - i.e. the one with Position of 0 (zero).
bEndofPath: you must set the last point on the path to TRUE for this property.
RateModifier: Affects the path's speed at any point. Because it's a spline, these RateModifiers are smoothed out across neighboring points in the path... a value of .5 (half) will slow the 'camera' down to 1/2 its default speed in over that point.
GameSpeedModifier: this adjusts the speed of the game at that point. Be sure you bring it up back to 1 (default) by the end of the cinematic. This would be awesome for slo-mo shots that highlight kick-ass animation or somesuch - didn't get a chance to use it much for Rune. Note that this will also slow your cinematic down accordingly - if you've got a RateModifier of .5 on a point and a GameSpeedModifier of .5 as well, you'll effectively get a 'true' rate modifier of .25, since you've slowed the game down. Just fuck with these values and you'll get some cool effects.
InterpInstant: this is the only way to try and force 'cuts' - it tries to make the path cut immediately to this point if it's set to TRUE.
bSkipNextPath: self-explanatory, it takes the next point in the path sequence and 'skips' it, as if it hadn't been placed at all. Handy for 'removing' points from a path without having to go in and renumber all the later Positions accordingly.
ScreenFlashFog and Scale: this is how I got the screen to go red during that boat flick. I don't remember how these work off-hand, but I think Scale works on a zero to one percentage scale, where 1 is for no "flashfog" color, and 0 is full-color. You can also use this to fade in/out of black along a path.
FOVModifier: this sounds cool, but we never even touched it. See what it gets you, if anything...
Each CineInterpolationPoint has its own Event which will fire as soon as the camera hits it. This is handy for syncing stuff up. Note that if the cinematic is set to be skippable, the Event of the _last_ cineinterpolationpoint in the path will be fired if the player skips the cinematic. This is handy for cleanup stuff. For example, if you're spawning stuff in just for the cinematic and you want it all gotten rid of by the end of it, just put call a bunch of SER->DestroyObject's at the last point in the path that nuke all the muck you don't want lingering around afterward - that way, if the player skips it partway through, these'll still get called and you won't have any bugs/glitches. I'd just make the cinematic non-skippable for starters, then retrofit skippability later if you want it.
There are many techniques you can use for cinematics. I'd recommend starting out by using as few as possible. When you want a harsher 'slow down' in your cinematic than normal splining allows for, it's a useful trick to double-weight, or even triple-weight, your InterpolationPoints by adding a number at the same position. Then it's a matter of learning how to weild the RateModifier to get the desired effects. Also, if you want your path to suddenly "cut to" [via InterpInstant->TRUE] a new position that is rotated significantly from the last [e.g. it's facing 180 degrees in the opposite direction as the last], you'll want to double-weight your InterpolationPoints at that rotated location - make the first one InterpInstant->True, and leave the second new one as default ->FALSE., but that's a pretty rare scenario.
If you make the Event of the last point on your path call a new SpecialEventRune/->StartCinematicSmooth that starts a new, distinct cinematic, it will cut almost instantly. In this way you can daisy-chain different cinematics, but it isn't perfect - you will get a visible hitch; that's why SailingShip.run is all on a single path.
If you want to make a Beetle flight path, set the Beetle's InitialState to LoneFlyer, and its Event to the Tag of the points on an InterpolationPoint path (NOT a cineInterpolationPoint path). InterpolationPoints are much like the CineInterpPoints in function. When the Beetle's Tag is called, he'll take off and fly that path.
