teaching computer science with virtual worlds

IEEE TRANSACTIONS ON EDUCATION, VOL. 47, NO. 2, MAY 2004 269

Teaching Computer Science With Virtual WorldsBrian M. Slator, Curt Hill, and Dayna Del Val

Abstract—The ProgrammingLand MOOseum of Computer Sci-ence is a multiuser virtual environment hosted on the Internet. Itis built on a model of exploratory, spatially oriented immersion,where visitors learn principles of computer science as they journeythrough the content. The MOOseum is divided into “wings” thatare devoted to particular programming languages and is populatedwith an array of interactive objects and agents that facilitate an ac-tive learning experience. This paper describes the environment andthe effort to integrate it into the curriculum.

Index Terms—Active learning, educational media, onlinelearning, virtual environments.

I. INTRODUCTION

THE ProgrammingLand MOOseum [1], [2] implementsan Exploratorium-style museum metaphor to create a

hyper-course in computer programming principles aimed atstructuring the curriculum as a tour through a virtual museum.Student visitors participate in a self-paced exploration of theexhibit space, where they are introduced to the concepts ofcomputer programming, are given demonstrations of theseconcepts in action, and are encouraged to manipulate the inter-active exhibits as a way of experiencing the principles beingtaught and to construct their own understanding of them [3].

ProgrammingLand has been developed and used in con-junction with classroom instruction. However, the goal is fordistance learning and nontraditional classes. It is intended todeliver the content that would normally be obtained from alecture or textbook yet would also have many of the attractivequalities of games and other learner-centered activities.

This paper describes a project that has been ongoing for fouryears, involving the Computer Science Faculty at North DakotaState University (NDSU), Fargo, and Valley City State Univer-sity (VCSU) Valley City, ND, a four-year college. VCSU is no-table for being one of America’s first “laptop colleges.”

This paper describes a system used in two ways in thecurriculum. First, it is used as a source of projects in theNDSU Comparative Languages course (COMP372), wherejunior-level students study programming languages andimplement virtual artifacts as a way of gaining a deeper under-standing of the principles being covered. Second, it is used as a

Manuscript received July 19, 2001; revised June 7, 2003. The Programming-Land MOOseum project has been supported in part by ND-EPSCoR throughthe FLARE program under EPS-9 874 802. The NDSU Worldwide Web Instruc-tional Committee (WWWIC) research is supported in part by funding from theNational Science Foundation under Grant EIA-0086142 and from the U.S. De-partment of Education FIPSE program.

B. M. Slator is with the Computer Science Department of North Dakota StateUniversity, Fargo, ND 58105 USA (e-mail: [email protected]).

C. Hill is with the Mathematics Department, Valley City State University,Valley City, ND 58072 USA (e-mail: [email protected]).

D. Del Val is with the English Department of North Dakota State University,Fargo, ND 58105 USA (e-mail: [email protected]).

Digital Object Identifier 10.1109/TE.2004.825513

virtual space for introductory programming courses (CS1 andCS2) at VCSU, where freshman-level students are engaged inthe process of exploration and discovery as they learn how toprogram in C++.

II. FUNDAMENTAL OBJECTS

ProgrammingLand is hosted on a multiuser-domain (or, his-torically, dungeon) object-oriented (MOO) environment [10].The basic components are “rooms” with “exits,” “containers,”and “players.” MOOs support the object management and inter-player messaging that is required for multiplayer games and, atthe same time, provide a programming language for customiza-tion of the environment.

When students log into the MOOseum, their character is ac-tivated. This character is the object the server uses to manageeverything known about the player. There are several importantproperties attached to the character that have an impact on theeducational use of the MOO: 1) a list of every room they havevisited, 2) a list of award and event tokens the student has earned,and 3) a goal. Every student has a goal at all times. Typically anaward token denotes the accomplishment of a goal, at whichpoint a new goal is instantly assigned.

There are several types of rooms or exhibits in the MOOseum:

1) the lecture room, which delivers a paragraph or so of ex-pository text;

