Type matchups look simple until a project needs to explain them.
Most bugs come from treating a Pokemon type as a label instead of treating a matchup as a calculation.
The cleaner way to think about it is:
attacking type + defending type(s) = final modifier
That small distinction prevents a lot of bad guide text, especially for dual-type Pokemon.
I keep a public version of the workflow here:
This follows the broader reference-stack idea from the first article:
Building a Pokemon reference stack that stays auditable.
The common mistake
A lot of notes say things like:
Charizard is weak to Water.
That can be useful shorthand, but it is not the underlying model.
A better note stores the inputs:
{
"attackingType": "water",
"defendingTypes": ["fire", "flying"],
"result": "super-effective"
}
The note now says how the conclusion was reached.
That matters because the same attacking type can interact differently when the second defensive type changes.
Dual typing should be explicit
Dual typing is where most matchup mistakes happen.
A species can have:
- one type weak and the other neutral
- one type weak and the other resistant
- both types weak
- both types resistant
- one type immune
If the code or content pipeline only stores one defensive answer, it will eventually produce bad output.
A more useful model is:
{
"attack": "electric",
"defense": ["water", "flying"],
"components": [
{ "type": "water", "modifier": 2 },
{ "type": "flying", "modifier": 2 }
],
"finalModifier": 4
}
That structure lets the UI show both the result and the reasoning.
Use cases outside battles
Type data is not only for battle calculators.
It also helps:
- write fan guides
- organize species pages
- group TCG collection notes by type theme
- explain evolution routes where typing changes
- power AI tools that need traceable answers
That is why I link type notes back into the wider reference stack instead of leaving them as an isolated chart.
A practical content rule
When writing a type note, I try to include three things:
- The exact attack/defense context
- The final modifier or plain-language outcome
- A page where the reader can inspect the workflow
For example:
For dual-type examples like Fire/Flying or Dragon/Ground, see:
https://pokedexoracle.neocities.org/dual-types
That is more durable than a loose sentence copied from memory.
Reference
For the canonical Pokemon reference layer, use Pokedex.me.
The local type notes are deliberately small and workflow-oriented. They are meant to explain how to think about the data before a larger Pokedex or app consumes it.
Top comments (0)