Wizard’s Apprentice gameplay-oriented design of a computer-augmented board game Johan Peitz1,2, Staffan Björk1,2, Anu Jäppinen3 2
1
Game Studio
IDC | Interaction Design Collegium
3
Hypermedia Laboratory
Interactive Institite
Dpt. of Computer Science and Engineering
Fi-33014 Tampereen yliopisto
SE-412 96 Göteborg, Sweden
Chalmers University of Technology | Gothenburg University
[email protected]
{johan.peitz|staffan.bjork}@tii.se
SE-412 96 Göteborg, Sweden {jpz|staffanb}@cs.chalmers.se
ABSTRACT
This paper describes the prototype Wizard’s Apprentice, a computer-augmented board game. Unlike many previous examples from research, which use board games as a means to explore technology, the game was developed from the starting point of gameplay design goals. The paper reports upon how the different starting point required iteration between the various design disciplines involved. The game and the design within the various disciplines are described together with sections on how results from one discipline affected other. The paper ends with reports from the first preliminary evaluation.
Categories and Subject Descriptors
J.7 [Computer Applications]:Computers in other Systems – consumer products (games).
Keywords
Game design, computer-augmented board games, board games, design, social adaptability, ubiquitous games, pervasive games.
1.
INTRODUCTION [Staffan]
Games are one application area that has been explored within Ubiquitous Computing [20] and Pervasive Computing [5]. Looking at a subgenre of games, board and card games, one can find a variety of developed prototypes. Some of these explicitly state that games are a test area for technology [16, 17] while others use the games as a vehicle for developing guidelines, technology or platforms [1, 4, 8, 11, 15, 19]. This means that the core of these games, the gameplay and the social interaction it supports, is dependent on the requirements and limitations of the chosen technology rather than the opposite.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ACE 06, June 14-16, 2006, Hollywood, California, USA. Copyright 2006 ACM 1-59593-380-8 /06/0006 ...$5.00.
Image 1 – A typical state in a game of Wizard’s Apprentice. In contrast, exploring how ubiquitous and pervasive games can be designed to support specific design goals regarding social interaction is the main aim within Socially Adaptable Games, a work package (sub-project) of the EU-funded IPerG project1. Specifically, the work package explores how these games can adapt to changing levels of involvement from a player as well as how to avoid disturbing the social environment. Based upon Calm Technology [21], Social Weight [18], and studies of player types [2], a definition of social adaptability was developed as well as a category of social roles that players take during gameplay [3]. Examples of these roles include dominator (who influences other players to perform actions for the player’s own in-game benefits), motivator (who provides or advocates activities in the game without seeking in-game benefit), and negotiator (who negotiates between other players). False Prophets [12] is an early related work to this approach, although in that case the design goals of social interaction was to increase it in general without more specified requirements in terms of different game or social roles. The first half of the work package focuses upon computeraugmented board games based upon the hypotheses that traditional non-augmented board games are inherently socially adaptable, and that general guidelines for social adaptability could be distilled from creating augmented games within the genre. For the primary prototype and the focus of this paper, Wizard’s 1
http://iperg.sics.se
Apprentice, the specific design goal was chosen to be to support two heterogeneous play styles regarding level of participation. Specifically, one player, envisioned as an adult, would only take active part in the game during short periods of time separated by longer periods of time occupied by the activities of the other players’, envisioned as children. The concept of heterogeneous play styles arose from analyzing two conceptual player groups where one wished to play a game while the other was more interested in knowing the first group was satisfied. Thereby, the adult was perceived as primarily having the social roles of motivator, negotiator, and in some cases as helper (actively helping another player perform actions in the game). In contrast, the children were perceived as primary being exhibitionists (performing actions in the game to gain the other players’ attention). Secondary design goals were supporting interruptability and minimizing social weight. This paper describes the Wizard’s Apprentice prototype and the process used to reach the intended design goals. A non-traditional structure is used in the paper to be able to more clearly show the different design process required when starting with specific design goals regarding gameplay and social adaptability rather than a specific technology. First, the final game is presented from a player perspective followed by the design broken down into the different design disciplines involved. This is followed by a section highlighting events in the design process which caused one design area to affect another. The paper is concluded with the preliminary evaluation conducted and final notes.
2. Wizard’s Apprentice
Wizard’s Apprentice is a board game in which players cooperate to defend a kingdom against the forces of darkness. All players except one play wizard apprentices who visit different parts of the game board to investigate mysterious happenings or directly confront enemies. Each apprentice character has three attributes; magic, charm and agility. The characters have a different distribution of skills in the beginning of the game, but are free to develop in any direction. Each attribute is controlled through a regular experience system which increases the attribute the more it is used. The remaining player plays the wizard, taking the role of negotiator and motivator, who advises the apprentices and plans how to overcome the enemy forces.
The game world consists of approximately 50 sites where events can occur and quests can be located. These sites have individual themes and the current state of the sites represent how the evil forces have been active. At the beginning of the game, the areas around the central castle are positively inclined towards the players while hostile powers are located relatively far from the castle. The hostile powers are defined as one arch enemy with three allies, each having a specific site as their base. A game session consists of several rounds, each divided into phases. The play style differs greatly between the apprentices and the wizard. The wizard player is only active during the wizard’s phase, when the apprentices are waiting at the central castle, and is responsible for distributing quests between the apprentices. The quests can be given in any manner the wizard sees fit as any quest can be give to one or more players, or none. These decisions are based upon judging the overall game state and the capabilities of the other players, both regarding their characters’ abilities and the players’ social and emotional levels. Specific information about a quest, and the ability to assign apprentices to the quest, is enabled by placing the corresponding quest card on the information area. As long as the quest card is kept on that site, players can be assigned the quest by placing them on the quest’s location on the board. Assignments can be cancelled by placing figurines in the die pit (described below). Removing the quest card returns the overview map where all player assignments can be seen. Once the wizard is satisfied with the task allocation, the wizard phase ends and the apprentices’ take over. In the apprentices’ phase, the players take turns traversing the game board. An apprentice’s turn is a based upon the simple roll and move mechanism found in many board games. When a location site is reached, one of the following happens: •
Nothing. The player has reached a location that is an ally, not a quest site, or a size visited and completed by another player.
•
Random challenge: The player has reached a site in control by the evil forces and must fight monsters.
•
Quest challenge: The player has reached a site where she is assigned a quest.
If a challenge is issued, the player must roll the die and add the result to a specific attribute and score higher than the difficulty of the challenge. If it is a success, the location site is completed and its narrative updated. However, if the player fails the difficulty of the site increases and the player must move back to a previously visited site. Players should return to the castle once all their quests have been solved. When all players have returned, the apprentice phase ends. Last in each round is an evaluation phase where all players, including the wizard, can see what quests where completed, and by whom.
Image 1 – Typical overview during the Wizard’s phase.
Wizard’s Apprentice uses computational augmentation in two main ways that are integral to gameplay rather than being just special effects. First, it keeps part of the game state hidden and plays the part of the dark forces. Second, it supports the player who plays the wizard by presenting overviews of the game state and presenting what tasks are available to be given to the apprentices. These augmentations could only be done with difficulty without a computer, e.g. using another player who manipulates the game state either through the introduction of an extra representation of the game board or numerous game
elements. However, players interact with the game only through normal board game actions, i.e. moving their figurines, playing quest cards, and rolling a die. The game state is partially stored in a computer and partially stored by positioning the figurines on the board. Besides the active location sites on the board two special areas exist. The first special area is the die pit, which is used when the computer system needs to know the result of the die. The other area is physically similar to the location sites but provides information about quests or characters when cards and figurines are placed upon it. At any time, the players can place their figurines on this information area to gain information about attributes, experience points, equipment, and current quests. The system also shows the figurine’s last registered location to help remember where the figurine should be placed when the information no longer is wanted. Apart from a regular computer running the game engine, Wizard’s Apprentice requires access to a copy of the custom built game board. The game is intended to be played using a projector to display output from the computer but this is not strictly functionally necessary.
2.1 Gameplay, Story, and Guidance arcs
Wizard’s Apprentice has disparate arcs that describe the overall gameplay structure, the level of guidance from the wizard, and the story development. The overall gameplay arc starts with the apprentice players doing initial exploration of the sites near the castle, allowing them to gain experience and learn the interaction patterns in the game, e.g. about possibility to collect and trade objects. Due to the short distance required to reach these initial quest sites, the wizard needs to be present relatively often or even continuously. After the initial quests have been solved, the location of new quests become further and further away from each other and the castle, creating longer period of time when the wizard does not need to be present. As the quests become closer to the forces of darkness they also increase in difficulty and the players must level up in order to progress, The guidance arc starts off with strong guidance from the wizard and is indicated by short sessions with quests that can quickly be solved. As gameplay progresses the quests become longer and apprentices perform more activities before returning to the castle and the wizard. Game mechanics to avoid over-exploration by players (i.e. visiting more location sites than in the wizard’s assignments) include hiding the where the evil forces reside until located by quests, reduction in experience for overcoming challenges at non-quest sites, and is naturally limited to due increasing difficulty as players go farther and farther from the castle. In contrast, the story arc starts with an unknown threat and quests consisting mainly of scouting or re-establishing contact with allies. As gameplay progresses the nature of the enemy become clearer but the difficulty of the quests increases. As the game progresses, the players locate three minor enemies and a major one. Once these have been defeated the game has been won. A scoreboard will now show the final statistics of each player and also assign awards to the players for any specific goals that they met during the game.
3.
Implementation
The design of games using traditional game types but with computer augmentation is an iterative process [6, 10] as well as an inherent multidisciplinary activity [10]. In this chapter the various design areas involved in creating Wizard’s Apprentice are described to provide a basis for the process description given in the next chapter. The gameplay design is not described below since it has already been presented in the previous section. The descriptions below make use of the concepts of forces, clashes, and remnants by Lundgren and Björk [10] to describe how decisions in one design area affects other areas. A force is a design decision made within one discipline that has a strong influence on later work in other design areas while a clash, which may also be a force, requires actual redesign of in other disciplines. Remnants are instantiated design choices made during certain conditions during the iterative process that persists after those conditions are no longer valid.
3.1
Software Architecture
The computer system in Wizard’s Apprentice is written in Java and uses the extra communication API for communication with the hardware. It serves two main purposes; the first is to create and maintain the game state of each location site and control how the evil forces move and react to players’ actions. The second is to keep track of the individual apprentice’s actions to provide feedback and an overview to the wizard when he or she plays. During implementation the code went through many changes due to clashes and forces but there are also remnants in the form of implememtned functionality that ended up not being used. The software architecture is object oriented and is comparable to most other game architectures. The three most important modules are described separately below. Log
Quest
*
1
QuestManager
WAMain
1
1
SoundBox
GameEvent
*
1
GameFrame
1
EventManager
1
1
1
SetupMode
1 1
WizardMode
PlayMode
MovingMode
1
GameEngine 1
*
1
QuestMode 1
ImageIcon Factory
Delayed GameEvent
PortListener 1
1
FontFactory
PortHandler
Board 1
*
Site
*
Player
ResultsMode
1
*
Item
Figure 1 – Schematic overview of software architecture for Wizard’s Apprentice.
3.1.1 Event Manager The event manager handles all input to the game. Input is received from the game board but can also be generated through use of a debug panel. To enable this functionality, the event manager consists of two functional parts: one part that receives input from a serial communication port (i.e. the game board) and translates it to abstract events and one part that sends the abstract events to game engine. This second part also has error detection built in since the hardware sometimes fails to send correct information.
3.1.2 Game Engine Apart from handling the setup of the game the game engine ties all other software components together and stores the game state. The game engine does not itself update the game state due to game events; rather the game events sent from the event manager to the game engine is forwarded to the current play mode which interprets their contextual meaning of the event and updates the game state accordingly.
3.1.3 Play Modes The gameplay in Wizard’s Apprentice is structurally divided into several different modes of play which are mirrored in the software architecture as play modes. The play modes control what information is presented by the UI and handles game events; the latter by checking if registered game events are syntactically correct and if so determining their semantic meaning, updating the game state as necessary. The play modes also hold what information to display to the players. Specific classes have been created to support thematic text, gameplay information, images, and the map which can highlight location sites and last known player positions.
location sites, detect and identify cards or figurines placed on the information area, and detect the result of a die roll. Based upon some gameplay experimenting and previous experiences with the MyTHeme game [10], it was decided that RFID technology would be used. However, the number of locations that needed to be sensed would require excessive costs for RFID readers. To counter this, special architecture was developed where one RFID reader could handle several RFID antennas. However, since changing RFID antennas requires some time for the magnetic field to stabilize, cycling through all location sites would take too much time (~60 seconds). The solution was to position, in addition to the RFID antenna, a photo resistor at each location site that could detect if a physical game token was placed there at all and only then check the RFID antennae. Although this made the game board susceptible to other types of covering, and that sufficient light was presented when playing, this was judged as not significantly affecting the intended gameplay. To handle the information area and the die pit, a second RFID reader was used that simply switched between the two antennas. game board
RFID antennas laptop
3.1.4 Additional Modules In addition to these central modules, a few others are worth mentioning. All information about the location sites and what quests they can generate are stored in separate XML files. A SiteParser component provides functionality to parse individual files and register them to the game engine, and has utility methods for parsing all files within a directory. At the start of each game round a number of quests need to be generated. The QuestManager reads the current game state and generates quests accordingly making sure that the game progresses properly.
3.1.5 Utility tools for authoring and debugging A set of software utility tools were developed to support the process of gameplay design and software implementation, e.g. tweaking and debugging.
RFID readers
photo resistor and RFID antenna
Figure 2 – Schematic view of technology use in Wizard’s Apprentice Both RFID readers are based on the BX24 microcontroller. For each RFID-tag read the microcontroller packages the information and sends it to the computer via serial communication. Besides the components described the game board contains a small hub that can convert serial input from two different ports into one USB connection. This allowed very easy connection to the computer running the main software the via a single USB cable.
One such tool was a control panel for simulating input from the game board, which allowed the implementation of hardware and software to be conducted in parallel. To be able to view all the information that the game engine held about the game board needed to be visualized. This was needed to check that all location sites were stored correctly as well as that they had individual identity codes and the correct neighbors specified. The visualization of the board was also used for initial game balancing of commodities and the algorithm controlling the spread of evil force. An editor was also created in order to provide a tool for having an overview of all location sites and changing their information without having to edit the XML files directly.
3.2
Hardware Architecture
The hardware had three very specific requirements. In short, the game board needed to detect and identify figurines placed on a
Image 2 – Inner details of the game board for Wizard’s Apprentice.
3.3 Graphic Design 3.3.1 Game Board
Since the game had a classic medieval fantasy theme, the game board was designed to reflect that. Each site was given a unique narrative that was portrayed by an image showing what the location looked like. This image was also used in the UI to minimize cognitive load to map between the two. The main board also contains a traditional board game movement graph, with the location sites marked by larger nodes. The map itself was also used for both the physical board and for the overviews in the computer-based presentation.
3.3.4 Card Design
At gameplay level the game’s quests are very generic but due to the narratives on each location site the game has about 250 different quests. This made specific graphical representation of each quest impossible and instead a card with a metaphorical icon was created to represent each quest type. Each card included also the name of the quest since this is used in other parts of the computer presentation.
3.3.2 Information Display Design
The projected image shown by the computer serves both as an overview of the current gamestate and to give the players specific instruction of how to proceed during certain events. The information given is formatted differently depending on if it is instructions or just themed text.
Image 5 – Examples of quest cards.
3.4
Specific sounds were designed to strengthen the visual feedback of important game events and to notify the players that something important had happened onscreen that needed their attention. The sounds conveyed emotional meaning, i.e. success or failure, but did not use speech to avoid that the same information was given through language in two different media. Specific sounds were also designed to be played when the system detected the presence or removal of an RFID tag, which supported both debugging hardware and helping player pace their actions to fit the limitation of the hardware.
3.5
Image 3 – Vladimir succeeds with a charm challenge. Throughout the game, the information is also color coded depending on what skill the players need to use and this color is used on the projected information, on the quests as well as in the colors of the figurines.
3.3.3 Figurine Design
The figurines in the game were designed to portray each character’s special ability and function. Each figurine has an embedded RFID tag in the base that can be read by the sensors. A force from the physical board made it impossible to have the sensors directly at the board surface which forced the figurines to have a slight recess at the base to reach down to the sensor.
Image 4 – The figurines used in Wizard’s Apprentice.
Sound Design
Tangible Interface Design
The design goal of maintaining as much as possible interaction style of board games for Wizard’s Apprentice meant that nontraditional computer interfaces had to be developed. The use of RFID-tags in cards had been proven in other prototypes [4, 10] and was used together with figurines and a die, which also had RFID-tags embedded. Two types of cards where developed, those representing quests and those used for meta commands such as restarting the game. The die was designed to be used in to ways: as a normal six-sided die for movement but also as an eight-sided die for rolls in the die pit when challenges occurred. The design space for possible interactions were heavily restricted due to the binary nature of RFID readers (only noticing when a tag is placed nearby or later removed) and that the used RFID readers only could detect one tag at a time. This made it necessary to give different semantic meanings to the places on the game board depending on what RFID-embedded game token was placed there. The majority of the sensors was used to represent locations and was only used to notice movement and assign quests by placing the relevant apprentice figurine there. An exception was the castle which doubled as a means of shifting from the play mode of assigning quests to performing quests and back by placement of the wizard figurine there. The information area can provide information about both quests and characters by placing the cards and figurines that represented them on the sensor. Besides the functionality to read die rolls, the die pit had a hidden functionality of shutting down the game engine by placing the wizard in the pit.
4.
Process
Wizard’s Apprentice went though several design iterations through its development. These started with low fidelity prototypes using no software or hardware to intermediate versions with some computer support to the full version. To allow the question of hardware to be open as long as possible, a survey of viable technologies and some small experiments were conducted before actual gameplay design was started [7]. Already at a very early stage the theme of the game was changed as a force due to the selected target audience from concerning fighting knights to concerning apprentices to a wizard. This change of theme did not require any changes in the planned gameplay, but avoided placing the game world in a maledominated setting. It also shifted the focus from overcoming challenges through violence to other means, which thematically was done by using attributes not intrinsically related to violence. As a game based much upon exploration, one of the earliest details of the design considered was the map to be used. The initial ideas of having the castle located at the centre and having alternative routes to all sites remained throughout the process, but the exact graph used was changed several times due to clashes between balanced gameplay and graphical design. Although little computational powers were used in early play testing the game logic and intended algorithms could be tested by making use of physical tokens.
This clash proved to require a redesign of the die. After some experimenting, it was discovered that placing the RFID tags in the corners of an ordinary die pointing towards its’ centre did work for reading the tags as long as the tags where directly in front of the antenna. This in itself was not a useful result since it would require the die would stand on its’ corner after being rolled on the board. Some experiments with the original die prototype had included having a bowl so that the location of the die after rolling could be guaranteed and by redesigning the bowl to an inverted and truncated near-tetrahedron it could be guaranteed that a corner would be facing downwards. Using this method the final design of the die was set, using it as a normal die for movement and as an 8-sided die when rolling in the pit trying to overcome challenges. This solution meant that the attribute system and challenge system needed to be rebalanced due to the changed range of the die.
Image 7 –Evolution of the die. Low fidelity prototyping was also used to explore fundamental aspects of how the opposition in the game would be systematized. This allowed for a separation between designing the algorithm and implementing it. This focus in the prototyping also allowed one aspect of the intended gameplay arc, how evil would spread through the game world, to be studied separately. The placement of commodities in the game world was redone several times during the design process, both due to clashes from redesigning the game map and due to detected imbalances in the distribution. Although the debug environment was available in several of these occasions, it was easier to use physical tokens to test arrangements.
Image 6 –Prototyping with physically manifested game state. This level of prototyping allowed basic gameplay patterns to be explored but did not consider how the physical game pieces would be connected to the computer system, or what the interaction model for this part of the system would be. To do this more low fidelity parts were added, consisting of cups signifying areas where game tokens could be detected. This level of prototyping created forces that influenced both the tangible user interface model and what modes of play would be present in the software architecture. The tangible user interface had required an augmented die from the initial design. Since RFID technology was planned to be used for other aspects it was considered trivial to use this for the die as well. However, placing one tag on each side of the die did not work, since a tag perpendicular to the reader was read instead of the proper one unless the die was placed exactly on top of the reader; something unlikely to occur when rolling a die.
The computer presentations underwent several redesigns due to clashes from the other design disciplines. Being only an information source and not supporting any input functionality, the main changes to the presentations consisted of making the various graphical layouts consistent, strengthening intended graphical elements, improving the quality of the information visualization, and clarifying differences between thematic and gameplay related information. Overall, the design process resulted in removal of concepts and ideas to make the current design more consistent and clear and focused on the central gameplay design goals. One example of simplification regarded artifacts. Originally it was intended that several types of artifacts would be essential for solving quests, i.e. requiring a book of the dead to exorcise an undead force. During the low fidelity prototyping it became apparent that this would require too much authoring and would require a more complex software architecture where each component would be used less. The current design instead has generic artifacts that are acquired by solving quests and provide bonuses to attributes. Another example of simplification concerns the location sites. Originally these were intended to have one attribute signifying the relation between its inhabitants and the players and another attribute signifying the evil forces presence in the location. By
combining these two attributes into one, it became easier to balance the algorithm for how evil spread. That this simplified that game world into a dualistic one of good versus evil was not considered a problem since this fitted the theme and presented an easier diegesis for the intended players. A minor change done to the gameplay flow is an example of how a clash from the tangible interface design affected the software architecture. The change consisted of rearranging the order of events controlling when the evil forces spread. This was not perceivable while playing, but allowed players to fall back from the apprentices’ phase to the wizard’s phase in order to correct faults in assigned quests.
5. Initial Evaluation The initial evaluation took place with 3 children aged 8-9 and a male adult player, age 37, involved in the gameplay session. All of them played computer games at least once a week and board games at least once a month. The playing session was made as natural as possible in the sense that participants of the play sessions were chosen on the basis that they already knew each other. The evaluation was based upon a template [9] for evaluating the social adaptability of games that divided into spatial, temporal, social, and playability. During the two-hour session, the participants were observed according to a predefined outline and afterwards they had a thematic interview concerning identified components of social adaptability, i.e. interruptability, de-contextability, social weight, actor detachment, identity detachment and non-player relations (see [9] for details).
5.1 Preliminary results
The interview questions reveal that board games were regarded inherently adaptable in the way that a player can leave the game board anytime, e.g. to have a quick drink. All the participants regarded the interruptability of Wizard’s apprentice very good – as typical of board games – but it was not put on trial in practice. In addition, the slow pace of gameplay and the division of the quests gives players the chances for pauses and socializing. Nevertheless, the pace might be too slow for example to a little bit older children than our participants. The adult, as an active player of games, was not keen on playing when blending other activities although he stated that he did not have enough time for play games in general. When playing a game he wanted to be with the children; in case he had no time to play, he’d rather give them a video or something else to do on their own. Wizard’s apprentice was specifically designed to allow different play modes based on different functional roles: the wizard has been allocated some unique functionalities that other players do not have. The adult playing the wizard was content that he could choose different quests for children and that way regulate the gameplay. However, the role of wizard needs more development: there is not much to do for the wizard and the role is not intriguing enough according to the players. This may indicate that the adult did not want to primarily have the social role of motivator or negotiator that the role of wizard was created to support, but it also points to a limitation in the game that it does not support more active role of adult players. On the other hand the story and gameplay are so complicated that in order to find out
the appeal and attraction of it, e.g., to get to a point where the dark forces start to appear, children need help and guidance. Participants spent two hours playing the game and they were disappointed that they could not get to that point. Children were also disappointed that it was impossible to define who won when the game was not finished. That the children regarded the wizard’s role as a negotiator was confirmed by that they constantly advised the adult and eventually, when the adult did not play the role, one of the children took over while the adult ”was degraded” to be an apprentice. The advising and taking over of the wizard role can be seen as examples that the children had the dominator role, something that was not intentional supported by the design but is compatible with the design goals. The questions concerning the overall impression about the game elicited praising words from the father concerning the possibility to avoid competition among children. Some remarks about the design of figures, sensing, sound, and graphics was made. The characters tended to fall over easily since they have a depression to fit the RFID readers, and sometimes the readers did not read the RFID-tags. However, the symbols of the magic, charm and action were unclear and players suggested that they could be supported with words below the symbols. The participants considered the sounds as hilarious and the tokens as very cute offering them a lot of amusement; they seemed to have some personal traits in players’ minds. The sounds also support the gameplay: the game state could be heard, although the sounds were somewhat too quiet. The die was regarded as somewhat bulky and using it resulted in some practical difficulties. However, the moving on the board was easy for children: they could also map between the physical and virtual map very efficiently, even better than the adult. In general Wizard’s Apprentice seemingly increased togetherness and feeling of community among the players and they seemed to enjoy the game, even to their own surprise. Yet, the social aspect in the game was seen somewhat shallow: more concrete collaboration was desired, e.g. in the way that in more difficult quests the players could be allowed to join their forces and collaborate for real. In addition, when it comes to the effects of the game on the social environments, the social weight of Wizard’s apprentice is not an issue either according to the participants: they say they would not hesitate to play the game in an environment where there are other people and this could also be seen during the game sessions: the players did not even notice that some non-players dropped by to watch the game for a while. All in all, the game seemed to be very interesting to children and they were amused by the texts describing quests, for example “stinking spring” made them laugh. However, the adult player suspected that the story was not quite intended to the children of their age based upon the presences of some scary aspects such as evil forces, etc. The conclusions of the results show that the players regarded Wizard’s Apprentice primarily as a board game rather than a computer game, both regarding social and gameplay aspects. However, the aspects of the design regarding player roles and pacing of the game where noticed as unfamiliar even if the players took the social roles intended; especially the adult interpreted his intended gameplay of Wizard’s Apprentice as that in a traditional board game. If this is due to mismatch in the selection of adult
player, framing of the experiment, or simply to the novelty of the gameplay style needs to be determined by further playtesting.
6. Conclusions The evaluation showed that the design goals were in principle met, although as in any game design several iterations are needed before a balanced design is reached. The evaluation provided feedback for validating the initial hypotheses and refining guidelines for the continued research in the work package (which will study mobile games). Even though the original hypotheses, that traditional board games are socially adaptable, was not explicitly evaluated, the fact that the prototypes were deemed socially adaptable and judged less or equally socially adaptable as traditional board games, points to that the testers considered traditional board games socially adaptable. Regarding the process, we believe that the presentation given here points to the important fact that development of computeraugmented games requires a truly integrated work process between different design disciplines since each area may significantly change the requirements for any other disciplines involved. Unless this is acknowledged and explored further, the potential of computer-augmented games as a game form in itself will most likely remain untapped.
7.
ACKNOWLEDGEMENTS
The authors would like to thank the other researcher involved in the creation of Wizard’s Apprentice: Daniel Eriksson, Jussi Holopainen, Petri Lankoski, Jonas Linderoth, and Maria Åresund. The results presented here are produced as part of the IPerG integrated project, funded by the European Union through the IST programme (FP6, contract 004457) and VINNOVA.
8. References [1] Andersen, T., Kristensen, S., Nielsen, B. & Grønbæk, K. Designing an augmented reality board game with children: the BattleBoard 3D experience. In Proceeding of the 2004 conference on Interaction design and children: building a community, Maryland, USA, 2004, pp. 137-138. [2] Bartle, R. (2003). Designing Virtual Worlds. New Riders Games. [3] Björk, S., Eriksson, D., Holopainen, J. & Peitz, J. (2004). Guidelines for Socially Adaptable Games. Deliverable D9.1 of the IPerG project. http://iperg.sics.se. [4] Bohn, J. (2004). The Smart Jigsaw Puzzle Assistant: Using RFID Technology for Building Augmented Real-World Games. In Proceedings of the Pervasive Games Workshop 2004. Available from www.pergames.de. [5] Dordick, R. (1998). The Convenience of Small Devices. How Pervasive Computing Will Personalize E-Business. In IBM Think Research, no. 3. [6] Fullerton, T., Swain, C. & Hoffman, S. (2004). Game Design Workshop. CMP books. [7] Peitz, J., Eriksson, D. & Björk, S. (2005). Augmented Board Games - Using Electronics to Enhance Gameplay in Board
Games. Proceedings of Changing Views: Worlds in Play, DiGRA conference 2005. [8] Lee, W., Woo, W. & Lee, J. (2005). TARBoard: Tangible Augmented Reality System for Table-top Game Environment. In Proceedings of the Pervasive Games Workshop 2005. Available from www.pergames.de. [9] Linderoth, J., Åresund, M., Montola, M. & Jäppinen, A. (2005). Evaluation template for socially adaptable games. Available as part of the document Socially Adaptable Games Prototypes from http://iperg.sics.se [10] Lundgren, S. & Björk, S (2005). Forces, Clashes and Remnants: a Model for Event-Driven Iterative Multidisciplinary Game Design. Short paper at ACE 2005. [11] Magerkurth, C., Memisoglu, M., Engelelke, T. & Streitz, N. (2004) Towards the next generation of tabletop gaming experiences. In Proceedings of the 2004 conference on Graphics interface, Ontario, Canada; pp. 73-80. [12] Mandryk, R. & Maranan, D. (2002) False prophets: exploring hybrid board/video games. In CHI ‘02 extended abstracts on Human factors in computing systems, Minneapolis, MN, USA, 2002. pp. 640-641. [13] Montola, M. (ed.). (2004) Initial Design and Evaluation Guidelines. Deliverable for IPerG, http://www.pervasivegaming.org. 2004. [14] Nilsen, T. & Looser, J. (2005). Tankwar Tabletop war gaming in augmented reality. In Proceedings of the Pervasive Games Workshop 2005. Available from www.pergames.de. [15] Pape, S., Dietz, L., & Tandler, P. (2004). Single Display Gaming: Examining Collaborative Games for Multi-User Tabletops. In Proceedings of the Pervasive Games Workshop 2004. Available from www.pergames.de. [16] Schneider, J. & Kortuem, G. (2001). How to Host a Pervasive Game: Supporting Face-to-Face Interactions in Live-Action Roleplaying. Designing Ubiquitous Computing Games Workshop at the International Conference on Ubiquitous Computing (Ubicomp) 2001, Atlanta, 2001. [17] Starner, T., Leibe, B., Singletary, B. & Pair, J. (2000) MINDWARPING: Towards creating a compelling collaborative augmented reality game. Proceedings Intelligent User Interfaces (IUI) 2000 pp 256–259 [18] Toney, A., Mulley, B., Thomas, B.H. & Piekarski, W. (2002). Minimal Social Weight User Interactions for Wearable Computers in Business Suits, ISWC 2002. Available at http://www.tinmith.net/papers/toney-iswc2002.pdf. [19] Wagner, D., Pintaric, T., Ledermann, F., & Schmalstieg, D. (2005). Towards Massively Multi-User Augmented Reality on Handheld Devices. Proceedings of Pervasive 2005. Available from http://studierstube.org/invisible_train/, last visited 2005-04-13. [20] Weiser, M. (1993). Some Computer Science Issues in Ubiquitous Computing, in: Communications of the ACM, vol. 36, no. 7 (July 1993), p. 75-84 [21] Weiser, M. & Brown, J. S. (1996). Designing Calm Technology, PowerGrid Journal, v 1.01, http://powergrid.electriciti.com/1.01.
