Hi gang!

Editorial

I recently updated the very first blog I wrote which is a beginners guide into one of my favorite Minecraft features: the commands and their blocks, something which I usually refer to as Minecraft scripting. In that post I briefly explained the concept of commands; how we use JSON formatting to construct these and how the extra parts of a command are basically nothing more but a collection of carefully formatted (NBT) properties which group together. For example: to give an object a name you'd need the Name property which is part of the display:{} "collection" which in its turn can be an extra part of your command.

But commands are only one part of what you need to know about if you want to dive into the wonderful world of Minecraft scripting. Because if you want to get serious with all this then sooner or later you are going to need the dreaded scoreboard feature. A function which has managed to confuse many players, and don't be ashamed if you're one of them!

The scoreboard is honestly not as hard as some sites or tutorials make it seem. The trick though is to understand the fundamental basics and then use those to fill in your own needs. And that's where most tutorials utterly fail (in my opinion anyway). So hopefully I can do better here.

Trying for yourself: I'm going to add quite a few examples which you can follow along with. Just keep a creative world ready, make sure you have cheats enabled (so that you can use commands) and then just follow the examples.

Let's try to score some board ;)

What IS the scoreboard anyway?

Seriously, how do you expect to use something if you don't understand what it is or how it works?

The scoreboard is a Minecraft mechanic which, as its name implies, keeps track of pretty much everything that goes on in your game, usually directly related to entities ("mobs and players" to keep it simple for now) and the things they do in the game:



If you're in a Minecraft game then press escape to pause, find the "Statistics" button right to the 'Advancements' button and have a look for yourself. Pretty much everything you did in the game got noticed, counted and archived here. From how many mobs you killed (or how many times they killed you) right down to less dramatic things such as the amount of times you opened a chest or the amount of times you jumped up and down.

Even all your interactions with the blocks in the game are carefully registered:

Objectives, criteria and triggers

So how can we use all this stuff? Well, first we need to dive a little deeper into the scoreboard because although we now roughly know what the scoreboard is and does, we still don't know how it actually works.

Minecraft uses a series of triggers which perform certain actions whenever something happens in the game. For example: when you kill a creeper then a few things will happen:

• You get a death animation.
  
• Some loot may (or may not) drop, this is determined by the loot table minecraft:entities/creeper.
  
• And finally some statistics will change: you killed one more mob, you killed one more creeper in specific and you probably picked up one or more items (if the creeper dropped any loot). All those actions get tracked individually.
  

This is a mechanic that happens within the game and something we can't directly control. But we can make use of it ourselves, which is where objectives and criteria come into play.

An objective is something which you add to the scoreboard so that Minecraft can track its value for you. It could be a real score (while playing a game for example) but it can also be anything else you'd like to keep taps on. Do you know the saying "thanks for all the fish?". Doesn't matter if you don't, but I just thought of it so let's use that and imagine that we're going to add a "fishy" objective to the scoreboard. This is going to track how many fish we have (seems pretty relevant with regards to Minecraft 1.13 too!).

So now we have made up an objective, but that's not enough. Next we need to tell Minecraft what to do with it. In other words: we need to set a criteria for the objective so that Minecraft will know what the objective is all about. And this is where things become interesting...

Tracking or triggering?

There are two main types of criteria: tracked and triggered (not official names!).

Remember how I started this guide by telling you how Minecraft basically keeps track of everything that happens in the game, and how we could use that ourselves? If we assign our objective to a tracked criteria then Minecraft will automatically update the value for us whenever something happens in the game that matched the criteria.

Time for an example (you can follow along)!

One criteria is minecraft.mined:minecraft.stone. So if we assign this criteria to a new objective then the value of our objective will automatically increase with one every time we mine a stone block. Let's see if I'm right!

First we'll add the new objective to the scoreboard, use this command:

• /scoreboard objectives add mystones minecraft.mined:minecraft.stone
  

You can also add a so called "displayName" but let's ignore that for now. Keep in mind that tab completion is a thing, but you're probably going to have to type the whole criteria. Of course, in this example you can also just copy & paste :-)

