AS2MineSweeper Article for Macromedia DRK6

Introduction

AS2MineSweeper is a Macromedia Flash MX2004 based implementation of the classic Minesweeper game. The object of the game is to locate all of the mines on a grid without uncovering any of them. AS2MineSweeper was programmed using ActionScript 2.0, and utilizes the Model-View-Controller (MVC) design pattern. MVC is an effective way to cleanly separate the data, user input handling and presentation aspects of an application. The benefit of such an architecture is that changes to any one of these 3 distinct parts can be made largely without affecting the behavior of the others. In AS2MineSweeper, this is demonstrated through the use of multiple views to give different visual representations of a single game state at any given moment in time. As you step through the code, you will gain a better understanding of how these parts encapsulate specific behavior, and at the same time, work together to create a functional application.

Analysis and Design

In any application developed using the MVC pattern, the application code is separated into 3 parts:

Model This is the part that handles and stores all of the data. Its responsibility is to do any calculations, parse any data formats, and update itself based on user input. When any data in the model changes, it sends out a notification to the view so that it can update itself.

View This part contains the stuff the user sees on the screen. The view gives a visual representation of the models data at any given point in time. The user interacts with the view directly, resulting in potential changes to the system. Also, the view is allowed to call on the model to get information about the current data being stored there.

Controller Though its fairly clear what the model and view do, the role of the controller can be a little fuzzy at times. In AS2MineSweeper, the controller basically initializes both the view and model and then takes user input from the view and updates the model. This gives a layer of abstraction so that the view doesnt directly manipulate the model in any way.

MVC was the underlying framework for how AS2MineSweeper was developed and the layout of the code (from the package structure to the class code) illustrates this. The following class diagram, created using gModeler (https://www.gmodeler.com/) provides a better idea of exactly how the code is laid out and shows the relationships between classes:

You can see that there are distinct classes for the model (MinesModel), view (MinesView) and controller (Mines), as well as a few helper classes. This code structure made it very easy to modify any given part without causing a ripple effect throughout the system. In fact, the creation of the isometric view was an afterthought, and was programmed in about 15 minutes without causing any blips in the system.

Installation

The source files are comprised of one FLA file containing the visual assets and minimal code, along with 8 AS class files in a standard package structure. In order to view and modify the FLA file, you must have Macromedia Flash MX2004 or MX2004 Professional installed. You can view and modify the AS files with any text editor, however, the AS editor in Flash MX2004 Pro or other AS editors are recommended. One great free editor that supports AS2 is SE|PY (https://www.sephiroth.it/python/sepy.php).

You should also have a basic understanding of how classes and packages work, as well as some understanding of AS2. The code is documented quite thoroughly to help you get around within it.

Classes

Here is a quick rundown of all of the classes and a brief description of what functionality they encapsulate:

Mines (controller) This is the class that is instantiated to create a new game. It creates instances of the view and model and stores references to them. When a square is clicked in the view (UI), the controller passes that information onto the model to update it.

MinesModel (model) This class generates and stores all of the data associated with the game board. It randomly selects positions for mines, calculates the numbers for all squares adjacent to mines, and it responds to clicks from the view (via the controller) in order to update the status of each square.

Square This class stores the data associated with a single square. Remember, this is ONLY the data, not anything to do with the UI.

MinesView (view) This class encapsulates the code that displays and updates the actual game board as well as controls and displays associated with the game (i.e., Switch Views button, Reset button, Time display, Mines Left display).

Timer Very minimal class that just counts up based on a given interval.

UISquare Base class for all square movie clips that appear in the UI. Sets the click handler for the square clip as well as setting the visual status of the square (i.e., covered, revealed, flagged, unknown).

UISquareNormal Extending UISquare, this class is the default class for the squares in the UI. This provides the default 2D view. This class is associated with the library item squareItem in the FLA.

UISquareIsometric Extending UISquare, this class provides an isometric view of the game board. This class is associated with the library item squareItemIso in the FLA.

Game Parameters

For the most part, the game classes encapsulate all of the game and game control functionality. However, there are a few important things to note:

You can easily change the parameters of the game by changing the parameters passed to the Mines constructor. The following properties are passed when creating a new game:

a.       width number of squares in the width of the game board

b.      height number of squares in the height of the game board

c.       mineNum number of mines to place on the game board

d.      viewType the type of view you would like to start with (currently normal or isometric). See Creating New Views for information on creating additional views.

Though you can change these parameters to modify the game board, keep in mind that the current UI shell doesnt resize itself, so if you create a large game board, it will likely not fit on the stage as is. Also, keep in mind that the larger the game board, and the more mines, the more calculations will be necessary at given points to place mines on the stage and update the status of multiple squares.

Currently, the movie clip that contains the game board is created in the MinesView class. It is also placed at a set position on stage (using __board._x and __board._y). If you want to change the position of this movie clip, look inside the draw( ) method within MinesView.

Creating New Views

Creating a new view for AS2MineSweeper is fairly painless. Here is all that is involved:

Create a new library item with the visual representation of a square that you want in your view. This library item should minimally have states representing the following (the way this is implemented in the 2 views created with AS2MineSweeper is by using labeled keyframes):

a.       Default not clicked yet (covered)

b.      Empty revealed but contains no numbers or mines

c.       Adjacent revealed and containing a text field to display the number of adjacent mines.

d.      Mine revealed and containing a mine

e.       Flag covered and flagged

f.        Unknown covered and tagged with a question mark

Make sure you export that symbol for ActionScript (right click library item, select Linkage).

Create a new class that will be associated with that library item. Its probably a good idea to extend UISquare, but you dont have to. The class needs to know how to change its visual status as well as set up its own click handlers.

In your FLA, make sure you associate that class with the library item you created (right click the library item, select Linkage and enter the class along with the full class path into the AS 2.0 Class field.

Go into com/philterdesign/minesweeper/view/MinesView.as and add another condition to the if..else statement in the draw( ) method. This condition should call a method that you create in step 6.

Create a method that will visually position your square symbols (i.e., drawCustomViewItem( )). The algorithm to do that is up to you and is based on what the view should look like. If you want a template to start from, look at the method drawNormalViewItem( ).

Thats it. Now you should be able to pass in the name of your new view into the constructor for the controller class and it should work. In the current implementation, the Switch View button only toggles between the 2 views. If you want to change this, youll have to look at the method switchView( ).

Next Steps

Theres not much else to say other than to encourage you to go and play around in the code. As mentioned before, it is commented thoroughly so the best way to learn is to read through the code and connect the dots that way. Once you feel comfortable with the code, one challenge might be to change the data source so that it reads its data from XML or a Flash Remoting stream and generate the random mines on the server side. Due to the MVC implementation, its just a matter to recoding the Model and plugging it into the system and away you go.

Of course, this implementation is based on my take on MVC. Other developers may give slightly different perspectives, but the overarching concepts will be similar. Fortunately, Flash MX2004 Pro makes implementing this very easy. With the addition of compile time features like classes, strong typing, private members, and more, it made implementation and bug catching much quicker than would have likely been possible in Flash MX.