2) a signpost or menu room, which serves as sort of a cross-road in the MOOseum;

3) a lesson room, which controls access to a group of ex-hibits that comprise a lesson;

4) a workroom, which houses interactive objects used by onestudent at a time;

5) a quiz room, where students take tests (these are alwaysconnected to a lesson room).

III. VISITING PROGRAMMINGLAND

A typical session for a student starts with the execution of aclient program that connects to the MOOseum. Programming-Land itself is structured into rooms, with exits being the pathfrom one room to another. The motif of ProgrammingLand isthat of an Exploratorium-style museum. Therefore, the term“exhibit” is usually used instead of room. Whenever an exhibitor room is entered, its description is displayed. Typically, thisdescription is a paragraph or two of expository text on some in-structional topic. The exhibit also indicates exits and where theylead. In the spirit of user-centered control, the student is alwaysfree to choose which path to take and what to do next. Althoughan exit is a one-way path from one exhibit to another, these exitsusually come in pairs so students may backtrack conveniently.

0018-9359/04$20.00 © 2004 IEEE

270 IEEE TRANSACTIONS ON EDUCATION, VOL. 47, NO. 2, MAY 2004

Fig. 1. Exhibit with a code machine named “simple.”

The ProgrammingLand MOOseum is both a text-based vir-tual environment and a Web server. Anyone can visit and tra-verse the descriptions of the rooms with a simple Web browser.Because a log-in is required to be fully interactive, this methodof visiting MOOSeum, while not fully interactive, still providesa convenient way for touring the environment.

IV. LOCAL CONTEXT

The NDSU World Wide Web Instructional Committee [4] iscurrently engaged in several virtual/visual educational projects,including the Geology Explorer and the Virtual Cell. Theseteach science structure and process: the Scientific Method,scientific problem solving, diagnosis, hypothesis formation andtesting, and experimental design.

V. THE STRUCTURE OF PROGRAMMINGLAND

The structure of the MOO needs to be considered from twodifferent perspectives: the logical structure and the pedagogicalstructure. The logical structure is shared with every otherMOO, and the pedagogical structure is superimposed on thislogical structure and distinguishes ProgrammingLand fromother MOOs.

A. The Logical Structure

The logical structure of any MOO is that of a directed graph.Each MOO object, including rooms, has a name and a descrip-tion, which are displayed to the players when they enter, plus thenames of any objects contained by the room, which may includeother players (Fig. 1). Much of the subject content of Program-mingLand is in the expository descriptions of these exhibits.

Each room has a property that determines whether to displayexits or not. Usually, the server displays the exits and their des-tinations when a player enters a room. However, signpost roomshave a menu of possible exits in their descriptions, and the exitdisplay is suppressed as redundant. The server notifies relevantplayers when a player or agent enters or leaves an exhibit.

Exits are the directed graph arcs that connect exhibits. An exithas a name and possibly some aliases, like any other object ina MOO, but the name or alias of an exit is also a command tomove to another node. In ProgrammingLand, the exits identifytopics or menu entries.

Fig. 1 is a typical exhibit display. (The output of a MOO is textonly, so this figure and others are directly extracted from user in-teraction, with the editorial exception of formatting user input inbold font with an “ ”.) When students enter a room, they seeits name followed by a description, which may be any numberof lines. The next-to-last line in Fig. 1 shows there is an object inthis room named “simple.” A sample lesson’s rooms and exits

Fig. 2. Exhibits in the Compound Statement Lesson (a typical studentnavigates clockwise from the upper left).

are diagrammed in Fig. 2. If the students type “help simple” or“look simple,” the server displays help on how the simple ob-ject works. Simple is an instance of a code machine, describedsubsequently, which is used to show, trace, and explain a smallportion of programming language code. The final line indicatesthat “exit” is the name of an exit that leads to a room named“Practice with the Assignment Statement.” A sample lesson’srooms and exits are diagrammed in Fig. 2.

B. The Pedagogical Structure

