Suggested A New Idea for a Module: Battle Bots

J Young Kim

New Member
Annually, there is a competition hosted by MIT (Massachusetts Institute of Technology) called BattleCode. In this competition, players write an AI to compete against other AI's in a game. With inspiration from this competition, I've decided to propose a module which would hold this type of competition. To be blunt in regards to the purpose of the module, the purpose is to create a way for people to create AI's for NPCs, and have the NPCs face off in some sort of battle. I believe such a module will be a great way for seasoned coders to test their skills out, and new coders to get introduced into coding.

For simplicity purposes when explaining the module, I will choose the Hunger Games as the game which the AI's will face off in.

General Gameplay using the Module

The general idea is that players will program a block which is equivalent to the functionality of the "Command Blocks" from Minecraft. Players will program the blocks, which will hold the code for an AI to be used for an NPC competing in the Hunger Games. After the player finishes programming the block, the player will head over to the "Battle Arena." There, participating players will place their programmed blocks on open (no block on it) "Code Accepter" blocks. Then, the participating players and the spectators will gather into a common room/area. Once the game official starts the game (via command line), everyone will go to the Cornucopia (see this for an example from Minecraft) as 'ghosts' (to be explained below). After a short countdown, the NPCs with AIs programmed by the players will start fighting for survival in the hunger Games. The fighting will occur for X minutes. After X minutes, in the case of having than one survivor, all the remaining NPCs can be declared winners, all the remaining players will be teleported to an enclosed box for a final battle or a random generator can decide on the winner. At the end of the match, everyone will resume their normal lifestyles (not as ghosts) and teleport to the "Battle Arena," with the participating players will have their coded blocks in their inventory.

Ghost Mode:

In Minecraft, when a player dies during the Hunger Games, they become spectators (see this video @ 5:00 for an example). Essentially, they will be able to fly around and view the NPCs competing. The spectators will not be able to see other spectators and left/right mouse clicks can be set to "Next NPC," which would teleport the spectator to an NPC.

Programming the Block:

Programming the Block:
The block can be programmed by right-clicking on it. The block will only be able to store one file of code, meaning that multiple files cannot be stored. In the future, a cool thing to implement is the ability for these blocks to "connect" so that one block can be a class, and another can be the "main."

Programming Language:
To be consistent, I would like the programming language format to follow the programming layout I mentioned in this thread. In summary, the programming language will follow a Python-like structure (for new learners to learn easily), and have many pre-defined methods, which in this case, can be "attack" or "moveNorth(number of Blocks)."

Testing the AI:

Obviously, even in the presence of no compiler errors, the program may have logic errors. Thus, I would like for a way to test the AIs. In the case that this module becomes popular, there won't be enough space in the world to test all the bots. Thus, I propose that there be a website which accepts the programming language used for the programmable blocks, and the website runs a few simulations using the code against others who would also like to test their's or just a default bot.

Ranking (Elo) System:

Since this is a competition, a fun thing to implement for players to have glory in competing in these games would be to have a ranking system. For every win or loss, a player's Elo rating will be affected, and Elo will be used to rank the players. Losing against higher Elo players will decrease the Elo less, and the high Elo players will gain a little Elo. However, winning against higher Elo players will increase the Elo by a lot, and lower the Elo of the higher ranked players by a lot. When the players have similar Elo, then the Elo gained/lost will not be small, nor large.

