Editor’s note: this is a guest post by game developer Roberto Peña. It is part of a series called Game Dissection, which aims to inspire and enlight game developers by showing how a game was made.

Numbers Toys is a jigsaw puzzles game mainly oriented for little kids (2-5 years old), with several different types of puzzles and with an increasing difficulty to invite playing children of all ages as well as mums and dads.

I decided to use the numbers (from number 1 to number 9) as an educational context, showing them as cartoon characters and putting them at the center of the jigsaw puzzles.

Development team: Roberto Peña (ImaGame)

Development objective

The main objective from a development standpoint was to include in the app different variations of a conventional jigsaw puzzle, taking advantage of Object Oriented programming (OOP) techniques and the implementation of OO Design patterns. Abstraction, inheritance, polymorphic features between others, have been used to make three different kinds of puzzles in a first app version. The app would be ready to be extended with new types of puzzles for upcoming versions in a easy and costless way.

Numbers Toys version 1 contains 3 different kind of jigsaw puzzles, applied to each number (1 from 9), having 27 distinct puzzles. Difficulty level increases as you build the puzzles and complete levels, adding an additional variation factor to all the puzzles.

The 3 different types of puzzle games have internally lot of code in common. From an external point of view they are different kind of game. The 3 types of puzzles are explained below.

---

Puzzle Type 1

The goal in Puzzle Type 1 is to discover the silhouette of the Number which is hidden under colored squares:

The gameplay mechanics consist of removing colored squares when tapping on them, but only when the right color is selected:

• The square will be removed only if its color is the same as the selected color indicator.
• Each color indicator is active for a limited period of time
• Color Indicators get active in a non sequential order
• If you tap on an colored square different than the active indicator, removed squares will reappear. The number of squares that will reappear depends on the difficulty level.
• The number of colors is different in each Number puzzle.
• Duration of the selected colors varies depending on the difficulty level

As a result all the colored squares have been removed and the hidden silhouette of the numbers has become visible. Then Puzzle Type 2 is unlocked to continue playing.

---

Puzzle Type 2

The goal in Puzzle Type-2 is to put together the colored pieces that form the Number character, filling the silhouette of the number discovered in Puzzle Type 1.

The gameplay mechanics consist of drag-dropping each piece in the correct place matching the silhouette of the number:

• Pieces initially appear on both sides of the number, in different starting positions.
• Number of pieces depends on the difficulty level
• Precision required to drop the piece in the correct place depends on the difficulty level
• Pieces dropped in wrong puzzle positions automatically go back to their starting position

As a result all the pieces put together correctly aligned on the silhouette form the colored number. Eyes and mouth will appear on it, giving to the number its own personality. Then Puzzle Type 3 is unlocked to continue playing.

---

Puzzle Type 3

The Goal in Puzzle Type 3 is to put the shapes into the matching areas that have been dynamically created on top of the board, covering the number character image.

The gameplay mechanics consist of drag-dropping each shape (piece) in the correct place within the corresponding area.

• Areas to be matched can correspond to only one shape, or to a group of several connected shapes (till 9 pieces).
• Shapes and positions are different in each puzzle game
• Basic shapes (star, cross, heart, hexagon,…) can be drag into the matching area in a easy way, but group of connected pieces are difficult to solve.
• The number of shapes depends on the difficulty level.
• Shapes can be drag an drop in any position. If the are dropped within the correct area and in the right position, the will merge with the board image.

As a result all the shapes connected together and located in its matching areas let the complete number image be visible.

Development Details

Game Engine

The game uses my own engine. It is basically a framework or set of related classes that forms the base of a game. The framework consist of the minimum required set of classes that were needed to build Number Toys. It has been evolving as the same pace as the game has been built.

Any required functionality that was required in the game has been abstracted and a generic class has been incorporated in the framework, thinking in using it in future games. Son many new features can be added to the framework, as well as the existing ones can be extended.

The key is that all of them can be directly reused for upcoming games. The main groups of classes are the following:

---

Rendering

The app is designed to behave the same way when it runs on a device with a different screen size, aspect ratio, or pixel density. The rendering engine is not a blitting engine, instead it leverages the Flash display list. The key is all the object display list is contained in a unique sprite that behaves as the screen canvas.

The baseline size of this screen canvas is 480×320 pixels. It is scaled to fit the device resolution. It forces that all the display list objects are automatically scaled. Horizontal or vertical margins (depending on screen aspect ratio) are automatically filled by the engine, and the game use it as an active part of the app.

The developer is responsible for ensuring the main game activity is going to happen in the 480×320 subscreen resolution.

---

Game Sprites And Animations

Due to the rendering system there is only one unique graphics set (same graphics resources for all sizes and densities) which is scaled in an proportional factor in both dimensions.

All the graphics used are bitmaps (no vector grahics). No movieclips are used, only sprites (flash.display.Sprite). All game sprites extend from ImaSprite (static graphics) or ImaSpriteAnim (frame based animation sprites). ImaSprites add a finite state machine behavior to the sprite.

---

Input

All input event listeners are concentrated in ImaState engine class. The ones that are going to be used are overriden in each game state subclass, which are in charge of detecting the imaSprite object that is affected by the input interaction (mouse, touch), sending the corresponding messages to it to manage the operation.

---

Sound

Default flash media sound methods. MP3 sfx assets are prepared in a in-memory dictionary.

---

Data And Assets

Default graphics and sounds assets are embedded in compile time in the executable. Same for other specific game resources. No system to dynamically load from local or remote files has been required.

---

Control And Elements Interaction

A simple game loop controls the game, updating only the active game state. Additionally calls the Timer manager to update its list of timers. No advance features to dynamically vary duration of cycles or vary time frequency.

Each game state has its update method to perform required execution logic. ImaState update state executes update method in all ImaSprites objects it contains (all UI objects and game sprites extend from ImaSprite, which can override, redefine or extend default update execution).

Interaction between game objects is accomplished using two different techniques:

• FSM based: The finite state machine logic move from one state to another based in specific logic conditions. Each states has defined its own behaviour.
• Signal based: Subscribing/dispatching message model used to send a message from an object when an specific event raises. Subscribed objects have it own answer logic defined.

The decision to use one or another interaction technique is based on different factors.

---

Configuration

Use of SharedObjects to save game progress, and configuration state. No remote save/load logic is implemented.

Technical information – Tools and Libraries

• IDE: FlashDevelop
• SDK: Flex 4.0, Adobe AIR 3.7

---

Third-party Libraries:

• TweenLite v11 (Greensock.com)
• Tweening engine. Standard version, using the following plugins: TintPlugin, AutoAlphaPlugin.
• As3-Signals by Robert Penner
• Messaging tool for communication and interaction between objects

---

Graphics

• Gimp 2.8.6, Photoshop CS4
• Graphics formats: jpg (background), png (sprites, panels, dialogs, buttons, character numbers, pieces).

All graphics done by me.

---

Sound

• Free sound effects, in mp3 format.