Embedded into the room, exit, and object structure of Pro-grammingLand are a number of items that work toward the ed-ucation of students. The basic unit, which covers one distincttopic of the material, is called a lesson. It does not have to beexhaustive on the topic, but it does need to be self-contained.Lessons in ProgrammingLand are usually hierarchical; that is, alesson may contain smaller lessons within it. A lesson may havemany of the following parts:

1) an introduction that motivates the students or demon-strates the need for the topic;

2) the content material;3) an exercise that causes the student to use the new

knowledge;4) some type of assessment of the student’s grasp of the

material.A lesson in ProgrammingLand usually consists of several ex-

hibits and several specialized objects. Typically, an entryway,

SLATOR et al.: TEACHING COMPUTER SCIENCE WITH VIRTUAL WORLDS 271

Fig. 3. Compound Statement Signpost Room (after a student has typed “@requirements”).

often a signpost/menu room, suggests an order of perusing thematerial, the only way in or out; but the student ultimately de-cides how to take the lesson. The Compound Statement Exhibitin this example is the entrance to the lesson, and it controls ac-cess to the entire lesson. A student entering into the lesson wouldsee the display in Fig. 3.

1) Goals and Assessment: In order for students to completelessons, they must visit certain rooms and interact with cer-tain objects while there. When the students visit an exhibit, thatfact is recorded and, likewise, when they complete an exercisewith an interactive object. The lesson exit, described hereafter,checks for these accomplishments.

The Compound Statement Room in Fig. 3 is a signpost roomwhich displays some text but also contains the requirements ofthe lesson. These requirements, organized as a list of lists, aredisplayed to the student by the “@requirements” command. Ifthe students have satisfied any of the sub-lists, then they havesatisfied the lesson. The requirements of a lesson’s sub-list maybe that 1) a certain room has been visited, 2) an object has beenexercised, or 3) another lesson has been completed. However,the student must satisfy every requirement of one sub-list to sat-isfy the lesson and receive the award token. This particular ex-hibit allows for two methods of satisfying requirements: either1) the students visit eight specified rooms within the lesson, or2) they execute the trace of a code machine found within thelesson’s rooms.

When the students leave the Compound Statement Ex-hibit, the lesson exit checks their event tokens against thelesson requirements. If the students have satisfied one of therequirement’s sub-lists, they are given credit for the lesson.Otherwise, they are told of the requirements still needed. Theyare then given a choice to continue on their way, assumingthey will finish the lesson later or to take a quiz to show their

mastery of the material, which is another way to satisfy lessonrequirements.

The lesson, lesson exit, quiz room, lesson dispatcher, androving goalie work together to assign award and event tokensthat measure student progress. When a student has visited theimportant rooms of a lesson, or exercised the machines that existthere, this credit is recorded with what has been titled “eventtokens.” When they have enough credit, students are given an“out of MOO” programming assignment by a roving goalie tofinalize their learning.

2) Lesson Exit: Either a lesson -exit or a quiz room may as-sign credit for completing a lesson; they also notify the lessondispatcher of the students’ progress. Certain lessons are allowedto change the goal of the students, which causes the rovinggoalie to be activated, to tell them about their new goal. Thelesson dispatcher checks the lesson and dispatches the goalie.

If they have not completed the lesson requirements, they areasked if they want to 1) continue to their destination and finishthe lesson later or 2) prove their mastery with a quiz. If theyopt for a quiz, they are transported to a quiz room (describedhereafter).

a) Roving Goalies: A roving goalie is an agent withseveral important properties for interaction with the student.Generally, students get a separate personalized assignment,usually a programming assignment from a list of equivalentassignments. The roving goalie gives assignments in a round-robin fashion so that students will each get a different one,insofar as possible. The roving goalie makes sure the studentsreceive only one goal from a particular lesson. When studentswants to reread their individualized assignment, they use theShowgoal command.

Fig. 4 shows a student leaving a lesson (by typing “x” to exit).Normally, the name of the room is the first thing displayed, but


Fig. 4. After completion of a lesson, a roving goalie named Fernanda gives an “out-of-MOO” programming assignment.

Fig. 5. Tracing the execution of the code machine named “simple.”

in this case, notification of the completion of a lesson is inter-jected. Then, Fernanda, a roving goalie agent, enters the room,gives an assignment, and leaves.

b) Quiz Rooms: When students elect to take a masteryquiz, they are transported to a quiz room. A quiz room cannotbe reached except by accepting the challenge of a quiz whenleaving a lesson (without completing lesson requirements).There is one quiz room attached to each lesson, where thestudents take a multiple-choice quiz. If they pass, they are givenfull credit for the lesson.

The quiz room randomly generates multiple-choice questionswhich cover lecture material the students missed. Attached toeach lecture room is a series of quiz questions. The quiz gener-ator looks at the players’ history and determines which requiredexhibits they did not visit. Then, it gathers five questions fromthese rooms and presents them to the students. If they answerincorrectly, the correct answer is given. If they answer four ofthe five correctly, they pass the quiz and receive credit for the

lesson. If they miss a second question, the quiz is terminatedand they are instructed to resume the lesson to receive credit. Ifthey attempt a second quiz, they get different questions but arenot allowed to take the quiz a third time.

The quiz room is used to verify student mastery of materialin the absence of the usual evidence—completing the goals asassigned. This technique is also a way for experts to short-circuitthe lesson structure, if they choose. A quiz room has no regularentrances; the only way to enter a quiz room is to take the quizoption when using a lesson exit. Quiz rooms exit to the originaldestination.

c) Code Machines: A code machine contains a piece ofa program that it will display, explain, or trace (Fig. 5). Codeis displayed with a description of what is happening at runtime, including the contents of any variables changed. Whena student completes either an explanation or trace of code, an“event” token is recorded, giving the student credit for usingthe machine.


Fig. 6. Realm of Recursion.

Fig. 7. Leprechaun counts.

VI. TOYS IN THE ATTIC

In the spirit of the Exploratorium, the ProgrammingLandMOOseum is also populated with a range of demonstrations,toys, robots, and interactive exhibits. These artifacts are in-tended to engage a visitor in the exploration of the content sothat these playful interactive objects will serve to both entertainand teach. The exhibits and machines in this section werelargely implemented by students.

A. The Recursive Leprechaun

Because recursion is an extremely difficult concept for stu-dents to master, one approach is to implement a recursive lep-rechaun, which resides in the Realm of Recursion (see Fig. 6),one of several exhibits implemented by students. The recursionleprechaun demonstrates a recursive counting function in a vi-sually descriptive manner (see Fig. 7). The leprechaun givesdemonstrations of recursive counting.

In addition to the recursive leprechaun, several other inter-active toys have been implemented by enterprising students,including a large set of interactive programming constructmachines, such as the isa machine shown in Fig. 8, a ring-tossgame, a who-wants-to-be-a-millionaire game, a historicaljukebox, an operating system “ride,” and many others. Theseare “salted” throughout the MOOseum.

B. Tutor Robots

Tutor robots were implemented to make the function roomsin the LambdaMOO wing more active and engaging. They arecreated, also largely by students, from a prototype Turing Robotprovided with the EnCore Moo [11], based on the Eliza model[12], which was inspired by Turing [13]. The robots are userprogrammable and capable of matching keywords and sentencepatterns, and they can be implemented with random responsesand question responses.

VII. PROGRAMMINGLAND IN THE CLASSROOM

ProgrammingLand has been used in classes in two distinctmodes. It has been used in introductory programming classesand has served as a programming laboratory for a comparativeprogramming languages class. In the former, the content of theMOO has supplemented or replaced the textbook; while in thelatter, the students have created content and interactive objects.

Comparative languages combined a virtual lecture, usingthe North Dakota Interactive Video Network (IVN), with avirtual laboratory and the MOOseum of Computer Science todeliver both lecture-based and hands-on instruction to studentsin remote locations. As a result, this study pursued a particulartheoretical approach to this new pedagogy—an approach thatstresses the importance of virtual environments, authentic


Fig. 8. Tutor robot named Curly who lives in the “isa” room.

