Knowledge Representation problem description
A popular fictional monster battling game features a type system that is used to determine the effectiveness of a
monster’s ability to attack or defend against another monster. In this coursework you will write a Prolog program
to represent knowledge about this system and to answer queries using the resulting knowledge base.
The version of the game we will use includes five monsters: bewear, fraxure, polteageist, rookidee, and
sirfetchd. Each monster can be one of five basic types: dragon, fighting, flying, ghost, and normal.
Each monster has four moves that it can use. Each move is also assigned one of the basic types. The details of
each monster, its type, its moves, and the move types are given in the following table:
Monster Monster type Move Move type
bewear normal strength takeDown
superpower
shadowClaw
normal normal
fighting
ghost
fraxure dragon falseSwipe
dragonClaw outrage
shadowClaw
normal
dragon
dragon ghost
polteageist ghost facade
shadowBall
astonish teaTime
normal
ghost ghost
normal
rookidee flying revenge peck
braveBird
furyAttack
fighting
flying flying
normal
sirfetchd fighting brickBreak
braveBird bodySlam
closeCombat
fighting
flying normal
fighting
E.g., sirfetchd is a fighting type monster with 4 moves: brickBreak (a fighting type move), braveBird
(a flying type move), bodySlam (a normal type move), and closeCombat (a fighting type move).
The effectiveness of a monster’s move when used on another monster depends on the move type (of the
monster using the move) and the monster type (of the monster the move is being used on). Certain moves are
strong against certain types of monsters while other moves are weak or superweak against other monster
types. The effectiveness of a move type against a monster type is represented in the following table:
move \ monster dragon fighting flying ghost normal
dragon strong ordinary ordinary ordinary ordinary
fighting ordinary ordinary weak superweak strong
flying ordinary strong ordinary ordinary ordinary
ghost ordinary ordinary ordinary strong superweak
normal ordinary ordinary ordinary superweak ordinary
E.g., a fighting type move is weak against flying type monsters but a flying type move is strong against
fighting type monsters. Combinations that aren’t strong, weak, or superweak are ordinary.
What to do
Write a Prolog program to represent the knowledge in the monster game according to the following specification:
1. Encode information about the monsters and their abilities using Prolog facts of the following form:
− type(t): to represent the idea that t is a basic type.
− monster(mo,t): to represent the idea that mo is a monster of type t.
− move(mv,t): to represent the idea that mv is a move of type t.
− monsterMove(mo,mv): to represent the idea that monster mo has a move mv.
2. Encode effectiveness information using Prolog facts of the form typeEffectiveness(t1,t2,e): a
move of type t1 used again monsters of type t2 has effectiveness e.
3. Encode basic effectiveness information using Prolog facts of the form moreEffective(e1,e2): e1 is
more effective than e2. You should only encode the strict ordering on effectiveness in this way, i.e.,
strong is more effective than ordinary, ordinary is more effective than weak, and weak is more
effective than superweak.
4. Encode transitive effectiveness information using a Prolog rule of the form moreEffective(E1,E2):
E1 is more effective than E2. The rule should cover information not represented by the facts in part 3,
e.g., strong is more effective than weak, ordinary is more effective than superweak, etc. E1 and E2
should be variables in your rule definition.
5. Define a Prolog rule called monsterMoveMatch(MO,MV) which represents the idea that monster MO has
a move MV and that MO and MV have the same type. MO and MV should be variables in your rule definition.
6. Define a Prolog rule called moreEffectiveMove(MV1,MV2,T) to represent the idea that move MV1 is
more effective than move MV2 against monsters of type T. MV1, MV2, and T should be variables in your
rule definition.
7. Define a Prolog rule called moreEffectiveMonster(MO1,MV1,MO2,MV2) to represent the idea that if
monster MO1 performs move MV1 and monster MO2 performs move MV2 that MV1 is a more effective
against MO2 than MV2 is against MO1. MO1, MV1, MO2, and MV2 should be variables in your rule
definition.
NOTE: For parts 4-7 of the specification, ensure that you write Prolog rules. You should not implement Prolog
facts as your solution for these parts and you will lose marks if you do this. However, it is okay if need to write
multiple rules for each definition. If you are interested, the game mechanics in this coursework are based on
information from https://pokemondb.net/.
What to hand in
• Prolog program file: Submit a single Prolog program file with all your Prolog facts and rules. Ensure that
the file is a plain text file with the name monster.pl. Make sure there are comments in your program
file to describe the different parts of your program
• Output file: Test your program by selecting a series of Prolog queries to demonstrate the various facts
and rules you have implemented. Capture the queries and output to a text file. Include at least 10 queries
in your output file. Ensure that the file is a plain text file with the name output.txt.
https://pokemondb.net/
https://pokemondb.net/
https://pokemondb.net/
Automated Planning problem description
A University has decided to extend its planetary exploration activities by terraforming an uninhabited planet. The
planet has been divided into a series of grid-based regions. A base of operations is located in one of the regions.
Terraforming operations will be controlled by mission plans generated using an automated planner that will direct
the terraforming personnel, equipment, and activities on the planet. Several types of personnel serve at the base,
including the commander, engineers, science officers, and security personnel. The base also contains certain
equipment that is useful to terraforming operations, including shield emitters and terraforming machines. All
personnel and equipment initially begin at the base but may be directed to move to other regions of the planet as
necessary. Some of the operations of the terraforming mission are described in the following list (which isn’t
exhaustive):
1. Each region of the planet can be either flat, hilly, or mountainous. The base of operations is located in a
flat region of the planet.
2. All personnel can individually move between different regions of the planet, provided the regions are
adjacent to each other. As a result, it may take multiple moves to reach distant regions. Personnel can
only move through flat or hilly regions, not mountainous regions.
3. Engineers can carry and deploy shield emitters. An engineer can carry at most two shield emitters at a
time. Shield emitters can only be deployed in flat regions.
4. A shield emitter can be turned on and off. Turning on a shield emitter causes a shield to become active
which protects the region in which it is deployed. A region can only contain at most one shield emitter.
5. Science officers can carry and activate a terraforming machine. A science officer can carry at most one
terraforming machine. A terraforming machine can be activated in either a flat or hilly region, but only if
the region is protected by a shield and the terraforming machine is charged. Once the terraforming
machine has been used it becomes discharged and must be recharged at the base before it can be used
again. Successfully activating a terraforming machine causes the region in which it was activated to
become terraformed.
6. Activating a terraforming machine in a region without a shield causes the machine to become damaged
and unusable, due to the dangerous radiation on the planet.
7. A science officer can recharge a terraforming machine at the base.
8. An engineer can fix a damaged terraforming machine at the base.
9. If three individual shield emitters are set up on the planet, a planetary shield can be activated which
networks the individual shields to protect the entire planet.
10. The commander can turn the planetary shield on and off at the base.
11. Space pirate camps have been reported in several regions of the planet. If base engineers or science
officers enter a region of the planet with space pirates then they will be captured unless there are security
personnel already in the region. Captured personnel cannot move or perform any activities.
12. Captured personnel can be released if the commander visits the pirate camp to negotiate their release. If
the commander enters a region of the planet with space pirates they will also be captured unless there
are security personnel already in the region.
At the start of operations, the base is given a series of missions to complete that involve terraforming several
regions of the planet.
What to do: all students
1. PDDL implementation: You must model the planetary terraforming domain in PDDL by defining the
properties, objects, and actions that are needed to describe the domain. Note that the planning domain is
described at an abstract level and is somewhat incomplete, with certain pieces of information missing.
You must make design decisions as to how you will represent the knowledge and actions necessary to
encode this scenario as a planning problem. Some requirements are more difficult than others. It is
strongly recommended that you try to implement the domain incrementally, ensuring that some parts of
the domain work correctly before moving on to others. Use the example domains from the PDDL lectures
as a starting point for your solutions. You may also find that the planning time increases as you add more
complexity. You may have to consider whether an alternative knowledge representation leads to a better
solution. You may use the planning tools available at http://editor.planning.domains/, the Fast Forward
(FF) planner, or the Fast Downward planner. You should ensure that your solution works with one of
these planners. Note that the performance of certain planners may outperform that of the web-based
planner. Do not use any features of PDDL that we have not covered in the course. Make sure you test
your solution on a series of different problem scenarios. Include comments in your PDDL files to describe
important sections of your code.
2. PDDL report: Write a short report (maximum 2 pages) showing the regions of your planet, how they are
connected, the type of each region, and the location of the base. Also list in your report the particular
problem instances you have included in your code and what planner you have used to test your
domain/problems. The report will be used to help understand your code.
What to do:
In addition to the above instructions, students should design an additional feature in PDDL to add to the domain
(e.g., new personnel that can perform some task, a new activity, etc.) that isn’t included in the above domain
description. Add this feature to your domain and test it. Include a description of the additional feature in your
PDDL report (maximum 1 extra page).
What to hand in: all students
• PDDL source files: Submit your PDDL source files (domain + problems) in a zip/tar file. Make sure your
source files have comments describing the properties and actions you’ve defined. Your solution should
consist of a single PDDL domain file and at least 4 different PDDL problem files illustrating different
scenarios that are supported by your domain. You should aim for comprehensive scenarios that support
multiple missions in each problem file. Your source files will be checked for plagiarism and tested to see if
they are operational. For 1-year Edinburgh postgraduate students and all Dubai postgraduate students
(full time and part time): one of the problem files must test your additional feature.
• PDDL report: Submit your report as a PDF file. Your report will be checked for plagiarism.
http://planning.domains/
http://planning.domains/
http://planning.domains/
http://planning.domains/