New Walks for SWG

[X'an Shin]

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.

[X'an Shin]

Man, can I kill a thread or what?

[MrDooo]

DOWN WITH XAN SHIN!!! GIVE US FUNKY WALKS!!!

[Jabe Adaks]

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.

Yeah, but I want them anyway.

Jabe

[Ekade]

Man, can I kill a thread or what?

I read the first two paragraphs. I have to say I really enjoyed them. I look forward to going back and reading the rest some day.

[Isleh]

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 .....

*ponders the Yoda response, decides on Vader*

*Takes her FWG5 and shoots the devil's advocate in the leg and watches him hobble away*

The Devs can start by a motion capture of that

*queue subdued track of emperor's march*

~

Just kidding!

Sooooo....

Why not have the /walk command change this reference table that you mentioned?

New walk, drop in a new table and the animations?

These new walks don't really require a new Jog or Run animation and blending issues that you mentioned could be handled by just running the animation that blends the standard walk to the new walk and vice-versa.

Terrain Negation issue? Can be handled either 2 ways. While using any other /walk besides the standard, it's negated. Very good RP value for '/walk wounded' and the 'I pwn3d u' crowd would most likley not even care or even know about the /walk command so it would be a minor issue at best ( this is my forst choice actually and SOE's respone could be simply "By design to make this feature feasable" ). Or, after X seconds where Terrain Negation would be used, they transition to the standard walk.

I'm looking for solutions, while not the best, they are workable and I'm not a game developer. Nothing against you X'an *hug*, but maybe that's the problem with SWG. To many devil's advocates in SOE.

[Weyune]

I think if enough people ask for it it will happen. They have now started to ask on the very SOE forums what people want. They have asked what droid fnctions people would like to see added, and have gotten tons of responses. And lets not forget that they asked people what things they would like to see craftable. And later, Low and behold we can get some new kinds of furniture and other equipment like bacta tanks and radar screens that we can put into houses.