More than one class at once

[Ampers]

Hi there,

I just have a question about what happen when you want to run more than one subject within the one firm. eg Real Estate, Commercial and Civil law. Is it possible to create a firm (simulation) that draws on more than one blueprint, OR do we have to create one big blueprint that has all the subject content it in for the whole term?

[mhughes2k]

It probably is better to not think of the simulation as the firm. But think of a firm (group of students) having multiple "cases" (a simulation instance)

This is the way that we run multiple subjects with the same firm. We set up a firm group of students (Firm 1 through 64), and then we have 4 subject projects (Personal Injury, private client, Conveyancing and Civil Court action).

We create an instance of each subject project, and allocate it to each firm.

When the the firm users log in to SIMPLE they get a list of the 4 simulations (aka Cases/subjects) to choose from and they "drill down" into each case. The jump list at the top of SIMPLE allows them to switch between the cases quickly!

[mhughes2k]

There is an imaginary construct in existence here...namely the "Player-Character". The player-character is in SIMPLE is no specific thing. If you have simulation (instance) (which is created from a blueprint within a Project) then there is an implied "Player-Character" but we've never explicity said *who* that is.

So here goes...
Each blueprint represents the process/workflow/experience of A SINGLE PLAYER-CHARACTER. Now that player (dropping Character from now on) can be:
1)a single physical entity e.g. Joe bloggs the Lawyer.
2)a compound physical entity. e.g. Linklaters the law firm.
For the purposes of designing the simulation blueprint it doesn't matter.

When it comes to *playing* the simulation it becomes a little problematic. In case (1) its pretty easy, there would normally be a 1-to-1 mapping of the Player to a single user.

In case (2) you *may* have multiple users allocated to the "firm".

Underlying this SIMPLE allows this to be implemented in a number of ways:
You can allocate a single user account to a simulation and you have case (1).
You can allocate multiple, individual user accounts and you have case (2).

-or-
You can create a group (comprising of multiple individual accounts) and allocate them to a simulation. This implements case (2).

Now this is fine for student-level users, adding any account to a simulation by any means makes them a "student" and they only have the basic Player tools.
But when you add a user or group to a simulation you *can* change the rights that that it has on the simulation you are adding to. This is the basic premise for making users into "staff" users.

[Ampers]

Thanks Michael for getting back to me.

"think of a firm (group of students) having multiple "cases" (a simulation instance)" was quite helpful.

We haven't experimented with variables yet, but when the players have multiple cases, how do you keep the supervisor of the firm's name (and say the address of the firm) consistent between each case? Or does that not even matter?

[mhughes2k]

The easy answers are you could
1) use the same non-variablised supervisor name in all of the projects (this is assuming that the actual member of staff is "hiding" behind a fictional supervisor role).
2) don't care that the fictional supervisor is different in the projects (e.g. we have different supervisors in the company who look after different areas of law)

What we actually do is have a plugin which adds a new variable command, which looks up what the information should be for a particular firm. A sort of "shared table" of information, which via the variable command can be used consistently across different simulations. So the command #LOOKUP(1,'seniorpartnername') always returns the same value when the parameter "1" is passed in.