In this chapter, you will use the knowledge of the previous chapters to create a well-known memory game. However, instead of presenting and explaining the code completed in the previous chapters, you will design a model first and work your way up from a modest beginning to a completely functional game, step by step. You will also learn how to enhance the attractiveness of web games with audio and video techniques. The following topics will be covered in this chapter:
- The model for the memory game
- Spiral 1—drawing the board
- Spiral 2—drawing cells
- Spiral 3—coloring the cells
- Spiral 4—implementing the rules
- Spiral 5—game logic (bringing in the time element)
- Spiral 6—some finishing touches
- Spiral 7—using images
- Adding audio to a web page
- The Collision Clones game
- Adding video to a web page
When started, the game presents a board with square cells. Every cell hides an image that can be seen by clicking on the cell, but this disappears quickly. You must remember where the images are, because they come in pairs. If you quickly click on two cells that hide the same picture, the cells will "flip over" and the pictures will stay visible. The objective of the game is to turn over all the pairs of matching images in a very short time.
After some thinking we came up with the following model, which describes the data handled by the application. In our game, we have a number of pictures, which could belong to a Catalog. For example, a travel catalog with a collection of photos from our trips or something similar. Furthermore, we have a collection of cells and each cell is hiding a picture. Also, we have a structure that we will call memory, and this contains the cells in a grid of rows and columns. Using our Model Concepts graphical design tool from Chapter 4, Modeling Web Applications with Model Concepts and Dartlero, we could draw it up as shown in the following figure. You can import the model from the game_memory_json.txt file that contains its JSON representation:
A conceptual model of the memory game
The Catalog ID is its name, which is mandatory, but the description is optional. The Picture ID consists of the sequence number within the Catalog. The imageUri field stores the location of the image file. width and height are optional properties, since they may be derived from the image file. The size may be small, medium, or large to help select an image. The ID of a Memory is its name within the Catalog, the collection of cells is determined by the memory length, for example, four cells per side. Each cell is of the same length cellLength, which is a property of the memory. A memory is recalled when all the image pairs are discovered. Some statistics must be kept, such as recall count, the best recall time in seconds, and the number of cell clicks to recover the whole image (minTryCount). The Cell has the row and column coordinates and also the coordinates of its twin with the same image. Once the model is discussed and improved, model views may be created: a Board would be a view of the Memory concept and a Box would be a view of the Cell concept. The application would be based on the Catalog concept. If there is no need to browse photos of a catalog and display them within a page, there would not be a corresponding view. Now, we can start developing this game from scratch.