Content-type: text/html Downes.ca ~ Stephen's Web ~ Self-Pacing & Collaborating

Stephen Downes

Knowledge, Learning, Community

Jan 31, 2000

Posted to WWWDEV, 1 February, 2000.

Sharon Roushdy wrote:

This is a non-technical question. Most courses using WebCT forums for collaborative projects and activities seem to be courses offered during a typical set period like a semester, quarter or set number of weeks. We have an asynchronous program which uses self-paced courses and we would like students to collaborate on case studies. The obvious problem being that if students are starting at different times and proceeding at different speeds through the material, how do you get them together to collaborate? Has anyone on the list had experience with this?

Caveat: I haven't had experience with this in an online course because nobody will let me try it. However, I have had experience with a similar situation in online gaming.

Let me set up the scenario:

In a multi-user online adventure game, the objective is to gain experience points. A beginner - a 'newbie' or 'vanilla' - starts with zero points. Points are accumulated by finding treasure and more often by killing monsters (online adventure games tend to be violent, but we'll let that slide).

As players accumulate points, they progress through a series of levels. After gaining a thousand points, say, they become a Level 3. After gaining a hundred thousand points, they become a Level 15. The objective of online adventure games is to achieve Level 20 and (if you haven't annoyed administration) be promoted to 'Wizard'.

At any given time there are many players in an online adventure game. Some are at Level 1 and some are at Level 19 (and some every level in between). They start on different dates, play at different times (since they are scattered around the world) and advance through levels at their own speed.

The accumulation of points in an adventure game is very similar to the accumulation of knowledge in an online course. As a player accumulates points and advances levels, his or her character gets stronger and is able to kill more powerful monsters. And in fact what also happened is that as a player gained experience, he or she became more adept at the game and could manage to tackle difficult monsters without getting killed.

Game designers soon found this system to be too simple, however. As it turned out, anybody with enough time could advance through the 20 levels by killing enough 1 point frogs - hardly a challenge. They were faced with the prospect of promoting people to 'Wizard' for the dubious achievement of having effortlessly killed 200,000 inoffensive creatures.

So they upped the ante. I n addition to having accumulated a certain number of points, a candidate for a certain level would also have had to complete a 'Quest'. In order to complete a quest, a player would have to solve a puzzle, traverse a maze, kill a monster with a special hidden sword, find the lost key, or perform some other feat which rises over and above mere slaughter.

Different quests were set for different levels. In order to achieve Level 3, for example, the player had to solve the 'Orc Quest' (a famously easy quest involving numerous Orcs). In order to achieve level 5, the player had to solve the more difficult 'Troll Quest'. And so on up the line, the player being required to solve the 'Dragon Quest' to achieve level 20.

What is important to note here is that quests were specific to levels. A player above a certain level was prohibited from completing newbie quests. And for players at the lower levels, it was suicide to attempt an upper level quest. Thus we have the idea established of tests being set at certain intervals through the 'course' for different levels of knowledge and achievement.

But because a games 'Wizards' achieved power and standing, and because the wizards were responsible for actually designing parts of games (including new quests) it was important that wizards actually be able to get along with other people (you'd be surprised what a problem this was in online adventure games).

Quests were inherently easier to complete in groups (six players can take out a dragon much more easily than one, just like in real life). Moreover, many quests were designed in such a way as to require a group - I designed one quest where you had to close the door to get the key, and then had to wait for your partner to open the door from the other side. After a few players starved to death in my little room, they got the point and started working in groups. Though it was a nifty way to off an enemy...

So now we have the scenario of collaboration established: in order to complete a quest, a number of players of roughly the same level must assemble together in a real time environment, work together in harmony, and solve the quest. And in fact the online games in which I played were generally full of quest parties setting off to battle.

How did they do it? Two elements were key:

First, a clearly designed and documented set of quests had to be set up, available for all players to read, so they could plan ahead. Most importantly, it had to be clear what level the quests were designed for (it being unfair to lure a newbie into a Level 20 quest).

Second, players had to have a means of communication by which to establish questing parties. Multi-user adventure games employed two major strategies: first, the 'Quest Board', so players could leave messages to each other, and second, interpersonal real-time chat, so players could synchronize their movements.

Players attempting to achieve Level 5 would know well in advance that they faced the Troll quest. So they would post a note on the Quest Board advertising for partners at or about Level 5 for the Troll Quest. Some negotiation was the norm - players had to work around work schedules, time zones, and the occasional unfortunate death. But at the appointed time they would gather together, each having set aside enough time, and complete the quest.

The Quest Model for asynchronous collaboration follows this example. It involves two major elements:

First, a clearly defined set of tasks where the 'level' of the task is apparent, and

Second, some mechanism of interaction which allows users to come together at an appointed time to accomplish the task at hand.

Now if you want to give students more complex tasks you may need to give them more tools. For example, if students are sharing a writing task, as they may be when writing a case study, they will need a space to store and retrieve updated versions of their materials. If they need to discuss matters, they will need a chat tool for synchronous communications. I won't get into the details of these because they vary with each assignment.

Finally, one more caveat: the Quest Model requires a certain minimal level of participation. If you have only ten students over the course of a year, they will find it very difficult to find partners. Experimentation is necessary, but generally you need to have four or five students at any given 'level' in the course. Otherwise collaboration is impossible and will fail.

(As an aside: this is why you should be careful about piloting courses with ten or so students (as adminsitrators are wont to do, which is why I never got to try it). The dynamics of an online course - or online game, for that matter - are completely different with ten people and with a hundred people.)

I hope my gaming experience helps - and I would be interested to knwo whether anyone has tried anything similar in an educational setting (and how it worked out).



Stephen Downes Stephen Downes, Casselman, Canada
stephen@downes.ca

Copyright 2024
Last Updated: Nov 23, 2024 3:06 p.m.

Canadian Flag Creative Commons License.

Force:yes