satoshinm

This looks amazing! Both Eaglercraft and Browsercraft (though Eaglercraft seems to be further along) — the closest realization to the dream I've had for years of running a fully-featured Minecraft in the browser. Quite promising, I can only wonder where these projects will end up as they develop further, wishing for the best...!

Why is this so exciting to me? I started playing Minecraft back in the Java modding days, which really picked up steam around 1.2.5 and, by my estimations, peaked around 1.7.10. There was a veritable cornucopia of mods widely available, to enhance the game in a plethora of ways. I modded my game so hard I undoubtedly ran more third-party code than first-party/Mojang. Minecraft was a platform for creative expression, freeform and unconstrained. The golden age of Minecraft modding!

But it wasn't all unicorns and rainbows. There was a dark side of modding: the ease of use, or lack thereof in getting mods setup. Modpacks helped, but you still had to run untrusted code, and you still had to have a compatible PC. This is what (nearly) killed Minecraft for me. I wanted to play with my friend, but his PC had Windows upgraded and lost Java or OpenGL compatibility, and he eventually dropped his desktop and switched to tablets, phones, and consoles. My highly curated developed modded technical world became inaccessible.

Contrast this unfortunate situation with the browser: with "load and go" functionality as Douglas Crockford calls it, you can just visit a website and play, provided sufficient specs. What if we could play modded Minecraft (preferably 1.7.10), with all the mods to our hearts content, right in the browser, accessible to anyone?! And anyone could develop and distribute their own mods without concern, being safely executed within the browser sandbox.

I don't know how close Eaglercraft is to this utopia, but I find the possibility very enticing.

I sympathize with the persistent UX issues with web-based voxel engines. I think what is really needed is a UI/UX expert (unfortunately not me) willing to push forward and drive fixes across the entire stack: the game engine, Emscripten, and even investigating and submitting fixes/enhancements to web browsers - owning the complete experience.

For what it's worth, when porting NetCraft I did make an effort to isolate, fix and upstream various UX fixes to Emscripten:

https://github.com/satoshinm/emglfwbugs

with _some_ success; the developers of Emscripten are happy to accept pull requests. But I agree there's a lot of papercuts, and tracking down each of the usability nits could essentially be a full-time job...

For the keybinding problem, I've found using backquote/tilde key for escape can sufficiently workaround the un-interceptable escape key. It also works well on mobile browsers without escape keys.

But the problems with multi-gigabyte world storage, multi-threaded networking, SharedArrayBuffer, may require more invasive architectural changes. At this point, maybe a rewrite focused on web support from the beginning would easier than a port? But _a lot_ of work was put into Minetest over the years, it is great having the library of mods already developed for Minetest, available on the web. Although the same could be said for Minecraft itself.

In any case, thank you for your work porting Minetest to the web. I appreciate it moving the needle in the "web-based Minecraft clone" niche. Even if it may not the be all to end all, hopefully the UX blockers can be resolved, fit and finish, if not in Minetest itself maybe it will inspire others to create something anew with lessons learned from your port. One step closer to the metaverse.

This is the precise reason I'm also very interested in this project (or more generally, any implementation of a web-based voxel game). Douglas Crockford correctly identified "load and go delivery" as a key feature of the web platform. I've lost friends as players because of problems they had installing the Java version of Minecraft on their new PC. If they could simply visit a website in their browser, especially on a mobile device, we could play again.

Amusingly, very early versions of Minecraft circa 2009 _did_ run on the web browser: as a Java applet. This was short lived, and of course since 2017, Java applets are completely deprecated.

Mojang also published a JavaScript implementation of Minecraft at https://classic.minecraft.net/. You can share a link to play multiplayer. However, it is only a version of Minecraft "classic" (reports as 0.0.23a_01), and even then, a reimplementation, not 100% faithful to the original. It seems to be more of a "hey look what you can run your browser" cool tech demo of WebGL and WebRTC, than a serious multiplayer survival game.

Hopefully Minetest for the Web can succeed in this niche. I, for one, am rooting for them.

This looks amazing, great work!

A web-based "Minecraft" has great potential, in my opinion, and has long been a dream of mine. My humble attempt at such a project: https://satoshinm.github.io/NetCraft/ (2017) - a port of Michael Fogleman's Craft, a simple Minecraft clone written in C, ported to the web using WebAssembly and Emscripten. It works, reasonably well (after a few small enhancements/fixes to Emscripten) but did not get very far. But it could be so much more, a "metaverse", if you will.

