Bejeweled Match 3 Games

[Kym Wash]

Thestrategy that has worked the best for me is working from the bottom up, switching from left to right. Working bottom up allows for cascades without disrupting your flow, and similarly for left-right letting you plan in advance and then move while blocks are falling elsewhere. The cascades are important because you need to destroy 12 tiles at once to drop a multiplier, and those are key to a high score.

Many rounds just won't pan out, and you'll have to be patient to get the exact right factors for a high score (this appears generally true from all my friends' scores too, where their totals in 25k, 50k, 75k, etc. categories match my distribution). If you're not enjoying each game much, it probably isn't for you (it's not for me), because high scoring games are going to be relatively rare for some time.

In a prototype I am doing, there is a minigame similar to bejeweled. Using a grid that is a 2d array (int[,]) how can I go about know when the user formed a match? I only care about horizontally and vertically.

Loop through each item in the same axis (x or y), if they are the same as the previous item them increment matches. When the next item becomes different, check if matches is or greater than 3, call a function that removes matching items, and continue.

We have built a prototype for a Match-3 based word game, a little like mashing up scrabble and Bejeweled. We realized very early on that the engine that supplies new gems/tiles to fill empty spaces would have to be highly introspective (we run hybrid heuristics and MonteCarlo sampling) in order to create actual opportunities for a player to string letters to form words through the Match-3 mechanic. It's way more elaborate than the description but I'm keeping it brief because we'd have to write a paper.

To answer the OP -- we are doing pattern checks to score how many matches there are on any given gird, at the current time, through a method very similar to "gladoscc" code snippet. While it works robustly, the computational cost for running that recursively during the tree-search play-out becomes a substantial burden, so we are in the process of rewriting this portion of the logic and the data-representation with the bit-board methodology (commonly implemented in other-grid like games like chess, checkers, Othello, etc.) In tests we have shown that it can run over 20 times faster in ActionScript, and so for us the need to do it is a slam-dunk -- and frees up essential cycles for responsiveness, sound, animation, etc.

Rather than starting from scratch I started to take a look around to see if somebody had already done it and came across Bombevo which executes the concept very well in a fun game where you fight an alien space ship.

This game was made for Ludum Dare and you can download the original source code for Bombevo here. The code is quite complex though and in some parts unfinished so I wanted to create my own version based on Bombevo that takes it all back to its simplest form.

Although quite a few parts are different in this tutorial when compared to Bombevo, it is still heavily based on it (especially the match finding algorithm and tile resetting) so a big thanks to the creator harsanalif. The end result of our version of the game will look like this:

As is usually the case with my Phaser tutorials, I will be building this game on top of my basic Phaser game template. This is a skeleton application with some default states and structure set up that I use to start just about all of my Phaser games. If you want to follow along with the tutorial, you can download the template by entering your email address below:

This is clearly a good structure to use for our grid since it basically mimics exactly how the actual grid will look (especially when we format it over several lines like that). An important distinciton to make before we jump into it though is that this is only a representation of the state of the game, what we actually see on screen will just be achieved by placing sprites at certain coordinates (which we will work out using this grid).

Most of the code above should be pretty self explanatory with the comments. One of the important concepts here is the active tiles, which we use activeTile1 and activeTile2 to keep track of. This forms the basis of how we know when to switch two tiles, later on in the code we will keep track of where a user clicks (which will be the first active tile) and then where the user drags to (which will be the second active tile). When we have two active tiles we will switch their positiojs.

Another important part of the code above is the tileGrid. As I mentioned before, this is what we will use to store a representation of the state of the game (i.e. where all the tiles currently are). The example above will create a 6 x 6 game grid, but you can easily add extra elements or arrays to create whatever grid shape you like, e.g. you could just as easily do this:

The tileDown function will set the first active tile and keep track of where the click started (so that we can compare it to where the user is hovering later to work out if a tile swap should be triggered).

We work out where the user is currently hovering, we then translate that into a position on the grid (so if the user is hovering a x: 375, y:200 in the game, that might convert to a position of tileGrid[1][3]). If the difY or difX values are 1 then we know the user has moved over 1 tile space, in which case we trigger the tile swapping process.

This function loops through all of the matches returned from the previous function and removes them both from the grid and from the screen. The problem we have though is that we only have a reference to the tile, which is a sprite, but we need its position in the grid so that we can remove it from the grid. To do that, we create another function called getTilePos which will search for that specific tile in the grid and then return the x and y coordinates of where it lives in the grid.

With this function we look at each column of tiles one by one, and then we look at each specific tile within that column. If we find a spot that is blank, but the spot above it is not then we move the tile above down one space. If this happens then we do a little trick with the for loop by resetting the counter (j) back to the beginning again. Since the positions have changed we need to start from the beginning again. Imagine if you had a tile with three blank spaces below it, this code would need to restart two times since when we check the bottom blank space the first time there will be nothing above it to move down, but when we check it on the second reset it will have a tile above it because the tile keeps getting moved down into the empty spots below.

That was a pretty complex game, but it makes sense if you step through it slowly and try to figure out what each function is doing. Now that you have the basic mechanic for the game, you could extend this to make it more fun and interesting. A few things to try might be:

Bejeweled is a tile-matching puzzle video game franchise created by PopCap Games and distributed by Electronic Arts. Games in the Bejeweled series involve matching three or more multi-colored jewels in a straight line, in which gems fall, often creating cascades.

Since the initial release of Bejeweled in 2001, Bejeweled has been ported and re-released to a variety of different platforms, ranging from PCs, mobile and smartphones, consoles, in-flight entertainment systems and more. More than 10 million copies of Bejeweled have been sold, and the game has been downloaded more than 350 million times. By February 2010, Bejeweled sales hit 50 million. The figure includes the original game, plus the Blitz and Twist versions. In 2020, Bejeweled was inducted into the World Video Game Hall of Fame.[1]

Bejeweled was influenced by the game Shariki, written in 1988 by Russian developer Eugene Alemzhin, which had nearly identical gameplay. The popularity of Bejeweled has spawned several clones. Collectively known as match three games, these games revolve around the mechanics of creating three-in-a-row combinations of identical pieces.

After the release of Bejeweled, the game has been ported to many platforms, including cellphones, smartphones, game consoles, plug and plays, in-flight entertainment displays, and more. The series would be subject to several non-video game products including casino machines, three board games from Hasbro, a web series based on the characters Snackers and Anchovy from Bejeweled Blitz and more.

On September 25, 2008, Bejeweled was officially released as a free addon for the fantasy MMORPG World of Warcraft, alongside Peggle. In addendum to the standard 'Classic' (Normal) and 'Timed' modes, the addon has an exclusive 'Flight' mode, wherein the game begins when the player takes a flight from one in-game location to another, with the goal to score as high as possible before they reach their destination. The WoW addon adds achievements to the game, as well as a levelling system.

Bejeweled is the first game of the series, and first PopCap title to be released into retail. Originally released as a web browser game named Diamond Mine in November 2000, it was later developed into a retail title before being renamed to it's current name due to conflicts with another product sharing the name. Bejeweled was released on browsers in 2001 as a free Flash game and later ported and improved as a paid game to PC (as Bejeweled Deluxe) on May 30, 2001. and mobile devices (as J2ME). More than 150 million people have downloaded the game and 10 million copies were sold.

Bejeweled 2 is the second game in the series that was released in November 2004. Bejeweled 2 introduces the planetary space theme that would be used throughout the 2000s and adds Special Gems to the game, along with new modes. The Deluxe version contains unlockable modes unlocked through various requirements.

3a8082e126