Creative Design of Digital Cognitive Games

Abstract

Digital cognitive games (DCGs) are games whose primary purpose is to mediate (i.e., support, develop, and enhance) cognitive activities such as problem solving, decision making, planning, and critical reasoning. As these games increase in popularity and usage, more attention should be paid to their design. Currently, there is a lack of design processes that provide both structure and room for creative development of such games. This article presents a preliminary process for design of DCGs. The design process involves the application of cognitive toys and isomorphism. Using this process, designers will use a cognitive toy to be inspired to develop DCGs, and isomorphism is intended to help them produce a diverse set of DCGs based on the same cognitive toy. The resulting DCGs will have deep similarity with the original cognitive toy but are unique in terms of their surface features.

Keywords

Cognitive Games Digital Games Game Design Isomorphism General Systems Theory

1. Introduction

Gameplaying has been, and remains, a popular leisure activity. Recent popularity and ubiquity of games is partially due to the proliferation and adoption of digital games (Siwek, 2010). According to surveys, 97% of American teenagers and over 50% of American adults played digital games in 2008 (Lenhart, Jones, & Macgill, 2008; Lenhart, Kahne, et al., 2008). The increased popularity of gameplaying is precipitating the use of digital games for purposes other than pure entertainment (e.g., see Burke et al., 2009; Gordon, Lent, & Velsen, 2004; Sánchez, Gutiérrez, Cabrera, & Zea, 2009). Digital game design techniques, principles, and mechanics are even recently being used in nontraditional applications, such as training, marketing, and health and wellness initiatives (Anderson & Rainie, 2012). Digital games have increasingly been used to support reasoning, problem solving, planning, learning, and other such cognitive activities (Barab, Thomas, Dodge, Carteaux, & Tuzun, 2005; Gros, 2007; Haworth, Tagh Bostani, & Sedig, 2010; Ke & Grabowski, 2007; Linehan et al., 2011). A rapidly growing body of research suggests that playing digital games can enhance the performance of cognitive activities (Blumberg & Ismailer, 2009). The support and development of such activities, however, may be incidental and not a primary function of many games. This article is concerned with a particular category of digital games—digital cognitive games (DCGs)—whose primary purpose is to mediate (i.e., support, develop, and enhance) such aforementioned cognitive activities.

Digital games are not that effective in nonentertainment contexts, unless their design is informed by well-researched and systematic frameworks. Despite their growing popularity and potential for supporting cognitive activities, the design of DCGs is neither simple nor often informed by research (Haworth & Sedig, 2011; Rambusch, 2010; Turner & Browning, 2010). Indeed, there are no systematic design processes for the creation and analysis of such games. Game design has been largely based on ideas and experiences from the gaming industry (Barr, Noble, & Biddle, 2007). Although such experience is valuable for game designers, whether academic or otherwise, it is primarily anecdotal and intuitive, composed of general principles and best practices rather than structured and systematic design processes (e.g., see Adams, 2010; McGuire & Jenkins, 2009). This is also true when it comes to the design of DCGs. For instance, even some researchers who discuss how to design educational games (e.g., DeVane, Durga, & Squire, 2010; Dipietro, Ferdig, Boyer, & Black, 2007; Dondlinger, 2007) fail to provide or follow a systematic design process. We believe and demonstrate in this article that it is possible to have a structured and systematic approach to the design of games that does not restrict or hamper the creativity inherent in the design of digital games. In this article, we will present a preliminary process for the design of DCGs that is structured and systematic, yet allows for creativity on the part of designers. At the heart of the process is the application of two fundamental ideas: cognitive toys and isomorphism. As far as the authors are aware, these two ideas have never been combined to inform the design of DCGs.

Cognitive toys are simple, nondigital activities that people use for mental stimulation and amusement. These toys can act as sources of inspiration for digital games, either as the initial seed from which a more complete game arises or as one component of a game. How one might take inspiration from a cognitive toy and use it to create a digital game relies on another concept, that of isomorphism. Isomorphism refers to similarity between systems in terms of structure, form, function, and other deep characteristics (Gunaratne, 2008; Whitchurch & Constantine, 1993). In viewing cognitive toys and digital games as systems, designers can use features and components of a toy to inspire similar characteristics in a game. Therefore, the design process presented in this article is a formalized way in which one can systematically and creatively use cognitive toys, as sources of inspiration, to design DCGs.

The remainder of this article is divided into the following sections. In Section 2, a more detailed discussion of some foundational concepts is provided. In Section 3, the design process itself is discussed. In Section 4, an example of using this process to design two games is given. Finally, in Section 5, this article is summarized and future works are discussed.

2. Background

This section consists of four subsections, which will provide the conceptual and terminological background for the development of the rest of the ideas in this article. First, we will define and exemplify cognitive toys and discuss why they can be sources of inspiration for design of DCGs. Second, we will introduce general systems theory (GST) as a framework within which designers can analyze cognitive toys and design DCGs. Third, we will define isomorphism from the perspective of GST and illustrate its application in the design of DCGs. Finally, we will discuss game rules, their usefulness, and their complementary role, along with GST and isomorphism, in the creative design of DCGs.

2.1. Cognitive Toys

Cognitive toys are known by various other names, such as brain teasers, brain games, brainmatics, mind-benders, thinker toys, and puzzles (Kroehnert, 1991; Michalko, 2006; Moscovich, 2000, 2005, 2006, 2009). As such, the term cognitive toy can become problematic if interpreted too strictly. Given that a definite distinction between toys, puzzles, and games can lead to problematic definitions (Koster, 2004; Salen & Zimmerman, 2004), we define the term cognitive toy somewhat loosely. As such, a cognitive toy can be defined as any simple, small, nondigital, amusing, play activity that can be used to engage and stimulate the mind. Putting it slightly differently, any nondigital activity that is simple to perform, is intended for entertainment, and requires cognitive effort to perform (Bottino, Ferlino, Ott, & Tavella, 2007; Chu & MacGregor, 2011), regardless of whether or not the activity has a definite solution or a practical purpose, can be considered a cognitive toy for the purposes of the design process discussed in this article. A number of mathematical problems that have been developed for entertainment (Danesi, 2002), given how ancient some of them are (Connaughton, Tache, & Burley, 2010; Gillings, 1962; Olivastro, 1993), could also be considered cognitive toys. Additionally, a nondigital game that has very simple rules, and requires cognitive effort to play, could also be considered a cognitive toy. In each case, giving an activity the label of cognitive toy does not require one to remove a previous label. For instance, a nondigital game can be considered a cognitive toy but can also be thought of as and called a game. Two examples of cognitive toys are provided in Figures 1 and 2.

