Teach people that object oriented design is a tool and not an universal answer to every problem and that data oriented design also exists. If they have cpu friendly code in the first place then regardless where they port the code it will do well as operating principles are the same across architectures.
How do you port the physical SIMD unit that allows the game to function at the necessary performance in the first place? Note, there are two kinds of AAA games - platform exclusives designed to emphasize the differences between competitors and widely accepted games that need to avoid those differences so they can have a reasonable degree of parity. So if the new compute unit enables the game to do something new, it won't be able to do that new thing on other hardware without an equivalent to that compute unit. This is why features like ray tracing took a while to actually arrive in AAA, because while it was one thing to add it as a shader pack in Minecraft, it wasn't ubiquitous enough for Rockstar to design a game around - that took a few years. You can get away with some scaling issues - simpler geometry on weaker platforms, possibly shorter load distances provided that isn't crucial to the game play, etc. You can't lower FPS. you can't simplify physics, etc. So any specialized compute can't be used in an enabling capacity or else your game isn't portable. It has f-all to do with the nature of how you write the code, and everything about the design of the game.
I mentioned this before in how CP2077 failed on PS4 because the game was designed for the PS5 generation of consoles and assumed there would be a fast SSD to steam assets off of storage. But the PS4 had a fairly slow spinning drive and couldn't do that and was the main bottleneck to the game working on the prior generation of consoles. It had nothing to do with the coding paradigm and everything about the assumption being made about the capabilities of the underlying hardware. CDPR couldn't just massage their way around storage that was 10x slower than what their game needed. Had they assumed spinning drives, they would have had to consider
design solutions like loading screens, greater asset reuse to keep it on the GPU, not having cars in the game that require loading the map at a certain rate, etc. These are
design questions, not OO vs functional programming.
If you've never written code around hardware constraints like this you don't understand what's involved. A lot of us old guys learned to code in such an era - when platform A had a blitter that could support 8 sprites and platform B had one that could support 16 sprites, if you wanted your game to run on both, you had to design it around 8 sprites. You couldn't use the extra 8 sprites as part of your core gameplay. Maybe it could be aesthetic, but for any cross-platform design that additional hardware capability would have to go largely unused. Now, portability wasn't an issue back then - you were usually writing everything in assembly, and your 'port' was a complete rewrite. Thankfully applications were a lot simpler then.
Today most of that is handled by the game engine which handles 90% of the lift, but these engines are also designed to help the developer deal with hardware disparities by handling LOD issues, etc. But that also means that the game engine isn't going to run too far down some hardware rabbit hole that would unlock a new set of capabilities because much of the point of game engines is that they also handle most of the porting lift for you, and that rabbit hole makes that harder to impossible. It's great for platform exclusives, and a trap for everything else, and that's why developers avoid it. It's not worth boxing them into one platform. Once that bit of technology gets wide adoption and you see SIMD more broadly, etc. then you start to build around it. Again, the point of a platform exclusive is to show off the capabilities of the platform and so they will make the most of it (note the Wii games that were designed around the controllers, and in no universe could be ported to other platforms, not because it was 'too object oriented' whatever the f that means, but because nobody else had nunchucks that would let you stand in the middle of your living room which is what made those games fun.) But because the Wii rejected the emerging console design language around two triggers, two shoulder buttons, two analog sticks, 4 action buttons and a D pad, it was hard to port games to the Wii because the controls needed simply weren't there. Note the Switch adopts this design language, and games can be ported to it. Again, nothing to do with the coding paradigm. So AAA ported games are largely an exercise in maximizing your lowest common denominator hardware, allowing the game to scale where it doesn't impact gameplay, and refusing to utilize hardware features where it would.
And because the economics of the game industry have gotten so bad around AAA titles, they simply can't function as platform exclusives unless they are being heavily subsidized, now by TV and movie rights, merch, etc. And so it's reached a point that there is simply no room for hardware diversity. Xbox and PS are pretty close to the exact same hardware now because every time they introduce haptic triggers or whatever that gets sanded off by the GTA VI/CP/Battlefield games and becomes irrelevant. Gaming hardware is fully a by committee design exercise now.
Facebook
Twitter