In this handbook, we’ll be concentrating on patterns,which we’ll be using to validate Sokoban boards, and graph transformations,which we’ll be using to move Sokoban around and push boxes correctly(according to the rules of the game or its semantics). Alongside with that, we will present how to implement the control flow, which defines the execution order of graph transformation rules to validate the Sokoban boards as well as to execute moves correctly.
✈️ Some starting assumptions we make
You have completed our first handbookand thus have an installed eMoflon::Coreand know your way around a bit.
Your workspace now contains two projects: SokobanGUI and SokobanLanguage.
Start the Sokoban GUI by right-clicking SokobanGUI/SokobanGUI.launch and selecting Run as → SokobanGUI.
Recall that you can create blocks, boulders, and Sokoban figures by right-clicking a field and making the appropriate choice in the pop-up menu:
After populating a board to your liking, you can start the game by choosingFile → Play Game!
This transitions from the edit mode to the play mode. In the play mode, you can choose items by clicking on them, and then move them by clicking the destination field. If you feel like editing the board again, you can always transition back to the edit mode by choosing File → Edit. Finally, you can clear the current board, as well as create a new board with dimensions of your choice.
A game without rules
When switching from edit to play mode, notice that a reassuring“Everything seems to be ok…” is displayed in the status bar. This is nice but not really true at the moment. You can create all kinds of silly boards right now and still be able to“play” with them. In the first part of this handbook, we’ll learn how to use graphconstraints to validate our boards and prevent users from transitioning to the play mode if the board doesn’t make sense(with respect to the rules of Sokoban). Later in the handbook, we’ll also check that only valid moves are executed(you can move anything to anywhere right now in play mode) using graph transformation rules.
Go ahead, check out the prepared workspaceeMoflon::TIE-GT Handbook, and open SokobanRules.java(projectSokobanGUI, packageorg.moflon.tutorial.sokobangamegui.rules) in the SokobanGUI project to inspect the two relevant FIXMEs we’ll be handling very soon:
Note that you could directly program the required checks in plain Java, operating on the EMF objects(Figure figure, Field field) directly. Go ahead and do this if you want to and just can’t help yourself. The whole point of using a standardised modelling framework such as EMF is, however, that you can use a suitable declarative language to do this instead.
Next, create a new eMoflon::TIE-GT project named SokobanRules. Please make sure that an Emfatic project(*.emf) is selected, and then press Finish.
Project wizard icon
Now, copy everything below the line package SokobanLanguage; from SokobanLanguage/model/SokobanLanguage.emf to SokobanRules/model/SokobanRules.emf. If you save the .emf file now, eMoflon should place generated code in SokobanRules/gen.
In the remainder of this handbook, we will be working with SokobanRules(instead of SokobanLanguage). The reason for working with only one project is that eMoflon::TIE-GT allows you not only to generate classes and packages, but also to specify the implementation of operations! Go ahead and open the manifest file SokobanGUI/META-INF/MANIFEST.MF, remove the dependency to SokobanLanguage, and add the dependency to SokobanRules, as shown in the following screenshot. You can now closeSokobanLanguage(Right-Click → Close Project).
Configure dependency from SokobanGUI to SokobanRules.
The SokobanGUI project will now contain compile errors because its code references classes from the package SokobanLanguage. This problem can be solved quickly as follows: Select the folder SokobanGUI/src, open Search → Search(Ctrl+H), and replace“SokobanLanguage” in all .java files of the“Resource selected in‘Package Explorer’” with“SokobanRules, as shown in the following screenshots.
This is a useful trick that can also help you when you are renaming packages etc. because Emfatic does not offer any refactoring support.
A final note on the SokobanRules project: You can, of course, start immediately with a fresh eMoflon::TIE-GT project when creating your own fancy project. This section shows you how to transition from an eMoflon EMF project to an eMoflon::TIE-GT project.
Creating a validator for boards and moves
(introducing operations in Emfatic, .gt files, and .mcf files)
OK, now let’s start to implement our first validation rule: a board shall contain one sokoban. We start with the relaxed condition that a board shall contain at least one sokoban. We will implement this check in a separate class called SokobanValidator.
Open the file SokobanRules/model/SokobanRules.emf and insert the new class SokobanValidator. In addition, specify two operations(more precisely: EOperations, but we call them operations in the following for short):
@GenModel(documentation="Validates board states and moves")