AS2MineSweeper Article for Macromedia DRK6
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.
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 model’s 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 it’s 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 doesn’t 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.
files are comprised of one
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.
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.
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” doesn’t 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 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. It’s probably a good idea to extend UISquare, but you don’t have to. The class needs to know how to change it’s visual status as well as set up it’s own click handlers.
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( ).
That’s 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, you’ll have to look at the method switchView( ).
There’s 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, it’s 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.
Adauga cod HTML in site