Please check out Xaos !

Member Discussions

terms



[Previous] [Next] [Post] [Reply] [Topics] [Summary] [Search]


Pages: 1 | 2 | 3 | 4 | 5 | 6 | 7

151. RE: 3 Guidelines To Staffing Thu Aug 27, 2009 [3:37 AM]
KaVir
Email not supplied
member since: Aug 19, 1999
In Reply To
Reply
> You brought up backups, and you're the only one who said
> anything about them at all

[snip]

> Don't believe me? Read the thread again and find one place
> I ever said backups were unnecessary

The entire crux of this argument is whether or not staff are necessary. I've explained repeatedly that the most essential staff role is someone with access to the code and data files, someone who can maintain their own backups independantly from the hosting service. That without them, it is inevitable that the mud will die. You have repeatedly disagreed with me, with comments such as:

mann_jess: "It is inaccurate to say that without off-site backups a mud will die. It has a high chance of running forever without them."

KaVir: "the mud is directly tied to something that will eventually fail"

mann_jess: "May. Not will."


And that's without getting into the various "gems of wisdom" you've been dropping in your posts, such as:

mann_jess: "It would be technically possible to fix all the bugs in a game at some point"

mann_jess: "A robust codebase won't simply crash and fail to recover"

mann_jess: "Professional software will be tested for invalid input, such as half-saved data, 'frozen' threads, and so on, such that even if these things happen, the app can still continue to run."

mann_jess: "Respectable hosts do backups, and this is something you can verify"

mann_jess: "I'm talking about a game which doesn't require updates. Such a game can be maintained by a host alone."

mann_jess: "Typical muds need staff, so it should be expected that a typical mud will die without staff. An atypical mud without such a need may not die."

mann_jess: "It seems foolish not to keep off-site backups, since it can be done automagically, but they still aren't technically necessary"

mann_jess: "we could envision this sort of MUD being hosted somewhere that DMCAs did not apply"

Your views are based on theoretical idealised scenarios. Have you ever actually developed and run a mud in the real world?
God Wars II: http://www.godwars2.org (godwars2.org 3000) Roomless world. Manual combat. Endless possibilities.
MudLab: http://www.mudlab.org


152. RE: 3 Guidelines To Staffing Thu Aug 27, 2009 [4:03 AM]
KaVir
Email not supplied
member since: Aug 19, 1999
In Reply To
Reply
> You're going to want someone to do line-item vetoes of things
> that are flat-out broken or unbalanced in zones that don't
> belong to them personally. The only solutions that come to
> mind (such as a flag system that requires a plebiscite, or a
> cadre of elected supercomrades) are terrifically unwieldy.

Another solution would be to place power restrictions upon each item. Certain muds already do this, for example maximum bonuses based on the level of the item which prevent lower-ranking staff from creating super-gear. Equally, a well-designed system for generating random magical items should already have some sort of in-built way of controlling the power of the items it produces, and the same principle could be applied here.

The downside of this solution is that it can potentially stifle creativity, and will still inevitably be min-maxed. I think it could be workable though.


(Comment added by KaVir on Thu Aug 27 5:24:56 2009)

Just to provide a quick example of what I mean:

In this scenario, the mud is set in a world where magical items possess a form of intelligence, represented by an attribute called "ego". Minor magical items are barely sentient, while the strongest items are powerful enough to overwhelm all but the strongest of wills.

A character's "level" doesn't just represent experience, but also confidence and strength of personality, with high level characters symbolising the imposing high-profile heroes of myth and legend.

Mechanically speaking, every bonus type has its own ego value. Attack and defence each have an ego of 3 per point, damage has an ego of 6 per point, resistance has an ego of 8 per point, and so on. Each character can wear up to 1000 total points of ego per level - if they wear more than that, they are overwhelmed and unable to move or fight. They must remove some of their magic items.

Thus the player who wishes to make a "ring of damage" (which gives +1000 damage) for their zone can do so, but it would have an ego of 6000, meaning that no character below level 6 could effectively wear it (and a level 6 character who wore it would be unable to use any other magical items).
God Wars II: http://www.godwars2.org (godwars2.org 3000) Roomless world. Manual combat. Endless possibilities.
MudLab: http://www.mudlab.org


153. RE: 3 Guidelines To Staffing Thu Aug 27, 2009 [4:52 AM]
shasarak
Email not supplied
member since: Dec 10, 2004
In Reply To
Reply
Cratylus:
It's quite a lot to expect that a random crowd is going to do careful
enough quality control that they'd avoid green-lighting an awesome
zone just because the (now unavailable, let's say) author left in some
insanely unbalanced things.

You're going to want someone to do line-item vetoes of things that
are flat-out broken or unbalanced in zones that don't belong to them
personally. The only solutions that come to mind (such as a flag system
that requires a plebiscite, or a cadre of elected supercomrades) are
terrifically unwieldy.

Some of the ideas I'm airing here are (I hope) interesting enough that they don't necessarily need to be coupled to a strict staff-free policy - if someone wants to make a MUD where each player has his own zone but where the reclassification of such zones as part of the main game is handled by MUD staff appointed in a traditional fashion, I still think that would be quite fun. :-)

Some other thoughts:

If each object, room, mob, etc. within a zone can be described accurately by an automated process, it would be possible for the game to automatically generate complete descriptions of the entire contents of a zone for public perusal. This could be done in a slightly anonymised way - so, for example, you'd be told that there is a weapon somewhere in the zone which does 3d10 damage, but you wouldn't necessarily be told where it is or how to obtain it (so someone who has read the report doesn't have all the surprises taken away). Potentially you could split up the info into different sections that people could read or not as they please, so those who actually want to read all of the room and object descriptions and check them for thematic consistency can, while those who want to experience exploring the zone first hand can simply look for over-powered weapons.

This would, inevitably, either stifle creativity somewhat, or allow loopholes, because, to work, the complete behaviour of any given object has to be discernable by an automated process. So, for example, if you have a weapon which does double damage when hitting an orc, then this has to be implemented in a way that the automated scanning process can pick up - so there has to be a standardised way of tagging a weapon as doing additional damage to specific targets, and builders have to use only that method. That means either you have to restrict people to only implementing pre-defined template forms of behaviour that the scanning process can detect, or you have to accept that sometimes stuff will happen in a zone that won't show up in the audit report.

(As an aside, I would imagine that incorporating a zone into the main game would be quite a long-drawn-out process - something that is discussed at length on website discussion boards before the vote happens).

There are some possible compromises. For example, you could require that all objects within a zone that is connected to the main game have to fall within certain parameters, and provide mechanisms for creating objects that are guaranteed to lie within those parameters, while also providing non-standard building methods for use in isolated zones. Any given player then has a choice: he can choose to build his zone using the standard, restricted, safe mechanisms (which means, subject to audit, his zone stands a good chance of becoming an official game zone) or he can choose to use non-standard building mechanisms which allow him greater flexibility but which also inevitably doom his zone to remaining forever a self-contained world and never acquring "official game area" status. That seems like a reasonable compromise between balance and creative freedom.

(A very crude way of doing this in LPC would be to insist that all "main game" zones only ever directly instantiate approved main-game classes and configure their properties, while isolated zones also allow the creation of custom subclasses. Or, more nicely, you could define any class that either overrides certain superclass methods or invokes any method on a library class other than a defined "safe" list, as being an "unsafe" object.)

Man_jess' notion of a game run as a republic rather than a democracy might have some application, here, too. You could have some people who volunteer to become zone-auditors, and zones are made "official" on the basis of their recommendation - but these people wouldn't necessarily be given any additional technical powers or, even if they are, being a zone-auditor could be a temporary elected position, with any player being able to stand for election, and impeachment procedures for zone auditors who are judged to be doing a lousy job.
Please do not feed the troll.


154. RE: 3 Guidelines To Staffing Thu Aug 27, 2009 [6:26 AM]
shasarak
Email not supplied
member since: Dec 10, 2004
In Reply To
Reply
KaVir:
How would you define 'active players'? Those who choose to vote?
In the context where I originally used that phrase (20% of active players being need to achieve something) I was thinking in terms of "people who actually play the MUD with some degree of regularity". The reason I suggested a 20% figure is that I suspect it would be difficult to get 50% of the entire playerbase to actually care enough to vote on anything. So I'm thinking that if 20% of the playerbase feel strongly enough to vote in favour of something, less than 20% vote against it, and the remainder don't care enough to vote either way, that might be a reasonable criterion for doing something like removing a controversial piece of game content. Obviously one can tweak that as necessary, e.g. maybe you need >20% to vote in favour if >10% vote against.

KaVir:
How would you deal with someone using a proxy to create hundreds of voter alts?
That is certainly an interesting question. Jess also raised the problem of "alts and sockpuppetry". Clearly any institution run along democratic lines needs to take electoral fraud very seriously. You need some system in place that is based on real people rather than on MUD logins. Quite how one could achieve this, I'm not sure.

If the MUD were already well-established and trusted, you could perhaps have a credit-card-based solution, where any player who wanted to vote would submit credit-card details. A nominal payment (£1, perhaps) would be charged to the card, and automatically refunded if successful. Players who didn't want to submit credit card details would be free not to do so, but would consequently not having any voting rights.

This would probably work well in pay-for-play MUDs, and reasonably well on pay-for-perks MUDs.

However, a free, start-up MUD couldn't possibly operate like this, because there would be no reason for the player-base to trust that whoever is responsible for administering the system wouldn't defraud them.

Submitting photocopies of a driver's licence or passport, maybe...?

I welcome suggestions. :-)
Please do not feed the troll.


