Programming in Minecraft (Redstone) - how to measure program size?

Question

Since programs may be created in vanilla (un-modded) Minecraft using redstone to create logic gates (and more), someone could create such a program for a challenge on this site.

How would such an entry be scored?

Some possible scoring methods:

• Blocks used (placed redstone counts as a block)

• Redstone used (redstone is also used in crafting redstone torches, repeaters, and other similarly useful components)

• Volume of the minimal bounding rectangular prism (same as blocks, but includes air blocks)

Note on testing:

Buying Minecraft is not required to test a program!

• Play the demo version:

  1. Start a LAN world
  2. Turn cheats on
  3. Use /gamemode 1, (or 2 or 3) in the chat/console to use Creative Mode, Adventure Mode and/or Spectator Mode, respectively. Creative mode will allow you to place any blocks you want. The demo starts in Survival Mode. Note that the demo ends after 5 in-game days (1 hr 40 min), and the world will have to be reset (wiped/restarted) to play more.
  4. If the program is posted with a .schematic file (useful for complex programs), you can install a mod for your demo (or purchased) version of Minecraft that can import it. MCEdit and WorldEdit are two popular mods that can do this.

• Use a redstone simulator. These are separate programs with partial functionality from Minecraft, useful for circuit creation, simulation, and exportation. You will probably want to try a few before choosing one to stick with.

  1. Baezon's Redstone Simulator (download)
     • Has the ability to export as a .gif
     • Copy/Paste functionality
     • Has the ability to simulate North/South lever functionality like Minecraft has
  2. Mordritch's JavaScript Redstone Simulator (web)
     • No download required
  3. ... and many others. Just search on Google.

Answer 1

There is now an MC Standard for bytecount.

With the 1.10 update, they introduced a block called the "structure block", which creates a .nbt file representing a structure in its entirety that can be measured in bytes. As this is a Minecraft standard for converting builds into bytes, this should be our standard as well.

Answer 2

Bytes ≡ Functionality

I love Minecraft! Here's my two cents:

• Redstone-related items (i.e. items that interact with redstone) should be each 1 byte, except for:
  • Command blocks, whose byte count should be 1 + length of inner code (Or 2 + length of inner code, if you are using version 1.9 or above, as this version adds an orientation to command blocks. I would add another byte for conditional/unconditional mode, but methinks that's a bit too much.. Ideally, a command block would consume more bytes, since it can have the attributes of Impulse/Chain/Repeat; Conditional/Unconditional; and Always Active/Needs Redstone. I am thus tempted to say that a command block indeed consume 4 bytes per default; however, since these features are as of yet unreleased).
  • Air blocks, which should be 0 bytes.
• Blocks should count as 1 byte, keeping in mind:
  • If they compose the mandatory floor of the "program". This can be thought of as a construction on an infinite plane; the base does not count towards the byte count. (I.e., flatlands.)
  • Buttons, levers, methods should be counted 1 byte, as this is similar to collecting input.
  • The placing of blocks in a certain place (e.g. placing sand atop a command block which waits for the sand to be placed there) is 0 bytes, as this is user-action.
  • Barriers should count as 1 byte, since they have physical interaction with the world.
• Entities should be 2 bytes: one for the position, and one for the spawning of the mob.

---

This still doesn't address the new command blocks added in the snapshot and future updates; I would say these still count as 1 byte, but I don't know enough about them. I also hesitate to say anything special about pistons and sand, because they seem like they should be 1 byte, but they do move; that is, I don't know how to score movement. If asked, I would lean towards the 1 byte option.

Answer 3

Byte size of a corresponding valid .schematic file

Easy to score and has no major issues with entropy. The only problem is, of course, that the byte counts are going to be a lot higher than one would desire, but I thought I'd just post this as one possible option.

Answer 4

Minimal Bounding Cuboid Volume

Only for things without Command Blocks!

The volume includes any air blocks, non-solid blocks, and blocks that are supporting redstone dust or other components.

This is the simplest and most natural way to score Minecraft submissions. It's a direct measure of space taken up, just like a byte count is the amount of memory taken up.

I don't have scoring method for builds that include Command Blocks, but I think this is the obvious choice when Command Blocks are not present (if we even allow such submissions...).

---

Perhaps for things with Command Blocks the cumulative byte count could be counted and reported alongside the block volume count (since it's kind of an apples and oranges thing). So the title of a Minecraft submission might look like #Minecraft - 20 blocks, 17 bytes.

Answer 5

Byte size based on per block diskspace

In an earlier version (1.2), minecraft began getting a lot more blocks than before. This made the developers rewrite the code and use a short instead of a byte (I say this from experience), thus increasing a block's size to 2 bytes in memory. The disk space however is different from this. Minecraft blocks can only have 4096 different ids, thus making them take up 12 bit (1.5 bytes) each.

This format is the so called anvil file format.

Reference: http://minecraft.gamepedia.com/Anvil_file_format

The text in the command blocks remained the same, a character can take up a byte, as in "normal" languages.

Answer 6

In light of new updates, I figured sizing of MC programs could be reconsidered.

These only apply to the new features and the other answers that address command blocks, entities, etc should be included in the total byte total. However, most code golf may just be solved using just these new features and no blocks (the use of the player is arguably irrelevant)

1.12

1.12 introduced function files that hold commands like a text file. Commands are listed line by line. Unlike command blocks and redstone, these require no in game blocks and only mcfunction files.

These function files are stored in the data directory.

.minecraft
|- saves
   |- 'worldname'
      |- data
         |- functions
            |- 'namespace'
                |- func-name.mcfunction

These files can be run with the following command in game:

/function [func-file]

Ex: With function file, test in namespace test

/function test:test will run the function

(there is an alternative method: /gamerule gameLoopFunction [func-file] but this is obviously longer. This will, however, loop the code if it is necessary. More on this later.)

There are two things to keep note of:

• Functions can call other functions inside of them and therefore should be counted as multiple files are.

• Functions can call themselves. This is recursion and is the only way to execute commands in a loop in one tick in game.

At this point, we can use the normal method of calculating bytes through the function file's byte count.

Then we should add the bytes of the line to call the function in game.

Total Bytes = Bytes of files + Bytes of ingame function call

Extra:

It should be noted that in Minecraft, the namespace minecraft is automatically added if not defined. Therefore, you can save the maximum amount of bytes by using a single letter function name stored in a minecraft namespace.

i.e. `/function a` for `a.mcfunction` in the `minecraft` namespace

Looping in mc can be done via: gameLoopFunction and recursion

• gameLoopFunction is done via the gamerule command (/gamerule gameLoopFunction.). This will loop the function every tick (minecraft divides ingame stuff in ticks. 20 ticks = 1 seconds (mostly))
• recursion is done when a function calls itself (as you would). This happens within a tick.

Do keep this in mind when designing your solutions for the lowest amount of bytes.

1.13 (currently in snapshots)

In 1.13 (the dev. versions of Minecraft reveal what 1.13 will be), datapacks have replaced the system for functions. Datapacks can be zipped and still function within the game.

A new addition to 1.13 removes the gameLoopFunction gamerule in favor of function tags. A JSON file can be included at `worldname/datapacks/[datapack-name]/data/[namespace]/tags/functions/[file-name].

If the JSON file is named tick.json and is located under the minecraft namespace, all functions listed as a value will be called every tick (like the old gamerule).

These bytes should be included in the total calculation. NOTE: it should be known that calling the function w/o adding the function to the #minecraft:tick tag is completely fine.

The bytes of a valid, zipped datapack should be added with the following lines:

/datapack enable [file-name] and /function [file-name] if function is not added to the tick tag.

** Total Bytes = Bytes of zipped datapack + bytes of following ingame commands **

Answer will be updated in light of new changes

Answer 7

Relevant blocks. These are

• Any Redstone component
• Any component relevant to the structure (blocks holding up redstone, doesn't include the floor)
• Any block that would remove functionality if changed (air blocks that remove functonality when filled, "normal" blocks that remove functionality when removed)

Command blocks are 1+inner code size

Filled blocks (chest, dropper) are 1+amount of stacks inside (where a filled slot is 1, size of stack irrelevant)

Exception to the above rule: items that need nbt data (a pick that MUST be damaged for the structure to work): 2 bytes

But: Redstone can't be compared to other (textual) languages

Answer 8

Redstone-Related Items Placed (bytes)

Typical Redstone Items Placed (found in the Redstone section of the Creative Menu)

I would count these as 1 byte each.

Comparator-Responsive Items Placed

I would count these as two bytes. Hoppers can output with a comparator from 0 to 15 redstone length in output. Similarly, the use of item frames to hold information or any other storage item should be counted as two bytes.

Filler Blocks Placed

Dirt or the like, as long as it isn't used for redstone transmission, should not be counted. If they are used for redstone transmission (passing power through a block with a torch/repeater/comparator), it should count as a byte.

Command Blocks

Command blocks should be counted as three bytes in version 1.9 but one byte in all other versions, as command blocks have 12 "states" in version 1.9. The text inside should count byte-for-byte there as well.

Entities

Entities would be tricky to count. If there were a definite restriction from the several hundred variations of several hundred entities one could have in the game, this would be easy to score. However, since that would be improbable, I would consider @Cᴏɴᴏʀ O'Bʀɪᴇɴ's solution to this with two bytes.

Dummy Players

These should remain uncounted, except for the command block source that generates them.