> Curious if you have any other use-cases in mind for such a technology?
Yes. In fact, the collage thing is the secondary pie-in-the-sky non-MVP use-case.
The primary use-case: a Mario Maker-like UX for playing cloud-hosted ROMhacks, where each ROMhack's game engine has been carefully cut down so that the experience is of just playing a level in isolation, with some state (e.g. life counter) managed by the runtime and passed in/out of the running core; where, just like in Mario Maker, the UX takes over between executions of the "per-level simulation", and so it's the UX, not the game, that determines whether you retry on death; and that determines what happens next when you "complete" a given level. So it can do various things like run you through playlists of experiences, shuffle a filtered set of all experiences, etc.
That "cutting down" of ROMs into game engines would be automatic/generalized, and would involve the classic techniques of "program-slicing", applied to the domain-specific tooling of emulation: input-movie control-path tracing + memory-watch rules for where the "boundaries" of the sub-engine in the game are, followed by unreachable-code and data elimination; then base memory-state capture to kick off the game at a given point + overlay-state synthesis to control what it looks like when it kicks off. Jumping control "out of bounds" ends the emulation, with memory rules to then determine whether that constituted a "win" or a "game over."
Also, the base "game engine" ROMs would have all IP "assets" (art, music, etc) removed / factored out; these would instead ship as [modder-provided] "game asset" packs, of which there could be multiple used in a single game project, and which would synthesized into ROM memory-bank files at publication time.
End-user supplies base-game ROM images locally; client synthesizes "game engines" from these ROM images. Or clean-room reversed "game engines" can be distributed, given that they're an alternative compilation from the reversed source, that doesn't contain any of the original game's assets — those all being wholesale replaced by the mod! — and so (I believe) don't violate copyright. In which case, the end user having the original ROM image available, only unlocks the ability to (potentially) "change the asset theme" of the game from its custom one, back to the original game's IP assets.
The core user-story, would be sitting there with a controller in hand, continuously consuming free-to-play "experiences", presented to them through playlists / recommendations / shuffle. (Game jams would be playlists!)
But there'd also be a store — for buying experiences that artists want to charge for, yes†; but also for buying asset packs, or for licensing the use of "engines" that others have put their hard work into developing, since the same UI that lets you play the games, is also the UI for publishing the games. (I'm not sure if I want to get involved with it being a UI for developing games, though. Maybe for the multi-module stuff; but I'm more expecting tooling like GB Studio and Lunar Magic to step in on the development side, allowing export to a package format that you'd use to publish on this thing.)
† (Paid experiences could have "demo versions" that show up in the free-to-play shuffle; where at all times while playing the demo, there'd be a little unobtrusive UI element that could take you to the store page for the paid version of the experience.)
You could add whatever "game engines" you want to this platform — as these aren't just limited to being ROMs, but rather can also contain a "native layer" (I'm currently thinking a PPAPI executable, even though it failed in its original browser use-case.) Engines can be designed "on top of" other engines; all the extracted-from-game-ROM game engines would actually be running on top of a set of native emulation-core engines that ship with the runtime. But "RPGMaker-compatible runner" is an engine. Love2D is an engine. RenPy is an engine. StepMania is an engine. The early Win32 GameMaker engines are engines. The Macromedia Flash projector is an engine. Etc. You can publish experiences with these, too; and there would be porting tools to take finished projects from these runtimes and shift them onto the platform.
And, perhaps less obviously, big third parties (e.g. Adobe, Unity) could publish pay-to-license engines on the platform, where you could design your more domain-constrained engine to run on top of their engine, and the whole licensing/royalties aspect would be handled automatically.
---
One of the key things I actually want from this project, is to "commodify" these other engines, in the way that MAME/RetroArch/etc "commodify" emulators into cores. I want to "containerize" all the old Flash games, old visual novels, RPG Maker 95 projects, etc. such that you could just pick-up-and-play them the same way you can pick-up-and-play a ROM on a modern multi-core emulator. And with all the same modern niceties, e.g. cloud-based save-states, super-resolution, etc.
The other, perhaps less obvious trick here, is that you can slice up the actual original games themselves — the ones whose game engines are the basis of the mods — and allow the bits and pieces of these original titles to be listed as these same kind of bite-sized "experiences" on the platform — but where these "experiences" are only accessible to owners of the original game (i.e. to people who have the ROM image locally, or maybe who have bought the game from its IP owner(!) through the platform; or who can prove they have paid some other licensing fee to the IP owner, e.g. by SSO-binding an account of that IP owner's platform that proves they have access to a subscription tier that comes with leased licenses for those titles.) Sometimes I just want to re-play a particular small section or mini-game from one of my favorite old games. This platform would treat that section/mini-game as its own addressable resource that I can navigate to and play.
You're right; but also, I had actually never put any of this to paper before; it was mostly just shower thoughts. The GP comment prompted me to actually make a lot of these whimsies concrete and coherent, while I had a moment between things at work, and a good reason to do so. The design docs will cite this comment thread! :)
Yes. In fact, the collage thing is the secondary pie-in-the-sky non-MVP use-case.
The primary use-case: a Mario Maker-like UX for playing cloud-hosted ROMhacks, where each ROMhack's game engine has been carefully cut down so that the experience is of just playing a level in isolation, with some state (e.g. life counter) managed by the runtime and passed in/out of the running core; where, just like in Mario Maker, the UX takes over between executions of the "per-level simulation", and so it's the UX, not the game, that determines whether you retry on death; and that determines what happens next when you "complete" a given level. So it can do various things like run you through playlists of experiences, shuffle a filtered set of all experiences, etc.
That "cutting down" of ROMs into game engines would be automatic/generalized, and would involve the classic techniques of "program-slicing", applied to the domain-specific tooling of emulation: input-movie control-path tracing + memory-watch rules for where the "boundaries" of the sub-engine in the game are, followed by unreachable-code and data elimination; then base memory-state capture to kick off the game at a given point + overlay-state synthesis to control what it looks like when it kicks off. Jumping control "out of bounds" ends the emulation, with memory rules to then determine whether that constituted a "win" or a "game over."
Also, the base "game engine" ROMs would have all IP "assets" (art, music, etc) removed / factored out; these would instead ship as [modder-provided] "game asset" packs, of which there could be multiple used in a single game project, and which would synthesized into ROM memory-bank files at publication time.
End-user supplies base-game ROM images locally; client synthesizes "game engines" from these ROM images. Or clean-room reversed "game engines" can be distributed, given that they're an alternative compilation from the reversed source, that doesn't contain any of the original game's assets — those all being wholesale replaced by the mod! — and so (I believe) don't violate copyright. In which case, the end user having the original ROM image available, only unlocks the ability to (potentially) "change the asset theme" of the game from its custom one, back to the original game's IP assets.
The core user-story, would be sitting there with a controller in hand, continuously consuming free-to-play "experiences", presented to them through playlists / recommendations / shuffle. (Game jams would be playlists!)
But there'd also be a store — for buying experiences that artists want to charge for, yes†; but also for buying asset packs, or for licensing the use of "engines" that others have put their hard work into developing, since the same UI that lets you play the games, is also the UI for publishing the games. (I'm not sure if I want to get involved with it being a UI for developing games, though. Maybe for the multi-module stuff; but I'm more expecting tooling like GB Studio and Lunar Magic to step in on the development side, allowing export to a package format that you'd use to publish on this thing.)
† (Paid experiences could have "demo versions" that show up in the free-to-play shuffle; where at all times while playing the demo, there'd be a little unobtrusive UI element that could take you to the store page for the paid version of the experience.)
You could add whatever "game engines" you want to this platform — as these aren't just limited to being ROMs, but rather can also contain a "native layer" (I'm currently thinking a PPAPI executable, even though it failed in its original browser use-case.) Engines can be designed "on top of" other engines; all the extracted-from-game-ROM game engines would actually be running on top of a set of native emulation-core engines that ship with the runtime. But "RPGMaker-compatible runner" is an engine. Love2D is an engine. RenPy is an engine. StepMania is an engine. The early Win32 GameMaker engines are engines. The Macromedia Flash projector is an engine. Etc. You can publish experiences with these, too; and there would be porting tools to take finished projects from these runtimes and shift them onto the platform.
And, perhaps less obviously, big third parties (e.g. Adobe, Unity) could publish pay-to-license engines on the platform, where you could design your more domain-constrained engine to run on top of their engine, and the whole licensing/royalties aspect would be handled automatically.
---
One of the key things I actually want from this project, is to "commodify" these other engines, in the way that MAME/RetroArch/etc "commodify" emulators into cores. I want to "containerize" all the old Flash games, old visual novels, RPG Maker 95 projects, etc. such that you could just pick-up-and-play them the same way you can pick-up-and-play a ROM on a modern multi-core emulator. And with all the same modern niceties, e.g. cloud-based save-states, super-resolution, etc.
The other, perhaps less obvious trick here, is that you can slice up the actual original games themselves — the ones whose game engines are the basis of the mods — and allow the bits and pieces of these original titles to be listed as these same kind of bite-sized "experiences" on the platform — but where these "experiences" are only accessible to owners of the original game (i.e. to people who have the ROM image locally, or maybe who have bought the game from its IP owner(!) through the platform; or who can prove they have paid some other licensing fee to the IP owner, e.g. by SSO-binding an account of that IP owner's platform that proves they have access to a subscription tier that comes with leased licenses for those titles.) Sometimes I just want to re-play a particular small section or mini-game from one of my favorite old games. This platform would treat that section/mini-game as its own addressable resource that I can navigate to and play.