StarLogo TNG: An Introduction to Game Development

Andrew BegelUniversity of California, Berkeley

abegel@cs.berkeley.edu

Eric KlopferMassachusetts Institute of Technology

klopfer@mit.edu

December 24, 2004

Abstract

The science of developing computer programs offers arich educational experience that can help students gainfluency with information technology. Unfortunately,while computers have become commonplace in schools,the practice of teaching programming is being squeezedout of high school and middle school curricula. We be-lieve that programming should be reintroduced to stu-dents, and that this can be done by focusing on videogame construction, a compelling subject area for manystudents. Given the current expertise required to cre-ate a modern video game, new tools are needed to makethis experience accessible to students. We have devel-oped StarLogo TNG, a visual programming- and 3D-based environment that enables students to easily pro-gram their own games. It uses graphical programming toease the learning curve for programming, and 3D graph-ics to make the developed games more realistic. An ini-tial pilot study has shown that these innovations appealto students, and in particular appeal to girls.

1 Introduction

In today’s world, computer literacy is a required skill,just like the ability to read, write, do arithmetic, andcommunicate one’s ideas to others. In order to pre-pare children to enter this adult world, it is necessaryto provide them instruction in the constructive use ofcomputers. While many children already understandhow to consume information with a computer (i.e. lis-ten to audio files, watch movies, or browse the web),

they often do not get the chance to produce content (i.e.author their own home page, compose and play theirown computer-based music, or produce their own homemovie). In other words, when it comes to computers,children know how to “read,” but do not often knowhow to “write.” School activities tend to concentrate onobvious job skills, such as training with word proces-sors, spreadsheets and accessing databases. But to gaina real fluency with technology, children require a newset of skills (Murnane & Levy 1996). In 1999 the Na-tional Academies of Science outlined a set of FITnessskills (National Research Council 1999) that defined theways in which students will need to be able to use infor-mation technologies for their personal and professionallives in the coming years. These skills include:

• Engage in sustained reasoning– Students havethe ability to plan, design, execute and evaluate so-lutions to problems.

• Manage complexity/Expect the unexpected–Students are able to plan a project, design a solu-tion, respond to unexpected interactions/outcomesand diagnose what is needed for each task.

• Test a solution– Students determine the scope, na-ture and conditions under which a solution is in-tended to operate. A solution to a problem must betested to determine that the solution is appropriateto the problem at hand.

• Organize and navigate information structuresand evaluate information – Students have theability to locate, assess and use relevant informa-tion.

1

• Collaborate – Students have a clear sense for howthe various parts of a problem are made to oper-ate together, as well as the expectations for his orher own part, and strategies for ensuring that teammembers work appropriate parts of the problem.

• Communicate to other audiences– Students un-derstand the needs of their audience and use ap-propriate language and tools to communicate effec-tively.

These principles center on the idea that we must cre-ate a culture in which students can navigate novel prob-lem spaces and collaboratively gather and apply datato solutions. Resnick (Resnick 2002) suggests that anequally important goal is for educational programs tofoster creativity and imagination. In other words, stu-dents should be acquiring habits of mind that will notonly enable them to address today’s problems and so-lutions, but will also allow them to venture into pre-viously unimagined territories. To achieve this, theyshould have a facility with tools to create manifestationsof their ideas so that they can test them and convey theirideas to others.

1.1 Computer Programming

Computer programming is an ideal medium for studentsto express creativity, develop new ideas, learn how tocommunicate ideas, and collaborate with others. Themerits of learning through computer programming havebeen discussed over the years (Harel 1990, Papert 1993,Kafai 1995, Kafai 1996). As a design activity, computerprogramming comes along with the many assets asso-ciated with ”‘constructionist”’ (Harel & Papert 1991)learning. Constructionism extends constructivist theo-ries, stating that learning is at its best when people arebuilding artifacts. These benefits of learning throughbuilding include (Resnick, Rusk & Cooke 1998):

• Engaging students as active participants in the ac-tivity

• Encouraging creative problem solving

• Making personal connections to the materials

• Creating interdisciplinary links

• Promoting a sense of audience

• Providing a context for reflection and discussion

As students learn to conceptualize and develop theirown computer programs, this specific type of design andconstruction activity comes along with many potentiallearning outcomes. Some of these apply specificallyto the opportunities opened by the knowledge of com-puter programming, which alone can provide access towhole new worlds of exploration (Wolfram 2002). Otherlearning outcomes from programming are more broadlyapplicable. Typical programming activities center onthe notion of problem-solving, which requires studentsto develop a suite of skills that may be transferable toother tasks. As students learn to program algorithmsthey must acquire a systematic reasoning skills. Mod-eling systems through programs teaches students how tobreak down systems into their components and under-stand them. Many problems require students to acquireand apply mathematical skills and analysis to developtheir programs and interpret the output. Together theseskills comprise a suite of desirable learning outcomesfor students, many of which are difficult to engenderthrough typical curriculum. They can also form the cor-nerstones of true inquiry-based science (American As-sociation for the Advancement of Science 1993), pro-viding students with a set of skills that allows them toform and test hypotheses about systems in which theyare personally interested.

1.2 Programming Education

Computer programming was widely introduced toschools in the early 1980s, largely fueled by cheap per-sonal computers, and inspired by Papert’s manifesto,Mindstorms (Papert 1980), which advocated that pro-gramming in Logo was a cross-cutting tool to helpstudents learn any subject. Logo was popularly usedto to enable students to explore differential geometry,art, and natural languages. Microworlds Logo (LogoComputer Systems Inc. 2004) extended this use intomiddle school where students continued to learn aboutmathematics, science, reading and storytelling. Kid-Sim/Cocoa/Stagecast Creator (Cypher & Smith 1995)

