[Request] Animated Crystal and Stadium sprites

[jonbarrow]

I have found a source that provides high quality, clean/transparent, animated gifs for all Pokemon found in Stadium 2 and Crystal, including shiny variants. The source offers them as a download organized by dex number as well. I plan to add support for these to https://trainercards.studio/ myself manually but I figured they might be appreciated here as well?

• https://bluemoonfalls.com/pages/general/stadium-gif-archive
• https://bluemoonfalls.com/pages/general/crystal-gif-archive

I also found https://pokemon.legends-station.com/?pkmn=stadium/gallery which has transparent renders from Stadium 1, but I'm not sure I like these very much. The renders themselves are fine but many of them are at odd angles so I'm not sure how usable they'd be in regular applications

[Naramsim]

Hi! Are those custom sprites? Or scraped from official games?

[jonbarrow]

They're not custom, afaik. The person who published them says this:

These official sprites belong to Nintendo/Game Freak and I do not own the rights to them, I merely mass converted them into GIFs and labeled them by both English species name and Pokédex number.

Which reads to me like they're not custom

Though I'm not sure where the animated Crystal sprites come from, it's been over a decade since I played that game but I don't remember the sprites being animated. But the disclaimer says they all belong to Nintendo/Game Freak so 🤷

The Stadium 2 ones are just renders of the models from the game but edited to be transparent GIFs, they're definitely not custom sprites

[Naramsim]

Hi! Pokemon Stadium is not even present in our API. We must first intoduce it.

Then we can add the animated sprites in the repo and map them in the API. So if you have time you could start by adding the Crystal ones and later implement the Stadium part.

[jonbarrow]

Pokemon Stadium is not even present in our API. We must first intoduce it

That sounds good to me, how would you like me to go about that? I'm willing to add it if I can get pointed in the right direction

[phalt]

Pokemon Stadium is not even present in our API.

Where possible I'd like to stick to the core series games because then the data structure gets very complex as games off the core series have very different mechanics. I know as the series grows that opinion is getting harder and harder to justify...

[jonbarrow]

Where possible I'd like to stick to the core series games because then the data structure gets very complex as games off the core series have very different mechanics. I know as the series grows that opinion is getting harder and harder to justify...

Can you clarify what constitutes "core" in this case? It seems like there's already several areas that stray from what, at least I would consider, "core" games, so this isn't super clear to me at the moment. Those being:

• Certain non-Pokemon sprites for certain spin-off games do already exist:
  • Colosseum
  • XD
• Certain Pokemon sprites for (what I believe are) spin-off titles/non-games entirely do already exist:
  • Dream World
  • Home
  • Official artwork
  • Showdown (which iirc does use custom sprites at times?)

So it seems to me like this rule has already been broken, and it's not clear where the line is drawn at? For example, would Pokemon GO be off the table (I have sprites for that title now too), and if so how is GO different than Home or Dream World in that regard?

I definitely understand why you'd want to limit the scope (different games, especially spin-offs, do have very different mechanics at times), but is there a reason why this applies to sprites as well? My personal main use case for this API is sprites, so that's all I'm really focussed on improving right now and it's possible I don't understand the full difficulty of introducing sprites for an entirely new game to the API. I may just be misunderstanding something critical to how this API is structured so forgive my ignorance, I'm genuinely just trying to get a better understanding of things here

[phalt]

Can you clarify what constitutes "core" in this case?

Main series games. And as I said:

I know as the series grows that opinion is getting harder and harder to justify...

Your comment:

but is there a reason why this applies to sprites as well?

Is actually a good one, I am not really against non-core series sprites - I hadn't considered that point of view.

I am mostly worried about the data structure getting way out of hand (it arguably already is!)

[jonbarrow]

Main series games. And as I said:

I know as the series grows that opinion is getting harder and harder to justify...

