Request: Expand the ability to moderate our games

Feature Requests Engine Features
#1

NOTE: if you must tl;dr, skip to the big bold words below.

Hey guys, crazy Reinitialized here back with those feature requests again. Some of you may know me for my previous attempts to get some APIs unlocked and what not. However, I feel my past attempts in requesting features were a tad incomplete in proposing the idea (that and I lacked a lot of the knowledge I have now, go figure) and ultimately lead to their downfall. So I’m going to give it another go, expect try to not be a dumbass about it! Let’s see where it takes us! :smiley:

For this thread, I’m going to be focusing on self-moderation of our beloved games! As someone whose played games, and even made a game once (despite the fact I don’t like referring to it anymore … god it’s an ugly mess in there). If there’s a single thing I’ve struggled the most with, it is moderation! My game and many other games I play in daily are swarmed with people who like to abuse. This abuse is an absolute nuisance when it comes down to enjoying a good round of Phantom Forces, throwing a knife around in Mad Games, or someone being a straight up ass in Pokemon BrickBronze. In the poll below, I want you guys to answer a question:

Do you like having an nuisance who you ban, and then rejoins on an alt only to continue to pester you in game?

  • Absolutely! Who doesn’t like having a raging preteen pissing in your cereal?!
  • Nope, cause I’m MLG pro and I want to punch their face off my SERVER!!!
  • ALPHABET SPAGGEHTI!!! (Oh come on, did you take this poll seriously?)

0 voters

Point is, this is the internet, and people will take advantage of the internet to be annoying. And the best part here? As developers, we have created ways to begone of these filthy annoyances! However, we have an issue … ROBLOX doesn’t seem to want to provide us tools to moderate our own games besides the incomplete Player:Kick(string Message) function!. Now, how fair is that? ROBLOX is becoming a go to platform for quickly deploying games on many platforms, and shoooot you can serious cash off here! However, all major MMOs have some form of moderation (and yes, it’s controlled by games staff, what a surprise!), and ROBLOX somewhat has this! Remember the glorious Report Abuse button? Seems it tends to do it’s job here and there (sorry, not trying to point too many fingers here). However, ROBLOX isn’t your traditional MMO. No no, it a User Generated MMO with amazing content ranging from all sorts of brilliant creative young minds barely tapping into the creativity potential they possess. Sooner or later, we’ll move on into another platform (Unity, RealEngine, etc), and a few already have! (Unturned anyone? Great game btw.) Point is, we need better moderation tools! And for the love of god, if this small yet extensive rant doesn’t convince you (yes, you with the rblx_staff role) on why we should have these features, then I don’t understand you.

ALRIGHT! AFTER A LONG TRYING TO BE CONVINCING RANT, HERE’S THE ACTUAL FEATURE REQUESTS:

Sidenote: these requests were all thought about with FilteringEnabled being in mind. I know it’s the go-to security feature, but it’s not a save all. We still have issues, and I believe these few requests can help complement it.

  • Either unlock NetworkReplicator:CloseConnection, or improve Player:Kick() to fully disconnect a Player. Yes, this is still a common issue. Players are able to make themselves nil, and evade being kicked unless we run an ClientScript to try to detect and crash their client for doing so. However, it appears exploits are getting more and more advanced every day, making this a more relevant issue than before. Out of all these features request, if you can do this one, I will at least be content.
  • Provide a way to identify an Client regardless of which account they’re logged into. I’m not suggesting identification by IP, cause I know there’s quite a few unfortunate souls who are forced to share an IP address or computer out there. However, with ROBLOX accounts being simple to create, alternative accounts have become one of the most annoying go tos for abusers. Sure, any method we throw out there can be countered, but you know what? It’s what we IT Security folk strive to tackle. As an IT Security Manager in training, it is my job to consistently maintain and reinforce our security measures at Amazon, and simply throwing my hands in the air when someone counters our new security measures we just implemented two days ago as if it was nothing is an absolute no. Even if it’s a do it once and never look back on ROBLOX’s part (I know, contradicting myself … but I don’t expect ROBLOX to put too many resources into this), if you gave us some form to identify a client regardless of what account they’re on, it would make moderating games a lot easier for all of us.

… I had a few more ideas, but managed to let them slip my mind. I’ll … edit this thread if I remember them. For now, I’m going to bed as I have a busy day trying to go Super Saiyan Blue. Peace for now, fellow developers!

2 Likes
[UPDATED] Dreambox Studios is hiring!
#2

For now: detect with replicators, kick with RemoteEvent:FireClient(plr,string.rep("ein is pro",1e5)).
Of course, having better methods, like :CloseConnection() would be so much better.

#3

It’s what I’ve done for now. However, we shouldn’t have to fully rely on little tricks like this. I’d prefer it if ROBLOX unlocked NetworkReplicator:CloseConnection() verse fixing Player:Kick(string Message), as NetworkReplicator contains NetworkReplicator:GetPlayer() + NetworkReplicator:CloseConnection(), and it isn’t removable like Player.

#4

If someone is annoying other players regularly on your game, using only the mechanics that you provided to players (not exploits), then you should just change those game mechanics? Same goes for alternate accounts doing it, so I don’t see a point in being able to link users together as being the same client.

I think the fact that :Kick() doesn’t fully close a client’s connection is a bug that should be reported (if it’s not already known).

3 Likes
#5

Chat is an effective tool to annoy other users.
Vote-kick systems are used to annoy others too.
Can’t say there is much you can do about those to change them…

#6

Agree and disagree.

