CS计算机代考程序代写 prolog Knowledge Representation problem description

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/