Creating an Engine that minimises Admin Cheating and Lazines
Mar 17, 2014 18:32:38 GMT -5
lulz and themountaingoat like this
Post by japheth on Mar 17, 2014 18:32:38 GMT -5
Hello everyone,
In case you don't know me, I am Japheth and I am the primary developer on FutureMUD (futuremud.freeforums.org), an in-development MUD Engine. I was an administrator on Shadows of Isildur from around 2006 to 2010, and took over ownership of the game from Traithe in 2008 (handing over to Kite after I left). While I have only played Armageddon the tiniest bit, I have been a long time lurker on these forums and very much enjoy reading about what you guys like about Armageddon, what you don't like, and your ideas for improving it - for my own selfish reasons mostly, to see what of those ideas I can build into my engine.
In my time at Shadows of Isildur I learned a great deal about how rampant Admin cheating is, and how bad it can be for the players and the game. I will admit I was far from a perfect admin or head admin, and I would certainly do things very differently had I my time over again. In the intervening time, I have remained close to the staff and players of several RPI Muds and with the benefit of a little hindsight as well as being outside the MUDDing community largely, I feel I have finally understood the grave impact of bad decisions on behalf of the leadership of a MUD.
Realising that admin cheating is what has driven away probably at least half of the community of all RPI MUDs, and realising that we are a small niche hobby that cannot afford to have such a practice occuring, I have set out with FutureMUD to make it a "Pit of Success", that is to say, that the easiest way to run a MUD with FutureMUD should naturally tend towards the right way to run it.
I believe there are three key "pillars" to get right in terms of having a well-staffed MUD:
1) A "Pit of Success" engine that makes cheating hard and provides modern, professional traceability of action
2) A well designed staff policy that is both realistic, consistent, and well enforced.
3) Only hiring staff of demonstrably good character, and being ruthless in punishing or firing those who step out of line.
Today I'd like to talk to you about element #1 on that list, as it is the one presently under my control as I develop my engine. I greatly respect the opinion of the people on this forum and believe that capturing the feedback presented here is critical to the long-term success of my engine, as while this forum exists mostly to talk about Armageddon, I believe the issues you discuss are almost universal to all MUDs (certainly I have very often seen direct or indirect parallels to other MUDs I have been involved in).
There are a couple of principles I have tried to stick to in building FutureMUD that I believe are specifically related to the Pit of Success / Controlling Admin Cheating topic:
1) Give players as much control over elements of the world as possible, with well designed and balanced systems. This reduces the need for admin involvement in the affairs of players, which reduces the opportunity for cheating or favouritism. Any system that requires admin control or involvement is an opportunity for both corruption and abandonment, and by minimising the number of such systems I can help reduce the impact of bad or lazy admins.
2) Hide as much of the numbers from admins and builders as possible. People are really bad at numbers and statistics. This was one of the worst areas of admin cheating I tended to see on Shadows of Isildur - quality creep.
Maybe a sword started out at 1d6 damage. Then someone came along and said "Well, I want this to be a really good sword, so it can be 1d6+1". Then over time all swords worth having were 1d6+1. Then someone came along and said "Well, I want this to be a really good sword, so it can be 1d6+2", and so on. A suspiciously high number of these were items made for either Admin PCs or "Pet" PCs that were admin favourites.
The consequence of this was that many of the numbers were quite arbitrary, and it led to a very unbalanced game where power kept creeping up over time (and into the hands of a select few). I will try to mitigate this problem by hiding the numbers wherever possible. An admin should not set a sword to do 1d6 damage. They should set the sword to be of "good" quality, and then the engine itself should handle the numbers. Of course, the raw numbers will be editable by the head admins for the category as a whole, but it should be consistent. A good sword is much the same as other good swords.
3) So far as possible all building should require or at least permit a review process. I have generally tended to make anything that builders can edit follow a uniform "Create Submit Review Revise" approach. All prototypes have a revision process, and cannot be used until reviewed. subsequent changes require review once more, and who made what changes, when and why is all tracked. You'll be able to set it up so people cannot review their own work, and that different types of things require different levels of permission to review (maybe some categories of building are higher risk than others). I will also set it up so that changes can be reverted to an earlier state, so there are modern systems of traceability.
4) So far as is reasonable practical, common elements of building should be rolled into templates for the sake of consistency and re-usability. For example, I have a concept with items in my game called item components. Item components are pre-built elements added to an item to make it do things. Adding the "Wear_Pants" component to an item for instance makes it wearable on the body locations that "pants" covers. In a mature FutureMUD, most components will already be built, so builders will generally only be assembling components and writing descriptions.
This split means you can also have different authority and approval levels for components as opposed to items. For instance, perhaps weapon components all require the approval of a single head admin in charge of such things. This helps ensure a more consistent, risk-controlled approach to building that will lead to better outcomes for players.
5) Encourage as much traceability as possible in other elements of the game. For example, I am considering having a formal system for tracking plots and keeping notes, allowing people to codify what they're doing and possible expose it to review. This may include requests to animate PCs that can only be animated within the bounds of a particular approved plot. Of course such things are not for every MUD (particularly small staff MUDs may not need to go to this level of detail), but the option should be there.
---
So with all of that spiel aside, what I am asking for is your best ideas and thoughts on the topic of what the ENGINE ITSELF can do to help reduce the opportunity for admins to be bad. It doesn't have to be a grand idea and it can even be specific to an anecdote that is arm-related, I am sure there is a kernel of an idea in just about any experience you guys have had with this. How can I best shape the FutureMUD engine to produce MUDs that are better experiences for you?
In case you don't know me, I am Japheth and I am the primary developer on FutureMUD (futuremud.freeforums.org), an in-development MUD Engine. I was an administrator on Shadows of Isildur from around 2006 to 2010, and took over ownership of the game from Traithe in 2008 (handing over to Kite after I left). While I have only played Armageddon the tiniest bit, I have been a long time lurker on these forums and very much enjoy reading about what you guys like about Armageddon, what you don't like, and your ideas for improving it - for my own selfish reasons mostly, to see what of those ideas I can build into my engine.
In my time at Shadows of Isildur I learned a great deal about how rampant Admin cheating is, and how bad it can be for the players and the game. I will admit I was far from a perfect admin or head admin, and I would certainly do things very differently had I my time over again. In the intervening time, I have remained close to the staff and players of several RPI Muds and with the benefit of a little hindsight as well as being outside the MUDDing community largely, I feel I have finally understood the grave impact of bad decisions on behalf of the leadership of a MUD.
Realising that admin cheating is what has driven away probably at least half of the community of all RPI MUDs, and realising that we are a small niche hobby that cannot afford to have such a practice occuring, I have set out with FutureMUD to make it a "Pit of Success", that is to say, that the easiest way to run a MUD with FutureMUD should naturally tend towards the right way to run it.
I believe there are three key "pillars" to get right in terms of having a well-staffed MUD:
1) A "Pit of Success" engine that makes cheating hard and provides modern, professional traceability of action
2) A well designed staff policy that is both realistic, consistent, and well enforced.
3) Only hiring staff of demonstrably good character, and being ruthless in punishing or firing those who step out of line.
Today I'd like to talk to you about element #1 on that list, as it is the one presently under my control as I develop my engine. I greatly respect the opinion of the people on this forum and believe that capturing the feedback presented here is critical to the long-term success of my engine, as while this forum exists mostly to talk about Armageddon, I believe the issues you discuss are almost universal to all MUDs (certainly I have very often seen direct or indirect parallels to other MUDs I have been involved in).
There are a couple of principles I have tried to stick to in building FutureMUD that I believe are specifically related to the Pit of Success / Controlling Admin Cheating topic:
1) Give players as much control over elements of the world as possible, with well designed and balanced systems. This reduces the need for admin involvement in the affairs of players, which reduces the opportunity for cheating or favouritism. Any system that requires admin control or involvement is an opportunity for both corruption and abandonment, and by minimising the number of such systems I can help reduce the impact of bad or lazy admins.
2) Hide as much of the numbers from admins and builders as possible. People are really bad at numbers and statistics. This was one of the worst areas of admin cheating I tended to see on Shadows of Isildur - quality creep.
Maybe a sword started out at 1d6 damage. Then someone came along and said "Well, I want this to be a really good sword, so it can be 1d6+1". Then over time all swords worth having were 1d6+1. Then someone came along and said "Well, I want this to be a really good sword, so it can be 1d6+2", and so on. A suspiciously high number of these were items made for either Admin PCs or "Pet" PCs that were admin favourites.
The consequence of this was that many of the numbers were quite arbitrary, and it led to a very unbalanced game where power kept creeping up over time (and into the hands of a select few). I will try to mitigate this problem by hiding the numbers wherever possible. An admin should not set a sword to do 1d6 damage. They should set the sword to be of "good" quality, and then the engine itself should handle the numbers. Of course, the raw numbers will be editable by the head admins for the category as a whole, but it should be consistent. A good sword is much the same as other good swords.
3) So far as possible all building should require or at least permit a review process. I have generally tended to make anything that builders can edit follow a uniform "Create Submit Review Revise" approach. All prototypes have a revision process, and cannot be used until reviewed. subsequent changes require review once more, and who made what changes, when and why is all tracked. You'll be able to set it up so people cannot review their own work, and that different types of things require different levels of permission to review (maybe some categories of building are higher risk than others). I will also set it up so that changes can be reverted to an earlier state, so there are modern systems of traceability.
4) So far as is reasonable practical, common elements of building should be rolled into templates for the sake of consistency and re-usability. For example, I have a concept with items in my game called item components. Item components are pre-built elements added to an item to make it do things. Adding the "Wear_Pants" component to an item for instance makes it wearable on the body locations that "pants" covers. In a mature FutureMUD, most components will already be built, so builders will generally only be assembling components and writing descriptions.
This split means you can also have different authority and approval levels for components as opposed to items. For instance, perhaps weapon components all require the approval of a single head admin in charge of such things. This helps ensure a more consistent, risk-controlled approach to building that will lead to better outcomes for players.
5) Encourage as much traceability as possible in other elements of the game. For example, I am considering having a formal system for tracking plots and keeping notes, allowing people to codify what they're doing and possible expose it to review. This may include requests to animate PCs that can only be animated within the bounds of a particular approved plot. Of course such things are not for every MUD (particularly small staff MUDs may not need to go to this level of detail), but the option should be there.
---
So with all of that spiel aside, what I am asking for is your best ideas and thoughts on the topic of what the ENGINE ITSELF can do to help reduce the opportunity for admins to be bad. It doesn't have to be a grand idea and it can even be specific to an anecdote that is arm-related, I am sure there is a kernel of an idea in just about any experience you guys have had with this. How can I best shape the FutureMUD engine to produce MUDs that are better experiences for you?
