[SUGGESTION] Transition Views

[subspark]

Would it be possible for a future version of AGS to support built in transition views?
I noticed that the walking views MUST have one of the idle (standing) sprites in frame 1 for the animation to work properly in-game. While this seems a little 'backwards', Chris has suggested that theres not much gain to be had by changing the way this works.

(However if transition views were indeed implemented, then I imagine this step would become unnecessary.)

The resulting view structure:

Views:
 

• Idle: stationary and/or blinking character
   
• Walking: walking frames only
   
• Transition: frames that are called in sequence before walk views are played. (smooths out transition from standing still to first walking frame)
  
  I think this would be a suburb feature for AGS 3.0.
  
  Cheers,
  Paul.

[Shane 'ProgZmax' Stevens]

Well, I know a lot of people have been telling you that you can do several of your suggestions easily in ags already, and in this case I will say that you definitely can.

Basically, what you can do is create a function that examines the player's (or any character's) movement status (.Moving) and goes down a basic if/else check to see which state is just occurring. 

For example:

Code: ags

int stop_transition = 0; // a global variable to keep track of whether the stop animation has been used.


if(cSubspark.Moving== true && stop_transition==1)
{
     //we want stop_transition to be 0 now so it will play the next time you stop
     stop_transition=0;
}
else if(cSubspark.Moving == false && stop_transition==0)
{
     //he's just stopped moving, let's run an animation of him stopping based on the
    //current loop

    int curr_loop == cSubspark.Loop;  //down =0, left = 1, right = 2, up = 3
     
         //play the animation for him stopping slowly
         //

         cSubspark.LockView(SUBSPARK_TRANSITION);

         //can make this blocking or not, it depends on you

         cSubspark.Animate(curr_loop,5,eOnce,eNoBlock,eForwards); 

         cSubspark.UnlockView();


    //set stop_transition to 1 so this transition animation cannot be run again until the character starts moving

    stop_transition=1;

}

Basically what this should do (I haven't actually tested this, yet) is check cSubspark for movement every time it is called (you could put it in repeatedly_execute to ensure it happens regularly).  The moment it detects that he's stopped moving AND has not been stopped already it runs a transition animation in SUBSPARK_TRANSITION using the same loop layout as his walk cycles, so if loop 0 is walking down then loop 0 in SUBSPARK_TRANSITION is him stopping while facing down.  Once it plays the animation it will then set the stop_transition variable to 1 so it does not repeatedly play the animation and will continue to bypass these loops until cSubspark moves. 

To have a transition to walking you'd check for a start_transition variable or something like that.  It might require some fiddling to get the animation timing just right, and you'd probably want to make the function able to check any character, but I'm pretty sure it would work.

[subspark]

I managed to get it to compile by removing one of the = from the int however upon running the game it crashes due to the following line:

Code: ags

cSubspark.Animate(curr_loop,5,eOnce,eNoBlock,eForwards);

While this may be done in code I still stand by my suggestion towards having a built in system for a future version of AGS.
Any ideas?

Cheers,
Paul.

[Gilbert]

Since V3.00 is already at RC stage, I don't think these kind of features will be added (that's also why CJ asked you to start a new feature-request thread instead of posting it in the V3 thread).

I think this may be useful sometimes, but doubt whether many people will use it (that also means EXTRA work when making sprites).
Moreover, your suggestion would mean basic changes to how stuff are implemented, which is not very preferable as it can break backward compatibility.
I have an idea, maybe, instead of using separate views, use the same view for everything like how it is done currently, but you have an option to choose the number of "easing" frames, which is nothing more than an extra integer parameter for each character:

1. When it is set to 0, there'll be no "easing" frame, so when the character stops walking he stays at that frame of graphics instead of displaying the stationary frame (may be useful to simulate the effect of say, some earlier AGI games).

2. When it is 1 (default), that means it has one "easing" frame, which is the standing frame, this is identical to what we have currently.

3. When it is larger than one, we can have several frames of "easing" animation to transist into the walking animation. Say, when the parameter is 5, then when the character starts to walk, the animation in frames 0-4 would be played (with frame 0 being the standing frame) and then cycle through 5 and the last frame while walking.

Anyway, though I can't speak for others, I have doubt on whether there're many people who need this feature to warrant it an addition of high priority.

[subspark]

High priority no. But something worth exploring for future versions, I believe so.
You've raised some interesting points, btw.

Is what your suggesting the same as what ProgZMax wrote? I'm not sure what you mean when you say,

which is nothing more than an extra integer parameter for each character:

Cheers,
Paul.

[Gilbert]

No, what I suggested was a possible feature upgrade (as opposed to the method you suggested), not a scripting workaround.

[subspark]

Oh I'm on the same page now. Thats actually how I originally imagined it would work until I thought about the separate views thing.
Good suggestion Gilbot. If we could add this feature without incurring any collateral damage on the current system then it's definitely something to look into for a future version of AGS. Would you agree Chris?

Cheers guys,
Paul.

[SSH]

