[Sprite Refactor] Pokemon Sprites filepath optimisation Discussion

[chaosgrimmon]

Discussion thread for suggestions to improve how assets, particularly Pokemon sprites, are stored on the repository, and packaged to be sent to the user and converted into Phaser Sprites.

[chaosgrimmon]

From @pom-eranian:

speaking of mobile refresh, there is a lot of duplicated garbage in json anim files for both pokemon and battle-anims. all shinies use a duplicate json, and all forms have a specific one too.

[chaosgrimmon]

I'd personally want some more insight into how animations are stored and cached.

It's very possible that the .jsons aren't actually relevant from a cache perspective— that they're only ever used when converting the spritesheet .png into a Phaser Sprite. After that, hypothetically, each frame of the animation is fully trimmed and shaded. Thus, loading the .json into memory repeatedly would have no long-term space impact, since the end result is always going to be one Phaser Sprite per Pokemon, regardless of whether they used the same .json or separate ones.

Of course, it's possible that they do get stored in cache for no reason, and because they're never used again after initialisation, that's an immediate source of cache savings to manually garbage collect.

[chaosgrimmon]

Would it save on server costs to reduce the amount of data required by the game? Without a doubt, and it'd surely add up over time. No matter what, it'd make sense to try to avoid sending over the same animation frame data repeatedly across multiple files.

I do have to ask, though, if that's what's actually happening.

Is every single Pokemon (and form) actually loaded and created on startup? Or are they only requested and delivered on demand?

If they're only procured when a user encounters them, then I'm not sure if there's a significant excess cost to the system in its current state. That is to say, if the only time an animation .json would see reuse is when a user manages to encounter multiple shiny tiers of the same Pokemon and form in close succession, I would not consider that a priority to address, given the likelihood of that occurring. (Assuming the biome continues to change frequently in Endless, where the shiny chance is significantly higher due to the ease of maxing out on Shiny Charms.)

[chaosgrimmon]

But say that sharing .jsons would help, and meaningful improvements would result. What should the end result of a refactor look like?

• Every sprite of a given formSpriteKey, directional facing (front/back), and animation type (animated/'static') should use the same .json. This would be the normal non-shiny, the official shiny, and Type 2 variants. (Type 1 variants already use the non-shiny's .json, of course.)
  • This requires all shinies, non-shinies, and variants to be using the exact same spritesheet. Certainly possible, and preferable, but isn't actually currently the case.
  • I know for a fact that Diancie suffers from this, and surely other cases exist. It probably makes sense to loop in the Art Team or another source of feedback to resolve those conflicts.
  • How might this indicate that the .json should be used across multiple forms?
  • Would it need some kind of marker in the Pokemon-Species declaration to flag that the spritesheets are named after the forms, but the .json is used for all of its forms?
  • Or does it make more sense to assume that to be the default, if the game can't find a .json with the more-specific, form key name?
  • This might be easier if each Pokemon/formSpriteKey got its own folder. In this scenario, instead of having default front non-shiny spritesheets and .jsons directly in \pokemon, as well as additional spritesheets and .jsons distributed throughout the subfolders for \back, \shiny, \exp, and \female, to name a few, all of the Pokemon's spritesheets would be in a single folder. Inside that folder might be subfolders as necessary, but the animation .json would be more centralised, relative to each spritesheet that'd use it.
    • This would make it easier to "plug-and-play" simple changes for individual Pokemon, since everything pertinent would be guaranteed to be within that folder, and easily zippable as a result.

[chaosgrimmon]

Alternatively, it turns out to be the case that the hardware limitation is not circumventable. Mobile users simply don't have the hardware to support loading spritesheets in their current form in the quantity that PokeRogue expects.

The only way to make it manageable, then, would be to reduce every single sprite. That is to say, add a toggleable setting to only use still images, with no animated Pokemon at all. Further savings might then be made possible, since there'd no longer be a need for the animation .json, the game would simply know to render the static image as-is directly.

[chaosgrimmon]

Again, I don't know what the correct course of option is, without knowing how the game works behind the scenes. It's very possible it does something entirely different, necessitating an entirely different course of action.

For instance:

This value is hard-clamped to 16 for performance reasons on Android devices.

makes it seem as though mobile devices are simply not expected to perform at the level of a computer, to the point of causing the issue where palette-swapping variants don't show up on mobile.