Article: [Updated] Battles visually lacking in Pokemon Sword and Shield

A long article I wrote on battle animations. I hope it's of value, and not just because it also has some cute gifs. :V

A few notes:
- article showcases some of the new animations spotted for Swsh
- it also discusses cases of good animation since XY
- the topic here is animations, not e.g. the pokedex.

Let me know your thoughts and if there's anythng else to be added to the discussion!

Really interesting and well-researched article. I hadn't seen some of the spinoff title battle animations until I read this, and it really gives you an idea of how different they are to the main series games. Sableye looked awesome. @_@

This is a very good article that emphasizes how much more effort spin-off companies put into the games than GF does.

The case of Blastoise as usual is quite baffling, a higher form of "Flamethrower coming out of a Pokémon's butt", and from my days of programming it looks like something that wouldn't take more than 8 minutes of dev time and about 12 bytes per Pokémon model to handle (since it has to he handled at the skeleton level: which node represent the part of the body that fires).

It's good to see BR, Stadium and Colo comparisons all together, there are very few cases where they all come to be representative of a subject and this is a very well put case.

the other day, i was starting to think about how the animations for these moves are really...uninspired, to day the least? obviously we haven't seen like every move known to man, but it's like. i look at some of these and i'm like yeah that looked better in colosseum/gale of darkness on the gamecube. like i get why it would be taxing to ask for very individual animations like what we got with the likes of stadium and the gamecube titles i mentioned, but it does seem bleh to have each pokemon going at their attacks in the same way.

no one asked to know this, but as a kid, i would imitate the pokemon's unique animations all the time. just kinda gives an idea of how fun they are. lol

One of the biggest reasons I've always preferred 3D models over sprites is because of the potential they have to be expressive. It's disappointing to say, but it has to be said that Game Freak certainly fell well short of what they could do when it came to battle animations. It almost seemed as if it wasn't really an oversight per se, but an intentional decision of some sort because they certainly took the time and effort to make unique models and animations for every single Pokemon as far as Refresh/Aime goes.

I don't think any of us would really ever know the reasoning unless Masuda or Ohmori gets interviewed about it (if they haven't, already). It's just that these battle animations really leave something to be desired if these are really the 3D games that are supposed to come on the heels of games that older fans loved like Colosseum, XD, and Battle Revolution.

Perhaps Game Freak is in more of a time crunch. I guess it's hard to say, but it's a letdown all the same. That doesn't mean I'll enjoy the games less or anything, but it'll certainly add that extra touch if there were unique move animations. Then again, given the number of moves that exist out there these days in comparison to say, how many moves existed when PBR existed, it certainly seems like a lot more of a daunting task that Game Freak may have felt like it wasn't worth prioritizing.

I still feel like sprites can be more expressive. Game Freak's using models that are… much less, and they're reusing the same animations for those models. They've done better.

Sheep said:

Really interesting and well-researched article. I hadn't seen some of the spinoff title battle animations until I read this, and it really gives you an idea of how different they are to the main series games. Sableye looked awesome. @_@

Click to expand...

Sableye went up several points in my interest when I saw it do that back when I was playing Colosseum. One of my favourite animations from that game.

Venia Silente said:

This is a very good article that emphasizes how much more effort spin-off companies put into the games than GF does.

The case of Blastoise as usual is quite baffling, a higher form of "Flamethrower coming out of a Pokémon's butt", and from my days of programming it looks like something that wouldn't take more than 8 minutes of dev time and about 12 bytes per Pokémon model to handle (since it has to he handled at the skeleton level: which node represent the part of the body that fires).

It's good to see BR, Stadium and Colo comparisons all together, there are very few cases where they all come to be representative of a subject and this is a very well put case.

Click to expand...

Thanks! I appreciate it.

Blastoise's issue in the main games is indeed disappointing. Interesting that it sounds that easy to do properly...

colours said:

Perhaps Game Freak is in more of a time crunch than Genius Sonority is when developing Pokemon games. I guess it's hard to say, but it's a letdown all the same. That doesn't mean I'll enjoy the games less or anything, but it'll certainly add that extra touch if there were unique move animations. Then again, given the number of moves that exist out there these days in comparison to say, how many moves existed when PBR existed, it certainly seems like a lot more of a daunting task that Game Freak may have felt like it wasn't worth prioritizing.

Click to expand...