Personally, I'd rather CJ spent his valuable time enabling people to do things that can't be done by scripting, rather than hard-coding what a module could do into the engine.

[subspark]

Well I imagine its pretty low on the list of priorities anyway, SSH but we'd be wrong to rule it out. 
Cheers,
Paul.

[Shane 'ProgZmax' Stevens]

One thing you must do is ensure that all the loops in question are filled, because if curr_loop moves to something that isn't there it will crash.  You can further protect the code by checking to make sure the current cSubspark view is set to your SUBSPARK_WALK view (or whatever you want to call it) and to make sure all the walking loops (4 or 8 depending) are full.  All 4 or 8 loops of the transition view will need to have sprites in them as well .  If it still crashes, pm me the error or something.

[Pumaman]

Something that has been suggested before was the ability to mark a Start and End frame in the walking loops, such that any frames before the Start frame would be played as a transition into the walk, and after the End frame would be played as a transition out of the walk.

However, this isn't as easy to implement as it sounds. Because the movement could end at any time, how do you go from a random walking frame to the stopping transition smoothly?

[Shane 'ProgZmax' Stevens]

In the case of relatively small walk cycles, I suppose it could just play out the sequence and then transition, but this would not be as practical for a walk animation with many frames. 

[subspark]

how do you go from a random walking frame to the stopping transition smoothly?

Thats a good point CJ. I imagined that the transitions would only be necessary for starting rather than both starting and stopping. But if one is willing to draw xx sprites ...

Cheers,
Paul.

[Pumaman]

In the case of relatively small walk cycles, I suppose it could just play out the sequence and then transition, but this would not be as practical for a walk animation with many frames. 

Potentially, but if it played out the full sequence then you'd end up with the character standing on the spot animating when he'd already finished moving.

Thats a good point CJ. I imagined that the transitions would only be necessary for starting rather than both starting and stopping.

I think this would look even stranger, because you'd have a smooth start to the walk and an abrupt end; it would probably result in more complaints than doing nothing!

[subspark]

I think your right Chris, about developers complaining that there isn't any transition out. Having said that there are alternate ways to go about this.
For example, in a moderate length walkcycle there are about 3 or 4 frames during the course of the animation where one transition would look smooth enough for those three frames to be undetectable by the player. The player could indeed 'walk' through enough frames to reach one of the transition friendly frames. To stay true to the point at where the user clicked, the movement speed could slow slightly to compensate. This might all sound too complicated but it's the only way I can think of to accommodate transitions for starting AND stopping.

Cheers,
Paul.

[Rui 'Trovatore' Pires]

If one wanted to go ALL the way, one would have to find a way to get the engine know when the character's foot has reached the ground. If it has and the next step would end character movement with a foot in the air, DON'T take that next step and instead play the "stopping" animation.

Kinda like Broken Sword. I once asked here if it was possible, but only as a hypothetical exercise. I remember being told that it was, and I left content.

Make of this what you will. Seems like a rather insane amount of work for a visual effect, but then again, it IS a purty damn nice effect.

[subspark]

Seems like a rather insane amount of work for a visual effect, but then again, it IS a purty damn nice effect.

Your not wrong there Rui. It sure is a visually pleasing aesthetic to a game. So you beleive what i said above can be done with some effort? Does anybody know how they tackled this for Broken Sword?

EDIT:

one would have to find a way to get the engine know when the character's foot has reached the ground.

Actually this could be acheived with the suggested foot plant plugin from this thread:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33099.20
You could set states besides offset coords for each frame like foot down or leaning forward and you could draw your actions from there.

Do you like where I'm going with this Chris?

Cheers,
Paul.

[Pumaman]

If one wanted to go ALL the way, one would have to find a way to get the engine know when the character's foot has reached the ground. If it has and the next step would end character movement with a foot in the air, DON'T take that next step and instead play the "stopping" animation.

But this would'nt work either. Suppose that the character's foot has just reached the ground, and there are 2 more game loops before he stops.

Even if at this point it switched to the stopping animation, unless that animation happened to have 2 frames in it, it would still look strange.

[Khris]

Am I correct that the x- and y-speeds are handled as floats internally?
If I am, the walk speed could be slightly adjusted so the character will reach the end point at exactly the right frame.

Say the x speed was 3 and the character is going to walk 100 pixels straight to the right using 6 frames.
With the current system he'll reach the 90th pixel using the 6th frame, then 1st @ 93, 2nd @ 96, 3rd @ 99, standing frame at 100. Thus, the animation jumps from the middle of the walk-cycle right to the standing frame.
AGS could calculate the two boundaries (90 & 108), choose the closer one (108) and adjust the x-speed of 3 to 3*(100/108)=2.77.
The downside is that this will screw up elaborately drawn walk-cycles and won't look too good with short distances.

[subspark]

The downside is that this will screw up elaborately drawn walk-cycles and won't look too good with short distances.

Your right about that. In my suggestion above I mentioned decreasing the movement speed and increasing the animation speed by 1 or somesuch but the success of this is entirely dependant on how far the player travels. Darn. I can't beleive that didn't hit me. Late nights.

Paul.