155. RE: 3 Guidelines To Staffing Fri Aug 28, 2009 [3:06 AM]
KaVir
Email not supplied
member since: Aug 19, 1999
In Reply To
Reply
> In the context where I originally used that phrase (20% of
> active players being need to achieve something) I was
> thinking in terms of "people who actually play the MUD with
> some degree of regularity". The reason I suggested a 20%
> figure is that I suspect it would be difficult to get 50%
> of the entire playerbase to actually care enough to vote
> on anything.

I suspect it could prove difficult even getting 20% of the players to care enough to vote, at least for many issues.

What if it were purely an opposed vote? Eg you need 20% more voters for than you have against. So if 100 people vote against adding my area, I need at least 120 people to vote for adding it.

But that raises another question...is it an ungoing vote, or is there some sort of deadline? Can people keep adding votes, causing my area to be alternately enabled and disabled, or would a new poll need to be started if someone later wanted to remove my area (and if so, could they start the poll immediately after my area was added, or would they need to wait for a while)? And what happens if I want to modify my area after it's been added? Presumably I'd need to submit it for another vote to have the public version updated?

> That is certainly an interesting question. Jess also raised
> the problem of "alts and sockpuppetry". Clearly any
> institution run along democratic lines needs to take
> electoral fraud very seriously. You need some system in
> place that is based on real people rather than on MUD logins.
> Quite how one could achieve this, I'm not sure.

It's the age old problem of multiplaying - and there really isn't any realistic way of preventing it if someone is determined to get around it.

What if the weighing of each vote were somehow based on your in-game progress? Thus the more time and effort you invested in the mud, the more influence you'd have over its content. A player with multiple characters would have multiple votes, but ideally the value of those votes would be comparable with that of a player who had invested the same amount of effort into a single character. Creating voter alts would be possible, but their votes would hold almost no weight.



God Wars II: http://www.godwars2.org (godwars2.org 3000) Roomless world. Manual combat. Endless possibilities.
MudLab: http://www.mudlab.org


156. RE: 3 Guidelines To Staffing Fri Aug 28, 2009 [5:56 AM]
Idealiad
Email not supplied
member since: Jan 16, 2006
In Reply To
Reply
Linking it to character progress doesn't help against alt bots, though. If you link it to the player, though...? Somehow you'd want to motivate players to maintain a single account that had multiple characters in it (if they had alts).


157. RE: 3 Guidelines To Staffing Thu Mar 25, 2010 [10:03 AM]
Magister
Email not supplied
member since: Feb 9, 2010
In Reply To
Reply
Instead of "talking" about it, why don't you just get off your own butt and start "working" on it.

This entire conversation, half of which I stopped reading due to several people, including yourself
jess, who have a VERY biased opinion on what a "staff" member is.

Let's apply this staff situation to the "real world" you're so fond of. Let's say that YOU own a house
and that YOU don't live in said house. In fact, no one lives in the house at all, uses the appliances
inside, or anything at all inside the house. Does this mean that YOU are not considered a "resident"
of that house? No. By the common laws of the "real world", you are considered a resident. As long as
your name is listed on the ownership of the house, you will always be a resident of the house, you
can't change that unless you sell it or give it to someone else. Now, I'm not in any way saying that
the empty, unused house is a PERMANENT residence for you, but it is a residence nonetheless. This same
theory applies to the ownership of the mud. You are a staff if you own the mud, regardless whether you
want to admit to it or not.

Also, there is NO such thing as a program that doesn't have bugs which are capable of crashing it.
This isn't to say that you can't "prevent" it from being crashed by adding in code to catch the
crashing commands, but a mud that cannot crash, does not and will not, ever exist. Another real life
example of this: Take your operating system for example, is it perfect? No. It was made by human
intellect, human hands, and human thought process. It can and will crash if it hangs, freezes, or
performs an invalid function. This is true for ALL programs created by humans, OR AI. Why you might
ask, would a program created by an AI be capable of crashing? The answer is obvious, an AI cannot
create itself, it must be created by an outside source --humans-- and is thus flawed.

