We have been working on designs for three classroom games as part of our
Gram's House story project. Each game teaches a different computer science principle, and has three different forms: an abstract game, a game with a fictional context, and a game with a complete story. We will eventually be comparing engagement and learning outcomes between the different versions, but for now we are focused on getting the game mechanics right. What follows is a summary of the three games so far and some of the design issues we have been running into.
Algorithms
The first game is about writing and performing algorithms. Our learning objective is that players should be able to both create and understand an algorithm of clear and concise directions to solve a simple problem.
First Iteration: Before the game begins, clue bags and decoys are hidden in the space the game will take place in (around a classroom, in a hallway, and so on). The bags will be placed inside of and underneath existing objects to require more complex instructions to find them. Two teams compete in a relay race. One player writes precise, step-by-step instructions to lay out three objects in a clue bag in precise positions on the floor. The next player follows the instructions. Another player writes instructions to find a location on a map inside the clue bag. A fourth player follows the instructions. A fifth player writes instructions to assemble individual parts in a clue bag into a completed object. A final players follows these instructions. Finally, players race to the finish line with their completed objects.
Design Issues: Because the teams are working on the same problems, they must be separated into two different locations. A proctor is required to determine whether algorithm performers have followed the steps correctly and whether the steps have lead to the correct outcome. Because teams are not in the same room, the facilitating instructor cannot proctor effectively, resulting in a player having to do it. Players are only active when they are reading or writing algorithms in their leg of the race, resulting in excess downtime.
Second Iteration: We are working on a cooperative version of the relay race that will reduce player downtime significantly. The race will be done with two teams in two rounds. For each team, two players will work together to write instructions, one player will be the algorithm reader, and the last player will be the algorithm performer. At the beginning of a round, writers will work together to plan their algorithms within a time limit. The non-writers on the first team will begin reading and performing their algorithm. After watching the first team for a short period of time, players on the second team will begin reading and performing their instructions. Writers will continue to refine their instructions after they are fully performed until the performers successfully complete the task.
Data Organization
The second game is centred on the principle of data organization. Our learning objective is that players should be able to recognize different ways to organize data, and see how the organization will affect data retrieval. For example, finding information in data that is unorganized requires a linear search, while a binary search can be used when the data is sorted.
First Iteration: Players are required to search a set of cards to find a specific data point. A deck of cards is arranged face down using a different organization each round. Each team draws a target card, and tries to find a card that matches the data on the target. Players can turn over one card at a time, check it, and turn it back down if it is not correct. There is a score penalty for each card checked. In the first round, cards are arranged randomly in a row, forcing players to search linearly or randomly. In the second round, cards are sorted according to the type of data being searched, allowing players to discover binary searching techniques. In the third and final round, cards are grouped into categories based on the data being searched (for example, the groups might be A-D, E-H, and so on).
Design Issues: Although there are points involved, the game feels more like an activity. Students have to observe the sorting order and determine how to make use of it, but there aren't any interesting choices to be made. The first round with randomly ordered cards makes it clear that unorganized data is difficult to search, but is unfair in a game setting; there is a risk of disengaging players.
Second Iteration: Our most recent idea for this game is unrefined, but holds some promise. The game involves dividing a communal set of objects with varying properties across multiple dimensions (something like cards, or buttons) into individual piles. Each player would get a target card that indicates the exact item in the pile she needs to find. Using one of a hand of action cards, players would modify the piles on the table. Her goal is to isolate the item she is looking for in a pile with only that item. This will hopefully lead into a discussion about how to arrange data once so that it is easy to find
any data.
Data Representation
Our final game shows players how images can be represented by computers. Our learning objective is that players should understand how images can be represented as numbers using different protocols. We also want players to understand the idea of compression using run-length encoding.
First iteration: Players will work on teams to transmit an image by encoding and decoding it in a relay. Before the game starts, players are asked to decide on a protocol they want to use during the game. In the first round, one team member takes a pixelated image and encodes it row by row by writing numbers according to the chosen protocol. The encoded version is taken to the next team member, who decodes the numbers back into an image within a time limit. The image is checked for accuracy. Players have an opportunity to discuss their protocols before repeating a second round using new images.
Design Issues: Players spend most of their time doing the rote activity of filling in their images or writing out the numbers. The only interesting choice is in making the protocol to encode images with, but the choice of protocol is constrained by the information already given. While some time is given to improve protocols between rounds, but there is little to no in-game motivation to try something new.
Second iteration: We wanted to maintain a clear connection between numbers and an image, but centre the gameplay on interacting with individual pixels. Our second iteration is for two players and is inspired by Battleship. Each player has an encoded black and white image that she keeps hidden from her opponent, and a publicly displayed grid of unknown pixels where the encoded image will be revealed as a regular image. How many pixels are black in each image is also public. Each player's goal is to reveal the image of the other player. On her turn, a player announces a pixel coordinate. Referring to their hidden encoded images, the other player either reveals the colour of the pixel at that coordinate, or reveal a run of all the pixels of the same colour starting at the coordinate.
---
We are play testing all of our games right now, though some are further along than others. In a future blog post, I'll share more details about the image representation game, since that is a design I have been working more closely with.
