deathcap

Minecraft may actually be closer to the metaverse than commonly believed:

Since the introduction of BungeeCord in 2012 (and then Waterfall and Paracord), it has become increasingly popular to link together multiple servers to act as a gateway to different virtual worlds on different servers. Most of the top popular "servers" are in actuality multiple servers joined together, somewhat decentralized, though still centrally managed.

Even before Bungee, the reign of Bukkit (2010-2014) introduced a plugin API system allowing for managing multiple worlds. To this day the "Multiverse" plugin remains among the top plugins. The multiverse, not the metaverse, but a related concept.

It wouldn't be too far of a leap to link together unrelated Minecraft servers.

Regarding "you can certainly not expand the protocol -southerntofu" - the Minecraft protocol is commonly expanded by modders. In fact, it is specifically designed to be expanded, since the introduction of Plugin Channels in Minecraft 1.1: https://wiki.vg/Plugin_channels. Forge modders frequently enhance the protocol to support new functionality far beyond what was possible in the original game.

"new media forms and new mediums of access (web, mobile, PCs, AR, etc.)" vs "you can only run Minecraft where Microsoft distributes it (unless you crack/RE it)" - granted, but there are multiple unofficial efforts to develop new ways to access Minecraft servers, including through the web. My humble attempt at building such a client: https://github.com/voxel/voxelmetaverse

Not coincidentally, I called it "Voxel Metaverse", thinking along the same lines as you were, and had high aspirations. It did not pan out, though we had some cool features including connecting to Minecraft servers, embedding web page content in a 3D space (including interactivity with voxel-webview, still working in the demo: https://voxel.github.io/voxelmetaverse/) and I wrote a retrospective about its successes and failures earlier this year: https://medium.com/@deathcap1/6-years-after-6-months-of-voxe... but it showed a lot of promise in what could be done to build a decentralized distributed malleable virtual world. Voxels are particularly attractive in my opinion due to the ease of content creation.

Other more recent efforts to build web-based Minecraft clients include https://github.com/PrismarineJS/prismarine-web-client and https://www.spigotmc.org/resources/websandboxmc.39415/, both are currently quite limited, but its only a matter of time/effort to complete the implementation and not a fundamental technology limitation. There are dozens of unofficial Minecraft-compatible clients, in various degrees of completeness: https://wiki.vg/Client_List

Vivecraft started in 2013 to allow a VR experience in Minecraft, and there is now an official Minecraft VR port though Vivecraft still has its fans. There's official mobile and console clients (Bedrock Edition), and although not officially interoperable with PC servers, there are also 3rd party solutions to bridge the two, including Dragonet DragonProxy and GeyserMC.

Will Minecraft blaze the way forward into what becomes The Metaverse? Honestly, maybe not. Mojang may not see the same potential in Minecraft as I do, but I feel the modding community is onto something developing projects on the edges of a hypothetical Minecraft Metaverse. If it isn't Minecraft itself, I am convinced a similar game will play a fundamental role in the development of what we come to know as the metaverse.

I forked a project [1] in 2015 to remove Gradle, and it then quickly subsumed the original project, remaining under active development to this day.

There were other reasons, but de-gradling was one of the main motivations for my fork, and among the first of the major changes I made. The project is an implementation of an API which was discontinued by the original developers, but initially was built using Maven.

After switching from Gradle (which the project switched to in 2014) back to Maven, build times significantly decreased and development became much more pleasant. I found Gradle to be like a speed bump slowing down development, and reverting back to Maven was like a breath of fresh air. Simple, straightforward, and fast. Maven may not be perfect, but it does the job well.

[1] An open source Bukkit server implementation, https://github.com/GlowstoneMC/Glowstone -> http://github.com/GlowstonePlusPlus/GlowstonePlusPlus

Voxelmetaverse, a voxel game platform based on voxel.js

Live demo: http://voxel.github.io/voxelmetaverse/

Source code: https://github.com/voxel/voxelmetaverse

I had big ideas for it but didn't get too far, after several years of working on it. Just published a retrospective today: https://medium.com/@deathcap1/6-years-after-6-months-of-voxe... - it could be developed much, much further.

Glad to see a shoutout to voxel.js here!

I worked on it for years and I had high hopes, wrote about my progress here: https://medium.com/@deathcap1/six-months-of-voxel-js-494be64.... Inventory, crafting, chests, texture packs, a plugin system, and embedded web views were some of my favorite features. My project was https://github.com/deathcap/voxelmetaverse, hosted at http://voxelmetaverse.com.

Unfortunately I haven't had time to develop it further, but it is all open source if anyone would like to pick up the torch.

If your main goal is to get as many contributors as possible, perhaps JavaScript would be the best choice.

Hi, I just wanted to mention I have started such a project: https://github.com/deathcap/voxel-clientmc - a Minecraft-compatible client written in JavaScript.

It sure could use more contributors =) help welcome if anyone is interested. Currently not many features are implemented, but you can connect to a Minecraft server (works with the official Minecraft server and its modifications, but I usually test with Glowstone or Glowstone++ for a 100% open source stack) in your web browser via the WebSocket/Minecraft proxy https://github.com/deathcap/wsmc. The protocol decoding is implemented by PrismarineJS https://github.com/PrismarineJS/node-minecraft-protocol, much of the client logic by mineflayer, and the WebGL voxel rendering using http://voxeljs.com.