Figure 1.

A sample Magic Square cognitive toy

Figure 2.

A sample Tangram cognitive toy that is partially complete

Cognitive toys can be used as sources of inspiration when designing DCGs. There are at least four reasons for this. (a) Engaging with cognitive toys requires some degree of cognitive effortful thinking; thus, they can inspire the design of DCGs irrespective of their ultimate purpose. As such, DCGs that are intended to entertain and facilitate and promote cognitive activities skills, such as problem solving and reflective reasoning, could all be based on cognitive toys. (b) People enjoy playing with cognitive toys, as the popularity and proliferation of toys such as Sudoku and other puzzles can attest (Crute & Myers, 2007; Huang, Cheng, & Chan, 2007; Smith, 2005); this is not just a recent phenomenon but a historical pattern (Danesi, 2002). Designers can, therefore, use cognitive toys to create games, knowing that the source of their design is popularly considered to be fun. (c) Thousands of cognitive toys have been developed over the years and new ones continue to be developed (Connaughton et al., 2010; Danesi, 2002; Gillings, 1962; Olivastro, 1993). As such, the number and variety of cognitive toys from which designers can choose is large and continues to grow. (d) Cognitive toys can be useful for finding patterns within or similarity between DCGs.

2.2. General Systems Theory

General systems theory is the science of systems and provides a theoretical framework for the study of structure, properties, and characteristics of systems (Hofkirchner & Schafranek, 2011). By a system is meant any whole that is formed from interacting, interrelated, and interdependent entities (Skyttner, 2005). In GST, systems that have physical existence—such as a tree, the circulatory system, or an ecosystem—are studied with the intent of identifying general or universal characteristics that can then be applied to the study of any system (Drack & Schwarz, 2010). Thus, GST provides a conceptual framework that assists with the structuring and organizing of thoughts and actions when analyzing or designing a system.

A system can be analyzed by identifying and describing its components and characteristics. All systems can be described through four main things: entities that comprise them, properties of those entities, relationships between entities and properties, and environment in which entities exist (Littlejohn, 2003; Skyttner, 2005). Each entity in a system can be simple or composite. Simple entities have no components or subsystems. Composite entities are composed of other entities and thus are, in fact, systems themselves. As such, a system can simultaneously have many subsystems as well as be a subsystem of another system, that is, its supersystem.

A digital game can be analyzed as a system (Geurts, de Caluwé, & Stoppelenburg, 2000; Krek, 2008; Salen & Zimmerman, 2004; Sweetser, 2008). At a macroscopic level, a game can be decomposed into a series of embedded subsystems. At the highest level, one subsystem of a digital game is its user interface (UI; see Figure 3). The UI is a composite entity and thus a system, with two main subsystems: a representational subsystem and an operational subsystem. The representational subsystem is composed of all the information representations that are visible at the UI, each of which encodes some information about the game and may itself be a composition of other representations. The operational subsystem is composed of all the interactions that the player can perform, that is, all of the actions the player can perform on various representations, and the reaction, or change in the representational subsystem that results.

Figure 3.

A digital game as a hierarchy of systems, with the user interface and its subsystems as an example

A digital game can also be analyzed at a microscopic level by choosing one specific subsystem and describing its components in detail. As an example, we will analyze both the representational and operational subsystems of the game Tetris.¹ First, we will identify the entities of the representational subsystem. Figure 4 provides a screenshot of Tetris, along with a decomposition of its representational subsystem. The main representation is itself a composition of several label representations and container representations. The containers are also composite, in that within them are embedded other representations of individual Tetris blocks (called Tetriminos). All of these representations are the entities of the representational subsystem. Once identified, we can determine properties of each entity. For instance, some of the properties of Tetriminos would include their shape, size, and orientation. We can also determine relationships these entities may have, such as the spatial arrangement of Tetriminos in the “playing area” container. Second, we will identify the entities of the operational subsystem of Tetris. This would include the two interactions the player can perform: rotating a Tetrimino, and arranging its spatial position in the “playing area.”

Figure 4.

A screenshot from the game Tetris and the decomposition of its representational subsystem

2.3. Isomorphism

Isomorphism refers to similarity between two systems at a deep level (Whitchurch & Constantine, 1993). This similarity can be conceptualized in terms of correspondence between two systems: in terms of their forms, shapes, structures, operations, internal relations, representations, and/or other characteristics. In GST, finding isomorphism between two systems helps with the analysis and understanding of an unknown or lesser known system’s entities and its behaviors with respect to a well-known system. Thus, comparing two systems at an abstract level allows us to see if they are isomorphic. For instance, at a certain level the Magic Square cognitive toy can be isomorphic to the Number Scrabble game, and both are isomorphic to the Tic-Tac-Toe game (see Dou et al., 2010). Similarity can occur at multiple levels of abstraction, but the isomorphism with which we are concerned in this article occurs only at higher levels of abstraction. Once entities of a system are considered in terms of abstract patterns, isomorphism between entities and between systems becomes apparent.

To discover the abstract patterns of any game, both the representational and the operational subsystems of the game can be analyzed using GST as a conceptual framework. For instance, consider the entities of the representational subsystem of Tetris, as shown in Figure 5, and discussed in the previous section. These entities can be examined at higher or lower levels of abstraction. If we focus on each entity in terms of all its properties in a specific manner, we achieve little abstraction. As we group and classify entities, a higher degree of abstraction is achieved. For example, using the term Tetrimino or Tetris block is a generalization and is more abstract than referring to a specific Tetrimino in the UI. A similar generalization can be made for the various labels on the interface. At higher levels of abstraction, both the labels and the blocks are simply representations.

Figure 5.

Degrees of abstraction when examining entities of the representational subsystem of Tetris

