Cutscenes in Unreal Tournament

(or, How To Be All Like Martin Scorsese And Stuff)

Cort Stratton (Mister Programmer, Sir)

The Coyote210 project introduces support for non-interactive, scripted in-game "cutscenes" into Unreal Tournament. This capability is vital when applying UT to any sort of theater context - without cutscenes, UT is a very action-oriented engine that doesn't lend itself very well to exposition or storytelling. Cutscene support gives content creators many new abilities:

Revealing backstory & plot points
Establishing character
Providing "rewards" when characters complete certain tasks

Download UMS (cutscene only version) here!!

We're using a modified version of the Unreal Movie Studio system (UMS) for our cutscene support (many thanks to Hugh Macdonald and Stephen Deaver for writing UMS in the first place, and helping me figure out what modifications would be necessary). Note that since we DID modify UMS, downloading a new version from their web site just won't cut the mustard. UMS is designed to let users create entire feature-length scripted movies within the Unreal engine (a fascinating sub-culture called "machinima" has sprung up surrounding this very pursuit -- it's worth investigating). By default, UMS movies are entirely non-interactive -- a level is either playable, or it's a movie. Our challenge was therefore to modify UMS to let you embed cutscenes into an otherwise playable UT level, and trigger them when the player accomplishes certain actions or enters certain areas.

Solving this problem involved addressing three sub-challenges:

Cutting the camera away from the player's view and into the the cutscene.
Immobilizing and hiding the player, so they don't interfere with the cutscene by running around in the middle of the action (and so they don't get themselves into trouble while they can't see what they're doing!)
Returning the camera view to the player's viewpoint at the end of the cutscene.

All three involved only minor changes to the code. Problem #1 is addressed in UMSCamera.UMSCamera class, in the "ExecuteCutTo" function. Problem #3 is essntially the same fix as problem #1, only in reverse; it's found in UMS1_6.Director, in the BackToMyTrailer() function. Problem #2 was the most difficult conceptually, but fairly simple to implement in the end -- the player is simply put into a new state called "Gimped" and his bHidden flag is set to true for the duration of the cutscene. These changes are found in CoyotePlayer (our descendant of the PlayerPawn class).

The easiest way to trigger a cutscene is through the UMS1_6.UMSTriggers class. Add a UMSTriggers object to your world, set its TargetDirector property to the Tag of the Director you wish to trigger, and you're done. The cutscene will trigger when the player steps within the CollisionRadius of the UMSTriggers object (and it will only trigger once for each trigger).

That's all I have to say about cutscenes. You still have many many questions, I'm sure, like how to actually script the cutscenes! Picky, picky...

Truth is, the UMS website has an excellent Tutorials section that'll teach you everything you need to know about the mechanics of UMS scripting.

Any questions, let me know.

Things to be aware of/future work:

The current incarnation of the cutscene system mostly plays nicely with Spectators: the Spectator sees the cutscene, same as the player does. And when the cutscene finishes, the Spectator goes back into Spectator mode. However, for some reason, camera motion is very very choppy from a Spectator's point of view (even though character animations are as smooth as always). I'm not sure why this is -- I have my theories, something about the way smooth cameras confuse the Spectator system's movement prediction logic...but the point is, it's an unsolved problem for future generations to match wits with.
Much of the UMS code is based on the assumption that there's only one PlayerPawn in the level at a time. It would be wise not to violate this assumption.
When I first started making my modifications to UMS, the authors warned me that I should put all my changes in a separate module, for easier integration back into the main source tree, and less pain when new versions came out. Well, I tried my best, but I found that in order to make the modifications I had to make, confining my additions to a separate module would have been well-nigh impossible. I did not heed their warnings, and now we're all going to suffer. When a new version of UMS is released and we have to go back and hack it again to support cutscenes in interactive levels, mine will be the first eyes to well with tears. Somebody, SOMEBODY should get this right!