Minetest is a much more sophisticated application: paradust7's minetest-wasm port, even in its early stages, is already quite impressive. If it can be optimized, with streamlined add-on installation, seamless multiplayer/networking support, browser compatibility improved - I would not be surprised if this project catches on and gives Minecraft a run for its money.

Having the ability to easily casually play within a web browser, no install needed, is a massive advantage over the Java or C++ implementations of Minecraft - which have not (officially) embraced modding to the extent Minetest has. If successful, this project could capture the large and diverse community of Minecraft modders - able to more seamlessly deliver their creative content through the web. Excited to see how it develops further.

These undocumented 6502 opcodes were very useful during the 90s, when developing Game Genie codes for the Nintendo Entertainment System.

GG codes were essentially[1] single-byte ROM patches. For example, the code AAAAA would patch address 0x8000 to 0x00 (I have a web-based decoder (and Node.js module) for those interested [2])

The Galoob Game Genie device only let you enter 3 codes at a time (unless you chained together multiple Game Genies), so minimizing the number of bytes you have to change to make the code work was a worthwhile goal. If your effect requires 3 codes, a typical player will not be able to use any other code. Modifying only one byte is ideal.

How do unofficial opcodes help here? Well, the official opcode list is quite limited. Undocumented/illegal opcodes help in at least two ways:

Multi-byte no-operations: want to remove an instruction completely? You can NOP the first byte, the opcode, but this leaves the operands (if there are any), desynchronizing the instruction stream (sometimes you can get away with this and it produces interesting effects, however). Fine, so you can add one or two more codes NOP'ing out the operands, but then your effect is 2 or 3 codes long!

Undocumented codes to the rescue. DOP and TOP, double-nop and triple-nop, turn this 2 or 3 code effect into only 1 code. Although to be fair, there is another workaround: patch to a legitimate opcode, which has an operand of the same size (same or similar "addressing mode"), but an effect which does not meaningfully impact the program operation. Frequently this was possible, with some effort, but DOP and TOP is nonetheless a cleaner solution.

Another benefit is combining multiple operations into one, also for a more compact code. Many of the undefined opcodes exist, as I understand it, due to "don't cares" in minimizing the instruction decoding logic, hence they combine multiple operations, sometimes usefully so (sometimes not):

ASR = AND + LSR

ANC = AND + ASL

XXA = AND + AND

ARR = AND + ROR

DCP = DEC + CMP

ISC = ISB + INS

LAS = LDA + TSX

LAX = LDA + LDX

LXA = STX + AND

RLA = ROL + AND

RRA = ROR + ADC

SAX = AND + AND

SBX = CMP + DEX

SHA = AND + AND

SHX = AND + AND

SHY = AND + AND

SLO = ASL + ORA

SRE = LSR + EOR

TAS = AND + AND

etc

The multiple-store (Sxx) and load (Lxx) operations most useful for this purpose, from my recollection. I think the most I used was LAX, which would load the operand from memory into both registers A and X, in one opcode. The combined store and arithmetic opcodes in theory could be useful though in practice many were unstable.

[1] Technically, GG codes patch the lower 15 bits of _CPU_ addresses, which can map to multiple ROM addresses depending on the mapper hardware in the cartridge. But this effect is difficult to usefully harness (though it is possible) to patch multiple ROM addresses you want because they have to line up exactly, in practice on these games the coder will use an 8-letter code to restrict the patching to one ROM bank (example: the famous SLXPLOVS = 1123?de:bd, meaning "if CPU address 0x9123 sends data 0xde, replace with 0xbd - replacing the DEC opcode with LDA, disabling decrementing the player life count variable when they die, resulting in the "Infinite Lives" effect on Super Mario Bros. 3. Galoob codemasters didn't use undocumented opcodes in their official GG codes as far as I know, but they were useful in homemade amateur codes.)

[2] https://satoshinm.github.io/nescode/

I cannot recommend Bountysource - my first time using it, excited to contribute to some open source projects, I made a deposit and it was never credited. Reached out to Bountysource and they claimed they had no record of the fund transfer. Never received my money back despite proof of the transaction.

In 2018, Bountysource was acquired by "CanYa", a company known for their CanYaCoin ICO. As far as I can tell since the acquisition they have only gotten shadier (fair or not, I now associate them with sketchy cryptocurrency operations). Would not recommend.

I wanted to find a platform to fund open source development through bounties, but Bountysource isn't it - fortunately there are new alternatives popping up, hopefully more trustworthy.

I for one find this project very worthwhile, there are/were plenty of web-based clones of Minecraft but many abandoned or haven't caught on. ian13456's mc.js, which I just learned about from this post, has 1717 stars on GitHub, quite impressive.

I'm aware of a couple other attempts. voxel.js (the furthest along fork seems to be http://voxelmetaverse.com - code https://github.com/deathcap/voxelmetaverse hasn't changed since 2016, and the domain expires 2020), originally named minecraft.js, written in pure Javascript originally with three.js, then stackgl using npm and browserify.