experiences, and active learning. A relatively standard IVNcourse was developed; it was then augmented with networked,multiplayer, simulation-based, and interactive multimedia—anactive educational environment that is both immersive andinteractive [14].

ProgrammingLand has also been used in various forms sincefall 1997, at VCSU in the first C++ classes (CSci 160, Intro-duction to Structured Programming I) and, to a lesser degree, inother introductory programming classes. CSci 160 is the insti-tution’s equivalent to CS 1 and is required for students seekinga degree in computer science. Reflecting the size of the institu-tion, these classes are typically small with an enrollment in the12–20 range, offered only in the fall semester. The course hasonly an algebra class as a prerequisite. The students are typicallyfreshman and sophomores who are familiar with computers be-cause of the VCSU laptop university experience. The typicalstudents bring their laptops to class, which is conducted in aroom with Internet connections. The instructor has a large videodisplay so that students may actually perform demonstrations ontheir own machines.

There was no attempt made to conceal that this approach wasas new to the authors as to the students. It was perceived thatthey responded well and entered into the adventure. This ap-proach did require flexibility when various technical problemsoccurred. In the end, the students rated the class highly.

The combination of IVN, WWW, and MOO proved to bequite effective and stronger than any of these alone. The useof the MOO greatly enhanced the effectiveness of the course byreducing the perceived separation of student and instructor. Stu-dent evaluations of the course were quite high, with 92% of thestudents responding, rating the quality of the course as eitherabove or much above average. Similarly, 88% of the studentsbelieved their understanding of the course content was eithergood or very good.

VIII. CONCLUSION

The MOO is a work in progress, and its use has varied fromyear to year. In the first two years, it was strictly an optional re-source; some students used it, while others did not. The betterstudents seemed to use it because of curiosity and its similarity

to certain types of games. This reasoning was clearly unsatis-factory. In 1999, the MOO had grown enough that the textbookrequirement was replaced with the use of the MOO.

Why a text-based MOO? Introductory programming ismainly text based; therefore, the MOOseum, as a text-onlymedium, has not been as restrictive as in other more intrin-sically visual disciplines. ProgrammingLand is currently afirst-semester programming course aid. The emphasis is muchmore on syntax and semantics than on techniques. Further,a considerable portion of the content has been developed bystudents in COMP372, Comparative Programming Languages,as class projects, drawn in part from the course text [15]. Thetext mode was most accessible to this group, who needed tobe trained as exhibit builders. As the content expands to moreadvanced and visual topics, the use of graphics to demonstratethese will increase.

The class has had a traditional lecture format: assignmentsannounced in class with full details posted to a Web page. How-ever, in recent years, two changes were implemented: the useof roving goalies to deliver assignments and interactive mul-tiplayer exercises [16]. The students now browse through theMOO, where they receive most of their assignments (Fig. 4).This step has added a new wrinkle to the class, automated ver-ification of reading assignments. If the students did not readthe material in the MOO, they did not get assignments. There-fore, ProgrammingLand was no longer optional work for thestudents.

ProgrammingLand is not currently complete in terms of con-tent, nor is it self-contained. The student still needs access to aprogramming language system for compiling, software devel-opment, and testing. One important aim of this project is the au-tomatic evaluation of student programs, such as has been doneby the Ceilidh system [17].

The MOOseum currently contains slightly more than 1000exhibits, spread across the several languages, such as C++, Lisp,and Basic.; the authors believe that there is currently only about70% of the necessary C++ material available on the Web. Therudiments for student progress and monitoring are in place in thelesson structure, awards, and events properties. The promise ofthis sort of project is a system that offers improved interactivity,better learner-centered control, and increased access to content.


ACKNOWLEDGMENT

The authors would like to thank T. Lemke, who implementedthe “recursive leprechaun;” J. Abel, who implemented Curlythe Tutor Robot; and all the other COMP372 students, withoutwhom this project would not be possible. The authors alsowish to thank the members of the Educational Media Seminarfor discussion and feedback: R. Balakrishnan, M. Dhandapani,U. Kedla, S. Pasupuleti, S. Ray, and H. Wu; and to A. Slatorfor editing assistance. Also important to this effort is theenCore project at the University of Texas—Dallas, upon whoseMOO core the MOOseum was built, and C. Unkel, who firstdeveloped the WinMOO server.

