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.