I don't pretend to know what this persons work flow/load is like. I'm pointing out the hypocrisy in claiming this person did something the devs couldn't/wouldn't(with "surprising ease" mind you). When it's clearly not anywhere near finished or even playable.
Again that's not even talking about the fact that he is doing this outside of a cooperative work environment where decisions are sometimes made for you.
It's mostly the separation they do between "research" and "implementation". Once technical research has been done (by creating a "proof of concept"), it is treated as a solved problem, and only the boring implementation work remains, which can sometimes be shared between several people.
The modder gave some insights about what they are actually doing in practical terms, the separate points of the process.
The modder says that the initial Technical difficulty of bringing functional Pokémon from LGPE is low. Quotes:
- « This was a model proof of concept, because everything other than models/anims is easy. Stats are "edit six bytes". The game already knows omastar exists, it just stubbed some values to zero that need to be copy/pasted back from an older game. » (source)
- « The fact that people seem to think stats are hard is fascinating to me.
- Stats are six bytes at a fixed location in one file -- the only reason I didn't bother was because I thought it would be well understood they're trivial...
- Moves are just a copy paste from USUM... » (source)
- « Actually, in battle animations are fully functional, and this was copy pasted so required basically zero effort. » (source)
- « The kanto Pokémon are basically free because let's go copypaste works, and the rest can be converted from usum once tools are made. » (source)
The "relative ease" is about the process he did.
- « About an hour to reverse the model table flatbuffer format, and then like 5 minutes to copy/paste the files + edit with PKHeX. » (source)
One hour of reverse-engineering, meaning that this part doesn't have to be redone.
What has to be done is automate the process of adding animations. Also an one-time work.
- « Another clarification: lots more work needed for anything people would want to use.
- Obvious action items:
- -Produce flatbuffer schemas to add new animations. » (source)
But for older games, there remains to create an automated converter for the models and animations. Difficulty unknown.
- « -Produce converter from BCH to GFBMDL, to use USUM models (no converter exists right now). »
However, they won't have the "GameFreak handmade updated textures" that are one of the noticeable change of the models.
- « -Upscale old pokemon textures. »
- « -Textures could probably use waifu2x or similar for a first pass? » (source)
You are right to say that modding doesn't have the same Quality Insurance as official development.
There will be many more reused animations and default values to make things work.
- « the omastar I imported works fine in camp + the overworld. Dynamax works fine with an animation renamed to allow it to re-enter the ball. » (source)
Some animations could be sourced back from Pokémon-amie etc. from 3DS games, or re-use generic-looking existing animation fitting the situation. (Just like how GF themselves used the "buff attack" animation when Pokémon get out of their Ball in LGPE.) There's no creative work involved (unless the communauty starts creating the missing animations rather than use the closest one from the existing ones).
The textures might also look off due to the different style used. There could be some automation/intelligent algorithms involved to produce something useable, but that's probably the part that GF or Creatures were tweaking by artists.
I nearly forgot but some moves animations are missing too,
since several moves were cut.
- « The old move animations are a much harder problem. But I'm not so concerned about those, it's really only the Pokémon that I care about. » (source)
Maybe they could be replaced in the data by similar existing moves, or be ignored entirely. (Or other modders could bring them back!)
So yeah, bringing all the Pokémon is "easy" if you don't take in account artistic polish. Or ignore new company-wide policies.
To wrap up, what the modder says is that:
- the technical hurdle of bringing LGPE Pokémon models is solved, it is just a matter of implementation/creating the tools to allow for automation which is always slow.
- the hurdle of importing a new Pokémon in the data is mostly solved trough Pkhex. Stats, entry ID, models and most animations are solved. Left to decide which animation to reuse when missing (plug holes in a way that doesn't stand out compared to other animations). And decide what to do with missing/cut moves (replace with similar?).
- the hurdle of bringing 3DS Pokémon is currently not solved, due to the difference in models format (must reverse-engineer the format and build a converter). And those won't have the same texture style (unpolished).
The modder says that building the tools to allow everyone to inject Pokémon in their game in a way that fits is going to be his next work. It is not about difficulty of implementation there. But easy to implement doesn't mean quick to implement. It's just "work to do", rather than groundbreaking exploration. They are counting on the community to do some of the cleanup later.