[MUD-Dev] Mudding and impact on academic grades
acius at simud.org
Wed Jun 12 22:25:38 New Zealand Standard Time 2002
Philip Mak wrote:
> I run a social/RP MUSH. It's final exam time for many high-school
> students and some university students now, and I see people
> talking about how they have all this academic work to do... while
> hanging out on the MUSH and probably spending a few hours per day
> I also see people who are worried about grades because they need
> to maintain a 3.x GPA or else they'll lose their scholarship. No
> scholarship = no college. (I myself probably mudded more than I
> should have during my undergraduate and masters degree days,
> although I still managed to pull through in the end.)
> Anyway, I feel kind of bad, fearing that my MUSH may contribute to
> wrecking someone's academic status.
> Has anyone else thought about this? Any ideas on how to make a
> MUSH coexist more peacefully with its players' academic standing?
I have given a good deal of thought to this. We work as hard as we
can to make our games "addictive," then expect people to "act
responsibly" in how much they play. What does addictive mean, then?
The problem, of course, is simple economics: A non-addictive game is
not addictive because it's not fun to play. If it's easy to leave,
they're unlikely to come back. That's exactly what you *don't* want,
right? How do you make an addictive game, then persuade players to
limit their time playing it?
Here are a few ideas that I've come up with:
1. Reward time away from the game.
In an MMORPG, you could have "craftsmen" players be working on
crafted items during the time that they're not logged on. To make
sure that the player still logs in at least once a day, though,
you could have them quit crafting after 18 hours -- after that,
they need to log in again and resume their crafting where they
2. Remove incentives beyond a certain playtime.
Your player "needs to rest," because you have been adventuring for
more than 2 hours now. For the third hour, he gains experience at
half the rate, and heals half as fast. Beyond the third hour, he
doesn't gain any experience, and heals at a fourth his normal
rate. The downtime needs to be more than a quick login and logoff
-- the penalties only disappear after staying away for "long
enough for him to sleep" (say, 2 hours at least). Basically the
idea is to implement the law of diminishing returns with respect
to playing time.
3. Rewards for logging in after a break
Certain powerful abilities might only have 20 or 30 uses per
login. This might be compared to the D&D "memorized spellbook."
After you've used up all of these abilities, you have to log off
for 2 hours before they're recharged. Powerful spells,
teleportation abilities, extremely powerful damaging moves from
warriors, etc., could all make use of a system like this.
These were written with MMORPG's in mind, but I suspect the
principles could be more generally applied. There's another good
argument for a system like this: If you can change player behavior
so that they log in *regularly* but for a *limited amount of time*,
you have reduced the load on your servers, hopefully without losing
players from your revenue base. This should allow you to handle more
players with fewer resources. Also, many players (or their parents)
don't want to buy highly addictive games because they worry about
how much time they'll spend on them (Yes, people really do this,
e.g. myself). These people might be persuaded if the game has
built-in safety mechanisms to control the amount of time spent.
There are some other interesting problems that this could solve --
players who spend more time in the game don't have a linearly
proportional advantage over those who spend less -- rather, the
advantage exhibits diminishing returns. It takes longer (in rl
months) to get a character into the very high levels; the players
don't 'max out' as quickly, and you might hang on to them longer.
Oh, and you might also keep them from flunking out of college, or
save a few marriages. That would be a nice side effect :-).
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev