Tool creator Havok has been at the forefront of physics engine development for some time now (as seen in games like Half-Life 2, Dead Rising, MotorStorm), and has recently has branched out to include products like Havok FX for special effects and HydraCore for multi-threaded optimizationan. They've also released animation SDK and tool (Behavior) which, as demonstrated to Gamasutra, uses intelligent and rather intuitive scripting and naming trees to create a very clean interface for animators, and also has a very simple system for blends.

On the occasion of this tool’s unveiling, we spoke with Jeff Yates, director of product management for Havok, and discussed the company’s plans for the future. Yates also provided a host of information useful for both developers and consumers interested in what goes on in the bowels of the industry, including a comparison of the respective strengths of the current crop of consoles, and a breakdown of a number of points of popular confusion, such as the necessity of a hard drive for data storage, or the difficulty of porting games from the 360 to the PS3, from the technical side of the game industry.

Gamasutra: How long has Havok been dealing with animation?

Jeff Yates: As a company on the SDK side, a good two and a half years. We launched our SDK at the end of 2004, and a lot of that work revolved around really good compression of the animation. What we do is to maximize and sample every key frame, then we compress it down and play it back exactly like you just saw. That's been going on for about two years, and a full half of our sales now include animations. It's a really good attach rate. In terms of this higher-level, broader view of character animation, it's probably been about a year and a half to two years we've been working on this. Some of us have been working with other companies too.

GS: How far do you think you're going to go with what Havok covers? It seems like it's continually expanding toward being a full engine competitor.

JY: We obviously like to grow, and our customers generally want us to grow and stay healthy too, as long as we don't take our eye off the ball with physics. What will make us unique is that we'll probably try to do only one or two components at a time, and we'll make those the best of their class. We'll really try to make those true components, in the programmer's sense of the word.

We could take a path where we say it's all one black box and we're going to grow it constantly, but we're very careful to make sure you can say, "I want this one or that one, and not all of it at the same time." A good amount of effort goes into making these things first-class SDK components, and I think that's the way we'll stay. I don't see us becoming a monolithic solution provider. I think we'll provide related components that know about each other, and will integrate well out of the box.

The Havok Behavior Tool

GS: Will it be possible in the future for scripted animations (such as idle animations) to feature slight variations? Right now they’re generally looped canned animations.

JY: Right now I think there are a lot of clever things you can do with blends. There are a couple of approaches to that. The extreme one is to have eight different ways the character might idle, then support random selection, so you can pick a different one every time and get randomization that way. That's a bit brute force, but surprisingly effective, because you know exactly how long it will take, and how much memory it will take in advance. Another approach that is a little less explicit is to have extreme ranges of motion, then blending those and having a variable that modulates. For example, if the AI is tired, maybe his arms will come down a little bit and then raise up. We try to enable that by letting you put variables on these blends.

I think full procedural stuff is even cooler. It's most doable for the upper body. Full procedural locomotion for the base of the body and for momentum and stuff like that is just now starting to come out into the open.

GS: Is that going to be difficult to blend into other animations?

JY: Yeah. I tend to sometimes think about procedural textures when I think about this stuff. They held so much promise, and then people saw that they had like twenty variables that all had to be tuned and simulated. It really depends. I think that almost anything that you look at - either through runtime or 3D authoring - the algorithms you choose have to be very predictable. To be honest, we haven't really tackled that part of the equation yet. But I think anyone can plug it in.

GS: It seems like that's the direction that things might want to go in the future.

JY: I think so, yeah. As long as the artists like it and can control it - that's key.

GS: It seems like when characters go into ragdoll state in games like Gears of War, they go completely limp. Is it possible to give it more rigidity?

JY: Oh yeah. You can blend the amount of keyframe animation - say for example if the keyframe pose says, "I want to be here at a particular time," but the physics say "You're dead over here," we can blend and have a certain stiffness between the two, and that can be animated. A lot of times you'll see tech demos where a ragdoll character will hit the ground and he'll be stiff for a second, and then he'll go totally limp. There's that kind of death pose that he holds before he goes down. That's totally possible.

Epic's Gears of War

The way we do it in this tool is to blend between a certain amount of physics and a certain amount of keyframe animation. We think that makes up so much territory. It's certainly not be-all-end-all, but it certainly makes ragdoll seem so much more alive. The ragdoll can serve a lot of brief, high-value purposes. You can take a hit, then go a little bit to ragdoll and then recover, and never go to the ground. You get a lot more variability in response that way. The Ubisoft talk at GDC had some great examples of that.

GS: What do you think of your competition, physics-wise? It seems like AGEIA may be in some danger, given that they were tied to hardware acceleration.

JY: In terms of software and what the software is able to do, we feel confident that Havok physics - especially in terms of functionality and platform support - is comfortably in the lead. Through the last 18-24 months, we've stayed focused, and have said, "We will make it cross-platform, we'll make it as fast as it will go, and we will support you." I think that when you're a hardware company, software is a means to an end. It's very difficult for a hardware company to persist and do all-around solutions. Apple is one of the few exceptions. I think that causes a bit of challenge.