Once similar entities are grouped together under a specific term, this abstraction allows us to discover isomorphism. For instance, when exploring Tetris blocks, we find that they can be regarded as isomorphic with regard to function and operation, as they are all grouped under the abstract representational label of “Tetrimino.” As such, the more that various, disparate entities in cognitive toys and DCGs are grouped together, the higher the degree of abstraction that is used to examine those entities. Just as we can abstract entities within a system to discover isomorphic entities, we can do the same across systems.

Taking the above into consideration, isomorphism then refers to similarity correspondence between structural (representations and their organization) and/or operational patterns of a toy and those of a digital game. Therefore, DCGs that are based on the same cognitive toy can also be isomorphic, either structurally or operationally or both.

2.4. Game Rules

Although a digital game can be described in terms of a hierarchy of systems, it can be difficult to determine the functionality of a game based solely on such a description. This is especially true when the functionality in question is exactly how one plays the game and what is required to either win or successfully complete the game. Thus, a systems-based description of a game can be complemented with a rules-based description. The rules of a game define its functionality in an explicit and unambiguous manner.

Part of the functionality includes the representational and operational subsystems, specifically: how current and future game states are represented, how possible actions are represented, and the possible interactions available to the player. Much of this information is already contained in the systems-based description but worded differently. However, the rules also define underlying details of the flow of the game, such as the starting and ending conditions of the game, winning and losing conditions for the player, as well as game pieces and their starting state. This information is highly relevant for understanding the functionality of a game but is often not well expressed in a systems-based description. Clear and unambiguous rules are useful to designers: for them to understand how the game should operate and to avoid design-related problems early in development. Although the rules of a game should be unambiguous, they can be written with different degrees of abstraction. For the purposes of this article, two levels of rules will be discussed: abstract and concrete (see Salen & Zimmerman, 2004).

Abstract rules define the functionality of a game at a high level, without too much specificity and detail. These rules define the fundamental functionality of a game but lack details regarding its visible or physical implementation. Thus, from reading a set of abstract rules, one understands the various pieces of a game, the conditions for winning, and what actions the player can perform, but there is no guidance for what the pieces would actually look like or specifically how an action is performed. For example, an abstract rule could be the following: “Players take turn arranging objects in an n-by-n grid.” This rule is sufficient for understanding the functionality of the game but does not provide the details necessary to actually play it. Information regarding the size or shape of the grid, what objects are arranged, and how these objects are arranged is necessary for a physical or digital implementation of the game but not necessary for analysis. Since abstract rules are written at a high degree of abstraction, they are useful for determining isomorphisms between games.

Concrete rules define the functionality of a game at a moderate to low degree of abstraction. All details for the functioning and implementation of a game are contained within concrete rules, such that anyone reading the rules could both analyze the game and play an implementation of it. For example, a concrete rule corresponding to the above abstract rule could be the following: “In a 5-by-5 grid of equal-sized cells, players alternate moving colored entities from one cell to an adjacent cell.” This rule is still somewhat abstract, in that it neither defines exact physical game piece nor specifies lines of software code, but it is sufficiently concrete that a physical or digital implementation could be made from it.

3. Process for Design of Digital Cognitive Games

This section discusses a process for the design of DCGs that uses cognitive toys as a means of initial inspiration. Thousands of cognitive toys have been developed over the years, and some are quite ancient in their conception (Connaughton et al., 2010; Danesi, 2002; Gillings, 1962; Olivastro, 1993). As such, there is a wide variety of cognitive toys available for designers. A carefully chosen cognitive toy can provide designers with a game idea that is both fun and mentally stimulating for players.

The design process we are presenting in this article is separated into five stages: (a) selecting a cognitive toy, (b) identifying and generalizing the patterns of the cognitive toy, (c) creating isomorphic abstract games from the patterns in the second stage, (d) creating concrete games from the abstract patterns in the third stage, and (e) implementing one or more of the concrete games from the fourth stage. Different games can result from this process based on designers’ creativity and ideas generated at each stage, as outlined in Figure 6. The design process, outlined here, is systematic and structured as it relies on GST as its conceptual framework. It is also creative due to the freedom that designers are afforded at each stage of the process to choose the way in which they abstract details from a cognitive toy and instantiate, or make concrete, those same details. There are many ways in which designers can instantiate an abstract systems-based description or a set of abstract rules, thus resulting in many possible implementations of the resulting game. Any resulting games will be isomorphic to the initially chosen cognitive toy but may be very different from the toy at the surface or detailed level. This proposed design process has the potential to inspire designers to creatively come up with many isomorphic games out of a selected cognitive toy.

Figure 6.

Possibilities for the variation in the resulting games, at each stage of the design process

Each of the stages of the design process is discussed below, and a detailed example of this process is provided in Section 4.

3.1. Stage 1: Selecting a Cognitive Toy

In the first stage of the process, designers search through a variety of cognitive toys and choose one. The chosen toy can then be analyzed as a system, and a systems-based description is created. In other words, the entities of the toy, and their properties and relationships, are described, along with any hierarchical nesting of subsystems. Designers focus on identifying the entities of the toy and tasks that are equivalent to the representational and operational subsystems of a game.

To develop creative ideas for the representational subsystem of DCGs, designers must first identify the toy’s entities and its container(s), if any. Entities inspire designers to determine the objective that the player must accomplish, the obstacles that must be overcome, and the tools available to the player. The containers inspire the design of the space which the resulting game may have and the boundaries of this space. For example, consider the Tangram cognitive toy, shown in Figure 2 above. In this example, the entities would be the various shaped polygons, while the container would be a shaped area in which the entities are to be placed.

To develop creative ideas for the operational subsystem of DCGs, designers must identify what the player does with the toy as a whole and with its entities. This includes the actions available to the player and the reactions or results that occur on performing each action. In other words, designers must determine how the player is able to successfully accomplish the toy’s objective, the methods of interaction with the toy, and any physical artifacts with which the player must interact. The physical artifacts correspond to the entities in the representational subsystem. Designers should take note of actions necessary to accomplish the objective as well as actions that a player can take with the entities that are possible but not explicit. For example, in the Tangram toy, the player is able to pick up an entity, rotate it, and place it somewhere within the container. However, the player is also able to rotate the entity again or take it out of the container completely. These are actions that are possible with physical artifacts; hence, their allowance in a digital game may be necessary or at least important to note.

