Key hoarding problem
Goto page 1, 2  Next
 
Post new topic   Reply to topic    mudlab.org Forum Index -> Design
View previous topic :: View next topic  
Author Message
Grabnar



Joined: 30 Apr 2006
Posts: 15

PostPosted: Sun Apr 30, 2006 9:23 am    Post subject: Key hoarding problem Reply with quote

I've recently been thinking about solutions to the problem of "key hoarding", which unfortunately tends to occur on a lot of MUDs.

Let's say there's a door in a dungeon, and the only way to open said door is by unlocking it with a key found in the same dungeon (the lock cannot be picked or smashed open). Everything is going fine until someone gets the key and instead of unlocking the door, they decide to hold on to the key indefinitely (either to sabotage other players or because the don't know any better), thus making further progress impossible. Annoying.

How can it be fixed? Some possible solutions are:

1 - Make key hoarding illegal: Punish players who are caught doing it.
Problems: Requires some degree of player monitoring. Hard to enforce (How do you prove someone was hoarding a key?)

2 - Do nothing: Allow key hoarding as an acceptable play-tactic.
Problems: Not really a solution. Can work in some games if PK and looting are possible.

3 - Teleporting key: After a certain amount of time, the key is teleported to a random location nearby.
Problem: Not particularly elegant or "realistic". Potentially punishes players who are exploring a zone for the first time by taking away their hard-earned key if they can't find the right door in time.


Are there any better solutions to this problem? I'm pretty strongly opposed to Solution 1 (unless someone can convince me it's a great idea). I suppose Solutions 2 and 3 (or a combination thereof) could work in a pinch, but I'd like to think that there's some more elegant approach that I haven't thought of yet.

Any ideas?
Back to top
View user's profile Send private message
Author Message
Alayla



Joined: 11 May 2005
Posts: 88
Location: Prague

PostPosted: Sun Apr 30, 2006 11:17 am    Post subject: Reply with quote

Odd. I've never run into this problem on any mud I've played. They way I've most often seen it handled clones a new key in the dungeon every reset or puts it on a mob that respawns. Since this produces unlimited keys, sometimes the key has either a timer after which it self-destructs (similar problems to your teleporting solution, but at least the player can go and get another one) or it has limited number of uses (I'm not terribly fond of this, since it encourages camping for "backup" keys). Personally, I don't see having unlimited keys as a problem.

Or am I misinterpreting the question?
Back to top
View user's profile Send private message Visit poster's website
Author Message
Sandi



Joined: 13 May 2005
Posts: 94
Location: Boston

PostPosted: Sun Apr 30, 2006 3:50 pm    Post subject: Reply with quote

I'm not sure where it started, but MERC (and hence, ROM, etc.) has global resets that only allow a specific number of the object to be in the game at one time. Thus, if that is set to 1, the key won't repop as long as a player is carrying it. So, one answer is simply increase the number of keys allowed. You can also put timers on keys - in my game, leprechauns steal them. Depends on your theme, I guess. Wink
Back to top
View user's profile Send private message Visit poster's website
Author Message
Grabnar



Joined: 30 Apr 2006
Posts: 15

PostPosted: Sun Apr 30, 2006 11:43 pm    Post subject: Reply with quote

Alayla: No you didn't misinterpret the question. Key hoarding is mainly a problem on muds with a "competitive" spirit; e.g. if there are two players or groups of players competing for the same prize in the zone, the one that gets the key first might typically hold on to the key either to sabotage the other's progress or to stall for time (if they are waiting for reinforcements to show up).

What you guys came up with is pretty much the best solution I've come up with so far, too. Have the key respawn on a timed interval and then have a leprechaun/time vortex/magical vegetable pop up and eat the duplicate keys after a while to prevent an overflow of junk items. It's a decent solution, I suppose. I was just wondering if anyone else on these boards had a different solution.
Back to top
View user's profile Send private message
Author Message
shasarak



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Tue May 02, 2006 10:14 am    Post subject: Reply with quote

Have a new key generated at each reboot. At that point, set a unique identifying code on both key and lock. Keys generated at previous resets will have an older code that no longer matches the code of the lock, so they will no longer open the door: any one key actually works only until a new one is created, and then becomes useless.

Obviously you do have to be a little bit careful with this: you don't want a key to stop working too early and leave the player trapped behind a locked door that a key he is carrying opened successfully on the way in.

