Minecraft Clones

These are just some of my thoughts on things that a Minecraft clone should probably do differently to Mojang's (well, Microsoft's) Minecraft, since a clone would be starting from scratch anyway and would be in a good position to fix some of the fundamental problems in the original game that are impossible/unlikely to be fixed by Microsoft.

Some of the Minecraft clones I'm familiar with so far are Terasology, Minetest, and Michael Fogleman's Craft. So far, Craft seems to do the most things "right" (as far as my list of fundamental improvements on Minecraft go) such as only storing changes to the blocks to disk rather than whole entire chunks, but more on that in a minute.

Disclaimer: I'm not a game developer. I am a software developer and have a particular interest in the technology used in games, i.e. I have the knowledge to write code for most given game mechanics and spend countless hours thinking about these sorts of things. I've read a lot about the technical internals of Minecraft and have read some of the source code to these clones, so this blog post is full of my own educated opinions on things. I may, at some point, take on the challenge of creating a Minecraft clone of my own, but until then these are just the things I've been thinking about over the last several months.

Fundamental Game Mechanics

Minecraft has a few fundamental design flaws that aren't likely to ever be fixed and are in all likelihood impossible to fix without horribly breaking the game (or at least without completely throwing away backwards compatibility and not working anymore with maps created by older versions of Minecraft).

Just to get this out of the way first: just because Mojang did it in Minecraft, doesn't mean it was the optimal way of doing it and that clones of the game should do it in exactly the same way. Mojang had the disadvantage of not being able to predict where Minecraft would go in the future (hindsight and all that), so some of the design decisions might've made sense at the time, but nonetheless they prevent certain features from being possible in the game as it exists today.

A Minecraft clone starting from the ground up is in a better position to learn from Minecraft's shortcomings and solve them from the beginning and produce a better game in the end.

Cubic Chunks

Minecraft divides the world into chunks, which are 16x16 blocks horizontal and 256 blocks vertical. This chunk system brings performance and world height implications. The world height in Minecraft is limited to 256 blocks, and they can't really remove that height restriction in the current chunk model. If they wanted to raise the height to, say, 512 blocks, they'd have to redefine a chunk to now be 16x16x512, meaning more data needs to be stored per chunk. That solution isn't scalable.

Instead, a Minecraft clone could be better served by making the chunk system cube-shaped, so a chunk would be 16x16x16 blocks. This would make worlds not only "practically infinitely" large horizontally (as Minecraft worlds are), but also infinitely large vertically. There would be no technical reason why the world height should be limited to 256, 512, or any other arbitrary number of blocks. For sanity's sake, servers might have a configuration option to set a maximum world height, but on a technical level you could build a tower that's 30 million blocks tall if you really wanted to.

Cube shaped chunks could also bring new biome-related features. In Minecraft, the biomes are only assigned on the horizontal level, i.e. a single block column from bedrock to the world height limit ALL have to be the same biome, i.e. Desert or Forest. With cubic chunks it would add more flexibility, and you could have height-dependent biomes, such as an underground Mushroom Cavern biome, or a floating Sky Island biome like in Terraria.

Nether below the world?

This idea may be controversial because the Nether dimension in Minecraft has an 8:1 scale ratio in relation to the Overworld, making Nether Highways useful for fast travel between locations on your Overworld.

However, with a cubic chunk system which opens the way to height-dependent biomes, the Nether could physically reside underneath the overworld, like how it is in Terraria. Just keep digging deep enough and you'll naturally find yourself in the underworld, where different types of monsters spawn and there's fire and brimstone and lava everywhere.

More Optimal Chunk Saving

In Minecraft, when a player wanders into unexplored territory, the game has to generate all of the chunks for the new area (16x16x256 block cuboids), and then the game saves the whole entire chunk to your hard drive. All 65,536 blocks in that chunk.

A better solution would be to do what Fogleman's Craft does. It doesn't save the whole entire chunk's data to disk, it only saves changes made to the chunk after its initial creation.

When you leave the game and come back later, the game would re-generate the "default" chunks, and then apply your saved changes as a "mask layer" over top of the defaults. So any tunnels you dug or castles you built, only the data for those modified blocks needs to be saved to disk.

This would bring so many advantages over the way Minecraft does it, and not just for disk usage reasons. One of my biggest complaints with Minecraft is that each new version tends to add new features to terrain generation (for example, new types of ores or new stone blocks that spawn randomly in generated terrain). If you already have an old Minecraft world and upgrade to the next version, your already-generated chunks do not update to include the new naturally occurring terrain features. You have to go out and explore new chunks to get the new features. Or otherwise, use a third party tool like MCEdit to delete chunks from your world, so that they can be regenerated by the new Minecraft version.

If the game only saved blocks that were changed, any new ores or stone blocks that would've generated in blocks that you've never touched, would appear there now. No needing to mess with MCEdit, and yet all your tunnels and houses and Creeper damage would be left intact between version upgrades.

And what if a new game version introduces massive terrain generation changes? i.e. so that a chunk that used to generate a mountain instead will generate an ocean?

Versioned Terrain Generation

This.

Each chunk generated and saved to disk could store the "generator version" of the terrain generation algorithm that was used to generate that chunk.

If a game update has to break backwards compatibility and radically change terrain generation (as Minecraft had to with the release of v1.7), having chunks remember their generator version would help here.

Instead of deleting all the old source code when you replace the generator, just add a version check.

if algorithm_version == 2:
    do_new_stuff()
elif algorithm_version == 1:
    do_old_stuff()

Then, an old world that got upgraded to a newer version of the game would have their old chunks still work as they expect, but have new chunks use a newer terrain algorithm. Or, they would have the option to say, "keep the ENTIRE world using algorithm version 1" and a world-breaking game update won't change the way their old world used to be generated.

