Spike Animation Tools

[mzgoddard]

How can existing tooling be used or new tooling created to support users doing the following to animations with boxart.

1. View
2. Edit
3. Blend

[mzgoddard]

Looking at Cocos Creator's animation mechanism and animachine I think there is an interesting and important problem unanswered in them. Responsive animations. How do you animate objects in a responsive website. The animation needs to deal with the context that the elements on the page may not have an absolute cartesian coordinate.

[mzgoddard]

From thinking on this last week, and talking with some people, any first tool would provide the first step mentioned in the issue's body. A tool to view animations in the project. For those animations we need to define what an animation's definition looks like and what it animates can look like.

Lets call what an animation works on an armature, a term used to describe the bendable wire underneath a sculpture. An animation should be applicable to multiple armatures as long as they have some pieces that are named the same. Like duck typing, if an armature looks like a duck an animation for a duck can work on it.

Lets refer to animations as animation clips. Or clips for short. Clips take input from an armature and transforms wires in the armature for those inputs. Those transforms can be dom styles and element attributes or methods on the wires if they are there. Common methods will be to interact with particle systems, emitting particles, or starting animations on armatures under a larger one allowing some clips to be constructions of smaller clips over a more complex armature.

Since we are working on top of React any first version will focus on that so we don't get stuck being something more generic. A more generic version that can work outside React on any DOM or even interact with Canvas framework objects is a great target but one we'll look to do later after we have a tool focused on React and BoxArt's helpers.

Armatures and Animations will be defined in JS but we should focus to make to define them so what they use can be understood by less technical team members. An armature is likely a subclass of Animated and instead of taking an animate function property takes an animation clip and a refs object. Instead of looking up elements by id or class or other dom selector, elements are stored on an object with keys that the animation expects. The armature can define a hierarchy for itself but the animation won't know that hierarchy just the names of the nodes it defines. In common sprite animations, the armature should define what frames go to what assets. An animation isn't in charge of loading assets, an armature is, so the armature also translates sprite info from an animation clip into how that changes the relevant element.

We should look to take this first version of the tool into helping with editing. A timeline is a naturally desired feature but it'll be a later target. First we need a common editing surface. Non technical team members may not have a preferred text editor setup with a lot of the helpful tools and plugins a technical team member may have. A minimum editor for editing armatures and animations would be a good second target after being able to preview animations. Being able to bring up and identify compile errors immediately while developing an animation would be greatly helpful. Since boxart-boiler is using babel we can probably take inspiration from babel-standalone for the editor and error prompt.

I think making an electron (or similar tool) wrapped version of the animation preview / mini-editor may be out of scope for this

All of these thoughts down I'm proposing a page generated by running the grunt (or npm start) command that provides the following features by milestones.

Milestone 1

• Lists armatures
• Lists animation clips
• Previews an armature with a given animation clip
  • Can play forward, play backward, pause, step forward, step backward, set position in time
  • HMR on armature or animation updates the preview

Milestone 2

• Preview
  • hover over element presents tooltip with its armature name
  • non-erroring changes in the editor updates the preview
• Editor
  • Switch between Editor views
  • Edit armature js
  • Edit animation clip js
  • Babel compile in the browser and update the preview immediately
  • State js errors and note their line
  • Prompt when a change on the file system triggered HMR (hot module replacement) that update the currently modified armature or clip

Milestone 3

• Preview
  • click on an element pauses (if not already paused) and lets you do standard transforms and see the resulting value, at this point it's up to the user to put their transform in the animation clip, this is just a vastly convenient way to find out what the transforms should be

[kadamwhite]

To recap the original brief for this spike, the goal is to have animations be something that can be authored in isolation, then integrated into a game, but still viewed in comparative isolation for debugging purposes; i.e., here's how this one agent in the game should move; here's it moving in the real game; if it's not moving properly, pull it up on its own again to see whether the error is part of its animation code, or an interaction with another animation. (All of this is stated above, just re-wording for my own clarity)

[kadamwhite]

The motivation for building an editor is to reduce the barrier to entry for non-programmer motion designers and editors: having an editor that can intelligently support on-boarding these users would significantly reduce friction and back-and-forth between motion designers and their supporting developers.

After discussion with @mzgoddard, I propose this re-cast of the prioritization, on the grounds that the editor is a large piece of work in and of itself and the preview/interaction capabilities of an animation viewer are relevant beyond the userbase that would be depending on this editor:

Milestone 2

• Preview
  • hover over element presents tooltip with its armature name
  • click on an element pauses (if not already paused) and lets you do standard transforms and see the resulting value, at this point it's up to the user to put their transform in the animation clip, this is just a vastly convenient way to find out what the transforms should be (could be implemented as a separate, parallel tool to the animation preview viewer)

Milestone 3

• Preview
  • non-erroring changes in the editor updates the preview
• Editor
  • Switch between Editor views
  • Edit armature js
  • Edit animation clip js
  • Babel compile in the browser and update the preview immediately
  • State js errors and note their line
  • Prompt when a change on the file system triggered HMR (hot module replacement) that update the currently modified armature or clip

[kadamwhite]

With the work items captured in #86, #87 and #88, this item can be closed. Thanks for the detailed write-up, @mzgoddard !