Situating Programming Abstractions in a Constructionist Video Game

Research on the effectiveness of introductory programming environments often relies on post-test measures and attitudinal surveys to support its claims; but such instruments lack the ability to identify any explanatory mechanisms that can account for the results. This paper reports on a study designed to address this issue. Using Noss and Hoyles' constructs of webbing and situated abstractions, we analyze programming novices playing a program-to-play constructionist video game to identify how features of introductory programming languages, the environments in which they are situated, and the challenges learners work to accomplish, collectively affect novices' emerging understanding of programming concepts. Our analysis shows that novices develop the ability to use programming concepts by building on the suite of resources provided as they interact with the computational context of the learning environment. In taking this approach, we contribute to computer science education design literature by advancing our understanding of the relationship between rich, complex introductory programming environments and the learning experiences they promote.


Introduction
With the ever-growing landscape of introductory programming environments, an important, yet unanswered (or at least not sufficiently answered), question is that of the relationship between a programming tool and the understandings it promotes.Does a student writing a program in Logo develop the same understanding of conditional logic as a student working in Scratch?Does learning to program with Alice, Snap!, or starting off with "Hello World" in Java all result in the same understanding of the programming concepts used?To a veteran programmer, the answer might be yesa conditional statement is a conditional statement is a conditional statement; syntax might differ, but the underlying concept is constant.Studies investigating the affordances of different introductory programming tools often rely on direct comparisons between two environments; do students perform better on a post-test after they use environment A or environment B? (see for example [1]).While much can be learned with this approach, it does not yield insight into the questions we pose above.By relying on post-test measures, we learn the outcome, but are unable to identify any explanatory mechanisms that can account for the differences.Answering these questions requires a different methodology and a different set of theoretical constructs.In this paper we present a study designed to address this issue, focusing on one specific type of introductory programming environment: program-to-play constructions video games.The goal of this study is to answer two, interrelated research questions: (1) How are programming concepts encountered and used while playing a program-to-play constructionist video game? and (2) How do features of the game and the gameplay context contribute to a player's developing understanding of these programming concepts?Using Noss & Hoyles' [2] constructs of webbing and situated abstraction, we analyze programming novices playing RoboBuilder [3], a program-to-play constructionist video game of our own design, to answer these questions.

Literature Review
The idea that young learners should be taught to program, and that doing so has far reaching benefits, originated with the Logo Project [4], [5].Papert found that "when a child learns to program, the process of learning is transformed.It becomes more active and self-directed…The new knowledge is a source of power and is experienced as such from the moment it begins to form in the child's mind" [6, p. 21].This view was part of a larger vision of the transformative potential of computers to fundamentally changing how learning takes place.diSessa [7] argues that it is not just the act of programming, but also the medium, that promotes this new form of thinking: "Programs are not just analytic and a basis for reasoning.They are also synthetic.They can be run…Programming turns analysis into experience and allows a connection between analytic forms and their experiential implications" [7, p. 34].
Studying the process of learning to program begins with a programming language.For Papert it was Logo, for diSessa it was Boxer.Logo, Boxer, and other early languages designed for novices, such as Smalltalk [8], seeded an ever-growing tree of low-threshold, high-ceiling languages.New languages and environments brought with them new ideas and innovations for making programming accessible and empowering for younger learners.NetLogo [9] introduces learners to emergent phenomena through programming large numbers of agents, making it possible for novice programmers to explore the dynamics of complex systems.Scratch [10], using a graphical programming interface, allows users to construct programs with only a mouse and provides an online forum for learners to explore, share, and remix programs written by others.Programming tools like Tern [11] use physical manipulatives to make writing programs a hands-on activity.The computer science education community has also created and studied many introductory programming tools (for a review, see [12]).Across these and other introductory programming environments, a large body of literature has emerged chronicling the thinking and learning that takes place as they are used.Papert's early work with Logo focused on types of mathematical thinking that develop in young learners through working in computational settings, arguing for promoting heuristic concepts like problem simplification and debugging over mathematical formalisms and terminology [13].This work launched multiple avenues of study, including the development of mathematical meaning with Logo and other computational microworlds [2], [14], as well as the growth of programming practices like debugging and other general problem solving strategies [15].Low-threshold programming environments have also been used to study thinking and learning in other disciplines beyond math and computer science [16]- [18].It is also important to mention the effects constructionist programming environments have had on shifting attitudes and perception of programming among girls and other underrepresented populations [19], [20].

