Animation editor in AGS 4.0

[Mehrdad]

Hi developers
I'm an animator and I really need to this structure in engine. This feature is ready in Visionaire and other game engines

1) change Anchor point to adjust to previous animations.


2) More than one frame to start animation in View editor. For example, start of 0 and return to loop to frame 4.
3) More than one frame in stop animation in view editor. For example, standing of character with a little animation.
4) custom "turn before walking" . For example Left to right --> play loop number and frame number
   I have a module that was written by @Gurok for this with some a little bug. if you want.

Thanks in advance

[Crimson Wizard]

This task is best separated into parts:
1. Data, how the necessary animation sections and other properties are organized within existing items (views, loops etc).
2. Engine behavior, how the engine runs these animations.
3. Editor interface.


For example, there may be two options for making start/stop animations.

One is to define a entry and exit sections within a loop, where middle section will be treated as looping.
This, however, may be inconsistent if used with Animate command, because animation may be stopped instantly by a script command, and it won't be proper to play an ending sequence after it ordered to stop. So while entry segment might work with Animate command, the exit segment won't.
OTOH, I suppose that having entry segment in the loop may be useful for regular Animate command too. Alternatively, we might introduce new parameter to Animate that tells which part to play: entry, middle or exit.

Another option is to have a new dedicated loop for each enter/exist segment. The downside would be too many loops to set, as you need that for each walking direction, so for a single walking dir you'll have 3 loops, for 4 directions - 12 loops, and 24 loops in case of 8 directions. Or maybe that's not a big deal. I'm not an animator, so cannot tell.

The upside of this second approach is perhaps that it's more consistent with idea of "animation transition".
If we also have transitions between walk directions (for turning), these would be dedicated loops, and then the whole system is represented by loops with assigned roles (rather than parts of loops).


EDIT:
I remember that in sound design the starting/ending parts of the track are called "Roll In" and "Roll Out". Do you use similar terms in animation?


EDIT 2:
Speaking of workarounds, AGS 4 script has a new Pathfinder and MotionPath commands that let you calculate the walking path and use it for scripting custom walking.

[Crimson Wizard]

I've been thinking about the "turning" animations, and how they could be organized in principle.

Right now we have a "Walking view" in AGS, which loops are designated certain fixed roles (walk Up, walk Down, and so forth). Suppose we want to also have "turning" loops. There are following questions here:


1. Is it better to have them also in a "walking view" or have a separate "turning view"?

Having them in a walking view would keep things together, but increase number of loops. Also, if we keep fixed loop roles, this may make it more difficult and inconvenient to expand walking view in the future (for example, if we like to add more directions).
If we have them in a separate view, then there will be another property, such as Character.TurnView, which is optional and may be left unset if you don't need that.

A certain downside of having a separate view is that previewing character movement may require switching views.
OTOH we might require a different preview controls anyway, which let switch direction/action more conveniently, rather than select loop number.


2. How many turning animations do we support?

There are 4 walking directions by default, and 8 directions if diagonal dirs are enabled.
How many turning transitions are going to be there?

Should there be animations per clockwise and counter-clockwise turning only, such as Left->Up, Up->Right, Right->Down etc, and turning from Left to Right would play two animations like left->up + up->right.
Or should there be animations between any pair of directions, like left->up, left-down, left-right?

In the second case, the number of turning transitions between cardinal directions will be 4 * 3 (each direction turning to each other direction). In case if there are diagonal directions, then there are 8 * 7 transitions.
So we will need to assume that the maximal possible amount of loops is 8 * 7 = 56.
Is this logic correct?

On another hand, I assume that not all combinations are necessary, as user may like to have only few of these animated in their game. And all of these are considered optional.

We need to know what should happen if turning view is set but particular loop is abscent.
What is the logic of selecting and playing a animation when turning character from direction A to direction B?


3. How do we designate loop roles for turning?

The assumption is that:
- we may have loops with roles in multiple views (e.g. WalkView, TurnView, etc)
- we may have a big number of max possible loops
- not all of these loops may be useful.

