Zanzlanz

Great question :D It's similar to the one I just answered before yours, about modding.

---

When block properties are general, such as name, color, material, and flammability, for example, they all fall under the blockData structure, which is a massive table of all blocks and items.

---

Let's take a pumpkin for example (hopefully this looks okay without code formatting):

---

blockData["pk"] = {
name: "Pumpkin",
identifier: "pumpkin",
tool: false,
mining: {WoodenAxe:25, StoneAxe:25...},
isWood: true,
pistonDrop: true,
flammable: true,
flamRate: 700,
shiftClickBlock: true,
placeable: true,
endermenCanChange: true,
color: "orange"
}

---

"pk" is the identifier I refer to in the code whenever I want to access the block data. I have a function (getBlockData(id, property)) that will retrieve the block's information easily and still handle any errors, in case a block doesn't exist or something.

---

But as you can see, each block can have a ton of properties, and it's super easy to add. I can set something to "stairBlock" or "halfBlock" and it will be treated like stairs or slabs for collision.

---

Now when the behavior of the block is unique, you'll often find it doesn't have a property. Slipperiness and bounciness haven't yet been converted to block data, for example. Currently the system just asks if the block underneath is an ice block, and if so, make the player (and mobs/items) slide.

---

There's a whole set of behaviors for each block that happen every frame. Or when you place it, break it, or shift-click it. These behaviors are currently scattered throughout the program, a lot of it being directly on a giant "block type" MovieClip which contains instances of all the blocks you see in the world. It's a mess, and everything will eventually be moved to the main code (that'll be in the two updates after 1.29, actually!).

---

:3

View more

Maybe!! It's a bit tricky to make an entire game data-oriented, but there's definitely a good level of flexibility with blocks, for example.

---

I'll get a bit technical with this, so sorry if it's confusing :3

---

As you may know, I'm still re-coding Mine Blocks to separate logic from the rendering, which makes it more data-oriented (think of it like... loading a simple text file to determine was properties each mob has, or what color a block is). Right now I'm doing this conversion to mobs.

---

Let's take skeletons and zombies. They're very similar, and run on the exact same logic now.
However, skeletons have "attackProjectile" enabled and "attackContact" disabled, and that's mostly how their behaviors differ. Skeletons can now shoot projectiles, while zombies can only attack by hitting you. This change is a simple thing that can turn on and off for each type of mob.
They also have different sound effects, animations, and item drops. These are just lists of data that can easily be swapped out during the game, making it extremely easy to "mod" the sound effects of zombies to sound like skeletons, or make all zombies drop 100 lemons when they die. xD
So essentially, a mod would simply be adding a new mob that swaps these various behaviors. It's totally possible to make a creeper that sounds like a wolf, shoots snowballs rapidly, drops diamond pickaxes when it dies, and is only hostile to spiders...

---

Apart from mobs, this type of system can be applied to blocks, items, player actions, visuals, and so much more. And as soon as you open these systems up for any player to be able to edit, you end up with a modding API!

---

The one huge limitation right now with a modding API is that it would not be able to support custom code. So, you couldn't make creepers do backflips unless it was officially supported as a mob behavior. If every aspect of the game could be generalized and dynamic, it could have a separate parser for modding which would be a "Mine Blocks Programming Language" in a way. This is what commands in Minecraft are turning into, and I intend to continue making commands more complicated in Mine Blocks to add similar features.

---

And maybe some day I can be able to get around these complicated limitations by porting Mine Blocks to JavaScript, which allows an "eval" function (it can run code that was passed to it as a text file, during the game).

---

These issues would apply to both Mine Blocks 2 and 3 as well. It depends what programming languages they'll end up being written in. It'd be really great to design both of them to be fully moddable - it's better to start designing that early, which is super helpful. Mine Blocks has been hard to work with because it was not designed to be flexible like that. With every update, it's been improving a ton though. xD

---

That was WAY more than you wanted to know! :D But hopefully it was interesting!

View more