Hong Kong Institute of Vocational Education Department of Information Technology
Higher Diploma in Game Software Development (IT114107)
ITP4712
Year 2 Semester TWO (2019/2020)
Logical and Artificial Intelligence in Games ASSIGNMENT
Due Date: 18 May 2020 Robocode
Robocode is a Java programming game, where the goal is to develop a robot battle tank to battle against other tanks. The robot battles are running in real-time and on-screen. The motto of Robocode is: Build the best, destroy the rest!
In this assignment, you are required to build some Robocode robots to accomplish different tasks. You will also need to have a design document on each robot you made.
TASK 1
Chasing Robot with a Forward-Chaining Rule-Based System
In the sample code, you are given a Robot that applies a forward chaining rule-based system for its action. The rule-based system consists of 3 major classes: Rule, Condition, and RBS. A sample implementation of the RBS, ReadFileBotRBS, is also given to you as a reference. The first two classes are tedious – they just store the rule data and the condition information of the rules.
Condition class uses the constructor to get the information of the condition, while the name of the condition is stored as a String. The boolean variable in the class indicates whether the condition is to be in the fact list of the RBS. There are some get/set methods and other methods are for equality comparison and String conversion (for output).
Rule class has some add/set methods for inserting the rule data. The conditions are stored as an unordered Set. The rule can have two types of action – method call or fact removal, which is identified by the boolean variable actionType (true for method call / false for fact removal). The rules can be compared by referring to the rule name. Similar to Condition class, there are also some get methods and a String conversion (toString()) method.
1
RBS class is the core of the forward chaining system. The abstract class has an unordered Set storing the known fact in the RBS, an ordered Set storing the rules read, and a Robot variable representing the robot under control so that action on the robot can be called. The two major methods of the system are:
– readFile() method reads the text version of your rule set “rule.txt” and converts and stored them into RBS understandable rules in the RBS’ Rule Set. The file should be stored under the subfolder “
– evaluate() method is an abstract method intends to do the forward-chaining. The system will match the rules from the beginning to the end once according to the rule order (rule names’ alphabetical order). ALL rules matching the condition will be fired. The action will either be calling a method to control the corresponding robot, or remove a fact from the fact list. During the evaluation process, facts may be added or removed during when executing the call methods to the robot (e.g. scanTarget() and turnTank() inside ReadFileRobotRBS), or the methods inside your robot itself (e.g. onScannedRobot() inside ReadFileRobot).
– There are other trivial methods for listing, adding and removing facts and rules; and also a resetRules() method to set all rules unfired so to prepare the system for next turn and a reset() method to reset all settings of the RBS.
ReadFileRobotRBS is a concrete class inheriting the RBS abstract class that tailor-made for the sample robot ReadFileRobot. ReadFileRobot is essentially the RBS-driven version of the Circler robot that we have done during the lab.
The following is the rules for the ReadFileRobot:
– RHIT: IF FACT HIT_SOMETHING THEN CALL CHANGE_DIRECTION
– R0: IF FACT TARGET_DEAD THEN UNSET TARGET_FOUND
– R0A: IF FACT TARGET_DEAD THEN UNSET TANK_FOCUS
– R0B: IF FACT TARGET_DEAD THEN UNSET GUN_FOCUS
– R1: IF NOFACT TARGET_FOUND THEN CALL SCAN
– R1A: IF FACT TARGET_FOUND THEN CALL LOCK_TARGET
– R2: IF FACT TARGET_FOUND AND FACT TARGET_UPDATED AND NOFACT TANK_FOCUS THEN
CALL TURN_TO_TARGET
– R3: IF FACT TARGET_FOUND AND FACT TARGET_UPDATED AND NOFACT GUN_FOCUS THEN
CALL TURNGUN_TO_TARGET
– R4: IF FACT GUN_FOCUS THEN CALL SHOT
– R5: IF FACT TANK_FOCUS THEN CALL MOVE_TO_TARGET
– RX1: IF FACT TARGET_FOUND AND NOFACT TARGET_UPDATED THEN UNSET TARGET_FOUND
2
Each rule begins with the rule name that ends with a colon (:). The condition part of the rule always begins with the keyword IF. Condition part may consist of one or more FACT (fact to be found in the fact list) or NOFACT (fact not to be found in the fact list). When there are more than one conditions in this part, the conditions are linked together using the keyword AND. The action part of the rule begins with the keyword THEN. There will only be one single action in a rule, which may indicate by the keyword CALL if it is a function call to the robot; or UNSET if it is a fact removal action. Any syntax error in a rule set will induce an exception throw in the program.
Inside the sample ReadFileRobotRBS class, apart from the constructor that gets the Robot that uses the RBS, it only needs to implement the evaluate() method that acts as the RBS’s rule interpreter. In the evaluate() method in the sample ReadFileRobotRBS class, the nested for loop is used to check if each of the conditions (inner for loop) in each rule (outer for loop) is matched. If all conditions of a rule are matched, the rule will be fired and the consequent part will be processed. The consequent is either an action or a fact removal. Fact removals can be done by calling RBS’s internal method. Actions will involve mapping to robot’s corresponding methods which is handled through a switch…case structure. Most of the parts in the given sample can be reused in your version of RBS. The only things you need to modify are those method mappings in the switch…case structure, in which you will need to handle the mapping of your “Action Names” to your robot’s “methods” according to your own rule set and coding.
For the implementation of your robot, you can refer to the given ReadFileRobot. In the sample Robot class ReadFileRobot, we can divide it to two different parts: RBS-related methods and normal Robot methods. You should be quite familiar with those normal Robot methods, such as run(), onScannedRobot(), onRobotDeath() and etc. In our sample Robot, run() method will call the RBS in each tick to re-evaluate the situation. You can reuse this run() method directly in your implementation without any need of modification. Event handlers such as onScannedRobot() and etc will act as sensors that add or remove fact symbols in the working memory. You can add/remove facts as you wish within whatever type of event handlers given in your Robot, but I suggest that you can just reuse the codes given for those event handlers. Methods like scanTarget(), lockRadar(), turnTank(), shootTarget(), moveToTarget(), and changeDirection() are those RBS-related methods. They are called in the RBS, corresponding to different Action items in the rules respectively. That means each method in this category will perform the single task specified in the corresponding action, e.g., lockRadar() will perform the radar locking operation. You need to write your version of such methods tailor-made for your RBS.
After trying the given example, you are required to write your own set of rules and RBS to implement a chasing robot, which will lock at one single robot, chasing it while ignoring other robots, shooting and ramming the locked target while chasing until it dies, and then finding another
3
target and doing the same thing. Your chasing robot should use precise targeting (Hints: making use of AdvancedEnemyBot given in the lab, modifying the code to give more precision). Your robot may work in a similar way as a combined robot of AdvancedBearingBot and AdvancedNarrowBeam with additional precise targeting.
To finish your task, you will need to include the Condition, Rule, and RBS classes in your own folder. You may also need to include other classes that you may need to use in your Robot, such as EnemyBot and/or AdvancedEnemyBot. You then needs to write your own Robot (similar to the sample ReadFileRobot) and the corresponding RBS for your Robot (similar to the sample ReadFileRobotRBS).
Deliverables:
– The rules for your RBS. Remember – order of the rules is important.
– The java implementation (source code) of your RBS class, which will extend the given RBS
class; and the robot’s source code, with all other Java source code that you have written for this
robot.
– A brief description on your facts and rules and how your methods inside the robot add/remove
the necessary facts during the process of evaluation.
4
TASK 2
Design a Robot as a Finite State Machine
In this task, you will need to model a robot using a finite state machine. Your robot should have at least FIVE different states apart from the initial state. You may divide the states into sub-states if you want to. Here are some state suggestions:
Idle (starting state)
Finding Sides (approaching to the nearest side while avoiding the Sentry Border to gain the
best defence)
Patrolling (move along the sides and shooting nearby targets)
Meleeing (attack nearby targets which are having low energy level)
Chasing (attack a single target when there are only very few enemies left in the field)
You can add other states to improve your robot. Your robot will use its senses (radar or hit events) (i.e., onScannedRobot(),onBulletHit(), onHitByBullet() and etc.) and its own attributes (e.g., getBattleFieldWidth(), getBattleFieldWidth(), getX(), getY(), getOthers() and etc.) as the condition of state transition. Your robot needs to consider the current status of battlefield and other enemies to apply different strategies, such as, when to state away from others and when to apply melee. You will also need to keep your robot out of the Sentry Border, which size can be checked using the getSentryBorderSize() method. You may also need to apply guessing and/or calculation to make your robot more robust. In testing your Robot, we will place five random sample robots with your robot to test your robot’s effectiveness and robustness. We will not put any Border Guard in this stage; but if you plan to use this robot as your robot in Task 3, you may also need to check if your target robot is a Sentry Robot using the method isSentryRobot()in ScannedRobotEvent class, while you are scanning your enemy.
For the state and state transition handling, you can state your current state of the FSM in an instance variable. Try using switch case statement in your run() method to handle the actions in your FSM. Each case represents the action for each state of your robot. The state transition should be triggered by the onXXX() methods and/or inside your run() method when you are checking your robot’s status.
Deliverables:
– A diagram representing the state transition of the robot.
– A brief description of the states and transition.
– The robot’s java file. You should try your best to implement the robot as the state machine
designed by yourself. Marks will be deducted if the robot does not implement as designed.
5
TASK 3
Design a Robot to Fight with your Classmates
In this task, you are free to use whatever approach to implement your robot. The ultimate goal is to defeat all other robots made by your classmates to earn bonus. In fact, you are recommended to use the robot from Task 2 to play this task; but make sure you have made another copy and renamed the robot and the package as required before you hand in.
During the battle with your classmates, sampleSentry.BorderGuard robots will be added into the battle mix. These BorderGuards will try to locate and attack the robots located in the sentry border area (default size: 100 pixels from the walls). Robots outside the sentry border area will not get any HP reduction even if it is hit by the BorderGuard bullets. On the other hand, your robots will not get any bonus HP by hitting these BorderGuards. To avoid wasting HP on attacking BorderGuards, you should use the method isSentryRobot()in ScannedRobotEvent class to check if the scanned enemy is a BorderGuard and you should skip attacking it. Also, you may like to keep away from the border area – to check the width of the border area, you can use getSentryBorderSize()inside your Robot class.
Deliverables:
The robot’s java file. You can have any reasonable name for your robot, but the name of the package of your robot must be your s+studentID, e.g., “s181920212”. If you need to have other supporting classes to run your robot, you also need to submit the source code of such files, under the same “s+studentID” package.
6
Instructions to Students
1. The weighting of this assignment is 40% of Continuous Assessment.
2. This assignment is an individual assignment and each student has to submit his/her own work.
Plagiarism is a serious offence and any assignments that involve any plagiarism will be given ZERO marks. The award of zero marks will apply to all parties, regardless of whether or not a student is the original author or the plagiarist. Further disciplinary action will follow.
3. All work is to be submitted through Moodle on or before 9:30 am on Monday 18 May 2020. Late submission without valid reasons may be given ZERO marks.
4. You must use compiler for Java SE 8.0 or above and Robocode 1.9.3 to develop the programs.
5. Your programs must be adequately commented, with reasonable spacing and line wrap and
sensible identifier names (including classes, methods, variables and etc.). Marks will be
deducted if the coding standard is not followed.
6. You are required to hand in your deliverables in different tasks following these instructions:
Each task should have its own folder (Task 1, Task 2, and sXXXXXXXX, where XXXXXXXXX is your student ID).
In each folder, it should contain the robot Java source code (the robot itself and all supporting class you have written) and a Word document containing the written report as described in each task (for Tasks 1 and 2 only).
The three folders should be zipped into a single zip file and submit to Moodle.
You must have one individual robot for each of your tasks; even if you want to use your
robot in Task 1 or 2 to join the competition in Task 3.
Students who do not have the folder for any task will be considered as forfeiting the mark
for that task.
7. Marks: Task 1
Task 2
Task 3
(You will get some marks even you lost all battles)
Total
40 marks 10 marks
10 marks 10 marks 10 marks
20 marks
100 marks
Rule/Fact Design and Description RBS Implementation
Robot Coding
Implementation Accuracy
Design and documentation
Implementation (need to match with design)
Efficiency (Are the strategies used efficient in killing others while keeping oneself alive?)
Fighting against classmates’ robots
40 marks 10 marks
20 marks 10 marks
7