Any improvement for movement opportunity system?

Help and Feedback Code Review
1

So i made a movement opportunity movement like fnaf. Is there anything i can improve on? like readability, comments, print statements for debbugging? Thanks for any help! I really appreciate it

--// Services //--
local RS: ReplicatedStorage = game:GetService("ReplicatedStorage")

--// Models //--
local LeftGuy = RS:WaitForChild("Hallucinations").LeftGuy:Clone()
local HallucinationRoot = LeftGuy.HumanoidRootPart
local PointsFolder = workspace.LeftGuyPoints
LeftGuy.Parent = workspace

--// Variables //--
local Lvl = LeftGuy.LVL.Value
local Position = LeftGuy.Position.Value
local Finished = false

local Door = workspace.LeftDoor
local IsOpen = Door:GetAttribute("Open")

Lvl = math.clamp(Lvl, 1, 20)
Position = math.clamp(Position, 0, 8)

local number = 0

--// Main Code //--
print(Lvl, Position)

task.wait(3)

while not Finished do
	number = math.random(1, 10) --to decide whether to move forward or not
	print("Random Number:", number)
	
	if number <= Lvl then
		Position = Position + 1
		print("Lvl:", Lvl, "Position:", Position)

		HallucinationRoot.CFrame = PointsFolder:FindFirstChild("Point "..Position).CFrame
		
		local IsOpen = Door:GetAttribute("Open")
		if Position == 7 and not IsOpen then
			print("Left Guy Failed!")
			Position = 3
		elseif Position == 8 and IsOpen then
			print("Left Guy Finished!")
			Finished = true
		end
	end

	task.wait(5)  -- Wait for a second before repeating
end
2

It really comes down to preference! This one isn’t bad, if you like it, it works. I personally use this: Roblox Lua Style guide and many others do too

1 Like
3

As the above post mentions, it all comes down to preference. However, since you are asking for suggestions I will go ahead and say that I steer clear of any abbreviations in my names if I can help it because it can cause confusion. RS might make sense to you when you first write the code as a logical abbreviation of ReplicatedStorage, but a month from now you may look at some snippet of this script with RS in it and wonder what the heck that variable even is. You would have to navigate to where you defined it to figure that out and thus it’s really bad for readability. Now, if you are the type of programmer that makes these sorts of abbreviations a habit then it will probably make sense a month from now and so you may not need to worry about it, however, you can’t necessarily say the same about other developers you may work with.

Ideally, you should get into the habit of writing code that doesn’t just make sense to you, but would make sense to another developer that is reading your code. That means descriptive names for your functions, variables, etc. as well as plenty of comments throughout your code. Even if you are the only scripter for your projects now, if you move on to bigger and better projects you will probably find yourself with another scripter or two. Descriptive names go a long way towards readability.

As for comments, this one is a bit trickier because it will vary depending on the code and you can easily forget about it when you’re in the zone so it’s a harder habit to form (at least in my experience). I think the best thing to start with is adding comments above each of your functions that A) describes the parameters the function takes (if applicable) B) describes what the function returns (if applicable) and C) summarizes what the function does. Sometimes any or all of these can be pretty trivial and make you question whether you even need to add a comment but I think it’s good to do it anyway to form the habit.

The second thing you want to focus on is complexity in your code. You may find that once you’ve worked out some code it just clicks for you and you don’t bother adding any comments because it… just makes sense now. I mean, why comment when you understand what it does? The problem is, it won’t always stay clicked and after a month you may find yourself having to work your way through the same mental hoops you’ve already been through to figure out where you were going with some piece of code, likely in the search for some bug. I found it really useful to stop and retrace my steps after finishing a function to take note of what mental leaps I had to make and add a comment to my future self in case I forgot where I was going with some code. Heck, often times I just separate my code into smaller logical chunks and provide little summaries for each small chunk.

For example, you could think of this as a smaller chunk:

local IsOpen = Door:GetAttribute("Open")
if Position == 7 and not IsOpen then
	print("Left Guy Failed!")
	Position = 3
elseif Position == 8 and IsOpen then
	print("Left Guy Finished!")
	Finished = true
end

and comment it like so:

--Check to see if Left Guy fails or finishes
local IsOpen = Door:GetAttribute("Open")
if Position == 7 and not IsOpen then
	print("Left Guy Failed!")
	Position = 3
elseif Position == 8 and IsOpen then
	print("Left Guy Finished!")
	Finished = true
end

These sorts of comments help you glance at code to understand what it does without having to read through the code and follow all the logic.

1 Like
4

Thanks for the tips ive only been coding for over half a year now so im not really that knowledgable with these things ill definitely keep them in mind if you have any more tips like tips on optimization and stuff ill be happy to receive them thanks for the advises!