Further information is available at the following Webaddresses:

WWWIC, http://wwwic.ndsu.edu/ProgrammingLand, http://newton.vcsu.nodak.edu:7000High Wired EnCore, http://lingua.utdallas.edu/encore/ND-EPSCoR, http://www.ndsu.edu/epscor/

REFERENCES

[1] C. Hill and B. M. Slator, “Virtual lecture, virtual laboratory, or virtuallesson,” in Proc. Small College Computing Symp. (SCCS), Apr. 1998,pp. 159–173.

[2] B. M. Slator and C. Hill, “Mixing media for distance learning: UsingIVN and MOO in Comp372,” in World Conf. Educational Media, Hy-permedia Telecommunications (ED-MEDIA), June 1999, pp. 881–886.

[3] T. M. Duffy and D. H. Duffy, “Constructivism: New implications forinstructional technology,” in Constructivism and the Technology of In-struction, T. M. and D. H. Jonassen, Eds. Hillsdale: Lawrence Erl-baum, 1992.

[4] B. M. Slator, P. Juell, P. E. McClean, B. Saini-Eidukat, D. P. Schwert, A.R. White, and C. Hill, “Virtual environments for education at NDSU,” inWorld Conf. Educational Media, Hypermedia Telecommunications (ED-MEDIA), June 1999, pp. 875–880.

[5] P. Curtis, “Not just a game: How LambdaMOO came to exist and what itdid to get back at me,” in High Wired: On the Design, Use and Theory ofEducational MOOs, C. Haynes and J. R. Holmevik, Eds. Ann Arbor,MI: Univ. of Michigan Press.

[6] C. Haynes and J. R. Holmevik, Eds., High Wired: On the Design, Useand Theory of Educational MOOs. Ann Arbor, MI: University ofMichigan, 1998.

[7] J. Weizenbaum, “ELIZA—A computer program for the study of naturallanguage communication between man and machine,” Commun. ACM,vol. 9, pp. 36–45, 1966.

[8] A. Turing, “Computing machinery and intelligence,” in Mind, E. A.Feigenbaum and J. Feldman, Eds. New York: McGraw-Hill, 1950, vol.65, pp. 433–460.

[9] A. T. Reid, “Perspectives on computers in education: The promise, thepain, the prospect,” in Active Learning. Oxford, U.K.: CTI SupportService, Dec. 1994, vol. 1.

[10] R. W. Sebesta, Concepts of Programming Languages, 3rd ed. NewYork: Addison-Wesley, 1996.

[11] C. Hill, “Collaboration in ProgrammingLand,” Advances EducationalTechnologies: Multimedia, WWW, Distance, pp. 83–90, June 2001.

[12] S. P. Foubister, G. J. Michaelson, and N. Tomes, “Automatic assessmentof elementary standard ML programs using Ceilidh,” J. Computer As-sisted Learning, vol. 13, no. 2, pp. 99–108, June 1997.

Brian M. Slator is an Associate Professor of Computer Science at North DakotaState University, Fargo. His research interests are artificial intelligence and intel-ligent educational media. He is currently involved in several research projects inthe area of immersive, multiuser, and virtual environments. He is also involvedin research for developing software tools for constructing virtual worlds and in-novative methods for assessing learning in virtual environments.

Curt Hill is an Assistant Professor in the Mathematics Department, Valley CityState University, Valley City, North Dakota, where his main job is to teachComputer Science classes and an occasional Algebra class and maintain Webpages. His current research emphasis is the development of the Programming-Land MOO for online instruction in programming and programming languages.

Dayna Del Val received the Master’s degree in english composition from NorthDakota State University, Fargo.

She is with the English Department of North Dakota State University, Fargo.Her current research interests include alternative discourse and multimedia com-position theory.

teaching computer science with virtual worlds

Documents