Computer Science Instruction in a Virtual World

Curt Hill

Brian M. Slator

Mathematics Department

Computer Science Department

Valley City State University

North Dakota State University

Valley City, ND 58072

Fargo, ND 58102

curt_hill@mail.vcsu.nodak.edu

slator@badlands.nodak.edu

Introduction

The ProgrammingLand MOO (Hill and Slator, 1998; Slator and Hill, 1999), is a computer aided instructional system to teach students the introductory ideas of Computer Science. It has been developed and used in conjunction with traditional classroom instruction. However, its goal is for distance learning and non-traditional classes. It is intended to deliver the content that would normally be obtained from a lecture or textbook, yet have many of the attractive qualities of games and other learner centered activities.

Content in ProgrammingLand

A typical session for a student starts with the execution of a client program. There are several applets that allow the student to use their web brower for this, as well as many good standalone clients. The student connects to the MOO and is registered for tracking purposes. The MOO itself is structured into rooms, with exits being the path from one room to another. Each student has a home that is usually the main entry way of the MOO, but the student may change their home if they desire. The MOO is built on Version 2.0.1 of the enCore database (Holmevik and Haynes, 1997).

The motif of ProgrammingLand is that of an Exploratorium style museum. Therefore the term exhibit is usually used instead of room. Whenever an exhibit or room is entered, the MOO displays a description. Typically this is a paragraph or two of instruction on some topic. The MOO will also indicate what exits exist and where they lead. The student is always free to choose which path to take and what to look at next. Although an exit is a one way path from one room to another, they often come in pairs so that a student may return to an exhibit conveniently. The student entering the Compound Statement Room would see the following display.

The Compound Statement

The compound statement is not a flow of control statement, however it is used in most flow of control statements and is essential to the Structured Programming model.

In the Structured Programming model there is the notion of a block. The block in C++ is the compound statement. It is a wrapper that binds several statements into one. It is also the block that greatly affects the scope of variables.

You may choose any of the following exhibits to consider next.

a) The syntax of the compound statement

b) Scope of variables in the compound statement

c) The compound statement and other statements

or

x) Return to the main exhibit on flow of control

Example 1: The Compound Statement Room

In summary the student meanders through the museum, picking and choosing what they want to read and also choosing the order to consider topics. If this were the extent of the techniques used in the MOO it might be useful, but would not be superior to a series of web pages. What must be considered next are the objects that work together to make this experience more educationally beneficial.

Fundamental Objects

In a MOO every thing is an object. Rooms are objects, exits are objects, players are objects and everything else that we will later consider are objects. These objects have properties that may carry information and methods that may perform useful functions. The student is oblivious to most of this, they walk through the museum without much thought to the processing the server is doing. The first objects that need to be considered are the studentís character and the rooms.

When a student logs into the MOO, the studentís character is activated. This character is the object that the server uses to manage everything that is known about the player. There are several important properties that are attached to the student object that have an impact on the educational use of the MOO. The first is list of every room that the player has visited. There are certain objects that mark events and make awards. The student scores points in this way, either by visiting an exhibit, taking a quiz, or achieving some other accomplishment. Finally, a student has a goal, which is what they should be working on currently.

There are two types of room in the MOO. The first type is called the lecture room, since it delivers a paragraph or so of the virtual lecture. This is the object that tags the student character with the fact that it had been visited. Its description property contains the text displayed when entered. It also contains a property that holds quiz questions, discussed below. The second type is called a workroom. The lecture room is the only type of room that records a visit on the student character and is the most common type of room. A workroom is only used to house some other types of interactive object.

Currently there are two such objects that are frequently used in workrooms: the code machine and the workbench. At any one time any number of students may be present in the MOO. They may interact with each other, since every room of the MOO is a chat room. However, when two or more students try to use either of these types of machines at the same time there will be confusing results. Neither student will be able to see what the other has done. Therefore, a workroom only allows one student into itself at a time. Furthermore, when the student leaves the workroom, the workroom will reset the contained machine to its starting state. Most objects other than rooms, exits and players can be picked up and moved. Few students realize this, but those that do can move a machine far from its intended location. Therefore, if a student does pick up the code machine or workbench, the workroom will remove it, when they leave.

Interactive Objects

