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

[Ralph Versteegen]

Multithreading (script fibers) is a prereq for implementing slice
animation/reaction script hooks (that is, running a HS script instead of
running an animation... script... terminology needs some work), because
animations need to run inside battles and menus, should run at the same
time that an animation/reaction would have been run (immediately at the
point the reaction is triggered? **) eg when the sprite slice is
updated/processed.
(Plus script OO might also be a prereq if those scripts are actually class
methods? I don't know.)

However there's no need to implement script hooks to begin with; that can
be added later. General slice animations and animation ops other than some
basic sprite ones can also be added later, though I want to settle on an
extensible file format (what I currently have for .rgfx, but don't actually
use yet, isn't general enough).

** In Godot, signals and method calls are often deferred (put on a queue to
be run at "idle time") out of necessity. I wasted a lot of time trying to
get initialisers to run in the desired order. You can pass a flag when
registering a signal handler that you want the call to be deferred. I had
something similar in mind: if you attach a plotscript to any sort of
trigger (not just animations), you get the current behaviour. But we could
have other script types, say "object scripts" or "npc scripts", which
behave differently when triggered. They could run immediately and not
suspend any plotscripts. Plotscripts would be the unique script trigger
type you use for cutscenes, since only one cutscene plays at once, and they
pause inside menus.
Incidentally, Godot's script interpreter is (optionally) multithreaded,
which really shows that the devs are insane enough to want it all. You have
to do your own synchronisation to get thread safety, such as using deferred
calls across threads, or it will crash since it seems locking isn't always
done, for speed.

On Thu, 19 Mar 2020 at 22:52, James Paige <Bob at hamsterrepublic.com> wrote:

> 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
>>
> _______________________________________________
> 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/20200320/9538d22d/attachment.html>