Constructionist, Program-to-Play Video Games
To study the relationship between the understanding that develops in learners and the programming language, environment, and activity, we use a program-to-play, constructionist video game [21].Constructionist video games bring central constructionist ideas (learner-directed exploration, personally meaningful constructions, emphasis on powerful ideas) to the video game design genre.Program-toplay video games are a specific form of constructionist video games that make the writing of programs the central activity of gameplay [22].We chose this type of environment as it provides a rich set of features for learners to leverage, including a blocks-based programming interface, a domain-specific programming language, a visual execution environment, and a familiar form of digital interaction.
Collectively these features provide a productive context for analyzing how design features of the environment affect novices' emerging understandings of programming concepts.RoboBuilder (Figure 1) is a program-to-play constructionist video game that challenges players to design and implement strategies to make their on-screen robot defeat a series of progressively more challenging opponents in one-on-one battle.To be successful, players must define instructions for their robot to locate and fire at their opponent while avoiding incoming fire; the first robot to make its opponent lose all of its energy wins.RoboBuilder's interface has two distinct components: a programming environment (right pane of Figure 1), where players define and implement their robot's strategy; and an animated robot battleground (left pane in Figure 1), where players watch their robot compete.Players first interact with the programming interface to define their robot's behaviors before launching the battleground screen.To program their robot, players are provided with a domain-specific, blocks-based programming language that includes basic robot actions, such as 'turn right' and 'fire!'.RoboBuilder is a component-oriented microworld that gives players the ability to "build and think in terms of objects that are close to their domain of interest" [23, p. 231].RoboBuilder builds on two open source projects: Robocode [24] and OpenBlocks [25].

Methods
The data in this paper were collected in hour-long RoboBuilder sessions during which programming novices played the game in the presence of a researcher.Sessions begin with the researcher introducing participants to the game, which includes describing the game objective and features of the language.The gameplay protocol follows a three-phase iterative cycle.First, participants are asked to verbally articulate their gameplay ideas and intentions.Next, participants work in the programming interface, constructing programs to carry out the ideas they just stated.The third phase of the protocol begins with the launching of a battle.As their robots compete, participants are asked to describe what they see their robot doing and whether or not it is behaving as expected.The end of the battle marks the completion of the cycle.The next iteration begins with participants explaining the next round of modifications or additions to their robot strategy they wish to carry out.This protocol is designed to elucidate players' developing understanding of programming concepts over the course of the interview.Twelve subjects were recruited to participate in this study.Older participants were recruited from a university in a large American city.High school-aged participants were recruited through their affiliation with a community center in the same city that serves a predominantly African-American, low SES community.

Theoretical Framework
The analytic lens we bring to this work is built on a pair of interrelated theoretical constructs.In their analysis of mathematical meaning making in interactive computational environments, Noss & Hoyles [2] developed the construct of webbing to capture the rich, diverse and interrelated features of constructionist environments that provide support to the leaner.Webbing describes "a structure that learners can draw upon and reconstruct for support -in ways that they choose as appropriate for their struggle to construct meaning" [2, p. 108].The construct of webbing is intended to capture the full network of supports provided to the learner, not just a single scaffold within the environment, allowing the designer to study the learning process as it emerges through the use of the features of the environment in concert, as opposed to elements used in isolation.Thus, researchers can remain faithful to the recognition that learning is not uniform across pupils, but is unique to the individual and provide a way for researchers to capture the nuance of the learner's activity within a rich computational context.
The second theoretical construct we use in our work provides a way move from the webbing of a specific interaction to the general concepts and practices of the domain of interest.The construct of a situated abstraction was developed in order to "afford a means to describe and validate an activity from a mathematical vantage point, without necessarily mapping it onto standard mathematical discourse" [26, p. 2].In interacting with computational learning environments "learners web their own knowledge and understandings by actions within the microworld, and simultaneously articulate and mesh fragments of that knowledge -abstracting within, not away from, the situation" [14, p. 228].Situated abstractions give us a way to both attend to the situated nature of the activity within the webbing of the environment, while also recognizing the ability of concepts to transcend contexts, and thus providing a way to link in situ activity with more general, abstract forms of conceptual knowledge.In bringing this lens to the analysis of a RoboBuilder, we can see how learners forge connections with the features of the tool and the computational meaning they carry, and interpret and ascribe meaning to this process.