2

brought modeling and simulation to children througha simple graphical programming interface, where theycould learn thinking skills, creativity, and computer liter-acy. Subsequent work with Stagecast Creator has shownsome success in building students’ understand of simplemathematical concepts through building games (Lucenan.d.). Boxer (di Sessa & Abelson 1986) is used tohelp students in modeling physics and mathematicalreasoning, while building understanding of functionsand variables. Kafai (Kafai 1996) introduced novelparadigms for helping students learn about mathematicsand social and relational skills through programming ofgames. Through this paradigm, older elementary schoolstudents use Logo to develop mathematical games foryounger elementary students. It is of note that most ofthese efforts have been targeted at elementary schoolaged children. Few efforts have targeted the middleschool and high school audience.

Despite many small-scale research efforts to exploreprogramming in schools, Papert’s larger vision of perva-sive programming in school curricula encountered someserious problems. Programming did not fit into tradi-tional school structures and required teachers to give uptheir roles as domain experts to become learners on parwith the children they were teaching. (Agalianos, Noss& Whitty 2001) Correspondingly, teachers grew disil-lusioned and tried to marginalize programming in theircurricula, going so far as to put it into its own subject,computer science. Computers were used to teach typingskills, and Papert’s vision of programming as a vehiclefor learning seemed to be dead in the water.

With the growing popularity of the Internet, manyschools have revisited the idea of computers in the class-room and rediscovered their utility in the educationalprocess. Schools now use computers to target job-oriented skills, such as word processing and spread-sheets. Some schools encourage children to create massmedia, such as computer-based music, animations ormovies. For the last several years, the state of Maine hasprovided laptops to all of its 7th and 8th grade students(and teachers) to make computers a ubiquitous tool inevery subject in school (State of Maine 2004).

Now that computers in school are enjoying a resur-gence in popularity, it is time to reconsider programmingas a vehicle towards fluency in information technology.

2 Programming Revisited

The benefits of computer programming have inspired usto revisit the use of computer programming in the class-room, and see if there are ways that we can reintroduceprogramming into the curriculum. One way we feel toincrease interest is to move programming in a directionwhere it would be easy to build video games.

Why should video games be part of a school curricu-lum? Kafai (Kafai 1995) makes a compelling case forteaching young children to program by using games asa focal piece. The advocacy and research group, Edu-cation Arcade (The Education Arcade 2004), has devel-oped pedagogy for integrating games in math, scienceand humanities curricula to better understand what ben-eficial roles games might play in educational activities.Games have the potential to entice today’s youth intoprogramming. Today’s middle and high school studentshave grown up with video games as a part of their cul-ture. For many it is what entices them to use technol-ogy. While boys still currently invest more time in gameplaying than girls, the gap is rapidly closing and bothboys and girls have become avid gamers. Through thisfamiliarity with games, students have begun to developone half of a video game literacy - they have learnedto “read.” But they have not yet developed the otherhalf of that literacy - learning to write. But we can usethe existing half of their literacy to lead them into writ-ing, thereby connecting their interest and knowledge ofgames to the practice of programming.

Game design and construction require that studentslearn programming skills; through careful design of theactivity and the environment in which it is enacted it ispossible to teach children how to make games and inci-dentally learn programming. One might ask how learn-ing about games will help at all to learn how to program.Games have a lot of natural connections to programs, forexample, most games have animated characters that re-act to control by human players. These animations andtheir sequencing and reactions must be scripted to be-have properly. Characters’ behaviors are all based onmodels of behavior that are implemented by algorithmsand whose state is stored in user-defined data structuresmaintained by the characters. Choosing data structureswisely is important to making a game play well and

3

efficiently. Computer-controlled characters incorporateforms of artificial intelligence to decide how to interactwith the player’s character. Even simply enumeratingall the characters’ behaviors is similar to planning outthe features of a computer application during design.

Storyboarding a game requires knowledge of se-quencing and branching which resemble binary deci-sion diagrams used in operations research applications.Game scenery design involves both creating an artis-tic look and a game environment’s functional behav-ior. Generating realistic-looking flora and landscapestaps into fractal geometry and iterative functions, both ofwhich have very strong ties to the mathematics of recur-sive functions. Reality-based sporting games often linkto large databases of statistics to help specify the vir-tual characters’ behaviors. Simulation games like Sim-City are based on mathematical models of city planning,geology or human behavioral systems, all of which re-quire algorithm design and data structures. Games havea significant non-deterministic component (the humanplayer), so they often exhibit unexpected behaviors. De-bugging these behaviors requires long hours of testing toidentify, diagnose and correct problems.

3 Video Game Construction Kits

The complexity in making professional quality videogames has risen steadily since hackers built the firstvideo games (e.g. Spacewar!, Pong) to the point wheremaking games requires an entire Hollywood productioncrew, with actors, writers, and directors in addition to alarge team of programmers. Despite their complexity,these games are not sealed products. A large commu-nity of developers and hobbyists have used “modding”tools to customize games using new skins for characters,weapons and environments. While game engines likeQuake and Doom make this process relatively straight-forward, they all require a fair degree of sophisticationand programming expertise to do anything more thanimport new characters (including adding new behav-iors).

This need for programming expertise may appear tobe an insurmountable obstacle in enabling children tomake professional-quality games, but this has not al-ways been true. Commercial efforts to develop game

