Design Frame-by-frame animation and alternate character colors

Khao

Member
Hey.

So I'm making a multiplayer game with frame-by-frame animation. Characters are super simplistic, but with complex, detailed animations with a large amount of frames. Despite using simple characters, it's an HD game, with high-resolution sprites, basicaly, I want the game to feel like a cartoon. Character actions are kind-of comparable to what you'd expect in a fighting game, walking forward, walking backwards, jumping, a few different attack moves and special moves, that kind of thing.

Soooooo the thing is that, much like a fighting game (this is not really a fighting game, but similar in structure) I want to have multiple color-palettes for every character, in case more than one player chooses the same character. And I was wondering what would be the best way to do this. Obviously, I shouldn't just have the duplicate the sprites and change the colors for every single alternate color palette because texture space. So I thought of a system that I think could work, but I'd still like to know if there's a better way to do it.

This is a character.



Buuuuuuut internally, that's not one single sprite. This is how I'm actually handling it.



I have five separate sprites total. One large sprite that has only the outline, and four separate sprites in half the resolution containing the shape of each color in pure white. Then, when drawing the character, I draw the four color sprites blended with color variables defined beforehand, and the outline on top. The color sprites are a lower resolution, but since they're completely flat and have the edges covered by the outline, it looks exactly the same as if they were of a higher resolution. And it works! So if I want to have multiple color palettes, all I have to do is give the color variables different value and I'm getting more sprites for free. Yay!

The problem?

Well, like I said, the game does use complex, detailed animations with a large amount of frames. I'm only just starting to create the animations, and I still mostly have place-holders in-game. But my jumping animation alone already has 15 frames total, and I really don't want to simplify it in any way.


The character also has 3 separate attack moves and I'm anticipating them to have something like 7 frames each. I'm gonna have two different walking animations, probably with 8 - 12 frames. And there's a few more animations for special moves, and in the future, probably for extra details like victory/defeat animations, or even just to make transitions feel better, like an animation for landing in the floor.

All those animations probably wouldn't be such a problem on their own, but with the color sprites, the texture information is basically doubled. And that's just assuming that every other character is going to have four colors! I may very likely want to use more colors with other characters, which is going to fill up textures much faster. So even though this may be fine right now, I'm worried that it'll become a problem in the future.

Which is why I made this thread. Do you guys think this will actually become a problem? Or is this actually a perfectly safe idea? If I do this, I'm probably going to need a full large texture page per character, potentially more than one page for some characters, and I'm gonna be loading up to four characters at once. Is this too much? Or do you think it's manageable?

And if it is too much... Is there a better way? I'd really rather not save space with animation detail, because I have high hopes that the animations could become one of the game's most visually appealing features, and while I could decrease the sprite resolution without losing to much detail, I have dramatic zoom-ins in the game from time to time, and I'd rather have sprites not lose definition when that happens. I've seen color-swapping shaders flying around the place, but I've only seen them work with pixel-art sprites, not with big sprites with anti-aliased edges with a potentially unlimited amount of colors. I'm hardly an expert on shaders though, so I don't know either way.

Aaaaaaaaaaaaanyway, I think I've said enough already. Thoughts?
 
Last edited:

Niels

Member
Watch this:

Fluid animations don't need to have a lot of frames, it's a matter of having strong keyframes and your brain fills in the missing movement.
 

Morendral

Member
I think a shader or even draw_sprite_color can do what you want.

Also i love your art style, and the animation looks terrific
 

Khao

Member
Fluid animations don't need to have a lot of frames, it's a matter of having strong keyframes and your brain fills in the missing movement.
Thanks for the link, but I've watched it before, and I've definitely taken advice from it! I've actually "studied" some of Skullgirls's animations in the past, and their framecount is comparable to what I'm doing. I'm already handling things in a similar manner than described on the talk. For example, I made a point in making all my attack animations feel fast and responsive, so they only have a single frame of anticipation and go right into a smear with a 6-7 frame total. Skullgirls' standard attacks have anything between 5 and 20 frames (perhaps more) depending on the complexity of the move and how fast they need to be. 15 frames for a jump is also not a lot if you compare it to jumps in Skullgirls, and my planned 8-12 frames for walking is half the amount of frames that some of Skullgirls walking animations have. I know I said I'm using a "large amount of frames", but it's far from being an unreasonably large amount.