My attempt is https://satoshinm.github.io/NetCraft/ (source code: https://github.com/satoshinm/NetCraft), but it is implemented slightly differently, in that it is actually written in C (based on fogleman's "Craft") and compiled to WebAssembly to run on the web. This 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.

This is really cool, glad to see someone tackling this problem.

I have added several of my abandoned projects, here is a quick summary of them if there is any interest:

https://github.com/satoshinm/WebSandboxMC: Bukkit plugin providing a web-based interface with an interactive WebGL 3D preview or glimpse of your server - this bundles the NetCraft frontend in a Minecraft server plugin. There are requests from Spigot users https://github.com/satoshinm/WebSandboxMC/issues/100 to make it active again, which is what inspired me to add it to Code Shelter.

https://github.com/satoshinm/NetCraft: Web-based fork of https://github.com/fogleman/Craft . Craft has been featured on Hacker News before, but it is pretty much abandoned, so I forked it into NetCraft, but then in turn ran out of time/interest to update it. The summary still applies: "Voxel 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.

Previous discussion: https://news.ycombinator.com/item?id=17828187

+1 for Glowstone, highly recommended to anyone interested in running a server, one of my favorite projects of all time. A while back it was forked to add improved Spigot plugin support (in addition to Bukkit), later re-merged into mainline Glowstone, extensively under new development so it is worth checking out again for those who have tried it out years ago. Glowstone has a long history!

It even works well as the server backend for my NetCraft client, which is based on fogleman's Craft. The support plugin WebSandboxMC provides a WebSocket client for the web client to connect to, and it runs well on the Glowstone server, compatibility with Glowstone being a top goal.

So with these projects you can have both an open source client and server talking to each other, the full stack open source. The downside, of course, is neither are complete, but it is a start. Open source can only get better (contributions certainly welcomed).

Another project I'd recommend for those in the market for an open source server is Cuberite. It is written in C++ and supports plugins written in Lua. Also has a very active developer community, maybe slightly bigger than Glowstone. Last year I added Forge handshake support, so modded clients with Forge can connect send their mod list, while server plugins can register certain mods as required. Not full Forge mod support, but a necessary prerequisite. The downside of Cuberite is, without Java support, it doesn't have compatibility with Bukkit or Spigot plugins, so there is a vastly smaller ecosystem of plugins available, unlike Glowstone which can use many of them no problem.

Either way, both Glowstone and Cuberite servers, and Craft-based clients (shameless plug for NetCraft/WebSandboxMC), are very exciting and promising projects in my opinion. Personally I have not contributed to either recently, seeing this post I'm tempted to pick them up again, yet for better or worse I've moved onto other things. I'm certainly rooting for them to keep up their open source momentum, could turn into something very cool!

Thanks so much for creating these side projects, I've always admired the effective simplicity yet functionality of your code, especially Craft. Glad to hear you are as efficient with time management/life as your code :).

For anyone interested, last year I've taken fogleman's Craft and ported it to run in the browser using WebAssembly and emscripten: https://satoshinm.github.io/NetCraft/. It can be used with a Bukkit plugin to provide an interactive web-based interface to (a small section of) the world in Minecraft server. Have not worked on it recently, but could be a fun project to develop further, for all the open source contributors out there. I tried to merge most of the open pull requests and other forks of Craft, but life has gotten in the way...

According to the CEO of Espressif, Teo Swee Ann, the I/O pins of the ESP8266 are 5V tolerant.

See discussion here: https://hackaday.com/2016/07/28/ask-hackaday-is-the-esp8266-... and official reply on Facebook (of all places): https://www.facebook.com/groups/1499045113679103/permalink/1...