construction kits for children have successfully em-ployed a simple click-and-drag paradigm to make gameconstruction easy. Some of these kits, which includeKlik ’N Play and The Game Factory (Budge 1983, Eu-ropress Software Ltd. 2004, Clickteam S.A.R.L. 2004),were used for building real-time strategy games. Unfor-tunately, while the click-and-drag metaphor lowers theinitial barriers to building a game, it lowers the ceiling aswell. By contrast, a full-fledged programming environ-ment would allow developers to create virtually limitlesstypes of games.

Many general programming toolkits have been usedby instructors as platforms upon which children canbuild games (Logo Computer Systems Inc. 2004, In-galls, Kaehler, Maloney, Wallace & Kay 1997, Repen-ning & Sumner 1992). These toolkits have recentlygrown more scarce due to a de-emphasis of program-ming in the curriculum and the sophistication of toolsrequired to create the photo-realistic three-dimensionalrenderings of modern games. Alice 3D (Conway,Pausch, Gossweiler & Burnette 1994) is one tool thathas tried to make this jump. It is a 3D modeling and pro-gramming environment, though its level of sophistica-tion makes it most appropriate for advanced high schooland early college students.

We are trying to address this scarcity of tools. Theway to make video game toolkits that are easy to useby children is to tap into the same increase in computerpower that engendered the rise in game complexity. Theabundance of CPU power enables us to create a gameconstruction environment that already includes the greatgraphics, character animations, sounds and storyboard-ing; all that is left for the child to do is to come up withan idea for a game, design the game levels, create thecharacters’ looks, and program their behavior.

In the next section, we introduce the StarLogo pro-gramming environment and discuss how we have en-hanced it to be a platform that enables children to createvideo games.

4 StarLogo

Over the past years we have been working with Star-Logo, a programmable modeling environment that em-

4

Figure 1: The left-hand panel shows a StarLogo modelof an epidemic in action. One can see the interface area,in which users can start and stop the model and adjustparameters, the running model where the different colorscode for different states, and the graphs at the bottomtracking model data. The right-hand panel shows thecode that was written to generate this model.

braces the constructionist paradigm of learning by build-ing. StarLogo was designed to enable people tobuild models of complex, dynamic systems. In StarL-ogo (Resnick 1994), one programs simple rules for indi-vidual behaviors of agents that “live” and move in a two-dimensional environment. For instance, a student mightcreate rules for a bird, which describe how fast it shouldfly and when it should fly towards another bird. BecauseStarLogo makes use of graphical output, when the stu-dent watches many birds simultaneously following thoserules, she can observe how patterns in the system, likeflocking, arise out of the individual behaviors. Build-ing models from the individual, or “bird” level, enablespeople to develop a good understanding of the system,or “flock” level behaviors (Figure 1 shows the graphicalinterface for the growth of an epidemic, another phe-nomenon that can be studied in terms of complex adap-tive systems).

4.1 StarLogo for Games

In the 1990s, a few of our undergraduate researchersworking on StarLogo began to build simple video

games, such as PacMan, Frogger, and Space Invaders.It turned out that StarLogo’s graphical turtle metaphorgeneralized quite nicely to user-controlled charactersthat could be programmed to play out the video game’sbehaviors. Some aspects of game design were notideal, however. StarLogo’s complex text-based lan-guage has always skewed it towards high school studentsand older. Our experiences with these games inspiredthe development of the Bongo video game constructionkit (Begel 1997), which helped scaffold the game de-sign and construction process around three main designfeatures: scene, character and story. Paint tools enabledchildren to draw the scene and lay out the initial posi-tions of all the characters. Characters and their interac-tions were designed next, followed by the rules for thegame and their enactment in the program. The game’scharacters and story were still programmed in StarLogo,however, which limited Bongo’s accessibility.

In the next section, we discuss a new incarnation ofStarLogo which encourages the design of compellinggames and makes them easy for children to program.

5 StarLogo: The Next Generation

We are designing the next generation of StarLogo to be amore satisfying game creation environment. The initialgoal is to make it suitable for making the 3D equiva-lent of platform games or “scrollers”, games in which acharacter moves across a scrolling landscape, encounterother characters and sets out on a mission (e.g. SuperMario Brothers). While we expect this environment tobe able to create many other kinds of games, given real-istic expectations, we do have to constrain the kinds ofgames that we expect children to build to make sure thatthe design is programmatically tractable. For example,it is important to have only a few characters, since theplayer can only easily control one, and artificial intelli-gence algorithms for controlling game characters are noteasily generalized to any arbitrary game a child mightwant to build. A small world is desired so the child’sentire game construction time is not taken by designingthe level and drawing in the scenery.

These goals have guided the development of our newprogramming environment called “StarLogo: The Next

5

Generation” (StarLogo TNG). StarLogo TNG incorpo-rates two major changes from previous versions of Star-Logo – Spaceland,1 which provides a 3D perspective ofthe game in action, and StarLogoBlocks, which providesa graphical interface for building games. In this redesignprocess, knowledge of our audience – primarily middleschool through high school and college – and the con-text in which these tools might be used helped inform usas we made decisions on the level of sophistication wewould require of the user. Often this tradeoff involvesproviding fixed properties or characteristics to the envi-ronment, which makes getting going very quick, but inturn can limit choices and flexibility. Things like low-level control, 3D rendering, and the like were fixed intheir functionality as a result.

5.1 Spaceland

As people today are inundated with high quality 3Dgraphics on even the simplest of gaming platforms, stu-dents have come to expect such fidelity from their com-putational experiences. While the 2D “top-down” viewof StarLogo is very informative for understanding thedynamics and spatial patterns of systems, it is not par-ticularly enticing for students. Additionally, students of-ten have difficultly making the leap between their ownfirst-person experiences in our kinesthetic learning Ac-tivities, and the systems-level view of StarLogo.

