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

[James Paige]

I was skeptical about animations moving slices, but in this mail you have
convinced me.

I see no problems with any of these suggestions.

Does implementing all this require script mutilthreading to be implemented
first? Is that a prerequisite?

---
James Paige

On Thu, Mar 19, 2020, 1:47 AM Ralph Versteegen <teeemcee at gmail.com> wrote:

> 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.
>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20200319/207f0702/attachment-0001.html>