Sid made two points in his answers. The first point concerns his strategy for dealing with the different design components. He said about himself, "I start from the hard thing; then I just go through the small ones so I can work my way down." This more accurately describes the implementations of Sid's first two games in which he start programming the interactions and animations first. For his third and final game, however, Sid changed his strategy and designed his games as he went along. He said, "I get my ideas like . . . first, when I started the game, well I am just typing that stuff. I get ideas. So I just keep on doing." Sid's case emphasizes how both planning and bricolage can coexist in one person.
The size and complexity of the students' games by the end of the project raised the question of what kind of support for the process we can offer students. Albert's case provided one compelling example of how the growing complexity of his game created the need for structure in the form of LogoWriter page organization. A number of research efforts have been dedicated to helping software designers, especially beginners, deal with the complexity of their programs and to supporting them in their learning of proven design strategies ( Guzdial, 1993; Soloway, 1988). What is pertinent to most of these approaches is that they include features in their programming environments that have been deduced from observing expert programmers at work. The reasoning behind this approach is that beginning programmers need to learn these strategies in order to become experts. Analysis of experts' work habits and processes has shown that they make extensive use of these tools to organize their work more efficiently. Although many experts share common strategies and knowledge, they do not necessarily achieve their expertise in the same fashion. This raises the substantial issue that the support structures or "training wheels" are built into a design environment (e.g., libraries, prompts, or multiple linked representations) might not have their complement in the designer's learning process.
The important point about Albert's case was that he created the organization of LogoWriter pages himself. If we had provided him with this tool in advance, I do not think that he would have taken advantage of it. This structure developed in Albert's understanding through his involvement in the long-term programming process. His recognition of its usefulness represented one of the crucial learning moments in his learning history. Now, after the Game Design Project, Albert might be ready to work with different structures to help him organize his next project. Of further importance is the observation that even beginning programmers use a variety of approaches in dealing with their problems. Hence, I leave the issue of design support structure open, but it is important that the designers of future environments take the various approaches into consideration.
To place students in the role of game designers is to confront them with a complex task. One of the insights gained from this analysis is that there are