<div dir="auto"><div>I was skeptical about animations moving slices, but in this mail you have convinced me.<div dir="auto"><br></div><div dir="auto">I see no problems with any of these suggestions.</div><div dir="auto"><br></div>Does implementing all this require script mutilthreading to be implemented first? Is that a prerequisite?</div><div dir="auto"><br></div><div dir="auto">---</div><div dir="auto">James Paige<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, Mar 19, 2020, 1:47 AM Ralph Versteegen <<a href="mailto:teeemcee@gmail.com">teeemcee@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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).<br></div><div><br></div><div>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).</div><br><div><br></div><div>=Slice Animations=<br></div><div>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: <a href="https://cdn.discordapp.com/attachments/275093304322818049/688893625110626311/treasurevalley0022.gif" target="_blank" rel="noreferrer">https://cdn.discordapp.com/attachments/275093304322818049/688893625110626311/treasurevalley0022.gif</a>  )</div><div>In fact I think that sprite animations should actually be slice animations.</div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>=Animation ops=</div><div><div></div><div>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.</div><div><br></div></div><div>Sprite animations will have a simple "play this frame group, X ticks per frame" option.<br></div><div>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 <a href="https://easings.net/en" target="_blank" rel="noreferrer">easing function E</a>. (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).</div><div><br></div><div>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).<br></div><div><br></div><div><div>=Slice reactions/hooks=</div><div>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.<br></div><div><br></div><div>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"?</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div></div><div><br></div><div><br></div></div>
_______________________________________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank" rel="noreferrer">ohrrpgce@lists.motherhamster.org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer noreferrer" target="_blank">http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org</a><br>
</blockquote></div></div></div>