Bongo: A Kids’ Programming Environment
for Creating Video Games on the Web
Andrew B. Begel
Submitted to the Department of Electrical Engineering and Computer Science
in Partial Fulfillment of the Requirements for the Degree of
Master of Engineering in Electrical Engineering and Computer Science
at the Massachusetts Institute of Technology
May 23, 1997
Copyright 1997 Andrew B. Begel. All rights reserved.
The author hereby grants to M.I.T. permission to reproduce
distribute publicly paper and electronic copies of this thesis
and to grant others the right to do so.
Department of Electrical Engineering and Computer Science
May 23, 1997
Arthur C. Smith
Chairman, Department Committee on Graduate Theses
Bongo: A Kids’ Programming Environment
for Creating Video Games on the Web
Andrew B. Begel
Submitted to the Department of Electrical Engineering and Computer Science
May 23, 1997
In Partial Fulfillment of the Requirements for the Degree of
Master of Engineering in Electrical Engineering and Computer Science
In recent years, a growing number of researchers and educators have argued that design projects provide rich opportunities for learning. To support this type of learning, educational researchers have developed computational environments (such as Logo and LEGO/Logo) that enable children to design their own animated stories, simulations, and even robotic constructions. The rise of the Internet presents an opportunity for new types of design activities, enabling kids to create projects that reach a larger audience than ever before. Some kids are beginning to create their own home pages on the World Wide Web. With the Java programming language, people can now create increasingly sophisticated Web pages with dynamic, interactive content. But Java is intended for expert programmers, not children. This thesis describes a new programming language and environment called Bongo that brings the power of Java to kids. In particular, it discusses a construction kit written in Bongo that enables kids to build their own video games, and to share those games with others on the Web.
Thesis Supervisor: Mitchel Resnick
Title: Associate Professor, MIT Media Laboratory
There are so many people to thank and acknowledge for all of their support and help that they have given over the past four years. I’d like to thank Mitchel Resnick, my advisor, for four wonderful years at the Media Lab. Ever since I joined the group as a UROP working on StarLogo, my academic life has been shaped by his research. As I move on, his work will continue to have a lasting influence on my life. Brian Silverman has been my programming partner for three years and has been a great source of inspiration, clever ideas and a youthful spirit. I couldn’t have done any of this without you, Brian, and I hope we’ll keep working together in the future.
I’d like to thank Amy Bruckman, my next door office neighbor, for her valuable commentary on my thesis and all of my work at the lab. I admire Amy because she knows how to believe in herself and offer a little bit of that feeling to everyone she knows. I’d also like to thank Fred Martin for four great years of fun and toys. You’ve created the gadgets that inspired a lot of my work. You were also a great help refining my ideas for this thesis. I’d like to thank Marina Umaschi for her large collection of useful papers and for being a great sounding board for the ideas in this thesis. Thank you to Vanessa Stevens and Rick Borovoy for always being around to answer my questions and always helping out with all of my research. Thanks to Kwin Kramer for all of your technical knowledge. I’m impressed with the progress you’ve made over the past year, and yes, I like your new computational beads. Really. Thank you to Paula Hooper, Aaron Brandes, David Shaffer, Mike Travers, and David Cavallo for listening and answering my random questions for the past few years. Florence Williams, with her quick wit, gave me a smile every time I saw her. That, and a little bit of work to do.
I’d like to thank David Feinberg and Carlos Mochon, my good friends and faithful StarLogo UROPs. You guys provided the inspiration for this thesis with your imaginative work in StarLogo. (I told you it couldn’t crash, and you had to prove me wrong...) I’d also like to thank the UROPs whom I’ve worked with for the past four years: Austina Vainius, Trevor Stricker, Steven Tamm, Drew Samnick, Adam Skwersky, Isaac Persley, Ilya Kaplun, Micah Gutman, and Steve Shapiro. You guys have been great friends and labmates.
Thanks to my mother and father who’ve supported me in all of my endeavors for the past five years of MIT (and survived my switch from Chemistry to Computer Science). You have always been patient with me while I talk on and on about computers.
I also have to thank all of the members of my fraternity, Alpha Epsilon Pi, who for the past five years were my best friends and confidants. You guys always listened to my random comments and unnatural affinity for school. You helped me grow from a shy 18-year old into the loud, talkative, expressive 23-year old that you see today. Thank you for everything.
Table of Contents
2. Motivation.................................................................................... 7
2.1 Why Construction Kits?................................................................................................... 7
2.2 Why Games?..................................................................................................................... 7
2.3 Why Network?................................................................................................................. 7
3. Related Computational Construction Kits................................. 7
3.1 General-purpose Construction Kits.................................................................................. 7
3.1.1 Logo........................................................................................................................... 7
184.108.40.206 Variants of Logo...................................................................................................... 7
3.1.2 Boxer.......................................................................................................................... 7
3.1.3 Agentsheets................................................................................................................. 7
3.1.4 Cocoa (Kidsim)............................................................................................................ 7
3.2 Construction Games........................................................................................................ 7
3.2.1 Rocky’s Boots............................................................................................................... 7
3.2.2 Robot Odyssey.............................................................................................................. 7
3.2.3 The Incredible Machine................................................................................................ 7
3.2.4 Widget Workshop.......................................................................................................... 7
3.3 Video Games..................................................................................................................... 7
3.3.1 Pinball Construction Set................................................................................................ 7
3.3.2 Klik & Play / The Game Factory..................................................................................... 7
4. Design Space of Video Game Construction Kits........................... 7
4.1 Design Principles of Construction Kits............................................................................. 7
4.1.1 Understandability......................................................................................................... 7
4.1.2 Uniformity and Elegance................................................................................................ 7
4.1.3 Interactivity................................................................................................................. 7
4.1.4 Functionality............................................................................................................... 7
4.1.5 Transparency............................................................................................................... 7
4.1.6 Powerful Ideas............................................................................................................. 7
4.1.7 Reflection and Audience................................................................................................ 7
4.2 Design Issues for Video Game Construction Kits............................................................... 7
4.2.1 Game Construction....................................................................................................... 7
220.127.116.11 One Constructor or Collaborative Construction?.............................................................. 7
18.104.22.168 Construction Kit Examples......................................................................................... 7
4.2.2 Programming Environment.............................................................................................. 7
22.214.171.124 What can you make with it?......................................................................................... 7
126.96.36.199 Interpreted or Compiled............................................................................................. 7
188.8.131.52 Direct Manipulation.................................................................................................. 7
184.108.40.206 Abstraction............................................................................................................ 7
220.127.116.11 Debugging............................................................................................................. 7
4.2.3 Programming Language.................................................................................................. 7
18.104.22.168 Models of Computation............................................................................................. 7
22.214.171.124 Graphical or Textual Programming?.............................................................................. 7
126.96.36.199 Data Flow or Instruction Flow?.................................................................................... 7
188.8.131.52 Object-Oriented Programming..................................................................................... 7
4.2.4 Game Structure............................................................................................................ 7
184.108.40.206 What Kind of Video Game?.......................................................................................... 7
220.127.116.11 Storyboarding or Instant Play?.................................................................................... 7
18.104.22.168 One Player or Many Players?....................................................................................... 7
22.214.171.124 Environmental Events............................................................................................... 7
5. Bongo: Video Game Construction Kit........................................... 7
5.1 Overview......................................................................................................................... 7
5.2 Design.............................................................................................................................. 7
5.3 Programming Language................................................................................................... 7
5.4 Implementation................................................................................................................ 7
5.4.1 Bongo: Logo for Java...................................................................................................... 7
5.5 Space Invaders Walkthrough.......................................................................................... 7
5.5.1 Conception of the Game................................................................................................. 7
5.5.2 Breed Creation............................................................................................................. 7
5.5.3 Character Creation....................................................................................................... 7
5.5.4 Wrapping it Up............................................................................................................. 7
5.5.5 Play the Game!............................................................................................................. 7
5.6 Discussion........................................................................................................................ 7
6. Conclusion.................................................................................... 7
7. Bibliography................................................................................. 7
List of Figures
Figure 1: Preliminary Breed Editor....................................................................................... 7
Figure 2: Video Game Playing Field...................................................................................... 7
Figure 3: Video Game Command Center................................................................................. 7
Figure 4: Space Invaders game running inside Netscape.......................................................... 7
In recent years, a growing number of researchers and educators have argued that design projects provide rich opportunities for learning. To support this type of learning, educational researchers have developed computational environments (such as Logo and LEGO/Logo) that enable children to design their own animated stories, simulations, and even robotic constructions.
The rise of the Internet presents an opportunity for new types of design activities, enabling kids to create projects that reach a larger audience than ever before. Some kids are beginning to create their own home pages on the World Wide Web. With the Java programming language, people can now create increasingly sophisticated Web pages with dynamic, interactive content. But Java is intended for expert programmers, not children. This thesis describes a new programming language and environment called Bongo that brings the power of Java to kids. In particular, it discusses a construction kit written in Bongo that enables kids to build their own video games, and to share those games with others on the Web.
This section will introduce the educational motivations for the creation of design activities for children. In the Epistemology and Learning Group at the MIT Media Laboratory, there has always been a strong emphasis on children as designers of their own projects. This group develops new technological tools for learning. Constructionism, developed by Seymour Papert, is the guiding philosophy for this research (Papert, 1980, 1993, 1996). Constructionism describes both a theory of learning and a strategy for education. As a theory, constructionism is based on the constructivist theories of Jean Piaget, the Swiss psychologist who studied learning in young children. Piaget argued that children construct their own knowledge during learning; knowledge is not simply transferred from one person to another. Papert expands on this idea by stating that one particularly good way to construct new knowledge is to construct tangible objects that a child can reflect upon and share with others (Kafai and Resnick, 1996).
In this chapter, I will explore several underlying motivations for enabling kids to build their own games on the Internet. “Why Construction Kits?” makes the argument that construction kits are important to provide design opportunities for children. “Why Games?” argues that games are in the “kid culture” and are personally meaningful to children. Finally, “Why Network?” discusses what advantages and prospects the Internet can bring to construction kits and game media.
Since construction is an important activity, getting children engaged in design activities is a good idea. A growing number of researchers have stated that design activities provide great opportunities for learning. Mitchel Resnick and Natalie Rusk, co-founders of the Computer Clubhouse in Boston (Resnick and Rusk, 1996), have compiled a list of reasons for this interest in design-oriented learning:
·Design activities engage youth as active participants, giving them a greater sense of control (and responsibility) over the learning process, in contrast to traditional school activities in which teachers aim to “transmit” new information to the students.
·Design activities encourage creative problem solving avoiding the right vs. wrong dichotomy prevalent in most school mathematics and science activities, suggesting instead that multiple strategies and solutions are possible.
·Design activities can facilitate personal connections to knowledge, since designers often develop a special sense of ownership (and caring) for the products (and ideas) that they design.
·Design activities are often interdisciplinary, bringing together concepts from the arts, mathematics, and sciences.
·Design activities promote a sense of audience, encouraging youth to consider how other people will use and react to the products they create.
·Design activities provide a context for reflection and discussion, enabling youth to gain a deeper understanding of the ideas underlying hands-on activities.
Other educational researchers have explored different aspects of design activities. Idit Harel engaged elementary school students in creating their own educational projects to teach fractions to other school children (Harel, 1990). Gerhard Fischer has been studying how computational environments can support transparent design, where the users notice only the problems they must solve, and not the computational framework around them (Fischer and Lemke, 1987-88, Fischer, 1993). Mitchel Resnick created StarLogo to encourage a new type of “decentralized” mindset to enable kids to learn about and model complex systems (Resnick, 1994). Alex Repenning has studied how children program and has been developing new graphical techniques to lower the threshold for programming (Repenning, 1994, 1995, 1996).
If it is good for kids to engage in design activities, then we should provide them with good construction kits. There have been several different types of “computational construction kits” developed by researchers for design activities. One of the earliest and most popular was Logo. Logo enabled kids to teach a robot-like turtle how to do simple tasks. They could use the turtle to explore mathematics, geometry, and more recently, storytelling, animation, and games.
Other researchers have chosen to explore constructionist environments where the focus was not on the computer screen, but in the physical world. One such environment was LEGO/Logo. This activity combined multiple types of design, using LEGO blocks as a mechanical design tool and Logo programming as a software design tool (Resnick, et. al, 1996). This combination allowed children to make mechanical creatures and endow them with behaviors, such as a paranoid robotic car that ran away from light, or a social ant that liked to dance with other bugs (Braitenberg, 1984). The 6.270 Robot Design Contest at MIT grew out of this work. Students created robots out of LEGO and programmed them to solve a series of tasks autonomously. Fred Martin, one of the contest’s designers, wanted to explore how MIT engineering students thought about the process of design and implementation, and how much they could balance real-world problems with idealistic designs (Martin, 1994).
No matter which generation you are in, playing games is an integral part of childhood. Growing up, I was involved in nursery school games like tag and leapfrog. Once I entered elementary school I started playing soccer and baseball. These games held my interest for awhile, but I sensed that organized sports weren’t for me and eventually dropped out by sixth grade.
There was one type of game that I started playing and haven’t yet stopped—video games. When I was 9, our family got an Atari 2600. We played Space Invaders and Combat and Street Racer. I had a lot of fun down in the basement with my brother and sister, daring them to score more points than me. One month, my dad surprised us and got Pac Man. This was supposed to be the most amazing game out at the time. But my dad wouldn’t let me play it until I learned how to ride my bike without training wheels. I tried and I tried, but I couldn’t get over my fear of falling down. My brother and sister were having the best time playing Pac Man. They played it almost everyday. I think they did it just to get to me. Well, it did, so one day I took my bike out of the garage, brought it to the street and rode down the block without my training wheels. I went straight to my parents, told them what I had done, and stormed right downstairs to play my first game of Pac Man. I’m not sure of which event I was more proud, riding my bike or playing Pac Man.
Video games are in today’s “kid culture” (Jenkins, 1993). This game culture started out with games like Space Invaders and Pac Man, but has quickly progressed to Super Mario Bros., Doom and the current favorite, Diablo. Children love to play games. They have a deep connection to them because the games transport them to a fantasy world where they can discover unexplored territory, take their hero on a quest to save the princess, and shut out all other distractions (including their parents). Kids also like to talk about games with other children. They trade gaming hints, like where all the secret doors are, and reflect on gaming strategies, such as what order to solve the puzzles of a game in, or which pattern of moves will enable you to get the most points in Street Fighter.
Since games are so much in the culture, we should harness them to constructionism. There have been many building games, like Rocky’s Boots and The Incredible Machine, that allow kids to build contraptions to solve puzzles. But these games only allow children to explore the design space which the authors allow. Why not give kids the opportunity to design and create their own games? If we give them good construction tools, then they could not only be creating something personally meaningful, but they also would be connecting to math, science, programming and other important domains of knowledge.
Over the years, several researchers have created new types of environments to explore the constructionist approach to video games. For example, Yasmin Kafai investigated ways in which children at Hennigan Elementary School in inner-city Boston could use Logo to make educational video games to teach younger kids about the solar system. These games triggered the children’s interest because they were not perceived as boring schoolwork, but as fun projects in which they actually could learn about science and teach others about it, too (Kafai, 1993).
At the end of the year, Kafai’s kids’ projects were presented to the parents at a game fair. Children took their parents on a walkthrough, showing them all of the interesting things that one could learn about the solar system. However, it would have been better if it were easy to publish these games, so that anyone could try them. Anyone would be able to give the children feedback about their games and offer suggestions for improvements.
The rise of the Internet presents this opportunity, enabling kids to create projects that reach a much larger audience than ever before. Several educational researchers have created “communities of learners” on the Internet, where school children collaborate on problem-solving activities and experiments. Scardamalia and Bereiter have looked at “knowledge building communities” and how learning in groups changes and distributes the acquisition of knowledge (Scardamalia and Bereiter, 1994). Songer studied children working together to use the Internet as a medium for engaging in science activities (Songer, 1996).
Other researchers have concentrated on making the Internet into a place where children can collaborate together to construct personally meaningful objects. Amy Bruckman created a virtual world, or MUD, where kids can congregate, socialize and actively create and design their environment (Bruckman, 1997). Children on MOOSE Crossing can create their own objects. For example, one girl’s pet penguin object won’t eat shrimp when it’s on a diet. This object interacts with its environment and with other members of the MOOSE community. This constructionist community of designers forms the basis for a type of learning that accelerates kids’ understanding of programming. Everyone in the community has a common focus, creating new objects, and helps one another by sharing programming skills and assisting less-experienced users.
A sense of community can also be found on the World Wide Web. The Web's introduction several years ago created a global audience that can browse what designers create. The Web has given everybody the ability to design web pages, where they can explain who they are, show a picture of what they look like and share their favorite links. The web’s architecture also encourages children to build on each other’s work. Every browser supports “view source,” where kids can find out how the author wrote their web page.
Up until now, however, further opportunities for design have been constrained by the static nature of the Web’s content. Java, a new Internet language designed by Sun Microsystems, has opened the door toward richer dynamic content on the Web. Using Java, a person may create a simulation, an animation or even an interactive video game. But there is a problem. Java is intended only for expert programmers. This thesis extends Java by creating the Bongo programming language, so that kids can gain access to a constructionist design environment on the Web. Earlier projects have shown that video games can be an exciting design and learning domain. This thesis presents the design and implementation of a video game construction kit, a tool that enables kids to easily design and implement video games to share with others on the WWW.
This chapter discusses several different types of computational construction kits. By no means a complete listing, this selection of examples is presented here to illustrate various design considerations that other researchers have taken in their research.
The first section, “General-purpose Construction Kits,” discusses Logo, Boxer, Agentsheets, and Cocoa and illustrates how these kits have been used with children, and advantages and disadvantages to each of their approaches to learning. The second section, “Construction Games,” introduces several games that use a construction metaphor to engage children in design. Rocky’s Boots, Robot Odyssey, The Incredible Machine, and Widget Workshop are all widely varying examples of construction games that have been popular with kids in the past. The last section, “Video Games,” specifically talks about video game construction kits and how these kits approach the task of enabling children to easily create their own video games.
Logo, designed in the 1960’s, was one of the first programming languages created for children. A team of researchers at BBN and MIT, including Seymour Papert and Wally Feurzeig, created this variant of Lisp to meet specific design goals. They wanted to make Lisp more accessible to non-programmers, especially children. They achieved this in several ways. First, they simplified Lisp’s syntax, removing parentheses, reducing the number of syntactic forms and shrinking the primitive sets. They did, however, keep Lisp’s dynamically-scoped, procedural semantics.
Another approach to enhance Logo’s understandability was to leverage it off natural language. Whenever a child tried to ask Logo to do something it didn’t understand, Logo would respond, “I don’t know how to do that.” Children could then teach the Logo interpreter how to do different tasks by saying “to make-a-square” and writing a procedure that told the computer how to make a square.
One of the overall results of Logo was that its accessibility provided a gateway through which children could reach many different problem domains where interesting questions lay. In the programming domain itself, children might discover recursion as a way to tell a procedure to repeat over and over again. They could learn new debugging skills when the computer executed a procedure differently than they had thought it would. They could also actively explore the Logo environment by interacting through a command center. Here, they could try out new commands and receive instant feedback about what they did. This helped immensely in debugging efforts, since children could try procedures with many different inputs to understand its complete behavior.
Outside of the programming domain, the introduction of the Logo Turtle (Papert, 1980) allowed kids to reach “Mathland.” Mathland was a metaphor for a place where children could use math as fluently as they used language. The Logo Turtle enabled children to think about mathematics and geometry using body syntonics. Children could envision themselves as the turtle, moving around on the ground to draw geometrical figures. This enabled children to think about computational geometry, instead of the more traditional Euclidean or Aristotelian geometry.
Logo became very popular in elementary schools, and with the help of Mindstorms (Papert, 1980), Turtle Geometry (Abelson and diSessa, 1986), and other educational books, many people thought that the children would easily make it to Mathland. Unfortunately, for all of the powerful ideas that Logo might help children to reach, it didn’t achieve the epistemological success that Papert sought. This was due to several problems: the inertia of the school system to resist change, the paucity of computers in schools, and the tendency of teachers to lecture to children, instead of letting them learn on their own. Others thought that some problems were due to Logo itself, rather than how it was deployed and used. They thought that Logo was too low-level and that domain-specific tools might be better to engage kids in learning (O’Shea, in press).
Since the 1960’s, the Logo turtle has been used in many different types of Logo programming environments, including moving from robotic form to screen form in the very popular Apple Logo, written by LCSI (Logo Computer Systems Inc). For many years, Apple Logo was used in elementary schools to teach geometry and math. In the mid 1980’s, LCSI introduced Logo Writer. This version opened up the design space further by adding turtle shapes and multiple turtles. Children could assign turtles different shapes and create stories using the new characters they made. Kids could also create video games, for example, by using a turtle for the enemy, a turtle for the hero and some turtles for the bullets.
At this point in Logo’s history, the technology could not yet match the kids’ expectations. Some of Kafai's students would come to school with grandiose plans about what they would work on that day, but then run up against technological limitations in Logo Writer. Kids wanted more turtles so they could have more than four characters at a time. There was also no multi-threading, so it was not easy to tell all of the turtles to do different things at the same time (Kafai, 1993).
The next Logo by LCSI was MicroWorlds. This version, introduced in 1992, included support for modern computer features like multimedia, sprite animation, sounds, movies, and paint tools. It introduced multiple processes, so kids could more easily program turtles independently and not worry about managing multi-threaded program flow.
MicroWorlds’ use of multiple processes was inspired by MultiLogo and StarLogo, both created by Mitchel Resnick (Resnick, 1991, 1994). StarLogo, written for the Connection Machine 2 parallel computer, added many more turtles to the Logo canvas. Users could have up to 16,000 turtles, instead of merely one or two. It opened up a whole new design space where children could model ant colonies, flocks of birds, or even create ideal gas molecular simulations. StarLogo suffered from one disadvantage, however. CM2s cost about one million dollars, so anyone who wanted to use StarLogo had to come to MIT.
In order to alleviate the access problem, StarLogo was ported to the Macintosh. A very lightweight process switcher enabled the serial processor of the Macintosh to emulate the 16,384 processors of the Connection Machine. A SPMD architecture (single program, multiple data: many turtles each running one program, but each with their own program counter) was also adopted. This provided an advantage over the SIMD model of computation (single instruction multiple data: many turtles, each running one program in sync) on the CM2 because now each turtle was now free to run separate pieces of code at the same time. The move to the Macintosh also enabled the addition of extra graphics and user interface features that were impossible on the CM2, such as sprites, paint tools and an interface builder.
The sprite graphics, combined with breeds, a turtle grouping feature, turned out to be an interesting addition to StarLogo, that allowed users to more easily identify with the simulations they were creating. During the summer of 1996, MIT undergraduates David Feinberg and Carlos Mochon used StarLogo to recreate two classic video games, Pacman and Frogger. The games looked and felt just like the originals and were fun to play. They were also unexpectedly easy to program. These video games were the inspiration for the work described in this thesis.
Boxer is a unique programming environment that embodies the ideals of Logo, Lisp and Smalltalk (diSessa and Abelson, 1986). Invented by Andy diSessa and Hal Abelson, it explores the transformation of Logo from a procedural text-based environment into an object-oriented hybrid graphical-textual environment.
Before the 80’s, Logo never really concentrated on the programming environment in which the children created their projects. At best, children could hope for a split screen approach, where they could see the turtle or the procedures, but never both at the same time. Boxer, in the Smalltalk tradition, integrated the procedures page with the graphics page and created a multimedia graphical approach to programming. Boxer actually foreshadowed the World Wide Web and document-based computing because it turned all data, including multimedia, into first-class manipulable objects on the screen.
Boxer’s basic building block is the box. Boxes can contain programs, data, text, pictures, and even other boxes (thereby supporting hierarchical structures and abstraction). Boxer’s display of its collapsible boxes (which visually indicate black boxing) “encourage programmers to interpret the organization of the computational system in terms of spatial relationships” (diSessa and Abelson, 1986). Children can also analyze dynamic program flow by employing the “Little Man” explanation of structural programming. Whenever a procedure calls another one, it appears as a box inside the first procedure call. When that procedure is finished, the box collapses and the original procedure regains control (diSessa, 1986).
Agentsheets is a visual programming construction kit created by Alex Repenning at the University of Colorado (Repenning, 1994). The first version of Agentsheets used a purely graphical approach to programming agents (similar to Logo turtles) that occupy cells in a grid. Using graphical rewrite rules to illustrate transitions from one picture state to the next, the agents can be programmed to move around the grid and interact with each other. This model of computation is very similar to the Turing machine model. But, like the Turing model, it suffers from an exponential rule growth.
Repenning writes that programming via graphical manipulation lowers the threshold for beginning programmers, especially kids. He has also experimented with a form of physical programming involving a robot and LEGO road base plates. Children programmed the car to always stay on the road, and could meta-program the robot by putting different road plates in front of it. This way they could make the robot go anywhere they wanted without ever typing a single command (Eden, et. al. 1996).
Recently, with the development of Visual Agentalk, Repenning has shifted his model of programming from graphical rewrite rules to a more programmable, direct manipulation approach (Repenning and Ambach, 1996a,b). Using command and sensor blocks in a stimulus-response framework, programmers can create behaviors using parameterized blocks. This alleviates much of the problem with the explosion of rules because it raises the abstraction level of programming above the Turing model. In addition, the user can try out commands or stimulus-response rules directly by dragging them on top of the agents. This allows the user to test and debug commands and rules interactively while programming.
Cocoa, a product from Apple Computer, is similar to the first version of Agentsheets. Created by Alan Cypher and David Smith, Cocoa’s programming style is an extreme experiment in pure graphical rewrite rule programming (Smith, Cypher, Spohrer, 1994). Intended as an introduction to programming for young children, kids can create their own simple projects by defining characters from a palette and placing them on a playfield. Similar to Agentsheets, the children can define transitions between before and after graphics to control the characters on the field.
Cocoa suffers from the same exponential blowup of rules as Agentsheets, but the designers feel that the increased usability and understandability of the simple rules allow children to more easily express themselves. Rather than working to raise Cocoa’s ceiling, they feel that adding more modalities and breadth of I/O to Cocoa is a better way to entice more children to program. (Cypher, 1996)
Apple has invested quite a bit of time and money into the background support of Cocoa. They recently introduced a Cocoa plug-in for Netscape, which allows kids to play their games (but not create them) on the Web. Apple also maintains a web site that allows kids to publish their projects and even participate in a best game contest. This web site is an important step in widening the audience for kids’ projects. Prior to the Web, children could create projects, but could only show them off to their friends in the same room. With the Web, however, children can publish their projects to a much wider audience and enjoy the benefits of this new interaction.
There were a number of games introduced in the early 1980’s that incorporated the construction kit metaphor in the activity itself. Rocky’s Boots, designed by Warren Robinett, allowed kids to learn logic and circuit design by constructing digital circuits. Each level of the game had challenging problems where children would wire up block sensors to various types of digital gates in order to recognize and “boot” a certain pattern of blocks. For example, if there were six blocks on the screen, and you were instructed to “boot” the red triangles, you could connect up a triangle shape sensor and a red color sensor to an AND gate which would then connect to the Boot. Whenever the sensors were both triggered by the red triangles, the Boot would kick the block out of the way and you would earn some points. There were also more complex sequence problems such as recognizing a red triangle only after seeing a blue square.
A graphical programming approach was used in this environment, as well as an electric data flow model. Similar to Widget Workshop (which is a much more recent game and is described below), children could connect wires between various logic gates and flip-flops in order to create a circuit. The kit had some facilities to aid debugging these circuits. When the power was turned on, you could watch the action of your digital circuit as the current flowed through the machine. You could also turn a dial to control the speed of the electric flow. Rocky’s Boots contained different rooms in its world where you could quickly try out different circuit combinations. It was also a modifiable environment. Children could build their own variants of Rocky’s Boots games and challenge their friends with difficult sequences of blocks.
Robot Odyssey, a game from the Learning Company, followed in Rocky’s Boots footsteps. It continued the use of the electric data flow model, but applied it to a robot’s brain. Children could program a robot to move around and interact with objects in a virtual world on the computer screen. Inside the robot’s head were a variety of sensors and actuators that could be wired together through logic gates, flip-flops and IC’s. To make a robot that followed the wall, a child would wire the left wall bumper to the right and rear thruster, thus keeping the robot against the wall and moving it forward at the same time.
Robot Odyssey also used a graphical environment, but expanded on the spatial metaphor by constructing an elaborate virtual world with puzzles to solve in every room. The child could try out a variety of robots in each room and test different circuits to see which would work the best. The instruction manual included with the game also gave quite a few example challenge problems. These ranged from wall-following to finding a key in a maze of stairways.
While the environment supported active exploration of various circuit ideas, it wasn’t easy to create a circuit that would work. This problem isn’t particular to this game, however; it is a problem that plagues robot designers to this day. Fred Martin, a researcher in the Epistemology and Learning Group, helped create the 6.270 LEGO Robot Design Contest at MIT. Students had to build a robot out of LEGO and program it to perform autonomously in a sixty-second contest against another robot. Often, the MIT students had problems overcoming noisy sensors, incorrect assumptions of environmental conditions, and problems learning exactly what the actuators could and could not do. On the other hand, students learned system theory related to control and feedback, bottom-up design, and programming techniques for unpredictable, non-ideal, noisy, environmental conditions (Martin, 1994).
Robot Odyssey supports black boxing. Children’s circuits often get large, gangly and unwieldy, turning into tangles of wires. Robot Odyssey’s circuit metaphor extends to IC chips, which provide an good metaphor for black boxing large programs. By moving the robot to the chip burning room, children can take a snapshot of a its “brain” (disconnected from its inputs and outputs) and burn a new chip with the program inside. Then they can put this chip inside the robot head and wire it directly to the sensors and actuators with very little mess. This works well, except that children sometimes forget what the input and output pins of a particular IC do. To help avoid this problem, Robot Odyssey provides a documentation tool to record the description of the inputs and outputs of the chips.
The Incredible Machine, published by Sierra On-Line, is a construction kit in which kids put together a Rube-Goldberg contraption to solve a puzzle. By connecting pianos, traps, levers and guns, kids can solve each new level of the game. The Incredible Machine uses a direct manipulation style interface, where each element in the parts palette can be dragged out onto the screen. The user can easily test out different configurations of parts to see if it would solve the puzzle.
One problem with this game is that sometimes the parts needed to be perfectly aligned in order for them to work, and there are no visual clues other than running the simulation to find this out. The game is also not customizable; the parts are static. The user can not extend the game to include more parts or modify existing ones to exhibit different behaviors. Sometimes the machines that are created get quite complex, so a facility for abstraction and black boxing a particular machine would be helpful, too. The next version of The Incredible Machine adds the ability to create new puzzles, so the user can devise their own challenges for their friends.
Widget Workshop is a product published by Maxis, the company that makes SimCity and other popular simulation games. Using Widget Workshop, children can make complicated machines from timers, switches, gates, and other graphical objects that perform different tasks. Children are challenged to create the right machine to achieve a particular goal, such as turning on a light, or making a Rube-Goldberg contraption work correctly.
Widget Workshop uses a data flow metaphor. Using wires to connect different parts together, children wire up inputs to outputs and create large information flow graphs. Widget Workshop is also graphical, so children use the mouse to directly manipulate the parts on the screen to place them in their proper locations. When the children have finished building a machine, they turn on the power and the machine starts to compute. If they have connected everything together correctly, a light goes on and a bell rings. The designers of this construction kit were very aware of the importance of good graphics and sound in keeping the child’s attention.
There are some problems with this program, however. There is a large library of parts, and none of them are identified with any text labels. Sometimes the icons are not plain enough to decode what they do. To a beginner using this program, this might be intimidating. There also is no facility for abstracting or black boxing a machine that a child has made. Some of their challenge problems require a large array of parts to be strung together, and without any means of black boxing, the screen quickly becomes a tangled mess of data flow wires. There also are no debugging tools in the programming environment. The only evidence that a machine didn’t work is that the light and sound didn’t go on. Some animation of data flow through the wires might be a plausible way to illustrate this, in addition to a testbed where the child could try out different configurations of parts to produce intermediate outputs.
Pinball Construction Set, written by Bill Budge, is a design kit that lets kids build pinball machines and play with them. Children can choose parts from a palette of bumpers, pins, racks, and flippers to create the ultimate pinball game. Users use direct manipulation to drag parts off the palette and place them on the playing field. They can also paint a background on the game. The set allows users to control system parameters like gravity, elasticity of the bumpers, and the speed of the game itself. An advanced feature allows users to use Boolean logic to specify how points are scored based on the particular bumpers and knobs that the ball hit during play. Once the user is done constructing their game, they can press the “Make Game” button which saves the completed game on the disk for people to play. This saved version does not include the development environment, however, so finished games are not modifiable. In addition, without the original “source code,” you can not reverse engineer a pinball game to see how it was constructed.
While Pinball Construction Set made it easy for children to create interesting pinball games for themselves and their friends, it did have some problems. It did not have any intelligence about where you were allowed to put pinball game pieces on the screen. You could easily make a structure that the ball could never reach, or a pocket where the ball would always become trapped. Fischer and Lemke argue that construction kits should have semantic knowledge of their programming domain and help the user avoid these dynamic “run-time” errors. (Fischer and Lemke, 1987-88).
In a totally different genre of building tool, Klik and Play (from Maxis) and its big brother, The Game Factory (from Europress), are video game construction kits that allow kids to create Nintendo-style video games easily. Employing a form of visual programming, Klik and Play gives the programmer a large palette of characters, backgrounds and props. The user may define different scenes, or may define a large world that scrolls as the player moves around in it. The programming environment uses drag and drop to allow the programmer to directly manipulate the characters on the screen (i.e. to define a path for a particular character to run, you right-click on the character, click on the Define Path menu item and drag the character around the screen). The game uses the right mouse button to pull up context sensitive menus to affect the characteristics of an object. Once you have defined your game, you can press a button, and it turns into a standalone application, playable without the construction environment.
The Game Factory contains a large library of shapes and animations. The library is almost too large, since there isn’t much organization to its parts. Example characters and parts are only divided by their inherent types and not by their purposes in particular games. On the other hand, The Game Factory comes with several pre-built games that can be opened and edited just like any other game. This gives the beginning user a base on which to start learning how to program in the environment.
The creation of a new construction environment for children is no easy task. One would hope to build off the lessons learned from past construction kits, as well as incorporate the latest ideas from the research in children’s learning and cognition. There have been quite a few researchers interested in children’s cognitive understanding of programming environments (Papert, 1980, 1993, 1996, diSessa and Abelson, 1986, Fischer and Lemke, 1987, Harel, 1988, Kafai, 1993, Resnick, 1994, Smith, Cypher, Spohrer, 1994, Repenning, 1994, 1996, Sargent, 1995, Umaschi, 1997).
Based on this research, I have selected several broad principles for creating computational construction kits for children: understandability, uniformity and elegance, interactivity, functionality, transparency, powerful ideas, and reflection and audience.
This chapter discusses these overall design criteria for construction kits, and then speaks specifically about those issues that affect video game construction sets in particular. The next chapter proposes a new type of video game construction kit based on the conclusions of this discussion.
The most important task of any construction kit designer is to choose metaphors, languages, and tools that enhance the environment’s understandibility. Since non-expert users have a limited mental model of the system, the construction kit is the tool that creates an abstraction layer between the problem domain and its implementation.
The different metaphors chosen by the designer allow the users to connect the design environment to familiar objects and experiences. Logo employed body syntonicity to allow children to relate the Logo turtle’s action to their own body’s movements. Direct manipulation interfaces are used in many systems to minimize the distance between a user’s actions and their effects on the screen. Video games employ joystick controllers to directly control characters on the screen (Schneiderman, 1992). Though some abstract concepts are difficult to express, direct manipulation interfaces generally enhance understandability when used appropriately.
Design environments should also have knowledge about how their own pieces fit together, and as a result of this information, they should be able to guide the user into putting these parts together in a logical and rational way (Fischer and Lemke, 1987-88). One common pitfall for construction kits designers is to provide only the construction materials, and forget to include the instructions on how the materials are supposed to go together. Using the “view source” option, Web browsers allows users to gain access to author’s “source code.” This ability to see the underlying “real” representation of the page gives users examples of correct usage of HTML that allow them to extend their own work in new creative dimensions.
Uniformity and elegance are the same idea viewed from two different perspectives. Uniformity is seen by the user of system. When users encounter a consistent, uniform user interface, it enables them to learn better and reduce mistakes (Schneiderman, 1992). In a structured user interface, the users expect that each level will behave similarly—that the same gestures and commands will produce equivalent effects.
Elegance is uniformity seen from the programmer’s point of view. Programmers strive to achieve elegance in their design and coding. Often, this involves many code revisions, but when the finished product is done, it can often be admired as a work of art.
These two concepts may not seem connected at all, but in a construction kit, they are tied together intimately. A construction kit designer must combine a uniform interface and programming metaphors to allow the user to understand their system easily. But since the user is also going to use the kit as a construction tool, the kit must allow the user/programmer to create elegant code.
Uniformity and elegance are not always easy to achieve, even though they are often desired. In some cases, non-uniformity may actually aid in comprehension by exposing flaws in the programming metaphor. These flaws reveal actual implementation details that must be surfaced to the user in order to give them a clear picture of what is really going on inside the computer. For example, in Boxer, every UI element is a box or contained within one. However, when two boxes need to reference the same object (a common occurrence in most traditional programs), two linked ports are used. Ports are like boxes, but are linked, so that a change in one port is immediately seen in the other. This port is necessary to achieve a standard effect in computer programming, but violates the “naive realism” of the interface.
“User interfaces are often considered to be separable from programming language semantics and almost an afterthought in language design. Worse, most present languages assume only character-stream input and output. A useful medium must be much more flexibly interactive.” (diSessa and Abelson, 1986). diSessa and Abelson lamented on the state of programming environments in the mid 1980’s and the situation hasn’t gotten much better for the programming community.
For special audiences, however, construction kits being created today find ways to become more interactive with their users. The systems might support direct manipulation which allows the user to affect the objects and metaphors present in the interface as if they were concrete objects. They also might talk back to the user and suggest possible courses of action, or give the user help when they notice there might be a problem. They may support interactive program development where a child can receive instant feedback about a program change and be able to debug the program while it is running.
SmallTalk and Boxer pioneered the idea of the combined user interface and programming language. Apple’s language, Dylan, had a programming environment that was a logical successor and upgrade to the SmallTalk-80 environment (Palmen, 1995). It incorporated color graphics and drag-and-drop direct manipulation, but Apple closed the project several years ago due to excessive delays in shipping. Kansas, a research project from Sun Microsystems, is a collaborative shared environment where many users can interact with each other and the system to create projects. A derivative of Self, itself a derivative of SmallTalk, Kansas supports interactive shared debugging in its networked environment by actively transporting its users to Oz, a shared graphical debugger, whenever a serious problem occurs (Smith, Wolczko, Ungar, 1997).
In programming, a construction environment that supports interactive development is necessary. If active exploration, undo/redo, direct manipulation, and feedback are part of the interface experience, then in the tradition of Boxer and SmallTalk, why shouldn’t they be also a part of the programming experience as well? These concepts would make programming easier, less frightening (since a child could try out lots of things quickly without fear of breaking the system) and bring it closer to the actual domain in which the child is working. A challenge for general-purpose construction kits is to provide some type of general direct manipulation interface without becoming too abstract in the actual problem domain that the child wishes to explore.
There are several different degrees of functionality that a construction environment must support. First, it must be capable enough to create a variety of outputs in the domain in which it operates. In the video game realm, it must be capable of producing a video game that supports graphics, animation, and some form of player control.
Once the basic formula has been created, what then? What extra functionality does the system support? A system could provide more interesting inputs and outputs or more modalities with which the user might control the system and receive information from it. Agentsheets and Cocoa have explored these types of functionalities quite extensively. Other systems could branch out in orthogonal directions, incorporating 3D graphics, animation creation and scripting, and complex character behavior generation.
Randy Sargent explored how multiple input and output modalities affect the kinds of projects you can make. He found that the variety of activities does not increase linearly with the number of things the program can connect to, but grows exponentially. Most of the simple and interesting applications of a program can be found at the intersections between things the program can read in and things that the program can output. Since complex applications will involve more than one input/output pair, and each modality can interface to many different things in the world, the number of possible activities grows at a very high rate (Sargent, 1995).
There is a tradeoff between usability and expressiveness in domain-specific and general-purpose systems (Repenning, 1996). A domain-specific system can be used to provide highly specialized tools which are capable of producing very polished projects. Since the author of the kit understands everything about the particular domain, he may provide a complete set of tools with which to work. On the other hand, a general-purpose system is flexible enough to explore multiple domains, especially those that the designer hadn’t intended. Indeed, a creative user might use a general-purpose design kit to explore a particular domain of interest as deeply as a domain-specific tool, though the threshold might be higher.
“Is the system made from turtles all the way down?” This Logo cliché is often used to describe systems that are created in their own programming environments. Systems like Lisp and SmallTalk are written in earlier versions of themselves and serve as platforms for programming new features. Thus, when a programmer doesn’t understand how a certain Lisp procedure works, he/she may search through the source code and read how it was done.
A similar principle could be at work in construction kits for non-expert programmers. If the system is powerful and general enough to be written in itself, then when the user doesn’t understand how a piece works, he/she can choose to look at the “source code.” Some systems, like Agentsheets are not written in themselves. To create a new graphical agent or new type of rule, you must program it in Lisp. Clearly, for the person who is a perfectly comfortable user of Agentsheets and not a Lisp programmer, the system will not be extensible without having an expert programmer on call.
Construction kit designers have a vested interest in making a fun toolkit that children can use to explore a large design space. In order to capture the children’s interest, the scope of the design space must include topics that are personally meaningful. Video games have been in the “kid culture” since the late 1970’s, and serve as a very compelling medium for exploration.
While a toolkit can merely be a vehicle for designing video games, it could also be utilized as a way to learn while designing. It can provide children the means to reach powerful ideas. Seymour Papert used the phrase powerful ideas to describe fundamental concepts that, when realized or learned, provide leverage for exploring new domains (Papert, 1980). Some of these concepts, like logic, probability, feedback and abstraction can be encountered while designing and implementing a video game. Comprehension of these concepts is valuable since they directly apply to many different domains, but as cognitive tools, they provide the leverage to explore and design in new domains. Life is about exploring different domains of knowledge and creating new knowledge in each of them. A person’s personal interests guide them through life’s design space and enable them to learn about new domains that are personally meaningful.
Reflection upon the design process and its result is an extremely important part of any design experience. Construction kits should support reflection in its many forms. One such form, iterative design, allows programmers to create and refine their ideas about the system they are building. Harel and Kafai asked all the children participating in their project to keep a notebook log of what they had accomplished each day. Reflection is an important part of this design process; without it, there would be no checks or bounds on the direction of the project.
Another aspect of reflection is the evaluation of the final design and product. Did it perform up to its expectations? Is there anything else to add? What modifications could be made to make it different or better? Other people might also take a look at the final product and offer suggestions. In the past, most school projects were shown off to children’s friends, or to parents on Parent-Teacher night. But, with the rise of the Web, a child can post their project for everyone to see. They can also advertise it in schools newsgroups or via mailing lists. People that the child doesn’t even know can stop by to take a look. They can comment on the work through email, perhaps suggesting new ideas or different implementations. Children can also surf the Web and see other kids’ games on the net and get new ideas for projects of their own. The Web opens up and diversifies the audience for a child’s project.
There are quite a few specific design issues for video game construction kits. Some are involved with game construction; others have to do with the programming environment and language that the child programs in. Each of the different issues affects the process of creating games and determines what kinds of games can be constructed. Through the prior analysis of both general-purpose and domain-specific construction kits, this section hopes to make clear some good directions and tradeoffs in the construction kit design.
This section covers several different areas that affect how children sit down and create games. The first part examines what happens to the design process when either one or more children interact to create a project. The second part explores how the quantity and type of examples included in the kit affect the children’s exploration of design space.
While there are many different considerations for construction kit design, one that affects the programming environment the most is whether the toolkit is geared toward one constructor or a community of constructors. A one constructor model allows an easier and less complex design, since many problems that come with coordinating multiple programmers just do not occur in a single user environment. On the other hand, many children tend to work in groups on projects, whether due to lack of computer resources or while working on group activities. A construction kit that supported a collaborative video game creation environment could be quite desirable.
In a one constructor model, the construction kit designer must take care to engage the user. The environment should be simple enough to be understood by one person working alone, but support a deep enough experience that the child won’t get bored quickly. The system can also make the assumption that the single creator knows everything about the project on which they are working. It doesn’t have to resolve design conflicts that come from having more than one programmer. On the other hand, some researchers feel that the system should then take an active role in guiding the programmer towards interesting areas of the video game domain, or invite them to explore little-used, but interesting features (Fischer, 1993).
A single user system can also take advantage of the multiple modalities of today’s modern user interfaces. In many computers, there are keyboard, mouse, joystick, sound, and sometimes pen inputs. Since the user is always sitting in front of the computer, the system may use all of these to create a complete user interface.
All of the early construction environments were geared towards one child construction because networking was not widespread enough. If a joint effort was desired, two kids would get behind the computer, one controlling the keyboard, and the other controlling the mouse. A few more would gather behind them and “drive” by shouting commands to them. “Move the mouse over there!” “Tell that turtle to go forward 1!”
Another more common type of collaboration occurs in classrooms where children are working on programming projects. One child will look at the other’s screen and copy anything that seems interesting. Over the course of a few hours, quite a few ideas could spread throughout the entire classroom in a form of low-tech networking.
If networking is available, then instead of asking “how many people can you fit around one computer?” you might ask “will people working at their own computers construct the same project together or work on different projects separately?” In addition, you might ask if these people will work asynchronously or synchronously with each other. Asynchronous environments like the Web enable off-line construction. People create projects by themselves and then publish them on-line. Synchronous environments allow multiple people to collaborate together in real-time to develop a project.
Some existing environments have taken different stances on the above two questions, but many support more than one style of construction. MOOSE Crossing, a MOO created for kids by Amy Bruckman, supports children working on separate projects in a shared world (Bruckman, 1997). However, since MOO’s are object-oriented, children’s projects are usually related by parent-child-sibling inheritance relationships. In Kansas, a shared graphical programming environment written by Smith, Wolczko and Ungar at Sun Microsystems, researchers work together to debug problems that cause part of the system to crash (Smith, Wolczko, Ungar 1997). In Castle Infinity, an adventure game published by Starwave Corp., children must work together to solve puzzles and finish a quest in a shared graphical world.
In a collaborative environment, kit designers should consider a few policy decisions that can affect the rest of the environment and the construction process. How do the children divide up the labor? How do they assign access control and permissions on objects? How are they able to communicate with each other while working on a project? And, finally, when they are all done, how do they publish and advertise their project to everyone else?
In a shared project, children are required to work together to construct something. How should they decide how to divide up the labor? In a video game project, they each might work on the behaviors for a different character. Then they could all work together to integrate the characters into the game and help each other in the debugging. For example, if three children wanted to work on a game of Space Invaders, they might split up the three characters, aliens, hero and bullets among them. Then, when the behaviors have been completed, they can all work together to place the characters in the game. When they begin to play, each might notice some bugs or strange effects and go back and fix them.
Permissions come into play when a child wishes to create a new object. There are many different types of permission structures. For example, in an object-oriented environment, a child may have seen some other interesting object in the system and want to make their own version. Who determines whether a child should be allowed to look inside another person’s object? The object could be controlled by no one, in an open system, or by the owner of the object, usually its creator. A child might not even need to open up an object in order to copy or subclass it. Again, the owner might allow or deny this attempt to examine the object. Generally, it is probably a good idea to let children get practice arbitrating their own privacy and permission issues, since these are pervasive policy questions in the adult world.
There are several modes of communication available in a networked environment. The simplest is a small IRC-like chat window at the bottom of the screen where children can send messages back and forth. A more integrated system might take the form of a MOO, where textual interactions with other users and objects are the dominant working mode. If asynchronous communication is desired, one could support email or a public bulletin board system where children can ask each other questions and get answers. One interesting implementation of a bulletin board is an electronic white board. Every person gets a pen and can write messages to each on a shared graphical board. Taking this one step further, in a truly shared virtual world, all of the children get a mouse pointer and may manipulate shared objects in real-time. Since there is only one world, all children would be able to view any piece of it whenever they wanted. Thus, they could use the world to leave messages or objects that they have created for each other.
On many systems, designers have taken care to manage their collaborative worlds to foster a sense of community between the users. This includes providing opportunities to show off children’s work and providing the means to expose children to things that they normally wouldn’t have come across.
Every winter in MOOSE Crossing, there is a public pet show, where children who have created new an interesting pet objects come to show them off. This usually leads to a flurry of new construction activity where everyone tries to integrate the new and interesting features that they have seen into their own pet projects. While the pet show sparks some new activity, the more common social conversations on the system also provide ideas to children from each other. When one child comes to another and says, “Look at my new pet purple ostrich!” a link is formed through which ideas, feedback and suggestions may flow.
In Kansas, whenever anyone makes a big enough mistake in their program to crash the system, all of the users are transported together to Oz where they can work together to fix the problem. The users might not have known each other otherwise, but in these times of crisis, people may work together to fix someone’s project (Smith, Wolczko, Ungar, 1997).
The WWW created a new form of public bulletin board for publishing projects. Since a net connection is quite cheap, and most schools have already been wired up to the Internet, children can get their own home page without difficulty. Suitable construction media, such as Cocoa or Java, and now Bongo, allow programs to run inside web browsers. Children may use these tools to construct various projects and show them to the world. While most children’s web pages aren’t heavily trafficked, enough people will stop by and give comments on the projects and offer suggestions for improvements. This kind of anonymous feedback is very interesting. It might even be taken more seriously than feedback from a person the child knows because this anonymous person could be an “expert” in project’s domain.
Examples help the user figure out the syntax and semantics of your particular system, as well as show them examples of good style and successful designs of projects (Fischer, 1993). It is also easier to modify existing projects when you are learning than to come up with new ideas on your own. For example, 6.001, the introductory computer science class at MIT, teaches freshman and sophomore students about programming by asking them to modify or complete partially written programs.
How many examples should be distributed with the construction kit? How are they distributed? Are they modifiable? Can someone open them and understand how they were created? Examples can be packaged either as components in a library or pre-built projects. How many components should ship in the library? If the design space of this construction kit allows wide ranging exploration, then a library with just few sample objects for each category in the design space should be sufficient. But how much is enough? If too many components are in the library, the users might feel lost in a sea of possibilities. At this point, the organization of the components becomes critical. Components should be organized in multiple hierarchies, not just by object type. Users should be able to search through the component sets and easily find what they need.
How are the example projects distributed? Usually, most construction kit designers would include a few pre-built examples with their kits. However, with the rise of the Internet and the WWW as a free publishing medium, many designers have started to put new and updated projects on Web pages. Interested programmers can surf to these pages and download them. This publishing medium gives the kit creator the ability to update and add new examples over time, and it allows the programmer to gain access to new and interesting projects. Programmers can even use the Web as a transfer medium to trade projects with each other. Klik and Play and The Game Factory have a Web bulletin board where children not only share finished projects, but also help each other find and fix bugs. In addition, the public pooling of knowledge about programming techniques is valuable for beginners and experienced programmers alike. Kit designers can also use this medium as a way to get feedback on their example projects and distribution techniques.
In 1994, the 6.270 LEGO Robot Design competition was started by Fred Martin and Randy Sargent. Students, undergraduates including myself, had to build Robo-Pirates. These robots had to capture pirate treasure (pick up foam blocks) and drink pirate punch (pick up sawed off plastic soda bottles). Students could take either a defensive strategy by collecting their own treasure and punch, or take an offensive strategy, and raid the other pirate’s treasure. Most people started out with their own ideas about what to do. A few days into the contest however, one team created a robot that ran around to the back of its own pirate ship, and one by one, knocked the bottles into its basket. As soon as everyone saw this, 20 teams switched their strategies to this one. Only five teams remained on any offensive strategy, and eventually one of these won the contest.
Students in this contest were easily swayed to making simple modifications on one simple strategy, rather than branching off to make unique projects. While modifying standard projects can be a great learning activity, it stifles creativity if the design experience does not provide opportunity to create more than one iteration of a project. Had the students in the contest the opportunity to try it again, more of them would have investigated offensive strategies.
The programming environment of a game construction kit is the place where the user encounters the metaphors, functionality, and style of use that are appropriate for their task. There are some fundamental questions to ask that determine the course of the environment. The following sections give a small discussion of each issue and touch upon some advantages and disadvantages of different approaches.
What can you make with the system? How much can it do? This is ultimately tied into the architecture of the kit, whether it is general-purpose or domain-specific. There is no black and white distinction between these two, however. Each construction kit can exist on a continuum between low-level and high-level programming. Often, the designer of such a kit must help build a bridge from the bottom level implementation details of a system to the high-level domain-specific knowledge that the user will have. The real issue is how far to make each side go before deciding where exactly on the bridge they will meet.
General-purpose programming environments allow users and programmers to explore many personally meaningful domains of interest without getting in their way. Traditional programming languages, like C, Lisp, Logo, and Smalltalk are general-purpose enough to allow programmers to write applications in any domain that want. Some even provide enough flexibility to define themselves recursively! These languages are also Turing complete, which means that they can compute anything that any possible Turing machine (or program) can compute.
Even though the designer of a general-purpose environment only has a limited idea of what to do with it, it may be used in many more domains. This gives programmers enough flexibility to create anything that they want to make, instead of limiting themselves to the environments’ authors’ imaginations. With this flexibility, however, comes some tradeoffs. Since these environments enable programmers to explore a very large design space, it becomes easy to get lost without any guidance. Usually, programmers must have a good idea of the type of project that they want to create before they sit down at the computer. Exploratory environments like Logo and Smalltalk make the conceptual development of a project easier by supporting interactive development.
Another technique for easing the cognitive burden in general-purpose construction kits is to create a situated subset environment, or microworld, in which the programmer can explore interesting ideas and problems (Papert, 1980). This new environment is limited enough to be explored completely, but complex enough to give the user a sense of understanding of powerful ideas. But, one should not create too many microworlds and present them all to the user as parts of a larger general-purpose kit. Lisp, to pick one example, has extended itself to match a number of specialized high-level domains. Due to this, it is more of a whole system than simple language. As more and more functionality is layered upon Lisp, the whole system gets more and more complicated, the documentation gets longer and longer, and the whole system becomes more difficult to learn (Hutchins, et. al. 1986)
A domain-specific programming environment provides tools to support more in-depth exploration in a specific set of topics than a general-purpose kit. Good domain-specific embedded programming environments allow the programmer to deal with only the content of their work and not be bothered with the mechanics of the environment (Fischer, 1993). If one is designed well, each of its metaphors will be intuitive enough to a person skilled in the application’s domain.
A good example of one of these kits is Macromedia Director. Specifically designed for creating movies, animations, and presentations, Director is highly specialized for the video domain. It contains a programming language called Lingo which is designed to make scheduling and coordination between many different media streams not just possible, but easy.
Another interesting domain-specific toolkit is SAGE (Storytelling Agent Generation Environment) (Umaschi, 1997). SAGE allows children to created embedded communication models of turn-taking-based storytelling conversations. Children can script a conversation between the computer and another child about any topic. SAGE’s programming environment allows children to create characters and describe them, create the conversation structure in a graphical form, and write stories and record them in their own voices. One interesting piece of the environment is the conversation editor. It uses a state diagram metaphor to control conversation flow between the storyteller, a story assistant and the user. State transitions or communication actions are illustrated by arrows between the states.
Domain-specific languages are great to use when you don’t want the user to have to decompose their high level intentions into a long series of low-level actions in order to accomplish a task. Since the author of the environment has knowledge about their programming domain, they may write the program to take on the task of translating these high-level structures and concepts into the low-level details for the user. However, the author of a kit must watch out that the system doesn’t get too overspecified. “Beware the over-specialized system where operations are easy, but little of interest is possible” (Hutchins, et. al, 1986). A system that becomes over-specific loses what little generality it had and only becomes useful in situations for which the author has provided support. User intentions that don’t decompose into actions supported by the kit could become very hard to achieve, if not impossible.
Is the environment in which the game is created the same environment in which it is played? If so, then the process of game development changes, as well as the possibilities for the environment’s use when the project is done. If not, then the environment behaves more like traditional compiled programming environments. (Note: I am using the terms interpreted and compiled not as references to the mechanics of the underlying language implementation, but as references to certain styles of programming. Interpreted stands in for interactive development, and compiled stands in for batch-style development where the compile/run cycle is not instantaneous.)
In an interpreted programming environment a child can actively explore different options and see how these choices might affect the outcome of the game. These environments should have support for undo and redo operations which make the price for any program change drop to almost nothing (Fischer and Lemke, 1987-88). Since the line between the program world and the runtime world is blurred, the programmer may use the environment as a laboratory, testing and playing with each piece separately, even before it is worked into the final project.
A good example of an interpreted environment is Logo. Logo carried the concept of the Lisp Listener to the kids’ realm and allowed children to try out their commands interactively. When there was a problem, an interactive debugger could be invoked to help find the source of the bug. In addition, once the Logo turtle was introduced, children had a way to see the direct effect of their programs as they were run. If there was a problem in a triangle drawing routine, they could easily see the incorrect behavior as the turtle moved around on the screen.
Once a game is “finished” in a interpreted environment, nothing more must be done to make it playable. This means that the programming environment is carried along with each project. If a program has a bug, the child can debug it wherever it is being used, regardless of where it was created.
Another advantage of keeping the development environment with the finished product is support for extensibility. A game may be modified at anytime and examined by anyone. If children were working on their own games, they could examine someone else’s game to see how it was created and what kinds of algorithms it used. If the children liked a particular character, they might even be able to copy that character into their own game! Alex Repenning has a working version of a trading post on the Web where children can swap agents for their Agentsheets programs. Sometimes it is very interesting to see what happens when a piano agent is dropped in a fish tank project. Will the fish ignore the piano? Or will they try to play some jazzy tune?
By contrast, a compiled programming environment implies a different design style. For example, in a programming environment like Pascal, programmers must conceptualize large chunks of their program and write them down all at once. Then they can compile what they’ve written and test it out in a separate play environment. Children can identify bugs and problems in this environment, but must switch back to the development environment to make changes because the run-time environment is not modifiable. Since it is not easy to test out different modules before they are integrated into the whole program (professional programmers use stubs for this), children must spend significant amounts of time planning ahead. When there is such a large time and energy price in the compile/debug cycle, unbounded exploration is curtailed.
Direct manipulation interfaces allow users to interact with a system through metaphors that match the way that one thinks about the system. Instead of using text-based commands to manipulate objects on the screen, a mouse can be used to drag icons representing these objects around. MacOS and Windows 95 both have direct manipulation desktop metaphors for their file systems which allow users to think of files and directories directly as icons and folders on the graphical desktop.
Ben Schneiderman, the researcher who coined the phrase “direct manipulation,” stipulated that these interfaces all have three properties: continuous representation of the object of interest, physical actions or labeled button presses instead of complex syntax, and rapid, incremental, reversible operations whose impact on the object of interest is immediately visible (Schneiderman, 1982).
The first real direct manipulation interface was introduced by Sutherland in 1963. His Sketchpad, a graphical design system where people could “converse rapidly through the medium of line drawing,” was a landmark because it was the first use of graphical interfaces, pointing devices, and the use of the screen as a sheet of paper (Sutherland, 1963). However, due to hardware limitations, it took about 20 years before anyone else could do anything significant with graphical direct manipulation interfaces.
Since then, many advances have been made in the field, many of which have manifested themselves as commercial products. Many of the construction kits mentioned in the Chapter Three make extensive use of direct graphical interfaces to make metaphors more clear to the user. Bill Budge’s Pinball Construction Set was one of the first construction kits for PCs in the mid 1980’s. It allowed people to move pinball game parts from a palette onto a blank pinball game. Users could customize their game with their own sets of bumpers and flashers that could themselves be reshaped by a simple tug of the mouse. Since there was a direct match between the graphical kit and the problem domain, there were no syntax errors. If a part could not be placed in a particular position, then it would not let itself be dropped there.
The root of the cognitive argument for direct manipulation is to provide the user a sense of “directness” about the interface and their task. This is not a definable term, but through the exploration of various examples which have been presented above, designers can get a feel for which metaphors are direct, and which are not.
One key aspect of this directness is instant feedback. Direct manipulation interfaces should provide visual feedback for every step that the user takes in manipulating objects on the screen. In the MacOS when the user drags a file from one folder to another, a visual representation of the file moves with the mouse until the button is released and the file drops into its new folder.
Another aspect should be direct engagement with the problem domain. “Are we playing a game? Then we should be manipulating directly the game world, touching and controlling the objects in that world, with the output of the system responding directly to our actions, and in a form compatible with them” (Hutchins, et. al. 1986). Control interfaces to video games are another example of direct manipulation. A movement of a joystick or a mouse sends characters in the game moving around in their virtual world. This mapping of controller to character has been taken for granted in every video game since Spacewar! Designers of game construction kits should think carefully about the input modalities of a system to make them intuitive and directly applicable to the games.
Sometimes, however, direct manipulation is not appropriate. For actions that induce abstract results, perhaps no mapping of physical or virtual reality onto these domains would work. Applications that are inherently “invisible,” such as hidden state updates, might not be represented very well by physical actions of the mouse. Repetitive operations, such as sowing the field of pellets into Pac Man, can be quite tedious if no other form of abstract pellet “sprouting” is available. Direct manipulation interfaces also do not lend themselves to accurate placement of objects on the screen. Applications which require precise motion need to provide extra alternative approaches to tweaking the results to get the desired effects. It isn’t easy to line up the aliens in Space Invaders without a ruler; a more clever mathematical approach uses div and mod to place each alien in its correct place within a block formation.
Any programming system must support abstraction and blackboxing in order to reduce complexity to a reasonable level. Human beings can only think of several things at a time (Minsky, 1985). When people try to comprehend a problem, they often break it up into subproblems that are easier to solve. If the programming language does not support this method of problem solving, then users will quickly grow tired of the language and the problem itself. At the very least, the ability to name procedures and use them as building blocks for other procedures is a requirement. There are several implementations of this black boxing in the kits discussed in Chapter Three: Logo, which uses procedural lambda calculus; Boxer, which uses graphical boxes on the screen to encapsulate procedures; and Robot Odyssey, which uses a chip burning metaphor to encapsulate a data flow circuit.
Data flow and instruction flow systems implement black boxing in different ways. In data flow systems, black boxing enables the user to draw an interface around specific I/O ports and declare the new interface as a new basic block. One does have to be careful about documenting the I/O ports so the block does not have to be opened in order to be understood. In most traditional instruction flow architectures, a procedure is named, and separated out with documentation that specifies what it does, what kind of inputs it takes and what kind of outputs and side effects it produces.
In a video game construction kit, abstraction and black boxing take on special meaning, since usually there are several different types of characters that wish to share some common behaviors. These behaviors, if referred to in simple discrete blocks, are easily moved in and out of characters. Creating discrete blocks with no dangling pointers, however, is not easy and requires a lot of redesign. Care usually has to be taken that dangling pointers to other objects are capped with either the original objects, or instructions telling how to attach a suitable replacement once the block enters the new space.
Debugging features have not been adequately thought out in current game construction kits. Debugging is still a major issue for the advanced programmer community, so this state of affairs is not surprising. What should the debugging features be and when should they be active and available?
Different types of bugs include syntax bugs, logic bugs, and timing bugs. Syntax bugs are the easiest to fix. Usually the compiler or interpreter can flag these down as they show up and point them out to the programmer. Often, the reason for the bug is known to the compiler and a suggested fix could be offered. (I hope someday for a compiler that fixes these obvious bugs for you instead of forcing you to correct something as simple as a misplaced parenthesis.) Graphical programming helps to alleviate a lot of syntactical problems by eliminating the need for text syntax in the first place. The graphics can also provide context clues (i.e. holes for procedure arguments) about what kind of syntactic graphics can be placed in different spots.
Logic bugs occur when the behavior of a running system is not what was expected. Once the code is running and the characters are moving around on the screen, perhaps you notice that the power pellet is eating Pac Man instead of the other way around. Finding these logic bugs is easy when the y are directly produced by a code error. However, in many cases, the bug might cause a nested chain of events to occur that produce a visible bug much later than the original error.
The timing bug is perhaps the most annoying of all bugs. When you have many characters on the screen that need to interact deterministically, timing issues can really get in your way. If character A is walking across the screen at 4 steps per second and character B is walking from the other side of the screen at 5 steps every other second, at what time does A need to start walking in order to make A meet B 3/4 of the way across the screen on B’s side? Debugging these timing errors is difficult since the tools for debugging dynamic run-time information such as tracing or inserting print statements alter the timing of the very code you’re trying to test!
In either interpreted or compiled programming environments, the ability to run an arbitrary piece of code with arbitrary inputs is very important in learning how a piece of code went wrong. In some cases you may want to “set up” a situation in which multiple characters are in a certain state, let the system go, and then watch it unfold in order to find out where it went wrong. Perhaps a system that records all state transitions and is able to play them back (data flow transitions + dynamic instruction flow transitions) would be useful. Football coaches tape scrimmages and games in order to reflect on them in a port-mortem attempt to identify flaws and errors that weren’t noticed during play.
Sometimes you don’t want your debugging to stop the rest of the system. It would be good if you could extract a malfunctioning character from a game, examine it under “laboratory” conditions and put it back in the game when you’ve corrected the problem. You could also use these laboratory conditions to alter a particular creature’s behavior in order to force a situation to occur.
Darwin’s Pond, by Jeffrey Ventrella, is a laboratory for evolving many-legged locomoting creatures. If you like, you can let evolution take its course and let the system self-select for the fastest creature. But, if the budding scientist in you takes over, you may pluck a creature from the pond, tweak its genes in a beaker, and then put it back to spread the new genes throughout the gene pool.
The programming model and language help shape the users’ cognitive models of the system. The first part of this section discusses different cognitive models of computation and how they affect the programs that are written. The second section discusses the influence of graphical programming on the game construction kit world. The third section explores the difference between data flow and instruction flow languages and identifies situations in which each is appropriate. The last section talks about object-oriented programming and how this can help lower the threshold for understanding how a complicated video game might work.
There are several different models of computation in use in the field of computer science today. While all of these are computationally equivalent to the Turing machine, they afford the user different cognitive models that have direct influences on the types of programs that may be created.
The most basic model is the Turing machine. This model uses a transition relation to define state changes in a program. Some construction kits, such as Cocoa and Agentsheets, use the Turing model as their model of programming. To make a ball fall in space, the programmer simply describes the state transition from the ball in one position to one where the ball occupies a position with lower potential energy. To make this model complete, one might also include some hidden state showing how much kinetic energy is in the ball.
One problem with the Turing model shows up when your problems get more complex. In a Turing machine, the more states you have, the bigger your transition relation. For every new object, new position, or hidden state, you need another state in your machine. There are 2n entries in a complete transition relation with n states. Clearly, this blowup has many implications on the types of projects that can be created. Simple things which don’t have much state are easy to write. But, as soon as you make your model a little more complex, the number of transitions you have to specify grows exponentially, and leads to cognitive and practical intractability very quickly.
One abstraction that improves the Turing machine is parameterized state. An example of this might be a predicate which says “if there is a ball to the left of me.” This predicate could easily stand in for quite a few states where the object in question could be in any position, with any internal state, as long as any ball is situated to the left of it. AgentSheets’ support for Visual AgenTalk is Repenning’s implementation of parameterized state machines, and in practice, affords a much higher level of control over the agents in the system.
Assembly language is the fundamental language of digital computers. FUNdaMENTAL is a general-purpose construction kit that uses an extended assembly language model of programming. Conceived of and written by Justin Kitch, it was introduced as a way to allow children to build all abstractions by themselves. This technique was used as a way to make transparent all of the computation steps that a high level language tries so hard to cover.
There are several models of computation that can take over when you have many different elements in your game that act in parallel. SIMD (single instruction, multiple data), SPMD (single program, multiple instruction, multiple data) and MIMD (multiple program, multiple instruction, multiple data) provide very good abstract models for parallel computing. SIMD allows the programmer to reason about single-threaded instruction flow that acts on multiple objects. This is often called vector processing, since the multiple objects all tend to be related in some way. These multiple objects could be characters in a game. Each character is programmed the same way with the single program, though since they could have different internal state at any point they might appear to act differently.
The SIMD model is appropriate for parallel procedural programming. When you add in object-orientation to the parallelism, however, MIMD programming becomes a better model. MIMD models the same multiple objects, but each object executes its own program at its own pace, rather than all executing in lockstep. Object-oriented approaches help alleviate the hierarchical pressure on the structure of the program by providing convenient interface and black boxes around abstractions.
SPMD is a simpler version of the MIMD model that enables different processes to execute independently, but removes the object-orientation from the system. This allows the programmer to write one large program that all processes may share. This model is good for the parallelization of procedural programming languages like Logo if object-orientation is not desired.
In the 1970’s, most games were written in assembly language and had to fit into very tight memory constraints. These games also required special video hardware to support this highly space efficient code. In the 1980’s, professional games were still being coded in assembly, but authors started turning to C and more platform-independent text programming languages. Once the PC was firmly entrenched, video game construction kits (which themselves were written in Assembler and C) started to appear.
The first kits embodied the same textual programming style as their authors preferred. Logo was a popular one for kids. They could program turtles to move around the screen and interact with each other. Using LogoWriter, kids could easily program simple shoot-em-up games with rudimentary sprite graphics. Since the code was in text form, children had to master syntax (already reduced in difficulty due to Logo’s designers), understanding of procedures, and the interpretation of system events in text form. MicroWorlds, the latest incarnation of Logo from LCSI, improves the graphics, sound, multimedia and parallelism of LogoWriter, and enables children to easily create good video games.
Since Logo, there have been quite a few game construction kits that moved toward a more graphical programming style. The early kits ran on the Apple II with limited resolution graphics and used joysticks for a pointer. Users could choose from many different metaphors for programming, but one of the popular kits, Rocky’s Boots, involved wiring up circuits. Kids could connect up wires between inputs and outputs and see the resulting program as a large circuit.
Other types of graphical programming involved translating textual languages to a graphical form to reduce syntactical programming difficulties. Logo was translated to LogoBlocks (Begel, 1996) in this way; each primitive was turned into a toy block on the screen that could be dragged around and snapped together to form a program. If a primitive needed to take an argument, there would be a hole in the block in which the argument would be the correct shape to fit. While removing the syntactical problems of programming, it still retained the sequential programming style of a textual programming language, though since programs could flow in two dimensions, branching programming flow was better revealed.
Another way to translate the textual programming into graphical form was Agentsheets, where the primitive blocks could be dropped into a stimulus-response block to build up rules. Each stimulus-response block could be dropped into another one, supporting hierarchy and nesting.
One of the latest forms of graphical programming in game construction kits is very object-oriented. Objects on the screen are containers for their attributes, such as sounds, graphics, animations and movements. The programmer can drag and drop new attributes on top of the object to give it new behaviors. Movement behaviors are illustrated by-example, where the user can draw a path for the object to follow, or are programmatically represented by defining simple motions with arrows. Collision behaviors, however, are not supported well, since there are n2 interactions between n characters. In this container-style environment, it is also not clear in which object these interaction relations should reside.
Another unresolved problem is the issue of debugging a graphical program. Graphical debugging tools are almost nonexistent, and those that do exist are in very primitive states, utilizing very little graphics and a lot of text. Are teachers able to look at students’ work to quickly see the problem and offer help? In addition, it is unclear whether graphical programming gives the programmer an enhanced understanding of program flow, data flow, or the operation of their program in any real sense.
Graphical programming has its flaws, but current research in the field offers many promises. Textual programming is still here to stay, however, which is why many researchers are now looking into hybrid text/graphics programming environments that try to incorporate the best aspects of each.
Most textual programs follow an instruction flow architecture. Sequences of code are written to be evaluated in order. The conditionals and procedure calls form the dynamic instruction scheduling of the program, so the key to understanding it is through tracing the control flow. Some graphical environments also present instruction flow models. Often, these are just graphical translations of textual programming languages, but others use the graphical nature to their advantage to help illustrate control flow through the program using tree structures on the screen. In addition, while the program is running, instruction flow can be illustrated by highlighting pieces of the program as the computation reaches them.
Data flow, on the other hand, has been used in limited cases in the textual world, usually through spreadsheets, where cells are linked to each other via equations. Systems that solve constraint equations are also modeling data flow. However, data flow works well in the graphical world. Borrowing from a circuit metaphor, programmers can connect computation blocks together via wires to create a data flow network. The direction of the wires determines the constraints in the program’s flow. Each computation block may either be a sequential computation or may be part of the I/O system. For instance, in Robot Odyssey, children program the robot’s head by connecting sensor inputs to motor outputs via wires. Along the way might be several computation blocks, like digital logic gates, which can control the data flowing through the wires.
In instruction flow, it is often hard to track data values or state variables as they change through the computation. Often, these state variables can be affected by numerous sources throughout the code, which makes questions like “how did that xcor get to be 5?” difficult to answer. Data flow helps alleviate this problem by making visible all of the factors that can affect a state variable or any other piece of the calculation.
Data flow also helps to present parallel execution. By merely expressing the constraints between the data values and not the control flow, the system is free to execute any part of the program at any time as long as the constraints are met. While this makes it difficult to visualize the algorithmic flow of the program, it alleviates the programmer and the kit implementor from having to state a specific ordering for an inherently parallel computation.
Instruction flow, though, has its own method for dealing with parallel constructs. If each program were represented by a stack of blocks which execute sequentially, the parallel program could be represented by a geometrically parallel array of these stacks. These parallel stacks also fit the object-orientation model, since each stack could reside in the object that it affects!
The question of programming style is also an open one in the programming community. Lisp started the procedural style of programming as an implementation of the lambda calculus. It is a convenient style for expressing mathematical functions and for expressing program flow in functional style. All action takes place in disembodied procedures that take arguments as inputs on which to specialize their action.
Object-oriented programming started with SmallTalk, and puts the procedures inside the objects for which they are associated. Instead of having walk and run functions that only check their input for what to do with a human or a dog, walk and run are embedded inside the creatures that support them. Dog and human can now be containers for those methods.
Container-based programming in object-oriented style is semantically equivalent to procedural programming and can be reduced to lambda calculus. But it does give many affordances to the programmer’s mental model of computation. Any object can be a container for some variables and some methods. This fits the style of most video game construction sets, since the characters in the game have some attributes and know how to perform certain tasks. Most video game construction sets are object-oriented in this way. In a game kit, objects might be implemented with two public methods: time-step and display. A global clock would send each object a time-step message and the object would update its internal state. Then a display message would be sent and any objects that had modified their visible state would be redrawn.
Another benefit to object-oriented programming is inheritance. Since dog and human both know how to walk and run, they could both inherit these methods from a mammal that knows how to do both. The methods are customized, of course, to use each instances’ unique form of locomotion. This is called shadowing, and lets each instance override methods inherited from its parent.
Object-oriented programming helps reduce complexity by adding hierarchy, modularity and abstraction. Objects can choose to be transparent or opaque and expose as much or as little of their internal structure as they want to the world.
One area in which OO programming breaks down is in the interfaces between objects. When two objects collide and interact, where do the methods that control their behaviors go? In a symmetric interaction, there should be only one procedure to describe this. But, in an asymmetric encounter, different behaviors might be programmed for whether the object ran into another, or was run into by another.
This section talks about the structure of the games that can be built by children. What kind of video game can you make with the kit? Is there any storyboarding involved in the game? Can the toolkit support a story-based game? How many players will there be at a time? And how are input events handled by the system?
With all of the discussion centered around issues in construction kit design, it might be easy to overlook the actual reason for creating the construction kit. The purpose is to create video games. But what is a video game? Are there different types? What will the scope of the kit be?
In Chapter Three, there was a discussion of several different construction kits, both general-purpose and game specific. If we could define what kinds of video games we are talking about, we might get a better idea about what specific features should be included.
There are several different types of video games, ranging from the original Pong-like arcade games of the 1960’s and 1970’s to the current Doom and Diablo. We can actually categorize games based on their chronology. Arcade games were first, beginning with SpaceWar! Video arcades grew up around the culture of playing video games and in the late 1970’s and early 1980’s this new culture took off. A new generation of children, including myself, grew up playing Space Invaders, Pac Man and Frogger. One particular favorite of mine was Moon Buggy, where you had to drive a moon rover along a bumpy landscape and avoid getting caught in the craters. These games helped kids develop a lot of hand-eye coordination, but did not do much for their mental agility.
The home gaming market took off with the Atari 2600 and continued with Nintendo’s game kit. This kit introduced the world to the Mario Brothers, who were to star in every version of Nintendo’s game kit, even up until today. With Nintendo, game designers could make goal-oriented video games. The Legend of Zelda was a particularly good game, where you had to maneuver your character through mazes and enemies to find the six crystals and put them together to defeat the evil Ganon. These games consisted of many different levels, each one bringing their own challenges.
The next type of game, the role-playing game, or RPG, was originally a personal role-playing game where several people would get together and take characters through an adventure moderated by a dungeon master. Ultima brought this game to the Apple II and enabled players to roll many different characters and play games over and over again without the hassle of finding other people or a dungeon master to play along. Players had their group of characters explore a fantasy environment to kill creatures for gold and experience. With enough experience, characters went up in levels and could learn new skills. These games took advantage of the general-purpose computer’s power to create truly complex games that took many hours to win.
For a long time, Nintendo and RPG games were just variations of earlier ones. But in 1991, Doom was introduced by Id Software. This was the first first-person viewpoint 3D adventure game. It combined great 3D graphics, rendering, and animation with a shoot-em-up atmosphere that swept homes across the country. Currently, the most popular game of this type is Quake, which added networking features so people could play each other from their own houses.
Game construction kits co-evolved with these games. Soon after the first games came out on the personal computer, Bill Budge introduced his very popular Pinball Construction Set. Allowing children to create their own pinball games proved very popular, since kids could customize their own game and show off their creativity to their friends. Recently, Klik and Play, by Maxis, came out to enable kids to program their own real Nintendo-style video games. Soon, Europress Inc. will come out with The Game Factory 3D, a toolkit for creating Doom-like games.
While the programming of games is much simplified with construction kits, the task of figuring out what to make is still difficult. Nintendo style games include so many levels, characters and story lines that a child needs to be an accomplished writer to come up with everything. How can this cognitive load be lessened, or if not, how can the kit support complex storyboarding?
First, let’s assume there are two types of games that the child wants to create: the shoot-em-up game and the Nintendo-style game. A construction kit may support one or both of these types of games. A shoot-em-up game requires thinking about a scenario and a background for the characters in the game. Perhaps the toolkit could provide suggestive components in its library or sample projects that could lead the child to creating certain types of games. Having a library filled with space ships and aliens would lead naturally to space adventures where the characters can shoot and kill aliens for points. One or two games could be represented in the library, which would provide enough direction for the child to easily come up with ideas for games, but wouldn’t stifle any creative ideas the child may get when they want to combine ideas from different sources into a mosaic game.
If a Nintendo-style goal-oriented game is desired, then there are issues like storyboarding, scenery, and character development involved. Before a child even sits down at the computer, they should be thinking about the game and what they would like in it. Is there a hero on a quest to save a princess? Is there gold and glory to be had? What is the reason for a person to play this game? What puzzles and challenges await the hero along the way? How are these puzzles organized? Must they be completed in order, or can the hero pick and choose the easiest ones to solve first? Are there any special tools or magic items that can help the character out during its quest? Are there any enemies or aliens to fight and get in the hero’s way?
A construction kit could provide some storyboarding support for children who wish to design their game in front of the computer. Macromedia Director contains a type of storyboarding tool which uses a film based metaphor to scripts scenes and segues. Artificial intelligence systems have used thematic role frames to help computers understand scripted actions. A form of these could be used by the child to script major events in a story line. Then, the computer could help the child fill in the required details along the way.
A painting system might be required for users to paint their own scenery in the game. Each screen of the game may contain similar scenery, so perhaps a morphing or graphical mutation system might be included to slightly alter each screen with respect to another. SimCity and Populous allow users to design their own landscape, complete with mountains, plains, rivers and oceans. Populous takes the metaphor that the author is a god, and can make mountains rise from the seas, or cause groundbreaking earthquakes to make the desired landscapes.
A goal oriented kit should also support large-scale production. Games like Legend of Zelda are not small; they involve scores of scenes, and many different transitions. If a kit supported scene cloning, or random monster generation, a child could concentrate on the story line and not get bogged down in boring details.
A multi-player game requires more ingenuity of design than a single-player game. Obviously, the controls for the game need to be duplicated or extended to support the second player. A more subtle problem might be synchronization between different characters and different players trying to affect them.
Where do the players physically reside? They can either all play at one computer, or play at many computers. If they are on one computer, they must contend for resources. There is only one mouse, one joystick and one keyboard. Often, each player will get a few keys on the keyboard to themselves. Are the keys customizable?
Playing on multiple computers requires networking support. It brings up questions of where the game lives. Is it client-server based, or is it distributed? In games like Quake and Diablo, there is a central server hosted by the game manufacturer that is a clearinghouse for distributed localized game servers. Your version of Diablo connects to the main server to find out where a local server is and then connects to the local one to join the game. dMOO, a distributed MOO from Intel explores object architecture issues in distributed systems. User’s objects may contain several replicated copies that exist on many servers. Actions that affect each object are transmitted through to each copy in a lazy consistency model.
How much interaction will the players have? If multiple people are in the world, the object might be creative collaborative construction, as in MOOSE Crossing. It might be Diablo’s model, where players can band together to kill monsters, or kill each other. Is it easy for kids to design games that require collaboration? This question remains to be explored.
Once the programming paradigms have been chosen, how should the system react to the player? In most video games, the interaction comes from a joystick, mouse, keyboard, or network. The system can either embed these interactions in an interaction object, or the user could embed these interactions in each object that needs to react to them.
It makes sense to embed procedures inside objects. But what happens when the object causing the interaction is not “in” the game? External events come in asynchronously and affect the characters of the game. If the characters don’t expect them, then the action could interrupt whatever they might be doing at the time. If characters instead poll for the events, they will never be interrupted unless they are ready to receive an event.
The event could be embedded inside its own “breed” of objects. When a key-up event comes in, it might affect two or three different characters. Inside the event, there must be several places to identify the characters to that will be affected and what to do to them. This approach, while linking the action to the effect, in fact disembodies the effect from the characters it is affecting. There is also another disadvantage. A key-up event and a joystick-up event should rightly go into separate objects, but they might have the same semantic effect on the characters of the game.
The other approach is to embed the event polling inside the character that wishes to receive it. If the system notices an event comes in, on the next time-step message, it would include an event. If the key-up event came into the character and the character wished to respond, it could do anything it wanted. All characters would receive their own key-up notification at the same time, and all effects would be localized to the character which they were affecting. This option allows the kit designer to abstract the lexically different events into semantic groupings and provide the characters with ways to recognize these semantic groups. This reduces duplication of code and brings the programmer closer to the semantic meaning of the program they are writing.
Now that many of the design considerations for creating construction kits for children have been enumerated and discussed, is it possible to create a construction kit that has all or many of the desirable qualities? This chapter describes a design and implementation for a video game construction kit that was designed around the discussion from the previous chapter and attempts to achieve the seven goals of understandability, uniformity and elegance, interactivity, functionality, transparency, powerful ideas, and reflection and audience.
This video game kit’s scope includes Atari 2600 style arcade games, like Pac Man, Frogger and Space Invaders. There are other game construction kits which attempt a broader scope to make Nintendo and Doom-like games, but we feel that there is enough creative design space open for children to make very interesting arcade games. In addition, since arcade games usually don’t get very complex, they would give an easy-to-learn game model that could be modified easily.
The video game kit produces standalone web pages with the games inside. This allows kids to publish their games on the Web, and allows other children to use them and share them. This publication takes place on a central server, so children can easily get access to a large quantity of sample projects and projects created by other children for inspiration and help in their own games. Currently, game design takes place off-line and involves one or more children sitting in front of one computer. In the future, this toolkit could be attached to a web site, and children who surf by will be able to not only play, but also create their own games on-line.
The programming environment for the video game toolkit is a text/graphics hybrid. Drag and drop is used in the high-level movement of objects in the interface, but text-based procedural programming in the Video Game StarLogo language is used for programming behaviors for the characters in a game. There also is a command center, where users can interactively try out commands with their characters and see the results run instantly. This makes this kit very similar in feel to Logo. But it is more domain-specific, since it allows users to easily create breeds of characters that can respond to the user and execute code on every clock-tick. It is not so specific, however, that it could not be used for normal Logo or StarLogo programming. Actually, this kit merely implements a different interface to the StarLogo kernel.
Object-orientation is very important in the design of this kit. It uses a container-based form of object-orientation, similar to Boxer, where most objects are containers for other things. For example, in the game character container, there are several sub-containers: a shape container, a sound container, an event code container, a time-step code container, and an auxiliary code container. Each of those sub-containers holds other objects like shapes, sounds and code. This container metaphor extends from the characters in the game to the game itself. It is also a container that contains meta-information about the game, like the score, the characters on the playfield, and the instructions on how to run the game.
The next section will describe the specific design details of the video game construction kit, starting with the characters of the game, moving through user interaction, and ending with the creation of a game.
This Bongo-based video game construction kit is based on StarLogo, a massively parallel version of Logo for children (Resnick, 1994). In StarLogo, kids program commands for many turtles to execute. Sometimes the turtles all do the same thing, but often, small differences in their positions or internal state cause them to behave very differently from their fellows.
This is also true in most video games. At the very least, the player’s avatar, or “hero,” responds to the player’s real-time commands; it is not just under algorithmic control. In many games such as Pac Man or Space Invaders, there is more than one type of character. StarLogo calls these breeds. Different breeds of turtles may be controlled with different programs. In a Pac Man game, there would be four breeds: pac-man, ghosts, pellets, and power-pellets. In Space Invaders, there are three breeds of characters: heroes, space invaders and bullets.
Using these breeds, we have a way to differentiate among the different characters in the video game. The child should be able to further customize the characters by setting their characteristics. One of these attributes is the shape. Pac Man should look like a yellow pie with a wedge cut out. The ghost should look like a person wearing a sheet over their heads with holes cut out for their eyes.
These shapes, however, might serve only for the default state for the characters. Often, you want the character to look different when it is in different states. While Pac Man is dying, his pie shape should turn upward, and its wedge should open wider and wider until the pie disappears. The default shape of a character can appear as a guideline, but other shapes or animations could be added into a shape container within the breed. Programmers are able to drag shapes from a shape palette into the shape container of the breed, and drag them out again to remove them.
In addition to shapes, a breed might have characteristic sounds to play when the character bumps into a wall or gobbles up a power pellet. Thus, a sound container is also a part of the breed container. This sound container could hold many different sounds that are characteristic to the breed.
Figure 1: Preliminary Breed Editor
After the user has customized the visual and aural components of the breed, they must finish customizing the other state variables. Since a breed is a class of character and not an instance, the particular values of the state variables don’t have much meaning except to serve as initial values for a new instance of that breed. Some state variables that are relevant to turtles include their x and y position, their heading, their pen color and their current shape.
The breed’s behavior can be broken up into three parts: response to events, the time-step action, and auxiliary functions. There are numerous types of events that may occur during game play such as mouse movements and key presses. Other events, like timing events, user-defined events, or even events generated by other characters might be supported as well. In many games, most of these events will not be applicable, but the programmer can specify which ones to listen to. The programmer can write some code that will determine what these characters do when those events occur. This code may call on any primitives in the language, or procedures that are contained within the auxiliary code container of that breed.
When the event-driven code has been finished, the user must specify what will happen on every time-step when there are no other events occurring. For instance, the ghosts in Pac Man wander around the screen randomly whenever they sense that Pac Man is far away. In Space Invaders, the Invaders march in file across and down the screen relentlessly until they are killed or until they reach the bottom of the screen. Again, the code in this section may call on any primitives or procedures that are contained within the auxiliary code container.
Figure 2: Video Game Playing Field
Once the breed has been defined completely, the programmer may create instances of the breed by dragging a copy of the breed from the breed palette to the playing field. When the character has been created in this way, it may be further customized by the programmer. Since the instance of the breed is also a container (but one specific to this particular instance) it may be opened up and examined. It contains an exact copy of all of the information from the breed, but the information inside may be altered without affecting the breed container, or any other instances of that breed. The user may choose to move the character around on the screen, change its shape, or change its personal copy of the breed’s code.
When all of the characters have been laid out on the playing field, the user can customize the background by painting on it with paint tools. They can also load in a GIF as a background image that would be suitable for their game. The characters in the game might be able to sense and react or even modify the background while the game is in play.
Figure 3: Video Game Command Center
Another important piece of the video game construction set is the command center. From here, the user can try out pieces of code, tell a few characters to run their time-step code, or even tell the game to begin. They can also use this window to run commands on all of the characters in the playing field.
In many games, a notion of score is useful to indicate to the player about progress towards a goal. The scoreboard acts just like any other global variable, except that it is a state variable contained within the game itself. Thus, the playing field is also a container for some parts. This container holds a representation of the background of the screen, the characters that are currently residing on it, the score, the time-step code (for the game, perhaps ticking a clock) which by default runs the time-step code of all the characters in the game, and an auxiliary code container.
When the user has finished the entire game, he may play with it in the testing environment, or he may press a button to generate a standalone version of the game that is available for any player to play. This button will auto-generate a web page with the game contained inside, and link it to a web page residing on the server so that the game may be reached from the Web.
While this document has mentioned quite a bit about the specification for the video game construction set, not much attention has been given to the programming language in which the children will control the characters. Video Game StarLogo is a variant of StarLogo and includes the same syntax and semantics. It also supports several new primitives to provide the user with the ability to play sounds, change shapes and detect collisions between creatures due to their on-screen shapes.
StarLogo is a parallel version of the Logo language developed by Mitchel Resnick. All of Logo’s turtle functionality is preserved, but any instruction code applies for all living turtles. When the user writes fd 10, all of the turtles go forward ten turtle steps. By the very fact that there are several hundred turtles around at any given time, this often leads to very unLogo-like behavior. If all of the turtles were oriented in random directions at the center of the screen, and you said fd 10, you would get a circle! (The locus of points equidistant from a center point form a circle.) This is StarLogo’s purpose. Parallel computing requires a new way of thinking about problems and solutions. Resnick’s proposal is the “decentralized mindset” (Resnick, 1994). The best way to think about decentralized systems is to program them yourself in a decentralized manner. While all of your turtles run the same source code, they execute it differently based on their local state and the local interactions they experience.
This SPMD model of computation may seem confusing, but there are several techniques for making it easier to understand. The first is that you can think of each turtle as an independent entity in the calculation. When you program each line of code, each turtle runs it in order. StarLogo does not support multithreading within individual turtles, so each turtle will never have synchronization problems with itself. If my turtle was a ghost in the game of Pac Man, I would have him loop to check if Pac Man is around. If it was around, then the ghost should run after it and eat Pac Man. But, if the ghost is “afraid” because Pac Man just ate a power pellet, then it should run away.
Another technique for controlling complexity is StarLogo’s breed mechanism. In order to manage different classes of turtles, each may be a member of a certain breed. Within StarLogo are primitives of the form ask-<breed> <list-to-run> that specify that a block of code is to be done only by turtles of that breed. This lets you easily specify that half of your trucks are “left” trucks and move to the left, while the other half of your trucks are “right” trucks and only move the right. This breed technique is further expanded in Video Game StarLogo to encapsulate the breed and include its own shapes, sounds, and code.
StarLogo is a procedural language like Logo. Video Game StarLogo, however, is object-oriented, which allows the programmer to more easily distinguish between separate resources intended for different breeds and other elements of the world. Thus, the programming style is more similar to MIMD (multiple instruction, multiple data) programming, since each object has its own code and runs it independently from the others.
The current version of the video game construction kit is implemented in Bongo, a new language created for kids to bring the simplicity of Logo programming to Java. Bongo, written by the author and Brian Silverman, is a dynamic, statically-scoped, object-oriented programming variant of Logo that is run by an interpreter written in Java, thus running on all platforms that support Web browsing (For more information on Bongo, including language documentation, tutorial, and sample projects, see http://www.media.mit.edu/~bongo). Bongo allows us to implement this video game kit as a simple application in a high-level dynamic language that can easily be altered at run-time. Since Bongo is interpreted, it is easy to try out new features in the video game construction kit and update old copies without recompilation. Bongo is also modular, which allows programmers to easily create different microworlds in Java and link them dynamically into Bongo.
The video game construction kit application includes a Java Bongo module, a Video Game StarLogo compiler written in Bongo, and a UI written in Bongo that uses an Intel Java Animation Library to speed up graphic operations. The Java Bongo module implements the StarLogo virtual machine and exports control commands to Bongo as a set of new primitives. It manages the turtles, the turtle code, the patches and the graphics. The compiler is a variant of the Cricket Logo compiler which provides support for breeds and Video Game StarLogo’s particular set of primitives. The UI is written in Bongo and consists of the different editors described in section 5.2.
This section walks through the creation of a Space Invaders game. It illustrates each aspect of the game design so that the reader might gain insight into the development process.
We’re going to make a Space Invaders game. In this classic Atari 2600 game, we have a hero spaceship that the user controls. The hero fires missiles at an incoming army of aliens who are marching back and forth across the screen. When the aliens hit the sides of the screen, they move down a row, and head towards the other side of the screen. If the hero kills all the aliens, he wins. If the aliens ever touch down on the ground, the hero loses and the Earth is destroyed.
There are two ways to begin programming this game with Bongo. One is to go on the Web and use the video game construction kit via Netscape. This version only lets the user save their game to the network. The other option is to run the toolkit locally with a Java interpreter. Running it this way removes any security violation problems the user might have when accessing the local file system.
Once the video game construction kit has been started, the user sees three windows. One is the breed palette, where the user may create, modify and remove breeds from the game. The second is the blank playing field. The user can drag and drop breeds to this field to create characters for the game. The third window is the command center. Here, the user can give Video Game StarLogo commands to any characters that are on the playing field.
First, we’ll assume that there are no libraries for Space Invaders. Therefore, we’ll need to create three breeds: a hero, some aliens, and some bullets. We click on Add Breed in the breed palette and pop a breed editor dialog. First, we name the breed hero. Then, we need a default shape for the hero, so we open up the shapes palette and drag a nice official-looking spaceship into the shape container of the breed editor. This breed should respond to user events, so we customize the Left, Right, and Fire events to run some code.
Left setx xcor - 1
Right setx xcor + 1
Fire hatch [setbreed bullets
setx xcor - 1 moves the character to the left by one turtle step. setx xcor + 1 moves the character to the right by one turtle step. The Fire command first tells the hero to hatch a new turtle and then tell it to set its breed to bullets, set its heading to point up, set its shape to the bullet shape and move up by one turtle step so we can see it.
This breed doesn’t need to do anything while idle, so we click on the OK button to accept our changes. The hero breed shows up in the breed palette.
We need to now add the next breed, aliens. Again, we click on Add Breed in the breed palette and pop another breed editor. We name this breed aliens, and go to the shapes palette to pick a good default shape for it. We drop this shape in its shape container and continue. This breed doesn’t respond to user events, so this section of the code will remain blank.
Then we go to the time-step section. This section is for code that will run on every tick of the clock. We want this alien to move back and forth across the screen and move down every time it hits a wall. Here is some code that will do that:
ifelse (xcor = left-edge) or (xcor = right-edge)
[sety ycor - 2
This code says if the alien’s x-coordinate has reached the left or the right edge, it should go down by two turtle steps, turn around and take a few steps to get away from the wall. If it hasn’t hit the edge, it should just move forward one turtle step across the screen. This code assumes that the alien has been set up to face either side of the screen (heading equals 90 or 270).
Since we’ve got the hero and the aliens, we can test them out before we create the bullets. We drag an alien from the breed palette to the playing field to make an instance of it. Then we type ask-aliens [time-step] in the command center and watch it go. Whoops, we forgot to set up the alien so that it points to the left or right. Double-clicking on it, we get a character editor. This looks very much like the breed editor, but it has a command center on the bottom that only affects this character. In it we type rt 90, to turn it sideways, facing to the right. We close up this editor and try running ask-aliens [time-step] again. This time it works. Let’s now do ask-aliens [repeat 100 [time-step]]. The alien moves across the screen, just like we wanted. When it hits the wall, it goes down, and turns around to head in the other direction.
If we have more than one alien, it will get tedious to keep saying rt 90 to set them up. We can open up the aliens breed editor again, and set the initial value of heading to 90, so all new aliens will already point in the correct direction.
Now, we can drag a hero onto the board and try it out. The video game construction kit supports keyboard and button controllers. We click on the Left button, and the hero moves to the left. Then we click on the Right button, and the hero moves to the right. If we click on the Fire button, we get an error, that we don’t know what the breed bullets is.
So, let’s make the bullets breed. We click on Add Breed and pop open another breed editor. Then we name it bullets. We go to the shapes palette and pick a default bullet shape for this breed and drop it into the shapes container. This breed doesn’t respond to user events, but it needs some time-step code:
if count-aliens-touching > 0
if ycor = top-edge [die]
This code says if the bullet touches any alien, then it should kill it, explode, and die. Otherwise it should continue moving up the screen by one turtle step and if it reaches the top of the screen, it should die.
We need to define that explode command. This should change the shape of the bullet to the explosion animation. (Animations are just containers for multiple shapes that either play through once, or cycle.) Well, going to the shapes palette, we drag out an explosion animation and drop it into the shapes container. Then in the auxiliary code section of the breed editor we do:
This defines a new procedure named explode that sets the shape of the turtle to the explosion animation. The explosion animation had been set up to play the explosion shapes one time through, so before the bullet dies, it will appear to explode.
We’ve now finished creating the breeds, so let’s create our characters. First, we have to drag those practice characters to the trash. Then we drag out one hero for the game and place him in the center of the bottom edge of the window.
Now we need a lot of aliens. But placing 30 or so aliens is a real pain. We can do it programmatically instead. Going to the command center, we type in create-aliens 36. This creates 36 new aliens on the screen. Now, a neat mathematical way to get them in a block involves their unique turtle number, or who, and some division. We say
ask-aliens [setx (who mod 9) * 2 - 10
sety (who mod 4) * 3 + 15]
Ask-aliens tells only the aliens to do what is inside the list. They set their x-coordinates to their who mod 9 (which returns a number from 0 to 8), multiply by 2 to get some spacing and subtract 10 to be in the correct offset from the center. Then, the sety command is similar but it sets their y-coordinate to their who mod 4 (returns values from 0 to 3), multiply by 3 for some spacing, and then add 15 to be in the correct place on the screen.
We don’t have need any bullets on the screen yet—not until the hero creates some by invoking the Fire event.
Now, we’d like to test out everything. We know that the aliens and the hero work, but we haven’t yet tested whether the Fire command works, or if the bullets can actually kill the aliens. Starting the game by pressing the large Go button in the corner of the playing field, we can try it out. When we press the Fire button, the bullet is hatched and starts running up the screen. It hits an alien and blows up, killing the alien and itself. But, we didn’t get any points. We’ve got to fix up the bullet’s time-step function:
if count-aliens-touching > 0
setscore score + 10
if ycor = top-edge [die]
Now we get 10 points for every alien that is killed. Fire! Another bullet flies up the screen, but this one misses the aliens. It disappears at the top of the screen. Good. Let’s wait and see what happens when all the aliens arrive on the ground. Oops, they kept going through the bottom of the screen and wrapped around the top. We forgot to end the game if they hit the bottom. Let’s edit their time-step method:
ifelse (xcor = left-edge) or (xcor = right-edge)
[sety ycor - 2
if ycor - 2 <= bottom-edge [set game-over? true]
That’s better, now when the alien gets close enough to the bottom edge, it sets the system global variable game-over? to true and ends the game. Now, let’s start over again by hitting Reset (which sets up the game to what it looked like right before we pressed Go). Then we hit Go again, and try killing all of the aliens. But the game didn’t stop. Oops, again, let’s edit the bullet’s time-step function to make the game end when it kills the last alien:
if count-aliens-touching > 0
setscore score + 10
if count-aliens = 0 [set game-over? true]
if ycor = top-edge [die]
OK, now the game is finished. One last test to make sure it works, and then we press the Make Game button. This wraps up our code, our shapes, our characters and creates a new Web page for us with the game inside. We can open this up in Netscape and play it, or put it up on our website and allow others to play the game too. W also add a mailto link to the HTML page to allow other people to give us feedback about the game later on.
Figure 4: Space Invaders game running inside Netscape
Does the Bongo-based video game construction kit meet all of its design objectives? There were seven design criteria presented in Chapter Four that were expounded upon in detail. This thesis covered a range of topics from game construction to the programming environment, and with each, attempted to show what kinds of effects each option had on the overall system. Bongo does implement many of the recommendations made in Chapter Four.
Understandability: Understandability was said to be linked to a construction kit’s metaphors, language and tools. Bongo’s container-based object-orientation metaphor is key in achieving understandability. The attributes of an object, such as the shapes, sounds, code, and state variables, reside inside that object, thus giving the user a sense of locality. The programming language and the turtle metaphor is based on Logo, so the techniques of body syntonicity are helpful to the programmer when trying to script a character’s action. The direct manipulation interface also allows the children to manipulate each character, shape and breed in the system as if its iconic representation were the real thing.
One area where this video game construction kit might go further is to have better video game specific knowledge. In the example game of the last section, we had forgotten to include a way to end the game. Perhaps a game parser could look over the child’s shoulder while they are working, and suggest game features that should not be forgotten. More knowledge about how video games are constructed and played might bring some needed domain-specificity to this general-purpose design tool.
Uniformity and Elegance: Bongo’s container-based object-orientation system provides a large amount of uniformity to the construction kit. All objects are either containers or primitive objects contained within other containers. Elegance of programming comes from the StarLogo programming language. In its history, StarLogo has undergone several language transformations in an attempt to make it less redundant and much more expressive. Video Game StarLogo inherits this elegance from the latest version of StarLogo, which introduced the concept of breeds. Children can control and program breeds of turtles independently. The container system refines this further, allowing children to put code within the container that it affects, and no longer have to specify the code’s target in the procedure body.
Interactivity: This construction environment also allows full interactive development of video games. The direct manipulation drag and drop interface gives children an intuitive notion of how they can combine and construct their own compound objects and structures. Characters can be dragged to the playing field to add them to the game. Objects can be opened up and inspected to see what kinds of attribute objects live inside. At several times during development of the example from Section 5.5, we were able to test out different characters to see if the programmed behavior was correct. We had made several mistakes, but due to the graphical nature of the environment, they were quite easy to find and fix.
Functionality: The video game construction kit achieves full functionality in the domain of video game creation. Atari 2600 arcade-style games can be constructed easily and efficiently in this environment. However, input modalities are limited. Currently, Bongo supports keyboard and button inputs. However, joystick and mouse inputs would be desirable especially in the video game genre. Collaborative construction and multi-player games are also not possible at this time.
Transparency: This construction kit is written in Bongo, a language very similar to Logo. Not coincidentally, Bongo is quite similar to StarLogo, and thus to Video Game StarLogo. If children ever get curious about how the video game toolkit itself is constructed, they may easily open up the source code and read it for themselves. But Bongo is object-oriented, while Video Game StarLogo is only object-oriented when augmented by the video game interface. This has the consequence that children not familiar with object-orientation and/or Java programming might become quite confused when trying to understand the low-level implementation. This is not necessarily a flaw in this toolkit, but can be used as leverage. Since the Bongo language is very similar to Video Game StarLogo, the children can at least read the code without learning a new syntax, even though they might not fully understand its content.
Powerful Ideas: Video games are in the kid culture and will remain in a central position for a long time to come. Therefore, creating a powerful construction tool for children to make their own video games definitely gives them leverage through which to explore domains and discover powerful ideas. Through programming the characters of a video game, children encounter ideas about feedback, control, abstraction, hierarchy, debugging and much more. These skills are very helpful in exploring other domains in their fields of interest.
Reflection and Audience: The last goals of construction kit design are reflection and audience. Bongo’s video game construction kit allows children to interactively and iteratively design their video game. They may make mistakes; they might scrap their grandiose plans to make the next Doom; but they can keep trying and designing until they have created their very own unique video game. Bongo’s Java support provides children with the opportunity to not just create these games, but to also publish them on the Web. This form of publishing and its ensuing feedback from a wide variety of sources enable children to reflect upon their work as proud parents, always tweaking and fixing little things until they move on to a new project.
This thesis has discussed many different design considerations of which authors of game construction kits for children should be aware. The Bongo-based video game construction kit described in the previous chapter addresses many of those design issues, in an attempt to create a tool that provides children with understandability, uniformity and elegance, interactivity, functionality, transparency, powerful ideas, and reflection and audience.
While the toolkit achieves these goals, there is much potential for further development. Much educational research has recently been focused on creating communities of learners and collaborative environments on the Internet. The Bongo-based video game toolkit is net-friendly, but game development takes place off-line. We would like Bongo to support collaborative network-based projects, where children could work either synchronously or asynchronously with each other.
The Epistemology and Learning Group at the MIT Media Laboratory has been thinking about creating a new virtual world for kids, similar to MOOSE Crossing, but graphical instead of textual. Children will be able to create graphical autonomous objects which exhibit programmable behavior. Children will also be able to work collaboratively on joint projects. For example, in one room, several children might built a checkers board out of 64 square objects of alternating colors, and 24 circle objects of the different colors. Then two children could play checkers against each other. Another group of kids could build robot objects that played tag as they ran around the rooms of the virtual world. This shared world approach would also work for building video games and other projects. Each room could have its own rules about object behaviors and support their own microworld. This room approach would also easily enable sharing and playing of other people’s projects simply through navigation of the shared world. Similar to Robot Odyssey, a new child could explore literally hundreds of rooms, each with its own interesting project inside that was created by other kids.
In conclusion, since design activities are such an important part of a child’s education, it makes sense to create good construction tools to support such activities. This Bongo-based video game construction kit is one possible construction tool to open up another pathway for a child to explore.
Abelson, H., diSessa, A. (1981). Turtle Geometry: The Computer as a Medium for Exploring Mathematics. Cambridge, MA: MIT Press.
Begel, A. (1996). LogoBlocks: A Graphical Programming Environment for Interacting with the World. Advanced Undergraduate Project. MIT.
Braitenberg, B. (1984). Vehicles: Experiments in Synthetic Psychology. MIT Press: Cambridge, MA.
Bruckman, A. (1997). MOOSE Crossing: Construction, Community, and Learning in a Networked Virtual World for Kids. Ph.D. Dissertation. MIT Media Laboratory.
Cypher, A. (1996). Personal Communication. Child’s Play ‘96.
diSessa, A. (1986). Notes on the Future of Programming: Breaking the Utility Barrier. In D. Norman, S. Draper. (Eds.) User Centered System Design: New Perspectives on Human Computer Interaction. Hillsdale, NJ: Lawrence Erlbaum.
diSessa, A. (1986). Models of Computation. In D. Norman, S. Draper. (Eds.) User Centered System Design: New Perspectives on Human Computer Interaction. Hillsdale, NJ: Lawrence Erlbaum.
diSessa, A., Abelson, H. (1986). Boxer: A Reconstructible Computational Medium. Communications of the ACM. 29(9). 859-868.
Eden, H., Eisenberg, M., Fischer, G., Repenning, A. Making Learning a Part of Life. Communications of the ACM. 39(4). 40-42.
Fischer, G., Lemke, A. (1987-88). Construction Kits and Design Environments: Steps Toward Human Problem-Domain Communication. Human-Computer Interaction. 3. 179-222.
Fischer, G. (1993). Conceptual Frameworks and Computational Environments In Support of Learning on Demand. Submitted to NATO Advanced Workshop “The Design of Computational Media to Support Exploratory Learning.”
Gosling, Joy, and Steele. (1996). The Java Language Specification. Reading, MA: Addison-Wesley.
Guzdial, M. (1994). Software-Realized Scaffolding to Facilitate Programming for Science Learning. Interactive Learning Environments. 4(1). 1-44.
Harel, I. (1988). Software Design for Learning: Children’s Construction of Meaning for Fractions and Logo Programming. Ph.D. Dissertation. MIT Media Laboratory.
Harel, I., Papert, S. (Eds.) (1991). Constructionism. Norwood, NJ: Ablex.
Hutchins, E., Holland, J., Norman, D. (1986). Direct Manipulation Interfaces, In D. Norman, S. Draper. (Eds.) User Centered System Design: New Perspectives on Human Computer Interaction. Hillsdale, NJ: Lawrence Erlbaum.
Jenkins, H. (1993). “x Logic”: Repositioning Nintendo in Children’s Lives. Quarterly Review of Film and Video. 14(4). 55-70.
Kafai, Y. (1993). Minds in Play: Computer Game Design as a Context for Children’s Learning. Ph.D. Dissertation. MIT Media Laboratory.
Kafai, Y., Resnick, M., Eds. (1996). Constructionism in Practice. Mahwah, NJ: Lawrence Erlbaum.
Martin, F. (1994). Circuits to Control: Learning Engineering by Design LEGO Robots. Ph.D. Dissertation. MIT Media Laboratory.
Martin, F. (1996). Ideal and Real Systems. A Study of Notions of Control in Undergraduates Who Design Robots. In Y. Kafai, M. Resnick (Eds.), Constructionism in Practice. Mahwah, NJ: Lawrence Erlbaum.
Minsky, M. (1985). Society of Mind. NY: Simon and Shuster.
Norman, D. (1986). Cognitive Engineering, In D. Norman, S. Draper. (Eds.) User Centered System Design: New Perspectives on Human Computer Interaction. Hillsdale, NJ: Lawrence Erlbaum.
O'Shea, T. (in press). Mindstorms 2: A review of The Children's Machine. To appear in Interactive Learning Environments.
Palmen, S. (1995). Apple Dylan. MacTech. 11(8). 41-53.
Papert, S. (1980). Mindstorms: Children, Computers and Powerful Ideas. NY: Basic Books.
Papert, S. (1993). The Children’s Machine: Rethinking School in the Age of the Computer. NY: Basic Books.
Papert, S. (1996). The Connected Family: Bridging the Digital Generation Gap. Atlanta, GA: Long Street Press.
Repenning, A. (1994). Programming Substrates to Create Interactive Learning Environments. Interactive Learning Environments. 4(1). 45-74.
Repenning, A. (1996). Personal Communication. Child’s Play ‘96.
Repenning, A., Ambach, J. (1996a). Visual Agentalk: Anatomy of a Low Threshold, High Ceiling End User Programming Environment. CU-CS-802-96.
Repenning, A., Ambach, J. (1996b). Tactile Programming: A Unified Manipulation Paradigm Supporting Program Comprehension, Composition and Sharing. In Proceedings of Visual Languages ‘96.
Resnick, M. (1990). MultiLogo: A Study of Children and Concurrent Programming. Interactive Learning Environments. 1(3), 153-170.
Resnick, M. (1994). Turtles, Termites and Traffic Jams: Explorations in Massively Parallel Microworlds. Cambridge, MA: MIT Press.
Resnick, M., Bruckman, A., Martin, F. (1996). Pianos not Stereos: Creating Computational Construction Kits. Interactions. 3(5). 41-50.
Resnick, M., Martin, F., Sargent, R., Silverman, B. (1996). Programmable Bricks: Toys to think with. IBM Systems Journal 35(3/4). 443-452.
Resnick, M., Rusk, N. (1996). The Computer Clubhouse: Preparing for Life in a Digital World. IBM Systems Journal 35(3/4). 431-439.
Sargent, J. (1995). The Programmable LEGO Brick: Ubiquitous Computing for Kids. Master’s Thesis. MIT Media Laboratory.
Scardamalia, M., Bereiter, C. (1994). Computer support for knowledge-building communities. The Journal of Learning Sciences. 3(3), 265-283.
Schneiderman, B. (1992). Designing the User Interface: Strategies for Effective Human-Computer Interaction.. 2nd Edition. Reading, MA: Addison-Wesley.
Smith, D., Cypher, A., Spohrer, J. (1994). KidSim: Programming Agents Without a Programming Language. Communications of the ACM. 37(7). 54-68.
Smith. R., Wolczko, M., Ungar, D. (1997). From Kansas to Oz: Collaborative Debugging When a Shared World Breaks. Communications of the ACM. 40(4). 72-78.
Songer, N. (1996). Exploring learning opportunities in coordinated network-enhanced classrooms: A case of kids as global scientists. Journal of Learning Sciences.
Sutherland, I. (1963). Sketchpad: A man-machine graphical communication system. Proceedings of the Spring Joint Computer Conference, 329-346.
Travers, M. (1996) Programming with Agents. Ph.D. dissertation. MIT Media Laboratory.
Turkle, S., Papert, S. (1991). Epistemological Pluralism: Styles and Voices Within the Computer Culture. In I. Harel, S. Papert (Eds.), Constructionism. Norwood, NJ: Ablex.
Umaschi, M. (1997). Soft Interfaces for Interactive Storytelling: Learning about Identity and Communication. Masters Thesis. MIT Media Laboratory.
Winograd, T. (1995). From Programming Environments to Environments for Designing. Communications of the ACM. 38(6). 65-74.