Planet X: The Geologer Project Design

The Geologer project intends to implement an educational game for teaching the Geosciences. This will take the form of a synthetic (or virtual) envirionment, Planet X, where students will be given the means and the equipment to explore a planet as a Geologist would (see the The Geology Explorer storyboard for the first thinking behind the project).

The game will be designed to give students an authentic experience that will include elements of:

• exploration of a spatially oriented virtual world;
• practical, field oriented, expedition planning and decision making;
• scientific problem solving (i.e. a "hands on" approach to the scientific method);

The first Planet X prototype will be implemented using the freely available Xerox PARC LambdaMOO, which is a development environment for creating text-based virtual worlds. LambdaMOO is an object oriented MUD (Multi-User Domain), implemented as an object oriented database with a messaging system and an extensible, object oriented scripting language.

Planet X development will be accomplished by creating objects in the LambdaMOO environment and implementing methods (verbs) on those objects in order to simulate an authentic exploration and problem-solving experience. To accomplish this, the following classes of objects will be implemented:

• objects representing geological spaces (mountains, caves, buttes and the like -- these will be implemented as instances of the LambdaMOO "$room" object);
• objects representing geological artifacts (outcrops, minerals, streams, and so forth -- these will be implemented as instances of the LambdaMOO "$thing" object), and programmed to act and react like the real thing
• objects representing the tools and instruments of Geologists (both field instruments like a compass, a rock pick and an acid bottle, and laboratory instruments, spectrometers etc., to perform complex analyses -- these will also be implemented as LambdaMOO "things")
• objects for representing game players (these will be special instances of the LambdaMOO "$player" type)
• objects representing on-line tutors (these will be software agents implemented as another special instance of the "$player" type)

A complete inventory of the objects for representing spaces, artifacts, tools, field instruments, and laboratory instruments, for the first prototype of Planet X, can be viewed at Planet X Composition and a preliminary "map", crudely implemented as an HTML table can be viewed at Map of Planet X. Design criterion for the player and tutor objects are below.

The remainder of this document is divided into the following parts: 1) Game Design; 2) Implementation Notes; 3) Minor Design Questions. An earlier document, the Planet X Task List, includes details that are relevant to this document. The design and implementation plans for the first prototype of Planet X should be seen as a combination of the two documents.

Game Design

1. Players will log on using their last name and NAID for password;
2. The game will record player connections and progress in terms of goals achieved, tutoring sessions, points scored, and so forth
3. The connections will be timed and metered so that sessions are concluded after one hour or 100 "moves", whichever comes first (timed tests achieve a couple of goals: 1) they eliminate concerns about students applying "brute force" solutions, and 2) they simplify comparisons of the student's experiences and relative progress).
4. Players will be given a "goal note" when they log on each time which will list
   1. a primary (discovery) goal -- eg. find diamonds (worth 1000 points)
   2. a secondary (evaluation) goal -- eg. assess whether the hill country will be suitable for oil exploration (worth 500 points)
   3. a general goal -- identify as many rocks and minerals as possible (25 points each)
5. Players will be able to see their progress at any time (with, perhaps, a "look score" command), and will be able to see a classwide scoreboard (with, perhaps, a "scoreboard" command).
6. The game will keep track of which goals a player has achieved in previous sessions so the same one will not reappear, but unfulfilled goals might be assigned more than once
7. Players will be able to "buy" whatever field instruments they wish
8. A map of Planet X will be available via the Web
9. Players will be able to ask for help at any time, on a variety of topics. See Help below for a complete list.
10. The planet will be implemented (see Planet X Composition) with a wide variety of
    1. places/formations/rooms (at least 40)
    2. rocks and minerals (40 of each)
    3. field and laboratory instruments (approximately 40)
11. Players will score points by "reporting" their discoveries, and they will lose points for incorrect "guesses" (say, a 15 point deduction for each wrong answer).
12. In general, tutoring will be through unintrusive but proactive software agents. Agents will monitor student actions and will "visit" a student when the need arises. Tutors will give advice, but they will not mandate or insist on student actions, nor will they block or prevent student actions.
    There will be (at least) three tutoring agents in the game:
    1. an equipment tutor who will detect when a student has failed to "buy" equipment necessary to achieving their goals
    2. an exploration tutor who will detect when a student has overlooked a goal in their travels
    3. a science tutor who will detect when a student makes a wrong guess and why (i.e. what evidence they are lacking); or when a student makes a correct guess with insufficient evidence (i.e. a lucky guess)