Some of the objects discussed in this paper could be generally used in many disciplines but the code machine and workbench are specific to the programming discipline. The code machine contains a piece of programming code, which it will display, explain or trace. The code machine may display the code with or without line numbers. The line numbers are important for the explanation and trace. The code without the line numbers allows the student to copy the code from the MOO client and then paste it into an edit window and actually compile the code. The explanation of the code works on a line by line basis. The numbered line is displayed with an explanation. The student then requests the next line. The trace of the code is a simulated execution. The code machine displays the lines that are executed along with a description of what is happening at run time, including the new contents of any variables that are changed. When a student completes either the explanation or trace of a code machine, an event is posted to their event property. The event captures the particular code machine in question and whether this was an explanation or trace.

The MOO is not used to compile student programs. The compiler resides on the studentís own computer or perhaps in a publicly available machine. Hence, some of the practice that would be desirable for a programming class must be done out of the MOO. However, the workbench represents an attempt to place part of this practice into the MOO. A workbench is a table driven parser, with enough of the tokens of a program fragment to allow the student to test whether they have the syntax of a contruct correct. The student builds a statement or program fragment from the pieces that are inserted into the workbench. When complete the student can ask the workbench to determine if the fragment is correct or not. In very simple instances the workbench may also interpret the code and run the program fragment. Like the code machine a successful parse of the code produces a point-scoring event on the student character.

Lesson Structure

ProgrammingLand is not a random collection of rooms containing instructional material any more than a textbook is a random collection of pages. There is an order imposed that organizes rooms into related clusters of rooms called sub-lessons. Sub-lessons have no required shape or size but often have some common characteristics. They are always a group of rooms on a single topic. There is often only one entrance in to the group and usually just one or two exits out. The first exhibit in the group is usually an entryway room with a short introductory paragraph and then a menu of available rooms. Often one of the rooms has only text that attempts to motivate the student or explain how the topic fits in the overall scheme of things. There is often a workroom in a sub-lesson as the final example. A sub-lesson may be nested within a larger sub-lesson.

The following objects were created to support the lesson: a sub-lesson, a sub-lesson-exit, a quiz room, a dispatcher and the roving goalie. These work together to post events on the student object and test the events. When students have enough point-scoring events, they can be given an "out of MOO" programming assignment to finalize their learning.

Sub-lessons

The head of the structure is the sub-lesson exhibit. It is a descendent of the lecture room so contains all the properties and methods of that object. It contains two additional properties as well, the all_rooms property and the requirements property. The all_rooms property is a list of all the exhibits in the sub-lesson. If a student is given credit for the lesson then the rooms on this list are removed from the studentís history of rooms visited. This is done to shorten what can be a long list of rooms, under the assumption that mastery of the sub-lesson is more important than any subset of rooms visited. The requirements property states what is expected for a student to gain credit for the sub-lesson. It is a list of lists. If they satisfy any of the sublists they are given credit for the sub-lesson. However, to satisfy a list they must satisfy every requirement of the list. Each of the sublists may require any combination of simple room visits or specific events recorded. The order that these requirements are satisfied is irrelevant, only that the students did each of the items on one of the sublists. A requirements property does not have to contain multiple sublists, but that is often the case.

The sub_lesson_exit is a descendent of the normal exit object but behaves in a rather different way. When a student chooses an exit that will leave the sub_lesson, their progress towards satisfaction of the requirements is checked. If the student has previously met the requirements, the exit moves the student to their intended destination with no action out of the ordinary. If any of the sublists of the requirements of the sub-lesson have been fully met, then the exit tells the student that they have completed the sub_lesson. It also posts a completion of sub_lesson event to their event list. If they have not completed the sub_lesson they get a different set of messages. The first sublist of the requirements is checked and one or two unmet requirements are displayed. They are then asked if they want to continue to their destination and finish the sub_lesson later or if they want to prove their mastery with a quiz. If they opt for a quiz they are transported to a quiz room.

Quiz Rooms