Programming Abstractions in RoboBuilder
In this section, we present our analysis of the RoboBuilder sessions.We coded the sessions to see if and how participants encountered and used four specific programming concepts: object state, conditional logic, iterative logic, and flow of control.For each concept, we provide a brief example of a learner encountering it during gameplay, then report on its frequency across the full set of participants.
Building on the constructs of webbing and situated abstraction, we link the use of these concepts back to RoboBuilder's interface and the gameplay activity as part of the discussion for each concept.We coded for the use of the concepts throughout the construction process, including the planning, construction and evaluation phases of the interview protocol.We begin this section with a vignette to provide a sense of how components of RoboBuilder's webbing were appropriated to situate one learner's emerging understanding, then continue with our analysis of the four programming concepts.
The following interaction occurred early in Beth's interview, during her second battle against the level one opponent whose strategy is to remain motionless until its energy drops below 50, at which point it begins to move randomly.After seeing her opponent come to life during the first battle, Beth asks: In this exchange, we can see the invocation of two programming concepts to explain in-game behavior, and start to get a sense for how the webbing of the game helped situate their use.The two programming concepts Beth employs in this example are object state and conditional logic.Through her statement: "If you reach a certain health level" we can see both of the two concepts invoked.First is the recognition that robots have a health level, which is a value that serves to describe a characteristic of the robot (i.e.defines its state).Second, in starting her statement with "if" and then describing the consequences for a given condition being reached (attaining a certain health level), she uses conditional logic to explain how to create the observed behavior.Interestingly, Beth's explanation of how to use the programming blocks to create this behavior matches the actual program controlling her opponent.
A number of features of RoboBuilder contributed to Beth, a programming novice, being able to correctly employ these two programming concepts.First, the displaying of the available blocks in the programming interface provided a key resource in her using these programming constructs; she even refers to the blocks (what she refers to as "boxes") in her explanation.Second, Beth is describing the behavior of her opponent, not her own robot.Her being able to draw on opponent behaviors as a way to bootstrap her own understanding is a design strategy we have analyzed elsewhere [27] and constitutes another component of the webbing in which the concepts of conditional logic and object state were situated.A third critical aspect of the webbing Beth uses in this episode is the visual enactment of the battle.While Beth did have all of the blocks explained to her during her introduction to the game, from this quote, it is clear that the first, out-of-context, explanation of the blocks was not sufficient for her to understand their meaning.Her saying "so that's what the other boxes are for" followed by "I didn't understand that" highlights the difference between her being told what blocks do versus seeing their behaviors enacted during gameplay.This quote suggests that while she initially did not understand the utility of some of the blocks, through seeing them situated within the webbing of the game, their meaning emerged.Put another way, through the network of resources provided by RoboBuilder (its webbing), Beth was able to use the concepts of state and conditional logic to interpret game outcomes (i.e.situate these two programming abstractions).

Programming Concept: Object State
Object state is the knowledge that computational entities contain data in the form of property-value pairs that define the object at any given moment in time.In RoboBuilder, there are two types of object state we coded for: internal robot state, which pertains to information about the properties of the robot, such as its energy, heading, or speed, and battle-state, which captures the state of a robot during battle, such as being hit or seeing an opponent.In the vignette above, we saw Beth encounter object state as she thought through how her opponent used its energy level, a characteristic of its internal state.A second example of a novice attending to state can be seen early in Ruth's RoboBuilder session.In explaining a strategy for defeating her level one opponent she says: "In level one, the robot doesn't move much, so if you're already facing the robot and hitting it, then there is not point in moving more."By saying: "you're already facing the robot", she invokes one form of object state, describing her robot in terms of what direction it is facing.She continues by saying "and hitting it", describing the second type of object state present in RoboBuilder, that of her robot having successfully hit its opponent.Here, Ruth draws on the visual enactment of the battle, RoboBuilder's language, and the overarching game objective as part of the webbing in which to situate the concept of object state.