13. It will be a general design principle that the game environment will be implemented with an eye towards entertainment value. In the ideal case, the playful elements of the game also serve to reinforce some element of the pedagogy -- this is rare, however. In the general case, and as a statement of policy, a game should have just as much frivolity as it can afford. This statement recognizes the fact that humans are inclined to play, and educational games that fail to capitalize on that are bound to fail.
14. An assessment protocol will be developed that compares student learning in terms of both conceptual (fact-based) and procedural (problem-based) knowledge.

Implementation Notes

1. Login Issues
   • A soft copy of the class list, complete with NAID numbers, should be obtained from ITS at some point in the semester
   • Need a Unix routine (PERL, Lex) implemented to take the ITS file and automatically produce a "login creation" file that can be uploaded to the MOO.
   • Need the Geosciences MOO player creation modified so that logins can be limited to students and guests, to keep our environment "clean"
   • Need a system so guests can continue to log in (for demos if nothing else).
     • Need a message about guest logins and getting a guest number added to the welcome screen
     • Need a verb (like who and version) that returns a fresh guest name/number
     • Need a registration "form" for guests to provide real names and email (for follow-up surveys)
   • The player's ability to rename themselves should be discouraged or disallowed somehow. It sows confusion in the MOO and makes the reporting functions less useful.
2. Tracking
   • There are a 100 details in here: what to record, how to represent it, etc.
   • The MOO will need to produce nicely formatted reports on a daily and weekly basis for the instructor's benefit
   • The question of what to record, and how to interpret it, are intertwined with assessment questions (see Assessment below).
