[Ohrrpgce] Slice animations, reactions, signals, context, menus, classes, script OO and fibers

[Ralph Versteegen]

My work on animations and other features is held up quite a bit by design
decisions being interdependent on many other features which haven't yet
been designed/agreed upon. I've tried writing up this stuff several times
before, but I never reach the end of that writeup, so I'm just going to
split it out over a number of emails, full of loose ends, get feedback, and
try to incrementally converge to a plan. The title outlines the scope (all
about slices and OO).

Learning Godot has been hugely helpful, providing new ideas, validating
ones I had, or suggesting where to diverge from or improve upon Godot. (For
example, nodes in the scene tree have an integer-valued "z index" which is
exactly the same as the slice "z index" I proposed once, and it turns out
to be wonderfully useful indeed).


=Slice Animations=
One thing I was very unsure about was whether to allow sprite animations to
move the sprite slice's position or just offset where the sprite is drawn
relative to the Sprite slice position, and handle slice movement by some
other animation system, or just have no movement at all and keep animtions
simple. I now think that moving the sprite slice is a very important
feature (eg we ought to aim to allow this without scripts:
https://cdn.discordapp.com/attachments/275093304322818049/688893625110626311/treasurevalley0022.gif
)
In fact I think that sprite animations should actually be slice animations.
Yes, a slice animation system is more complex than a sprite animation
system, but a powerful animation system with a good UI which requires no
scripting is *vastly* easier than requiring users to learn HS and write
scripts.

Allow any slice to have animations, which are automatic changes to the
slice's attributes.  For example a rect that shifts between different
colours, or a container slice that slides on- and off-screen. A sprite
animation will then be a slice animation that also has additional animation
operators to change sprite-specific data, and we would other other slice
type-specific ops too.

=Animation ops=
Many but not all slice attributes would be mutable with slice animations.
The ops could be (de)serialised as RELOAD nodes overlapping how Slices are
(de)serialised.

Sprite animations will have a simple "play this frame group, X ticks per
frame" option.
Aside from that, I had a series of "set state, wait" animation operators in
mind. But we should also have complex operators like "interpolate attribute
X from value A to value B over T ticks, with easing function E
<https://easings.net/en>. (I guess initial value A isn't needed, though it
would help the animation editor to know the initial state) These are only
available for "continuous" (though still currently integer-valued)
attributes like position, padding, palette index (because palettes contain
ramps).

As soon as you talk about slices, you have slice trees. Animations ought to
be able to tell child slices to do something, and maybe even to spawn
children. Sometimes directly modifying child attributes from the parent's
animation is far easier than using an animation on the child. Particularly
for moving children (e.g. synchronising movements and the gif linked above).

=Slice reactions/hooks=
Non-sprite slice animations may sound limited, but "animation" is a
codeword for "script created in an editor instead of written in HS". I want
to allow animations to be script hooks, so you can attach a script instead
of defining an animation. Think of a slice as an instance of a class, and
animations and "reactions" are methods or hooks called upon a signal.

Hand-waving, reactions are just animations, but when you play an animation
it stops and replaces the existing one, while when you play (trigger) a
reaction it doesn't. Reactions probably could still contain wait commands.
Maybe the only difference between the two is that reactions end in "return"
while animations end in "loop" or "goto idle"?

There's plenty possible hooks for a slice to have. They could react to
generic events like being created, mouse-over, selection, activation
(click/use). (Basically I want to get rid of the hard-coded plankmenu
reactions in the Items menu and elsewhere.) But also we already have these
SliceContext types: so far just NPCSliceContext and HeroSliceContext. I'd
like to be able to treat slices that have one of these *as* an NPC or hero
for some purposes. These slices could receive NPC/hero specific signals
like "use", "each-step", "turn", "pushed" and signals triggered by
entering/exiting/stepping in zones (e.g. to change the walkabout palette in
shadows). Examples in battles are more interesting.

I hear some animation systems are organised around "states" and
"transitions". Consider transitions like moving from standing to running -
what if you want a special animation for that (probably a couple existing
frames with different ticks-per-frame)? I wonder how reactions could be
used for that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20200319/9bfd471a/attachment.html>