Enter “Spaceland,” a three dimensional OpenGL-based view of the world. This world can be navigatedvia keyboard controls (and soon by an on-screen nav-igator). The default view is similar to the old StarL-ogo view, being a top-down representation (Figure 2a).However, from this view, the user can zoom in on anyportion of the world for a closer look and view the 3Dlandscape as they fly by. The other available view is the“Turtle’s Eye” view (Figure 2b) in this representation,the user sees out of the “eyes” of one of the turtles in thesystem. As the turtle moves around they see what theturtle sees. This works particularly well in seeing howturtles bump off of objects, or interact with other turtles.Of course, it is not just turtles per se, but shapes can be

1The name Spaceland is inspired by Edwin Abbot’s “Flatland”where two-dimensional creatures discover the three dimensional worldcalled Spaceland.

Figure 3: Runtime view

imported so that they agents in the system are turtles orspheres or Mario (Figure 2). The ability to customize thecharacters provides a sense of personalization, concreterepresentation, and also of scale. Lending further to thecustomization capabilities are the abilities to change the“Skybox” background (the bitmap image shown in thedistance) as well as the texture, color and topography ofthe landscape. Since the top-down view is also still quiteuseful, that 2D view is seen in an inlaid “mini-map” inthe lower-left corner of the screen (but may be reposi-tioned as the user sees appropriate).

In runtime mode, users will see not just the 3D rep-resentation of the world, but also the tools to edit thelandscape and the runtime interface (buttons and slid-ers) with which a user can interact to start and stop themodel, or change parameters on the fly ( 3).

5.1.1 Additional 3D Benefits

Making games is just one reason to switch to a 3D envi-ronment from the 2D representation of the existing Star-Logo. While making it easier to initially engage stu-dents through a more up-to-date look, a 3D representa-tion has additional advantages. A 3D view can make theworld feel more realistic. This can actually be a limita-tion in modeling and simulation, in that students feel thatmore realistic-looking models actually represent the realworld, but in the proper context, a more realistic-lookingworld can be used to convey useful representations ofscale and context – for example, conveying the sense ofa landscape or the changing of seasons. Moreover, the

6

Figure 2: Top-down and turtles-eye views in TNG

3D view of the world is what people are most famil-iar with from their everyday experiences. Making theleap into programming already comes with a fairly highcognitive load. Providing people with as familiar an en-vironment as possible can lighten that load and makethat leap easier. Similarly, a navigable 3D landscape canprovide a real sense of scale to a model that otherwiseappears arbitrary and abstract to a novice modeler. Fi-nally, with the proliferation of 3D tools (particularly for“modding” games) we can tap into the growing libraryof ready-made 3D shapes and textures to customize theworld.

5.2 StarLogoBlocks

StarLogoBlocks is a visual programming language inwhich pieces of code are represented by puzzle pieceson the screen. In the same way that puzzle pieces fit to-gether to form a picture, StarLogo blocks fit together toform a program. StarLogoBlocks is inspired by LogoB-locks (Begel 1996), a Logo-based graphical languageintended to enable younger programmers to programthe Programmable Brick (Resnick, Martin, Sargent &Silverman 1996) (a predecessor to the Lego Mindstormsproduct).

StarLogoBlocks is an instruction-flow language,where each step in the control flow of the program isrepresented by a block. Blocks are introduced into theprogramming workspace by dragging a block from a cat-egorized palette of blocks on the left side of the inter-face. Users build a program by stacking a sequence ofblocks from top to bottom. A stack may be topped by a

procedure declaration block, thereby giving the stack aname, as well as enabling recursion. Both built-in anduser-defined functions can take argument blocks, whichare plugged in on the right. Data types are indicated viathe block’s plug and socket shapes.

The workspace is a large horizontally-oriented spacedivided into sections: one for setup code, one for globaloperations, and one for each breed of turtles. A philoso-phy we espouse in the programming environment is thata block’s location in the workspace should help a userorganize their program. While separating code by sec-tion appears to the user as a form of object-oriented pro-gramming, in reality the system does not enforce this.All code may be executed by any breed of turtle. Fishcan swim and birds can fly, but that certainly should notprevent the user from successfully asking a fish to fly.

5.2.1 Graphical Affordances

The “blocks” metaphor provides several affordances tothe novice programmer. In the simplest sense, it pro-vides quick and easy access to the entire vocabulary,through the graphical categorization of commands. Asprogrammers are building models they can simply se-lect the commands that they want from the palette anddrag them out. Perhaps more importantly though, theshape of the blocks is designed so that only commandsthat make syntactic sense will actually fit together. Thatmeans that the entire syntax is visually apparent tothe programmer. Finally, it also provides a graphicaloverview of the control flow of the program, making ap-parent what happens when.

7

Figure 4: The LogoBlocks interface. A simple programis shown that includes logical statements, random be-haviors and movement. The blocks are assembled into acomplete procedure, drawing upon the palette of blocksat the left.

For example, the following illustration of StarLogoB-locks code on the left, and StarLogo code on the rightfor a procedure which has turtles turn around on redpatches, decrease their energy, eat, and then die with a10% chance and continue moving otherwise.

to runif pc = red

[ rt 180 ]setenergy energy -- 1eatifelse (random 100) < 10

[ die ][ move ]

end

