Overview

Castle Quest is our interactive game to get kids excited to do math. Kids learn math immersed in a physically interactive video game. Visual and auditory feedback create a fun learning experience. Kids answer basic math problems to blast cannon balls at their competition.
Sections: Introduction, Gameplay Development and Insights, Physical Development


Two players each own a castle and solve math problems by adding numbers to reach a target.

The red player has correctly added up to the target numbre and its cannon has fired. The first to destroy the other player's castle wins.





Development

Introduction

3DE arose from a serendipidous meeting during a Computer Science 247 cource. We were all interested in creating an physical math game with younger kids. Our name is based upon the storytelling creativity and diversity.
In forming our group, we all began brainstorming interesting ideas and gameplay. Throughout the next two weeks, we began to ideate on different game play, metaphors, and how this all fit together.
Castle Quest actually began around discussions around an two player math game that is "solvable" by dynamic programming. We imagined scaling this game up to many players. This new dynamic would increase number variety and decrease solvability. We developed this idea along different ways to make gameplay more interactive and engaging.

Design Process

The CS247 human computer interaction course centers around rapid prototyping to gain insight into user needs. Each step of our game design process and creation embedded these ideas.
We centered around the idea of designing a physical game for younger kids. We picked the East Palo Library's Quest program to be our awesome observees / guinea pigs. The Quest Learning program is a daily after school program encouraging kids to read, do homework, build academic skills, and do activities. Students in the 3rd to 5th grade were very enthusiastic in sharing stories and being awesome. We found them an absolute pleasure to work / play with starting with our first observation of a game tournament and student run store. In this section, we briefly overview the prototypes we ran through. Discussion on each of these learnings will occur in later sections.
With our second observation, we prototyped the game with playing cards to simulate our future game input device. The game dynamic that really encouraged us was a sense of cooperation to not break the ice. One initial concern was 3de was the difficultly level and engagement with math for these 3rd to 5th graders. Instead, we found these kids who had not even learned algebra yet were really engaged in doing math. This is our first prototype, embodied through a card game.
Our iteration the next week was to prototype our game in javascript. We found this to be very insightful with regards to gameplay mechanics. Our earlier ideations on game mechanisms were on par with expectations, and we gained insight into how speed, feedback, and animation were very crucial. This is our second prototype, embodied through a javascript game.
The next week, we created the game in Processing with RFID tags. We iterated with a couple of designs in terms of both which tags to use This example gave us insight into the importance of user feedback and engagement. We realized the target score / number was easily modify-able to speed up or slow down gameplay. This is our third prototype, our first visually phsyically end to end system.
Following on this, we refined the prototype with physical holder from our findings in the raw physical prototype. We added our initial thoughts on visual and audio feedback. This is our fourth prototype, the raw physical prototypes.
Our next prototype has integrated all of our learnings on visual and audio feedback and placed it all into nice holders and better game play, our fifth prototype.
After our information presentation, we made a new polished physical holder and integrated better visual feedback both in terms of graphic polish and an enhanced visualization for addition. This is the one played during our presentation.

Gameplay Development and Insights

At the beginning, our game started off as a math riddle. The problem is posed as "We are solving a two player counting game. The first person to count to 50 wins. You count up numbers one at a time by saying a number between 1 - 9."

Prototype 1:

To see how this game play translated into an actual two player game, our team prototyped the game feasibility using playing cards. We used cards from A - 5 to test how well we individually added numbers to reach 50. Players took turns placing down a single card while the scorekeeper kept track of the played cards' accumulated sum on a centralized white board. The goal was simply to reach, through the gameplay, the target number without going over. In our game between two people and a mediator, we found certain gameplay elements worked extremely well while others did not. We iterated on having whether or not to have auditory / visual feedback. By auditory feedback, the mediator read out what the total sum was. With visual feedback, the mediator wrote the current sum on a whiteboard. With absolutely no visual or auditory feedback, the math to sum up numbers was actually pretty difficult. We found a combination of the two feedbacks was the best. Although we found a limitation in the medium we used, for a play to see the number, they had to look up from the math problem they were currently doing.
The gameplay was dictated by a hand of 5 cards to play. We hypothesized once we had a digital game, we could play with the idea of modifying the goal number and game speed. We would experiment with gameplay to either have smaller miniture goals to create a point system separate from the counting problem. Also, we would experiment with the number of cards playable at one time and this goal number.
To better explain the game, we used the metaphor of "Icebreakers." The target number was liked to a layer of ice and each card played was like an ice block placed on top of it. We told children that if at the end, they reached a value greater than the target number, then they would "break" the ice. To our delight, kids easily grasped this metaphor and encouraged us to continue advancing towards building an interactive math game.

Prototype 2:

For the next week, we created the card game in javascript. The gameplay was sped up a lot by the fast acting computer clicking motion. We no longer had to worry about picking up the cards. This was a positive and negative, we could experiment with gameplay very quickly but the physicla representation made the game more engaging on some level. Once we had the javascript game, we found a visual feedback on number we were playing was extremely useful. Also, we did not have auditory feedback in this version. We inserted visual color cues on whether a user succeeded or failed in reaching small goals. We had a display of the current target, but no cues on what card was just played.

Prototype 3:

For this prototype we learned a number of insights on physical interaction which are discussed in a later section. The largest gameplay elements we iterated on was the presence of graphics and how to best frame the different stages of victory.
The fast prototypes let us full ideate on how much detail we needed to place into the metaphor. We decided to use the Castle metaphor because we simply could not decide by the end of a long brain storming session. Also, this initial processing animation and feedback was not particularly enhanced. The animation for the cannonball and the castle crumbling was accomplished by simple image changes.
We found though on each round or swipe of the different playing tags, kids would look for an indication of progress or activity. This helped us realize the importance of visual and audio feedback for our future prototypes.

Prototype 4:

This prototype involved us re-programming the entire project in Action Script. This decision came to create more fluid graphics and flexible feedback with regards to visual highlights and emphasis.
For this prototype we learned the game we created was basically functioning. We re-imagined our initial impetus of team play. Throughout the gameplay we found kids did not operate as teams, instead when we placed kids in teams to play our game, the kids always had one dominant driver and one passanger. This presented a tradeoff between creating rules or letting natural social hierarchy dictate play. We decided to eliminate our conceived notion of creating a classroom sized game.
We also found through audio feedback was so important in helping kids register the fact they entered a card. We found though kids would still look at the screen after they heard the click to double check the current target and the current number. This led to a hypothesis we could create a better visualization to represent the most recently entered card in relation to the current and target.

Prototype 5:

This prototype was made to enhance polish and give us another iteration to show the East Palo Alto a first take and to showcase the CS247 a refined version.
In our most recent prototype, we added much richer visual and audio feedback. We added prompts to the different actions such as busting and added better feedback through a health bar. In particular we added audio feedback on each chip input. This added a level of engagement in the game. Furthermore, we added a track from an 80s video game to our game. This created a very fast paced game, though the music was on loop and confused kids when we demonstrated the game with our readers.
Also, in the situation we had a double knock-out, kids were very picky on who was the winner in our last iteration in the case both castles were destroyed. We opted to include a mechanism to show the double knockout situation.

Prototype 6:

This push of this prototype was to increase the resolution of the feedback and add polish to our video game. We revamped the feel and the cardboard of the cannons once again. We increased the sliding mechanism of the cannons by using a food frame and had the tokens dispense from the side of the box. The feel of inserting the cannon ball into the holder felt much nicer as well. The feedback we received was that it felt like a slot machine.
The visualization of scoreboard was enhanced to emphasize the progression of the game. One frequent behavior we noticed was individuals looking to the screen to receive not only the audio feedback but some indication of what element they just placed. Our new scoreboarding mechanism includes a fade-out to indicate what was being played by the cannonball.

Physical development

Decision to Use RFID

Our choice to use playing cards reflected our desire for a game where players entered their decisions by some sort of unique physical action. Taking our observations, we expanded upon this vision and came up with several options for input devices. RFID, Reactivision, bar codes, and IR sensors were all likely candidates for the technical component of our game. Much discussion was spent exploring the pros and cons of each. RFID sat at the top of our list because of its reputed reading efficiency and speed but the high prices of RFID components and the lack of experience we had handling them discouraged us from its full use. Luckily, these challenges became non-issues when the CS247 instructors gave us 2 RFID readers and a bunch of tags to test and use; the technology proved easy to learn and surpassed our expectations in terms of performance.

Aesthetics and Metaphors

After concretizing most of the foundational game mechanics, we set about the task of finding a suitable metaphor that would clearly convey the game mechanics as well as highly appeal to kids. Additionally, the ideal metaphor should consist of familiar objects and actions that we could easily create and manipulate with our available hardware materials. Taking all these requirements into consideration, 3DE decided upon using medieval castles as the central game metaphor over such alternatives as race cars, musical instruments, and space colonies.
Now, even within the castle theme, there were many more decisions yet to be made. What other characters or objects can or must we entail? Dragons? Cannons? Charging knights? Wizards or other forces of magic? After much debate, we decided upon using a cannon visualization for a player's "firepower. " For one, it was most accommodating to what was available to us in terms of RFID readers and tags. We felt that "loading a cannon" reader with "cannonball" tags provided the most robust representation in light of other options such as feeding a dragon or casting spells with magic crystals. On a more practical standpoint, we deemed cannons and cannonballs the easiest option to draw, animate, and physically recreate.

Single-Screen Setup

After the testing of our paper prototype, we created a Javascript mockup of our game fully played on the computer. To not crowd players over the same laptop, we made the multiplayer version of this version support each player having an individual laptop. In two-player mode, two laptops were placed back-to-back and so during gameplay, players were facing each other and only able to see their own screen. This Battleship-esque setup, however, had some significant shortcomings. For one, players could not know their competitor's progress and so in this setup, their competitive nature remained the same throughout the game and then dwindled in the end. Furthermore, we observed players interacting and engaging predominantly with what the screen and not with their actual human competitor. To our dismay, there seemed to be little that differentiated this game play from that of a traditional one-player game.
After our fortunate procurement of RFID readers and tags, we only had time to implement a RFID-inclusive system for single-screen play for our second visit to East Palo Library. This granted 3DE an opportunity to test Professor Winograd's suggestion to deeply explore the pros and cons of different screen set-ups and how they impact the engagement and competitive levels of the players. With one RFID reader per player, we no longer had to worry about children fighting over sharing input mechanism. To our pleasant surprise, the kids exhibited greater competitiveness in single-screen play, motivated by awareness of their opponent "catching up" or "nearing victory". As a result, the game's pace and friendly competitive interactions between players increased.
Certain that we would use a single-screen setup, we sought to enhance the game play experience even more. Following Scott Snibbe's presentation on "Interactive Spaces for Learning," we decided that during actual gameplay, the game screen would be projected and enlarged to better engage and immerse children in the fun experience of learning math Castle Quest had to offer.

Cannons

On our first test with a RFID-inclusive game system, we discovered that children did not know how to interact with the technology. In this stage of Castle Quest's physical development, we had one laptop, a bunch of RFID tags, and two, bare RFID readers. We originally assumed that a quick swiping motion was intuitive but for many kids, but that was clearly not the case. Kids were unsure of where and for how to tap, slide, wave, etc. the tags onto the reader. This lead to many game complications. The game was significantly slowed because players had to pause and check if their tags was detected after each turn. Unwanted behavior also arose as players discovered they could easily win by holding on to the same tag and rapidly entering it into the system, transforming the game into one of dexterity and not math skills. Another big flaw we observed was that players had no instant feedback of whether their input was accepted or not, drastically slowing the game down. From these observations, we knew we needed to implement an instant feedback mechanism in the game as well as configure the RFID reader into a device that allowed only one, intuitive method of input and force players to play a new tag each turn.
With these thoughts and the central game metaphor in mind, 3DEs created two physical "cannons" out of cardboard boxes and duct tape. Though they were just boxes with a single input slot, a RFID reader slit, an internal slide to return played tags, and a mean looking cannon drawn on them, they produced amazing results and addressed all the physical gameplay issues observe in the previous visit. The main problems we did encounter was with construction of the contraption, such as it sliding away from players, losing the RFID signal, and unintentionally detecting tags.
For our next physical prototypes of Castle Quest, we bought some PVC pipes and created more realistic looking “cannons” that sat atop boxes that performed similar functions as our box prototypes. This was the version we presented in class on March 11th. Though the trial was successful, 3DE still saw much room for improvement. That night, we set about enhancing the external aesthetics and the internal mechanics of our “cannons.”
The final version of Castle Quest contains several important internal improvements. We moved the RFID readers farther away from the entry slot and created a Faraday's Cage around them to better maintain and direct their signals, addressing the issue of unwanted tag detection. Furthermore, we completely reconstructed the internal tag-returning slide mechanism. First, we constructed a brand new wooden slide mechanics to prevent tags from sliding too fast past the RFID reader and not getting read. Then, we rerouted the side so that played tags would automatically be re-dispensed out to the side of the cannon since the previous cannons occasionally burdened players by requiring them to tilt the entire cannon or reach into the output slot to retrieve the tags. All the internal mechanisms could be easily accessed and adjusted as we built doors into our new cannons.
Externally, 3DE built more realistically looking cannons based on a careful study of actual cannon images. We painted the cannon bases with colors that corresponded to the ones in the digital system and also decorated their side with wood-prints. Ultimately, what we created were fierce looking cannons that effective received players' decision in the form of tags, read and sent them to the central computer system to be processed, and then returned them to the player once finished.

Cannonballs

Throughout the user testing of our RFID-inclusive prototypes, we observed many kids struggling to pick up the thin card-shaped tags and knew we did not want to use these tags in the final version of our game. We explored the idea of using ping-pong ball stuffed with a tiny RFID tag and painted into cannonball for input pieces. However, while we knew they'd be easy to pick up, we ultimately decided against them because one, they would be difficult to maintain in a single, orderly place and second, the effort needed to attach them with tags in way that guaranteed they be read appeared to exceed the benefit they brought to game play. And so, we settled upon using the poker-chipped RFID tags as the final representation of our cannonball pieces. To make their representation of cannonballs more explicit, we designed and printed out cannonballs that were color and numerically labeled on sticker paper. Sticking them onto our RFID tags, it was clear which tags should be played with which cannon and how much they were valued.

We left very optimistic about Castle Quest as one kid commented that it, "...is the best game in the world."