Although we have described this stage of the design process as though one toy is chosen to generate design ideas, designers can choose multiple toys and combine the resulting ideas.

3.2. Stage 2: Generalizing Cognitive Toy’s Patterns

In the second stage of the design process, designers generalize the description(s) created in the previous stage so as to develop a set of generalized patterns of the cognitive toy. Many of these patterns will be at a micro level, generalizing features specific to parts of the toy’s system. For example, in the Magic Square cognitive toy, a micro-level pattern is that the entities each have a property which can be compared and combined. This pattern could be instantiated in different ways but is specifically instantiated in the Magic Square as “a numeric value.” Other patterns will be at a macro level, generalizing features applicable to the whole of the toy’s system. For example, in the Tangram cognitive toy, a macro-level pattern is that the task is to construct an object with a specific form. Table 1 shows a possible generalization of the patterns of the Magic Square cognitive toy.

Table 1.

Possible Generalization of Magic Square’s Patterns

The toy has the following generalized patterns

• a set of unique objects

• a grid container, which is an n-dimensional space segmented into equal-sized cells

• individual objects can be placed in the cells of the grid container

• each object has an attribute that identifies it (we can generalize the above to state that the object has several attributes)

• objects can be arranged on the grid cells

• objects’ attributes can be connected (the connecting action modulates the arranging action)

It is important to note that features identified in the previous stage may already be described in abstract, general terms. For example, the container of the Magic Square cognitive toy could be identified as a 4-by-4 grid or a two-dimensional (2D), cell-based container. Designers do not need to wait until this stage to identify patterns, but the two stages have been separated to ensure that important details are not missed and that a high level of abstraction is used in the description of the toy for the next stage.

3.3. Stage 3: Creating Isomorphic Abstract Games

In the third stage of the process, designers formalize the description from the previous stage into a set of isomorphic abstract games. An abstract game is a game in which all the rules are abstract. To formalize the representational patterns, designers must describe the entities of the game, the attributes of those entities, and the relationships among the entities. Different types of entities are described, but all descriptions should remain abstract. To formalize the operational patterns, designers must explain what actions the player performs, what entities of the game the player acts on, and why those actions are performed. These are the operational patterns described in the previous stage, but these patterns can now be modulated by environmental properties in addition to other patterns.

To create each abstract game, designers expand and elaborate on the patterns from the previous stage but keep the results abstract. The patterns previously identified should be used for inspiration, not just copied verbatim.

Table 2 shows four possible isomorphic abstract games derived from the Magic Square cognitive toy.

Table 2.

Three Possible Isomorphic Abstract Games Derived From the Magic Square Cognitive Toy

Game possibility	Abstract rules or descriptions
Game with objects	• The game is split into levels
	• Each level contains an n-by-n grid
	○ The size of the grid is set at the beginning of the game but it may change between levels
	○ Each grid cell can contain a single object
	○ Each grid cell may start empty or with an object in it
	• The player chooses a unique object from a set of objects and arranges that object on the grid
	• When the objects in each row are combined, the combination must satisfy some criteria
	○ The same occurs for each column, and each main diagonal
	○ If all combinations satisfy the same criteria, the level is complete
	• Each time a level is completed, the size of the grid increases
	• When the player completes all the levels, the game ends and the player wins
Game with objects, plus time limit	• The game is split into levels
	• Each level contains an n-by-n grid
	○ The size of the grid is set at the beginning of the game but it may change between levels
	○ Each grid cell can contain a single object
	○ Each grid cell may start empty or with an object in it
	• The player chooses a unique object from a set of objects and arranges that object on the grid
	• When the objects in each row are combined, the combination must satisfy some criteria
	○ The same occurs for each column and each main diagonal
	○ If all combinations satisfy the same criteria, the level is complete
	• Each time a level is completed, the size of the grid increases
	• Each level contains a time limit, with the limit dependent on the size of the grid
	○ The timer is set to its maximum value at the start of the level and counts down to a specific minimum value
	○ When the timer reaches the minimum value, the game ends and the player loses
	• When the player completes all the levels, the game ends and the player wins
Game with progressive objects, plus time and score	• The game is split into levels
	• The player starts the game with a specific score
	• Each level contains an n-by-n grid
	○ The size of the grid is set at the beginning of the game but it may change between levels
	○ Each grid cell can contain a single object
	○ Each grid cell may start empty or with an object in it
	• The player chooses a unique object from a set of objects and arranges that object on the grid
	• When the objects in each row are combined, the combination must satisfy some criteria
	○ The same occurs for each column and each main diagonal
	○ If all combinations satisfy the same criteria, the level is complete
	• Each time a level is completed
	○ The player’s score is increased by a value specific to the difficulty of the level completed and the amount of time remaining
	○ The size of the grid increases by a set amount, up to a maximum value
	○ When the size of the grid reaches its maximum value, the grid becomes an n-by-n-by-n grid of a smaller size
	• Each level contains a time limit, with the limit dependent on the size of the grid
	○ The timer is set to its maximum value at the start of the level and counts down to a specific minimum value
	○ When the timer reaches the minimum value, the game ends and the player loses
	• When the player completes all the levels, the game ends and the player wins

3.4. Stage 4: Creating Concrete Games

In the fourth stage of the design process, designers create a set of concrete games. A concrete game is one in which designers instantiate the representational and operational patterns or rules of one of the abstract games from the previous stage into a set of concrete rules. As suggested above, the concrete rules created in this stage should be sufficiently detailed such that a digital game can easily be implemented from them. In other words, it should be clear from the set of concrete rules exactly how the game is played; however, the aesthetic details of the game need not to be clear, as they can be implemented in different ways.

In this stage, a possible UI implementation based on these rules should be clear, and the look and feel of UI entities can be considered but need not be fully detailed. Similarly, the theme, narrative, setting, and images for the concrete game can be considered but do not have to be completely established. In the abstract game, a theme, narrative, or setting is only included if it is relevant to the functioning of the game.

