Three deliverables, one character: document and frame-rate planning
A regional science museum has hired your two-person studio for three deliverables built from one set of illustrations: an offline touchscreen kiosk (1080 x 1920 portrait, Windows 10 PC, no internet, capacitive touch, 24-hour uptime), a 15-second loop for a 3840 x 1080 video wall driven at 30 fps, and a 6-second vertical social bumper (1080 x 1920). The client wants the same character art in all three. Deadline is three weeks, and the video wall loop will be rendered to MP4 by the venue's own AV contractor rather than played live from Animate. Your junior proposes building everything in a single 30 fps document at 3840 x 1080 and scaling down at export.
1. How should the project be split into files, and what is your reasoning for refusing the single-document approach?
Read the worked answer
Three deliverables, three documents, plus one shared art source. The single-document plan fails on specifics, not principle: a 3840-wide stage scaled to 300 px for social turns a 24 px label into roughly 2 px of mush, and the kiosk's touch hit areas are authored against real 1080 px coordinates, so they cannot be inherited from a scaled-down master. Export paths also diverge completely - the kiosk publishes as an interactive runtime, the wall is a rendered MP4 the contractor encodes, the bumper is a short looped clip. Each needs its own approval cycle and its own QA. So: kiosk.fla, wall.fla, bumper.fla, and art_source.fla holding the character symbols, pulled in through File > Import > Open External Library. Document in the spec that external-library imports copy symbols at import time, so art updates are re-imported at named art-lock milestones, not silently assumed to propagate.
2. Specify frame rates for each document and explain what breaks if the wall loop is authored at 24 fps and converted.
Read the worked answer
Wall: author at 30 fps and keep the loop length an exact multiple of the render frame rate, because the contractor renders 30 frames per second and any 24 fps source is resampled. That resampling duplicates and drops frames unevenly across a 15-second loop, and the seam at the loop point is the first thing a viewer notices on a wall-sized screen. Kiosk: match the source of motion - if it plays 30 fps screen-capture video, set 30 so the video is not retimed; if it is hand-drawn vector motion, 24 is fine and cheaper to author. Bumper: platforms re-encode at 30 or 60, so author at 30. The critical constraint is that frame rate is fixed at document creation; changing it later rescales every duration in the file and destroys the loop seam you tuned.
3. The client asks how the character stays consistent across three files. What do you commit to, and where do you warn them?
Read the worked answer
Consistency is a process commitment, not a file feature. Keep the character as symbols in art_source.fla, and re-import into each deliverable at two named art-lock dates, freezing copies after the second. Warn the client that the three outputs cannot stay in lockstep automatically: the rendered wall MP4 is frozen at encode time and cannot be re-skinned, the kiosk instance may need extra states and hit areas, and the bumper version will be simplified for a 6-second read at thumbnail size. Also warn that a symbol revised after the wall is rendered requires a re-render and a new contractor booking, which is why the wall's art lock comes earliest. Everything goes in the project spec so the divergence is deliberate.