Hey CloakedYoshi!
Brick Count is Not the End All Be All <
Explanation: When you have an excess of parts, all that happens is it increases the loading time, it doesn’t necessarily decrease player performance. If you follow these conditions you can definitely stretch out the amounts of parts you use in your game:
Conditions:
- Not crowding your parts in the thousands into one area, this’ll overwork the player’s ability to render. Please try your best to space them out accordingly or heck, even turn on streaming enabled if your game is incredibly part concentrated and large enough where this’d be effective.
Here’s an example of triangles overcrowding. The sphere in the center is highly subsurface and is split 10 times to conform to ROBLOX’s 10k triangle limit. You’ll see how poorly your machine will respond to touch or looking in the direction of the ball.
https://www.roblox.com/games/2918221866/Triangle-Density-Render-Demo
- Not using unions to cut down on gross part count, this does the exact opposite of what you think it does.
Exceptions: However if you have an excess of moving parts, then no, that’ll heavily decrease player performance.
Measuring the Competition :
Jailbreak Part Count: 19,000 - 20,000
MadCity Part Count: 25,300 - 25,500
MeepCity Part Count (Mobile Champion): 13,500 - 14,000
Conclusion:
You can stretch out the part count as far as you want, there’s a lots of ways to do so and still keeping it performant. However if you’re doing any type of standard build or commission where you don’t want to implement this amount of effort, the 15k - 30k range is optimal.
“When is Geometry Optimization Overkill”
Geometry optimization overkill would eventually set in when either:
- Your assets are heavily baked in, uninteractable due to obscure hitboxes or are outright nocollide.
- A refrain of any geometry at all causing builds that lack shape nor style.
However
" * The game runs well on all devices currently
- I currently have about 3.6K parts, but I could definitely reach 5-10K parts when finished
- The game in question uses minimal physics and almost all parts are anchored
- I use parts sparingly - I’ve already cut down on unnecessary bricks as best as possible
- I would prefer to not split my game into separate places as teleporting has been very iffy recently"
This description of your game is incredibly light, the biggest of your worries now are definitely how you code your project and memory usage is consumed. If your builds are this accessible and light, your coding is the only genuine cause of performance dips or longer loading times.
Goodluck, hope I helped!