And since you have seemingly forgotten exactly what it is you are arguing over, I'll remind you. This
entire discussion is over the topic of a matter we call a "game". A person's "real life" personality
does not dictate that it fully, 100%, transfers over to the "game". Why would anyone play a game, if
they were just going to act like it was real life? We play games to get away from real life, and to
experience something new. The problem with player generated content is that somewhere, somehow, some
player will find a way to make content that is design to give his or her own self, or group, an edge
of the rest of the players. It WILL happen. Here's another "real life" example on this one: Gangs &
their members.
We as humans sometimes tend to forget things like "groups" exist, because we'd prefer that everyone
were equally important. That fact still remains that groups exists, and players will always band
together with like companions in order to form a "territory". In the future, you'd do well to remember
that "real life", does not entirely transfer over into games, because a game is NEVER entirely related
to real life. For a game to be entirely related to real life, it would have to be real life itself,
which therein lies the problem. It can't be done. Simply put, games are not "real life", they are a
"fantasy life" and they will never be the same.

Now, before you begin to argue about whether or not I'm right or wrong here, take the time to think
about what I've said. I did not state me personal opinion on any of the above matters, I stated
factual information. So if you think that you really can prove information based on a set of facts
that many others have already proven to be correct, then by god you go ahead and try. I might have
joined the conversation a bit late, but I am already aware of this and I still felt like I needed to
correct things where they needed to be corrected.

But again I must reiterate, 'Instead of "talking" about it, why don't you just get off your own butt
and start "working" on it. ' Since, it seems like you've done some thinking on the entire concept, why
not go out and DO it instead of arguing about how it would be nice if it was available. With all the
ways that the argument was carrying on, it sounded like a child bickering because he/she wanted
someone ELSE to do something about it and it wasn't getting done.



158. RE: 3 Guidelines To Staffing Fri Mar 26, 2010 [12:14 PM]
Drey
Email not supplied
member since: Mar 19, 2000
In Reply To
Reply
Darn, just a necro-ed thread.


159. RE: 3 Guidelines To Staffing Fri Mar 26, 2010 [12:44 PM]
cratylus
Email not supplied
member since: Feb 1, 2006
In Reply To
Reply

But again I must reiterate, 'Instead of "talking" about it, why don't you just get off your own butt and...


y so srs?

Also, welcome to 2010. Looks like you were in cryosleep since last summer,
hope the thawing went well.

-Crat


160. RE: 3 Guidelines To Staffing Fri Mar 26, 2010 [6:08 PM]
Fishy
Email not supplied
member since: Jan 25, 2004
In Reply To
Reply
God Da#### You ARE a slow reader Magister.... Maybe good'ole gran'pa was right. "Those who can't do, teach."
Throes of Creation (throes.slayn.net)
End of Time (eotmud.com)


161. RE: 3 Guidelines To Staffing Fri Mar 26, 2010 [9:49 PM]
mann_jess
Email not supplied
member since: Dec 10, 2005
In Reply To
Reply
I
stopped reading due to several people, including yourself
jess, who have a VERY biased opinion on what a "staff"
member is.

I can't believe this got dredged up again. Of all the
useless debating I've ever been a part of, this is the most
worthless pile of junk you could have necroed.

Rather than have this resurrected yet again, let me explain;
This quote is exactly why the thread is such garbage. It
devolved very quickly into a debate over the semantics of
"staff" rather than discussing game mechanics, which was my
intention. I allowed KaVir and I to go down that path for
who in the **** knows what reason, and it just turned into
an unsalvageable trainwreck as a result.

To clarify, my position was not ever that a game could be
setup and run wholly autonomously, or that code could be
entirely perfected, or any such idealistic drivel. There is,
however, a type of game administration I would like to see
which centers around player and environmental governance
over celestial bouncers.

And to address your concern, I actually have worked
on it, much more than I care to admit. I developed a
functional proof of concept some time ago, but a series of
personal issues IRL pulled me away from that and another
project I was very much excited about, and I haven't really
had a chance to return.

Regardless, this thread is junk; If you're interested in
discussing staffing guidelines, or interactions between
games and IRL, or whatever... please do it the
justice it deserves by starting a new thread instead of
lumping it with this pile of internet-drama.

Also, hi.

Best of Luck,
-Jess


Pages: 1 | 2 | 3 | 4 | 5 | 6 | 7



[Previous] [Next] [Post] [Reply] [Topics] [Summary] [Search]