There are probably many resources available in Japanese to learn programming/game development. But, English is the foundation of almost everything in the information age.
Yup. No matter how much information you think is available in your native language, you will have more and higher quality in English, the vast majority of the time.
I've worked at a Japanese company and seen people who were ostensibly good at English gloss over the right result in a Google search because they didn't quite have the fluency to pick up on it immediately. People who aren't comfortable with English at all often get lost in native language articles that are just outright wrong or misleading, because when there's a vacuum of information to begin with it's very easy to write a bad article and still end up the top result for that topic in that language.
That's not to say most non-English content is bad - most content overall is bad or mediocre (or just obsolete), in any language, English included. Thus, the lower the density of content in any given language, the more likely that good content for any given search doesn't exist, and you're left with the poor stuff.
The exception is when you're looking for information on an insular tool or community that is primarily developed and used by speakers of a given language. There's a whole world of "Galapagos tech" in Japan that nobody uses elsewhere, and you won't find any English resources on it, and it might even be pretty good. But in today's globalized society, cooperation across borders ends up producing higher quality results (especially in open source) most of the time, so these kinds of insular projects are rarely the best option, unless it's a very niche thing or support and documentation in a non-English language is a primary concern.
Quick example of this kind of bizarre situation: I recently took a peek at reverse engineering a certain Japanese product that uses Android tablets and involves keeping a database on them and synchronizing it from a base station. Database updates are hilariously slow, taking hours to catch up on just a few thousand mutations. Turns out they were using an extremely niche database engine by Hitachi (if I remember correctly), in an embedded version; the only reference to this engine I could find was in the context of a full blown enterprise offering by them (think Oracle competitor). I bet it was configured to flush to disk after every mutation, for data durability in an enterprise setting. Had they used SQLite - which comes with Android, is free, and would've saved them a license fee - everything would be much simpler and DB updates would be orders of magnitude faster, since you can trivially configure it not to flush or just put the whole update in a transaction. They also could've just had the base station maintain the SQlite DB file and bulk transfer that, since it's not that large and it'd probably end up being faster and more reliable than the delta update mechanism with CSV mutation logs they were using.
(I'm a native Spanish speaker and my Japanese is good enough to understand technical content with occasional use of a dictionary, so I have a bit of experience with two non-English ecosystems)
One thing I noticed back when I worked in Japan 15 years ago is that, because a lot of software engineers there don't speak English (or at least not well enough), there was a big market for translations of English technical books. It was rather striking compared to what I had seen in France.
So, while I agree with your point, at least 15 years ago, there were a lot of resources for Japanese programers to read in their native language. Of course, another problem was the terrible, terrible state of education in Japan and the fact that good students would study Electonic engineering and that Software engineering was seen as being an unattractive choice.
The problem with books is that they're invariably obsolete, and almost always third party information (and thus usually at least a little bit wrong). I've never found the need to get my software engineering knowledge from books; online documentation is always more up to date and usually written by the authors of the project directly. In addition, only a tiny fraction of the knowledge you can find online in English will be collected in books, and it is much, much harder to search for.
Books are good for abstract knowledge (if you're that kind of learner) and to get an introduction to a particular technology, but not having access to the latest up to date information and a search engine over all the accumulated knowledge in the Internet is a major handicap.
This is one of the causes of a common pattern in SWE in Japan: always being behind the curve on tech, best practices, etc. There's just an inherent delay added by having to wait for information to be available in your native language. Add to that Japanese bureaucracy that discourages change (especially in big companies, but by no means exclusively), and it's even worse.
I've worked at a Japanese company and seen people who were ostensibly good at English gloss over the right result in a Google search because they didn't quite have the fluency to pick up on it immediately. People who aren't comfortable with English at all often get lost in native language articles that are just outright wrong or misleading, because when there's a vacuum of information to begin with it's very easy to write a bad article and still end up the top result for that topic in that language.
That's not to say most non-English content is bad - most content overall is bad or mediocre (or just obsolete), in any language, English included. Thus, the lower the density of content in any given language, the more likely that good content for any given search doesn't exist, and you're left with the poor stuff.
The exception is when you're looking for information on an insular tool or community that is primarily developed and used by speakers of a given language. There's a whole world of "Galapagos tech" in Japan that nobody uses elsewhere, and you won't find any English resources on it, and it might even be pretty good. But in today's globalized society, cooperation across borders ends up producing higher quality results (especially in open source) most of the time, so these kinds of insular projects are rarely the best option, unless it's a very niche thing or support and documentation in a non-English language is a primary concern.
Quick example of this kind of bizarre situation: I recently took a peek at reverse engineering a certain Japanese product that uses Android tablets and involves keeping a database on them and synchronizing it from a base station. Database updates are hilariously slow, taking hours to catch up on just a few thousand mutations. Turns out they were using an extremely niche database engine by Hitachi (if I remember correctly), in an embedded version; the only reference to this engine I could find was in the context of a full blown enterprise offering by them (think Oracle competitor). I bet it was configured to flush to disk after every mutation, for data durability in an enterprise setting. Had they used SQLite - which comes with Android, is free, and would've saved them a license fee - everything would be much simpler and DB updates would be orders of magnitude faster, since you can trivially configure it not to flush or just put the whole update in a transaction. They also could've just had the base station maintain the SQlite DB file and bulk transfer that, since it's not that large and it'd probably end up being faster and more reliable than the delta update mechanism with CSV mutation logs they were using.
(I'm a native Spanish speaker and my Japanese is good enough to understand technical content with occasional use of a dictionary, so I have a bit of experience with two non-English ecosystems)