Click here to view the embedded video.

Although only containing a handful of updates from their 2010 version, this video shows that they owned pretty much every CG Trailer you got excited about in the last few years.

Click here to view the embedded video.

When we initially showed Mass Effect at E3 2006 I recall a handful of Square developers attending to evaluate the facial animation. While it looks like their production methods are somewhat dated due to the long development cycle, playing FFXIII shows the eventual result to be outstanding – presumably due to their dedicated engine for facial closeups and meticulous planning.

The google translation for the piece is especially bad, but so far I can gather:

Like Square Enix studio-offshoot Feelplus, cutscenes are divided into 4 categories depending on importance. A & B level cutscenes employ full keyframed facial animation (with lip-sync done individually for both Japanese and English versions). C & D level cutscenes just use procedurally-generated facial and lip-sync animation.

Similarly, the cutscene team is divided into four distinct teams that handle each progressive stage of creating a full cutscene. They are:

Motion Capture Group: Shooting and cleaning up motion-capture data.

Body Motion Team: Creature keyframe animation, and human motions that cannot be captured.

Facial Group: Facial acting and lip-sync.

Simulation Team: Hair and cloth simulations.

Cutscene shoots are meticulously planned ahead of time. Beyond storyboards, clean layout boards that contain descriptions of the actors, props and set layouts required for each scene are created.

Temporary voice-over was used on the set with full ADR done later. Interestingly, it appears that animatics were projected on the walls during the shoots to give the actors a better sense of their virtual counterparts and surroundings.

Within Motionbuilder, additional tools were created to easily allow editing and exporting of complex scenes via a check-box matrix of assets vs shots, seen at the lower-right of the image below – something I’ve had in mind for some time as the best solution for working on scenes that require a lengthy full export only very occasionally.

Character-wise, the highest resolution characters (Lightning and Snow) consist of up to 223 bones, covering the basic skeleton, auxiliary (corrective and simulation), facial and hair bones.

The keyframed facial animation was done via a traditional slider setup. The image below shows the numerous attributes, which must have become quite unwieldy and therefore given rise to the need for a dedicated team to specialise in this area.

For simulations, the wind level is initially set for each scene to provide the requisite amount of movement in the simulated assets.

Around 20 bones are used for hair, employing a spring system that dampens as a character’s inertia increases to prevent crashing with the head.

First, a little bit of background about where I’m coming from. I’ve been working on games now for nearly a decade in a variety of both in-game and cinematic roles, with the in-game side mostly focussing on player control, cameras and animation-system design relating to gameplay, whereas the cinematic part is about pure art and storytelling, getting information across to the player in as efficient a manner as possible.

At the time of the presentation, our team was wrapping up the final stages of production on cutscenes for Mass Effect 2 and here’s an image of the wall behind my desk.

This was a deliberately blurred picture (so as to not give away any spoilers) of our workload as it stood, with only the last few bugs remaining and each of those lines there representing anywhere between 1 and 7 individual cutscenes, many of which we now know post-release were well-received cinematic experiences. However, with such a heavy history of in-game animation design, I feel that with games like ours and the recently released Uncharted 2 among others, we’re coming to the limits of where we can go with pure cutscenes in our games.

Uncharted succeeded with its seamless transitions into and out of cutscenes, as well as the sheer high quality of the characters and acting, and ours with the logic behind them that decides which sequences (and how) to play depending on choices. As animators, we didn’t know whether your player-character was male or female, what their face looked like, or who you’d brought along with you on your team, not to mention the myriad choices that you can make throughout the game that will determine the outcome of particularly climactic scenes. After this point I can see cutscenes only limiting our progress in terms of developing storytelling in games, so I’m interested in exploring alternative methods that will allow us to truly develop stories for our medium rather than continually within the pre-established constraints of film – which are essentially where cutscenes lie.

The Problems With Cutscenes

