Argh! Where is that last pair?

Adding hints to the game is a fairly easy task, since we already have the ability to check which blocks are free. Even better: because we’ve marked the free blocks with a special class name, retrieving them at a later stage is just a matter of using a selector. Right now you may be thinking that showing a hint is a bit more complicated than just finding the free blocks; after all, a move requires two matching blocks. And you’re right, there is a bit more to it than that. Let’s see how we can do it:

What we’ve done here is checked each free block on the board to see if there are more free blocks of the same class. The logic here is very basic: there are no priorities, nor any forward planning. This means that while this method will always find a free pair if one exists, it will by no means guarantee a “win” for the player.

If I could just move things around a bit…

The next feature we’re going to look at is shuffling the board. In order to shuffle the board we need to change the locations of all the blocks while maintaining the occupied spots in the layout, otherwise things could get a bit weird. But like the hint feature, it’s a bit more complicated then that. If you followed the previous posts you may remember that each block remembers its index in the layout, its layer, whether it’s covered or not, its z-index, and some more attributes, some of which help us determine whether the block is free. So in order not to mess up everything, we need to separate the position spot attributes (layer, index, z-index, top, left, covered) from the block attributes. Let’s see how we can do that:

Thats about it: get all the blocks, extract their position information, and shuffle the positions array so we can put the blocks in a different order. After that, since we changed everything, we need to determine which blocks are free in the new order and inform the user of the number of pairs available.

A new look

They say you can’t have a new version without some graphical makeover, so I apologize that the game looks the same… but I do have a new, beetle-shaped layout for you, courtesy of Maurice de Regt. So head over to the demo and see how it looks .

Some more code is required to get the finishing touches and interconnect all the features, but I do believe we’ve got the core of it covered. As always, you can find the rest of the javascript in the game demo itself:

Zip file for this tutorial

Demo for this tutorial

So until next time, have fun!

Adi Gabai

In a web page, any key you press triggers an event, so using the keyboard to control a browser-based game is as simple as listening for and catching these events. Listening for keyboard events is fairly easy if you’re using JavaScript, and with jQuery it’s even easier. Before we get properly started, I’d like to introduce a very simple and useful jQuery plugin called HotKeys, which can help you attach to events in a simple manner. You can find it here, and binding with it is a simple matter of:

Sometimes, however, you want to do things yourself and not use a plugin. As I said, that is simple as well. You probably already know how to bind an input box to the Enter key:

Binding to other keys is pretty much the same. All you need to know is the code for your wanted key. For example, if you want to support the arrow keys you can use something like this:

You can also add support for the space key if you want; its code is 32.

’till next time,
Adi Gabai

1. The blocks are arranged in layers, and there can be multiple layers on a given board
2. In each turn, the player must select two free, matching blocks to remove them from the board
3. The game is won when there are no more blocks on the board
4. The game is lost if there are still blocks on the board, but no moves are available to the player

In the previous post, we created a script tag for each block on the board, to help us to transfer the block metadata to the game client. In order to be able to read this metadata, we are going to use one of my favorite jquery plugins: metadata. The metadata plugin can read data about each element from attributes or script tags—in our case we used script tags—so using this method to fetch data is as simple as adding the following line somewhere at the start of the script:

Selecting Blocks

As stated above, each turn consists of the player selecting two blocks; if the blocks match each other and are not blocked by other blocks, they are removed from the board. Blocks are considered free if they can be moved either left or right without disturbing another block (i.e., there is no block immediately to their left or right, and there is no block above them). Let’s take a look at how we can check whether a block is free:

Whew, that was a bit long. But at least it wasn’t complicated: What we did here was check whether the block has already been marked as free (since once a block is marked as free, it can’t ever be blocked again). If it’s not already marked as free, we then determine whether there are blocks to the left and right of the block. If there aren’t, we check the layer above the block, to see whether it’s covered by a block from that layer.
Now, let’s see what happens when the user selects a block. To do that, we will use the toggleBlock function:

The toggleBlock function is basically our “onClick”-type function: it will be called every time a block is clicked and select or unselect the block, assuming it’s not blocked by another. As can be expected, it uses the freeToMove function we just defined to determine this. In addition, if two free blocks are selected, the toggleBlock function will check for a match, and raise the appropriate event. This event will in turn call a function that will handle the blocks’ removal from the board, and check for a win/lose condition.

Removing Blocks

Removing blocks from the board and checking if the player won is fairly simple:

One thing worth take a closer look at is the setTimeout function right in the middle: in my experience, when you start operations that can take a while it’s best to isolate them and separate them from our current call, which requires a more immediate response. You can see that within setTimeout’s scope we’re only triggering a custom event. We’re merely leaving a hook for future features – specifically, showing how many free blocks remain. This event can take a while to run, since it needs to scan the board for free elements (something that will take some time on IE), so putting these events in a different, unrelated scope can prevent our game from looking unresponsive. Please note that if the event was to trigger something which had to end before we could continue, we would have had to find a different method.

Now that we can handle two matching blocks, we also need to handle cases where the blocks do not match. This can be done using a simple function like this:

Someone Won?

Up until now we’ve been happily toggling blocks and removing matched pairs, but what do we do if someone won? We’ve seen that our foundMatchingBlocks function checks whether there are no more blocks left (our winning condition) and triggers the proper event, but what happens then? And also, what if there are no more moves?

Above are two really simple functions that simply handle the display of winning and losing. But… wait a minute… when and how do we check for the losing condition (no matching blocks left)? Well… remember the setTimeout-triggered event we talked about? Every time we remove blocks from the board we also trigger the changed_num_blocks event, which fires the following function:

The updateFreeBlocks function checks how many matching pairs are left on the board. If there are no matching pairs left, updateFreeBlocks will trigger the game over event; otherwise, it will just update the display with the new number of remaining matches. Because we already know how to tell whether a block is free, checking if we have any matches left is pretty simple. We can do it by mapping the free blocks, and counting for possible pairs, like so:

That’s Not All

Some more code is required to get the finishing touches done on the game, but I do believe we’ve got the core of the game covered. As always, you can find the rest of the javascript in the game demo itself:

Zip file for this tutorial

Demo for this tutorial

So until next time, have fun!

Adi Gabai

The Layout Class

Our first step now will be to create a Layout class that will read our layout files. Let’s say we have a mahjong directory in which we’ve created a layout directory, which in turn contains our layout files.
The constructor for our Layout class can look something like this:

Every time the class is loaded, it will go and fetch a layout file, which can then be processed like so:

Since our layer file already contains the variables ($layout, $rows, $cols), the process of loading and processing takes little time. By including the file we gain access to those variables, and can save them in our class. The layout variable should always be an array, since the layout itself is basically an array of positions.

At this point we can read the layout file and store it in our class, but we still need to build a game board out of it. To do that, we’re going to need two more classes: one to handle the board and one to handle a block on the board (AKA tile). But before we rush off to build these classes, let’s take another look at our layout file, because there’s quite a bit more information we can get out of it.

Another responsibility of the Layout class is processing the location of each block in each layer of the layout, and providing relevant information about it, such as its position or whether or not it is covered by a higher layer.
Here’s some code to clarify things:
Numbers of layers in the layout:

The position of a block:

In the above method you can see that we’re placing the blocks according to their index in the array, but since our array has in fact double the actual number of columns and rows, we need to halve the result in order to get the right position. The end result of this method is the left and top positions of the block’s html element.

In addition to providing the positions of the separate blocks, the Layout class also needs to know how to provide the coordinates of the entire layer. We can do this by adding the following loop:

What we did here was take the array holding the current layer, filter out the indexes which don’t contain blocks, so that we’re left only with cells that actually represent blocks. For each one of these cells, we checked the position value for the block, and used that to see if it is covered by a block in a higher layer. If you’re wondering how we can filter the active cells, it can be done like this:

First we filter the array to get just the cells whose value is higher than zero, and then we request the keys of those cells.