Programming Concept: Conditional Logic
Conditional logic builds on the previous concept to allow a player to introduce differential behaviors based on the state of the robot or the state of the game.Above, we saw Beth use conditional logic to explain the level one opponent's behavior.In coding for conditional logic, we looked for players proposing different outcomes based on state or explicitly referencing or using RoboBuilder's conditional logic blocks.Conditional logic was also used by players when thinking through strategies, as we can see in this quote from Allen:

Allen: While I'm shooting at the other robot, if he misses, I'm pretty sure he'll have to still shoot because I'm pretty sure the point of the game is to hit the other robot… If [my robot] does get hit, I guess he's probably too close to the other robot, so I might have to tell him move back… If he has higher energy than the other robot, let's say, he's probably 50 higher, I'd probably just tell him to get closer to the robot and just start shooting 'cause he's got energy to spare.
Here we see Allen laying out his robot's strategy as a series of conditional statements.In some cases, he depends on the battle-state to dictate his robot's behavior ("if he misses…"); in other cases Allen uses robot-state to inform his robot's behavior ("if he has higher energy…").For Allen, the video game context served as an important resource for him to situate his use of conditional logic -by drawing on the webbing of the game (the game objects, the nature of gameplay, the in-game objects themselves)he was able to articulate a potential robot strategy built around the concept of conditional logic.

Programming Concept: Iterative Logic
Iterative logic can be used to repeat commands either a fixed number of times or until a specified condition is met.In our analysis, this code was applied when participants referred to an iterative aspect of the game (such as an in-game event repeating) or when either of RoboBuilder's two iterative blocks (while and repeat) were used or discussed.We can see how the webbing of RoboBuilder supported the use of iterative logic and the situated nature of the in players in-the-moment understanding of it in how Joseph resolved the problem of his robot getting stuck against the wall of the battleground.When his robot hit a wall, he gave it the instructions: back 10 then turn right 30 forward 50.This caused his robot to hit the wall repeatedly, turning a little bit each time.Upon completion of the implementation of his solution, Joseph explained: "this way [my robot will] back up and kind of parallel park away…till he's not at the wall anymore."Here, Joseph devised a strategy that relied on iteratively running as many times as necessary to move his robot away from the wall.In comparing the maneuvering of his robot to the act of parking, he includes parallels between in-game and out-of-game events as part of the webbing he uses to build his understanding of the concept.

Programming Concept: Flow of Control
Flow of control captures the knowledge that programs are executed sequentially and serially.In analyzing the interviews, the flow of control code was applied when players discussed the execution order of blocks either within an event or across game events.In some cases, the concept of flow of control was confronted directly, including instances of participants systematically testing out the order of execution of the program by changing the order of blocks within their program then running it to see how the behavior changed.In other cases, players encountered flow of control by trying to understand how and when different events ran.For example, when Bram was trying to reason through his implementation of When I see a robot, he slowed down the execution of his program, focusing specifically on how his robot behaved after first spotting its opponent."So when [the When I see a Robot event] finishes, it moves up and does [the Run event]."Here we see Bram make a statement about how flow of control moves from one event to another, relying on the ability to slow down the speed at which his program executes to help him figure it out.Like with the other programming concepts, the visual execution, iterative nature of gameplay, and the ability to control the speed of program execution all contributed to the webbing in which he developed his understanding of the concept of flow of control.Table 2 shows the results of our coding the full set of interviews.Three things about this table are noteworthy.First, every participant encountered at least one programming concept during their session, with most participants encountering a majority of the concepts.Object state was observed in all 12 of the participants' interviews, while flow of control and conditional logic were both used at least once by a majority of participants.Iterative logic was the least frequently encountered concept of the four we coded for, but was still seen in half of the sessions.Participants encountered the coded-for programming concepts an average of 19 times during their hour-long RoboBuilder sessions.A second item of interest is the relatively high frequency of players employing the concept of object state.The central activity of controlling a robot, paired with the visual execution of the battle and the design of the protocol, facilitated players attending to the current state of the robot in terms of its position, energy, and the events that did (or could) occur during battle.We interpret this to mean that object state was more accessible and central to the gameplay activity than the other concepts and see it as evidence for how the design of a the environment and the webbing it provides can foreground certain concepts over others.Finally, these data show that as participants advanced in their schooling, the frequency of use of the concepts increased.Pre-university aged participants (rows 1-5) used an average of 13.4 concepts during their RoboBuilder session, while university aged participants (rows 6-12) used an average of just over 21 concepts.This seemed especially true for the iterative logic concept as only one of the preuniversity participants used it, while all but two of the older participants did.While these data do suggest a developmental trend for the use of programming concepts in a program-to-play game, as this was not the focus of the study, we hesitate to make any strong claims of a developmental nature and instead note it as a possible avenue for future research.