While the code in StarLogoBlocks takes up morespace, it can be seen that the syntax is entirely visibleto the user. In contrast, the StarLogo code has mixturesof brackets [ ], parentheses ( ) and spaces that are oftenconfusing to users. The if-else conditional fully specifieswhat goes in which socket. The if predicate socket has arounded edge, which can only fit Booleans, such as thecondition shown. Similarly, functions which take inte-gers have triangular sockets. The two other two sockets(for “then” and “else”) are clearly labeled so that a pro-grammer (or reader of a program) can clearly see whatthey are doing.

Figure 5: StarLogoBlocks and StarLogo representationsof the same code.

Blocks create more obvious indicators of the argu-ments taken by procedures, as compared to text-basedprogramming. This enables us, as the game construc-tion kit designers, to provide new kinds of control flowand GUIs for the blocks without confusing the program-mer. Adding a fifth parameter to a text-based procedureresults in children (and teachers) more often consultingthe manual, but introducing this fifth parameter as a la-beled socket makes the new facility more apparent andeasier to use. Graphical programming affords changes inthese dimensions because a change in the graphics canbe more self-explanatory than in a text-based language.

While StarLogoBlocks and LogoBlocks share the“blocks” metaphor, StarLogoBlocks is presented withmuch greater challenges due to the relative complex-ity of the StarLogo environment. LogoBlocks programsdraw from a language of dozens of commands, are typ-

8

Figure 6: The StarLogoBlocks interface.

ically only 10–20 lines long, have a maximum of twovariables, no procedure arguments or return values, andno breeds. StarLogo programs draw from a languagewith hundreds of commands and can often be a hun-dred lines or more long. Screen real estate can become areal limit on program size. Driven by this challenge, wecreated a richer blocks environment with new featuresspecifically designed to manage the complexity and sizeof StarLogo code.

One of the most important innovations is to incorpo-rate dynamic animated responses to user actions. We usethis animation to indicate what kinds of user gestures areproper and improper while the user is performing them.For example, when a user drags a large stack of blocksinto an “if” statement block, the “if” block will stretchto accommodate the stack. See the “Climb” procedurein Figure 6. The first part of the if-else command hasone command to run (forward 1), while the else has two(right random 90 and forward 1). The blocks expandto fit as many commands as necessary so that the elseclause could in theory have dozens of commands.

If a user tries to use a procedure parameter in a differ-ent procedure from which the parameter was declared,all of the block sockets in the incorrect stacks of blocksclose up. When a user picks up a number block to insertinto a list of values (which in Logo may contain valuesof any type), all block sockets in the list will morph froman amorphous “polymorphic” shape into the triangularshape of a number, to indicate that a number block may

be placed in that socket. We plan to continue adding newkinds of animations to help prevent users from makingprogramming errors in the system.

These animations are implemented using vector-based drawing. Vector drawing enables a second im-portant feature: the zoomable interface. Using a zoomslider, the user can zoom the entire interface easily (seethe zoom slider in the upper-right of Figure 6) to lookclosely at a procedure they are writing, or expand theirview to see an overall picture of their project.

Another innovation has been “collapsible” proce-dures. Individual procedures can be collapsed and ex-panded to see or hide their contents. This allows theprogrammer to build many small procedures and then“roll up” the procedures that they aren’t using and putthem on the side. Figure 6 shows the “Eat” and “Move”procedures in their rolled up states. The individual com-mands are not visible, like they are in the other two pro-cedures, but can be made visible by clicking on the plussign on the block. Additional advances provide for theeasy creation of new procedures, including procedureswith an arbitrary number of parameters, and variables.

Together these innovations lower the barrier of en-try for programming, thus facilitating model construc-tion/deconstruction in the context of science, math orsocial science classes.

5.3 StarLogo TNG as Game Builder

The first version of StarLogo TNG will support thedevelopment of first- and third-person 3D explorationgames. All games consist of three main pieces: charac-ters, scenery, and behavior. Characters are implementedusing StarLogo turtles; different categories of charac-ters are defined using StarLogo breeds. The scenery ofa game is created in the StarLogo Terrain Editor. Sim-ilar to the SimCity city builder editor, our Terrain Edi-tor supports landscaping, drawing, and character place-ment. The behavior of the game and the characters areprogrammed using StarLogoBlocks. Our first version ofStarLogo TNG will support relatively simple behaviors(such as moving around, jumping and shooting), but be-cause StarLogo TNG is a full-fledged programming en-vironment, we expect people to be able to build morecomplex character behaviors (incorporating desires like

9

hunger and greediness, or semi-autonomous motion orintelligence). In fact, while we have designed StarLogoTNG with simple exploration games in mind, buildinga more complex game with original characters is a greatchallenge for a designer, especially one we would like toget hooked on programming.

In the next section, we will walk through the creationof a Super Mario Brothers-like video game using theStarLogo TNG toolkit.

6 Building Super Mario Brothers

Super Mario Brothers was one of the most canonical andpopular games for the Nintendo Entertainment System,introduced in August of 1985. In this game, two charac-ters, Mario and Luigi (the brothers) are controlled by theplayers to make their way through the two-dimensionalside-scrolling world of the Mushroom Kingdom in an at-tempt to rescue Princess Toadstool, who has been takencaptive by Bowser, the evil King of the Koopas. Alongthe way, the brothers face Koopa Troopas (turtles thatcan be stunned by jumping on them), deadly Venusfly traps (must avoid touching them), Goombas (mush-rooms which you can shoot with a fireball), and bottom-less pits. To help them, there are floating magic boxes;if you hit them from below, out will pop a star (makesyou invincible for a short time), a mushroom (makes youtwice as bit and resistant to one hit from an enemy), oran extra player mushroom (gives you one more life).

