The quality of any Machinima project is dependent on two factors: the amount of time and effort invested in it, and the quality and ease-of-use of the tools used to create it. I'll be coming back to the "time and effort" point later -- for now, let's look at tool designs. Traditionally, there are three basic models of tool design for real-time cinematics in game engines. All of them have their advantages and disadvantages, so let's look at them one by one, in chronological order.

1. Demo editing. This technology came first -- it was using these techniques that the first hobbyists created the original "Quake Movies" which first showed the potential of 3D engines to create films. This technique, growing out of the hacker's ethos of the original Quake community, uses special tools to edit, cut, and splice in-game recordings of earlier games -- originally Quake deathmatches -- but with some design changes these recordings can easily be the equivalent of a studio-filmed rush from which a finished film can be produced.

These techniques have rarely been used within the game production community, but groups such as Cnet's Gamecenter and the BBC are now using similar technologies to televise games like Quake 3: Arena and Unreal Tournament.

This technology has a lot of advantages:

• Films are very quick to produce, as it's far faster to give a human a complicated series of instructions on his role than to script those instructions for a machine.

 

• A well-organized shoot can exhibit much of the spontaneity that enlivens "real" filming (a way in which this technique is unique in the world of animation).

 

• Because the "demo editor" used can easily be tied in to send the game engine information allowing real-time previewing of edits, it allows the user to receive instant WYSIWYG feedback on their editing.

However, it also has a number of disadvantages:

• It's very hard to get any sort of precision in the initial shoot. While a lot of this imprecision can be cleaned up by editing the demo produced, it's often the case that this takes substantially more time than simply creating the shot from scratch using other techniques.

 

• Because of the "live filming" aspect, the actual shoots require a large group of "actors" and a LAN, as well as a lot of coordination of that group.

 

• Once "filming" is complete, if major changes to the action are needed you'll either have to reconvene your actors or perform a lot of complex scene creation and tidying. Frequently neither are particularly viable options.

 

• From the point of view of the tool designer, this is a complex project, requiring a new tool to be built with a lot of versatile editing capabilities.

