Click Picture to see Animation

Go here for more posts in this series

WPF animations of visual elements require special attention when used in a multithreaded environment or for that matter even in a single threaded environment whenever animations have any level of complexity. This is because the visual objects being animated are bound to the specific thread in which they were created, and require that their visual properties be changed only on that thread.  While this problem is easily enough dealt with via the Invoke() operations, the issue is further complicated by the fact that subsequent animations may depend on the effect of previous animations, i.e. the final position and attitude of the previous animation may be required in calculating the next sequence.  Further complicating the issue is the fact that the animation sequence itself runs in an event triggered fashion on the main UI thread, therefore for an animation to in fact animate, control must be returned to the UI thread.

Consider the game of Mah-Jongg.  17 tiles are dealt to each player, after which any tiles that represent flowers and seasons, and any four of a kind sequences, are removed from the players hand and placed face up in front of them.  This requires several successive animations to;

 

ü      Shuffle the tiles and lay them out in rows in front of the players

ü      Push the rows together to form a box

ü      Open a break in the box

ü      Deal tiles to the player

ü      Move Flowers, Seasons, and 4 of a kind sequences

ü      Shift the players hand tiles so they are once again adjacent

ü      Deal new tiles to the player to replace any removed by the previous steps

 

There are two interlocking issues present here.  The first, is that prior to the tiles being dealt, the entire animation sequence for them is unknown.  The second is that the tiles should not be dealt directly to a face up position, i.e. if a season tile is dealt to a player, then it should first go to their hand and then be moved to the face up display.  These in turn adds animation requirements on subsequent tiles in the player’s hand, so they will be shifted to the left and fill any holes that are made.

While it is possible to envision calculating the entire animation sequence at the outset, this is obviously not a simple undertaking, and such complexity begins to scale exponentially as more steps are added to any animation sequence.  The purpose of this article is to show you how to use concepts from workflow, or more properly, a  20+ year old concept in software engineering to gain the following advantages;

 

ü      Individual animations always deal with an atomic motion

ü      Animations are associated with individual game pieces.

ü      Any animation can be based on the end result of a previous animation

ü      Animation steps can be conditional

 

This concept, or more properly, implementation pattern, is formally known as a continuation, which are a mechanism for being able to save and restore program state.  I have written a set of postings on continuations in the enterprise workflow environment, which you can find here.  You do not need to read this to use this technique in animations, as this set of postings will provide you with all the relevant information.  However, if you are interested in the wider range of applications of continuations, or what in fact is going on under the covers, this is a good place to start. 

.

In the use of continuations for animation, we will leverage the completion event triggered by any animation to trigger the next step in the animation sequence.  In doing this we know that the animated element has reached its final destination, and can therefore be inspected to determine its current position and attitude.

Dealing Tiles in Mah-Jongg

The first step in setting up a new Mah-Jongg game is to shuffle the tiles and create four unconnected rows of tiles, 18 across and 2 high, one row in front of each of the four players.  These rows are then slid towards the center of the playing area until the walls touch and a box is formed.  In Mah-Jongg, when the box is formed, it is known as the wall.

Once the wall has been formed, it must be opened.  This involves the random selection of a position in the wall, removing the two tiles at that position and stacking the top tile one position counterclockwise, and the bottom tile three positions counterclockwise.

Tiles are removed from the wall in clockwise fashion, and are dealt in blocks of four to the four players at each of the cardinal compass points.  A block of four tiles is dealt to the East, South, West, and North players, and this is repeated three times, so that each player has 12 tiles.  Finally, a single tile is dealt to each of these players, so that each player now has 13 tiles.

.

Once all of the player’s hands have been filled, any flower and season tiles need to be placed face up in front of them, as well as any groups of four tiles of the same suit and value (known as Kongs).  Then the remaining tiles in the players hand need to be shifted left to fill any holes left by flowers, seasons, or Kongs.

Once this has been done, new tiles need to be dealt to each player to bring the number of tiles in their hands back to 17.  Once this has been done, the hand must be reexamined to remove any new flowers and seasons, or newly formed Kongs.  Once the players hand contains no flowers, seasons, or Kongs, the process is complete.

Expanding on the previously described animation sequence;

	1	Shuffle the tiles and create a row of tiles in front of each player
	2	Push the rows together to form a box (the wall)
	3	Open the wall
	4	Deal tiles to the players hand
	5	Move flowers,seasons, and Kongs to the area in front of the player
	6	Shift players hand tiles left to fill any gaps left by step 5
	7	Deal new tiles to player to replace those removed in step 5
	8	Go back to step 5

All of the code for the Mah-Jongg demonstration is available here - note that it is a work in progress, so check back from time to time and get newer versions, which will have improved comments, bug fixes, and subsequent development.  The current version has all of the code necessary to support this animation article.  Also note that this application uses the Component Application Block (CAB) from Enterprise Library, which is outside the scope of these posts -  if you find missing libraries in the build, odd are you’ll find them in the bin/debug directory, I leave it to you to move them somewhere safe…….

In the next article I will examine the specific implementation of the algorithm hat handles steps 2...6, and show how continuations can be used to break down a complex animation into a set of sequenced simple animations and conditional logic.