I've been wondering if it's possible to pull off a recognizable version of The Legend of Zelda: Breath of the Wild on the Nintendo 64. Since I haven't played BotW and have no game development expertise above SNES level (which is probably a bridge too far for this game), the following is mostly handwaving:
Physics is easy as long as you're clever and don't just run everything all the time. The math is really very simple, and if you watch your code size the N64 has a disproportionately powerful CPU. Rocket: Robot on Wheels used real physics.
Distant terrain doesn't have to be rendered every frame if you can scroll and zoom the backdrop. The killer is pan, really, and scroll is a trivial way to accomplish that in between skybox updates. Zoom just drops the required update speed even further. You could even have multiple backdrops with different update speeds, with only the near field updating at the full 20 fps or whatever. Mind you, I haven't tried this; it just seems reasonable... You might get some weird-looking artifacting in edge cases, but perhaps you could mitigate some of it with some reasonably inexpensive image warping... I'm getting out of my depth here...
With heavy use of terrain LOD and billboarding, maybe some procedural geometry/textures to finish up the near field without busting the storage limits... you'd never be able to pull it off on Playstation, but with data streaming from cartridge like in Infernal Machine, plus a custom microcode to push the RCP as far as it will go, I think an open-world game of this size might just be feasible on N64.
Maybe I'm underestimating the difficulty of combining all those interactive systems on such a primitive CPU. But honestly it doesn't seem that hard if you're clever and don't try to use brute force. It might not turn out exactly the same in all cases, but I don't see why something that feels similar enough to the player should be out of reach.
Apparently a lot of open-world games are CPU-bound due to the enormous amount of stuff that has to happen independent of the player; NPC actions and such. Has anyone who's played Zelda got a good idea of whether this element is likely to be a problem?
I get the feeling that world state might be an issue, with only 8 MB of RAM. Perhaps efficiencies could be had and shortcuts taken; one bit per chest/enemy should about do it, with extra storage only when the player is nearby... I'm sure nobody would mind if boulders replaced themselves once you got too far away...
Physics is easy as long as you're clever and don't just run everything all the time. The math is really very simple, and if you watch your code size the N64 has a disproportionately powerful CPU. Rocket: Robot on Wheels used real physics.
Distant terrain doesn't have to be rendered every frame if you can scroll and zoom the backdrop. The killer is pan, really, and scroll is a trivial way to accomplish that in between skybox updates. Zoom just drops the required update speed even further. You could even have multiple backdrops with different update speeds, with only the near field updating at the full 20 fps or whatever. Mind you, I haven't tried this; it just seems reasonable... You might get some weird-looking artifacting in edge cases, but perhaps you could mitigate some of it with some reasonably inexpensive image warping... I'm getting out of my depth here...
With heavy use of terrain LOD and billboarding, maybe some procedural geometry/textures to finish up the near field without busting the storage limits... you'd never be able to pull it off on Playstation, but with data streaming from cartridge like in Infernal Machine, plus a custom microcode to push the RCP as far as it will go, I think an open-world game of this size might just be feasible on N64.
Maybe I'm underestimating the difficulty of combining all those interactive systems on such a primitive CPU. But honestly it doesn't seem that hard if you're clever and don't try to use brute force. It might not turn out exactly the same in all cases, but I don't see why something that feels similar enough to the player should be out of reach.
Apparently a lot of open-world games are CPU-bound due to the enormous amount of stuff that has to happen independent of the player; NPC actions and such. Has anyone who's played Zelda got a good idea of whether this element is likely to be a problem?
I get the feeling that world state might be an issue, with only 8 MB of RAM. Perhaps efficiencies could be had and shortcuts taken; one bit per chest/enemy should about do it, with extra storage only when the player is nearby... I'm sure nobody would mind if boulders replaced themselves once you got too far away...