Saturday, 6 November 2004

Online Role Play Simulation Design - 3

This is the third of a series of posts on creating online role play simulation. The first post was on how we normally run an online role play simulation. The second post described how to create an engaging and effective online role play simulation.

In this post, I shall describe the re-usability regime of Fablusi version 2.

In Fablusi, we distinguish between 4 types of users: simulation creator (author in short), administrator, moderator and player. Re-use makes sense to the first three types of users. In the following, I will briefly describe the main re-use mindset of each of the first three types of users and then how Fablusi provides re-use support matching the mindset.

Authors are people who create role play simulation, whether for their own learners or for sharing. The primary objective of identifying this user type is to allow role play simulations to be used by others who cannot afford the time and resources to create their own simulation. They can just choose an existing one (via administrator type and moderator type).

The primary re-use concern of authors is to minimize the amount of tedious work involved in creating a simulation. As mentioned in the last post, after the conceptualisation of the simulation, there are a number of tedious jobs: creating roles, iSpaces, tasks and writing up kick-start episodes. (For the meaning of these terms, please refer to previous posts.) All these "components" are reusable. At the moment, there are built in "web-retrieval" for importing pre-built roles, iSpaces, tasks (and in fact all components) from "content packs". Shortly in version 2.1, we plan to allow authors to export their roles, iSpaces etc. for future import.

The second reuse, more like a usability, is the concept of "group". By putting roles into groups, rights can be assigned to the same group by a single click and later further customised by adjusting other groups in each iSpace right setting. A rough observation from how our authors work show that by properly grouping roles, there is an average saving of 30 clicks for each iSpaces and a significant reduction of errors too.

Look and feel used to take up a lot of time during the design process. We now move to a complete CSS-supported paradigm. The look and feel is applied by selecting a template. We have some pre-built look and feel and authors can further modify the look and feel by changing the CSS.

Administrators is a handle for job of initiating a role play simulation and allocating players into different roles. The first reuse is from the separation of this type of user from the authors. Now, you can just select from a collection of role play simulations (yours or created by other authors) and instantiate to run.

We also support self-role selection. During self-role selection, administrator may also like to collect a set of data from the players. The data to be collected is defined by a set and the set can be re-used in other simulation or worlds. Notification emails are based on templates which are either pre-built by us, or created by administrator for future or current re-use.

In order to cater for different cohort size, we allow grouping the cohort into worlds and allow them to play within the worlds. Worlds a great re-use concept, the same design (roles, iSpaces,...) are repeated without additional work.

Administrators may also like to change the look and feel. Again, this can be further customised from the "default" specified by the author, or select a completely different look and feel depending on whether the author has granted the right to do so.

We have spent a lot of time in building a comprehensive moderator tool box to support the job of moderating and assessing a role play simulation. The assessment assistant (AA as we call her) consists of defined rubrics and activation rules. Again, these are re-used as they are designed as components to be plug-into different simulations.

Running any reasonable size role play (say for a typical cohort of 40 players) over 2 to 5 weeks is a major task. There are lots of planning, design and administration. Fablusi has moved beyond just a platform for delivering role play simulation. We have developed many procedures and supports to streamline and minimize the effort required. The fact is that any "artificial intelligence" of a piece of software actually represents a lot of work either from the Fablusi team, the authors and/or the administrators. By implementing a rigorous re-use regime, I hope that such work can be re-used over and over again.

My ultimate goal is to create a system which allows a "15-minute" preparation time to deliver a 2 to 5 weeks role play simulation. I also aim to create a moderating environment so that a moderator can reasonably moderating a 40-player role play by spending one hour per day during the actual running time of the simulation - including providing continuous assessment during the role play. There are still hard work, but I hope the system can provide an environment to do the job within reasonable effort.

No comments: