These are the design challenges I came up with for the Design and Education course. Interesting stuff.
How do you make learning a language/literacy skill playful?
What are people going to learn? And why? What form will it take?
I intend to teach the fundamentals of multimedia programming to interface designers who have not had much exposure to programming. I will use a graphical programming language that guides players to build simple programs from a limited set of programming blocks. By doing this, players will gain an increased proficiency with programming skills and an increased sense of self-efficacy when approaching problems that require coding. It is hoped that this will enable the users to feel that they can pursue more difficult tasks on their own.
The game I will build is called Alien Pet Shop. The player is the chief mechanic of a funky store that sells unusual, customized pets to discerning customers. The mechanic's job is to build and expand the store's ordering system to allow for different kinds of requests. In the process of working on the store's machine, players will be introduced to important programming concepts suchs as variables, control structures, and functions.
Using the store as a metaphor for an interactive process, users will read the kind of inputs given to them by users. At first, the input will be very simple. Customers will ask for a specific type of pet, such as the "rudbud." The player will then set up a "plan" that will allow for a "type" request to come into the system.
After the request is in the system, the real work begins. The player will add a new "action" to the plan. The action will take the input and perform work to try and get the proper outcome.
The player can edit their actions to work with the kinds of requests that come through. For example, if the customer has asked for a "rudbud," then their action will simply be a condition that asks if the type equals "rudbud" and then returns that pet to the output.
As the player completes the simple challenges, different kinds of orders will start to come in. A customer might ask for a "red" pet. The player will then work with that input and return a set of new choices to the customer, based on which pets are red.
A further advancement will be customizable pets. A customer might ask for a "rudbud" with 5 legs instead of 3, which would require the player to set up a loop that can add legs to the pet based on the type and quantity requested.
By setting up increasingly challenging processes to manage the store, the player, as mechanic, will have to write more and more accommodating "code" to make the system work.
As they progress in complexity, they will see their work on the graphical code editor represented as an actual programming language in the code window. By showing the player multiple syntaxs, they will get used to the idea that the work they are doing in the graphical editor relates directly to the code produced in the code window.
A further advancement would encourage the player to start using the code window for complex scripts, and submitting the to the "machine." This would give the user their first taste of writing code, but would still keep the training wheels of the graphical system handy if they get stuck.
Take a look at the gallery.
The purpose of this game is for professional interface designers to gain an increased proficiency with programming skills and an increased sense of self-efficacy when approaching problems that require coding. From this starting point, it is hoped that students will feel they can advance farther in programming than they otherwise thought they could have.
The main movement in the game begins with a new challenge posed by the fictional clients. In the first few runs, the player is assisted by the Master Mechanic. The MM guides the player through the process of selecting inputs from the order, setting up the plan, and, most crucially, "writing" the code. The MM prompts the player through the early challenges and points the player toward the right tools from a limited set that represent actual coding concepts.
Once the plan is complete and the code has been written, the plan is run. The player can see how the code operates with the input as each step is highlighted as it gets executed (see below.) Then a new challenge is initiated. Eventually, the MM takes a long and well-deserved vacation and the player is left to handle the challenge based on what they've learned.
The model for this game is a highly-colorful alien pet shop. The palette for both the game pieces and the rest of the art is a saturated and contrasting, emphasizing fun and the odd funkiness of this futuristic enterprise. The game pieces themselves are large and block-like, and designed to suggest a pairing or an action without much additional prompting.
Taking a look at the attached PDF file (see bottom of this page,) the building of the code becomes apparent. The initial levels are guided by the Master Mechanic and prompts on the menu items, put the pieces themselves fit together consistently through the play of the game. In addition to explicit hints from the MM and implicit hints on the shapes, other elements appear the help guide likely pieces together, so that a user who drags an item around long enough will receive clues as the matching pieces near each other.
By using the simple set of cues, the player begins to see a fully formed program taking shape. This program is represented graphically in the main window, and takes more concrete shape in a side window in actual code that the player can grab, save, and manipulate more expertly as they progress in the game.
In the future, I want to focus on increasing the visual representation of what is happening, particularly in line with the machine/factory metaphor. By showing what actually happens as the pet is selected or constructed, it could reinforce important points along the "plan's" execution path. Increasing this tie to the central metaphor can help visual learners tie down the concepts to their own already sophisticated visual understanding.
Attachment | Size |
---|---|
model.pdf | 1010.04 KB |
Can you adapt an existing game to make it a focused teaching experience?
Children will learn about how animals forms and behaviors adapt them to their environments. Using Apples to Apples as a game, a rotating "judge" player will draw an animal card (just as the judge in A2A draws an adjective card). Other players will have, in their hands, traits of animals like color, climate preferences, mode of transport, diet, etc. Players will submit a trait that they think best matches the animal on the table. The judge will pick the traits he or she best thinks matches (maybe more than one, as opposed to one and only one in A2A). The animal and the traits are written down, possibly on a computer, for later discussion and comparison. As the rounds continue, players are encouraged, either on the worksheet on which the rounds are recorded or on the computer screen, to see which traits animals share in common, and start making inferences about similar creatures.
In addition to the inferences made about animals, each of the animal cards could be marked with brief descriptions that point to likely traits. Similarly, the trait cards could point toward animals that are more likely to possess them. This way, players wouldn't need to depend as much on prior knowledge and would be able to construct new knowledge within the confines of the game itself.
See attached desed2sketches.pdf for idea sketches.
The purpose of this game is to teach elementary school children about animals. Specifically, they will learn about how the animals are adapted to their environments by exploring these animals habitats, traits, and behaviors and finding commonalities with similar creatures.
The game follows the same progression as Apples to Apples, except that the dealer can pick multiple winners per round and the progress of the game is tracked on a worksheet.
Each player starts out with 5 trait cards. The stack of animal cards is picked up by the dealer and the top card is laid face up on the table.
Each player submits a trait they think is most appropriate. The dealer selects as many cards as he or she thinks matches the animal and writes them down on the worksheet.
A variation I want to test is switching trait and animal cards, so that players hold animals and traits appear in the dealer's deck. I also want to game how many cards a dealer can pick (unlimited, limited to 2 or 3, only one) and see how this affects the game flow.
The model for this project is similar in many ways to that of Apples to Apples. For testing purposes, an equal amount of trait and animal cards were prodeuced, making switching the focus of the game (from animal to trait) as simple as switching decks.
Two versions of the worksheet were also produced, each version reflecting a different possible focus on animals or traits.
Attachment | Size |
---|---|
desed2sketches.pdf | 458.1 KB |
desed2structure.pdf | 180.35 KB |
For my game, I originally modified Apples to Apples to work with animals and their behaviors and habitats. The very first play test of this occurred in class, with four of my classmates playing. As much fun as the original game was, though, play was slow and the learning features were a little clunky--recording the animals and their traits clogged up the game play.
The game I came up with after that, based on suggestions from that class, was more like dominoes, specifically the "Mexican Train" variation. The twist I put on it was faithful to my original educational goal of teaching kids about the lives and homes of animals. Each domino had a name and picture of an animal, and a set of four icons that depicted that animal's identity. The icons represented:
Players were asked to match three of the four traits on tiles on the table to a tile in their hands.
The next play test of the game happened in class with Becky, Laura, Albert, and I playing. I held the lead for a brief period, but Becky won in the end. There was a good consensus that the game was fun and playable--despite several players never having played any version of dominoes before, the rules were easy to explain and everyone picked it up very quickly.
I asked the following questions:
I did get a couple of correct responses from the group of players, but not everyone answered correctly or at all. This exposed one flaw in the game play--the animal identification can be missed if not emphasized properly in the play.
The next test I ran at home with just my wife, Kelcey, and me. I was interested in seeing if the game was still playable with only two people, which turned out to be just fine. I also emphasized, before play, that she should pay attention to the animals on the cards, and I made a point of mentioning the animals as I played.
In the end, Kelcey got two of the three questions after a little prompting, but there did still seem to be a weakness in that area. Some of the suggestions that came out of that play test were:
On the positive side, the game got raves for working with categorization tasks and simple playability. Such are the benefits of living with an educational psychologist.
When considering the game as it stands now, the following principles of James Gee come to mind:
I would argue that the Well-Ordered Play and Pleasantly Frustrating qualities are at the fore, mostly because of the greatness of the original game. Next, On-Demand Information is at work here rather nicely, with the dominoes holding compact and easily-readable data for players to use. This quality in turn benefits the Skills as Strategies characteristic by enabling players to easily convert their data into action. Finally come Co-Design and System Thinking, which work in tandem as players experiment with different pairings and branchings during the course of the game.
I think this game has a good amount of potential for playful learning. It may take a few rounds to pick up the lessons, and more could be done to clarify the game pieces and emphasize the animals. On the whole, though, it's a fun variation of a successful game.
Design a lecture or instructional piece for something missing from the MFADT curriculum.
My concept is to create an interactive "cookbook" that will allow Parsons MFADT students to explore, test, and create their own interactive or computational pieces using simple but powerful math fragments. The idea is threefold:
The purpose of the cookbook is to teach DT students about mathematical formulas that can help them achieve desired effects in their interactive and computational work. It should be a persistent and expanding resource for students to use as a reference and repository of collective associations between different math concepts.
The overall structure of the product is very similar to other community content sites, like the Python Cookbook or instructables. That is, there are individual pages that host particular pieces of information, say about the sine wave function or elasticity functions, that are linked together to form a whole corpus and are supplemented with user responses and other data.
More specifically, each page contains an interface that displays the function as line, in most cases, and shows an example, where applicable, of what that function would look like it it were placed in motion.
The page will also contain keywords that link to this page (as well as others), a list of similar pages (derived implicitly by automated analysis of the keyword linkages), a set of saved settings for the student and other users, so people could go back and explore their experiments, and a threaded list of comments, where users can post more about their experiences.
The pages would be linked together via a search page that allows users to search by keyword. The result of this search would be a graphical result page that would visually show the user what the relevant results looked like. The user could than navigate into the individual pages themselves and begin exploring.
Simple pause, play, rewind and fast-forward buttons would aid study of the function as motion.
Below the graphical display are a set of sliders and numerical readouts that would allow the user to modify useful parameters of the function in order to display different results. The function itself is prominently displayed next to the sliders and changes in response to alterations in the numbers. This provides a multiple-syntax approach to the learning--both the graphical and formulaic representations are provided for the student.
To the right are the keywords, similar pages, and saved settings of the user and others.