Next stop:

• /give @p diamond_pickaxe
  
• /give @p stone 16
  

Give yourself a pickaxe, give yourself some stone (if you're in creative mode you only need one) and then place some stone blocks. Don't overdo it because you're going to have to remove them the hard way ;) Then switch to survival mode and get mining!

After you're done it's time to check if this scoreboard thing actually worked:



Use this command to check for yourself:

• /scoreboard players list @p
  

If you look at the screenshot above you'll notice that I have 10 cobblestone in my inventory (3rd hotbar slot) and my "mystones" score is also 10. In other words: every time I mined a stone block Minecraft increased the mystones objective for me by one. Pretty cool right?

There are tons of different criteria available, almost every imaginable action is covered by one. Some (obvious?) example:

• Player is killed by a member of team "X" ('x' is one of the 16 team colors)
  
• Player broke, mined, killed, used or crafted something ('something' being any of the available blocks or mobs in the game, which is a lot of different items!).
  
• A players health, xp, or kill count.
  

And that fishy objective I mentioned earlier? Well, there are even criteria for that. For example: minecraft.used:minecraft.fishing_rod (keeps track of how many times you use a fishing rod), or minecraft.killed:minecraft:cod; this would trigger as soon as you killed some cod "the old fashioned way" (using a sword or axe). And if you start fishing then you'll most likely trigger minecraft.picked_up:minecraft.cod eventually (as well as some of the other fish criteria of course).

One important detail you need to keep in mind is that using objectives will have no impact on what Minecraft tracks internally. So if you set up an objective which tracks how many animals you killed and then reset that objective then the only thing which will be reset is the objective's value itself. Minecraft would simply have added your kills to its general statistics (the one I showed earlier) and be done with that. So any resets you perform will only affect the objective, not the internal scores themselves.

So what if you want to track something which isn't automatically tracked by Minecraft?

(manual) triggers

Here you see two farms I build (both are my own design). In the background is a rather overcomplicated pumpkin / melon farm (it 'works', but sometimes also stalls when the chunks get unloaded (I made a new & better design in the mean time)) and in the foreground you see my much better sugarcane farm. It's a simple design: the cane grows to the 3rd block, the observer detects this, triggers a piston below it which then breaks the canes middle block. The two canes then drop in the water and get collected.

So... how is Minecraft going to detect all this? It might be able to detect that a sugarcane block got broken but there's no way that it will be able to link that action to a player. After all: it isn't me but the piston that broke the block.

Fortunately Mojang also thought of this and they have devised two scoreboard criteria specifically for this situation:

• 'dummy': Any objectives which get assigned to the 'dummy' criteria will be completely ignored by Minecraft itself. So if you want to update the objective (adding, removing or resetting values) then you're going to have to do this manually using the /scoreboard command.
  
• 'trigger': This is basically the same as the 'dummy' criteria with one major difference: (regular) players can also control this objective themselves using the /trigger command.
  

Summary

So to summarize this section: You can add several objectives to the scoreboard and each objective needs to be linked with a criteria. The criteria determines how Minecraft is going to treat the objective. If you use the dummy or trigger criteria then you will need to manually set (or update) any values, but if you use any other criteria then Minecraft will update the objectives value ("score") for you automatically as soon something happens that corresponds with the criteria. And there are criteria for pretty much every possible situation or action.

Tags

Now, objectives are fun and all but what if you need to make a quick selection of some sort?



Here I have a few animals ("entities") which I either 'invented' or summoned in one way or another. All have a little story behind them. LlamayamiKun is my friend Aya's favorite pet which get's spawned using a very special spawn egg. It's the result of some spawn egg experimentation; the 'LlamayamiKun spawn egg' will spawn the llama as you see it here; so including the carpet, chest and even a little something in that chest.

Then we have Toast the rabbit which helps remind me that you can name mobs after which they'll start acting a bit weird. Dolly and Polly (don't ask ;)) and even a horse from the period when I started experimenting with their stats (basically checking for another friend of mine what the odds were with regards to breeding and gaining better stats).

