The goal of this assignment is to build a rule-based transformation for the operational semantics of RPGGame in AToMPM.

Make your operational semantics such that the model is updated visually while executing the transformation.

Write a report that discusses your solution. Your report should include an overview of your solution, with focus on the difficulties you encountered and how you solved them.

You will have to complete this assignment in groups of 2. Submit your assignment on Blackboard before Friday 8 November 2013 at 23:59.

Contact Simon Van Mierlo if you have a problem.

Required

Syntax and Static Semantics

1. An RPGGame consists of exactly one scene (or "level"). The scene has a name, such as Forest, Desert, Castle, etc.
2. In each scene, there are a number of connected tiles.
3. Tiles can be connected to each other from the left, right, top or bottom. This way, a map is created for the scene.
4. If a tile has a left neighbor, that neighbor should have the tile as its right neighbor. If a tile has a top neighbor, that neighbor should have the tile as its bottom neighbor.
5. In the game, there is one character: the hero. The hero is always on exactly one tile.
6. A tile can be an empty tile, or an obstacle, on which no character can stand.
7. On an "standard" tile (not an obstacle), there can be an item.
8. There is one type of item: the goal.

Dynamic Semantics

1. A character can move from one adjacent tile to another (provided it is not an obstacle or it is not occupied).
2. An item can be picked up by the hero by walking on its tile. Every item can only be picked up once.
3. A hero can pick up a goal. The hero wins if he can pick up all goals. There must be at least one goal in the game.
4. The game stops when the hero wins.

Optional

Syntax and Static Semantics

1. An RPGame now consists of a world that is divided into a number of scenes.
2. There is a new type of character: the villain.
3. There are two new types of tiles: a trap, and a door.
4. A door is a portal to a door on another scene.
5. The hero and a villain have a health value that depicts how much damage they can take. The default health for the hero and for a villain is 100 (although it can be set otherwise). The health always has a strictly positive value.
6. The hero, a villain, and a trap have a damage value that depicts how much damage they inflict. Damage is always strictly positive.
7. There are two new types of items: a key, and a weapon. A weapon has a strictly positive damage value.

Dynamic Semantics

1. The hero can pass through a door to enter another scene. If the hero goes back through the door, he goes back to the original door at the original scene.
2. The hero can attack villains and vice versa, if they stand on adjacent tiles.
3. Villains do not attack each other.
4. A trap hurts the hero, but not a villain (they have set these traps...).
5. A door can be locked, and the hero must pick up a particular key (for that door) to be able to enter that door.
6. A hero can pick up a weapon, that can give the hero additional damage, according to the damage of the weapon.
7. The hero and a villain inflict damage (according to their damage value) if they choose to attack (when on a tile adjacent to their adversary's tile). A trap inflicts damage (according to their damage value) on the hero if the hero steps onto it.
8. The game is simulated in time slices: first, the hero gets one chance to move or attack. Then, all the villains in the same scene, each get their chance to move or attack. The order in which the villains get their chance is not determined.
9. Villains in a different scene from the "active" scene (i.e., the scene in which the hero currently resides) do not do anything.
10. When the hero achieves the goals, or dies, the game is over.

An example of an execution/simulation trace is shown here.

• AToMPM main page: http://syriani.cs.ua.edu/atompm/atompm.htm
• AToMPM Download Link (v 0.5): atompm.zip. To install AToMPM, follow the instructions at the bottom of the 'Projects' page on the main website. THIS IS A DIFFERENT VERSION. Install this version next to your original AToMPM installation, and copy your user directory over.
• Useful tutorials can be found on the 'Tutorials & Demos' page on the main website.

An example visual trace of running the transformation implementing the operational semantics is shown below. To save space, several intermediate steps have been left out. The first screenshot shows the model in its initial state, the last when the hero has reached the goal in the second scene.

• Modelling rules can only be done when your metamodel is compiled to a pattern metamodel (third button on the CompileMenu toolbar). Click on the button, then select your compiled abstract syntax metamodel and click 'ok'. This will create two new files in the same folder as your metamodel, called 'name'.pattern.metamodel and 'name'.defaultIcons.pattern.metamodel, where 'name' is the name of your metamodel.
• Model your rules using the '/Formalisms/__Transformation__/TransformationRule/' formalism. The name of rule models must start with 'R_'. Contents of the rule are modelled using the pattern metamodel, generated in the previous step.
• Model the schedule of your transformation using the '/Formalisms/__Transformation__/Transformation/' formalism. The name of transformation models must start with 'T_'.
• Actions and Constraints in rule are written in Python, not Javascript.
• Make sure to fill in every action and constraint on a rule and its contents (even when this rule should not do anything - use 'result = True' for conditions and 'pass' for actions).