The concrete rules developed in this stage can be written such that they do not include technology- and platform-specific details. For example, a digital game designed for a personal computer may include controls that utilize a mouse, but a mouse does not exist in a handheld game console. The rules for the concrete game could be written for any kind of pointing device, such that a mouse would apply but so would a touch screen, leaving the rules platform independent.

Table 3 shows three possible concrete games derived from the second abstract game in Table 2, namely, game with objects, plus time limit.

Table 3.

Possible Concrete Games Based on the “Game With Objects, Plus Time Limit” Abstract Game

Game possibility	Concrete rules or descriptions
Color crystals	• The game is split into levels
	• Each level contains a grid with square-shaped cells
	○ The grid starts at a size of 4-by-4
	○ Every fifth level, the grid increases in size by 1, up to a maximum size of 10-by-10
	○ Each grid cell can contain 1 of a set of 10 possible colored crystals
	○ 10% of the grid cells, rounded up, will start with a crystal
	• In each level, with a grid size of n, the player is given exactly n crystals of n different colors, that is, with a grid size of 4 the player is given 16 crystals: 4 crystals of 4 colors each
	○ Some of those crystals may already be placed on the grid
	○ The player is randomly shown one of those crystals beside the grid
	○ The player must select which cell of the grid to place that crystal in
	○ When the crystal is placed, the next crystal is shown
	○ The next crystal shown may be of the same color
	• When each grid cell is filled with a color
	○ If each row, column, and the two main diagonals of the grid are filled with one of each color then the player successfully completes the level
	• If a row, column, or one of the main diagonals contains 2 of the same color, then the game ends and the player loses, regardless of how many cells remain empty
	• Each level contains a time limit that counts down by 1 every second
	○ The timer is set to its maximum value at the start of the level, initially being 2 minutes
	○ The timer’s maximum value is increased by 2 minutes whenever the grid increases in size
	○ When the timer reaches 0, the game ends and the player loses
	• When the player completes Level 35, the game ends and the player wins
Number swapper	• The game is split into levels
	• Each level contains a grid with square-shaped cells
	○ The grid starts at a size of 5-by-5
	○ Every third level, the grid increases in size by 1, up to a maximum size of 20-by-20
	○ Each grid cell can contain one box with a number between 1 and 400
	○ Each grid cell is filled with a numbered box at the start of a level
	• Each level will have a numeric value, specifically chosen for that level
	○ The available numbered boxes must provide a correct solution
	• The player can select any box on the grid and swap its position on the grid with any adjacent box
	• During the level, if the sum of all the numbers in a row, column, or one of the main diagonals is equal to the numeric value chosen for the current level, then that row, column, or diagonal is lit up
	○ When all rows, columns, and the two main diagonals are lit up, the player successfully completes the level
	• Each level contains a time limit that counts down by 1 every second
	○ The timer is set to its maximum value at the start of the level, initially being 5 minutes
	○ The timer’s maximum value is increased by 3 minutes whenever the grid increases in size
	○ When the timer reaches 0, the game ends and the player loses
	• When the player completes level 50, the game ends and the player wins
Egg pusher	• The game is split into levels
	• Each level contains a grid with square-shaped cells
	○ The grid starts at a size of 5-by-5
	○ Every 10th level, the grid increases in size by 2, up to a maximum size of 11-by-11
	○ Each grid cell can contain one egg or barrel with 1 out of 11 possible colors
	• In each level of the game
	○ The top left grid cell contains a player-controlled character
	○ 5 of the grid cells contain an egg
	○ The remaining grid cells are filled with a barrel
	○ In each level after the first, one more egg is used instead of a barrel
	• Each level contains a time limit that counts every second
	○ For every 45 seconds that pass, one of the eggs on the grid will crack
	○ An egg can crack three times before no further cracks develop
	○ When all the eggs on the grid are cracked three times, the next time a crack would develop all the eggs break, the game ends, and the player loses
	• The player directs his or her character in any of the four cardinal directions
	○ When the player’s character moves, it pushes any eggs or barrels in front of it in the direction of the movement
	○ An egg or barrel pushed off the edge of the grid will wrap around to the other side of the grid in the same row or column
	○ If the player’s character is adjacent to an egg with three cracks, and pushes that egg, then the egg breaks, the game ends, and the player loses
	• The player can change the color of his or her character to any of the colors available for that level
	• During the level, if any row, column, or one of the main diagonals contains one barrel or egg of each color, then that row, column, or diagonal is lit up
	○ When all rows, columns, and the two main diagonals are lit up, the player successfully completes the level
	○ The color of the player’s character is included as well
	• When the player completes Level 50, the game ends and the player wins

3.5. Stage 5: Implementing Games

In the fifth, and final, stage of the design process, designers instantiate the concrete rules into a fully implemented digital game. This includes the development of images, audio, narrative details, layouts of each level or area of the game, and software code. The details of this stage are beyond the scope of this article, as it is closer to that involved in the development of any software project based on a specific design.

4. An Integrated Example of the Design Process

In this section, we present an integrated example of how one might apply the design process to create two isomorphic DCGs.² The two games seem very different on the surface, but at an abstract level they are isomorphic. The example games are intentionally small in scope, as there is insufficient space to explain the rules of games with larger scopes.

The first three stages of the process are included below. Following that, the remaining two stages are included in sections specific to the game that is under consideration.

4.1. Choosing a Cognitive Toy

A popular cognitive toy is one shown in Figure 7 (Moscovich, 2000). This toy involves nine octagons. Each octagon has a fixed number of colored slices. The octagons can be rotated but not moved. The objective of this toy is to rotate the octagons such that each pair of adjacent octagon slices has the same color.

Figure 7.

A cognitive toy

Using GST, we can analyze this toy as a system and identify its components (see Table 4).

Table 4.

Components of the octagon toy when analyzed as a system

Entity	Properties	Relationships
Container	3 cells × 3 cells in size	N/A
Octagon	8 colored slices	Adjacent to other octagons
		Adjacent slice colors match

4.2. Generalizing the Cognitive Toy’s Patterns

The components of the toy, as described above, the interaction available to the player, and the overall goal of the toy can be abstracted to a high or very general level. The patterns are then organized in terms of representational and operational features.

The representational features include the following:

Multifaceted entities (derived from multicolored polygons)