To an degree, there’s only so much you can try to fix and throttle before you ruin an experience a part of your fanbase enjoys. Now, this logic doesn’t always apply to every case, and there is definitively some ways you can change some game mechanics to stop this abuse. However, there are some mechanics which changing can only cause your fanbase to die. Good example is Pokemon Go. There should be absolutely no problem with having the ability to look around the map to see where Pokemon are at, but Ninatic decided “it ruins the gameplay experience.” Now? They’re paying the price as Pokemon Go has peaked and is decaying rather quickly.

#7

I don’t see how your example is relevant at all in this context because (1) they manage their own moderation (if there is any), (2) they don’t have an issue with users going between accounts to get around bans, and (3) as you mention that feature wasn’t necessarily a cause for annoyance among users but rather enhancing their gameplay experience. It’s an example of bad insight by restricting a third party feature that was generating lots of gameplay value instead of incorporating it officially. It’s not an example of what you’re suggesting in this context.

IMO vote-kick systems seem to be just “duct tape” fixes for not changing your gameplay mechanics in the way I described before.

Example for chat: you could implement features for users to mute someone in chat, or set the chat to friends-only, or disable chat entirely.

#8

The example was attempting to fix game mechanics for what the company deemed to be a problem. It’s not the best example, no, but it’s an example describing what “fixing” mechanics can do to your game if it’s not a true serious problem (true serious problem being infinite cash glitch, gaining admin permissions, gamebreaking bug, etc). It’s to point out changing game mechanics should not be the only solution to the problem. Instead, we should be presented with multiple options, and better moderation of our games should be an option. It’s our time and effort, and we should be able to do whatever we want with it.

As for the chat features, even if you had those (which you do!), other chat services still provide a way to ban/kick a user from your channel/server. Discord, Skype, and Slack are great examples of such. Even though they have tools to throttle what a typical user can do, moderators can still ban people off the server.

#9

I feel like your example is steering it off-topic. This feature request is about giving you extra moderation capabilities so that you can kick/ban people across accounts so that they can’t switch to an alt and continue annoying people. I’m suggesting that, when you know that something in your game is allowing players to annoy others severely, you should go ahead and patch that up, so that you don’t need this at all. “Changing game mechanics that no one is complaining about can cause issues to your game” is not the topic of the thread, nor “people may be unable to find a good way to fix their game mechanics”.

This is not relevant either because it exhibits the exact same “problems” that ROBLOX does according to your reasoning. If a service is public (i.e. a discord channel) then people will always be able to alt-switch. The only way to prevent alt-switching is to have an invite-only service, which is probably what you’re referring to with the chat channels. But ROBLOX games aren’t invite-only usually, so the comparison doesn’t hold.

#10

The Pokémon Go problem is a design problem. You can’t force players to do X or Y, but you can prevent them from doing A or B if your design supports it. Pokémon Go had poor design and thus issues popped up the developers weren’t aware of. It was ultimately their fault for not noticing and fixing the problems before release. It’s why running a beta is popular nowadays, so developers can see these problems surface on a smaller scale to prevent big chaos.

The reason why Skype, Slack and Discord offer you the power to kick or ban people is because those companies want the user to create their own experience. They want you to be able to decide who you want to chat with. They also know that individuals make mistakes/wrong decisions or walk into problems they didn’t forsee. Sometimes it just turns out that the person who you thought was so nice is actually a big jerk. That’s why they added kicking and banning as a way for those individuals to correct their mistakes. They only have those rights within their own small environment though and those environments are all seperated from each other.

I’m not completely opposed to allowing a developer to ban whoever they want, but when better moderation tools becomes a necessity to your game it’s probably because you made the same mistake as Niantic did with Pokémon Go. With a good design you shouldn’t need powerful moderation tools because you can limit the player’s power as much was you want. Unfortunately we’re not all excellent game developers so I do agree that we could use some improvements, but I can only think of one improvement which I’d like to see: :Kick() should accept an additional argument which determines how long it takes before the player can reconnect to the server or game they were kicked from.

#11

That’s basically banning, which users can bypass by using another account.
Also, :Kick() is useless if users use an exploit that make them have no Player object.

#12

Kind of going up one level here:

I find that manual moderation is always a last resort step when there is no possible other way to avoid an issue. If your game mechanics allow a user to terrorize other users, that should be changed (unless acquiring new users isn’t a goal)

As for chat spam, muting another user is the best way to avoid that. You can of course use analytics here to determine if a specific player is always toxic.

Could someone explain to me the bypasses people can use to not have Kick() work on them? If this hasn’t been done already we need a bug report filed on this in the Bug Reports forum.

#13

Unless it’s fixed, the most obvious one is “doesn’t work on players parented to nil”.

#14

It’s not so much bypasses, as it is a bug on ROBLOX’s part.
Although I really can’t speak for all cases.

What you can do is inject a localscript to nil or the camera and if you’re lucky enough not to be disconnected but be nil instead then the script can and will continue running. As long as you can program custom camera controls you can still move around the map with studio-esque camera control.

The last step in the puzzle is 1 of 2 things:
If filteringEnabled is on then knowing how to communicate to the server might not always be able to protect server side exploitation (unless you ensure the message being received from the client is sent from a client with a Player instance attached.)

If filteringEnabled is not on then it’s just flat out easy to mess everyone’s day up.

#15

Setting Player.Character to nil already enables the studio-esque camera.
(and maybe set CameraType to Fixed or something, I think that’s also needed, but not sure…)

#16

In my experience I have been completely disconnected when doing that.
In safe zones though, not other people’s games of course.

#17

Setting Player.Character should never disconnect you…

#18

Idk what to say that’s just been my experience in the past.

#19

If there are no players in a server, the server will shutdown, as you expect.
Players parented to nil don’t count, so if you test it in an empty server, the server gets shutdown.

#20

I realize that, I tested in this environment and a player filled environment at the time and got the same result.