3. Time Constraints
   • Need login time recorded as a property of the player (this might already be happening),
   • Need a .move_count property on each player initialized to zero at each login.
   • Need a verb implemented on generic exit (#7) to count "moves" and increment the player's .move_count property (experiments and help queries should NOT count, I think, just roaming from room to room).
   • Two potential problems:
     1. the cluster machines have their own timeout mechanism, much less than an hour, which will confound our statistics;
     2. a player who moves to a room and never leaves will escape the detection of the exit counter, so some other timeout mechanism must be dreamed up in addition.
4. Goals
   • Need the Geologists among us to create a set of plausible goals for the benefit of the Computer Scientists among us;
   • Need an implementation of goals which includes both a readable text component and a hidden object component. Both the scoring and the tutoring will depend on this.
   • Need the login routines modified to semi-randomly assign a goal to a player (and notify them of their goal).
   • Need a routine that formats the goal nicely for player reference; something like showgoal me.
5. Scores
   • Need a player's score to include their current score, their best previous score, the goals they've accomplished this turn, a list of goals they've accomplished across all sessions (like an Audobon birders career list), and the amount of time they have left in this session
   • Normally games of this sort also have a ranking scale: (less than 50 points -- beginner; 50 to 150 points -- novice; and so forth); this should also be on their score card
   • A master scoreboard is an essential factor and some system must be figured out (see Problems with a Master Scoreboard, below).
6. History
   • There are 100 issues in here too, concerning what to record and how to represent it.
   • The MOO needs to record goal history in order to insure that goals, once achieved, are not accidentally assigned again (is there an interesting pedagogical study in here for deliberately re-assigned goals?).
   • The MOO needs to keep track of a lot of stuff connected with goals: i.e. where were they satisfied? what missteps occurred along the way? or, if they were not satisfied, where did they fail? and why?
7. Instruments
   • Need a purchase verb, defined on $g.instrument, as follows:
     • call: purchase X
       where X is an instrument name like "rock pick"
     • creates a child object of the particular instrument
     • names the instrument using the naming convention described below
     • assigns ownership to the player
     • places the instrument into the player's inventory
     • charges the player the value of the instrument from it's .dollar_value property by adding the value to the player's .dollar_charges property.
     • calls the instrument tutor to evaluate and possibly remediate on the player's purchasing decisions.
   • Need a record verb, defined on $g.instrument, as follows:
     • call: instrument:record(player, rock/mineral, result)
     • adds an ordered triple to the player's .instrmnt_test property that records every test, by every instrument, on every rock/mineral, and the result of that test.
8. Map
   • For all the effort that has gone into it, the HTML Map of Planet X is barely useable and needs to be relaced with a nice GIF or JPEG that can be viewed from the WWW.
9. Help
   • Help in LambdaMOO is managed through a system of "help databases". LambdaMOO provides methods for creating/modifying/deleting these databases. Planet X needs to have several such help databases, listed above, and also needs to have the main help system modified to include a reference to the new databases. Help topics will include:
     1. rock and mineral definition; eg. "help pegmatite" will give a description including color, streak, hardness, etc.
     2. instrument use; eg. "help acid bottle" will give a description of the uses of the acid bottle in field testing, including the chemistry involved
     3. field techniques, testing techniques
     4. the rules of the game
     5. advice on how to achieve goals
     6. others (?)
10. Composition
    • The rocks of Planet X will all be stored in the Rock Museum with their nominative name: i.e. Slate
    • Each rock must have a .descriptive_name property; i.e. Smooth Flat Grey Boulder
    • The "rooms" of Planet X must be populated with the appropriate boulders, outcrops, and mineral deposits. To accomplish this:
      1. The Planet X Composition table should be updated (with the advice of Geologists), so that each location has a list of rocks and minerals that belong there, rather than the current system where a single rock and mineral is associated with each place.
      2. Need two (2) setup verbs, defined on $g.rock and $g.mineral, as follows:
         • call: setup X in Y
           where X is a rock or mineral (nominative) name like "Slate" and Y is a location like "Sinkhole Margin".
         • creates a child object of the particular rock or mineral
         • names the new outcrop by concatenating the rock's object number (see the naming convention described below), with its .descriptive_name property (i.e. "Smooth, Flat, Grey Boulder")
         • moves the new outcrop to the location named in argument Y
         • makes the new outcrop fertile
         • locks the new outcrop into the new location (using .key = #2)
    • The minerals of Planet X must all be stored in the Rock Museum with their nominative name; i.e. Halite
    • Each mineral must have a .descriptive_name property; i.e. Smooth Faceted Translucent Crystal
    • Each rock must have it's .minerals property filled with a list of {proportion / mineral} pairs, where the proportion is an integer and the mineral is an object number; i.e. {{40, #336}, {35, #360}, {25, #246}}
11. Reporting
    • Players will score points by showing they have achieved goals. They will do this by "reporting" their discoveries
    • Need a definitive list of the rocks and minerals in terms of the instrument tests that will confirm or deny them.
    • Need a report verb, defined on $g.geologer, as follows:
      • call: report X as Y
        where X is a rock or mineral descriptive name like "smooth grey slab" and Y is a rock or mineral nominative name like "Slate"
      • record the report on the player's history list
      • check the correctness of the report
        • if the report is correct: a) update the player's .score property; b) record the correct guess on the player's .report_history property; c) call the appropropriate tutoring agent
        • if the report is incorrect: a) record the incorrect guess on the player's .report_history property; b) call the appropropriate tutoring agent
12. Tutoring Agents
    • So far, three (3) tutoring agents have been identified.
    • The three (3) tutoring agents will operate as follows:
      1. The Equipment Tutor
         • The equipment tutor is called by the purchase verb (described above in the Instruments section). The tutor checks whether the instrument purchased can be used to satisfy any of the player's goals. If not, the tutor may decide to remediate on that topic (i.e. buying instruments that serve no obvious purpose)
         • The equipment tutor is also called by the exit(s) from the Equipment Locker. The tutor checks whether the student has the instruments needed to satisfy their goals. If not, the tutor may decide to remediate on that topic (i.e. the need to buy instruments that serve to satisfy goals)
      2. The Exploration Tutor
         • The exploration tutor is called by the exit(s) from each of the locations (rooms) on Planet X. The tutor checks whether the student is leaving a room that might satisfy a goal; i.e. if their goal is to locate Kimberlite, and there is Kimberlite in the room they are leaving, the tutor may decide to remediate on that topic.
         • This remediation could be done on a room-by-room basis (easiest), or it could be done on a region-by-region basis (harder); or on a hot-cold basis (i.e. if the player is moving farther away from some distant goal).
      3. The Science Tutor
         • The science tutor is called by the report verb (described above in the Reporting section). The tutor checks the player's .report_history property (also described in the Reporting section), and determines which of the following cases are relevant:
           1. (wrong tests) the player has "guessed" incorrectly and the player's .instrmnt_test property indicates they have not conducted the necessary tests to identify the rock/mineral in question
           2. (wrong answer) the player has "guessed" incorrectly and the player's .instrmnt_test property indicates they have conducted the necessary tests to identify the rock/mineral in question
           3. (lucky guess) the player has "guessed" correctly but the player's .instrmnt_test property indicates they have not conducted the necessary tests to identify the rock/mineral in question
           4. (good work) the player has "guessed" correctly and the player's .instrmnt_test property indicates they have conducted the necessary tests to identify the rock/mineral in question
         • Depending on the results of the reporting analysis, the tutor may decide to remediate on the spot, or may decide to defer remediation until the player begins to show a pattern of behavior.