The quiz room is a special room that is a descendent of the regular MOO room and not any of the aforementioned rooms. It always has a single exit, which is the destination that a student usually arrives at when leaving the sub_lesson. It has no entrances; the only way in is to take the quiz option when using a sub_lesson_exit. It has a single new method, which administers the quiz to the student. The quiz is randomly generated based on the requirements of the sub_lesson and the state of the students progress toward the satisfaction of the requirements. The quiz generator determines the rooms that the student has not visited by looking at the requirements of the sub_lesson and the history of the rooms from the student. Each lecture room has a property that contains quiz questions. These questions should be about the content of that room only. It then gathers the available quiz questions from the unvisited rooms and makes up a quiz of no more than five questions. If there are not enough questions in those rooms it will look at the sub_lesson for a store of more general quiz questions to get the total up to five.

A quiz consists of up to five questions. Each question is a four or five answer multiple choice question. The questions stored in the lecture rooms are coded with three distinct pieces: the problem statement, possible right answers and possible wrong answers. The quiz generator will randomly select one of the right answers and four of the wrong answers. Therefore it is desirable to form questions that have several right answers and many wrong answers to prevent students from communicating these questions to their peers. The randomization of the answers disallows certain types of multiple choice answers like both b) and c) and discourages answers like all of these and none of these. When the student answers, they are given immediate feedback, either that the answer was correct or the letter of the correct answer. If the student answers correctly a sufficient number of questions then the quiz posts the sub_lesson completion event on the student character.

Lesson Dispatcher

The sub_lesson_exit or the quiz room may give the student the event for completing the sub_lesson. This notice is put in the studentís events property. It also notifies the dispatcher object of the student and the event. Certain sub_lessons are allowed to change the goal of a student. These sub_lessons are noted in the dispatcher. When the dispatcher receives the sub_lesson notification, it compares the sub_lesson with a list of sub_lessons and roving goalie objects. If this sub_lesson is on the list, then the matching roving goalie is activated. It will wait for three seconds and then move to the location of the student. It will assign them a goal and tell them some messages pertaining to that goal.

Goalies

A roving goalie is an object with several important properties for the interaction with the student. Generally, it is intended to give each student a separate, personalized assignment, usually a programming assignment. This is accomplished by three message properties. The first is the prefix message. This congratulates the student for completing the sub_lesson and usually starts to introduce the assignment. The second message is selected from a list of equivalent assignments. The roving goalie maintains an index which records the next assignment to be given. When an assignment is given, this index is circularly incremented. If there are more assignments than students each student will get a different assignment. If there are more students then several may receive the same assignment. The third message adds whatever concluding information may be appropriate. Every student receives the same first and third message, but the second message will vary between students. This message may be quite lengthy, not just a single sentence. If the student ever wants to reread the assignment, the goal and roving goalie are noted on their character. They have the showgoal command which shows them the three messages again. Moreover, the roving goalie records the student which received each assignment index. A student may only receive one such goal from a particular sublesson, since the sub_lesson_exit first checks that they do not have the sub_lesson completion event.

Toys in the Attic

In the spirit of the Exploratorium, the ProgrammingLand MOO is populated with a range of demonstrations, toys, robots, and interactive exhibits. These artifacts are intended to engage a visitor in the exploration of the content stored in the museum. It is hoped that these playful, interactive objects will serve to both engage and teach.

Demonstration Machines and Checker Machines

Demonstration machines were built for Lisp functions as an in-class project in the summer of 1998. A class of 50+ students were each assigned a unique Lisp function, and instructed to create a machine with a 'demo' function that would illustrate the operation of the function. For example, the Lisp 'cons function' room contains a description of the 'cons' function, written on the wall, a 'cons' machine that will give a demonstration of how the 'cons' function works, and a 'cons checker' machine where players can plug expressions in to see if they're well formed.When the student plugs a correct value into the machine a congratulation message is returned and an 'award' is added to the player's history. When the player makes a mistake, the feedback includes the correct answer.

The Recursive Leprechaun

Since recursion is one of the most difficult concepts for students to master, it is important to expose the students to recursion as often as possible. One approach is to implement a recursive leprechaun, which resides in the Realm of Recursion. The recursive leprechaun demonstrates a recursive counting function in a visually descriptive manner. For example, the Leprechaun gives demonstrations of recursive counting by producing new leprechauns from a sack, and handing them an N-1 value to count; when N reaches zero, the leprechauns shout their value, pass it to the next, and jump back in their neighbor's sack.