Currently only "Walking view" has loop roles. If other views will have loop roles, then Editor will need to display different hints. How will Editor know which hints to display?
Currently there are only 8 walking loops with defined roles. What if there is going to be more?
What if user needs only few of the many possible loop roles, what will be the convenient way to work with the view?

This makes me think that we need a different approach.

If we like to stay in the existing AGS View/Loop paradigm, then I can see following options:
1. A view may have a "View Role" selection in the Editor, which tells how to interpret this View, and how to call its loops.
2. Additionally, Editor may allow to set a role freely for each loop. Or, on contrary, display only loops of certain roles.

The difference between a) assigning a role to a loop and b) display a loop of fixed roles, is that:
1. If a loop has a custom role, then this data must be passed into the engine, and engine must modify its logic. It no longer will be able to decide loop by its number, but will have to decide the loop by its "role" parameter. If such rule also applies to a walking view, then this means that Character.Loop property will no longer directly correspond to the walking Direction.
2. Alternatively, if Loop roles are still fixed, then Editor may simply hide unused loops and display only ones that user selected. The loop numbers will still have a role attached to them, but some may not be displayed in the editor and remain empty.

[Crimson Wizard]

@Mehrdad , could you upload examples of the starting, stopping and turning animations, for our reference?

[eri0o]

@Crimson Wizard , I don't know if it helps or not, but I shared with you a game on GitHub that has some interesting view animations in case it's useful.

[Crimson Wizard]

@Crimson Wizard , I don't know if it helps or not, but I shared with you a game on GitHub that has some interesting view animations in case it's useful.

Oh, I did not realize that, I've seen the invitation, but thought that's some kind of mistake.
I'll check that out then.

[Snarky]

The only part of this I have an immediate opinion on:

1. Is it better to have them also in a "walking view" or have a separate "turning view"?

Having them in a walking view would keep things together, but increase number of loops. Also, if we keep fixed loop roles, this may make it more difficult and inconvenient to expand walking view in the future (for example, if we like to add more directions).
If we have them in a separate view, then there will be another property, such as Character.TurnView, which is optional and may be left unset if you don't need that.

A certain downside of having a separate view is that previewing character movement may require switching views.
OTOH we might require a different preview controls anyway, which let switch direction/action more conveniently, rather than select loop number.

If we build on the existing AGS logic, I don't think there is any doubt that turn-animations must be a separate view (or multiple views), and probably start and stop animations as well. There will often be a need to have them for different directions, and directions are currently defined by loop number.

This is also consistent with how all the built-in animation logic is done (apart from the merging of standing and walking views).

Now, perhaps there could be reason to rethink the hardcoded way directions are tied to loops. And the ideal solution for walks (and other animations) with particular start/stop sequences would probably be the ability to define animation loops with intro, loop and outro sections. But short of such fairly radical changes, I think the answer is clear.

[Snarky]

I would add that I think this all sounds like it will get very complicated very quickly.

For example, there can be cases for walk-start animations where the character remains stationary while the start animation plays (for example an animated skeleton that collapses whenever it stops, and has to reassemble and reanimate before it can move), and other cases where they start moving while it plays (for example a character with a cape, where the walk-start animation is to get the cape, which hangs straight down when stationary, to lift and trail after the character). Do we need a setting and branching logic in the engine to handle both cases?

And what happens if you send another walk command in a different direction while the walk-start animation is playing? Do you play the turn animation? Do you restart the walk-start animation with the new angle, or continue from the same frame? I think it will be very hard to find a solution that will satisfy every use case.

As for the stop, will it play before the character comes to a stop? (Like a "skid to a stop" animation for a run.) In that case you need logic to predict how far there is left, so you can start playing the animation while the character is still moving.

[Mehrdad]

@Mehrdad , could you upload examples of the starting, stopping and turning animations, for our reference?

I sent you PM

[Snarky]

I suppose it makes sense to copy some of the discussion from Discord here as well. @Walmaker posted a comparison of walks in DOTT and AGS, which led to considering some of the quirks in AGS walks (including this), identifying some things SCUMM does differently, and hence alternative possibilities in AGS.

