DELETE THIS POST NOW THANK YOU
Yep
6 Likes
This isn’t entirely from myself, but what I heard from other top developers. As you may have already known, all physical objects are broken into triangles or poly’s. The more triangles there are (such as 10k and above), is when the lag starts to begin. Not only that, but things such as unions can cause even more lag. Roblox has a mediocre way of calculating collisions with unions. So if you are gonna use unions, keep them can-collide off, so the user doesn’t have to calculate collisions with it.
Tl;dr, more triangles/parts/unions = more lag
3 Likes
There are many factors that can cause less than optimal experiences. The biggest “trio” I’ve found that really sucks the life out of a game are:
- Physics
- Expensive script calculations that are run frequently
- Memory leaks
Physics is one of the largest resource hog in a game and the more parts you have anchored, the better. The smaller they are, also the better. Parts with transparency 0 or 1 are the best, anything in between is more expensive. If you rely on physics for gameplay, its fine to leave some unanchored and let the server handle its ownership. If physics is only used for effects, I recommend using localscripts to locally create the parts so the physics are calculated smoothly and it will free up server resources for other things. Players can have noticeable performance impact if they collide with each other (if you have a lot of players that is), so unless collisions are a big factor, I would consider putting them into their own collision groups. Anything that is subjected to being moved, either through physics or code, will always have performance overhead.
Expensive script calculations. This is something that a lot of novice scripters suffer from. A good post that I like sending to people is Erik Cassel’s old post about using wait. It may not have aged as nicely, but his points are still very valid to this day. Consider breaking up logic that uses a lot of loops to certain intervals. The less calculations you do, the better. But sometimes it is unavoidable, so you will need to prioritize what is more important in your game.
Memory leaks. Destroy and remove anything you no longer need. This includes connection lines, useless effects that was played 3 minutes ago which only lasted 2 seconds, etc.
Unless you have a few hundred script objects, they don’t really cause lag. What actually causes the misconception of “more scripts = bad” is actually the programming logic behind them. 100 scripts doing small mundane tasks that runs every second or so won’t come near the lag of 1 script that does fancy loop logics and math that executes every heartbeat frame.
Edit: Some additional optimization tips that I can share as well. For parts/objects/lights that don’t need shadows, make sure the shadow/castshadow property in them is set to false. Light calculations do have a performance impact. If you are a scripter or have a scripter, consider not using Instance.new or Destroy a lot. For example, machine guns that fired a bullet 0.2 seconds ago will tend to be destroyed using the :Destroy function. This is fine when there is 1 player, but it gets real nasty later with more. I would recommend using something like PartCache or a similar pooling method if you are making something equally as spammy.
17 Likes
That’s interesting. I never knew that a part that has a transparency between 0 and 1 is more expensive. Still have much to learn.
3 Likes
In my experience, having a bunch of parts unanchored and free really lags. I made an entire destruction game in which the parts were stacked, not welded or anchored, and that was really laggy.
2 Likes