… He paused me there and told me to “Go All Out” although one structure of my heavily-detailed buildings can go up to 5,000 parts alone. Adding that all up to duplicating, it could cause harm to performance but he seemed to not have worry because he trusted the coder on the team that claimed he can use scripts to make the game still run great on plenty of PC’s even if the part count exceeds over 150,000.
It sounds too good to be true but is that possible?
This is my current knowledge, please correct me if I’m wrong.
Scripting does NOT increase performance, and actually it can even decreased performance. The server has to replicate the objects to the player, and that increases the workload. Adding a server script results in an increase of workload. So the more objects you have, the more workload the server has to do.
However, this doesn’t mean you can improve performance. My suggestion for your build is to have some parts be a mesh (like a player can’t interact). You can easily convert 60 parts to 1 part by making it a mesh. This doesn’t work entirely, since it depends on your build.
There have been scripts that automatically reduces the graphics of the game by detecting the FPS of the player. You could also have client render objects close to them.
In conclusion, you can improve the performance of the game using scripts, but you are sacrificing something like the map detail, the surrounding, etc.
This is certainly possible. In fact, you could theoretically do this without making many (if any) sacrifices to detail as well. Here are some things that come to mind:
We can control which instances are rendered and physically simulated by the client. Meaning that even if the client has the instances in memory, they don’t have to be rendered or physically simulating, significantly saving on graphics and physics calculations. If a solution based on this were used, one could avoid making more complex manual server replication systems.
The server’s own memory should not be a major issue for this many parts. Depending on the game, further memory and processing resources could potentially be saved by not physically simulating the instances on the server (removing them from workspace).
We can create systems that would allow the client to only load instances near them. This could also include loading simplified versions of assets that are further away. I imagine it like an API, where the client interacts with the server and requests parts with a certain range. Could also include requests for multiple sets of instances with levels of depth based on their distance.
These are just initial thoughts. It is entirely possible that whoever you are working with has considered these possibilities and deemed them plausible.
This makes no sense whatsoever. When FPS in Roblox drops beneath the cap, it is a direct result of the client machine running out of computing resources to complete the game’s calculations at the speed necessary to provide the maximum FPS. Raising the cap would make no difference, as the client is, in this hypothetical, already incapable of producing the capped performance.
This is not true either. Removing instances from the client, removing instances from graphics calculations, and removing instances from physics simulation, are all ways that immediately come to mind through which scripting could improve client performance in a game.
While scripts can obviously use a varying degree of server resources and increase the load on a machine, there are a multitude of programming strategies that can be employed to provide net gain to performance (in both processing and memory) through more effective management of the a machine’s resources.
Wouldn’t that reduce the graphics to the client though? I do not completely understand. That defeats the point of the graphics if it can only been seen to the server. (I don’t completely know how to explain this lol)
Most of the solutions that I suggested would involve reducing the graphics to the client in some way, whether it is through render distance or level of depth. Your original comment regarding the FPS limit has nothing to do with graphics, however. Raising the FPS limit would not have any implications for OP’s situation, nor would it have any implications for any given client that fails to process a given game at the current maximum.
None of my suggestions involved graphics only being seen on the server. They involved the server selectively replicating instances as requested by clients. This is as opposed to the default behavior of replicating all of the instances, in this case 150,000 of them, all the time.
Clients would not be able to see all 150,000 at a time, but it is unlikely that they’d ever need to do so anyway. Even less likely that they need to do so in full detail.
I kind of understand and don’t understand your point. What is the point of creating the graphics if the client cannot see all of it? The best thing I would do is make a GUI at the start of the game that asks for high or low detail.
Can’t see all of it at once. How exactly to implement this would depend on the game itself. For example, here are some questions I’d ask myself if I were the developer for this game:
If the player is outside of a building, do they need to see the furniture on the inside?
If a player is far away from a detailed element, do they need to see all of the detail?
How far away can the user usually see? If their view is often obstructed by walls or other barriers, do they need to see what is on the other side?
The answers to questions like these would also answer your question. The client would not see all of it because they would not need to see all of it, and the performance of the game is more important to them.
Creating separate places within your universe solely for the sake of providing different graphics for the user is absurd. It’s ideal to optimize the game per client, not the client per game.
The issue that then is put there is say if two players want to play together but one plays on low graphics and the other on high graphics there will be conflict. There is no need to make two seperate places for something that can be achieved by building a framework to handle what each client is being required to calculate and render.
How so? Many games do this, but just not teleport to different places. If you do not want to do this, you can just make the instances show to the client if they pick high or low graphics.
I am aware of what you said, but I am saying that if you do not want to do it my method, (of teleporting between different places) you can make a gui that asks to pick for high or low instances that show to the client. Which can fix what @xZylter replied with.
What was said here is the ideal approach. Even if a player asks for full detail it would be best to introduce optimization into a game, especially with part counts at 150k or more parts.
Your suggestion of adding/removing details would only work on removing small detail objects in the map because it would not be dynamic which means you would not be able to remove any important items such as chairs or tables in a room that are not visible to the client at a given period of time.