When it comes to turning in walking, we need to think of both turning at the beginning of a walk, and in the middle of a walk. To take the middle first, the options I can think of are:

• Stop to turn
  
  • Instant (this becomes a shorter step, but character then continues walking in the new direction with no transition) – I believe this is how changing direction while walking works in AGS currently
  • Spin in place (using standing frames) – the way turning before walking works in AGS currently
  • Walk in place (using walking frames, animated)
  • Dedicated turn animation in place
• Continue along next path segment
  
  • Instant (go directly to the new direction)
  • Walking turn (facing direction passes through intermediate directions, while moving and walk-animating) – this is how turning works in SCUMM
  • Dedicated turn animation on the move (play a turn animation while moving)

[Crimson Wizard]

@Mehrdad , could you upload examples of the starting, stopping and turning animations, for our reference?

I sent you PM

Thank you, but I was hoping for something that may be posted for everyone to see, that is - not private.
There's no guarantee that I will be doing this. Someone else may be working on this in the future.
Some people may have ideas of how to implement this feature, so they may have a use for real examples too.

[Mehrdad]

So

@Mehrdad , could you upload examples of the starting, stopping and turning animations, for our reference?

I sent you PM

Thank you, but I was hoping for something that may be posted for everyone to see, that is - not private.
There's no guarantee that I will be doing this. Someone else may be working on this in the future.
Some people may have ideas of how to implement this feature, so they may have a use for real examples too.

rry

Thank you, but I was hoping for something that may be posted for everyone to see, that is - not private.
There's no guarantee that I will be doing this. Someone else may be working on this in the future.
Some people may have ideas of how to implement this feature, so they may have a use for real examples too.

Sorry, it's just related to the arts. No other things

You can share all the codes
 

[Crimson Wizard]

For example, there can be cases for walk-start animations where the character remains stationary while the start animation plays <...>, and other cases where they start moving while it plays <...>. Do we need a setting and branching logic in the engine to handle both cases?

<...>

As for the stop, will it play before the character comes to a stop? (Like a "skid to a stop" animation for a run.) In that case you need logic to predict how far there is left, so you can start playing the animation while the character is still moving.

Indeed, these are also essential questions. I wish that @Mehrdad elaborated more on which sort of effect he has in mind.

In modern engines, AFAIK there are animations made of node-based state machines, where user may decide for themselves how does animation corresponds to the movement (i.e. movement direction changing, movement speeding up or slowing down, and so on).

[eri0o]

I guess the original author of this game wouldn't mind (and I think he has said so in the past to me on LinkedIn).

https://github.com/ericoporto/concurrence_refactor/blob/24fddddd1b63f98422f557c721bd8d032f0f9661/Platformer.asc#L169

There is a sort of state machine here. The thing to notice is that this isn't a point and click, but anyway, the animation here is tied to the game play. I guess the state changing logic, which would require something like function as parameters if implemented solely in script if it was not specialized (specific) for this game.

[Crimson Wizard]

For example, there can be cases for walk-start animations where the character remains stationary while the start animation plays (for example an animated skeleton that collapses whenever it stops, and has to reassemble and reanimate before it can move), and other cases where they start moving while it plays (for example a character with a cape, where the walk-start animation is to get the cape, which hangs straight down when stationary, to lift and trail after the character).

From what I understand from the first post, the request was to have a "intro" and "repeating" part of the same animation. That is - the second case in your examples.

It's not a separate view that plays as a separate stage, but the same walking view, except it does not go all the way back when it repeats, but goes back to the particular frame in the middle.

This may be implemented fairly easily in AGS without changing much. We only need to be able to mark a frame that begins the repeating part.

And what happens if you send another walk command in a different direction while the walk-start animation is playing? Do you play the turn animation? Do you restart the walk-start animation with the new angle, or continue from the same frame?

I think that if there's no turn animation, then it should continue a different loop from the same frame, just like it does now when walking. If that's a frame from "intro" sequence, then the new direction continues with the "intro". if it's in "repeating" sequence, then it continues with repeating.
If there is a turn animation, then I am not sure what it should do.