As such this is a group of animals which I don't want to get rid off. Sure: I can easily re-create them if I want to but that's not the point. So how could I tell Minecraft: "Kill all the sheep in the world except Dolly and Polly"?

Well, I suppose I could use the 'name' selector (@e[name=!dolly,name=!polly]), but that's quite a bit of typing. Besides: my horse doesn't even have a name, so how would I deal with that?

The solution, you might have guessed it, are tags.

/tag, you're it!

Tags allow you to 'mark' entities with a specific name of your choosing; any name you want for any entities that you want. And that makes it much easier to make selections. And don't get fooled by the separate /tag command: tags are a scoreboard feature. However, because it became quite a hassle to use them with the /scoreboard command Mojang has decided to assign them with their own command.

So.. in my example above I tagged all those animals as 'pet'. So, while standing in the animal pen I used this:

• /tag @e[distance=..15] add pet
  

Meaning: tag all entities within a maximum radius of 15 blocks and add the 'pet' tag. So I 'tagged' all my pets.

And that gave me access to commands such as these:

• /kill @e[type=sheep,tag=!pet]
  

Meaning: kill all entities with type sheep (so: kill all sheep in the world) except those which have the 'pet' tag assigned to them. So as long as I remember the 'pet' tag there is no way that I'll accidentally kill Dolly & Polly.

You basically use tags every time you want to 'mark' something (usually an entity) so that you can more easily address those in later commands.

Time for an example (and you can follow along again)!

Don't feed the animals!

This is going to be a bit of a silly example, but still a valid one.

So I have this group of animals. What if someone were to come along and started feeding them? If we're not careful then I'll soon be looking at a pen full a sheep, and that's no good to me. I suppose I could place a sign but that could be overlooked. Instead we're going to use a command block using the /title command. And to make sure that this only affects players who come close(r) to the animal pen we'll be using the distance selector too. 12 blocks should do it:

• /title @p[distance=..12] title "Don't feed the animals!"
  

We need this to happen constantly so I'll just place a repeating command block, set it to always active and we're done.

... or are we?

See, right now every player who comes within this 12 block range will get this title displayed and it will never go away as long as they are in range, it is a repeating command block after all. But that gets annoying and it also hinders you from looking at the animals. Actually... the whole thing will go crazy and won't even display properly:



This is no good! If only we could tell Minecraft that it should be doing this just once. And what do you know? We can!

We're going to update our previous command so that it also checks for a tag. Rather it's absence actually, so:

• /title @p[distance=..12,tag=!warned] title "Don't feed the animals!"
  

Now we'll be warning every player within a 12 block radius that doesn't have the 'warned' tag. Therefor every player who comes into range for the first time will get this warning.

Then we need to actually tag the player. We can do that by adding a chain command block and set it to conditional and always active. We'll be adding this command:

• /tag @p add warned
  

And voila:



It showed me the warning, it then added the tag and eventually the warning ('title') disappeared and that was that. Easy, right? And you can easily expand on this as much as you'd like. For example you could reset the tag every (in-game) day so that there would be a new warning issued.

Summary

You can use tags to quickly 'mark' an entity so that it'll be easier to address them later within commands (specifically the selector part such as @e, @p and so on). Although we use the separate /tag command for this the feature itself is actually part of the scoreboard mechanic.

Show me what you got!

So now we know what the scoreboard is, that objectives can contain a certain value ("score") and that they are assigned to criteria. Usually objectives get updated automatically but we can also restrict that to commands only. And finally we've just seen how to mark entities in the game using tags.

But what good is keeping a score without being able to actually see its value, preferably in an easy way?

Well, there are three different ways to show the value of an objective in the game:

• list; if you set the display to 'list' then the objectives value will be displayed after the name of the player(s) in the main overview (the one which you can see when pressing tab).
  
• belowName; as its name implies this will show the objectives value below the players name. While you can't see your own name you can see those of others. So the objectives value is shown below that.
  
• sidebar; this is a special area at the right side of the screen. Its main use is to show the value of one objective for different players at the same time. You can already see an example of this in some of my screenshots above.
  

All of this can be set up using the command /scoreboard setdisplay.

Keep in mind that you can only use 1 objective per display type, so at best you can display three objectives at the same time.

Ghost players

When we're using a 'tracked' objective then this will get automatically updated every time a player performs an action. But as I've mentioned before you can also set up 'triggered' objectives which means that you'd have to update an objectives value yourself. So what do you think would happen if you tried to do that for a player which doesn't actually exist?

Well, then you'd basically create a "ghost player" as I like to call it. It would keep track for the "player entry" even though the player itself doesn't actually exist!



Here you can see my (overcomplicated) pumpkin farm, I designed it right after the observer block was added to the game but in the mean time made a much better design. When a pumpkin grows it triggers an observer which will then trigger a redstone torch which you can see in the middle. This unlocks a hopper which then pulls out a hoe from the chest above it. That gets detected by the redstone circuit behind it which will then unlock the hopper above the chest; that's for the refill process.

When all hoe's have been collected a circuit at the other end detects it: harvests the pumpkins (the ground is pushed up which breaks the pumpkins & protects the plants, then two dispensers release water to collect the pumpkins), resets the "tracking routine" by returning the hoe's and the process can start all over.

Now: as you can see in the right part of the screen I actually keep track of the amount of pumpkins this has generated. I do so by triggering a command block during the harvest process which runs the following command:

• /scoreboard players add Pumpkins farm 8
  

And since the scoreboard only tracks objectives for players (basically 'entities') this means that a virtual player called "Pumpkins" gets created:


This allows you to create scores as shown in my screenshots. Basically it seems as if you're tracking three totally unrelated tasks (farming sugarcane and farming pumpkins) while in fact you're merely seeing one objective ("farm") for different, virtual, entities.

Real example: pie eating contest!

Originally I made this small arena for another kind of game but that didn't work out too well, and then Aya suddenly had this idea: a pie eating contest! Of course now we needed something which could track of who did what. And you probably guessed it by now: the scoreboard was the perfect solution.

So we have 2 things which we wanted to track: the amount of pie the player(s) ate but also the amount of damage they took (as you can see there is magma lying around). My idea was that taking damage sometimes also raises your appetite a bit.

Now, as I told you earlier you can only display one objective per area (list, belowName or sidebar) and if you want to display multiple scores next to each other then the sidebar is the most ideal place. And in case you're wondering: the only reason you don't see my name in the picture above is because I hadn't eaten any pie yet.

So, I first created 2 objectives:

• /scoreboard objectives add pie minecraft.custom:minecraft.eat_cake_slice "Eaten slices"
  
• /scoreboard objectives add hurting minecraft.custom:minecraft.damage_taken "Damage taken"
  

Then I set up the way these should be displayed. As you can see above the damage is displayed below our names whereas the eaten slices got displayed at the side:

• /scoreboard objectives setdisplay sidebar pie
  
• /scoreboard objectives setdisplay belowName hurting
  

And done! Because these are both tracked criteria I didn't have to do anything to make this work. Of course the only thing I did need to do was to replace those pie's and then reset Aya's score:

• /scoreboard players reset @a
  

Now we were ready to play!

So who won?

Well, that is a long story ;) When we finally started playing it became dark and since I mostly play in Creative I don't bother myself with sleeping. So it didn't take long for this to happen:


But eventually we decided to call it a draw:



Although Aya had eaten more pie slices she also took more damage, whereas I got it the other way around: I did eat less slices but also suffered less damage.

Easy gaming!

But as you can see all it took was placing some pie's, setting up a few objectives in the scoreboard and you had yourself a fun game to play. The scoreboard honestly isn't that hard as long as you know how it works. Something I hope you guys now do too.

And there you have it!

How to use the scoreboard in Minecraft. And if you still have any questions, be sure to leave a comment!