=Paper=
{{Paper
|id=Vol-1450/paper5
|storemode=property
|title=Making Interactive Board Games to Learn: Reflections on AnyBoard
|pdfUrl=https://ceur-ws.org/Vol-1450/paper5.pdf
|volume=Vol-1450
|dblpUrl=https://dblp.org/rec/conf/iwec/MoraFLD15
}}
==Making Interactive Board Games to Learn: Reflections on AnyBoard==
https://ceur-ws.org/Vol-1450/paper5.pdf
Making interactive board games to learn:
Reflections on AnyBoard
Simone Mora*, Tomas Fagerbekk*, Ines Di Loreto**, Monica Divitini*
* Dept. of Information and Computer Science, NTNU, Trondheim, Norway
{simone.mora, divitini}@idi.ntnu.no
** TechCICO, ICD-Université de technologie de Troyes, France
ines.di_loreto@utt.fr
Abstract. In this paper we discuss the making of interactive board games as a
learning activity. We do this by presenting AnyBoard, a platform that we are
currently developing to support the design and implementation of board games.
In our approach we do not use a game board virtualised on an interactive surface,
but rather achieve interactivi-ty through technology-augmented game pieces. In
this way, we aim at offering to game designers a broader design space and lower
costs of the final product. In this paper we discuss the possible use of AnyBoard
in the learning context
1 Introduction
Making games, either analogic or computer-based, has long been used as a learning
activity in different educational contexts. Making games has proved useful in areas as
diverse as engaging students with cultural heritage [1] and teaching university students
about software architectures [2]. Teachers have used making games as a way for teach-
ing programming in high or middle schools for many years, for example using RPG
maker1 or Scratch2.
In this context, we want to discuss the making of interactive board games to promote
learning. With the term interactive we mean board games that use tangible computer-
augmented objects. There are different benefits that could be achieved, mainly combin-
ing the learning strengths of creating games with the strengths of making tangible and
interactive objects for educational purposes [3, 4]. In addition, board games are popular
also among the elderly, offering a cross-generational form of entertainment. This is an
aspect that could be exploited to create cross-generational maker activities. Finally, by
making board games the learner does not get distracted by the complex graphics that is
common to many video games. In this way, it is easier for the learner to concentrate on
the game concept.
To ease the development of digital board game we present AnyBoard, a framework
for supporting the making of interactive board games. AnyBoard supports the design of
1 RPG Makers - https://en.wikipedia.org/wiki/RPG_Maker
2
The Scratch project – http://scratch.mit.edu
Copyright © 2015 for the individual papers by the papers' authors. Copying permitted only for private and academic purposes.
This volume is published and copyrighted by its editors.
Make2Learn 2015 workshop at ICEC’15, September 29, 2015, Trondheim, Norway.
29
digital board games by providing theoretical constructs, software tools and a set of aug-
mented game pieces (all currently under development). The platform was not originally
designed to be used in the educational context, but mainly targeting maker communi-
ties. However, it could potentially be useful in the context of educational maker activi-
ties. In this paper, after presenting the AnyBoard approach, we discuss the challenges
connected to the use of this platform for learning building on our experience on the
creation of an interactive board game.
2 The AnyBoard framework
The dominant paradigm for creating digital board games consists in designing games
for interactive surfaces such as smartphones, tablets or tabletop computers. In some
cases, artefacts that resemble game tokens, yet augmented with markers (e.g. barcodes,
RFIDs), can facilitate interaction with the interactive surface [5, 6].
We propose a different approach: the game pieces are the means to bring interactiv-
ity, rather than the game board virtualised on an interactive surface. Distributing inter-
activity across multiple components opens for a wider space of possibility in designing
game experiences. For example, game pieces can influence the state of a game not only
when they sit on an interactive surface, but also when they are manipulated over and
around it. In this way, the board is mainly used to stage the game and set a context for
the use of the pieces, as in traditional board games. In addition, the interactive area of
the board is less limited by size, which also determines the portability of the game and
costs.
2.1 A new perspective on digital board games
In our approach to digital board games the role of technology is twofold. On one side
it brings interactivity by augmenting, not virtualizing, pieces’ material representations,
for example we aim at providing developers with tangible game pieces augmented with
visual, audio or haptic feedbacks (e.g. by means of LEDs or displays). On the other side
sensor technology is used to capture players’ physical interaction with pieces aiming at
preserving their traditional physical affordances; for example, to sense the result of a
dice throw, or the movements of pieces onto the board.
Game pieces still preserve their traditional aspect, having a tangible representation
that complements an intangible one provided by technology. For example, in a revisited
version of Monopoly tokens might preserve their physical semblances to identify play-
ers but might embed a graphical representation of the number of property owned by the
player (e.g. in icons or symbols on a LCD display). The intangible representation is
kept updated by a computer game engine during the playtime, as a consequence of
players’ interaction with game pieces and activation of game rules. The interaction with
pieces is based on a double loop [7].
30
Fig. 1. Double interaction loop in interactive board games
A first interaction loop consists in the passive haptic and visual feedback the player
perceives when manipulating pieces on the board, this loop is in common with tradi-
tional board games. A second loop adds interactivity by means of graphical and audi-
tory feedbacks conveyed via the tokens’ intangible representation (Figure 1). This loop
requires technology for sensing tokens’ manipulations as well as providing visual/audio
feedbacks. The set of valid interactions with game pieces are defined by the affordances
of pieces and by game rules. To formalize these rules we build on two theories: the T+C
framework [8], providing a powerful descriptive language, and the MCRit model [9],
addressing issues of representations and control in TUI.
2.2 Key design constructs
We define a game, which is composed by game dynamics (the sum of game logic
and rules), as a sequence of player-initiated interaction events that modify spatial con-
figurations of tokens with respect to board constraints and other tokens. In the follow-
ing, building on the T+C framework, we describe key constructs required to develop
an Anyboard game.
Tokens are technology-augmented artifacts capable of triggering digital operations
that can activate game dynamics. They are an augmentation of traditional pawns, dice
and cards. Tokens may be capable of sensing information (e.g. proximity with other
tokens) and displaying computer graphic and sound.
Constraints are confining regions in the board space, for example checks in the
Chess game and territories in Risk. The association or dissociation of a token within a
constraint can be mapped to digital operations to activate game dynamic. Constrained
regions are determined by a perimeter that could be visual, or physical.
Interaction events are player-triggered manipulations of tokens, that modify the
(digital and physical) state of a game. We identified three types of events.
Solo-token event (T) - the manipulation of a single token over or on the board. For
example, the action of rolling a dice or drawing a card.
Token-constraint event (T-C) - the operation of building transient token-constraint
associations by adding or removing tokens to a constrained region of the board. T-C
events can have different consequences depending on game rules.
31
Token-token (T-T) event - the operation of building transient token-token adjacency-
relationships, achieved by moving tokens on the board. For example, approaching a
token next to a different token to unlock special powers, or to exchange a resource
between two players.
Sequence of interaction events, validated against game-specific rules, activate game
dynamics and allow the game to evolve from a state to another. For example, we can
model the act of capturing a piece in chess as a sequence of interaction events that
modify proximity between two chess tokens within checkers constraints. For more de-
tails, see [10].
In the following section we describe how theoretical contracts have been imple-
mented for the augmentation of an existing board game.
2.3 An example
Don’t Panic, is a collaborative game inspired by Pandemic3. Four players start the
game as member of a panic manager team that must work together to manage panicking
crowds. A map representing a city map is displayed on the game board and the territory
is divided in sectors. Each sector contains a number of people (PO) characterized by a
panic level (PL). During the game randomly triggered panicking events (e.g. fires, ex-
plosions) increase PLs in determinate sectors. Each player is represented on the board
space by a personal pawn token and gets a limited number of actions with the goal to
lower the panic level in the city. Using the public “Calm!” and “Move!” tokens a player
can either reduce the panic in a specific sector or move panicked people to an adjacent
sector. Information cards tokens distributed in each turn can lower the panic in multiple
sectors. Players collectively win the game when the PL in all sectors is zero. For a full
description of game rules see [11].
Don’t Panic is composed by a cardboard and a set of tokens:
The board (Figure 2-a) – is a cardboard that visualizes a map portraying a territory
divided in nodes, sector and paths. Nodes feature physical constraints and no degree of
freedoms for the hosted tokens; sector and paths provide visual constraints allowing
tokens’ translation and rotation, within the perimeter.
The card deck (Figure 2-c) – dynamically print information card tokens. Each card
has a textual description of how it affects the game and a barcode that links the card to
its digital representation. The top surface of the card deck can read the barcode on the
card and trigger actions in the game (Figure 2-d).
Pawn tokens (Figure 2-b) – embody the players’ presence on a node. Pawns can be
moved from node to node and provide visual information via a LCD display. These
include the role of the player, number of people present in sectors adjacent to each of
the four pawn’s sides; and their panic level.
The Calm! token – represent the field action of calming people talking to them, thus
reducing the PL in a specific sector. This action is activated when Calm! is bumped
towards a Pawn token (Figure 2-e).
3
Pandemic board game - http://zmangames.com
32
The Move! token – simulates moving people across sectors, in this way people
moved acquire the panic level of the recipient sector. This action is activated by drag-
ging Move! across a border between two sectors (Figure 2-f).
Fig. 2. Don´t Panic interactive tokens
3 The AnyBoard software library
We present here a library to bridge the gap between the theoretical constructs re-
ported in section 2 and the making of interactive game pieces.
Game design communities, game developer environments and game engines already
exist, and hence the main part that makes the AnyBoard framework unique is helping
integrate the development interactive tokens interaction as a part of games (Figure 3).
This role is performed by the Token Manager library.
The token manager provides a Token API to available game engines, so developers
can listen to player-token events and send commands to the interactive tokens without
the knowledge of the low level code or the tokens’ hardware. The API provides primi-
tives specifically suited for augmented board games, such as Token, Constraint and
Interaction Events (Section 2.2). The API is generic enough to be used with popular
game engines, both commercial and open source, such as Phaser4 and Unity5.
On the other end, the token manager is separated from any specific hardware imple-
mentation, and communicates with the physical tokens through device-specific drivers.
Besides a set of tokens is provided as part of the framework, expert users can tinker
them or build new tokens using popular toolkits such as Arduino and RaspberryPi.
Drivers for the Arduino platform as well as a generic extendable driver will be provided
to assist developers that wish to create their own tokens with specific technologies.
4 Phaser game engine – http://phaser.io
5 Unity game engine – http://unity3d.com
33
The AnyBoard library builds on the Apache Cordova6 platform that enable games
made for AnyBoard to compile to different operating systems, including mobile ones
such as Android and iOS. We aim to use open source, free-to-use, modular and well
documented tools, so that a developer can pick apart the AnyBoard system and add
capabilities where need be.
Fig. 3. High level components of AnyBoard
Standard example games, and templates implementing typical token capabilities,
will be provided for developers that wish to create games with general token require-
ments.
Finally, a web-based community for AnyBoard is intended to grow a community
and provide information for all roles involved with augmented board games. The Any-
Board platform will be available from there, and tokens sold from a third-party or made
using prototyping techniques and open source schematics. The community will provide
a knowledge base and tools for developers. Furthermore, it will feature a repository of
ready to use Anyboard games and an assistive IDE for game.
4 AnyBoard for learning
Making an interactive board game with AnyBoard requires different competencies,
varying from game design to software and hardware development skills, and it therefore
opens for the design of learning activities with different and multiple learning objec-
tives. In this section we reflect on how the platform, when fully developed, could be
used for learning.
6
Apache Cordova Platform - https://cordova.apache.org
34
The phases that are required for the full development of an AnyBoard game include:
- Game design, i.e. the definition of the game concept, logic and rules
- Interaction game design, i.e. the definition of the interactions of the players with
the game tokens and the interaction among players, either directly or mediated
by game elements
- Mapping of the game into the associated token+constraints system
- Implementation of hardware and software, this might range from implementa-
tion of the game engine to the development of the token interactions. This phase
might also include the production of objects that are not computerized, like the
board and cases to tailor the appearance of tokens, e.g. using 3D-printing.
The different phases allow to explore different learning goals through adequate ac-
tivities. The design of the learning activity might focus on one or more of the following
learning area:
- Specific subjects. If the game is designed as a serious game, i.e. by playing the
game players are expected to learn X, it requires that students gain a knowledge of
subject X to inform their design. In this perspective, the implementation part might be
less relevant and the main focus is on the first phase of game design.
- Interaction design by designing the intended interactions among players and the
interaction with the tokens. It should be noted that the actual design of the tokens ap-
pearance and interaction is strictly related to the game design. It can also become a way
to learn about the game subject. For example, in developing a game for crisis manage-
ment, one could work on tokens that resemble actual objects in the domain, mirroring
their behavior in the real world.
- Abstract thinking/logic. To achieve this learning goal, in addition to the high level
design, one should put focus on the translation of the high level rules into the framework
constructs in terms of tokens and constraints.
- Coding. Learning to code can be achieved during the implementation phase. This
might include both more traditional coding for the game engine and coding for embed-
ded systems. In this way, different computational approaches, languages, and feedback
systems might be explored.
- Tinkering. The design and implementation of the game requires to play around with
different software and tangible components.
5 Conclusions: towards a revised framework
In this short paper we presented an innovative approach to design of interactive
board games. The approach is based on the use of interactive tokens on an analogic
surface, in alternative to current approaches that mainly rely on interactive surfaces.
This approach, we claim, might be suitable to be used in the context of learning by
making. The paper discusses the potential of the framework for learning.
To realize this vision there are a number of components that should be added to the
framework, including:
35
- Graphical interface for coding, hiding if required by the design of the learning
activity, the complexity of moving from high level rules to the token+constraint
system.
- Templates for learning activities with different learning objectives. These tem-
plates should help the organizers of the learning activities to quick-start the de-
sign, choosing activities that reflect the intended learning objective.
- Scaffolding, possibly including support to hide complexity or irrelevant parts of
the platform. This can be achieved in different ways at different level of com-
plexity. It should be taken into account that board games might have a lot of
objects and very complex rules that can be overwhelming for a non expert. At
the same time, though learners are getting less distracted by developing graphics
than in a traditional video games, still the development of the tangible parts
might become very complex and distract the learner from other possible learn-
ing objectives.
- Community support oriented to education
- Analytics for reflection
As part of our future work we aim at developing these components following a
learner-centered approach. This will require to identify more in detail the benefits of
this approach compared to other types of game development for learning to focus the
development of the component necessary for the more suitable learning activities.
REFERENCES
1. Yiannoutsou, N. & Avouris, N.: Game Design as a context for Learning in Cultural Insti-
tutions. In C. Karagiannidis, P. Politis, & I. Karasavvidis, eds. Research on e-Learning
and ICT in Education. New York, NY: Springer New York, pp. 165–177, (2014).
2. Wang, A.I. & Wu, B.: Using Game Development to Teach Software Architecture. Int. J.
Comput. Games Technol. (2011)
3. Horn, M.S., Crouser, R.J. & Bers, M.U.: Tangible interaction and learning: the case for a
hybrid approach. Personal and Ubiquitous Computing, 16(4), pp.379–389 (2012).
4. Mellis, D.A. & Buechley, L.: Case studies in the personal fabrication of electronic prod-
ucts. In Proceedings of the Designing Interactive Systems Conference (DIS2012), ACM
Press, pp. 268-277.
5. Haller, M., Forlines, C., Koeffel, C., Leitner, J., Shen, C.: Tabletop games: Platforms, ex-
perimental games and design recommendations. Art and Technology of Entertainment
Computing and Communication. 271–297 (2010).
6. Bakker, S., Vorstenbosch, D., Van Den Hoven, E., Hollemans, G., Bergman, T.: Tangible
interaction in tabletop games. In Proc. of ACE 2007. 163–170 (2007).
7. Ishii, H.: Tangible bits: beyond pixels. In Proc. of TEI 2008. (2008).
8. Ullmer, B., Ishii, H., Jacob, R.J.K.: Token+constraint systems for tangible interaction
with digital information. ACM Transactions on Computer-Human Interaction (TOCHI).
12, (2005).
9. Ullmer, B., Ishii, H.: Emerging frameworks for tangible user interfaces. IBM systems
journal. 39, 915–931 (2000).
10. Mora, S., Di Loreto, I., Divitini, M.: The interactive-token approach to board games. In
Proceedings of AMI2015, LNCS, Springer (to appear).
11. Di Loreto, I., Mora, S., Divitini, M.: Don’t Panic: Enhancing Soft Skills for Civil Protec-
tion Workers. In Proc of SGDA. 7528, 1–12 (2012).
36