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 <[email protected]> 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 > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >
_______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
