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.