We will build a 3D version of this game, similar towhat one would see by playing Super Mario 64, an up-dated version of the game designed for the Nintendo 64System. We start our game by designing the characters.To shorten the exposition, we will simplify the game toinclude only two characters and their interactions.

6.1 Characters

• Mario The player character. Mario looks like aplumber and has a red hat and overalls. He canjump, punch upwards, and sometimes shoot fire-balls (if he has gotten a fire flower).

• Koopa Troopa Evil turtle henchman. KoopaTroopas patrol areas of the screen and crawl like

Figure 7: By clicking on the Add Breed (+) button, theuser can create a breed of Koopa Troopa turtles.

turtles. Koopa Troopas can be stunned if Mariojumps on them. They can be killed if Mario kicksthem while they are stunned. Koopa Troopas cankill Mario if they crawl into him.

To create these characters in StarLogo TNG, we cre-ate two new breeds by clicking on the Add Breed but-ton in the StarLogoBlocks window (Figure 7). Design-ers would associate several shapes and animations (3Dshapes in StarLogo TNG come with prebuilt animations)with a breed. StarLogo TNG comes with a variety ofshapes, and users can add more of their own.

6.2 Scenery

We next move on to describe the scenery of Level 1. Un-like the original Super Mario Brothers, our scenery willbe three dimensional. We switch to the StarLogo TerrainEditor and describe our landscape. First, we initializeSpaceland to a flat world covered with a grass texture.Then we grow three dimensional blocks on the surfaceof the world that Mario can jump on. These blocks willhelp us create a maze. At one end of the world, we createa flagpole-like extrusion from the world and color it likea metallic flagpole. When Mario reaches this spot, hewins the game. Between a few of the blocks, we push theground down to create a pit. If Mario falls into the pit,he will die. We make each pit short enough for Mario

10

to jump over, but leave some longer to make the jumpsmore challenging.

We design the level to encourage Mario follow a pathto the flagpole. Along the path, we place a KoopaTroopa on patrol. We place one Koopa Troopa on ev-ery block as well. Sometimes we place more than one inan area to make it more difficult for Mario to get aroundthem. We save this terrain into a terrain block calledLevel 1. This block will appear in the Block Palette inthe StarLogoBlocks window.

6.3 Behavior

Each character has behaviors that must be programmedby the user. Designers could program a funny wayto walk, add shooting capability, or the ability to fly.Mario’s behaviors are the simplest. He listens to theuser’s joystick to move him left, right, north and south.In addition, when the user hits the A button, Mariojumps. Mario must also keep track of how many liveshe has – when he loses them all, the game is over.

We create one procedure: Respond To Joystick thatuses two joystick blocks from the Block Palette. Thefirst joystick block has four slots ready for a block stack,one for each cardinal direction. The second block hastwo slots, one for each button on the joystick. In eachslot, we place code blocks that causes Mario to react tothe joystick. For example, if the user moves the joystickleft, we want Mario to turn to the left and move forwardone step. If the user pushes the A button, we want Marioto jump using a Jump block. To determine if we falleninto a pit, or won the game, we create another procedurestack called Check State (Figure 8).

Koopa Troopas have a very simple behavior. Theymove back and forth over a certain distance (patrollingthe region). This distance may be overridden if they’reon a block and reach the edge prematurely. A Koopa hasone procedure called Move (Figure 9).

Distance-to-go is a variable that Koopas use to deter-mine how many steps they should patrol. Koopas alsoneed a variable called Hidden? which indicates whetherthey have been stomped by Mario. If Hidden? is true,they should stand still and not run the Move command.

Finally, we must describe the global behaviors of thegame. What happens when each of these characters

Figure 8: Mario’s Check State function.

hit one another? When Mario hits a Koopa Troopa, hemight die, or the Koopa might hide. When two Koopashit one another, they reverse direction. We describethese behaviors with a Collision block that we drag outfor each breed. There is one code slot in the Collisionblock for every breed that our character may hit.

If Mario hits a Koopa Troopa, we run some logic tosee what happens (Figure 10). If Mario jumps on aKoopa (i.e. when Mario collides with a Koopa wherehis height is higher than the Koopa’s), the Koopa hidesin his turtle shell. If Mario touches the Koopa in anyother way, Mario dies.

To finish up the game, we set up the scoring system.The score is a built-in property of all games; we modifythe procedures above to increment the score when Mariostomps on a Koopa and when Mario wins by reachingthe flagpole.

11

Figure 9: Koopa’s Move function.

7 Field Testing

While StarLogo TNG is still in development, it hasreached a point in development where we have been ableto do pilot testing with small groups of students, andclassroom usability focus groups with teachers. Both ofthese mechanisms have helped guide the developmentprocess, and provide comparative information with theprevious version of StarLogo. Below we describe a casestudy from one of the pilot tests with students, as well assome of the feedback we have received from the teacherfocus groups.

7.1 Pilot Study

Our case studies employ comparative tests between theexisting StarLogo and StarLogo TNG. We have targeted

Figure 10: Mario Vision block describes what happenswhen Mario collides with a Koopa.

students who have familiarity with the concepts of Star-Logo, but have not done any programming. In onecase study we worked with pairs of students at a Bostonmetropolitan area private school, in which students haveused StarLogo models. In a 90 minute session the stu-dents were given a simple programming task, along withinstructions, in one environment and then the other. Theprogramming task, at its minimum, involved 6–10 linesof code. Students were videotaped during their program-ming session, and also debriefed afterwards. This partic-ular case was with two tenth grade girls (Alice and Beth)who had never programmed before.