I appreciate the advice, though! I even took the time to watch the video again, hahaha. Definitely a lot of great info there.

you seems to use a very limited number of color, that should be a good usage case for something like : https://marketplace.yoyogames.com/assets/1661/retro-palette-swapper
Got excited for a second, as it seemed to be exactly what I needed. But the description specifically states that it's only really compatible with "retro" graphics (assuming that means pixel art), and doesn't work with the "interpolate colors between pixels option", which is a no-go. I do use few colors, but they're heavily anti-aliased, and definitely not consistent between each frame. Which would make that thing almost impossible to manage if I understand what it's doing correctly.
I think a shader or even draw_sprite_color can do what you want.

Also i love your art style, and the animation looks terrific
Definitely thinking that shaders might be the better solution. Guess I need to do a bit more research.

Also thanks! This is probably the most ambitious project I've done by myself in terms of graphics, so I'm both excited and terrified about all the stuff I'm gonna have to do to make it work. A single person enjoying the style feels like a huge breakthrough for me, haha.
 

kupo15

Member
I was thinking similarly with my project also. Splitting it up seems cleaner but will take too much texture memory. The biggest issue I'm currently finding is the pixels around the lines and other colors getting interpolated especially since my assets are being made at a high resolution and exported down. I understand how to use shaders to palette swap a single layer but not having pixel perfect retro art style is causing some issues. Perhaps I'm thinking too hard about this and there is an easier way?
 
I still remember a Youtuber animated all 60 frames of animation. I think you only need a new frame of animation every 12th of a second. It will save you a lot of work.
 

Rayek

Member
I did some testing myself. What seems to work well is preparing non-antialiased indexed coloured high resolution art at twice the size you would diplay it at, import that, scale down by 50%, and allow for interpolation of colours between pixels in GM. My test consisted of a 1920x1080 screen size.

It should be relatively easy to target the aliased indexed areas of colours with a shader like this one:
https://gamedevelopment.tutsplus.co...-dynamically-swap-a-sprites-colors--cms-25129

Advantages of this method:
  1. high resolution art that is nicely anti-aliased by GM's screen drawing routines.
  2. asset quality is very nice either at upscaled or downscaled window size. 1280x720 looks just as nice as 2560x1440
  3. tiny, tiny files sizes. A 2300x1600 test file with a couple of test colours compressed down to a mere 76kb PNG
  4. each colour can be easily targeted with a shader
  5. simple asset workflow.
Drawbacks:
  1. high resolution assets still take up a lot of video memory: four times as much as an asset natively designed for 1920x1080. This may impact performance on lower end machines.
  2. asset generation software must support non-aliased asset workflow. Not all software does.
  3. artist must be very careful with picking the correct colours, and colour palette control is very important. Probably best to work in an app for animation that offers rigid colour palette control with aliased options, like OpenToonz or ProMotion NG. I wouldn't want to work in Photoshop this way for example, in my opinion.
  4. sprite sheets are out of the question. Or at least, it depends on the size of the animated assets, of course. Large on-screen animated characters taking up half the screen: too large sprite sheets, I think.
PS I've just done the same thing in an alternative game engine which, I discovered, supports lossy video ram compression of assets with a quality control slider. The video ram savings were more than considerable: instead of 19mb, only 4.8mb was taken up. I understand this not only saves video memory, but also improves performance between the bottleneck of GPU and Ram.

Because of the nature of this method relying on the screen drawing to take care of anti-aliasing automatically, the quality is hardly affected by it, even at quite low quality settings. The method is similar to saving large JPG files at very low quality for web pages, and then scaling these down to remove the visible artifacts. It works really well in this case too!

So I tried to find a similar option in GM, but failed to locate it in the image settings. Where do I go in GM to control an asset's video memory compression? Or is this done automatically?
 
Last edited:
Top