Show HN: Teachcraft – Learn Python through Minecraft

Sure! At one point, some group of volunteers also created a spin off project with the aim of putting more focus on creating a whole web interface around the concept, but I think it's inactive now. I try to maintain this repo from time to time and to keep it as bare-bones as possible.

At one point, I plan to experiment with ZipPy (https://github.com/securesystemslab/zippy) to see if that would be a viable option to get Python 3 support underway.

Maybe you are expecting just too much out of your child, if you tried so many options and they still don't like it, perhaps it is not something for them. Not everyone must like coding, let your kids shape their future based on their own passion instead of forcing yours upon them.

I guess I gave the impression that I'm shoving it down his throat. I'm taking the approach where I'm trying to inspire by showing him different kid friendly coding tools, not forcing anything and being totally okay if he doesn't want to do it. I was just curious if anyone had any success at inspiring a child to be excited by coding who wasn't into it at first. I know there are a lot of parents out there who try to force activities on their child, and I'm not one of them.

I remember working with a few people who had families several years back.There was a bring your kid to work day. Around mid day I saw all the kids playing minecraft on their laptops. They were probably about 8 - 12 I think. As I talked to them, they got really excited. Wanting to show off their private worlds. They had created custom modules in java, were running servers, and all these other things. This was like the lego blocks for their generation. In addition it bought a lot of STEM knowledge to boot.

Seeing stuff like this is really cool. Adding more to the community and growing opportunity.

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