> Teo Swee Ann i can reply officially here: it is 5V tolerant at the IO. while the supply voltage is at 3.3V.

Updated this blog post just now, I found out how to effectively mirror the Linux console to the OLED module:

The basic technique is to run /usr/bin/screendump to capture the Linux console text, then write it to the SSD1325 module over SPI. However, the problem I ran into was this small 2.7" 128x64 display can only fit at most 9 rows and 31 columns of text, much smaller than any normal video mode (like the fabled 25x80 standard).

This could be solved by reimplementing a terminal emulator, of course, but an easier solution is to restrict the size of the console. On Linux, this can be accomplished using `stty rows 9` and `stty cols 31`. These commands cannot increase the size, but can decrease the console viewport beneath the maximum supported by the current font and graphics resolution. So now I can use my USB keyboard to interact with the real Linux console, and have it displayed properly on the OLED display, even working as you would expect with full-screen terminal programs such as vi.

If anyone is interested updated script (with screenshots) is available at: https://github.com/satoshinm/oledterm

Hey thanks for finding my project! I haven't posted about it much, so its cool to see it being noticed.

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

These are commonly known as ".io games" after the ccTLD (though not all have this type of domain). There is a subreddit dedicated to them where a large number of them can be found: https://www.reddit.com/r/IoGames/

A more likely and practical outcome is using the HTML5 DOM UI instead of Qt, and JavaScript instead of Python, etc. Native web technologies the browser already has support for.

There is already a movement towards using the DOM for web game UI instead of canvas, for example this recent article makes some compelling arguments: https://blog.pocketcitygame.com/5-reasons-to-use-dom-instead...

Using web platform technologies can actually reduce the download size over native apps. In the game I am working on, written in C and compiled using emscripten, as a rough measure, the equivalent program compiled natively totals an executable size of about 2 MB, not including texture resource data. An optimized asm.js build is about 950 KB and WebAssembly only 580 KB, this includes the .html shell, .js loader, and .wasm binary itself.

This is not a completely fair comparison because I compile out some native code not relevant to the web, and vice versa, but here are a few specifics of where I believe the gains may come from:

curl: the native C app uses libcurl for fetching resources from HTTP and HTTPS servers, but on the web, we have XMLHttpRequest and HTML5 Fetch. Emscripten provides the built-ins emscripten_wget() and emscripten_async_wget() for these purposes. No need for shipping HTTP and SSL stacks because the browser already has it included.

glfw and glew: libraries for wrangling OpenGL, emscripten has its own implementation which largely simply bridges to WebGL or other HTML5 APIs, a very thin layer. SDL, too.

databases: many apps bundle their own copy of SQLite, often as the single C file amalgamation. I used to, too, even through emscripten and it worked fine (there is even a pre-packaged emscriptenified sqlite.js), admittedly I haven't looked into it much yet but the web platform supports IndexedDB built-in, no extra dependency needed.

JSON: how many JSON encoders/decoders are there out there, separate copies in all of the apps? On the web, you can rely on JSON.stringify and JSON.parse (from JavaScript, but all functionality is bridged through WebAssembly anyways).

We may see a resurgence in "small C libraries" targeting WebAssembly. There is a growing trend of header-only libraries, especially the popular stb: https://github.com/nothings/stb#stb_libs and there is a growing list here: https://github.com/nothings/single_file_libs I consult to find tiny libraries appropriate for linking into a web-based C application. lodepng (for decoding PNG images) and miniz (for reading and extracting zip files) are about the only substantial dependencies I have beyond what is in the emscripten standard library. Everything else is provided by the browser, the web has grown to a surprisingly powerful and complete platform.

> It seems there is this effort to get C/C++ code performing fast inside of a browser... then at the same time there seems to be an effort to get people to stop coding in C/C++ altogether and switch to something more memory safe.

WebAssembly offers a compelling "alternative": instead of (or in addition to, if you desire) writing in memory-safe languages, with all the cost that incurs, you can write in unsafe languages and the consequence of memory errors is limited by the sandbox.

This approaches the problem from a different direction, on one side we have e.g. Go and Rust. Go with garbage collection and its overhead, or Rust with zero-(runtime)-cost abstractions which push the burden onto the programmer at development time. C compiled to WebAssembly is low-overhead but safer than native code, giving the benefits of both worlds.

I would have 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.