Hello, everyone. I'm gcr. Feel free to mercilessly make fun of me; I'm just a n00b, but perhaps it is this unfamiliarity that affords me to see things from a different perspective.
I see a problem with this game, particularly in the multiplayer part. Perhaps you know what I'm talking about. Griefers. They mess stuff up, flood caverns, construct rude shapes. I just visited a server where someone used automated tools to turn every 5th block into a sponge. Once that happens, there's nothing players can do but manually go and fix everything by hand.
What are our current tools for dealing with griefers? Currently, we exclude people. We build spawn jails to confine them to certain parts of the map. We kick them after they do their dirty work. We constantly police the server, so much that admins are so busy keeping people in line that they can't have fun building things themselves. In fact, we've put so much effort into tuning these weapons of administration that there are custom servers floating around that automate these precise things to a frightening degree. It's all I can do to build enough trust to even be let out of the jail cell, let alone get kicked right when I join a server. As a new player, knowing I'm not wanted is excruciatingly annoying.
I think we're attacking this the wrong way. Griefers aren't the real problem: they're just a symptom. The real problem is that the map is immutable, and once a change happens, there is no undo. Should we compensate for this by kicking people out and letting no one in? Or should we build an undo button?
Here's what I'm proposing: Let's take a cue from revision control systems like SVN and git. Let's build a server that keeps track of everyone who touched a block. Every time I destroy a block, that empty space will have my name on it. Every time I construct a building, every piece of that structure will have my signature in its history.
Why would this be useful? In more ways than one: Perhaps the admin decides he doesn't like what I've done. In a normal server, he would kick me out and try to rebuild what I've broken. However, if our server tracked history, the admin could simply type /revert 5min gcr to undo everything I've done in the past five minutes. All my damage will disappear along with the rude shapes I've made. There would also be benefits for the player. What if I spend all my time making a wonderful skyscraper, the likes of which have never been seen? Obviously, I wouldn't want anyone to mess it up. In our hypothetical server, I would type /lock 2hr. All of the blocks I've made in the past two hours would now be locked, and griefers wouldn't be able to touch them. The Admin could still destroy them of course, but at least my work would be safe from everyone else.
Of course, there are other ways of solving this problem. Why not give new players their own little "plot" of land that they can freely build on and destroy, or allow builders to secure a certain section of the map? This would allow new players to have fun without messing anyone else's work, and it would allow veterans to show off without worrying about vandalism.
You all spend so much time creating these wonderful works of art. Why do you hide them away so that only your trusted circle of friends can even enter the map? Why not show them to the world by building tools that allow you to do so safely and in a controlled manner that lets everyone have fun?
Being a n00b, I don't know how the network protocol works. I don't know how the server keeps track of things, or how much memory would be used. I don't even know if you guys like the idea. But I'd love to try and see what we could do to fix this.
If we can build the tools to mitigate and control damage, we wouldn't have to kick griefers out of the game because when they see that even their best most destructive efforts take only a few keystrokes to fix, there would be no fun left in griefing. Their actions would then be an annoyance, not terrorism.
Are there any open source servers I could hack on? If so, is this even a good idea? What other ideas do you all have?
There is an open-source server project, ( viewtopic.php?id=4437 ) although it is still in its beginning stages. Take note, the game is still in alpha.
What you have suggested has been put forth many, many times. We'd all love to have it, but there hasn't been a feasible solution for this thus far (from what I've seen). For more explanations look around in the suggestions for anything to do with griefing. ( viewforum.php?id=1 )
Hmm. Seems like the current solutions are either "this would be too slow so I'm not going to even try" or "this doesn't exist yet but really should."
I don't think it would take very much ram, would it? How big are the levels? 1024×1024? The blocks are one byte which means that's 1MB to store one revision of the level. Storing everything as history attached to the player (where every change is one byte for the block plus two bytes for the player ID, I don't know if java is this efficient) means that even if they change every single block in the level 10 times, that would be about 30MB.
Firefox right now is hogging up 530MB and pidgin is taking 150MB.
As for speed? I don't think appending something to a list for each chunk update takes all that much effort. Then again, I don't really know how much bandwidth reverting a large change would take...
The server doesn't look too complicated. Thanks for the link, erronjason. I'll look into this when I have some free time.
Server back-ups. There are tons of software floating about that allows you to save back-ups of a map every 5 minutes.
Sure, but he is suggesting a way to undo a certain players actions, not everyones. While backups are important in case of a massive grief attack, it is too impacting om the server as a whole when, say, ten players buildings gets wiped to restore the griefing of one players building.
I think it's feasible this could work. The comment about backup software made me think of this:
The server could keep backups of each player's actions in a file for that player. This would basically be a log, such as
ADD 122,34,167,1 //Added a stone block
DEL 123,34,167,2 //deleted a grass block
but in a more efficient, non-ASCII manner.
That way, the server could just flip the commands and execute them in reverse to undo what the player had done. Once a player disconnects and a given period of time elapses, the server will clean out the log for that player.
As far as ram, as long as you have the server dump the backups to file often enough it shouldn't accumulate too much. 3 integers and 2 bytes (ints for coords, bytes for type and command) make up 14 bytes in Java, say a person changes 200 blocks in a minute that's only 2.8KB per player.
Oh, Notch doesn't want us to? I guess I won't do this then out of respect for him, but it's kinda sad to see the maker of the game refusing to let us help him make it better.
Still, of course he has the right to do that. This isn't exactly an open source game after all.
I see a problem with this game, particularly in the multiplayer part. Perhaps you know what I'm talking about. Griefers. They mess stuff up, flood caverns, construct rude shapes. I just visited a server where someone used automated tools to turn every 5th block into a sponge. Once that happens, there's nothing players can do but manually go and fix everything by hand.
What are our current tools for dealing with griefers? Currently, we exclude people. We build spawn jails to confine them to certain parts of the map. We kick them after they do their dirty work. We constantly police the server, so much that admins are so busy keeping people in line that they can't have fun building things themselves. In fact, we've put so much effort into tuning these weapons of administration that there are custom servers floating around that automate these precise things to a frightening degree. It's all I can do to build enough trust to even be let out of the jail cell, let alone get kicked right when I join a server. As a new player, knowing I'm not wanted is excruciatingly annoying.
I think we're attacking this the wrong way. Griefers aren't the real problem: they're just a symptom. The real problem is that the map is immutable, and once a change happens, there is no undo. Should we compensate for this by kicking people out and letting no one in? Or should we build an undo button?
Here's what I'm proposing: Let's take a cue from revision control systems like SVN and git. Let's build a server that keeps track of everyone who touched a block. Every time I destroy a block, that empty space will have my name on it. Every time I construct a building, every piece of that structure will have my signature in its history.
Why would this be useful? In more ways than one: Perhaps the admin decides he doesn't like what I've done. In a normal server, he would kick me out and try to rebuild what I've broken. However, if our server tracked history, the admin could simply type /revert 5min gcr to undo everything I've done in the past five minutes. All my damage will disappear along with the rude shapes I've made. There would also be benefits for the player. What if I spend all my time making a wonderful skyscraper, the likes of which have never been seen? Obviously, I wouldn't want anyone to mess it up. In our hypothetical server, I would type /lock 2hr. All of the blocks I've made in the past two hours would now be locked, and griefers wouldn't be able to touch them. The Admin could still destroy them of course, but at least my work would be safe from everyone else.
Of course, there are other ways of solving this problem. Why not give new players their own little "plot" of land that they can freely build on and destroy, or allow builders to secure a certain section of the map? This would allow new players to have fun without messing anyone else's work, and it would allow veterans to show off without worrying about vandalism.
You all spend so much time creating these wonderful works of art. Why do you hide them away so that only your trusted circle of friends can even enter the map? Why not show them to the world by building tools that allow you to do so safely and in a controlled manner that lets everyone have fun?
Being a n00b, I don't know how the network protocol works. I don't know how the server keeps track of things, or how much memory would be used. I don't even know if you guys like the idea. But I'd love to try and see what we could do to fix this.
If we can build the tools to mitigate and control damage, we wouldn't have to kick griefers out of the game because when they see that even their best most destructive efforts take only a few keystrokes to fix, there would be no fun left in griefing. Their actions would then be an annoyance, not terrorism.
Are there any open source servers I could hack on? If so, is this even a good idea? What other ideas do you all have?
What you have suggested has been put forth many, many times. We'd all love to have it, but there hasn't been a feasible solution for this thus far (from what I've seen). For more explanations look around in the suggestions for anything to do with griefing. ( viewforum.php?id=1 )
But it would take an unearthly amount of ram.
I don't think it would take very much ram, would it? How big are the levels? 1024×1024? The blocks are one byte which means that's 1MB to store one revision of the level. Storing everything as history attached to the player (where every change is one byte for the block plus two bytes for the player ID, I don't know if java is this efficient) means that even if they change every single block in the level 10 times, that would be about 30MB.
Firefox right now is hogging up 530MB and pidgin is taking 150MB.
As for speed? I don't think appending something to a list for each chunk update takes all that much effort. Then again, I don't really know how much bandwidth reverting a large change would take...
The server doesn't look too complicated. Thanks for the link, erronjason. I'll look into this when I have some free time.
Sure, but he is suggesting a way to undo a certain players actions, not everyones. While backups are important in case of a massive grief attack, it is too impacting om the server as a whole when, say, ten players buildings gets wiped to restore the griefing of one players building.
The server could keep backups of each player's actions in a file for that player. This would basically be a log, such as
but in a more efficient, non-ASCII manner.
That way, the server could just flip the commands and execute them in reverse to undo what the player had done. Once a player disconnects and a given period of time elapses, the server will clean out the log for that player.
As far as ram, as long as you have the server dump the backups to file often enough it shouldn't accumulate too much. 3 integers and 2 bytes (ints for coords, bytes for type and command) make up 14 bytes in Java, say a person changes 200 blocks in a minute that's only 2.8KB per player.
[bookshelf] [bookshelf] [bookshelf] [bookshelf] [bookshelf] [bookshelf] [bookshelf] [bookshelf] [bookshelf] [bookshelf] [bookshelf] [bookshelf] [bookshelf] [bookshelf]
Still, of course he has the right to do that. This isn't exactly an open source game after all.