My post is kinda wrong to be honest, and, probably outdated. Robloxâs physics are actually very cheap even with a lot of parts in my experience, especially in âmodern timesâ since I wrote that post. Youâre not going to really be able to write something any faster than Roblox already does, mainly because theyâve invested a lot into making physics cheap, even at large scales, and, they have a big advantage over you on that front.
Moving (a lot of) parts yourself in a cheap way can be done with :BulkMoveTo(). This is the fastest way I know of if you are avoiding recreating your tables over and over each move or something, but, for this kind of thing, you probably donât want to do your own physics, unless you have very simple movements (like moving in a straight line) in which case you can have your table of parts, your table of cframes, and then you can just directly update all of the cframes with whatever modifications you are doing before you call :BulkMoveTo()
The reason games like Super Bomb Survival are so fast despite using a lot of moving parts is really just because a lot of moving parts wonât really cause lag on their own, it really depends on what exactly youâre doing and how youâre doing it.
The microprofiler will be one of your most useful tools for identifying what is causing lag, even things completely unrelated to scripts, or even your own development decisions. For example, the biggest cause right now for lag in [đ Compete đ] Vehicle Simulator - Roblox which I work on are the Texture instances. Itâs not because Textures are inherently slow though, itâs that many of the buildings use layered transparent textures, and, well, this nearly triples and in some places quadruples the triangle count, while making it pretty impossible for Roblox to batch render most things. Thereâs probably other quirks which explain why textures take up such a large portion of the frame time, but, these are the ones I could easily identify.
If you want to avoid lag in your game, you definitely donât want to end up thinking one thing will cause lag, but then it turns out to be something more obscure that you didnât anticipate causing lag (like Textures being used in a very specific way) because that will mean you put a whole lot of effort for no real benefit.
For this reason, I think itâs a good idea to start working on your idea, but just keep in mind how certain things you do could cause lag. Then you can check and see if these things actually do cause lag if youâre worried about them. Often times the simplest and most reasonable things you can do will also cause the least lag, especially when youâre using modern features, and if youâre doing something that takes a lot of effort to prevent lag, then thereâs probably a better way to do it.
Additionally, believe it or not, but, keeping your code clean and following consistent styles is a great way to reduce lag on that front, as well as reducing the amount of places you rewrite identical code, because it will make it easier to understand, easier to spot issues, and in many cases youâll be cutting down on things that could cause lag in certain situations just by staying simple. Even if it doesnât manage to avoid lag, clean code, especially where youâre staying at least a decent bit organized, is going to be way easier to modify and itâs going to be way easier to potentially track down lag through the microprofiler.