Mark Cooke’s G-Mixer

While browsing a Japanese iPhone blog I ran across a video of Indicator Maniacs, an app I programmed recently for Mission-One. It was cool to see someone post about it. Check it out in motion below:

I downloaded the demo of inFAMOUS on the PS3 today and was pleasantly met by how well the player control was implemented. Mapping user input and intent onto what an in-game character does, particularly in third person games, has been a personal interest of mine for some time. It’s great to see a game doing it so well.

There are many challenges to overcome to result in a player control system that feels fun. In a third person game player control is the cross section between input handling, physics, animation, and camera systems. If one of those systems does the wrong thing at the wrong time it can completely break the players experience and drive the user directly to frustration. Everyone can tell when a player control system feels bad but it can be difficult to pinpoint the specific factors that make a control system feel good.

What the developer Sucker Punch really nailed is the recognition of player intent and the animation that supports the belivability of the character’s actions. For example, at one point I wanted to climb from ground level up to eleveted train tracks (part of the first mission in the demo). To the software my intent is fairly vague as I jumped at a grouping of concrete supports, street lamps, telephone poles, and fences. inFAMOUS does a good job of figuring what I wanted to do from all the available options. Not only is the character going where I want him to go, the character’s actions look purposeful. Basically, the hero looks like a hero.

It’s not surprising that it turned out well as the controls in earlier Sucker Punch games has been great too. The Sly Cooper series of games have a lot of the same high quality recognition of intent in their platforming actions.

While writing this post I downloaded a developer interview video on PSN and it touched on the controls quite a bit. One part I particularly enjoyed was seeing some of their debug information for animation and controls up on one of the developer’s monitor. Below are photos of the video:

This is displaying what looks like the animations that are being driven on the main character. Of course it is impossible to know exactly what is going on since I wasn’t on the development team but it looks like there are quite a few locomotion animations being simultaneously blended on the player. Slow and fast versions of the base locomotions (fairly typical), plus a lean factor, facial animation, and head look. I’m curious what the “balance” animation does.

On the bottom is what looks like performance and memory metrics. The colored bars are likely how much time the game is spending in various subsystems with each bar representing a thread. “M” and “V” are likely memory and video memory, respectively. I don’t know what “globs” are, perhaps it is Sucker Punch’s nomenclature for game entities.

In this screen we can see a bunch of debug spheres being rendered that appear to indicate where the hero character can grab onto various parts of the environment. I always like seeing images like this as it gives me some insight into how the control system was developed. Based on the size of the environments in the game it is unlikely that these points were authored by hand. More likely is that there was a tool pre-pass that determines where the player can attach onto that can then be cleaned up by a level designer by hand afterwards if necessary.

Hopefully someone on the development team will write up something for Game Developer, GamaSutra, GDC, or their own blog. I’d love to read more about how the recognition of player intent was balanced.