Memory Match Game - Extending a Game Template

3
  • 20 favourites

Attached Files

The following files have been attached to this tutorial:

.capx

memory-match.capx

Download now 4.08 MB

Stats

3,481 visits, 4,833 views

Tools

Translations

This tutorial hasn't been translated.

License

This tutorial is licensed under CC BY 4.0. Please refer to the license text if you wish to reuse, share or remix the content contained within this tutorial.

(Original template taken from scirra.com/tutorials/280/creating-a-memory-match-game)

The objective of this tutorial is to show how one might modify a game template, and in turn to give you all a template to build off so that you can do the same thing.

I have decided to extend a memory match game template to include progressive difficulty, recent scores, and a save state. Modifying the images of the game itself to suit your needs should be fairly simple. Just adjust any of the images of the cardFace animation of the object Card. Note how there are two pairs of each item. This is to simulate an actual deck of paired cards, so keep to that structure if you don't want to modify the game extensively.

Objective 1: Progressive Difficulty

This simplest incarnation of this in a memory match game is to increase the number of rows and columns in the game. The author of the original template was kind enough to name such variables for easy identification. They are as follows:

gNumberRows

gNumberColumns

One might simply add one to each of these variables after each win in order to make the next round of matching harder. I chose to add one to only one of the variables each time. Specifically, columns increase, and then rows, and then again and again. Here are the events I used for this:

First I check to see if gNumberRows and gNumberColumns are equal to MAXROWS and MAXCOLS, global variables I have defined to be 6, respectively. This is so the game doesn't increase beyond the number of cards I have (36, since I have 18 pairs of cards). If that is true, I set a local variable I am treating as a boolean (1 being true, 0 being false) to 1, meaning I am done messing with those variables.

Otherwise, I first increase gNumberColumns and then block out the next condition by setting hasSizeIncreased to 1.

If hasSizeIncreased is 0, and gNumberColumns > gNumberRows, then we go ahead and increase the number of rows.

Thats it for that. Now we have a nice difficulty curve in our memory game (which could get brutal if you increase MAXROWS and MAXCOLS and the number of card pairs in the game)!

Objective 2: Recent Scores

Okay, now we want to keep the most recent scores and store them for display by a page we can access from the main menu.

So, to keep the score, we will need an array. We could just have an array of score numbers, but that would be a little boring. The information I settled on keeping in the recent score chart is the score, the row and column count for that game, and whether or not the player won that round or gave up or exited to the menu.

Since we want to save so many values, we are going to need some conglomerate object to contain them all. I chose to use a dictionary, because I like the ease of accessing key and value pairs. I decided to put saving in a function, and then use the location from which I call it to differentiate between the "Yes" and "No" values for the key "win".

Those stored values can then be later accessed and displayed with an event sheet like the following.

Objective 3: Saving

Saving is really only important in this game for keeping our high score and recent scores around. The original author had no such plans, and thus the global variables are not quite save friendly, as they get reset on load and are required to have a certain value. Delve more in to the event sheet to get a better idea of what I mean. This is particularly important for gFirstTimer, which sets the score array to have a size of 0, so that our recent score display is empty on a first play of the game.

A more important and interesting variable though is the gComeByGame variable. What is the gComeByGame variable? It is a variable to let use know whether or not to load or save on entry to the menu start screen. In general, since we go to the Start layout be beating a game or giving up, we want to save on layout load. However, that doesn't make sense when we first start the game, especially if we have a save stored that we want to load, because if that is so, we will save and overwrite it before having any chance to load. Thus, we keep gComeByGame at 0 (or false, meaning we didn't come by game), so that on starting the game we load instead of save, and we change it only when we win or click the back button in the Game layout.

This all looks like this:

Hope this helps with ideas on how to mess with templates. Mess with my extension of the template (itself, also a sort of template), with the uploaded capx.

.CAPX

memory-match.capx

Download now 4.08 MB
  • 0 Comments

  • Order by
Want to leave a comment? Login or Register an account!