13. Atmosphere
    • Policy: In general, there should be plenty of room for play in every game. This means the entertainment value of a game could/should include "frivolous" entertainment whenever that frivolity can be made a) consistent with the environment and b) not excessively distracting or c) misleading. These criterion are qualitative and fluid, and boil down to a matter of "look and feel", and taste. Some possibilities are listed below.
    • Animals and Plants: flora and fauna would be expected on any earthlike planet.
      • Small creatures have been implemented on Planet X that do not interact with players: a chipmunk, a deer, etc. (visit Nathan Green's Hilly Forest, north of the Hill Region, for an excellent example);
      • there is also a dog that is supposed to play and fetch ( I've changed my mind on this. Nathan Green has pointed out that a trained dog is a highly plausible crew member, if not a very plausible planet dweller, and on that basis should continue to be an element of the game). It's still not working (as of July 10, 1997), however.
      • In addition, we wouldn't be surprised to find bats in caves, and lizards in the desert, and so forth.
      • Dangerous animals? See Hazards, below
    • Space Junk:
      • We could imagine finding the wreckage of a long lost space probe. For example, there is a famous old story of a Fortran mistake (using "i=9" when they should have used "i = 9") that resulted in a rocket veering into the sun.
      • We could hide a meteorite somewhere on Planet X and give bonus points to anyone resourceful enough to identify it.
    • Fossils: a natural extension to this game is in the direction of Paleontology (sp?). Even in this game we could give small points for bringing back small bone samples, and deduct points for breaking off chunks of big bone samples (which would probably be a BAD thing to do, right?)
    • Hazards: there are hazards in Geology, both in the field (avalanche, serious falls, deep water, carnivores, poisonous snakes, volcanic gases, magma, exposure, starvation, etc.) and in the lab (toxic chemicals, dangerous equipment, etc.), not to mention the famous exploding rock-pick.
      This leads to some fundamental design questions.
      • On the one hand, it's unquestionably the case that awareness of and preparation for hazards is part of being a geologist and learning to think like a geologist. It's also quite true that the possibility of "death" lends an extra element of excitement and urgency to a game.
      • On the other hand, being killed in a game will upset some people, and will distract some others from the principal objectives of our pedagogy.
      • On yet one other hand, getting stung by a scorpion (i.e. wounded not killed), will teach the valuable lesson of taking a first aid kit into the field.
      • In practical terms, however, implementing danger (in whatever form) will add to development time.
14. Assessment
    • Assessment for this project must take at least two (2) forms: 1) assessment of student learning and 2) assessment of system "usability".
      1. Student Learning:
         • The students of Physical Geology 120, or a portion of them, will be subjects in a bi-modal study. Each will be given a pre-test instrument composed of two parts: 1) a selection of standardized, multiple choice questions; and 2) a subjective, case-based exam where authentic geoscience scenarios are described and the students are asked to work through the problem sets as a geologist would.
         • The students will be separated into two groups at some point in the semester. Half will be given a self-paced, on-line, textbook and quiz system to work through. The other half will become explorers on Planet X. At the end of the parallel sessions, a similar two-part post-test instrument will be administered.
         • Students will also be assessed in internally (i.e. within the game) according to how well they accomplish their goals.
      2. System Usability
         • Several questions go into the design of user tests: Could they understand the software? Could they get the help they needed? Was it clear what they were supposed to do, and how they were supposed to do it? What should be different?
         • In addition, games must rise to the qualitative standard of "playability": Did it engage? Was it fun? Did it get boring after awhile? Was it too easy or too hard? What should be different?

Minor Design Questions:

Naming Conventions

        "get #1731" or "hit #1731 with #1992"

        "hit smooth grey slab with hammer"

Problems with a Master Scoreboard