○ Multiple values of an attribute are encoded in the entity (derived from different colors)

○ Attribute values of two adjacent entities can match, creating a “matched” relationship between them (derived from same color)

An n-by-n, cell-based container, into which the composite entities are arranged (derived from 3-by-3 grid)

The operational features include the following:

The player can transform an entity (derived from rotating the polygons).

○ This changes which attribute values are compared between entities, and thus creates or destroys a “matched” relationship.

○ When all adjacent entities have a “matched” relationship, a correct solution is obtained.

4.3. Creating an Abstract Game

Once general patterns have been identified, they can be used to create rules for an abstract game. One possible set of abstract rules is the following:

The game is divided into multiple levels.

○ Each level is composed of several multifaceted objects.

○ These objects are placed into a 2D, cell-based container.

○ Relationships are formed between nearby objects when there is a specific correspondence between their attributes.

○ The goal of each level is to create a specified relationship between nearby objects.

The player can transform each object, one at a time, to change its relationships with nearby objects.

The rules in the abstract game use the generalized patterns of the toy, “multifaceted entity,” and the necessary relationships. The division of the game into levels is a new rule that does not correspond to any generalized pattern above. This rule is just one example of how designers do not have to be restricted to the general patterns of the toy and can be creative in how they design the game.

4.4. Digital Game 1: Control the Flow

In this subsection, the last two steps in the design process will be discussed for a sample digital game, titled Control the Flow.

4.4.1. Concrete Game

Using the abstract rules in Section 4.3, one set of concrete rules can be the following:

The game is divided into multiple levels.

○ In each level there is a 2D grid.

○ Four kinds of objects are arranged into this grid: a gate, a lever, grass, a water channel.

○ Water can flow through water channel objects into adjacent water channels.

○ Gates are opened, to allow water to flow through a channel, or closed, to prevent such flow.

○ A lever will open or close gates of the same color as the lever.

○ An avatar is placed into grid.

The player navigates an avatar through the level.

○ An avatar can move among grid cells that contain closed gates or grass.

○ When an avatar is adjacent to a lever, the lever can be manipulated to open or close gates.

The objective of each level is to open gates such that water flows from one edge of the grid to the opposite edge.

Since the avatar, representing the player, can move across closed gates, pulling various levers will create paths to other levers. As a result, the player needs to determine the state in which each lever should be in order to complete each level.

The set of abstract rules above have been instantiated into this set of concrete rules in the following manner. The 2D cell–based container is instantiated as a 2D grid. The gates and levers are instantiations of multifaceted objects. The facets of a gate object form its state: whether it is opened or closed. Similarly, the facets of a lever object form its state. Gates and levers have a relationship whereby the state of a lever affects the state of various gates. Gates also have a relationship with water channel objects, in that water can flow through an open gate. In the abstract rules, the objective is to create a specified relationship. Similarly, in these concrete rules, the objective is to create the right relationships between levers and gates, so that the appropriate relationships can be formed between water channel objects.

4.4.2. Implemented Game

With the concrete rules completed, the digital game Control the Flow can be implemented. One way in which the concrete rules can be instantiated into a digital form is shown in Figure 8. The grid is not explicit,but is instead implicit in the arrangement of objects. All the other objects have an explicit form, as can be seen in Figure 8.

Figure 8.

A screenshot from the digital game Control the Flow

An example of playing the game, based on Figure 8, is as follows. Water needs to flow through the green gates or the purple gates in order to reach the bottom of the level. The player cannot reach the switch to open the green gates, unless she or he first closes the red gates. Thus, the player must move her or his avatar toward the red switch, close the red gates, move toward the green switch on the right, and then open the green gates. This will complete the section of the level currently shown in the screenshot, though more may need to be done to successfully complete the level.

4.5. Digital Game 2: Space Industries

In this subsection, the last two steps in the design process will be discussed for a second sample digital game, titled Space Industries.

4.5.1. Concrete Game

Using the abstract rules in Section 4.3, one set of concrete rules can be created:

The game is divided into multiple levels.

○ In each level there is a 2D grid.

○ In some cells are arranged space colony objects or trade route objects.

Trade route objects between two space colonies create a trading relationship between them.

Space colony objects also have industries that provide goods.

○ Each industry demands a specific good to function and produces a specific good.

○ Colonies that have a trading relationship share produced goods.

○ A colony is satisfied if each demand is met.

The player can change some industries on some colonies.

○ In doing so, the player can change which goods are produced on a colony and thus whether trading colonies have their demands met.

The objective of each level is to ensure that each colony is satisfied.

The set of abstract rules in Section 4.3 have been instantiated into this set of concrete rules in the following manner. The 2D cell–based container is instantiated as a 2D grid. The space colony objects are instantiations of multifaceted objects. The facets of a space colony are its industries, the goods the colony produces, and the goods the colony demands. Whether a colony is satisfied is dependent on the state of other colonies with which it has a trading relationship. This is an instantiation of the “specified relationship” in the abstract rules.

4.5.2. Implemented Game

With the concrete rules completed, the digital game Space Industries can be implemented. One way in which the concrete rules can be instantiated into a digital game is shown in Figure 9. One space colony is shown, along with its industries. The goods demanded are shown as the second list, hidden behind the industry list. The goods produced are shown as the third list, hidden at the bottom.

Figure 9.

A colony in Space Industries that trades with two nearby colonies

An example of playing the game, based on the screenshot in Figure 9, is as follows. The colony in the figure demands food, water, common ores, common metals, and rare metals to be satisfied. The colony produces common ores, common metals, tools, and electronics. However, the demand for water and rare metals has not been fulfilled. In addition, the colony is producing two goods that are not fulfilling the demands of any colonies with which it has a trade route. One of these goods is electronics. Although the player cannot add an industry to this colony that would create rare metals, it could change the electronics industry into a resort. This would remove the demand for rare metals, create a demand for tourists, and stop the colony from producing electronics, which are not fulfilling another colony’s demands anyway. If a nearby colony produces tourists but not rare metals, this would create a relationship that fulfills more demands of the colony. As such, changing the electronics industry to a resort would move the player closer toward satisfying this colony, and thus completing the level successfully.

