game.Players vs. game:GetService("Players")

I typically use game.Players, but literally everyone else seems to use game:GetService(“Players”). It seems like the latter is simply using more characters to do the same thing. Could someone please explain the difference between the two?

Thanks,
kiloe2

3 Likes

The only difference you can see is when you change the name of a service. game.Players will error, and game:GetService("Players") will return the Players service, regardless of its name. Exploiters can change the name of the services and break your scripts, so it’s best you use game:GetService()

9 Likes

This is from the developer wiki.

Returns a service with the class name requested. When called with the name of a service (such as Debris ) it will return the instance of that service. If the service does not yet exist it will be created and the new service is returned. This is the only way to create some services, and can also be used for services that have unusual names, e.g. RunService’s name is “Run Service”.

1 Like

A little off-topic but wouldnt exploiters still be able to use GetService() to bypass the exact same thing? Essentially rendering the part where you change your service’s names to different things useless?

This is smart, and a good idea. However…

Aw, darn. @3rdhoan123 beat me to it.

Couldn’t the exploiters also use game:GetService()?

1 Like

Yes, they can also use game:GetService().

1 Like

Use ServiceProvider:GetService for all services, not just Players. You don’t use it because of exploiters, but because it is the canonical way to get services. If you release some open source code and a user uses it and for some reason renames their services, the code would still work because of :GetService’s nature.

7 Likes

Yes but won’t work against exploiters that make sure to update their scripts. Plus, simply changing the name of any objects to random strings, even remotes, I deem to find useless in the end. Why?

Objects can simply be easily tagged and be referenced later on, making it useless to randomize names.

The best way to secure your game is to protect everything and do as little as you can on the client and more on the server. If statements are your savior :eyes:

Renaming services is bad practice. And plus since it’s good practice to use :GetService they’re more likely to use it. Security through obscurity != security :confused:

2 Likes

Had no clue exploiters messed with service names. I normally use game:GetService() only when I require a service not already visible in the Studio Explorer menu. Read somewhere that you wont get an error if it’s visible in the explorer years ago. Might need to change that behavior now…

Wouldn’t the script kiddies get their scripts from someone who knows to use game:GetService()? I am not trying to be argumentative, I apologize if it sounds like it.

Although Its advised to use getservice, I often test my games with game.Servicename since I can reference objects easier since for some reason, roblox doesn’t support it when you do game:GetService() which honestly makes no sense to me :thinking:

Example:

local Players = game.Players
local Character = Players. (I can see the options inside players, bad example but you kinda get the point when typing in lua)
local Players = game:GetService("Players")
local Character = Players. (Cant see it at all ;.;)

Of course though, I just ctrl H and change everything back to game:GetService() after I finish.

3 Likes

I don’t have this issue, just tested. Might need to update something?

1 Like

Really? Odd, Its been an issue ever since I started :thinking:

1 Like

GetService is canonical

Some services aren’t loaded by default, so GetService loads them when they don’t exist. (doesn’t happen with indexing like game.Players) Some services aren’t named after their ClassName, so something like game.RunService or game.UserInputService won’t work. Obviously you shouldn’t re name services, but you probably shouldn’t rely on services having a specific name.

3 Likes