Major updates to Pokésprite

[msikma]

Hi all. There's quite a lot of people who have been waiting for updates to this project, and none have been made for quite some time. I'd like to announce that I'm finally going to do something about that.

It's been a bit difficult to figure out what would be the best continuation for this project, given that it's got quite a bit of legacy in it and I really just want to clean it all up and restructure it. At the same time I don't want to break anyone's use of the current images where they are right now. So what I'm opting to do is to make a new main branch (this repo is so old it still uses master), in which we'll completely restructure the project, and then master becomes legacy.

The biggest issue regarding the actual project content is that it seems Game Freak seems definitively done with using pixel art for their box sprites in games going forward, opting to go for higher resolution illustrations instead. Plus, there's now so many Pokémon that they don't include all of them in the games anymore, which means we end up not having a full list of sprites.

To accommodate this problem, I'd like to start making use of community art projects designed to fill the gap. One of these is the National Pokedex Version Delta project, but other projects can be added as well if their authors would like it.

The goal of Pokésprite was always to provide a nice looking and consistent spritesheet, something that works for every Pokémon and variation in regular and shiny form and looks cohesive all across. With Game Freak ending their long run of pixel art sprites we can't do that anymore off of just official sprites, so I'm hoping that with unofficial projects we can keep this going for a long time.

Long story short, here's what the basic plan is:

• Figure out a good structure for the project going forward
• Work on a new structure for the database JSON file that properly accommodates multiple projects
• Write code that can automate the inclusion of new sprites from the Delta project from their spreadsheet
• Migrate the old sprites from the current project to the new format

I'll be working on this and giving updates as I go along.

I want to emphasize that my plan is not to get rid of the official Game Freak sprites. They'll still be a part of the project going forward.

When I started this project all the way back in 2014, the latest game in the series was Pokémon X/Y. At that time I did not foresee that I'd still be working on this project by now, much less that I'd have to account for multiple different styles and generations. Really, all I wanted was an easy to use sprite sheet for my own trading purposes! Since there were no shiny versions of the box sprites I decided to just make them myself. Other people started using my work, and I ended up keeping the project up to date even long after I personally stopped using it for anything.

At this point it's difficult for me to keep doing this because there's just so much work, and it's really too much for one person to do in their spare time, especially since I'm also quite busy with other projects besides work. So I'm really happy if we can continue this project with community work supplying the actual sprites.

If you have any ideas or suggestions, feel free to post them here.

[Or1onCL]

Hi, a few hours ago @CentroLeaks posted the sv sprites for most of the pokemons (normal, mega, iconic gender differences).
Attached link.
CentroLeaks

[sora10pls]

Here's a proper dump of said sprites, not in a montage.

[shankarsivarajan]

Suggestion: better handling of variants. If I wanted to find the sprite for something like [pokémon name]-female-[region]-[form]-mega-shiny, it's very hard with the current flat structure of the sprite directory. More hierarchy would help, as would a database listing which variants exist for each pokémon.

[shankarsivarajan]

Please don't use master vs main as your version control. If you're making breaking changes, use semantic versioning, and call the new one pokesprite-v2.0.0 (or something like that). Alternatively, issue a deprecation warning and actually break it, calling the new version master and renaming the old version legacy.

[koenigderluegner]

Please don't use master vs main as your version control. If you're making breaking changes, use semantic versioning, and call the new one pokesprite-v2.0.0 (or something like that). Alternatively, issue a deprecation warning and actually break it, calling the new version master and renaming the old version legacy.

There are at least two reasons behind the change to main: a deprecation warning wont help as many, many resources link directly to the raw urls of this repos files. Changing the structure of the master branch will break all those resources as they cant receive a deprecation warning (example: spreadsheets in many pokemon communities)

Second: the term master itself has some historical meanings why its common to be be 'main' now. 'main' is the default in new projects and this one will just go with the rest.

AFAIK a new handling of files and versioning will come anyway - just including the name change

[shankarsivarajan]

Surely no one is relying on the master branch of someone else's repo being stable? If there are no tagged release branches, the obvious thing to do is to fork a copy. Efforts to maintain backwards-compatibility here is solving a problem that doesn't really exist: any project that links directly to the master branch is clearly signaling that they're actively maintaining their application, and can easily adapt to any changes upstream by changing links as needed.

And the master vs. main thing was a passing American culture-war fad from a few years ago, mostly only expressed by a few corporations, primarily Google, Facebook, and Microsoft, which owns Github, and so changed the default. Again, this is trying to solve a problem one has imagined into existence.

The natural thing to do is just release a version v1.0.0 or legacy or whatever, so anyone who wants to keep their current version can use that, and then update the current branch, called master, main, updated, new, v2.0.0, or whatever else one wishes.

[koenigderluegner]

As I said, a lots of communities do rely on master with their spreadsheets for example, most of them are not tech-savvy enough to figure out whats happening when all their sprites disappear.

Also there's always the possibility for you to make a fork and just do the versioning yourself, if you're not satisfied with how it goes.

[shankarsivarajan]

Well, he did ask for suggestions, and "don't implement the abominable version control system you're planning" is mine.

[koenigderluegner]

And that's absolutely fine. I just tried to tell you why the decisions were made.
There already is versioning, current one being 2.7.0.
And as I said before

AFAIK a new handling of files and versioning will come anyway - just including the name change

There most likely will be versioning going further - just trying to not mess up hundreds, maybe thousands of other resources for problems one has imagined into existence ;).

[msikma]

Yes, unfortunately I don't see a better way to do it at the moment. Although I understand your misgivings about it.

It's a requirement that we don't break the existing use of the project, and people are massively linking to the files directly on the master branch, so we can't really touch it. In fact, that's why there's tons of legacy files under /icons/pokemon as well—that's where the box sprites were originally located before being moved to separate directories in the root. Breaking this structure would cause a lot of trouble for a lot of people, so I want to avoid that if possible.

It's worth considering that a lot of people using these sprites are not application developers and don't follow the standard way of using a repo, so that's what led to the current situation.

But I think it's OK. master is a legacy branch name to begin with. We'll set the main branch to main so that that's what you'll see when you visit the project on Github or clone the repo. This will keep all existing links intact. The only thing is someone may be a bit confused when they look at the list of branches, but I think most developers will understand what happened at a glance. The master branch will also get a proper notification in the readme that it only exists for legacy purposes.