For those curious, https://github.com/satoshinm/NetCraft is my first project with WebAssembly/emscripten. It was surprisingly easy to port from Michael Fogleman's Craft (https://github.com/fogleman/Craft/). I briefly tried porting a few other open source block-style engines without success, but Craft being written in plain C with only a few libraries is relatively straightforward.
The initial requirement is to refactor the main loop, from while(1) to emscripten_set_main_loop, a common step for most all emscripten ports. Then update the cmake build file to build with the Emscripten.cmake module, and you're almost done. Emscripten's GLFW3 wrapper covers nearly all of Craft's usage. I posted a fairly minimal pull request showing the basic changes needed: https://github.com/fogleman/Craft/pull/175
After that, the other major change is networking. Craft used a separate thread to listen for network data using blocking sockets and parse message boundaries. But on the web platform with WebSockets, networking is even easier, I use emscripten_set_socket_message_callback() to get called when a new, complete message arrives. Easy as pie.
The harder part is the remaining long tail of minor bugs. At this point, the web port of Craft was functional, but difficult to play, a death by a thousand cuts. Emscripten's GLFW implementation had a few bugs related to cursor focus and keyboard handling, but I developed test cases and submitted fixes (https://github.com/satoshinm/emglfwbugs), which were all merged into emscripten's incoming branch. Until they were merged I built against a patched emscripten.
If anyone wants to get their hands dirty with emscripten, I highly recommend it. You can write the game in C, but the APIs are bridged to JavaScript, and it was fun to extend it and add new API for HTML5 platform features. I implemented the glfw joystick API (https://github.com/kripken/emscripten/pull/5175) on top of the HTML5 Gamepad API, and drop callbacks on top of the HTML5 File Drop API (https://github.com/kripken/emscripten/pull/5206), and started but have yet to finish the glfw monitor API on top of the HTML5 Screen API (which reminds me I ought to finish https://github.com/kripken/emscripten/pull/5205...). This means existing games written using GLFW (a popular multi-platform library for OpenGL, see http://www.glfw.org) with these features should port to the web using emscripten automatically.
After the web port, I continued to enhance https://github.com/satoshinm/NetCraft merging open pull requests from https://github.com/fogleman/Craft and developing new features and fixes. Blocks no longer break instantly, but instead are mined by holding down the mouse button, drawing a growing block break indicator until it breaks, and so on. Up until last month, recently taking a break (to investigate a few other, semi-related projects). However, it is still very playable in the current state.
A live demo can be found at https://satoshinm.github.io/NetCraft/, but the more interesting possibility in my opinion is multiplayer. Craft's original Python server backend can be connected to over the web (/server servername), using a websocket proxy, but I also wrote a Bukkit plugin to bridge a small chunk of the Minecraft world: https://github.com/satoshinm/WebSandboxMC. Last month I ran a server on a VPS (for 1 month), backed by a variant of the open source Glowstone server (https://github.com/GlowstoneMC/Glowstone), with this custom plugin and it peaked at a couple dozen users, running decently smooth. I also experimented with hosting on Heroku, it is less stable and deletes when the dyno shuts down, but works (for a smaller number of users): http://netcraft.herokuapp.com
I don't know if Craft is the answer, but I definitely agree, a web-based block style game is extremely appealing. The next major missing piece I see is extensibility, allowing outside developers to conveniently and cleanly create and distribute new content. Minetest is way further in this regard, I have not looked into it, but at least the filesystem and networking should be feasible to port to emscripten (emscripten has its own virtual filesystems), and shared memory may benefit from the upcoming SharedArrayBuffer technology: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
