Performance can be a big issue in gaming. Lag and long loads can interrupt play and possibly dissuade players from playing again. ROBLOX is constantly working to improve game performance on its end, but there are things developers can do to improve how their games run.
Knowing where to focus your efforts when working on performance is very important. Your game may have a very inefficient piece of code, but if it is not run often or at critical times, fixing it will likely not improve the game experience and uses time that could have been spent fixing more important issues. ROBLOX offers several tools to monitor the status of your game to help determine where optimization might be useful.
One of the first steps to see where problems may lie is to use Studio's Script Performance window. This window shows all of the scripts that are running in your game and how much processing power each script is using. In general, if a script's activity is over 3%, it is probably worth checking to see if you can optimize it. The Script Performance window also helps let you know if changes you have made have indeed increased performance (or possibly decreased!).
See Script Performance for more.
Another view that can help determine if your game is slowing down in certain areas are the Diagnostics windows. These windows can be brought up in Studio and even when you are running a game. The diagnostics windows provide a lot of information, much of which you will likely never need to be concerned about. There are a few however that can help identify that there may be problems. Note that these windows will not identify where problems are, but can show you that you need to search for the cause of certain slow behavoir:
A large contributer to poor performance can come from how a game is scripted. Not all code is written equally, and there are some ways of performing tasks in Lua that are faster and more efficient than others.
In general it is better use local variables than global ones in your code. Making a variable local is very easy, simply include the name local before the variable when you are making it:
x = "test" local y = "test"
In the above example, the variable y is a local variable, the variable x is not. Because of the way Lua works, y will be much quicker to lookup than x when it is used later in the code. Granted, this lookup speed increase isn't much if y is only looked up a couple of times, but if there is a loop that uses it thousands of times, that small increase in efficiency adds up.
Sometimes it is useful for a game to check a condition periodically, or needs to repetitively repeat a function. Putting this code in a loop with a wait() call is the general solution, but one must be careful, especially if the code has expensive calls (such as accessing DataStores). If a script with a wait loop is causing performance problems, check to make sure that if that loop could be run less frequently by increasing the wait. This is explained in depth in this Blog post.
Not all performance improvements are made in scripts. There are some things in places that can contribute to slow gameplay and lag.
Not all ROBLOX players are playing on top of the line machines. Some are using laptops or older desktops. They may also be playing on slower connections. One setting that can help is StreamingEnabled. With this on a client will not load the entire game, but will rather load the game while the player is playing. While content is streamed into the client as the player moves around the world, less important content will be streamed out which lowers the memory the game requires. For example, if a game has a large map, StreamingEnabled will only show the parts of the map that are close to the player, while very far away parts will not render.
Keep in mind that StreamingEnabled does have some limitations and restrictions on scripting. To learn more consult the StreamingEnabled guide.
Large games with a lot of content can provide excellent gameplay experiences. Attention to detail can help with immersion and atmosphere. That said, there is a limit to how much a game can handle. There is no hard set rule on part count but suffice to say the more parts a game has, the slower it will run. This means you may have to be strategic to where you focus the detail and embellishments in your environments. Suppose a game takes place in a futuristic city with ships flying far overhead. If the player can never get close to these, there is not much point in making these ships out of hundreds of parts when perhaps a dozen or even fewer may suffice.
Very large worlds may also benefit from TeleportService. If a fantasy world has a several towns, a castle, a cave, a haunted forest, it is possible to put each of these environments in their own separate place, using teleports to move between them at specific points. This will allow each individual environment to have a higher level of detail with more parts. That said, teleporting does take time and introduces more complexity if persistent information is a concern (in which case Data stores may be useful).
Below are a list of suggestions to making games run faster. Note that these are not hard rules that your whole game has to adhere to, but should be taken advantage of when possible: