Children Programming Games: A Strategy for Measuring Computational Thinking

• In Event: Examining Computational Thinking in the Field

Abstract

Computer game programming is increasingly being introduced in K-12 grades, but despite its apparent potential to support learning, there is limited research to support this connection (Hayes & Games, 2008). Recent studies confirm that computer game programming is motivating (Basawapatna, Koh, & Repenning, 2010; Denner, Bean & Martinez, 2009) and increases girls’ perceived computer skills and perceived support for computing (Denner, 2007; Denner, 2011). But researchers are just beginning to explore what students learn.
In the current paper, we will describe our strategy and results of coding 238 games programmed by middle school students. The study took place in technology elective classes where students used the Alice 2.2 and Storytelling Alice programming environments to make games. Participants are primarily white and Latino/a, and there is a range of parental education. We developed two strategies for coding student games for computational thinking constructs.

The first coding scheme counts the details of programming constructs included in each game, which indicates the breadth of understanding of algorithmic thinking and abstraction (Denner, Werner, & Ortiz, under review). Categories include methods (a named sequence of contiguous instructions), functions (a named sequence of instructions that returns a value), and types of events (interruptive instructions). Coders indicate whether each construct was student-created, used, and has side effects under normal execution. Preliminary findings suggest that most middle school students create and use methods, they use functions but don’t create their own, and they use events to interrupt normal program execution and create interactivity.

The second coding scheme builds on the work of Koh et al. (2010) to identify computational thinking patterns. Patterns are collections of constructs that together form a higher-order construct. One pattern is collision, where the student uses a built-in proximity function to make something happen depending on program state (i.e., dog jumps when it gets close to a person). Another pattern is counters, where the student creates an integer variable, initializes it, and adds to that variable depending on program state. We also look for whether the student programs an action to occur if a threshold is reached. Findings to date suggest that students can create counters but most don’t complete the pattern with execution of a threshold action.

The coding took place in three steps: 1) examine the code to see what was included, 2) run the program to see if constructs were used successfully, and 3) search through code to determine whether code is student-created or involves use of built-in constructs. The data provide some important information about the potential of computer game programming for helping students to think and work in computational ways that prepare them to navigate and contribute to new technologies. Limitations are that the coding was tedious and in order to ensure accuracy, we required each student game to be coded by at least two people. The coding schemes may prove useful for other game programming classes that want to assess students’ higher order thinking, and the findings can be used to describe levels or stages of computational thinking.

Authors

• Jill Denner, Education, Training, and Research Associates

• Linda L. Werner, University of California - Santa Cruz

• Shannon Campe, ETR Associates