Do Lighting Better

This one is debatable, and I'm not extremely familiar with OpenGL, so take this with a grain of salt.

One of Minecraft's big problems is that light sources can't be dynamic. So you can't be holding a torch and walk through a cave and see the lighting dynamically update as you walk. You'd think that dynamic lighting is a very basic feature in OpenGL and even the most amateur 3D game can do it, so why doesn't Minecraft?

In their case it has to do with monster spawning. Each block has to store its "light level", a value from 0 to 15. If the light level is low enough, hostile monsters can start spawning. Placing a torch, or breaking a torch, or turning a redstone lamp on or off, these events need to touch every block in their radius and recalculate that block's light level. This is an expensive computation, and you can see the game lag if you turn on or off a lot of light sources at once, i.e. by using a redstone circuit involving a large amount of lamps.

I would think a better solution would be to query the pixels on blocks for their brightness levels, and let OpenGL handle the dynamic lighting the "correct" way. Like, the mob spawning rules could say, "find a block that's at least 20 blocks away from a player. Okay, check this block's pixel brightness. Dark enough? Spawn a hostile mob. Otherwise, find a different block and repeat". But again, I'm not super familiar with OpenGL and don't know how possible this is.

An alternative would be to just change the mob spawning rules, and make them more like Terraria. In Terraria monsters can spawn pretty much anywhere, as long as the background tiles aren't ones placed by the player and as long as there aren't a large number of friendly NPCs nearby (so building a town creates a natural radius of anti-monster-spawning). The background tile part wouldn't make sense for a 3D game like Minecraft, but something similar could be worked out that doesn't rely so heavily on light levels.

Let's Talk Blocks

Another bad design decision IMHO in Minecraft is the block ID system. Especially earlier on, every little variation on a block required a whole new, distinct, block ID. Oak Wood Stairs are an entirely separate block than Jungle Wood Stairs. Birch Wood Slabs are different from Spruce Wood Slabs. And so-on.

In Minecraft, a block in the world had a block ID, and one byte worth of meta-data (actually, a half-byte, with value options between 0 and 15). Some blocks used the metadata to hold color information (the Wool blocks all share one Block ID, and they come in 16 predetermined colors, which coincidentally is the maximum number of variations you can squeeze out of a half-byte).

Wood Stairs can't do this because their half-byte metadata has to hold things like which direction the stairs are facing, and whether they're connected to other stairs (to form corner stairs, for example), so each type of wood has to have a completely new Block ID.

Minecraft duct-taped this to allow for more data to be attached to a block by introducing the Tile Entity system. Examples of Tile Entities are Chests, Furnaces, Enchantment Tables, and Cauldrons. They're basically blocks (they have block IDs), but they have arbitrary, unstructured metadata attached to them, to hold things such as their inventories (like with Chests) or their available enchantment level, etc.

The Tile Entity system isn't great though and it brings a lot of overhead to it, so if you have an extremely large number of Tile Entities it will lag out the game. So, in Minecraft's case, it wouldn't be possible to make every single block a Tile Entity, or to even make half the blocks Tile Entities, as it would probably harm the game's performance.

From poking around at the source code of clones such as Terasology and even Craft, it looks like they followed Mojang's flawed block system here, i.e. they'll have 16 colors of Wool and each Wool Block is a different distinct block ID.

A better system would be to think of this problem from the ground up and implement a proper, performant block system. For example, why should Wool Blocks be limited to 16 pre-defined colors? In Minecraft you can dye Leather Armor to pretty much any color imaginable, because Leather Armor has enough data to hold a full RGB color code. Wool Blocks don't, so you can only use a limited color set.

If the system were better designed, Wool Blocks could be any color, and you'd have the ability to recolor a lot of blocks, like in Terraria. In Terraria you can paint pretty much everything, stone, wood, all kinds of colors. In Minecraft this would require a metric ton of new Block IDs for all the types and variations of blocks in the game.

And About Plugins...

It is my opinion that a Minecraft style game should have a well defined vanilla version, with a default set of "plugins."

A plugin-based architecture is great, it's what Minetest uses. It allows for easily adding new types of blocks, crafting recipes, and features to the game. The base game itself can be composed of various "default plugins."

But, making too big a deal of the customizable, pluggable nature of the game causes users to be overwhelmed by choice. In Minecraft, a lot of people play the vanilla game, the one released directly by Mojang/Microsoft and they don't mess around with plugins.

But take for example the Feed the Beast mod pack for Minecraft. Did I say mod pack? I meant mod packs, because there are a ton of them. If I wanted to run my own Feed the Beast server and have my friends play it, we all have to pick one of these and agree on which one we picked. Can somebody use the Monster client mod pack and log in to a Magic 2 World server? I have no idea. Probably not. And this would turn away a lot of casual users. It turned me away and I consider myself to be more tech savvy than most.

This is a problem with Minetest, imho. Minetest wants you to mix and match your mods and create a version of the game you wanna play. But that will just lead to confusion when you want others to play with you.

A Minecraft clone should have a well defined "default" vanilla game that is highly recommended for all players to play. More tech savvy players can play with mods if they want, just like in Minecraft.

A good solution, I think, would be for most mods to be server-side. Mods that introduce new blocks, crafting recipes, and some game mechanics, should be able to work as being purely server-side mods. Clients connecting could download graphics and other assets needed by those mods, but the end user playing the game shouldn't need to worry about it. This isn't the case with Minecraft mod packs like Feed the Beast, where the client has to be playing with the matching mod pack that the server uses or else things will in all likelihood break in a very bad way.

tl;dr.

Minecraft clones should take their opportunity, as a ground-up rewrite, to do everything better than Minecraft did. Just because Mojang did something a certain way, doesn't mean it was the right way.