They strongly preferred the StarLogoBlocks pro-gramming paradigm to the text based paradigm of theexisting StarLogo. Specifically, they pointed out the wayin which you could follow the flow of programs visually,and that you didn’t need to worry about the syntax.

Alice: It is easier to see the commands too becauseinstead of typing in random things that you don’t knowwhat they really mean this is like a puzzle piece and youcan kind of put it together.

Beth: You can tell if you are doing it right if the puz-zle pieces fit too. Because before I was like questioningmyself if I was doing it right like bracket or space. Idon’t know.

They both expressed satisfaction with the empower-ment that programming provided them. Being able totake control over the program was clearly more satisfy-

12

ing than simply manipulating programs.

Alice: I definitely think this one is a plus, since we canfigure out how to program. Since sometimes in a simu-lation you want to change it. I’m just the kind of personwho wants to put their own stuff in there and see whathappens. And I haven’t been able to do this because I’mnot a programmer.

It is of note that they do not consider themselvesprogrammers, even after writing a program. Two boyswho were doing the activity simultaneously called them-selves programmers at the end, though one had neverdone any computer programming, and the other had only“programmed” web pages in HTML. In other tests andfocus groups we have consistently received highly posi-tive feedback from girls and women who have felt intim-idated by programming languages, which to them havebeen seen as male-oriented.

The 3D environment also appealed to these girls.While they expressed an understanding of the value ofthe 2D top-down view for getting a sense of the sys-tem level dynamics (which we have since given a greaterpresence in the new version as a result), they liked thatyou could focus on the interactions of a single turtle orsmall number of turtles in this version.

Beth: I think what this does with the 3D too, is likeyou can track one turtle and just track his whole course.You can follow him through. And that can help you un-derstand it.

Alice: With the other one, we’ve been doing evolu-tion models in class. And we had to see when they re-produced what color came off, like this might be able tohelp us see which ones thrive and when they reproduceand what happens to them.

Understanding the value and role of the systems-levelview and individual view shows that these students havebeen able to make a huge conceptual leap. Knowing thatthe large-scale patterns are the results of these individ-ual interactions is a start at overcoming the CentralizedMindset (Resnick 1994). It also allows them to start gen-erating hypotheses about the specifics of how these twoscales are connected. But the graphically rich 3D worldalso makes the world more tangible to them. The 2Dworld, while illustrative, is limited in its ability to pro-vide a sense of the world. The 3D world has customiz-able characters, terrains and environmental context. This

aspect appealed to them. In the following example, oneof the students is commenting on the potential she seesfor customizing the backgrounds to convey informationabout the model.

Beth: This could be cool too because you can see theenvironment in the background. We had a lot of ones inthe other one where we had a drought. It would be coolthis way since you could see what was happening to theturtles.

The backgrounds, and other graphically rich compo-nents of the visualized 3D StarLogo world are an easyfor programmers to customize their world, and conveyinformation about the context of the model to their au-dience. The fact that the background, turtles, or land-scape look like something recognizable has tremendousexplanatory power.

7.2 Feedback from Teachers

We have also done several focus groups with teacherswho have used the existing StarLogo to develop simula-tions. While a few initially have expressed some reser-vations about their existing programming skills becom-ing obsolete, they have embraced the StarLogoBlocksprogramming metaphor and feel that it will provide thenecessary comfort for introducing the students to pro-gramming — first by program deconstruction and thenthrough model building. Most of the feedback has beenquite positive, while other feedback has allowed us tomodify the programming and runtime worlds to betteraccommodate a variety of programmers and learners.

On the positive side, nearly everyone who has seen theblocks has commented on how much easier it is to seethe flow of the programs, and that it relieves the stress ofhaving to remember all of the syntax. We have, however,been asked if it will be possible to “drop down” to thetext level after setting things up. Our answer is “no”. Itis our goal to make it possible to construct sophisticatedprograms using this paradigm, and we are not treatingthe blocks as a starting place. Algebraic expressionshave been problematic, in that it takes several clicks anddrags to write expressions. As a result, we have revisedthe layout of algebraic expressions to appear less proce-dural, and will eventually add an algebra-specific mode

13

that will allow basic mathematical expressions to be en-tered by keyboard and laid out automatically in blocks.

Other feedback on the programming side has led tocollapsible procedures and zooming features that enablethe navigation of multiple procedures and lengthy code.As mentioned previously, many users have valued thecomplimentary perspectives of the 2D and 3D views,prompting us to redesign the runtime interface with theability to show both 2D and 3D simultaneously, or sim-ply one or the other. The only major concern that teach-ers have expressed is whether it will run on their com-puters, due to the 3D graphics card requirements, whichare relatively low for 3D games, but may not work onolder computers without dedicated graphics cards.

8 Conclusion

The testing and focus groups that we have done so farhave suggested that the blocks design will promote theuse of StarLogo as a programming tool in the classroom.Teachers feel more secure in teaching this paradigm totheir students, and students have been able to easily de-code programs written in this way. While it is still earlyto tell, it seems that it may also provide a more female-friendly programming environment than other tools.

The 3D world is “definitely cool”, in the words ofmany of the students. While teachers have been morelukewarm in their reception of this aspect, they recog-nized that it will be more attractive to students. It isclear that both 2D and 3D representations will have aplace in this environment, but the ability to customizethe world and make it look like something recognizable(though not realistic — which is important in conveyingthat these are simply models) is a big plus for students asthey approach modeling for the first time. It also allowsstudents to invest themselves personally in their prod-ucts, which is empowering.