I did assume you meant this, I was just trying to get a better grasp as to what you personally were considering "main series", just so I had a better baseline. For example, I know people personally who don't consider the Let's Go games as "main series" games (even though I think they're wrong). I was simply trying to get a better frame of reference for my suggestions going forward, since I'm not really interested in trying to break any existing conventions here

I am mostly worried about the data structure getting way out of hand (it arguably already is!)

I honestly agree here. Having only used the API for a small amount of time and even with my limited scope, I think the data structure is pretty out of hand as it is

Would you be opposed to adding an additional endpoint for this in that case, with a different structure? Some of the things I found somewhat painful when working with the API to get the sprites are:

• null fields can be present, which leads to several (what I believe to be) unnecessary checks in the consumers code
• The way the nested structure is organized seems rather...messy, for lack of a better word. For example, the early titles have gray and transparent keys not present in other generations (which also has the issue of some missing combinations, such as the gray sprites always having white backgrounds and are never transparent, whereas the colored sprites don't really have this issue?), and similarly the later generations have icons entries not found in older generations for some reason (and lack other sprites entirely?)

If I could make a proposal, I feel like a /api/v2/pokemon/ID/media and /api/v2/pokemon-form/ID/media endpoint could solve things here? That way you can serve media (currently only sprites afaik, but trying to future-proof the name just in case) of the Pokemon, without having to change anything about its data structure

Edit: I forgot that PokeAPI also provides content like cries. I feel like moving that to a /media endpoint would also potentially make sense?

I would also propose that instead of the object of sprites like currently in use, a more easily consumable way to serve this would just be a list of media. That way consumers of the API don't really need to worry about variable-nested objects, updating their clients when new keys are added/removed, checking for null entries, etc. This is how I handle the data in my own app, I transform the sprites object into a list of images with various metadata, which makes it infinitely easier to consume in my application:

{
	"name": "bulbasaur",
	"display_name": "Bulbasaur",
	"images": [
		{
			"style": "pixel_art",
			"platform": "generation_vii_icons",
			"platform_display_name": "Generation VII Icons",
			"gender": "male",
			"gender_display_name": "Male",
			"shiny": false,
			"creator": "GameFreak",
			"url": "/images/pokemon/bulbasaur/generation_vii_icons_male.png",
			"preview_url": "/images/pokemon/bulbasaur/generation_vii_icons_male_preview.png",
			"dimensions": {
				"content": {
					"width": 20,
					"height": 19
				},
				"original": {
					"width": 40,
					"height": 30
				},
				"padding": {
					"top": 9,
					"left": 10,
					"bottom": 2,
					"right": 10
				}
			}
		}
	]
}

Taking some inspiration from how I transform things, a /media endpoint could return data such as:

[
	{
		"type": "sprite",
		"origin": "red-blue",
		"shiny": false,
		"gender": "male",
		"facing": "front",
		"transparent": true,
		"grayscale": false,
		"url": "https://raw.githubusercontent.com/PokeAPI/sprites/master/sprites/pokemon/versions/generation-i/red-blue/transparent/1.png"
	}
]

And so forth, fixing all the mentioned issues

I feel like this would also serve as a viable solution to this issue, without needing to change any of the existing data structures https://github.com/PokeAPI/pokeapi/issues/1281

[Naramsim]

These suggestions are all all welcomed and important. A key fact remains, we need someone to actively work on a V3 version of the API. We cannot alter too much the current API V2 since it's used by so many people.

We should entirely rework the pokemon, species, forms and then add in all these ideas.

[phalt]

I am in agreement with @Naramsim here.

[jonbarrow]

I also agree, I had the proposal in mind for a v3 update. Was just trying to gauge interest in the idea, not necessarily make a formal proposal for the current API

Is there anywhere that outlines the general requirements/ideas for v3? I wouldn't be opposed to trying to participate in that if so

[Naramsim]

We have an issue dedicated I think. Try looking for it 🙂

[Naramsim]

https://github.com/PokeAPI/pokeapi/issues/1086

[jonbarrow]

Try looking for it 🙂

I can't tell if this was supposed to be rude or not, to be quite honest. I was simply asking for direction as I figured it was easier to ask the people in charge, rather than to go hunting for something that might not exist, may be out dated, etc.

[Naramsim]

Not at all rude! Rather I was happy that you are contributing a lot! It's rare to find people that contribute spontaneously to this project. Mainly we get flooded by issues.

I'm sorry if my reply turned out to be rude, it wasn't supposed to be.

After my reply I even posted the link to the issue you were looking for, saving you from looking for it