I find it hard for it to be a time crunch thing when there are many, many moves and animations in battles still looking the same as when XY came out. =(

Laslow said:

I still feel like sprites can be more expressive. Game Freak's using models that are… much less, and they're reusing the same animations for those models. They've done better.

Click to expand...

In Amie/Refresh they do have some good expressions and animations; it's just mostly remained in there alone.

bobandbill said:

Blastoise's issue in the main games is indeed disappointing. Interesting that it sounds that easy to do properly...

Click to expand...

No problem.

And see: it sounds easy, if you do properly. But if it was done improperly to begin with, the effort to fix it is oftentimes just not worth the hassle.

For example, in a properly done way, the skeletons and the move animations live in an environment where they are aware of each other, so that they can pose and reposition themselves to "look good for the camera". In this case most if not all what you have to do is to "tag" the nodes that represent eg.: the mouth, or the tip of the cannon for a Blastoise, and then file which camera positions visualize that combination properly. For completeness, tagging a Blastoise's cannons would only require tagging two nodes, each with an index that marks them as firing points and with an index that identifies the kind of animation that connects to them. In a 3DS system architecture this can be done in 2 bytes per index, for a total of 8 bytes (shorter than a mon's nickname) for the concept "Blastoise + water attack".

But in the improper ways, for example if skeletons and animations are not aware of each other or if either of them is not aware of the camera, or if your attack animations are "hardprints", not scalable or rotatable, fixing it means potentially having to fix half of your entire battle engine's visual core, not to mention fixing the models and or the animations themselves.

In Amie/Refresh they do have some good expressions and animations; it's just mostly remained in there alone.

Click to expand...

That sucks doesn't it. In X/Y spending time making my mons look happy and curious was one of my favourite ways to spend the bus ride.

Venia Silente said:

For example, in a properly done way, the skeletons and the move animations live in an environment where they are aware of each other, so that they can pose and reposition themselves to "look good for the camera". In this case most if not all what you have to do is to "tag" the nodes that represent eg.: the mouth, or the tip of the cannon for a Blastoise, and then file which camera positions visualize that combination properly. For completeness, tagging a Blastoise's cannons would only require tagging two nodes, each with an index that marks them as firing points and with an index that identifies the kind of animation that connects to them. In a 3DS system architecture this can be done in 2 bytes per index, for a total of 8 bytes (shorter than a mon's nickname) for the concept "Blastoise + water attack".

But in the improper ways, for example if skeletons and animations are not aware of each other or if either of them is not aware of the camera, or if your attack animations are "hardprints", not scalable or rotatable, fixing it means potentially having to fix half of your entire battle engine's visual core, not to mention fixing the models and or the animations themselves.
.

Click to expand...

I'm no animator, but from my limited experience/understanding. wouldn't it just be a matter of adjusting the coordinates of the particle nodes to match those of the camera?

The camera moves statically during attacks meaning that their location is not a dynamic variable within the engine, rather it is simply unique to every Pokémon. Therefore, it does not seem like a hardware or labor restrictive problem.

Based on my experience modding The Witcher 3, that game has far more unique animations, and a fully user controlled 3D camera as well, and this all from a studio with far fewer potential resources than GF. From a hardware perspective, the 3DS is capable than far, far more than what the Pokémon games utilize, and the switch even more so.

I don't mean this sarcastically at all, I am genuinely curious about what you said, as you seem to know a lot more than I do, please clarify if I am wrong.

Phyrrhic said:

I don't mean this sarcastically at all, I am genuinely curious about what you said, as you seem to know a lot more than I do, please clarify if I am wrong.

Click to expand...

Hey, it seems you would know more than I do! You modded The Witcher 3? You mod videogames! That's already an Awesome™ skill tier to have.

My field is not videogames programming so I don't really know the specifics of how things are done in the industry, buy my fields do are computer systems analysis and integration, so I was taught the thought and the tools behind how to make systems work, work correctly and work fast. (Basically my job description is to tell my coworkers "you shouldn't do / have done that" but people seem to not like it when I put it that way)

Come to your points:

I'm no animator, but from my limited experience/understanding. wouldn't it just be a matter of adjusting the coordinates of the particle nodes to match those of the camera?

The camera moves statically during attacks meaning that their location is not a dynamic variable within the engine, rather it is simply unique to every Pokémon. Therefore, it does not seem like a hardware or labor restrictive problem.

Click to expand...

If the attack animations are hardprints (ie.: solid animations without handleable nodes), that might serve a good base, since at most you only need to move the model of the Pokémon within the scenario to find a good fit, assuming there is one.

Unfortunately the problem of calculating and storing the necessary adjustments per user per target is costlier on aggregated time (and processing) than the alternative of eg.: zooming the camera out to a distance where the mismatch is not noticeable, and since the net effect of that simplest solution is that both Pokémon would look smaller and/or less focused during the attack, I guess it was tested and deemed not worth the shot... let's remember the 3DS has an impressive resolution of 240p; that's less than the original Play Station Portable and much less than the SNES's advanced resolution modes.

The Switch, on the other hand, should have no excuse wrt the ability to stretch, compose or transform animations, or retrace the camera and test obstructions in 3D, so in this console even if the animations were hardprints the issue should be easily solvable, even by preoptimizing and storing the precomputed paths and tuples on disk.