JavaScript has some interesting benefits for game development, I enjoy its dynamicism; plugin loading is a breeze. Since it is already a "scripting" language, it is easily modifiable by third-parties. Some game engines have taken to implementing a second language runtime, for example Minetest and MC-Server are written in C++ but allow addon development in Lua. The Minecraft modifications ComputerCraft and OpenComputers also allow in-game programming using Lua. ScriptCraft, a CanaryMod plugin for Minecraft, allows writing plugins in JavaScript. etc. But when everything is written in JavaScript, there is no platform/addon dichotomy. In voxel.js (especially https://github.com/deathcap/voxel-engine-stackgl), much of the core functionality is even implemented in "plugins".

Or let me put it differently - what's the most popular open source client?

Another open source Minecraft-compatible client in the works is https://github.com/thinkofdeath/steven. Written in Go, already decently functional, though still far from finished it is under active development and progressing nicely. Not that popular yet but seems to be promising to me. The author is a major contributor to one of the most popular Minecraft server software packages.

Should have been implemented in Java :/

If you are looking for an open source Minecraft-compatible implementation in Java, I humbly suggest (shameless plug) checking out https://github.com/GlowstonePlusPlus/GlowstonePlusPlus. Glowstone++ like TrueCraft currently only implements the server portion, and it has some differences such as targeting 1.8.4 compatibility not 1.7.3 beta, but being implemented in Java has some significant benefits.

For those not aware there is a huge ecosystem of additions available for Minecraft written in Java. This includes thousands of "Bukkit plugins" available from http://dev.bukkit.org/categories/, Spigot plugins from http://www.spigotmc.org/resources/, and now an emerging community of Sponge plugins from https://forums.spongepowered.org/c/plugins/plugin-releases. Writing Minecraft-compatible software in Java has the advantage of being able to potentially support these plugins. Glowstone++ in fact implements much of the Bukkit API and Spigot API, as well as (currently a small subset of) the Sponge API through a bridge. Based on the original Glowstone server, Glowstone++ is completely open source, yet it ties into the existing "Minecraft" plugin development ecosystem.

Java has some disadvantages of course as well, so it's good to see alternative implementations in other languages (not only C# TrueCraft, but C++ MC-Server, Rust Hematite, JavaScript PrismarineJS, etc). The more choice the better =)

As xlib said, the screenshots were taken with the official client. I have a contributor who is working on a free (as in freedom) texture pack that we can use when we start working on the client.

A freely-licensed texture pack would be great, I faced this same problem when developing a different voxel-based game. There are plenty of texture packs available on Minecraft Forums or Curse but very few released under permissive licensing terms, or those that I could find were outdated.

So I made my own, feel free to use it or parts of it if you would like to: https://github.com/deathcap/ProgrammerArt - it is updated for and includes all items and blocks for Minecraft 1.8, available in "resource pack" (1.8-1.6), "texture pack" (1.5), and "stitch pack" (1.4 and earlier, prebuilt texture atlas) formats. It is not the greatest quality artwork I admit, but can serve as a decent placeholder, and best of all is released under CC-BY 4.0 so it can be freely used and distributed. Though if your contributor makes a better free texture pack I'll probably switch =) cheers

Using the zip method saves you some of that headache/overhead with the tradeoff of having to package your images into a zip and unzip them on the client side.

I wrote an NPM module recently using this exact technique, https://github.com/deathcap/artpacks (for use in the browser with browserify). Had a bunch of small textures, originally I was requesting each individually in their own HTTP request, but zipping them up and extracting in the browser led to a fairly significant improvement in latency.

Packing all of the small textures into one big image and slicing it up at runtime was also an option I considered. In fact, since I'm using these textures with WebGL they actually are packed into one large texture atlas before uploading to the GPU, then indexed at runtime using UV coordinates. So one could stitch together all the textures beforehand, distributing a prebuilt texture atlas as a single file over HTTP — this may slightly improve performance, but it has another disadvantage.

Flexibility. For my purposes, it makes more sense to build up the atlas dynamically at runtime, since you might not know exactly what textures are needed and when (due to the nature of my application). Also, I wanted to support "cascading" textures, where multiple packs are loaded each providing possibly a subset of all textures, and the first pack with a matching texture takes priority. With unzipping at runtime in the browser, this technique was very easy to implement (without the latency cost of individual texture file requests).

And for compatibility with img src, and other HTML file references, I just convert the unzipped file to an HTML5 Blob then request its 'blob:' URI. 'data:' URIs would also work, but blobs are widely supported by modern browsers (unlike 'filesystem:' URLs, for the Web Filesystem API supported by Chrome) and don't need to encode the full file contents in the URL. The complete process, including unzipping, matching, blobbing, all happens fairly fast, have not ran into any noticeable performance issues.

(Note: technically I'm not using Stuart Knightley's JSZip, but Kris Kowal's zip module https://www.npmjs.org/package/zip - I can't recall why as they are both available on NPM, but its the same idea).