When researching this topic, I began by initially trying to define exactly what a “cutscene” is. I’m sure when we’re all watching one we can tell that it’s a cutscene, but we have had so many variations of them over the years that it’s difficult to define them in a pure sense. The first and most natural idea that springs to mind tends to be “whenever the camera cuts”, but this is not the case as we often have no cuts, particularly during “designer cutscenes” whereby the camera simply transitions to a location to show the relationship between the player and the subject.

Next is to assume that player control is removed entirely, but as we’ll see later there have been many attempts to include some level of interactivity during cutscenes that doesn’t detract from them being cutscenes. The creation method is irrelevant – we have different terms in the industry such as Cinematic Cutscenes, Designer Cutscenes, Ingame and Pre-rendered, but in the end what really matters is how the player perceives the result, of which length is a sizeable factor.

Below is a great example of a cinematic sequence from Resident Evil 4 that follows all the “rules” of what we typically consider to be a cutscene, but because of its short duration the player doesn’t consider this a cutscene, and instead just another cinematic moment that contributes to the overall feeling of the game being a cinematic experience.

Click here to view the embedded video.

Defining The Problem

As such, a better approach is rather than to define what a cutscene is, instead to define the problem, so hopefully we can concentrate on simply attempting to overcome the issue rather than arbitrarily abolishing cutscenes themselves which has been done in the past to greater and lesser degrees of success.

Control and choice is restricted, if not removed entirely.

One second the player is running around, making choices and personally involved in many aspects of how the story or adventure is progressing, then the next they are force-fed exactly what we as developers want them to see and experience. This is fundamentally against the nature of our medium, and greatly restricts their experience for the duration of the cutscene back to the levels of the older medium of film.

Cutscenes make a clear division between the gameplay and the story.

The visual difference between cameras (and often character fidelity) in gameplay and those for cinematic cutscenes negatively reinforces the fact that most of gameplay involves little to no story progression at all.

Cutscenes are opt-out.

Once a cutscene is triggered, often without the player’s consent or choosing, his or her only option is to exit the cutscene. This brings with it issues of missing important information after the point of exit, and more importantly highlights the fact that we have a major problem here. If we have a design element in our medium that consistently requires we add the option to skip it entirely, then surely there is something fundamentally flawed with some aspect of that element?

This brings me to the definition that cutscenes are essentially “Imposed Cinematography”, whereby we as developers wish to impose narrative or progression information required to continue, or to ensure that the player experiences a part of the game exactly as we wish them to. This is the heart of the conflict between developer and player where, unlike other older mediums, we perform best when we play to our strengths and require participation from the player rather than purely imposing our creative will upon them.

Click here to view the embedded video.

This is the launch trailer, and I count some 75% of the shots here were done by the Montreal Cinematics team. So far the reviews have been overwhelmingly positive, but I still nervously await the ultimate litmus test – the ever-critical girlfriend…

Cutscenes are a divisive subject amongst videogame developers. We rely on them as a relatively production-safe solution for imparting exposition and story progression, to give the player objective location information, and to reward achievement and successes like level completion. However, they cut more than just the camera. The flow, immersion, and most of all, interactivity uniquely enjoyed by the medium of videogames all take a hit for their (often unskippable) duration.

In their defense however, attempts to forego their inclusion can result in a weaker visual presentation and take us further away from an emotional connection with characters and story. Additionally, a quick scan of screenshots previewing upcoming games illustrates our growing reluctance as an industry to present titles from the in-game perspective, where cameras are rightly skewed towards gameplay.

This talk explores various techniques used by games over the years to create a cinematic look outside of the traditional reliance on cutscenes, with the pros and cons of each, finishing with suggestions on how these might be combined in the future to offer cinematic moments while keeping the player in the game.

Takeaway: Techniques alternative to cutscenes for imparting interactive story and cinematic moments in games.

Intended Audience: Game Designers, Writers, Animators and those involved in storytelling.

Should you be attending the conference please stop by at 2.45 on Monday afternoon. If at least one of my observations is taken onboard then we might just reduce our reliance on cutscenes for storytelling.