This easy enough to justify in "realism" terms: you just say the NPCs have had their locks changed since the player last "visited". If that's still not good enough, make it a combination lock with a combination that changes every day, and eliminate keys altogether.
Back to top
View user's profile Send private message
Author Message
Vopisk



Joined: 22 Aug 2005
Posts: 99
Location: Golden Valley, Arizona, USA

PostPosted: Wed May 03, 2006 1:41 am    Post subject: Reply with quote

shasarak wrote:
Have a new key generated at each reboot. At that point, set a unique identifying code on both key and lock. Keys generated at previous resets will have an older code that no longer matches the code of the lock, so they will no longer open the door: any one key actually works only until a new one is created, and then becomes useless.

Obviously you do have to be a little bit careful with this: you don't want a key to stop working too early and leave the player trapped behind a locked door that a key he is carrying opened successfully on the way in.


Only create new keys when the area/zone is empty and you won't have any problems. I would still suggest a decay time on keys, since even though it may no longer open the lock, are your players really going to want five million keys in their inventory that have no corresponding locks, and do you want all the garabage littering the place? The answer to both questions is no, and the most obvious solution is that players will junk/sacrifice/disgard of useless keys, however, what if they don't? I can imagine the database just growing and growing as players horde up keys in their inventory as they're too lazy to junk them so that they and their ID numbers can be recycled back into the system...
Back to top
View user's profile Send private message AIM Address MSN Messenger
Author Message
Nornagest



Joined: 08 Jan 2006
Posts: 12
Location: California

PostPosted: Wed May 03, 2006 4:49 am    Post subject: Reply with quote

Vopisk wrote:
Only create new keys when the area/zone is empty and you won't have any problems.


Defining "empty" usefully can be very difficult, depending on the code. My former MUD attempted to do something similar, but I still had to teleport a few players out of rooms they'd inadvertently locked themselves into. Easy enough to reproduce: you could just rent an inn room, log out in it, then log back in a week later after your money had run out, the rental expired, and the locks been changed.

You could store a list of players that had logged out in the lockable area (although this'd have to be kept somewhere persistent, which would have to be written reasonably cleverly to avoid efficiency issues on big MUDs), but this has other problems. How long do you freeze the key information? If it's too short a time, the same problem will occur, albeit at a reduced rate; if too long, some lockable areas will essentially have static keys (or, worse, no keys), making the whole exercise pointless.

Alternately, you could just decree that all such areas must be capable of being left by keyless players, just not entered. Works fine for inn rooms, assuming you have the code for it, but I'm pretty sure there are situations where it'd still be awkward.

One solution might be to have expired keys work once from inside the area, then break in the lock (or otherwise become useless) on the way out. A bit contrived from a thematic perspective, and you'd still need some way to distinguish between the sides of the lock, but it does have the advantage of being essentially foolproof.
Back to top
View user's profile Send private message
Author Message
Vopisk



Joined: 22 Aug 2005
Posts: 99
Location: Golden Valley, Arizona, USA

PostPosted: Wed May 03, 2006 11:23 am    Post subject: Reply with quote

Nornagest wrote:
Vopisk wrote:
Only create new keys when the area/zone is empty and you won't have any problems.


Defining "empty" usefully can be very difficult, depending on the code. My former MUD attempted to do something similar, but I still had to teleport a few players out of rooms they'd inadvertently locked themselves into. Easy enough to reproduce: you could just rent an inn room, log out in it, then log back in a week later after your money had run out, the rental expired, and the locks been changed.

You could store a list of players that had logged out in the lockable area (although this'd have to be kept somewhere persistent, which would have to be written reasonably cleverly to avoid efficiency issues on big MUDs), but this has other problems. How long do you freeze the key information? If it's too short a time, the same problem will occur, albeit at a reduced rate; if too long, some lockable areas will essentially have static keys (or, worse, no keys), making the whole exercise pointless.

Alternately, you could just decree that all such areas must be capable of being left by keyless players, just not entered. Works fine for inn rooms, assuming you have the code for it, but I'm pretty sure there are situations where it'd still be awkward.

One solution might be to have expired keys work once from inside the area, then break in the lock (or otherwise become useless) on the way out. A bit contrived from a thematic perspective, and you'd still need some way to distinguish between the sides of the lock, but it does have the advantage of being essentially foolproof.


I see your point and really just want to make a quick note about your last paragraph there... What if the keys only work twice and then snap off in the lock, chip a tooth, whatever... Of course, these kinds of doors would probably need to lock behind the player as they entered, to assure that players couldn't go in once, run out while the door was still open and have a come back one time for free card stashed in their inventory, otherwise the same problem with hording will continue...

My two cents, something to chew on,

Vopisk
Back to top
View user's profile Send private message AIM Address MSN Messenger
Author Message
Nornagest



Joined: 08 Jan 2006
Posts: 12
Location: California

PostPosted: Wed May 03, 2006 7:37 pm    Post subject: Reply with quote

Vopisk wrote:

I see your point and really just want to make a quick note about your last paragraph there... What if the keys only work twice and then snap off in the lock, chip a tooth, whatever... Of course, these kinds of doors would probably need to lock behind the player as they entered, to assure that players couldn't go in once, run out while the door was still open and have a come back one time for free card stashed in their inventory, otherwise the same problem with hording will continue...


I think that'd work great for situations where you're using keys to restrict quest areas, or anywhere else where you only need the area to be entered once. It'd work less well for situations like inn rooms, where you want players with keys to keep their entry privileges for some fixed period of time.

It'd also be tricky to allow other players to accompany the guy with the key, which I can see being an issue on MUDs where group questing is encouraged, but I don't think that problem is intractable. You could, for example, have the door close when the local room is empty rather than immediately after it's entered.
Back to top
View user's profile Send private message
Author Message
Vopisk



Joined: 22 Aug 2005
Posts: 99
Location: Golden Valley, Arizona, USA

PostPosted: Wed May 03, 2006 11:31 pm    Post subject: Reply with quote

I think an elegant enough solution for the "inn-room problem" would simply be to move any character who logged out in an "inn-room" to reload back in the main room of the inn or some such. Since it would be feasible that after they woke up, they came downstairs to get a bite to eat, or hear the latest gossip for their next big adventure or whathaveyou.

The idea of making the local room be empty before locking the door would cause the problem of groups of players or players themselves making sure that the local room did NOT become empty. thus keeping the door open and returning us to our original problem.

However, it shouldn't be too hard to always add an "is being followed" flag to the player first entering the quest zone and waiting until those following him are all in the same room and then giving a spooky message about how the entrance collapses, slams shut, whatever behind them.

My two cents,

Vopisk
Back to top
View user's profile Send private message AIM Address MSN Messenger
Author Message
eiz



Joined: 11 May 2005
Posts: 152
Location: Florida

PostPosted: Thu May 04, 2006 2:05 am    Post subject: Re: Key hoarding problem Reply with quote

Grabnar wrote:
I've recently been thinking about solutions to the problem of "key hoarding", which unfortunately tends to occur on a lot of MUDs.

Let's say there's a door in a dungeon, and the only way to open said door is by unlocking it with a key found in the same dungeon (the lock cannot be picked or smashed open). Everything is going fine until someone gets the key and instead of unlocking the door, they decide to hold on to the key indefinitely (either to sabotage other players or because the don't know any better), thus making further progress impossible. Annoying.

How can it be fixed? Some possible solutions are:

1 - Make key hoarding illegal: Punish players who are caught doing it.
Problems: Requires some degree of player monitoring. Hard to enforce (How do you prove someone was hoarding a key?)

2 - Do nothing: Allow key hoarding as an acceptable play-tactic.
Problems: Not really a solution. Can work in some games if PK and looting are possible.

3 - Teleporting key: After a certain amount of time, the key is teleported to a random location nearby.
Problem: Not particularly elegant or "realistic". Potentially punishes players who are exploring a zone for the first time by taking away their hard-earned key if they can't find the right door in time.


Are there any better solutions to this problem? I'm pretty strongly opposed to Solution 1 (unless someone can convince me it's a great idea). I suppose Solutions 2 and 3 (or a combination thereof) could work in a pinch, but I'd like to think that there's some more elegant approach that I haven't thought of yet.

Any ideas?


4 - If you hoard keys, Ivan the Red comes and beats your ass down. May not work if your theme is not ninja related.

5 - Don't make quests with one magic, unbreakable, unpickable locked door that Require This Key To Proceed. Perhaps I'm alone in thinking this, but dungeons do not have to be DOOM maps.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Virago



Joined: 06 Jan 2006
Posts: 12
Location: Just south of Nashville

PostPosted: Thu May 04, 2006 3:05 am    Post subject: Reply with quote

Vopisk wrote:
I think an elegant enough solution for the "inn-room problem" would simply be to move any character who logged out in an "inn-room" to reload back in the main room of the inn or some such. Since it would be feasible that after they woke up, they came downstairs to get a bite to eat, or hear the latest gossip for their next big adventure or whathaveyou.


Only problem with automovement-upon-login is that if, say, inn rooms can be used as storage (via a stasis container, special code, a persistent world, what-have-you), they might potentially lose items this way. I suppose everything not set to belong to the room (i.e. things that aren't the furniture and chamber pot) could be loaded into their inventory, but this might potentially overload the character, go over their item limit, whatever. This could also become problematic if a room was shared between two or more characters.
Back to top
View user's profile Send private message
Author Message
Vopisk



Joined: 22 Aug 2005
Posts: 99
Location: Golden Valley, Arizona, USA

PostPosted: Thu May 04, 2006 3:19 am    Post subject: Reply with quote

Virago wrote:
Vopisk wrote:
I think an elegant enough solution for the "inn-room problem" would simply be to move any character who logged out in an "inn-room" to reload back in the main room of the inn or some such. Since it would be feasible that after they woke up, they came downstairs to get a bite to eat, or hear the latest gossip for their next big adventure or whathaveyou.


Only problem with automovement-upon-login is that if, say, inn rooms can be used as storage (via a stasis container, special code, a persistent world, what-have-you), they might potentially lose items this way. I suppose everything not set to belong to the room (i.e. things that aren't the furniture and chamber pot) could be loaded into their inventory, but this might potentially overload the character, go over their item limit, whatever. This could also become problematic if a room was shared between two or more characters.


Well, if we have a problem with inn-rooms, in that, we don't want players to have recurring access to them (and subsequently, no keys after their time at the inn has expired) I don't see a manner in which inn rooms would be suitable as persistent storage locations anyway. However, once could always take the route of "renting a room" for X given amount of time, if they log in and that time has expired, they are moved to the main room of the inn, if they still have time, they wake up, stretch their arms out wide and have free-will with what to do next...

Edit: Also, if they do run out of time, perhaps the Innkeeper could collect up their belongings and store them in a chest in the backroom or something so that players can collect them upon returning and not be rather bent out of shape...
Back to top
View user's profile Send private message AIM Address MSN Messenger
Author Message
Grabnar



Joined: 30 Apr 2006
Posts: 15

PostPosted: Sat May 06, 2006 2:58 am    Post subject: Re: Key hoarding problem Reply with quote

eiz wrote:

5 - Don't make quests with one magic, unbreakable, unpickable locked door that Require This Key To Proceed. Perhaps I'm alone in thinking this, but dungeons do not have to be DOOM maps.


That's the idea, though. Force the players to interact with the zone by having to search for a specific item (a key, in this case) in order to progress further into the zone. Yeah, I could just have the players type "pick lock" or "cast unlock door" or "smash door" as soon as they encountered a locked door, but that's a different game design altogether.
Back to top
View user's profile Send private message
Author Message
eiz



Joined: 11 May 2005
Posts: 152
Location: Florida

PostPosted: Sun May 07, 2006 12:54 am    Post subject: Re: Key hoarding problem Reply with quote

Grabnar wrote:
eiz wrote:

5 - Don't make quests with one magic, unbreakable, unpickable locked door that Require This Key To Proceed. Perhaps I'm alone in thinking this, but dungeons do not have to be DOOM maps.


That's the idea, though. Force the players to interact with the zone by having to search for a specific item (a key, in this case) in order to progress further into the zone. Yeah, I could just have the players type "pick lock" or "cast unlock door" or "smash door" as soon as they encountered a locked door, but that's a different game design altogether.


There are plenty of things other than magic locked doors that require the user to explore - puzzles, magic secret doors, doors operated by gigantic cranes, doors that are only open at 3AM on Tuesday, you get the idea...

Something which has always annoyed me about RPGs is that all of the character's might can be negated instantaneously by a rotting wooden door with a rusty padlock, just because the designer wanted to force me to run around his "awesome" area looking for a key.

If you really want to prevent players' behavior from interfering, well, instancing is all the rage these days. It turns out that many people don't actually like the "interaction" experience provided by waiting around for your stuff to respawn because some other jerk just went on a killing spree, so it might not even be all that big of a loss. This is a much more general solution than respawning keys - each PC or group can have their own copy of quest items/mobs, damage the environment as much as they want, and so on.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Design All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign