NetCraft

his avoids some of the performance pitfalls with Javascript and garbage collection. It even lets you play on a Bukkit-compatible server using a plugin. Unfortunately I have abandoned my project as well, but C/C++/Rust compiled to WASM may be the future, although it will be interesting to see how far this pure Javascript-based client can go. I wish mc.js developers the best of luck, we had similar goals of wanting to play Minecraft on the web.

game for modern web browsers (Chrome, Firefox, Safari) and desktop operating systems (Windows, macOS, Linux). Just a few thousand lines of C using modern OpenGL (shaders)." Heavily inspired by Minecraft, but much smaller and simpler. https://github.com/satoshinm/pill_serial: Triple USB-to-serial adapter firmware for flashing onto an STM32F103C8T6 "blue pill" minimum development board . With this firmware you can make your own USB-to-serial adapter, times three, by flashing a <$2 blue pill board. https://github.com/satoshinm/pill_duck: Scriptable USB HID device for STM32F103 blue pill (inspired by USB Rubber Ducky) . Another project for the "blue pill", this one lets you make an automated USB keyboard/mouse device, an imitation of the popular Rubber Ducky hacker tool, but a lot cheaper. https://github.com/satoshinm/pill_6502: emulated 8-bit 6502 CPU and 6850 ACIA for STM32F103 blue pill . Want to build a retrocomputer but an authentic 65C02 chip is too much? Play around with a classic processor without buying old hardware? Emulate it with the cheap blue pill, with enough support at least to run the Microsoft OSI BASIC ROM. I have started a few more abandoned projects on https://github.com/satoshinm?tab=repositories&type=source but these seem to have generated the most interest (especially the NetCraft/WebSandboxMC combination, but the pill_ projects can be quite handy), no longer can maintain them myself but would be great to see continued maintenance provided a community finds them valuable.

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...

ve never expected it, but now believe C is the language of the future for the web. Built on decades of history with an unbeatably large existing codebase, extensive analysis and tooling support, standardization, raw power without the shackles of safety, yet confined to limit damage by the browser sandbox. True cross-platform compatibility with powerful HTML5 web APIs. My experience about a month so far developing a C application compiled to WebAssembly/asm.js using emscripten has been surprisingly smooth. I can compile and test natively, including enabling the clang static analyzer or -fsanitize=address and -fsanitize=undefined to find bugs endemic to C, fix them and then deploy and run on the web. For the most part I can code directly to OpenGL and GLFW, which emscripten bridges to WebGL and other browser APIs seamlessly. I had to contribute a handful of fixes to emscripten, as well as an implementation of glfwJoystick to the HTML5 Gamepad API (also working on file drop and monitor API), but this was straightforward and easier than expected, emscripten happily accepted the patches. There are Rust (https://github.com/thinkofname/steven) and Go (https://github.com/thinkofname/steven-go) applications in this problem space but porting a similar application written in plain C (https://github.com/fogleman/Craft) to emscripten was nearly trivial (if there is any interest: https://github.com/satoshinm/NetCraft). After about a week I was able to consider the web-based port finished, and then focus on developing new features, for both web and native. Is C compiled to WebAssembly a panacea? Not by a long shot, there are many (perhaps most) scenarios where memory-safe languages such as Rust would be preferred. But for games and other programs where performance is more critical over correctness and safety, WASM is a godsend.