Square Enix: The Technology of FINAL FANTASY

Taku Murata – General Manager, Technical Research Division

Traditionally, a new platform was created for each title, with the game first made in Japanese and translations following much later. This looks set to change with the latest upcoming releases which will be very exciting to many western fans, and the target platforms (for the engine) are PS3, PC and XBOX360.

Murata’s history reads like something of a chronology of technological breakthroughs in Japanese game development, with much of his work driven by animation – in particular facial animation. Of interest most of all was the admission that several of the driving forces for this new engine centred on displaying characters’ faces to a very high fidelity in close-up.

1997 – Final Fantasy Tactics: First time using real-time previewing on the console, convincing Murata of the power of this approach. The game was edited on PS1 in realtime, driven by the artists’ requests.

2000 – Vagrant Story: Used a unified tool to create cutscenes, preview textures and visual effects. Apart from the opening FMV, every cinematic was in-game and featured skeleton/bone animation for the first time. One requirement was that the team had to preview facial texture animations to ensure they looked good without anti-aliasing. Murata spoke at length about what he called “peak-points”, which are presumably normals. Apparently they had to change the peak-points relative to the camera to maintain the facial integrity. Lots of post-effect and field-of-view corrections, such as a fish-eye lens filter, were employed in order to promote a wide range of facial expressions.

2004 – Data Standardisation: Established a common 3D data format. Within the company there was a big debate over whether to use COLLADA, FBX or a proprietary file format, with each team previously using a different format. They eventually decided on their own proprietary data format, but the integration process wasn’t easy, especially when convincing certain entrenched teams.

2005 – Tech Division Established: Murata’s team was formally created with the objective of establishing a company-wide technology.

2006 – Final Fantasy XII: Team sizes by this time were incomparable to previous projects and as such brought with them large volumes of assets required to be created by staff with diverse skill levels. To aid this, Murata’s team created separate tool sets for different needs and skill levels.

2007 – Crystal Tools: The company-wide technology was finally rolled out. Previously named the “White Engine” , the Crystal Tools platform is the result of Murata’s team’s work. The essence of the Crystal Tools was described as thus:

• Must support extensive use of character close-ups.
• Focus on stylised facial expressions designed to promote the anime style.
• Must allow detailed control of characters.
• Specialises in physics, visual effects, post-effects and Graphical User Interface.
• Must support a large team, with a detailed division of work.
• Contains seperate tools for different functions.

With an extensive use of GUI to accommodate veterans and novices alike and focusing on ease of use, the Crystal Tools are currently being used for the production of Final Fantasy XIII, Final Fantasy XIII Versus and unannounced next-gen MMORPG. Separate teams for separate tools allowed v1.0 to be created in a year, though as is often the case in engine development they did not employ a technical writer so the documentation suffered. This is an area that game developers are slowly coming around to, where complex tools and system are created on an almost daily basis but oftentimes their power is not realised due to bad or lacking documentation.

Apparently, after one post-session questioner inquired, Murata admitted that Square Enix cannot currently license tools due to documentation, but possibly in the future – something very interesting indeed should the chance to work with their tools arise. Of all the tools mentioned, (Character Viewer, Effects Editor, Cutscene Editor, Layout Tool and Sound Maker), I fortunately managed to find screens online of the two most interesting to videogame animators.

Character Viewer: The Character Viewer is only for previewing of textures and animation and exists on PC only, with modeling and animation still created in Maya or XSI. It clearly displays a hierarchy view though, hinting towards additional character set-up that could be performed and maintained from within this external viewer.

Cutscene Editor: Bearing a resemblance to Unreal Engine 3′s “Matinee”, the Cutscene Editor offers timeline control over cinematography, visual effects and audio all in a single editor. The multi-screen view shows that this is an editor and not simply a tool in which to re-construct pre-exported cameras and cutscene assets, with an asset browser and animation curves clearly visible towards the lower right.