Now our Layout class can really supply us with what we need in order to build the board, but as you can see it doesn’t build anything; it just returns an array of coordinates, which will be used to actually build the board (like in the Memory game). The one that will actually build the board will be the Board class, which will use the Block and Layout classes to generate that bodacious board-building code. And since we’ve already completed our Layout class, let’s get started on the Block class.

The Block Class

The Block class is pretty simple. Upon its creation it will get its index in the graphic map file we created earlier (i.e., which block it represents), and will then position the background image in the map file. It will do this by checking which row and column it’s located in; combined with the (already known) block dimensions, this provides the needed information. The block’s index in the graphics file will also tell the Block class if it’s a normal numbered block, or a group of special blocks that can exist only once and match each other.

After setting all of these values, the block knows how to generate its css and html markup:

As you can see in the above html method, the block will get its layout information as a parameter just to enable it to generate the markup; as an entity it only knows its type and which graphic to display.

Finally, the Board Class

As we’ve said before, the one that will bring all of the above together and use it all to create the actual board will be the Board class.
When the board is initialized it will gather all the required details:

After the Board class is initialized, we can easily get the html markup and the needed css:

Thats about it. A simple file with a call to the following code can get us a nice looking mahjong game board. But we are still only halfway there: we still need to add the game logic, and we will do just that in our next post.

Until then, have fun!

Adi Gabai

Since we are dealing with a lot of elements here (at least 144 objects for the tiles alone), it is better to build the layout on the server side. To do this, we will use PHP. We already know some of the code since we used it in the Memory game but we have a lot of new additions here.

1. We know we only have one graphic file
2. The board does not have a quadrangular (square-like) shape.
3. The board is made up of several layers

Before we start, remember: today we’re only going to create the logic for the creation of the game board; we’re not going to touch the gameplay logic just yet. Let’s start by creating a layout file. There are number of ways to create a layout file. The one I’m about to show here is used mainly for its simplicity and is probably not the most efficient way, but it will do for now. We are going to use Excel, or any other application that can generate a csv from a table. I guess I could spend the time to build a layout builder for the game, but as I don’t have much time to spare, the csv will do for now.

What I did was to create a “table” with 30 columns and 16 rows in order to draw the first layout. Each tile will span 2 cells horizontally and vertically (a 4-cell square), but we will only use the top left cell to represent the tile. In this table we will fill in the first layer of the layout, but before we do that we first need to understand the limitations of our game client. The game is for a web browser, so in order to put one element on top of another element in a browser, we need to make use of positioning and z-index. Positioning allows us to say where we want each element to be, and the z-index allows us to tell the browser which element is higher than another. This wouldn’t be an issue for us if we were using 2D tiles, but because in the last post we created 3-dimensional tiles, adjacent tiles will by necessity overlap one another, and we will need to avoid situations like this one:

If we left the z-index out of the picture, the browser would render the layout with the default behavior of placing each element on top of the previously created element, but that would leave us little room for adjustment if we needed to place a certain tile on top of another. Such a situation would give us quite a headache, even with the basic layout.

So now that we know that the z-index is a factor, we can start filling our table. In our table, each cell will contain one of the following: If the cell is not the top left cell of a tile, it will contain a 0; otherwise, it will contain the tile’s z-index. For the first layout, we’ll use incrementing z-index values to make it easy to understand; for the second, we will generally use the same small number and only use others when we need to change the default behavior, to make it quicker . Getting back to our table for the first layer, go ahead and fill out the cells as in this image.

As you can see, the filled blocks kind of look like a turtle, which is the classic layout for mahjong. If you take a closer look at the table, you will notice the value of cell A8 is inconsistent with the rest, since in this position the default behavior is not what we want (we want the tile in A8 to be “lower” than the tile in C7, even though it is created after it), and so we use a lower z-index. The same is true for cells AA8 and AC8, except in these cells we will use a higher z-index rather than a lower one (because we want them to be higher than the tile in cell Y9, even though they are created before it). Generally speaking, we only need to tweak the z-index values in situations where the tiles are not flush with each other, like in the picture above.

Now that we have our first layer, the second is even easier to build. Because each layer’s tiles are always placed on top of existing tiles in the previous layer(literally on top, not just overlapping like the situations we’ve had so far), we are limited in where we can place the tiles. Create another table below the first one with the same number of rows and columns and then fill it like in this image.

Now that you’ve seen how to build the first and second layers, the rest are really easy, but in case you want to see how they’re done, you can view them in level 3, level 4 and level 5.

Now that we have all the layers in our spreadsheet, we need to convert them to a format that PHP can work with quickly. To do so, we will use a middle man in the form of a csv (comma-separated values) file. Let’s create a directory called layout under our mahjong directory. In it we will put all the layout files. Create a new file called classic.inc.php to be included in our php script, and open this file for editing. In the beginning of the file we will have some details about our layout: the number of columns and rows and an array of levels for the layout, like so:

To keep the example short I left out some of the levels, but adding them is a simple matter of copying and pasting from your csv file and adding a comma to the end of each line (except for the last line in each layer). What we did here was create a layout array, which holds each layer as an array. Our array is one-dimensional, but since we know how many rows and columns comprise it, we can use that information to “divide” the array and build our layout.
Now that we have the php file we are finally ready to read and process it, and this is what we will do in our next post.

If you want to see another example of a layout, I created another layout in the shape of a cat. You can download all the relevant files here.

So until next time, have fun

Adi Gabai

Since this is a more complicated game, I decided it would be best to tackle it in several posts instead of just one. In this first post we’ll create the graphics needed for the game. Let’s start by considering what this game needs to include. If you search the web for even a few minutes you will find that there are several versions of this game, each with its own set of rules. To make things easier, our own basic version of the game will use simplified versions of some rules, and ignore others (like score) entirely.

So what does that leave us with?

1. Multiple sets of tiles:
   27 Common tiles, consisting of 3 sets of numbered tiles, each set with 1-9 images of the set icon (e.g., flowers, cars). A Common tile must be matched to its exact counterpart (e.g., six of cars matches six of cars)

   4 Picture tiles. Picture tiles have only a single large icon on them, and work the same as Common tiles, in that each tile can only be matched to its exact counterpart (e.g., pink clock matches pink clock)

   4 Single tiles. These tiles feature a picture (not an icon) but no numbers, and each tile can be matched to any of the others (e.g., squirrel matches beach)

2. With the exception of the Single tiles, there are 2 pairs of each tile (144 tiles total)
3. The board can have several different layouts.
4. In each turn the player must select two matching tiles, in accordance to the behaviors described above, and the rules described below.
5. If the player selects two valid, matching tiles, the tiles are removed from the board.
6. The game is won when there are no more tiles on the board.
7. The game is lost if there are still tiles on the board, but no more moves are available to the player.

As I said, we are going to start by creating the game’s graphics. Since we have about 35 different tiles with different graphics on them, we will be dealing with a lot of objects, which means we are going to suffer a hit to performance. Therefore, whatever we do next must take performance into account. What does performance have to do with the graphics, you ask? To answer that question, let’s consider how we did things in the Memory game: In that game, we used separate image files for each card. If we did the same here, we would trigger a lot of different network calls, and even if we used caching it would still be slow, because we’d have to move around a whole bunch of different graphic files; unlike the Memory game, where we had relatively few cards, and therefore relatively few graphic files (actually, now that I’ve made that observation, I think I need to go and apply the solution which I’m about to share to the Memory game, too). To work around the performance issue, we could combine all the tiles into one big graphic file, which we could preload if we wanted. If we used caching, the performance would be even better. Because all of our tiles have the same dimensions, I think it would be very easy to use a single file for all of them.

So let’s get to it. Go ahead and open your favorite graphics software; in this example I’ll be using Adobe Fireworks, but I’m pretty sure any program will do. The first thing we need to create is our basic building block: the tile. Since Mahjong boards have layers, we need to make sure our tiles have a 3D look. To do that, we will draw a rectangle with a height of 68 and a width of 50. I chose white as the background color and a shade of gray for the stroke (or borders): #999999. To get the 3D effect, we will need to give this image some depth. We can do this by drawing a 4 pixel diagonal line from the upper right corner to the lower right side with the same color as the stroke. Do the same at both of the bottom corners. The end result will be a rectangle with 3 diagonal lines coming out of its corners:

Draw lines to connect the diagonals and create the 3D rectangle:

We now have 2 big empty spaces created by the lines we added. I filled them up with a lighter shade of gray: #cccccc.
So the final image is:

YAY! We now have a basic empty tile! We can now create a new file with a height of 360 and a size of 486 and fill it with our new tiles (make sure you are accurate in positioning them side-by-side. The end result should look like this:

Excellent! We are now ready to fill in the tiles. The structure of this file is as follows: the 3 upper rows contain the Common tiles. The 4th contains two sets of Picture tiles, and the last row contains 4 Single tiles (remember, these tiles will not be duplicated).
For icons you can just use whatever you want. Just make sure you are not violating any copyrights while doing so.
My final image looks like this:

Now we have our tiles image ready. In my next post we will take this file and extract single blocks from it for display. We will also create the logic to duplicate the tiles according to our game guidelines.

Remember: When using a lot of images in one webpage it is wise to reduce network call by having one file that includes all the images when possible (at least when they are for the same purpose and are the same size).

So until next time, have fun

Adi Gabai

So let’s break down what’s in this game:

1. Pairs of cards
2. Raising the level increases the number of cards
3. In each turn the player flips over 2 cards
4. Matching cards are removed from the board
5. The player wins when there are no more cards
6. To keep things interesting – some effects

We have a lot to cover in this little guide so in order to keep things as short and quick as we can I’m going to skip some of the phases in building this game. If you want to see those phases, they can all be found in the demo.

To understand this guide you need to know some basic javascript & jQuery, and some PHP. There are some excellent guides for these topics all over the web to get you started or answer your questions.

1. Pairs of cards

In order to create the cards that will be used in the game I used an array to hold the available image files. I used 20 different image files in order to create a randomness factor for the images (assuming I will use less than 40 cards). When the board needs to be initialized, we select some random elements from the array of image files according to the number of cards we need on the board, and then we create card objects from each file. Since we know we need two of each card on the board, we “double” the array by merging it with itself. And now, a quick shuffle and the array for the board is done.

What is a card? Well a card will be displayed in the game, we will need to know how to build its css properties in such a way that we will have an element with the right background image and so on. As you can see below, the Card class is quite simple:

The Card object creates its css class name based on the file name. It handles the its own html markup and css markup, and that’s about it. The Board class that we saw pieces from earlier will handle the building of the board’s html and css using the Card class.

2. Raising the level increases the number of cards

In the code above we used a variable called num_of_cards. This variable’s value is determined by the level of the current game: At low levels we will have relatively few cards, but as the level increases, so does the number of cards on the board.
Let’s look at the code for this:

This code was also taken from the Board class. Let’s see how it adds up by taking a look at how we initialize the Board class and set the level:

If the user sends a request for a certain level, we use it for every game he plays from this moment on. If no request is sent, we use the default first level (1). In addition, we can see that we only set the board once per session, unless the a level request is sent, which is almost true (later on we will see that we also reset the board after the player wins). Saving the board in the session is done with the future in mind: as you will see in this post, the logic of matching the cards is carried out, for the moment, by the client. But if you want the game’s logic to be more secure, it should be carried out in the server, and then the server will need to know how the game board is built. For now, let’s go back to our subject.

Just before we move on to see how the player turns the cards we need to actually see how we build the board:

3. In each turn the player flips over 2 cards

Now that we have our board, it’s time to add some interactivity and the main gameplay. We will use a special (and excellent) jQuery plugin to handle the flipping for us. You may have noticed before that, when we built the card’s html block, we actually built a wrapper and two elements inside; one for the back side and one for the front. This markup is recognized by the QuickFlip plugin (which you can get here). Now there are two things we need to do. First, we need to register the Click events for the cards. Second, when a card is clicked, we need to trigger the flip and run a check to see if:

• The two cards match, but there are still cards on the board
• The two cards don’t match
• The two cards match, and there are no cards left on the board (i.e., the player has finished the game)

Let’s take a look:

In order to do its job, QuickFlip will duplicate our elements, so we want our selectors to be more precise. That’s why we’re using the direct child (>) directive in our css selector. We can also see the use of the setTimeout function since in case we have two cards turned over, we want to give the user a second or two to look at them before we turn them face down again. We added the card’s css class to its element according to the metadata which we got when the Board class built the html (metadata is another excellent jquery plugin that can be found here).
If you noticed the line: $(document).trigger(“flipping_cards”); we are also triggering a custom event which we can bind to later with different plugins for the game if we will want to, if you haven’t already done so you can read about custom events in my previous post: jQuery custom events.

4. Matching cards are removed from the board

Now that the player can flip a card to see its image, we need to check if we have a match or not. If we have a match, the cards will be removed from the board; if we don’t, the cards will be turned face down again.

5. The player wins when there are no more cards

In the above code we check if no more cards are left; if that is the case, the player_won event is triggered. When this event fires we need to do several things: We need to notify the server that the player won, and we need to show the player a message letting him know that he won. Let’s see how it goes:

We can see that we notify the server with a simple ajax request. The server will then reset the board for us and remember the win.

6. To keep things interesting – some effects

At this point the game is basically working, and it’s time to add some sound to it. Usually I absolutely hate sounds in web pages but since this is a game, it’s allowed . So in order to add the sound, we are going to use the “hooks” we left in the code in the shape of custom events. We are going to use a Flash object with some preloaded mp3s for the sound effects. The communication between the JavaScript and the Flash (actionscript) is pretty simple these days, but it’s not in the scope of this guide. However, if you want a guide on this let me know in the comments and I’ll post one. For the purpose of this guide, let’s assume we have a Flash object that can accept commands and output sounds. We will use swfobject to embed the flash object to the page.

Now that’s done, it time to handle the binding the events and triggering the sounds. We want the sound to play when the player flips a card over, when we wins the game, and when a match is found.

That’s it! You can check how everything fits in place and view all the code by looking at the demo.

Zip file for this tutorial

Demo for this tutorial

So until next time, have fun!

Adi Gabai

Custom events go together with an event-driven programming style, a style whose benefits I’m sure are explained by many articles out there. What I want to focus on is the relation to web programing in jQuery or javascript in general. In every application I worked on there was a need to bind to certain events like onclick, onsubmit and onload (to name a few). I don’t think there is a modern application out there that doesn’t use at least one kind of event. Therefore I think it’s only natural that the application will define a few events of its own.

In my opinion, integrating custom events in almost every web application is very beneficial for us as developers, since it gives us some very powerful possibilities and flexibility. Let’s think of a basic example related to gaming; let’s say we’ve created a game with the following basic flow:

1. When the player’s turn starts a pair of dice is interactive.
2. The player then rolls the dice.
3. The player chooses a move.
4. A piece on the board moves.
5. We check if there is a win condition.
6. If there is a win condition, finish the game.
7. Else, start a new turn.

We’ve described a very basic dice game. I don’t really have any idea what the game is about at this point and for the purpose of our example, it doesn’t even matter. Once we have written the code for this simple interaction we can use it for many different dice games. We can port it from game to game by copy pasting the code we had, or we could use some kind of hooks for the different functionality, like what to do when the turn starts, what to do when the player has made his move, or even when we have a win condition. All of these can be events. A custom event can be “player_rolled_dice”, “player_won”, and so on… an event can receive parameters just like functions, and that is what we are about to see now.
Take the following example:

We can see the checkWin function, which triggers the event “player_won”. We didn’t see anything binding to this event, so nothing will happen, but let’s say later on we decide that we want to keep a high score board. Because we already have a “hooking” place, we don’t need to change the code for the checkWin function; all we need to do is something like this:

To add to more flexibility, this can be in its own file: if the file is loaded / initialized the code will run, the function will be bound to the event, and the highscore will be saved upon win. And if it doesn’t, then nothing will happen. We just expanded our functionality without changing the original code.

I know this is a bit high level with no real practice code, so let’s look at a small example to see how things work.
Create a web page with jQuery attached (or use an existing one) and add the following javascript:

You can even add another bound function, such as:

And if you will run the code now you will get two annoying alerts in the order in which you binded the events. The possibilities which this functionality brings us, as we will see in the upcoming posts, are really great.

’till next time,
Adi Gabai

1. The size of the game map is 3×3.
2. We have 2 players (X & O).
3. Each player makes a single move in his turn.
4. A move means marking a field in the map with the player’s mark.
5. A player wins when he has a full row / column / diagonal.

Now that we have our basic design requirements, we can start programming them one by one. I’m going to assume you already know how to create the needed html/js/css files and connect them. You will also need to connect your html file to jQuery, since we are going to rely on it.

For those of you who might still be having problems with creating the structure of the files together there is a demo available at the end of this post. Feel free to take a peek there.

1. The size of the game map is 3×3

To create the game map we can just create 9 divs in our html file, but instead of that I’d like to create them with the help of a little JavaScript, since this is one of the requirements that look like something we might want to expand later on.
In order to do this, let’s start by creating a div to be our game map.

CSS:

and now let’s populate that div with some JavaScript:

CSS:

So, we’ve created a floating div to act as our game map. For every row and col(umn), we’ve attached a small floating div to act as a cell in our game map. There are various ways to position the cell in the game map, but I don’t want to position them; I think its simple and fun to just float them. But since floating everything has its own small price, we’ve also added a small non-symantic div to the game map to handle our rows.

There are many hacks and tricks to avoid adding markup for layout, but I consider this little extra markup to be quite harmless.

2. We have 2 players (X & O)

The number of players and their marks is another item that looks like we can customize it later on. So we might leave some places ready for customization, without really delving into the little details.

So what does having 2 players mean? For one thing, it means we will need to keep track of the score . It also means that we might need to indicate who is playing and who’s won. We will also need to have some kind of representation for the players and their respective marks (X / O).

So let’s see how we can achieve those goals. Let’s start by representing our players:

What we just did was define two simple objects with the following attributes: mark (e.g., X, O), name, style (which will direct to the css class the player uses) and score_el (score_el holds the element id for the element which we want to update with the player’s score). After that, we put the players in an array in order to be able to access them easily with an index: current_player.

So far it’s pretty simple, and soon we will see how we can use all of the objects which we’ve just defined.

Before we go on, let’s define the css classes that will be used to represent the players in the game: player1_cell & player2_cell.

As you can clearly see, these classes are just used to make the display a bit clearer, and distinguish between players.

3. Each player makes a single move in his turn

Some games allow the players to play simultaneously, but in tic-tac-toe the players take turns playing, which makes things simpler for us .
So what do turns mean? Mostly they mean that it’s time to indicate who’s supposed to be playing now.
Let’s prepare some html elements for the display:

We’ve added a simple line with placeholders for the player’s name and his mark. Now let’s fill them with some JavaScript code:

Now we’ve added the function that will be called to initialize the values in the html placeholders.

4. A move means marking a field in the map with the player’s mark

So far so good. We now know who’s turn is it, but we still haven’t addressed what the player can do in his turn and what a move really does. So what does a move mean? It means that the player will do something in his turn: he will move the mouse and click a cell in the game map. These actions will result in his mark being placed in the chosen cell and so on… let’s see how we can achieve all of this.
Look at the following code:

What we did here was define some events. This code will be placed with the same code we used earlier to create the game map. I chose to use the jQuery .bind method instead of the .click since we need to use the great power of .unbind later on; an event attached with .bind can be detached very easily using .unbind.

So now that we have the events set up for us let’s move on to the functions we attached:

The first two functions are quite simple, when the mouse enters a certain field we attach a hover class, and when the mouse leaves the field we remove the class. If you are wondering why we haven’t used the :hover pesudo css class, it’s because it will not work in older browsers like IE6 and it’s simpler to turn off a bind function than to replace css classes and play with what comes first. Using the JavaScript method, we have a simple .hover jQuery method, but again we need the power of unbind.

The playMove function adds the player’s style and mark to the clicked element and then disables it by removing the events from it, but not before it triggers the mouseout event so we will not stay with the hover class. After making these changes to the element itself (the cell on which the player clicked), the function also calls the checkAndProcessWin() function, which will check what happened after the player made his move and act accordingly.

We then change the current player by rotating the players, as follows: if the current index is 0 it means we’re using the first element in our players array which is player1. Increasing it by one will make us use player2. After that we want to go back to the first index, which is why we’re using the % operator with the numbers of players. As you will soon see in the function that checks the win condition, the % operator is about to become our best friend.

5. A player wins when he has a full row / column / diagonal

The last (but not least) requirement in our game design. Most of the core of our game is here, where we check the winning condition and what to do with it.

This function is a bit more complicated than the ones we’ve had so far, but I’ve tried to keep it simple as I could make it. We will add a new custom selector in our document ready function as follows:

Custom selectors are one of jQuery’s strong sides. You will see how we’ll use these selectors in our win condition function in just a bit.

So how are we going to check if the player’s won? Let’s think of our game map / board for a bit: A player wins the game if he manages to fill any row, column or diagonal, so we need to check if the current player did so. Let’s start by checking the rows:

To check the rows, we’ve created a for loop to go over each row until it either scans all the rows or finds a win condition. For each row the function filters out the cells of the game map that don’t belong to that row, leaving us with only the row’s cells. Then the function filters out any cells that don’t belong to the current player. This leaves us with all the cells owned by the current player in the current row. If the function finds that the player owns all the cells in the row, it returns a win.

Now let’s check the columns. We’ve already added a custom selector so it’s time to see it in action.

See how easy it is to check the columns when we have our custom selectors? All we need to do is to filter the column according to a certain modulus and see if we have a match. Most of the logic here is the same as when we checked the rows, but here we have the help of our custom selector named :sub_mod.

OK, we’ve checked the rows and the columns, but we still have the diagonals to check. For this task we don’t need loops, since we will always have exactly 2 diagonals, regardless of the game map size.

Both diagonals are checked with the help of the modulus functionality, though we don’t use it in quite the same way. We also need to take care not to select the fields (last and first) in the last check since they can never be part of the win condition there.

Those were all the conditions we needed to check in order to find if the player won. There is a bit more work to be done in this function, like speeding things up a bit (for example, check if we have less than 3 fields marked, since that would mean there is no chance of a win). We also need to notify everyone of the win, maybe with some fireworks… You can see the complete function in the demo files.

Before We Finish

That was quite lot to cover in one go, but we are not done with our little game yet. I’ve left out some of the code in an attempt to keep things as simple as possible, but please feel free to check out the demo to see the rest. Also, since we are talking about web development playing locally is a bit… wrong . So next we are going to see how we can add some multiplayer support so you can play with your friends online. We will also add some basic AI so you can play against the computer, and see how we can customize the game a bit.

Zip file for this tutorial

Demo for this tutorial

So until next time, have fun

Adi Gabai

There are a lot of sites, blogs, and portals  around that teach and explain how to do this or that in web development, so you may be asking, why do we need another one? Simple – We can never have enough. No, really. I started learning web development about 10 years ago, and ever since then I find myself constantly in search of more sites, and many of the sites I’ve found have managed to teach me something new, so I really do think we can’t have enough, especially this day and age.

There’s another reason for my starting this blog. As I mentioned, quite a large chunk of the things I know, I’ve learned from other people’s blogs and sites, so I think it’s about time I started giving back to the community.

Having said that, you are now probably wondering what is going to make this particular site so special, so let’s answer that next. In this site I’m going to focus less on web design (much less actually), and more on the logic of web development. The main focus is going to be building browser based games, built with JavaScript, (x)HTML & CSS (once in a while a bit of server-side scripting will be involved).

I plan to update about once a week with new projects/parts. This week we will start with a simple game of tic-tac-toe. You probably know this one and it will be easy and fun to write, so stay tuned.

Until next time,

Adi Gabai