mrpci_request_save / mrpci_save_out / mrpci_save_in carry a SaveData across
the wasm boundary, so the browser build can save and restore even though
Command::SaveGame's std::fs call goes nowhere there. The moment being stored
is exactly the one the native build writes to saves/<slot>.json — the same
GameState::save_data — so a slot means the same thing in both places.
F5 now asks the page instead of the filesystem; F7 points at the SAVES menu,
because restoring needs to know *which* slot and a function key can't say.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The macroquad GUI now builds for wasm32 the way MRPGI's does, with two
deliberate differences.
It boots into Play and the F8 editor toggle is compiled out of the web
build. What ships to someone playing a game should be the game, not the tool
that made it.
And it embeds a WorldBundle rather than a game *folder*. MRPGI reaches for
include_dir! because its bundle carries only manifest+rooms; MRPCI's already
carries scripts and sprites too, so one `--export-bundle` document is the
whole game. That is also the format MRP3GI boots from, which means one file
now feeds two engines.
mrpci_alloc/mrpci_world_in let the page hand over another bundle while the
engine is running — the arcade picker and drag-and-drop both arrive there,
and the session restarts on the new world.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
