What kinds of things hurt game performance?

Help and Feedback Game Design Support
,
1

Im pretty sure i know too many while loops will crash the game (for loops too?) but what else can crash the game/hurt performance? And what are the substitutes i can use to make sure my games run smoothly?

3 Likes
2

This is an important question (that probably belongs in Game Design Support).

Loops themselves aren’t really the issue. It depends on the loop and what is inside of it. If you are doing 100 FindFirstChilds every frame, yes, it’ll cause some slowdown.

I like to reduce loops too, as you suggest, but in order to do this, you need to create a module to handle your loops for you, so they run in a centralized place.

local loopHandler = {}
loopHandler.loops = {}
local loopTimes = {}
local runService = game:GetService("RunService")
function loopHandler.loopCallback(name, time, callback)
loopHandler.loops[name]={callback,time}
end
function loopHandler.removeLoop(loopName)
loopHandler.loops[loopName] = nil
end

runService.Stepped:Connect(function(dt)
for name, loop in loopHandler.loops do
local timeLeft = loopTimes[name] or 0
if time() > timeLeft then
--run loop
loop[1]()
loopTimes[name]=time()+loop[2]
end
end
end)

return loopHandler

Untested, I just wrote this in the DevForum. Can you spot the optimization issues? I think there are two.

Another tip is to put things into variables. Don’t run 100 FindFirstChilds, as I said before. This is very important at times, and has made my games very fast.

But at the same time, don’t write the same code twice. If a module exists for one thing, it should work on another, without using up excess memory or resources. The same code should work for multiple objects in your game, and preferably do them at the same time.

The most important thing, however, is to prevent yourself from adding too many things. These could be objects in code, or objects in the Workspace. Usually these will hurt the server.

The thing that hurts the client the most, in rendering and physics, however, is SmoothTerrain (unless you have meshes that aren’t optimized). Try to use as few of it as possible in your game, or suffer with “Streaming”.

4 Likes
3

Basically anything can kill performance if done the wrong way, but probably the most common unoptimized thing I see people do is leaving scriptConnections connected in an environment where they will constantly duplicate, like this for example:

local part = script.Parent

part.Touched:Connect(function(hit)
    local humanoid = hit.Parent:FindFirstChild("Humanoid")
    if humanoid then
        local player = game.Players:GetPlayerFromCharacter(hit.Parent)
        if player then
            humanoid.WalkSpeed = 32
            
            game.RunService.Heartbeat:Connect(function()
                if (player.Character.HumanoidRootPart.Position - part.Position).Magnitude > 20 then
                    humanoid.WalkSpeed = 16
                end
            end)
        end
    end
end)

Always make sure you disconnect your dynamically created connections!

5 Likes
4

Thank you for your tips, ive always been bad with modules and neglected them, but i can always try them out. Thanks again :slight_smile:

switched to game design support btw

2 Likes
5

Oh shoot i didnt know you could disconnect functions. Thank you :slight_smile:

1 Like
6

Not recycling effects and other commonly cloned instances.
If you’re only spawning something like a laser beam very rarely, it’s generally fine to create and destroy a new instance each time, the performance impact will be minimal. However, in cases where you’re dealing with high frequency effects, such as a fast-firing weapon, or a visual effect involving multiple shockwave meshes or particle bursts, recycling will be important. Instead of destroying the instance when it’s no longer needed, it’s a good idea to reparenting it to nil and store it in a reuse table. When you need a similar instance again, you can pull it from the table, reset any changed properties, and bring it back to where it’s needed. This reduces memory allocation and garbage collection overhead.

4 Likes
7

Thank you for this btw. I definitely need something like this for the current game im working on.

1 Like
8

Hi, where is the disconnect code in the above script example?

Thanks

9

The whole point is that there isn’t one. You can’t really code it in with that infrastructure and the whole codebase in that snippet needs to be restructured in order to properly have just 2 connections.

10

oh… do you have an example of how it or some other code would properly disconnect…

what if players leave the game or die , would it handle that also? are you running it via that code that runs in the background , regardless of if the function ends .. forgot what it was called.. some thing when you kick it off it runs by itself…

Thanks

11

In the code, you would need to put the Heartbeat connection in the global scope, or any scope that is not inside an existing connection. However, it should just be completely remade.

First of all, it should be on the client, not the server. Just one Heartbeat event connection, then, this code:

You really cut down on a lot of that stuff. Unless touching the part before the speed changes to go faster is a game mechanic, you really don’t need the Touched event connection at all.

1 Like