How to play with XgaG - a guidance for modeling TicTacToe

This introduction describes the various steps that will usually have to be performed when playing around with XgaG. It is seperated into three parts: General concepts, the modeling part, and the transformation part.

I. General Concepts

XgaG defines several metamodels that describe the logical structure of simple turn-based board games. By using these metamodels one can create a model that represents a specific board game, e.g. Tic Tac Toe. Such a model does not include graphical information, it really just represents the game´s logic. At this time we do not provide an Application that can be used to directly play a game described by an XgaG game model. Fortunately this is not the end of the story: Zillions of Games is a (non-free) Program that can play games that are described in a special Lisp-like language. We provide a transformation for this language.

1. Overview of the XgaG meta models

When creating an XgaG model you actually have to create 4 separate models. Figure 1 gives an overview of this architecture.
The Board model defines a graph that represents the game´s board. We seperate this from the other models because one can think of several games that share the same board, e.g. Chess and Checkers. The same applies to the PieceSet model, which serves to define collections of playing pieces. The Game model is the core of our models. Here we define the rules of the game and its abstract concepts.
The ResourceWrapper model is used to attach graphical representations of board and pieces to the logical model.
The main idea is now to transform our abstract game definition to arbitrary game engines. In our case we implemented a sample transformation to the Zillions of Games platform.

Figure 1: Overview of the XgaG models

II. The Modeling Part

We now describe how one can create each of the needed models by using our editors.
Notice: The shown meta models do not display cross-package references because the GMF editor does not support this. In doubt look at the javadoc.

1. Create a Board model

Based on the Board meta model we created a GMF-Editor (see Figure 2) where you can easily create your own board. Notice that not only the abstract graph but also the geometric structure is used later on.
A Board model consists of the following Elements:

Fields: A Field in the editor is directly mapped to a Field in the board model.
Edge: The Edge tool lets you create a connection between two Field nodes. This maps to an Edge element in the model. Note that every edge has to have its Direction property set.
Direction: Every Edge in the model has to be typed using Direction elements. Direction in the editor are mapped to Direction elements in the model.
Region: With regions you can group sets of Fields. Regions are also directly mapped to their model namesakes.

[img/gmfEditor.png]

Figure 2: The GMF based Board model editor showing the Tic Tac Toe board model.

The complete model of the Tic Tac Toe Board and its notation.

2. Create a PieceSet model

PieceSets are used to create collections of playing figures (see Figure 3). Note that these are just types for describing certain characteristics (e.g. movement) that are independent of player ownership. Have a look at the simple PieceSet meta model.

[img/tttPieceSet.png]

Figure 3: The EMF based PieceSet tree editor. One Piece is enough to create Tic Tac Toe.

The complete model of the Tic Tac Toe PieceSet.

3. Create a Game model

Now we are going straight into the thick of things. Figure 4 displays an excerpt from the relative small example of Tic Tac Toe.
At the root of the model is the Game element that contains all the neccessary features:

Player: The entities that will play the game.
TurnOrder: An ordered seqence of players that specifies which player comes next (round robin).
PieceMapping: Defines each player´s pieces, their count and their starting position. The starting position can either be off the board, or any Field on the board.
RandomElement: This will serve as a random value creator, e.g. Dice or a random Player.
Rules: Abstract class for everything that allows/disallows an action in the game. If several Rules conflict within a game state the higher priorised Rule is chosen. For example to realize enforcement of piece-capturing. Every Rule has a Condition that indicates if the rule applies.
GoalCondition: Rule that ends the game if its condition evaluates to true. Depending on the chosen GoalConditionType this can be win, draw or loss.
PieceMovement: efines how piece can be put on the board, removed from the board or moved on the board depending on the choosen PieceMovementType.
NamedCondition: Wrapper for a Condition with an id to reference from other contexts.
Condition: Abstract condition that evaluates either to true or false. Evaluation depends on the game´s current state.
AndCondition: True if both inner conditions evaluate to True.
OrCondition: True if at least one inner condition evaluates to True.
NotCondition: True if the inner condition evaluates to False.
AtomicCondition: A Condition that can be evaluated and is non-separable.
SpecialCondition: Used to handle special events that often occur in board games, e.g. stalemate.
AbsoluteCondition: True if the FieldSpec and PieceSpec hold for all of the given Fields.
RelativeCondition: From the starting Field the PathSpec is evaluated to a list of target Fields. The Condition evaluates to True for every target Field that complies with the FieldSpec and the PieceSpec and if there is at least one target Field for which the Relative Condition next evaluates to True.
FieldSpec: Predicate for a Field. For example if the Field is member of a certain region and empty.
PieceSpec: Predicate for a Piece. For example if there is a certain Piece on the referenced field and does it belong to the enemy.
PathSpec: Specifies a set of Fields given an initial implicit context Field by walking a certain number of steps to a specific Direction. For example if there is some Condition two fields to the "north".

[img/TicTacToeGame.png]

Figure 4: Excerpt from the Tic Tac Toe game model.

The complete model of the Tic Tac Toe Game.

Transformations

1. Recycling the Board diagram model (Model-to-Code)

Any game platform that will eventually run your game needs geometrical information about your Board and especially the location of its Fields. Normally the abstract board diagram is in some way connected to that geometrics. Thus, we reuse the board diagram for extracting this information into a SVG file. This file can be processed further e.g. by professional layouters and serve as the graphical view of your board (used in the next workflow). The clou is that the created fields will be referenced for gathering the geometrical information as long as you do not delete them. See Figure 5 for an abstract workflow representation and Figure 6 for the concrete transformation of the Tic Tac Toe Board. For more details look at the workflow and the implementation.

[img/workflow1.png]

Figure 5: The Board2SVG Workflow

[img/Board2Svg.png]

Figure 6: The Board diagramm (step1) is used as input for creating the Board.svg file (step2) wich can be modified and layouted (step3) while preserving the field identities.

2. ResourceWrapper Workflow (Model-to-Model)

Last but not least we have to give additional information about the final layout of the game. Therefore a ResourceWrapper is needed that maps game Board and game Pieces to images. To make it easy to use, a ResourceWrapper instance is generated by the workflow (see Figure 7). The only thing one has to do manually is to enter the file URIs. For more details look at the workflow itself and the corresponding implementation.

[img/workflow2.png]

Figure 7: The ResourceWrapper Workflow

The filling is as usual provided by an EMF tree editor. An example is shown by Figure 8.

[img/ResourceWrapperEditor.png]

Figure 8: The ResourceWrapper Editor for the Tic Tac Toe with URI checking.

3. XgaG2Zillions Workflow (Model-to-Code)

The last workflow transforms the XgaG game model into a Zillions Rule file by using the Open Architecture Ware Xpand/Xtend template languages (see Figure 9). For more details look at the workflow itself and corresponding Xpand and Xtend templates.

[img/workflow3.png]

Figure 9: The ResourceWrapper Editor for the Tic Tac Toe with URI checking.

Check out the XgaG project page