As for the stop, will it play before the character comes to a stop? (Like a "skid to a stop" animation for a run.) In that case you need logic to predict how far there is left, so you can start playing the animation while the character is still moving.

I am not sure myself. Maybe we may begin with having a "outro" loop sequence that plays when the character stopped moving.
In other words, we can have a "intro"/ "repeat" (or middle) / "outro" parts of the animation loop.

But re-reading the first post, I begin to doubt if that's what Mehrdad meant. Maybe he was speaking about "idle standing" animation, not "stopping after walk" animation.


@Mehrdad, could you please elaborate on these? We need to understand which kind of animation behavior are you asking about exactly.


EDIT:
I checked the Visionair Studio. I've never used it before, so only understand the basic idea.
They have separate entries (sort of views from AGS) for:
- Walk animations
- Stand animations
- Turn animations

Other interesting bits:
- each frame may have a trigger action, including calling a script; I believe that Alan Drake was trying to design a similar thing a while ago (although it is difficult because AGS does not have a base object class in order to pass the generic pointer into such function as a "caller" parameter).
- walking animation allows to define the amount of movement per each frame (although i could not understand how to set separate values, the UI is rather confusing in this editor).

[Mehrdad]

@Mehrdad, could you please elaborate on these? We need to understand which kind of animation behavior are you asking about exactly.

OK

1) Ability to change character offset. Like the one you added in the View Editor. But visually. ( XOffset, YOffset). Please see image in first post.
2) Custom turning ( Like Visionaire). I sent for you this module
3) More than one frame for Stop character. AGS has only one frame for stop player in View editor. Please increase it.

These features are enough for a animation editor

[Crimson Wizard]

@Mehrdad , sorry, but that's not elaboration, that's short version, it is already present in the first post.

Let's start with "More than one frame for Stop character".
What do you mean by this?
- animating a character while the character is standing?
- or special animation when the character is stopping in the end of the movement?

2) Custom turning ( Like Visionaire). I sent for you this module

Can you explain, in plain words, what is the desired behavior? I do not want to read the script module, trying to understand what it does.

For instance: should there be different animations depending on whether character was standing still, or moving when turning?

[Mehrdad]

What do you mean by this?
- animating a character while the character is standing?
- or special animation when the character is stopping in the end of the movement?

special animation when the character is stopping in the end of the movement.

Can you explain, in plain words, what is the desired behavior? I do not want to read the script module, trying to understand what it does.

Ok. Let me explain to you with an example

cEgo.SetTurnAnimation(eDirectionDown,eDirectionUp , eTurnClockwise , 4, 0);
The character is in the "down" state and is clicked "up". it moves clockwise, and use int view 4 , int loop 0

Edit : Clockwise is not an important option

[Crimson Wizard]

special animation when the character is stopping in the end of the movement.

Alright.

Is this animation played while the character is still moving a second before stop; or is it played after the character have stopped and is standing still already?

What should happen if player clicks to start a new walk during the stopping animation, does the character finish the stopping animation first and then starts moving again, or is the stopping animation interrupted and walk animation plays instead?

Ok. Let me explain to you with an example

cEgo.SetTurnAnimation(eDirectionDown,eDirectionUp , eTurnClockwise , 4, 0);
The character is in the "down" state and is clicked "up". it moves clockwise, and int view 4 , int loop 0

That's not what I meant...
I meant logical explanation of how the turning animation should work.

For instance:

Is there a difference if character is turning while standing still, or is turning while already moving? Is it the same animation, or two different animations?

What happens after the turning animation, does the character begin walking from frame 0 again, or does he continue with the last walking frame he was on?

[Mehrdad]

Is this animation played while the character is still moving a second before stop; or is it played after the character have stopped and is standing still already?

Once stopped, it will only run once.

Is there a difference if character is turning while standing still, or is turning while already moving? Is it the same animation, or two different animations?

This is the same "Turn before walking" that is present by default in AGS, but here we tell the player to first execute our frames and then move.


5) other feature I remember now: More than one IDLE for player. And run in random.