5. Summary and Future Work

This article discusses a preliminary process for designing DCGs, using the concepts of isomorphism and cognitive toys. This process facilitates a structured and systematic approach to design, yet encourages the creativity of designers. Designers first choose a cognitive toy and analyze it from the perspective of GST. Then, they create a description of the toy deriving its general patterns, use those patterns to create a set of isomorphic abstract games, choose one of the abstract games and instantiate it into a set of concrete games, and finally choose one of the concrete games and implement it on a digital platform. At each stage of the process, designers are free to use an extensive amount of creativity. This results in a wide variety of possible games inspired by a single chosen cognitive toy. The inspired games can look very different with regard to their surface features but can be isomorphic at the abstract level of their description, that is, deeper levels of structure and operation.

To enhance this design process, a classification of cognitive toys, through systematic analysis, is still required. Such classification would greatly assist designers in the first two stages of the process. Additionally, further exploration of the various components of a DCG would aid designers at all stages of the process. Most important, further research is required to investigate the impact of different design choices made at different stages of the process on the final DCG. A design decision made on one component of a DCG can affect the resulting experience of playing the game (Hunicke, LeBlanc, & Zubek, 2004). To ensure that the game provides the intended experience, designers must be able to understand the implications of their design decisions. This requires empirical studies to evaluate the effect of different design decisions on the quality of the game.

While the design process presented in this article is simple to follow, it can potentially inspire designers to use simple cognitive toys that people enjoy in order to come up with countless novel and engaging DCGs. Finally, it is important to note that the process is flexible enough to allow designers to blend the features of different cognitive toys into created DCGs.

Footnotes

Declaration of Conflicting Interests

The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The authors received following financial support for the research, authorship, and/or publication of this article: This research has been supported in part through funding from the Natural Sciences and Engineering Research Council of Canada.

Notes

Bios

Kamran Sedig is an Associate Professor at Western University in Canada. His research is interdisciplinary. In the past 19 years, his overarching research interest has been: how to design interactive, information-based tools and interfaces that fit and support people's cognitive activities. More specific areas of his research are: human-information interaction design; complex cognitive activities; information visualization and visual analytics; digital cognitive games; knowledge and learning technologies; human-centric informatics; information design; and health informatics.

Robert Haworth is a PhD Student in Computer Science at Western University in Canada. His current research focuses on the design of digital cognitive games, both in general and when designed for specific cognitive activities, such as problem solving or learning.

References

Adams

(2010). Fundamentals of game design (2nd ed.). Berkeley, CA: Pearson Education.

Anderson

Rainie

(2012). The future of gamification (Pew Internet & American Life Project Report). Retrieved from http://pewinternet.org/Reports/2012/Future-of-Gamification.aspx

Barab

Thomas

Dodge

Carteaux

Tuzun

(2005). Making learning fun: Quest Atlantis, a game without guns. Educational Technology Research & Development, 53, 86-107.

Barr

Noble

Biddle

(2007). Video game values: Human–computer interaction and games. Interacting With Computers, 19, 180-195.

Blumberg

Ismailer

S. S.

(2009). What do children learn from playing digital games? In Ritterfeld

Cody

M. J.

Vorderer

(Eds.), Serious games: Mechanisms and effects (pp. 131-142). New York, NY: Routledge.

Bottino

R. M.

Ferlino

Ott

Tavella

(2007). Developing strategic and reasoning abilities with computer games at primary school level. Computers & Education, 49, 1272-1286.

Burke

J. W.

McNeill

M. D. J.

Charles

D. K.

Morrow

P. J.

Crosbie

J. H.

McDonough

S. M.

(2009). Serious games for upper limb rehabilitation following stroke. In VS-GAMES ’09: Proceedings of the 2009 conference in Games and Virtual Worlds for Serious Applications (pp. 103-110). Washington, DC: IEEE Computer Society.

Chu

MacGregor

J. N.

(2011). Human performance on insight problem solving: A review. Journal of Problem Solving, 3, 119-150.

Connaughton

S. P.

Tache

Burley

D. V.

(2010). Taupita: A 3000-year-old shell game in the Lapita cultural complex of Tonga. Journal of Social Archaeology, 10, 118-137.

10.

Crute

T. D.

Myers

S. A.

(2007). Sudoku puzzles as chemistry learning tools. Journal of Chemical Education, 84, 612-613.

11.

Danesi

(2002). The puzzle instinct: The meaning of puzzles in human life. Bloomington: Indiana University Press.

12.

DeVane

Durga

Squire

(2010). “Economists who think like ecologists”: Reframing systems thinking in games for learning. E-Learning and Digital Media, 7, 3-20.

13.

Dipietro

Ferdig

R. E.

Boyer

Black

E. W.

(2007). Towards a framework for understanding electronic educational gaming. Journal of Educational Multimedia and Hypermedia, 16, 225-248.

14.

Dondlinger

M. J.

(2007). Educational video game design: A review of the literature. Journal of Applied Educational Technology, 4, 21-31.

15.

Dou

Ziemkiemkiewicz

Harrison

Jeong

Ryan

Ribarsky

Chang

(2010). Comparing different levels of interaction constraints for deriving visual problem isomorphs. In Symposium on visual analytics science and technology (VAST) (pp. 195-202). Piscataway, NJ: Institute of Electrical and Electronics Engineers.

16.

Drack

Schwarz

(2010). Recent developments in general system theory. Systems Research and Behavioral Science, 27, 601-610.

17.

Gardner

(2001). A Gardner’s workout: Training the mind and entertaining the spirit. Natick, MA: A. K. Peters.

18.

Geurts

J. L. A.

de Caluwé

L. I. A.

Stoppelenburg

(2000). Changing organisations with gaming/simulations. The Hague, Netherlands: Elsevier.

19.

Gillings

R. J.

(1962). Problems 1 to 6 of the Rhind Mathematical Papyrus. The Mathematics Teacher, 55, 61-65.

20.

Gordon

Lent

M. V.

Velsen

M. V.

(2004). Branching storylines in virtual reality environments for leadership development. In Hill

Jacobstein

(Eds.), Proceedings of the Sixteenth Innovative Applications of Artificial Intelligence Conference (pp. 844-851). Palo Alto, CA: AAAI Press.