There's certain aspects of what they're working on from a software technology standpoint that are very interesting, but I think they're pursuing it because it's what will sell the hardware. So we'll see. We certainly don't want to be arrogant or take our eye off the ball. We want to stay focused on what our customers are asking us to do. That's focused on cross-platform, console-first kind of stuff.

GS: What do you think of companies that use Havok as a selling point and then don't use it very well? I've seen a few examples of that.

JY: It really falls back to us, to work with those customers as much as we can. At the end of the day, though, they have constraints too. Sometimes they may come to it very late in the development process. It's always very tough for us to see a game come out that either isn't using it or isn't using it well, because it's still a tricky thing to get things integrated nicely. So it's a bit frustrating, but it's our problem too. We focus on helping our customers. That's a part of our product. If we don't have great integration, then that reflects badly on us.

GS: Do you find people coming to you late in a project when they have failed to create proper physics?

JY: Sometimes! If a team has worked with us on more than one title, we get a good thing going where we get in early and have an opportunity to suggest changes. For people we haven't worked with before, though, there's a tendency for them to go silent on us. Then they come back and ask for help, and it ends up being really intense for everybody. We try not to let that happen, but it does happen sometimes.

GS: How much of what you do in the future comes from those kind of calls where people ask you what is possible currently?

JY: A lot. Understandably, people want to know what is possible, and I think the tricky part for any software company is when somebody says something like, "I want to have fluids running through the hall and seeping into the carpet -- go build that!" Algorithmically, you can go do that kind of thing, but what you really want to understand is how much of your compute cycle you're willing to dedicate to that. If I can't do it in under two milliseconds, for example, maybe you don't want it. We try to ask customers whenever they have a feature request whether it's important to the gameplay and what our target is for performance and memory usage. In general, we try to sort it all out and pay attention to what our paying customers and potential paying customers are asking us to do.

GS: How much are the next-gen consoles changing that memory usage?

JY: It's changing for sure. I think the PS3 has great potential, but it's a very different kind of architecture. If people build their games with an understanding of what their challenges are going to be with porting between consoles, we can do a lot. In some cases, though, we're seeing people start with a 360 SKU and defer thinking about the PS3 port later. That can have some pretty dire consequences for how you process your art. We try to advise people that if they're thinking about moving to PS3 eventually, that they need to talk to us at the start so we can get things sorted out. I think that's going to be a very big challenge for everybody for awhile, because this idea of many, many cores with smaller local memories will present a lot of challenges in many different directions.

GS: At this stage, I've heard some people say that when starting with an Xbox 360 version, they have trouble getting the PS3 version to look as good later on. It's interesting, because the PS3 is potentially more powerful.

JY: I think a lot of it has to do with slicing and dicing the task and moving it to each of the smaller processors. Those processors are really powerful, but you have to plan for it. We've spent the last two years re-architecturing our software so that you can have one interface that, when used appropriately, can get maximum use out of the SPUs. You do need to plan for that, and if you have one massive world presented as one object, it's a little more challenging. It takes preparation.

GS: Do you have any existing support to split things across those SPUs?

JY: Yes. We can take that stuff and automatically split it. But as with anything, there are pathological cases where if everything is piled all together all in one place at the same time, you can get performance spikes. Most of the gameplay situations we see feature lots of activity spread out over a variety of quadrants. Those situations efficiently use up the cycles that are there.

GS: It's interesting to see how things are progressing, since people aren't even maximizing the usage of the Xbox 360's cores yet.

JY: Yeah, and I'm hoping that just means that there will be more cycles for us once people start plugging stuff in the right way. There might be lots of cycles we could suck up, which would be cool.

GS: What troubles specifically have people had with moving from 360 to PS3?

JY: There are certain things that are proprietary and need to be walked around carefully, but I would say that you don't have to go back, for example, and redo the art, but you may need to re-export or reprocess the art to chunk it up differently. For our stuff, it may be to store the right amount of information locally, so that when information is passed around the system, it has everything it needs to do its job.

GS: I suppose it's because you can use bigger chunks on 360, whereas on PS3, you have to chop it up a lot more?

JY: Yeah, you have a more unified memory architecture on 360 and PC in general. I think that there are merits to both, though. If you can move the world over to many processors and structure the game so that you can dice stuff up, there's a lot of leading-edge technology out there that seems to be going in that direction. That might just be one of those paradigm shifts that the software development component of the game industry goes through over the next five or ten years.

GS: How important do you find hard drive use on consoles?

JY: I personally haven't heard of us needing that specifically. I would imagine, though, that with worlds being very physical and in need of persistent terrain, that certainly will require saving on a lot more estate than has been required before. That's got to be put somewhere, and I suspect that a hard disk is the only practical place to do it, unless it's an online game saved on servers. That's one of the next chapters for physics - being able to capture a simulated world and being able to come back to it in the state you left it.

GS: It’s going to be really sad when things become really solid like that - I enjoy breaking games.

JY: Well, I think that the more people who aspire from a development standpoint for complexity, the more ways there will be to break stuff, especially with procedural animations. Everybody wants emergent results, but when you get that, you actually have a very hard time testing it. It's a very serious practicality issue that everybody is facing. Ragdoll and physics are the same way. You can stack things up and get out of a game's world! It's pretty wild. Somebody should design a game based entirely around that premise.