The Ring Toss Game

The Ring Toss game is intended to provide an amusing challenge in the area of associating programming languages with their historical antecedents. The goal of the ring toss game is to associate languages with people and other concepts. More than one ring can be tossed on a single peg.

The History Jukebox

The History Jukebox is a device for summarizing programming language history in an entertaining and on-demand fashion. If a player were to 'press 1959 on History Jukebox' they would be told about John McCarthy at MIT and the origins of Lisp.

Tutor Robots

Tutor Robots were implemented to make the function rooms in the LambdaMOO wing more active and engaging. They are created from a prototype Turing Robot developed by Ken Schweller, based on the Eliza model (Weizenbaum, 1966) which was inspired by Turing (1950). The Robots are user programmable and capable of matching key words and sentence patterns, and can be implemented with random responses and question responses. However, Tutor Robots can display both remarkable responses, and remarkably obtuse responses.

Conclusion

ProgrammingLand was never designed to be completely self-contained. The student will always need access to a language system. Thus the goals assigned by the roving goalie are externally satisfied. Related MOOs such as the Geology Explorer (Slator et al., 1999) have a goal system that is completely internal. When a student is interacting with the Geology Explorer, they always have a goal, usually the identification of some mineral on the virtual planet. When they find that goal they are congratulated and given a new goal. The system itself may monitor the progress toward the goal. If they need a particular instrument to properly distinguish a mineral from others that may appear to be similar and they leave the starting point without it, a tutor may appear and give them some instruction. Similarly, if the goal mineral is in a room and they leave without identifying it, then a tutor may appear and give them some instruction about that as well. These advantages stem from the fact that the goal is issued by the MOO and progress towards the goal may be monitored by the MOO. Though there are many parallels between Geology Explorer and ProgrammingLand, there are some differences as well. Specifically Geology Explorer is a virtual laboratory, the student should gain experience and hone skills. ProgrammingLand is designed to replace either the textbook or the lecture or both. However, its laboratory features are substantially weaker, due to the topic. ProgrammingLand provides some facilities such as code machines and workbenches but the bulk of the experimentation must be outside of the MOO.

Student evaluations of a course using ProgrammingLand were generally quite high; in one survey, 92% of the students responding rated the quality of the course as either above or much above average. Similarly, 88% of the students believed their understanding of the course content was either good or very good.

The ProgrammingLand MOO is an interactive learning environment. It attempts to balance content material and immersive exploration. It is more interactive than a textbook or a lecture, it keeps better records than web instructional pages, it also productively uses the information that it records.

References

1. Hill, Curt and Brian M. Slator (1998) Virtual Lecture, Virtual Laboratory, or Virtual Lesson. In the Proceedings of the Small College Computing Symposium (SCCS98). Fargo-Moorhead, April. pp. 159-173.

2. Holmevik, Jan Rune and Cynthia Haynes (1997). http://lingua.utdallas.edu/encore/.

3. Slator, Brian M. and Curt Hill (1999). Mixing Media For Distance Learning: Using IVN And Moo In Comp372. World Conference on Educational Media, Hypermedia and Telecommunications (ED-MEDIA 99), June 19-24, Seattle, WA.

4. Slator, B.M., P. Juell, P.E. McClean, B. Saini-Eidukat, D.P. Schwert, A. White, C. Hill (1999). Virtual Environments for Education at NDSU. World Conference on Educational Media, Hypermedia and Telecommunications (ED-MEDIA 99), June 19-24, Seattle, WA.

5. Turing, Alan (1950). Computing Machinery and Intelligence. Mind, 65(236), pp. 433-460. Reprinted in ``Computers and Thought'' (1963). Edited by Feigenbaum and Feldman. New York: McGraw-Hill.

6. Weizenbaum, Joseph (1966). ELIZA -- a Computer Program for the Study of Natural Language Communication between Man and Machine. Communications of the ACM, vol. 9, pp. 36-45

Acknowledgements

Thanks to Faye Erickson, who implemented the 'cons machine' and the 'cons checker'; Tom Lemke who implemented the 'recursive leprechaun'; Mahesh Sharma who implemented the 'ring toss game'; Bryan McGowan who designed the History Jukebox; and Justin Abel who implemented Curly the Tutor Robot.