StarLogo TNG will be in development for some time.Some of the next steps involve adding hooks like net-work connectivity and joystick control, in order to addto the attraction of those wishing to build games. Butwe also will be building libraries of blocks for specificacademic domains (e.g. ecology, mechanics, etc.) thatwill allow students to quickly get started building sci-

ence games using some higher level commands, whichcan in turn be “opened up” and modified as their skillsprogress.

Acknowledgments

The authors would like to thank all of the undergraduateresearchers who worked on the implementation of Star-Logo TNG. We thank Hal Scheintaub for welcoming usinto his classroom for our pilot study. The research inthis paper was supported in part by a National ScienceFoundations ITEST Grant (Award #0322573).

References

Agalianos, A., Noss, R. & Whitty, G. (2001), ‘Logo inmainstream schools: the struggle over the soul ofan educational innovation’,British Journal of So-ciology of Education22(4), 479–500.

American Association for the Advancement of Science(1993),Project 2061: Benchmarks for Science Lit-eracy, Oxford University Press, New York.

Begel, A. (1996), ‘LogoBlocks: A graphical program-ming language for interacting with the world’.Massachusetts Institute of Technology, Dept. ofElectrical Engineering and Computer Science.

Begel, A. (1997), Bongo: A kids’ programming environ-ment for creating video games on the web, Mas-ter’s thesis, Massachusetts Institute of Technology,Dept. of Electrical Engineering and Computer Sci-ence.

Budge, B. (1983), ‘Pinball construction set’, ElectronicArts Inc.

Clickteam S.A.R.L. (2004), ‘The Games Factory’.http://www.clickteam.com/English/tgf.htm.

Conway, M., Pausch, R., Gossweiler, R. & Burnette,T. (1994), Alice: A rapid prototyping system forbuilding virtual environments,in ‘Proceedings ofACM CHI’94 Conference on Human Factors inComputing Systems’, Vol. 2 ofSHORT PAPERS:Designing Interaction Objects, p. 295.

14

Cypher, A. & Smith, D. C. (1995), Kidsim: End userprogramming of simulations,in ‘Proceedings ofACM CHI’95 Conference on Human Factors inComputing Systems’, Vol. 1 ofPapers: Program-ming by Example, pp. 27–34.

di Sessa, A. & Abelson, H. (1986), ‘Boxer: a re-constructible computational medium’,Communi-cations of the ACM29(9), 859–868.

Europress Software Ltd. (2004), ‘Klik & Play’.http://www.clickteam.com/English/klilk&play.htm.

Harel, I. (1990), ‘Children as software designers: A con-structionist approach for learning mathematics’,The Journal of Mathematical Behavior9(1), 3–93.

Harel, I. & Papert, S., eds (1991),Constructionism,Ablex Publishing, Norwood, NJ.

Ingalls, D., Kaehler, T., Maloney, J., Wallace, W. &Kay, A. (1997), Back to the future: The story ofSqueak, A practical Smalltalk written in itself,in‘OOPSLA ’97 Conference Proceedings: Object-Oriented Programming Systems, Languages, andApplications’, ACM Press, pp. 318–326.

Kafai, Y. B. (1995),Minds in play: Computer game de-sign as a context for children’s learning, LawrenceErlbaum Associates, Hillsdale, NJ.

Kafai, Y. B. (1996), ‘Software by kids for kids’,Com-munications of the ACM39(4), 38–39.

Logo Computer Systems Inc. (2004), ‘MicroworldsLogo’. http://www.microworlds.com.

Lucena, A. T. (n.d.), ‘Children’s understanding ofplace value: The design and analysis of acomputer game’. http://www.stagecast.com/cgi-bin/templator.cgi?PAGE=Corporate/ presenta-tions/PRESENTATIONS.

Murnane, R. J. & Levy, F. (1996),Teaching the NewBasic Skills, Principles for Educating Children toThrive in a Changing Economy, Free Press, NewYork.

National Research Council (1999),Being Fluent withTechnology, National Academy Press, Washing-ton, DC.

Papert, S. (1980),Mindstorms: Children, computers,and powerful ideas, Basic Books, New York.

Papert, S. (1993),The Children’s Machine: RethinkingSchool in the Age of the Computer, Basic Books,New York.

Repenning, A. & Sumner, T. (1992), Agentsheets: Atool for building visual programming environ-ments,in ‘Proceedings of ACM CHI’92 Confer-ence on Human Factors in Computing Systems –Posters and Short Talks’, Posters: Helping Users,Programmers, and Designers, p. 30.

Resnick, M. (1994),Turtles, Termites, and Traffic Jams:Explorations in Massively Parallel Microworlds(Complex Adaptive Systems), MIT Press, Cam-bridge, MA.

Resnick, M. (2002), Rethinking learning in the digitalage,in G. Kirkman, ed., ‘The Global InformationTechnology Report: Readiness for the NetworkedWorld’, Oxford University Press, Oxford, UK.

Resnick, M., Martin, F., Sargent, R. & Silverman,B. (1996), ‘Programmable bricks: Toys to thinkwith’, IBM Systems Journal35(3-4), 443–452.

Resnick, M., Rusk, N. & Cooke, S. (1998), TheComputer Clubhouse,in D. Schon, B. Sanyal &W. Mitchell, eds, ‘High Technology and Low-Income Communities’, MIT Press, Cambridge,MA, pp. 266–286.

State of Maine, D. o. E. (2004), ‘Maine learning tech-nology initiative’. http://www.state.me.us/mlte/.

The Education Arcade (2004), ‘Education Arcade’.http://www.educationarcade.org.

Wolfram, S. (2002),A New Kind of Science, WolframMedia Inc., Champaign, IL.

15