So, far as I know, using atlases/texture sheets to import sprites for animation work is usually the way to go.
For simple character animations and such, you can easily fit all your sprites into a single sheet.
But what about large, hand drawn full-background animations?
Example: you have a hand drawn animation where a soccer ball bounces around the entire (2D) background.
The ball also affects elements of the backgrounds, in different positions.
That is, each frame would need to be as wide as the entire screen.
At ~24FPS, you’d never be able to fit the hundreds of frames into a reasonable amount of sprite sheets.
Plus, that’s quite a lot of memory for a single animation.
One alternative I’ve tried is to export such an animation to a video format.
MP4, or WEBM for animations with transparency. But this seems a finicky solution.
I have had issues with frames being skipped/timing and 2D lighting using the VideoPlayers, while I never had such issues using Animators.
TLDR
I’m extremely curious how other devs deal with importing large-size hand drawn animations that wouldn’t fit into a reasonable number of sprite sheets. Can anyone point me in the right direction?
Sequence consisting of hundreds of arbitrary full screen frames is a video, no way around it. If there was a better solution than existing video formats, anyone dealing with videos would use that. Only way of sidestepping that is if your stuff fits very specific constrains with regards to art style, content, creation process and willingness to adapt your workflow and artistic vision to match the tools. That’s something you need to plan ahead before drawing anything.
Just to enumerate the potential aproaches (each with major drawbacks):
-
Avoiding large full screen animations for stuff that isn’t critical to your game
-
Video → good for cutscenes and other non interactive elements, not so much for everything else
-
skeletal/armature animations (spine, unity builtin stuff, or other external tools) even for 2d → not suitable for pixelart stuff ok for other art styles. Doesn’t have to be purely skeleton based, you can still have multiple hand drawn frames for more expressive characters
-
Split the scene into multiple smaller objects where each object is animated separately potentially with much smaller amount and size of frames. Most of the time whole screen doesn’t change anyway, only some smaller objects are moving indepentdently. It’s done even in animated movies, although there it’s mostly for the sake saving animator time and fact that unless camera moves stuff like buildings and furniture also doesn’t move, not because video size was an issue. The example you described with background that contains with ball bounching around could be split into something like this: static full size background image, smaller looped background objects (spinning windmill at distance, tree or grass chunk swinging back and forth, water moving back and forth, bird flying …), the ball bouncing around. For ball you can reuse few smaller animations of ball streching and squishing as it hits the stuff, but animate the general movement across screen using interpolation within Unity that way each frame is only as big as the ball. Background objects can have singificantly less frames than whole scene (as much as it takes too loop), but if their lengths are different total repetition period can be quite long. Assemble the whole animation from separate animated objects within Unity Editor. Downside is that whole animation process needs to be adjusted to suit the tools, you can’t just draw whole frames in software of your choice. Potentially everything on the screen can slightly move as long as each object doesn’t have too many frames. Each object doesn’t need to have single animated loop, you can have few different animations for each object and assemble them randomly or depending the stuff you want do display.
-
vector based drawings and animations (the stuff people used to do with Flash) → not really doable with Unity or as far as I am aware or any modern and maintained game development tools in general. Even shipping flash player itself isn’t much of an option now, from what I understand Adobe doesn’t maintain it anymore and legally distributing it is problematic. There people using this drawing style, but in the final form it still gets rasterized potentially in combination with skeletal animation tooling and some special shaders to keep the vector art looking sharp.
-
If something is very important for the game like final cinematics, main character or final boss of your game and you don’t want to change workflow and skills of existing artists you can somtimes get away with some amount of big animated frames. Single 1920x1080 frame takes roughly 1920x1080*4 (bytes per pixel) / 4(fixed ratio texture compression) = 2MB. If you have a serious few GB game you could dedicated let’s say 300MB to it. It could be (barely) reasonable both from the perspective of disk space and also dedicated VRAM of dedicated GPU. Even low end dedicated GPU will have at least one or two gigabytes of VRAM. That’s assuming rest of your game can justify taking few GB of hard drive and not running on builtin GPU. This approach won’t work for mobile or 1$ indie games. 300MB / 2MB = 150 frames. At 25fps that’s 6s seconds or animating on twos 12s. Enough for short ending cutscene or a couple of main character moves.
-
At the end of day there is only so much hand drawn animations you can draw (regardless of team size and budget). So there will be some amount of static background images, interpolated movement, reused parts. Handle as much of simple translation, scaling and rotation within Unity as possible. Think about it ahead of time before drawing a bunch of stuff and understanding that stuff you draw is inconvenient to use in game.
3 Likes
Thank you so much for the elaborate reply, Karliss!
I’m surprised this appears to be such a tricky subject - I figured I was missing something very simple.
Just to make sure we’re on the same page, let’s look at that ball example again.
Say we want the ball to bounce against the wall, break a vase, then hit the ceiling, break a light bulb or whatever, and then fall down and roll across the screen.
What I’d need to do (aside from use a video format):
-Create a sheet for the vase animation (doable)
-Create a sheet for the the light bulb animation (doable)
-Create a sheet for the ball rolling across the screen (I don’t think this would fit in a sheet)
-Call each animation (Animator) at the exact right timing to synchronize everything (sounds difficult).
I can’t imagine old hand drawn point and click games etc. go through a process like that for a single animation.
Is that the only non-video approach for large hand drawn animations?
Am I missing something?
You wouldn’t draw the frames for the movement across whole screen. Only for the ball stretching/squishing and maybe rotation if you ball has unique pattern for which rotation in 3d is recognizable. Each frame would be more or less the size of ball, so sprite sheet would be quite small. The movement across the screen would be done in Unity Editor.
Synchronizing timing shouldn’t really be a problem if you use the tools correctly. Since you can preview, scrub through the timeline and tweak the timing of each object exactly the same way you would do it in any other animation software. You don’t have to manually call each part from code.
Have you looked at the timeline feature? It can be useful to assemble more complex sequence from individual reusable animation parts in situations where you don’t want to put everything in single animator (for complexity management reasons or because how animators affect objects when the cutscene isn’t playing)
1 Like
Thank you, that makes sense!