In the end, however, I should be the one defering to you for an analysis of the feasibility of any of those implementations.

Based on my experience modding The Witcher 3, that game has far more unique animations, and a fully user controlled 3D camera as well, and this all from a studio with far fewer potential resources than GF. From a hardware perspective, the 3DS is capable than far, far more than what the Pokémon games utilize, and the switch even more so.

Click to expand...

I've heard a number of times the argument that in theory GF should be a studio with unlimited resources - I mean, Pokémon does literally print money. I'm not sure how true that is but certainly the hiring process in GF has resulted in a set of workers that either don't have the time or are simply not capable of performing basic optimization analysis on the hardware implementation that they could take advantage of.

At the same time however, I wouldn't sell the abilities of the 3DS too high. In terms of pure execution capability it is a console less powerful than the N64 and the Play Station Portable, and the hardware comes already gimped in a number of ways including a too low baseline for the second processor, no direct USB data bus, horribad filesystem for on-card storage (the same as Windows 95!), and an inefficient data bus for the touchscreen.

As a relevant data point: when the homebrew scene for the 3DS was still growing the beard, there was a long time during which playable speed SNES emulation was thought to be impossible even by the people who had implemented other similar emulators before, and even today AFAIK there is only one emulator offering at or above native playable speed. While I don't have that much understanding I'd surmise much of the limitations were due to GPU processing and rendering. Meanwhile both SSE2-tier desktops and the PSP have enjoyed near-native playable speed N64 emulation for a while.

Venia Silente said:

The Switch, on the other hand, should have no excuse wrt the ability to stretch, compose or transform animations, or retrace the camera and test obstructions in 3D, so in this console even if the animations were hardprints the issue should be easily solvable, even by preoptimizing and storing the precomputed paths and tuples on disk.

Click to expand...

The capability of the Switch specifically is where I intended to base my claims, as it is the console which I understand the most about its hardware capability.

I think we agree that it is capable of properly processing and storing hundreds of unique animation sets, a fact clearly demonstrated by the impressive graphical features of many games in its existing library. Due to this, I agree with you that although TPCI should have the resources, other factors limit its ability to properly/effectively utilize them.

Venia Silente said:

I wouldn't sell the abilities of the 3DS too high. In terms of pure execution capability it is a console less powerful than the N64 and the Play Station Portable, and the hardware comes already gimped in a number of ways including a too low baseline for the second processor, no direct USB data bus, horribad filesystem for on-card storage (the same as Windows 95!), and an inefficient data bus for the touchscreen.

Click to expand...

This is where I would disagree. Although I do not understand the exact limits of the 3ds's abilities, other factors of Game Freak's implementation of its animation engine point to their failure fully utilize them.

The fact that battles still lag, even with models with gimped LODs, and uncompressed data streaming for texture loads and ambient occlusion are examples of GF's resistance to implement industry-standard graphical tech. Further, the fact that the attack animations themselves are not even true 3D practice systems, rather they are 2D images statically loaded on a 3D plane, means that the only intensive processing required for the compute units on the system lay in the Pokemon model itself, which as it stands, simply freezes during the attack, meaning that if anything, processor load is lower during idle moments.

That all said, I simply believe that although they didn't have to do more, they certainly could have done more, and my claims are meant to argue this specifically.

IMO, CFW is not a good basis for understanding hardware capability. it often has more to do with the hardware architecture, and the ability for hackers to fully utilize it as CFW, with it often being loaded in atypical ways. In comparison to GF's unrestricted access to documentation. etc... GF shouldn't be forced to contend with any inherent restrictions or limitations of the system that CFW programmers have to work around.

Thank you very much for the insight! I think this discussion is a super interesting one, as without insider knowledge, it is unclear if GF's choices are made with technological or economic factors in mind.

I'm enjoying the above discussion; interesting insights for me as well!

But I'll also draw attention to the article getting a small update. We had two trailers since it was published, so I highlighted a few cases at the bottom. There's a new Dynamax animation for Gengar which is cool (objects thrown at the opponent like a poltergeist!), but there's also Charizard showing an even bigger separation from its mouth with where a fire-based attack originates. To the point of being entirely below where the fire comes from. Whoops.

(Also Yamper's tail whip.)

Bump!

The article has been significantly updated. The original article is more or less the same, but there's a large part added to the beginning, reviewing the battle animations and graphics of the SwSh games as part of our official game reviews (thanks again, Nintendo Australia!)

Unlike the SwSh music review I'm not quite as positive here... there's some good aspects like (most of ) the new moves and the UI is clean, but other things were found lacking, especially for a Switch title reusing assets from gen 6 3DS titles. Let me know your thoughts!

Honestly, I really don't care about the graphics unless it is good. I just enjoy the game for what it is.