DISCUSSION
Programming concepts are often taught removed from a meaningful, authentic contexts, resulting in the observation that students know "the syntax and semantics of individual statements, but they do not know how to combine these features into valid programs" [28, p. 17].Research in the learning sciences shows that creating a meaningful context is important for learning [29], a finding replicated in the CS education literature [30], [31].In our constructionist, program-to-play game, learners encounter programming concepts situated within a context that provides a rich array of resources upon which learners can interpret and employ them.The language primitives developed meaning for the players through the iterative, construction process central to gameplay.Providing such webbed contexts aid in the meaning-making process, as "these meanings become reshaped as learners exploit the available tools to move the focus of their attention onto new objects and relationships" [2, p. 122].By having players express their ideas in the computational medium and then witness their expressed ideas enacted, the game context provides an opportunity for learners to interact with the programming concepts and develop an understanding of the computational behavior they embody.This promotes understandings of programming concepts that are built upon the webbing of the learning context, situated within the game play experience, and consistent with the abstract, transferable version that educators seek to teach.
In this study we used a video game context to introduce learners to programming concepts and study how the webbing it provided shaped the experience the learners had.There are a number of features of the game context that make it an effective medium for such a task including the expectation of challenges and early failures, a progression from easy to more difficult objectives, and the cultural syntonicity between programming and the computational nature of the video game medium.The rich, dynamic interactions of video games provide an array of potential scaffolds that collectively can serve as an effective webbing for situating programming abstractions that can be leveraged by a diverse range of learners based on their specific disposition, prior knowledge, and general approach to gameplay.It is important to note that using video games as a medium for introducing programming concepts to learners does have its drawbacks.For example, as most learners are familiar with video games, they come with expectations about video games that may not be desirable.As one participant put it: "[In RoboBuilder], you actually have to think, but like with other games you just sit there with the remote control and just play or whatever."The statement that most games do not require thought is not an ideal mindset for learners to have going into an educational experience.A second potential drawback for the game context is from potential repercussions if the game does not conform to players' expectations.One high school aged participant in our study decided to end his RoboBuilder session early, explaining that he was not a "computer gamer" and that he was more of a "systems person" (i.e.Play Station or Xbox).While this only happened once, it is important to be aware of the various ways learners might interpret and respond to the designed environment.

Conclusion
In this paper we showed how features of an introductory programming environment's language, design, and activity could inform and support how novices encounter and use programming concepts.Using a program-to-play constructionist video game, we analyzed when and how 12 programming novices encountered and used object state, conditional logic, iterative logic, and flow of control in order to accomplish in-game goals.Using Noss and Hoyles' [2] constructs of webbing and situated abstraction, we identified how specific components of the environment supported the use of programming concepts and tied the meaning making and abstraction processes to specific instances of gameplay.In taking this approach, we argue for the importance of evaluating an environment's full set of design features, along with the programing activity learners engage in, and the prior knowledge they bring to the experience, when studying novices learning to program, as they collectively contribute to the webbing within which learning occurs.This stands in contrast to approaches that rely solely on post-test comparisons as the primary analytic tool for such research.In bringing this lens to introductory programming experiences, we showed in more detail how learners experience programming concepts in a way that post-test analyses cannot.As the importance of programming grows, the question of how best to introduce novices to these concepts becomes more important.Building on work from the constructionist tradition, we showed how a detailed investigation of a single environment can advance our understanding of the way learners draw on the environment to make sense of these ideas in a way that complements the post test comparison approach.Combined, these methodologies paint a clearer picture and provide insights into designing new introductory programming tools to teach the next generation of programmers.

Table 1 . Information on the twelve participants included in this study.
Table 1 provides basic information about each participant's RoboBuilder session(s).