21.

Gros

(2007). Digital games in education: The design of games-based learning environments. Journal of Research on Technology in Education, 40, 23-38.

22.

Gunaratne

S. A.

(2008). Understanding systems theory: Transition from equilibrium to entropy. Asian Journal of Communication, 18, 175-192.

23.

Haworth

Sedig

(2011). The importance of design for educational games. In Méndez-Vilas

(Ed.), Education in a technological world: Communicating current and emerging research and technological efforts (pp. 518-522). Badajoz, Spain: Formatex Research Center.

24.

Haworth

Tagh Bostani

S. S.

Sedig

(2010). Visualizing decision trees in games to support children’s analytic reasoning: Any negative effects on gameplay? International Journal of Computer Games Technology, 2010, 1-11. Retrieved from http://www.hindawi.com/journals/ijcgt/2010/578784/

25.

Hofkirchner

Schafranek

(2011). General system theory. In Hooker

(Ed.), The philosophy of complex systems (pp. 177-194). Amsterdam, Netherlands: Elsevier.

26.

Huang

O. W.

Cheng

H. N.

Chan

(2007). Number jigsaw puzzle: A mathematical puzzle game for facilitating players’ problem-solving strategies. In DIGITEL 07: Proceedings of the First IEEE International Workshop on Digital Game and Intelligent Toy Enhanced Learning (pp. 130-134). Washington, DC: IEEE Computer Society.

27.

Hunicke

LeBlanc

Zubek

(2004). MDA: A formal approach to game design and game research. In Proceedings of the AAAI-04 Workshop on Challenges in Game AI (25-29 July 2004) (pp. 1-5). Palo Alto, CA: AAAI Press.

28.

Grabowski

(2007). Gameplaying for maths learning: Cooperative or not? British Journal of Educational Technology, 38, 249-259.

29.

Koster

(2004). A theory of fun for game design. Phoenix, AZ: Paraglyph Press.

30.

Krek

(2008). Games in urban planning: The power of a playful public participation. In Schenk

(Ed.), Proceedings of 13th international conference on urban planning, mobility nodes as innovation hubs, regional development and information society (pp. 669-683). Retrieved from http://www.hcu-hamburg.de/fileadmin/documents/Professoren_und_Mitarbeiter/Alenka_Poplin/games_in_urban_planning_2008_005_Krek.pdf

31.

Kroehnert

(1991). 100 Training games. New York, NY: McGraw-Hill.

32.

Lenhart

Jones

Macgill

(2008). Adults and video games (Pew Internet & American Life Project Report). Retrieved from http://pewinternet.org/Reports/2008/Adults-and-Video-Games.aspx

33.

Lenhart

Kahne

Middaugh

Macgill

Evans

Vitak

(2008). Teens, video games and civics (Pew Internet & American Life Project Report). Retrieved from http://pewinternet.org/Reports/2008/Teens-Video-Games-and-Civics.aspx

34.

Linehan

Lawson

Doughty

Kirman

Haferkamp

Krämer

N. C.

Schrembi

(2011). Teaching group decision making skills to emergency managers via digital games. In Lugmayr

Franssila

Näränen

Sotamaa

Vanhala

(Eds.), Media in the ubiquitous era: Ambient, social and gaming media (pp. 111-129). New York, NY: IGI Global.

35.

Littlejohn

S. W.

(2003). Theories of human communication (7th ed.). Beijing, China: Tsinghua University Press.

36.

McGuire

Jenkins

O. C.

(2009). Creating games: Mechanics, content, and technology. Natick, MA: A K Peters.

37.

Michalko

(2006). Thinkertoys (2nd ed.). Berkeley, CA: Ten Speed Press.

38.

Moscovich

(2000). Probability games and other activities. New York, NY: Workman.

39.

Moscovich

(2005). Sensational shape problems & other puzzles. New York, NY: Sterling.

40.

Moscovich

(2006). The big book of brain games: 1000 Playthinks of art, mathematics & science. New York, NY: Workman.

41.

Moscovich

(2009). BrainMatics: Logic puzzles. Cologne, Germany: Tandem Verlag.

42.

Olivastro

(1993). Ancient puzzles: Classic brainteasers and other timeless mathematical games of the last 10 centuries. New York, NY: Bantam.

43.

Rambusch

(2010). Mind games extended: Understanding gameplay as situated activity (Unpublished doctoral dissertation). Linköping University, Linköping, Sweden.

44.

Salen

Zimmerman

(2004). Rules of play: Game design fundamentals. Cambridge: MIT Press.

45.

Sánchez

J. L. G.

Gutiérrez

F. L.

Cabrera

Zea

N. P.

(2009). Design of adaptative videogame interfaces: A practical case of use in special education. In Lopez Jaquero

Montero Simarro

Molina Masso

J. P.

Vanderdonckt

(Eds.), Computer-aided design of user interfaces VI (pp. 71-76). London, England: Springer-Verlag.

46.

Siwek

S. E.

(2010). Video games in the 21st century: The 2010 report. Retrieved from http://www.theesa.com/facts/pdfs/VideoGames21stCentury_2010.pdf

47.

Skyttner

(2005). General systems theory: Problems, perspectives, practice. Hackensack, NJ: World Scientific.

48.

Smith

(2005, May 15). So you thought Sudoku came from the Land of the Rising Sun. The Observer. Retrieved from http://www.guardian.co.uk/media/2005/may/15/pressandpublishing.usnews

49.

Sweetser

(2008). Emergence in games. Boston, MA: Charles River Media.

50.

Turner

Browning

(2010, November). Workshop on HCI and game interfaces: A long romance. Paper presented at the OZCHI 2010: Design–Interaction–Participation, Queensland University of Technology, Brisbane, Australia. Retrieved from http://www.ozchi.org/2010/attend/assets/TurnerWorkshop.pdf

51.

Whitchurch

G. G.

Constantine

L. L.

(1993). Systems theory. In Boss

P. G.

Doherty

W. J.

LaRossa

Schumm

W. R.

Steinmetz

S. K.

(Eds.), Sourcebook of family theories and methods: A contextual approach (pp. 325-355). New York, NY: Plenum Press.