The last few years have seen a growing recognition of the educational potential of computer games. While there have been many worthy achievements, the design and deployment of pedagogically sound mathematics games with a wide appeal has proved illusive. There are many potential reasons for this but it is generally agreed that the process of designing and deploying a game for mathematical learning is a difficult task. The Kaleidoscope project Learning patterns for the design and deployment of mathematical games aims to investigate this problem. We work from the premise that designing games for mathematical learning is a difficult task because it requires the assimilation and integration of deep knowledge from diverse domains of expertise including mathematics, games development, software engineering, learning and teaching. We see all these aspects of knowledge as various facets of design knowledge. The mathematical dimension of game design pertains to the question of selecting and connecting mathematical content – a question of designing mathematical structures. The question of pedagogy is a question of designing instructional structures, and so on. While each party may have expertise in several of the associated knowledge domains, no single party has expertise in all of them. The complexity of each of the various bodies of knowledge means that it is often hard to communicate ideas between parties. Each community has developed its own lore and jargon. The result of this fragmentation of knowledge is that most games emerge from a particular, often restricted viewpoint. A game that embodies deep mathematical can be poorly designed in terms of the gaming experience, whereas a sleek and entertaining game may be simplistic in its pedagogical intent.
We argue that design patterns hold a powerful promise for recording, calibrating and collaboratively refining expert knowledge. Patterns are flexible enough to address a very broad spectrum of practices, from in-depth technical development to deployment issues in classrooms. In addition, they are rigid enough to oblige the pattern writer to focus on and concisely capture their own best practice. The design patterns approach (Alexander et al., 1977) was developed as a form of design language within architecture. This was done with the explicit aim of externalizing knowledge to allow accumulation and generalization of solutions and to allow all members of a community or design group to participate in discussion relating to the design. A design pattern "describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" (Alexander et al, 1977, p.x). This original definition positions a pattern as a high-level specification of a method of solving a problem by a design that specifies the context of discussion, the particulars of the problem, and how these can be addressed by the designated design instruments. And in The Timeless Way of Building he elaborates:
Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.
As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves.
As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant.
The pattern is, in short, at the same time a thing which happens in the world, and the rule which tells us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing (Alexander, 1979, p 247).
Design patterns have the explicit aim of externalizing knowledge to allow accumulation and generalization of solutions and to allow all members of a community or design group to participate in discussion relating to the design. Patterns are organized into coherent systems called pattern languages where patterns are related to each other. Although the use of design patterns never achieved a large following among professional architects, the idea has been embraced in several other disciplines, including software engineering (Gamma et al., 1995), hypermedia (German & Cowan, 2000) and interaction design (Erickson, 2000; Borcher, 2001). The approach has also found application in educational domains including e-learning systems (Derntl & Motschnig-Pitrik, 2004) and the design of computer science courses (Bergin, 2000).
The idea of applying the design patterns approach to produce game design patterns was first described by a practitioner within the game industry (Kreimeier, 2002). Although some patterns were presented in this work, a complete collection was first produced (Björk and Holopainen, 2004) by researchers. This collection was created with a different framing that shifted the focus of a pattern from being problem-solving to being feature-descriptive. The change can be described through four observations, two explicitly based upon the use of design pattern in the context of games and two on general observation of design patterns. The first observation is that the typical context of creating games does not start with a real-world problem. This means that game designers do not need to restrict themselves to functional requirements to the same degree as other design fields, but more typically start from wanting to add a feature that is perceived as being advantageous for the design. The second observation was that the effect of introducing, removing or modifying a game feature easily affects many different aspects of the gameplay to the point that it would be difficult to state one specific problem that was addressed by one design solution. The third observation was the design patterns had the potential for support analyzing existing designs, but this potential was difficult to realize as a noticed design feature could not necessarily easily be matched to a pattern described as a problem-solution pair. The fourth observation was that many professional game designers identified patterns with mechanically producing a solution, especially if they were presented as ways of solving specific problems. Based upon these observations game design patterns were defined as “semi-formal inter-dependent descriptions of commonly reoccurring parts of the design of a game that concern gameplay” (Björk and Holopainen, 2004).
The first reference to learning was made by (Alexander et al, 1978) when he described a pattern called “Network of Learning”. The approach in education more generally has manifested itself through three main trends. The first is the growing trend of pedagogical design patterns (Anthony, 1996; Bergin 2000; Eckstein, Bergin & Sharp, 2002). The second is the development of software design patterns for educational technology (Dearden, et al., 2002b; Avgeriou et al, 2004). The third is the search for patterns in related practices, such as evaluation and assessment (Chaquet, El-Kechaï & Barre, 2005) and and analysis of learning and learning systems (Gibert-Darras et al., 2005).
Design patterns display three facets: descriptive, normative, and collaborative. In their analytic function, they are used to describe design situations and solutions. As a meta-design tool, they are used to highlight key issues and dictate a valuable method of resolving them. As a communicative tool they enable different communities to discuss design issues and solutions. The tension between these three aspects is visible in Alexander’s work, and in much of the literature that followed.
The Kaleidoscope project Learning Patterns for the Design and Deployment of Games for Mathematical Learning aims to formalize expert insights from the different domains of design knowledge using the pattern approach. Our learning patterns are intended to serve the needs of researchers, practitioners and designers as one. The structure of these patterns is based on the long-standing tradition of pattern languages in various fields, adopted to the special focus of games and learning. We began with a process of collaborative reflection on our own experiences, and have expanded this process to include other researchers and practitioners through an on-going series of workshops. Our language of patterns, and the collaborative on-line tool that support it, is evolving continuously as our knowledge grows. While the current deliverable presents the present form of our knowledge, it should be seen as a snapshot from an on-going conversation.
The pattern language
This section presents the current state of our pattern language, along with a set of interactive tools for using it productively. This pattern language intends to provide a framework for analyzing, discussing and refining the design and deployment of games for mathematical learning.
The first outcome of the project, a review of the literature, highlighted both the educational potential of games and the complex challenges which impede the realization of this potential. We argued that these challenges are dominated by issues pertaining to design knowledge in a broad set of domains. We identified a range of design approaches to educational research in the field of technology enhanced mathematical education, and concluded by suggesting that the design pattern methodology may offer an answer to some of the open issues in this field.
The next effort was aimed at producing a set of typologies, which provide a structured lexica derived from six different knowledge domains which we see as central to the questions at hand. These typologies were developed in tandem with several illuminating case studies.
These typologies and case studies inform our pattern language. Most patterns are distiled from the case studies, and the typologies play a crucial role in defining their context and in providing the conceptual vocabulary for their descriptions.
We do not claim to offer a comprehensive set of patterns, but we do strive to construct a coherent language, which has few holes and many open ends. Our aim is it to address issues across a broad range of aspects pertaining to the process of designing, implementing and deploying games for mathematical learning.
The learning patterns we developed attempt to strike a balance between problem solving and being feature specific. Some patterns address the process of game development and in doing so emerged from problems we were trying to overcome. As such, they can be viewed as problem solving patterns. Others are directly concerned with particular game features and interaction issues and are considered feature specific. However, in describing the patterns we use the generic term ‘problem’ to encompass both perspectives. For example, to address a particular problem the designer may add a specific feature.
Our patterns are distributed along two axis:
Vertical: level of detail, where one pattern elaborates a higher level one, or is used by it as a component.
Horizontal: modes of abstraction, moving from general methodologies through the dynamics of the game design and deployment process, and down to the specific patterns of game structure.
Aims
Our pattern language, and its associated interactive tools, are presented resources to be used by researchers and practitioners in several ways.
As an analytical asset, design patterns are a means of making visible implicit design decisions. Researchers and designers can reflect on their own work by mapping it to patterns in our language, or by extending the language to account for aspects we do not cover. Identifying the underlying patterns can help understand the strengths and weaknesses of existing games and the ways in which they are used. Once a pattern has been mapped to a case under observation, the context noted in the pattern can be compared to the details of the actual case, and conflicts can be discussed. On the other hand, the related patterns should be explored, to identify possible extensions and enhancements.
As a design aid, practitioners from various fields who are involved in game design and deployment can consult the patterns in different stages of their process, and chose those which address the particular questions they are confronted with. Some of our patterns address the flow of the process as a whole, some address specific phases - such as 'bootstrapping' design, and some offer concrete structural elements which can by used as building blocks. It is important to note that patterns are not cookbooks. They do not devolve responsibility from the designer, but only help her understand the scope of the issues to consider and scaffold her attempts to resolve these.
However, the most important facet of the pattern language is its potential as a framework for discussing and collaboratively refining design. In fact, this is precisely why it is called a pattern language, and not collection or set. This language grew through its use in various assemblies of designers, researchers and educators. Our workshops are structured around the language and the tools, and have used them successfully to sustain effective communication among experts from varied backgrounds. In this function, our pattern language should be seen as a starting point, an example - from which each community will derive and develop its own language.
Process
The process of creating, or 'distilling' a pattern begins with reflection on expert knowledge represented as a case study of good practice. The pattern authors identify a single element of design which contributed to the success of this case study. This element is phrased in a manner which detaches it from the single example, but avoids over-abstraction. In the words of one of the project members, it is a "situated abstraction done by an expert". The pattern is carefully named: names need to be descriptive, concise and attractive. Its details are then molded into the pattern template (described below). Using a good pattern in the wrong context is a common pattern of failure. Once the pattern has been described, it is mapped to other case studies and to other patterns in the language. By comparing to similar case studies we can refine the pattern and identify its critical features. This may lead to the need to define new patterns - as special cases of this one or as generalizations of it. At the same time, we classify new pattern using the hierarchical structure of the language and look for related patterns which are already in our collection. The GmX trail provides an illustrative example of this process.
The pattern language was developed iteratively and collaboratively by the project team, in dialogue with a wider community of designers, researchers and teachers. Due to the distributed nature of the team, the availability of on-line tools played an important role in our ability to conduct this process effectively. These tools were developed in parallel with the language, as our understanding of the process we were engaged in evolved.
Our first patterns were drafted in early April, while working on the case studies and typologies. The purpose of these drafts was mainly to direct and inform the development of the typologies so that these would prove useful when the main effort shifts to the patterns. These preliminary drafts also provided us with the basis for a pattern template.
The pattern drafts, the template and the emerging structure of the pattern section of the web site were discussed at the project assembly in Genoa in late April. After the discussion we split into cross-site groups and, as an exercise, each group produced one or more patterns. Following the assembly we reviewed the process of pattern development and the tools needed to support it.
The pattern language and tools were developed intensively over the next two months, leading to the FNG workshop in late June. That workshop brought together over 20 researchers, game designers and educators, and established depthful discussions of game and educational design using the pattern language as a framework of communication. Delegates contributed case studies from their experience, and these were processed to a new set of patterns which extended the existing language.
Structure
Our pattern language consists of over 70 patterns. We see it as a dynamically evolving resource, and this vision is reflected in the structure of the language and in the tools which support it. Patterns are classified at having one of four states: 'seed', 'alpha', 'beta' and 'release'.
'seed' patterns often represent ideas which were noted during discussion or while developing other patterns. These are placeholders, which would probably not make much sense to anyone other than thinner authors. Once they undergo the initial editing cycle, they are promoted to 'alpha' state. This state signifies patterns which are ripe for internal discussion by the project community, but still require some refinement before they are submitted to public review. This refinement would include completing missing details, elaborating the context, and adding any graphics or formating which will make the pattern easier to read. Once this work is completed, patterns will be marked as 'beta', which means they are open for public review. The feedback from this review will be used to bring the pattern to its final 'release' state.
The pattern language is organized hierarchically. The top layers of this hierarchy are abstract categories of patterns, while the lower ranks are concrete patterns and sub-patterns. The details of the structure are described in the text of the top-level node. Patterns themselves are structured using a template described below. The high-level category nodes are exempt from this template, and take form of a free-text description of the category's semantics, and a list of the main patterns and sub-categories in it. While the pattern template provides a soft scaffolding: it suggests a structure, but does not impose it. However, basic meta-data is consistently attached to each pattern, either automatically or by its authors.
The tools
Alongside the development of the pattern language, we have developed a set of interactive tools to support it. The primary functions of these tools are to allow us to efficiently manage the pattern language, and at the same time make it easy to use by any interested reader.
These tools provide various methods of browsing, reading, editing and organizing patterns.
Trails
Paradoxically, often as more expert knowledge is embedded in a pattern languages it becomes less accessible to novices. As a pattern language grows more rich and intricate it becomes the private language of the community which created it. Novices do not know where to start and how to penetrate it, because the structure of the language does not expose the path along which it evolved. In an attempt to address this issue, we have added a tool called 'Trails'. A trail is an informal illustrative account of how patterns were derived or how they might be used. It is not presented as hard data or detailed analysis, but rather as an aid for the casual reader.
An interesting example is the GmX trail, which traces the story of our progression from the Guess my Robot case study to the other case studies it was compared with and the patterns that were derived in the process.
The pattern browser
The pattern browser is the central tool in our system. It provides several modes for viewing the patterns, as well as entry points to tools for creating new patterns and structuring the language.
All patterns are listed in a database, and can be viewed in table mode and sorted by various keys. The hierarchical structure of the language is represented in a FreeMind map, which can be viewed and used as a navigation scheme for accessing pattern pages.
Overview
This is the default mode of the browser. It displays the main branches of the pattern hierarchy as an image. It is intended to enable a novice user to quickly orient herself with the structure of the pattern language. The image is followed by a listing of previous versions, and a 'forum' section for discussion issues pertaining to the overall structure of the language. The forum and versions are available in all modes of the browser. The structure can be updated by uploading a new FreeMind map. This automatically updates the overview, the browse and live modes.
Browse
Browse mode displays the pattern language as an interactive html tree. Branches can be expanded and collapsed. Clicking on a pattern name leads to the pattern page.
Live
Live mode uses a java applet to browse the map, combining the functionality of both overview and browse mode.
Index
Index mode lists all patterns in the database, even those in preliminary state which have not yet been integrated into the structure. Index mode displays each pattern's name, author, creation and last modification date, summary description, category, status and ranking. The table can also be sorted by each of these columns.
Categories are the higher-level nodes in the pattern hierarchy. Each has a page with some explanatory notes, as described above.
The status column displays the pattern's state, as described above.
Rank is a measure of how useful readers have found this pattern. Any authenticated reader can assign a rank between 1 and 5 stars, and the cumulative average is displayed.
New
Creating a new pattern is initiated from the 'new' link in the pattern browser. This leads the author through a two stage process. In the first stage, she is requested to provide the basic pattern meta-data: name, summery description and category. After this, she is led to a page where she can edit the pattern content. This page uses a template which suggests a common structure, but the author can edit it freely when it does not suit the item at hand (for example, in the case of categories). The process of editing patterns is described below.
Versions
Previous versions of the language structure map are listed below the main browser content, and can be loaded for viewing in all the above modes or downloaded for desktop manipulation.
The pattern editor
Patterns are edited using an on-line rich text editor. This editor is based on an open source tool with slight modifications and enhancements.
Header
A pattern page begins with a header which displays an expanded view of the meta-data listed in the browser index view. This header is flanked with three links: 'edit info' allows authorized authors to edit the meta-data fields (apart from dates and rank), 'edit page' allows the author to edit the pattern content, and 'publish' makes these changes public.
The Template
Pattern pages are generated from a template, which scaffolds the author to use a common structure. This structure includes a consice statment of the pattern's intent or the problem it addresses, a detailed deliniation of its context - based on the typologies, a description of the pattern itself, its relations to other patterns, additional notes and examples. The notes will typicaly refer to underlying educational research. The examples point to the relevant case studies in our collection.
The problem / intent
Short paragraph presenting the issue this pattern addresses. Remember - awareness to the issues arising in a particular situation is sometimes more important than the details the solutions.
The context
When / where is this relevant? In what kind of situations does it emerge?
Use this table as appropriate:
Concise description of the pattern in a form that can be easily applied by the user in relevant situations.
use bullet points to highlight key issues.
or
numbered lists for 'recipes'.
Include diagrams and illustrations when helpful.
Related patterns
Note the relationship to other patterns, using the appropriate qualifiers from this set - Leads to: pattern a, pattern b. Patterns the user should consider after using this one. Follows: Patterns the user should consider before using this one. Elaborates: Higher lever patterns which would use this one as a component. Elaborated by: More specific patterns which implement abstract elements of this one.
Pattern languages are typically densely linked. In our system, patterns are also linked to case studies (as examples) and typology terms (in their context). To facilitate and encourage cross linking, we have added a wiki-style quick link feature:
[[T6:PDA]] links to 'PDA' in Typology 6.
[[cases:ChanceMaker]] or [[c:ChanceMaker]] links to the chance maker case study.
[[patterns:Storyboarding]] or [[p:StoryBoarding]] links to the Story boarding pattern.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike2.5 License. 
log in