This page is undergoing updates, sections that are yet to be updated are marked.

Project ARENA served as a vital learning ground for understanding mob mechanics, behavioural patterns, and the application of random number generation (RNG). This experimental arena allowed players to test their skills against various mobs, tracking their progress through a kill score. The lessons learned during the development of ARENA have directly influenced the creation of xSnipez Games' popular annual Halloween Special and remain invaluable for other projects and game creation.

Project Goals

• Understand different mobs' behaviour and AI

• Practice RNG use cases and how to effectively apply them

Project Initiatives

• Create an arena environment for players to fight mobs in

• Implement variations of difficulty for the players to choose from

• Utilise difficulty variations in conjunction with RNG

Project ARENA categorised mob spawns into two distinct classes, otherwise referred to as a "Round Type": "Melee" and "Ranged". When a "Melee" class is active, only melee-focused mobs will appear. Similarly, a "Ranged" class will exclusively spawn ranged mobs.

Why separate 'melee' and 'ranged' mobs?

It is important to separate these two types of mobs due to ranged mobs attacking melee mobs incidentally. It is common for a ranged mob to hit another mob when aiming in the direction of the player. After observing AI behaviours, it was noticed that some ranged mobs do not retaliate upon being hit by their allies. In short, ranged mobs don't tend to attack their friends. This does, of course, remain untrue for all ranged mob types, yet this remains true for those observed. It is also the case that in the event of a ranged mob retaliating on their friend that they seem to rather quickly "give up" or "lose interest". These observations are markedly different in an event where a ranged mob type attacks a melee mob type. Melee mob types that retaliate tend to retain their interest (unless redirected by another source) and therefore attack the ranged mob type and more often than not kill the entity. Conversely, if they do not successfully defeat the ranged mob type, they will unfortunately perish themselves. This creates an undesirable dynamic in a Player vs Environment scenario.

'Melee' class mobs

The following is a list of melee mob types that could spawn if the "Melee" class was chosen:

• "Zombie"

• "Baby Zombie"

• "Husk"

• "Baby Husk"

• "Drowned"

• "Baby Drowned"

• "Cave Spider"

• "Creeper"

• "Charged Creeper"

• "Vindicator"

• "Piglin"

• "Piglin Brute"

• "Magma Cube"

• "Wither Skeleton"

'Ranged' class mobs

The following is a list of ranged mob types that could spawn if the "Ranged" class was chosen:

• "Skeleton"

• "Stray"

• "Pillager"

• "Witch"

• "Blaze"

• "Evoker"

How was the class chosen?

Class was chosen through random number generation (RNG). It was decided that the percentage chance for the "Melee" class to be chosen was 90%, and the percentage chance for the "Ranged" class to be chosen was 10%. These values were picked in the expectation that the "Melee" class would be chosen more prominently than the "Ranged" classification due to the nature of ranged mob types proving to be difficult when attempting to get them to work collaboratively with their allies. The 10% chance for a "Ranged" class translates to a 1 in 10 probability, so we can use a randomly chosen number between 10 values to decide the chosen class. In the project, the values 0 through 9 were used to determine the class; the "Ranged" class was assigned the number 9, and every other number would result in the "Melee" class being used if it was chosen. In summary, if the randomly chosen number is between 0 and 8, the class would be "Melee", and if the randomly chosen number is 9, the class would be "Ranged".

How did this work with commands?

To generate a random number, we first had to create a place to store it. We did this by creating a scoreboard objective, then adding what is known as a "false player" to hold the score for us. The objective was created with the following command:

• /scoreboard objectives add Mobs dummy "§aMobs"