Overall, demo editing is a very versatile and usable technique (particularly for scenes requiring a lot of complex, intelligent movement -- it's particularly useful for battle scenes). However, on its own it is very limited, particularly for scenes with complex animation or very precise synchronization to other factors in the film.

2. In-map scripting. This was the next technique to develop, and so far has been the most widely used, appearing in games from Half-Life to Unreal to Soldier of Fortune. Here, cutscenes are entirely scripted within the map editor used for level design, usually using the same scripting technologies used within the game to produce in-game scripted actions.

Obviously, from the tool-design point of view, this is a very simple and direct approach, requiring little additional design -- all that's generally needed is a "camera" object within the game's structure, with some movement options, controlled from in-game triggers or scripting engines.

Advantages:

• Initial shot and sequence setup is usually fairly swift, and it is possible to create very precisely controlled action sequences within the engine.

 

• Because audio can be scripted within the engine alongside the action, audio synchronization to the on-screen action is relatively simple.

 

• As mentioned above, tool design time is minimized.

 

• All cinematic creation (except voice acting) can be done by one person.
• Editing character positions and actions after initial creation is very simple.

Disadvantages:

• Unlike the demo editing approach described above, this technique does not work on a WYSIWYG basis. In order to see the effects of a change in a cutscene, the creator must recompile the map on which he or she is working, and then run that map from within the engine. The lack of instant feedback this produces is definitely detrimental to the quality of films edited using this process.

 

• Likewise, compile and run times for maps using this technique may well discourage the creator from trying different techniques or editing the work more than the bare minimum. At the very least, the compile times will eat into the time available in which to work on the cutscenes.

 

• In general, scenes created using this technique are edited linearly, rather than nonlinearly. Translated from film terminology, this means that the order of shots (and frequently their duration) acts like a stack of shots rather than a linked series: in order to swap the positions of two shots, or even change the duration of a shot, it will frequently be necessary to re-create large portions of the sequence. This isn't always the case (particularly if scenes are very carefully created with an eye towards a nonlinear approach), but the interplay of scripted movement and scripted camerawork certainly tends toward this problem.

 

• The time taken to create a shot increases dramatically if that shot involves complex interaction between multiple characters. Any large fight sequence, for example, will generally be extremely difficult to create convincingly using this system.
• The film will only be as good as its scripting language. If it is difficult to create an effect which is needed for the film, then that shot will be compromised. Of course, it's possible to rewrite or add parts to the scripting system to accommodate new requirements, but this will take time on the part of both the programmer and the cinematographer.

Overall, despite its prevalence, the in-map scripting technique does not work particularly well, and may well be responsible for a lot of the quality issues within older cutscenes. Its lack of a decent editing facility and its reliance on recompilation of the sets on which the scene is taking place are certainly its biggest flaws, and can seriously compromise the quality of films created purely using this technique.

It's worth noting that many of this technology's problems can be ameliorated by combining it with another method of film creation, such as demo "re-camming" or even conventional video editing software such as Premiere. This may be the simplest approach to take if tool creation time is a major concern.

3. Independent scripting. This third technique has been employed in several different forms in a number of recent games. In general, independent scripting uses a combination of in-engine tool work and text scripting to create its films: some games, such as Vampire: the Masquerade -- Redemption, simply allow the user to select camera angles and actor positions via an in-game engine tool and then script the action within the scene entirely in a text interface (with Java scripting, in Vampire's case). Other games allow the user to set up and preview entire shots within the cutscene editing tool, including character movement. However, they still have an underlying script for the scene to follow, with the in-game tool acting as a "helper" to create this script.

Vampire: the Masquerade -- Redemption allows users to select camera angles and actor positions via an in-game engine tool.

In many ways, this is not a single tool technology, but a base point from which to build a tool set. However, there are certain common features (the presence of a script, rather than a recording of action within the game, and the reliance on a separate file rather than information within a map) that make this approach unique.

It's safe to say that this technique has a number of advantages:

• WYSIWYG editing, at least to some degree. Exactly how far this capability goes is up to the designers of the tool set, but it's certainly relatively easy to enable anything up to full WYSIWYG capability.

 

• Instant feedback. The cinematic creator can see how changes affect the film instantly -- and, unlike the other tool systems mentioned above, the creator can easily make major changes to anything in the film, including character movement.

 

• All cinematic creation can be performed by a single person.

As with the potential advantages of this technique, many of its disadvantages depend on the design of the helper tools used with it. However, some disadvantages are constant.

• While it's possible to set up a nonlinear editing environment within this system, the scripted nature of the films created predispose it towards linear editing only.

 

• In order to create a useful tool, considerable programmer time and effort will have to be invested. As with any content creation utility, there is frequently a lot more work that needs to be done to create a usable tool than is initially apparent.

 

• Similar to the other approaches, as a scripting tool, the more complex a scene, and the more characters involved, the more complex the scripting becomes. Battle scenes are frequently particularly difficult, as I mentioned above.

The Ideal Tool?

None of these approaches is ideal -- in fact, on their own they all have gaping flaws, and flaws that can't be easily solved within a single tool. However, that's more than just a design challenge: that's a signal that there's something drastically wrong with the "single tool" approach. A quick look at the credits for any Hollywood blockbuster will tell you that film work isn't a single, homogenous whole. By the same reasoning, then, neither is Machinima production.

Let's consider again the basis of "real film" work, in which there are several main stages of production, apart from content creation (audio recording, set design, animation, and so on): pre-production, production and post-production.

In pre-production, the final draft of your script is analyzed by the director of the cutscenes and broken down into a shooting script and storyboards. The shooting script allows the director to break down the script textually to help the him or her and the team begin creating storyboards. Storyboards are simple illustrations that assist the director visually of the cutscenes prior to the actual production. During the storyboarding process, the director and team can start to see what elements will be needed in production (as well as which game assets can be repurposed for the cutscenes). While this preliminary effort may seem like a lot of work, it is invaluable throughout the rest of the cutscene (if not the entire game's) production.

In production, individual shots are filmed. There's no effort just to capture the action needed here, or to shoot the shots in any kind of cinematic order -- that comes later. In Machinima terms, this is where individual character movement is scripted, in-scene audio is synched into the action (characters talking, feet scuffing on floorboards, and other such "real-world" effects), and camera positions are set up. This would also be where any live demo filming is done, and the subsequent shots tidied up.

The important point here is that the target end product for this stage is just individual, uncut shots from the film. This part of the process requires that its tools be very flexible, and focused on creating single sequences: complex movement creation tools; flexibility in camera movement, focus, and position; and precise timing of events are all important here.

Then, in post-production, these shots are edited together to form a whole, and additional audio (mostly background music, in the case of Machinima) is added over the top of the finished, edited piece. Editing is a very different discipline from camerawork, and demands very different skills and tools: the ability to chop and change shots freely about in the shot sequence of the film and to edit their lengths and transition between them, is important here. Most utilities commonly thought of as "film packages" (such as Adobe Premiere) are actually editing tools.

In development work on Lithtech Film Producer, we very quickly moved to a paradigm based on this breakdown of the film-creation process. The ability to break the work down in this fashion is probably the most important missing element in many Machinima creation packages today. By trying to do both jobs at once, any tool ends up lacking on one or the other side, hampering its users ability to create quality films.

Obviously, other elements of the package are also important: as a visual medium, it's vital that any Machinima package have WYSIWYG capability. The potential of live filming for certain scenes is huge, and any tool designer should consider including some form of live filming option within the Machinima tool set. Lastly, if your game does have scripting capabilities, then incorporating them into the pre-production section of the tool set in some form is also an excellent idea.