Metamodelling in AToMPM 

  Assignment Goal

The goal of this assignment is to build a formalism to model RPGGames in AToMPM:
  1. Implement abstract syntax using SimpleClassDiagram, enrich with global constraints if necessary, create a concrete syntax (using the ConcreteSyntax formalism), and generate a modelling environment (by compiling the metamodel and the concrete syntax model). Do this incrementally.
  2. Make your RPGame visually more appealing by adding actions that move/resize/... model elements. Find useful constraints. To implement this, you'll need to make use of the mappers and parsers in the concrete syntax of your formalism.
  3. Create test models that demonstrate the use of your language.
  4. Optional: Create multiple concrete syntaxes for your formalism.

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 (report in PDF + zip file containing your formalism and example models) on Blackboard before Friday 25 October 2013 at 14:00.

Contact Simon Van Mierlo if you have a problem.

RPGame Requirements

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.

  Useful Links

  Tips

  • Primitive Types: int/float/boolean/string
  • Composite Types: [] for lists, {} for dictionaries
  • Cardinalities are specified by the construct: map<[dir,type,min,max],[string,string,string,string]>. 'dir' is either 'in' or 'out', 'type' is the type name of the association, 'min' is the lower bound, and 'max', is the upper bound. An example: {'dir': 'in', type: 'A2B', 'min': '0', 'max': '1'} defined on class B means that an instance of B can be connected to 0 or 1 A's with the relation A2B.
  • To get connected neighbors, use the 'getNeighbors' function. The signature of this function is: getNeighbors(_dir [, type, _id]) where '_dir' is either '>' (outgoing) or '<' (incoming), '_type' is an optional type name of the association (use '*' to match all relations), and '_id' is an optional model element id (if none is given, it takes the current model element). Connected neighbors include both associations and objects. For example, if an instance of class A is connected to an instance of class B with the association A2B, a getNeighbors call on the instance of class A will return the instance of the association A2B.
  • Actions and Constraints are written in JavaScript. Actions and Constraints consisting of multiple lines need to have each line ending with '\'.
  • When saving a model, you can create a new folder (in this example, 'test') by specifying 'test/mymodel.model' as the filename.