Every 6 months, Terasology can hold a tournament, with seedings based on the Elo System. The winner of the tournament can be in a 'Hall of Fame,' and winners (up to top 8 since ideally, 8 bots would play at a time) should receive a badge or something for the forums of Terasology, or some in-game title (i.e. having '[Top 8 in BattleBot] NAME_OF_PLAYER' as the nametag when using the chat. However, prizes, time interval between tournaments, and tournament rules are subjected to change based on what's popular (i.e. community wants top 16 should fight for 1st, 2nd, or 3rd, instead of top 8).

Structures Needed (StructureTemplates?)

  • Battle Arena:
    • The Structure that Accepts Programmable Blocks: The structure will be accepting programmable blocks to use for the match, This structure can be customized to be very cool: an idea is that an effect can be played depending on the status of the station (i.e. a matrix effect can be playing if a game is going on in the station and a clock can be displayed if the station is waiting for more players to start the game. I believe that it should look somewhat like a League of Legend's Nexus.
    • Other Misc. Stuff to Make 'Battle Arena' Cool: It would be cool to create arches for the entrances, and sculptures depicting the glory of the Battle Arena.
Some Events (not an exhaustive list):
  • onPBlockPlaced: This event is launched when a block is placed on the 'Code Accepter' block. The block will be checked for three things: if the block has code in it if the code has no errors, and if the block is a programmable block. If all the three criteria are not true, then the block will be returned to the player's inventory.
  • onAIKilled: When an AI has been killed in a game, it'll trigger this event. This will update all the UIs, as well as send a chat message broadcasting of the death to all players who toggled the chat for game updates. The event will also check how many more NPCs are in the game. If there remains only one, then the event 'onGameEnd' will be launched.
  • onGameStart: When the game starts, all the spectators will be teleported to the game with 'Ghost Mode' enabled. All the NPCs with the AIs of programmable blocks will be created on the NPC spawn blocks. This event will also send a message to all players who have game updates toggled on (see 'Toggle Game Updates' in the commands section).
  • onGameEnd: This will be called when the game ends. This will result in all spectators being teleported to the Battle Arena with 'Ghost Mode' disabled, with the programmable blocks being in the inventory of their respective owners. The winners of the game can be given an award too in their inventory. This event will also send a message to all players who have game updates toggled on (see 'Toggle Game Updates' in the commands section).
  • onGameCountDownStart: When the Game Official starts the game, then it'll start a timer. Once the time reaches zero, 'onGameStart' will be called. This event will also send a message to all players who have game updates toggled on (see 'Toggle Game Updates' in the commands section).
Blocks/Items Needed:
  • Blocks:
    • Programmable Block: This is the 'centerpiece' of the whole module. The programmable block will be the block which the players program and use to enter competitions. These blocks should not be craftable, and should be easily obtained via asking an Admin for the block, command line access for obtaining the block, etc. The programmable blocks can be dynamic in texture: if there is no code, there is no 'light' on the block, if there is code and there are no errors, then there is a 'green light', and if there are errors, have a 'red light' on the block. Used programmable blocks will remember the owner, and not allow others to edit the block. The name of the owner will be stored to display on the NPC during a match.
    • Sample Block: This will be a programmable block that contains a bot which works decently. It acts like a programmable block, except it has code from the start.
    • Code Accepter Block: This block will be placed on the ground, connected to structures meant for accepting the programmable blocks for the game. Once a block is placed, it'll send an 'onPBlockPlaced' event.
    • Waiting Floor Block: This will be the blocks which will be placed in the area where the spectators gather to watch the game. When the game starts, all the players will be set to 'Ghost Mode' and then teleported to the game site.
    • NPC Spawn Block: The NPC spawn block will be on the game site. At the game site, NPC's will be spawned on these blocks at the start of the match.
  • "Items":
    • NPC: These will look like players in Terasology. They will act according to the script given by the programmable block. The owner of the script will have his or her name (Player ID) hovering above the player.
    • Handbook Of Coding (Book?): This will be an in-game book, with a link on the first page of the book if the player decides to view the information in a browser. The book will essentially contain information on how to get started coding an NPC, and the API which the NPC bots use.
User Interfaces:
  • When Coding:
    • IDE: The IDE, in its most simplistic form, can be like a notepad. Since a Python-like language will be used, an indent managing system would be HIGHLY recommended. The IDE should take up a most of the screen since coding is not something a player should be doing as he or she is playing the game. A very good example of an IDE that can be used as a model is Sublime Text.
    • Buttons: Buttons to be around the IDE
      • Compile: This button will 'compile' the code. If there are no errors, a sound or another text should be displayed to indicate that no errors were found. However, if there are errors, it'll highlight the areas of the code which errors exist, and hovering the mouse over the highlighted area will give a tooltip on what the error is and possibly how to fix it.
      • Save: This button will save the code. When saved, the code should not disappear after a player has exited the IDE, nor after the block is broken.
      • Clear: This button will clear all the code written. It'll result in the IDE being empty.
      • Undo: This will undo the most recent action taken with the code.
      • Redo: This will redo the most recent action undone.
      • Close: This will close the IDE.
    • Name: This will be the name of the programmable block, so that if one creates multiple AI's, the player won't be confused as to which is which. Ideally, the name should hovering above the top of the programmable block.
  • Map: This will be like the minimap in many games (i.e. Call of Duty's minimap), and will be toggled via 'Get Map (Game Number)'. For spectators, all the dots will be the treated equally. For players who made the AIs participating in the match, a blue (or any distinct color) can represent their bot. More information as to the information it presents will be explained in the commands section (read about 'Get Map (Game Number)').
  • Game Info: This is a UI which will be toggled by the command 'Get Match Info (Game Number),' and will give information regarding the game. It should look like the 'mcMMO Stats' UI. More information as to the information it presents will be explained in the commands section (read about command 'Get Match Info (Game Number)').
*The Placement of the Buttons, I will leave to the Designers/Coders

These commands will be limited to the Game Official. The parentheses are parameters.
  • Start: This will start the game, and invoke the 'onGameCountDownStart' event. If the 'TimerBeforeStart' is set to 0, then the event 'onGameStart' will be invoked instead.
  • End: This will end the game, and invoke the 'onGameEnd' event.
  • Pause: As the command implies, this will just pause the current game. If the 'pause' command is used when the game is already paused, the game will just unpause.
  • Unpause: As the command implies, this will unpause the game. If the Official accidently uses the command when the game is already unpaused, it'll automatically just pause the game just in case.
  • Set Timer (Time in minutes): In the game, to prevent infinite looping bots from dragging out the game forever, a time limit will be imposed. This time limit will be set by this command.
  • Set TimerBeforeStart (Time in Minutes): When the official starts the game, a timer will first run to allow potential spectators to get to the Battle Arena to watch the game, or allow players to place a Programmable block if there are still open slots.
  • Set End Method (Method #): As mentioned earlier, there are cases where the game will reach the time limit. This may be caused by two bots refusing to fight each other due to some bug. At that point, there will be a method of ending the game. This command sets how the game will end, with 'Method #' specifying the number associated with the 'ending plan.' For instance, one the plans could be that all surviving bots will be declared winners or another can be that one surviving bot gets chosen randomly as the winner. Of course, some sort of sudden-death match would be ideal.
*There is a lack of a 'kick' command because bots can't cheat, they just follow a script. In other words, if one bot is better than another, it's a result of the script. However, if the script changes (i.e. the melee attacking distance), then a 'kick' function will be required.

These commands will be available for the players to use:
  • Join Game (Game Number): There will be cases where a player would like to watch a game from 'Ghost mode.' In this case, the player will use this command to join the game they desire. There should be error checking so that a player doesn't enter an invalid game (number doesn't exist or the game with the game number is not occurring). This command can be used while in another game.
  • Leave Game: This game will teleport the player back to the Battle Arena and leave Ghost Mode from the game they were spectating. This command is only valid if the player is in a game.
These commands will be available to both players and the Game Officials:
  • Get Match Info (Game Number): This will give the player the NPCs left in the game, the Health Points of each NPC, and the time remaining. If the game number is invalid or the game with the game number is not occurring, then a simple "Non-existent or Not-occurring Game." Information will be provided via a UI. If in a game, the Game Number is optional, and if omitted, the information from the game they're spectating will be given. The UI can be untoggled by calling the same command.
  • Get Map (Game Number): This will give a UI which represents a map of the Hunger Games, with dots representing the NPCs (updating real-time). The dots can 'blink' temporarily if taking damage, or the dots can progressively change color to red as the HP goes down. The game number must be valid for the UI to display. Otherwise, the command line will notify the player in a user-friendly manner that the game number is invalid. If in a game, the Game Number is optional, and if omitted, the information from the game they're spectating will be given. The UI can be untoggled by calling the same command.
  • Toggle Game Updates: When this is toggled on, the player will receive notifications regarding the game via the chat. An example of a chat message when a chat has finished would be 'NPC A has been slain by NPC B in Game 4... 5 survivors remain!' An example of a chat message when a game is about to start is 'Game 2 is starting in one minute! There are X spots left for Programmable Blocks!' An example of when the game ended would be 'NPC A is the winner of Game 5!'
  • Get Rank: In the console or the chat, the player will receive the Top 3 players who are the best at the game, and below the list, have the rank of the player who called the command. If the player has never competed in the game, then it'll list 'N/A: You should participate in the games!' Next to each name, will be a score, representing the Elo.


Org Co-Founder & Project Lead
Love it :)

I remember playing with Robocode years and years ago. Heck I ran a small Java User Group for a little while and a couple times we used Robocode to hand out door prizes - fittingly full Ultimate licenses to IntelliJ! That was a decade ago ;)

I think this framework could actually be easier than visualized above. We don't really need any kind of command line setup or worries about multi-game, that's more of a future concern if ever needed (at which point just build a fancier arena). And the setup could work for an in-game coding language, which we've already demonstrated as doable although probably favoring JVM languages, or something like basing the bots off a behavior tree players could edit right inside the game no additional tools needed (other than a few more behavior nodes). After all it just results in a bot/block that follows some code/config.