PostedSun Dec 19, 2004 3:58 am
Allow me to be the bad guy for a second and pee all over this parade. Since what you're describing is exactly what I do for a living, please understand that I'm not shooting you down, merely explaining things a bit.
While I love the ideas of different walks, I'll explain why you'll almost probably never see them in SWG:
First, there's the problem of blending. In the motion system that is SWG (or any game for that matter), there's not just a walk. There's the walk, a jog, and typically a run.
Each one of those animations has a cycle (say 24 frames for a full out run and maybe 60 frames for a walk), and a set translation rate for each animation (how fast they move through space when the person is walking/jogging/etc.)
Now, the walk has to blend into the jog, and the jog has to blend into the run. Typically, if the animator knows what they're doing, they can just supply three animations and their part of the deal is done. Then, the scripter has to take those three animations and try and make the code understand that when the left foot is down on the ground on frame 28 of the walk cycle, that matches up when the left foot is down on the ground at frame 8 of the sprint cycle. Unfortunately, the values aren't scaleable, so you pretty much have to hand tag the code to match where you need it to and hope that the system can interpolate the difference.
But we're not done yet. Since in SWG you can "level up" in your walking ability (Exploration I-IV), now the walk, jog, and burst-run values are also scaleable on top of the fact that they all have to blend together. This hopefully isn't as big of an issue as getting the blend positions correct, since you can just have the code scale all the values together proportionately and it should all work.
However, now you've got not only three animations with scripts that accompany them, but you now have another file called a table which tells the code where the animations live, and which animation to use when the proper keyboard input is given. And we haven't even started talking about the code that does the blending itself.
That's a lot of code to debug, and once it gets done right, it's usually left the hell alone. Really robust engines can plan for this sort of multiple walks thing, and make sure the code is designed to implement it from the getgo. However, I don't think SWG was (or they would have added more walks by now), so now it's a matter of doing band-aid and rubber-band code to make it work, which always creates more bugs, and holy god, what kind of a nightmare have we created for basically no "real" content is what the devs will be saying.
Now take that process and multiply it by the number of walks you want to see implemented.
Also, walks that have an asymetrical cycle to them (an injured walk, or a hobble, for instance, where the footfall cadence rhythm doesn't neatly fall into a marching-style beat) will take that original walk/jog/run codebase up there I talked about and throw a fairly decent sized monkey-wrench into it.
Of course, your game engine mileage may vary, but in my experience, just adding a new "system" of movement (the low-defensive stance in Ballers, for instance) wound up taking us like an additional 3 weeks of development time.
Most devs aren't going to bite on this unless they can find a way to just "drop" the code in and have it work, and like I said, I don't think SWG is set up for that.
Again, sorry to sound like a parade rainer, but I'm just playing devil's advocate for the devs here.
While I love the ideas of different walks, I'll explain why you'll almost probably never see them in SWG:
First, there's the problem of blending. In the motion system that is SWG (or any game for that matter), there's not just a walk. There's the walk, a jog, and typically a run.
Each one of those animations has a cycle (say 24 frames for a full out run and maybe 60 frames for a walk), and a set translation rate for each animation (how fast they move through space when the person is walking/jogging/etc.)
Now, the walk has to blend into the jog, and the jog has to blend into the run. Typically, if the animator knows what they're doing, they can just supply three animations and their part of the deal is done. Then, the scripter has to take those three animations and try and make the code understand that when the left foot is down on the ground on frame 28 of the walk cycle, that matches up when the left foot is down on the ground at frame 8 of the sprint cycle. Unfortunately, the values aren't scaleable, so you pretty much have to hand tag the code to match where you need it to and hope that the system can interpolate the difference.
But we're not done yet. Since in SWG you can "level up" in your walking ability (Exploration I-IV), now the walk, jog, and burst-run values are also scaleable on top of the fact that they all have to blend together. This hopefully isn't as big of an issue as getting the blend positions correct, since you can just have the code scale all the values together proportionately and it should all work.
However, now you've got not only three animations with scripts that accompany them, but you now have another file called a table which tells the code where the animations live, and which animation to use when the proper keyboard input is given. And we haven't even started talking about the code that does the blending itself.
That's a lot of code to debug, and once it gets done right, it's usually left the hell alone. Really robust engines can plan for this sort of multiple walks thing, and make sure the code is designed to implement it from the getgo. However, I don't think SWG was (or they would have added more walks by now), so now it's a matter of doing band-aid and rubber-band code to make it work, which always creates more bugs, and holy god, what kind of a nightmare have we created for basically no "real" content is what the devs will be saying.
Now take that process and multiply it by the number of walks you want to see implemented.
Also, walks that have an asymetrical cycle to them (an injured walk, or a hobble, for instance, where the footfall cadence rhythm doesn't neatly fall into a marching-style beat) will take that original walk/jog/run codebase up there I talked about and throw a fairly decent sized monkey-wrench into it.
Of course, your game engine mileage may vary, but in my experience, just adding a new "system" of movement (the low-defensive stance in Ballers, for instance) wound up taking us like an additional 3 weeks of development time.
Most devs aren't going to bite on this unless they can find a way to just "drop" the code in and have it work, and like I said, I don't think SWG is set up for that.
Again, sorry to sound like a parade rainer, but I'm just playing devil's advocate for the devs here.
