So, this may not work in future versions of Pico-8, but right now, I've noticed that if you do a load() within your game game code, you still have your base ram untouched until you run run(). With that info, you can use objelisks technique (https://www.lexaloffle.com/bbs/?tid=1860) and use cstore(x,y,z) and some empty space in the spritesheet to transfer info from one cartrige to another. Then use run() to switch to the new cartrige and peek to read back the transfered info. A single sprite equals 32 bytes with is good enough for a metroidvania.

As I said, there's no guarantee that load() will work like that in the future and it probably wouldn't work like that on a "real" Pico-8 console, so in a way it could be considered cheating. But right now it works.

I like it,. multi-ROM games are like mega carts where in hardware, . .

One way around it might be to use a password system between carts.
Would feel very old school.

password....no ugly and awesome at the same time....

It unfortunately also wouldn't work in the web player, which is probably how the vast majority of PICO-8 games are played. By a longshot.

If you don't want to load(), you can always reload().

Also, haven't found it yet but I swear multi-cart support was high on a list of upcoming web-version features.

You can also use the GPIO pins in the web browser. I don't think the BBS does anything with them, but you can if you're self-hosting the games. Since the GPIO pins are written to a javascript array, you can store data in to that and have the website switch cartridges (and then read the data back from GPIO pins.)

There's no way to automatically know when the cart has written to the GPIO array though*.

• You can manually patch the .js file so it runs a callback upon write, which would let you do this smoothly in the browser. I haven't tested that much.