After taking close to a 3 year break from development on ROBLOX and focusing on my career as a web developer I’ve only recently realised how much I miss making games on ROBLOX.
In these 3 years, I have essentially replaced most of my knowledge of Lua I used to have… and a lot has changed since then.
Is there anything in particular that has changed over the last 3 years which are worth re-learning? I’ve gone to jump back into making a game, but have found my motivation to finish what I start is not quite there anymore due to my knowledge being so limited now.
What would you say is worth learning again? Of course I still know the basics, and I’m looking to challenge myself.
If you may realize by searching on the developer hub for a little longer, you can realize that connect is deprecated, you should use Connect instead. (Correct me if I’m wrong) Datastores have also changed a little, you should check it out again if you want to get a refresher.
I’m also pretty sure disconnect:() used to to be a thing, like again, you should captialize the first letter to be: Disconnect:().
I don’t know if from 3 years they used to have this but what you can do instead of doing game:GetService("Workspace") is workspace, its shorter and still does the same exact thing.
Also, if its been 3 years, you can try messing with the the FIB build, play around with it, you can also make negative transparency/reflectance blocks (Player messing with the properties):
Also, If i’m not mistaken, lua is getting an upgrade of somewhat for optimization (Still a work in progress im pretty sure):
Another thing, its pretty recent but, see what you can change/make using this (Epic notepad effects or something ) :
There are many other things to go over which have changed but these are some of them so good luck on your development journey
Getting input has changed, KeyDown is now deprecated and we have a service - UserInputService
This service can be used in LocalScripts to get User input, similar to KeyDown.
This is incredibly useful and in-depth. I have used workspace for as long as I can remember.
I had no idea about parenting with Instance.new or :connect and :disconnect, so that was super helpful!
I read the textbox post earlier, got a little too excited about that one.
FilteringEnabled is now a thing and is enforced (it’s enabled whenever you create games and you can’t disable it). Basically, FilteringEnabled prevents (almost all*) changes from the client replicating to the server, making games easier to secure (as exploiters changing things locally wouldn’t replicate*) and makes the communication style much more oriented to the Client-Server communication you are familiar with as a web dev.
What if the client has to request the server for something/to do something? E.g. How would a player tell the server that he is attempting to buy a weapon which costs 500 coins? You would use RemoteEvents for this. RemoteEvents facilitate communication between the clients and the server. You would use it in the above scenario by firing the remote event to the server stating what item the player wants to buy, and the server would check if the player has enough coins, and if so, reduce the amount of coins they have and give them the item. You can learn more about remote events here.
FilteringEnabled doesn’t automatically make your game exploiter-proof. There could be some security flaws in the way you set up your remote events which exploiters can take advantage of. For example, say you were trying to create a gun where the client tells the server whenever they want to shoot. However, you set it up such that the client has to provide the origin and destination of the bullet and the damage it does. This is a security flaw as exploiters would be able to tell the server how much damage they want to do allowing them to 1 shot players, and where they want the bullet to go to regardless of where they are. To make it secure, you have to make it such that the client only tells the server the direction theyre going to shoot. The server then determines the damage they should deal and the range using the player’s equipped gun’s stats, and where the bullet should go would be determined using ray casting.
*Some physics related mechanics can be changed by the client and it will replicate. This is why it is hard to make an anti-exploit for speed (and some other) exploits. Clients control their characters and it replicates to the server, so an exploiter could easily change their character’s position/humanoid WalkSpeed and have it replicate. Yes, you could check if the player’s velocity is too high, but that could cause false positives for when players are lagging or when they are teleported (by the game). You could listen for when the player’s humanoid WalkSpeed changes but from what I’ve read, exploiters can prevent changes on their humanoid from replicating to the server. There are still ways to minimise exploiting though. There are posts out there that describe how to effectively combat common exploits, and as long as you set up your remote events securely, you should be fine.
) :