All this command does is create a new scoreboard objective called "Mobs" and provides a unique display name of "§aMobs" (this translates to the word "Mobs" in a light green colour; the display name is only shown when the scoreboard is visible). Once the scoreboard objective was made, we needed something, or someone, to hold the score we wished to generate for us. As previously mentioned, we used a "false player" to hold the score for us ("false player" is the terminology given to a "player", score, that is added to a scoreboard objective that isn't an actual player). The "false player" was added with this command:

• /scoreboard players add "Class" Mobs 0

This command simply added a "false player" to the scoreboard objective we had just created called "Mobs" and gave it a value of 0. We could then manipulate the value and generate our random number. This was achieved with the following command:

• /scoreboard players random "Class" Mobs 0 9

The command states to generate a random number between 0 and 9 for the "false player" we called "Class" in the scoreboard objective we just created called "Mobs". The new value would replace whatever the previous value was set to.

Project ARENA allowed players to select between three options that would provide a different level of difficulty. The difficulty setting would determine what types of mobs would spawn, how many mobs would spawn, what type of gear they could have, and the difficulty setting for Minecraft itself. Whilst players couldn't directly control the difficulty on their own, they were given the option of "Easy", "Medium" and "Hard" before they began.

If players couldn't directly change the difficulty, how was it changed?

To select the difficulty a player wanted, they were offered the choice before they began their run. There was then a series of command setups that would go about changing this setting. The difficulty setting was dependent on a value stored in a scoreboard objective, the same objective we used above to store the class value (the objective that was named "Mobs"). The value was stored in a "false player" which was called "Difficulty". Depending on the value, the project's command setups would use it to determine the above-mentioned things required for that difficulty setting. To change the difficulty, a tag was used to bring up an NPC menu; this menu then had a button which would add a different tag, which would then trigger a system to run the relevant commands.

Why use an NPC menu and tags to change the difficulty setting?

Efficiency. A tag called "menu" would open the NPC interface when given to a player. This NPC menu then had 3 unique buttons which were labelled "Easy", "Medium" and "Hard". If you pressed the "Easy" button, you'd be given the "set_easy" tag; if you pressed the "Medium" button, you'd be given the  "set_medium" tag, and so forth. There was then a system which would identify players who had either the "set_easy", "set_medium" or "set_hard" tag and then trigger the commands necessary. 

How was the "false player" added?

Adding the "false player" was done by adding it to the already existing scoreboard objective. The scoreboard objective was called "Mobs". The "false player" was called "Difficulty". To add the "false player" to this objective, this command was used:

• /scoreboard players add "Difficulty" Mobs 0

How did the "open menu setup" work command-wise?

The "open menu setup" had the goal of opening the NPC interface. To achieve this, it used 3 commands. The setup needed to test for a player with the "menu" tag, open the menu for the person with that tag, then remove the tag from that person. The repeating command block was used to find a player with the tag. The command used was as follows:

• /testfor @a[tag=menu]

Once activated, the command would search for all players with the provided tag and then provide a successful output. Once the repeating command block had a successful output, the comparator would detect this and provide a signal to the impulse command block. Once the impulse command block received a signal, it would run the following command:

• /dialogue open @e[type=npc,tag=controls] @a[tag=menu]

This command would open the NPC menu for all players with the "menu" tag. The NPC selected was the one that was given the "controls" tag; this was done to easily identify that particular NPC. Finally, the impulse command block would provide a signal to the chain command block (provided the output was successful). The chain command block would then run the following command:

• /tag @a[tag=menu] remove menu

The point of this command was just to remove the "menu" tag from all players after the menu was opened. Doing this allowed the player to open the menu again after they were done, and allowed the system the chance to depower.

How did the NPC interface work command-wise?

The NPC interface had 3 buttons for controlling difficulty, these were: "Easy", "Medium" and "Hard". The commands behind each button were relatively the same, just some slight tweaks to the wording so the correct tag was applied. Each of the commands was laid out as follows:

• /tag @initiator add set_easy

• /tag @initiator add set_medium

• /tag @initiator add set_hard

Each button had its corresponding command to provide the relevant tag. The tag would then trigger the "configure difficult setup", so it could function accordingly.

How did the "configure difficulty setup" work command-wise?

The "configure difficulty setup" worked in a similar way to the "open menu setup" in that the system was triggered upon detecting an entity with a relevant tag. Three individual systems were combined together to create the "configure difficulty setup"; 5 commands each, 15 commands total. The repeating command blocks shown in the image were used to test for the relevant tags, below is a list of the commands used in all three of the systems (in order from closest to furthest as shown in the image):

• /testfor @a[tag=set_easy]

• /testfor @a[tag=set_normal]

• /testfor @a[tag=set_hard]

Just like the "open menu setup", the command would search for all players with the provided tag and then provide a successful output. Once any of the repeating command blocks had a successful output, the corresponding comparator would detect this and provide a signal to the corresponding impulse command block. Once any of the corresponding impulse command blocks received a signal, they would run the following commands (depending on which system is triggered):

• If the "set_easy" tag was found:

  1. /execute as @a[tag=set_easy] at @s run difficulty easy

  2. /execute as @a[tag=set_easy] at @s run scoreboard players set "Difficulty" Mobs 0

  3. /tag @a remove set_easy

  4. /tellraw @a {"rawtext": [{"text": "§7Changed difficulty to §aEasy"}]}

• If the "set_normal" tag was found:

  1. /execute as @a[tag=set_normal] at @s run difficulty normal

  2. /execute as @a[tag=set_normal] at @s run scoreboard players set "Difficulty" Mobs 1

  3. /tag @a remove set_normal

  4. /tellraw @a {"rawtext": [{"text": "§7Changed difficulty to §eNormal"}]}

• If the "set_hard" tag was found:

  1. /execute as @a[tag=set_hard] at @s run difficulty hard

  2. /execute as @a[tag=set_hard] at @s run scoreboard players set "Difficulty" Mobs 2

  3. /tag @a remove set_hard

  4. /tellraw @a {"rawtext": [{"text": "§7Changed difficulty to §cHard"}]}

The goal of these commands was to change the game difficulty score, the game difficulty itself, and alert players to the fact the difficulty had changed. Command 1 changed Minecraft's difficulty depending on which difficulty is set (this would change how hard mobs hit and stuff based on Minecraft's core difficulty changes). Command 2 updated the "Difficulty" score in the "Mobs" scoreboard objective (this was important, other commands used this value to determine different outcomes in the arena). Command 3 removed the tag from all players so the system didn't trigger a second time and endlessly loop. Finally, command 4 alerted all players of the difficulty changes.