Improving Game Performance
Improving Game Performance
In gaming, lag and/or 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 ways you can improve performance as well.
Roblox offers various built-in tools for analyzing game performance, including:
|Performance Stats||The Performance Stats widget, toggled via Ctrl+F7 or Command ⌘+F7, is a basic way to monitor memory, CPU, GPU, and network stats. If you see "spikes" in memory or other graphs, you should investigate them using the tools below.|
|Developer Console||When running a live version of a game, the Developer Console shows diagnostic messages from in-game scripts, categorized memory usage, network stats, and much more. See the
|MicroProfiler||The MicroProfiler is an advanced tool for analyzing and debugging client-side performance. See
Place Setup and Design
The following setup and design tips can make significant improvements in overall game performance.
Not all Roblox players have top-of-the-line machines or fast network connections.
Workspace/StreamingEnabled|StreamingEnabled, a property of Workspace, can improve performance by streaming content into the client as the player moves around the world. At the same time, distant content is streamed out which reduces the memory the game requires.
Workspace/StreamingEnabled|StreamingEnabledunless you understand its implications and have put processes in place to manage them. For example,
LocalScript|LocalScriptsmay need to use
Instance/WaitForChild|Instance:WaitForChild()in order to access distant objects, as those objects may not exist in the game world when referenced.
Very large worlds may benefit from
/articles/Teleporting Between Places|teleportation. For instance, if a fantasy world has several towns, a castle, multiple large dungeons, and a haunted forest, you should make each a separate place and teleport players between them at specific points, like a dungeon’s entrance/exit.
/articles/Intro To Terrain|terrain system offers peak efficiency per unit and automatic level-of-detail. When using terrain, consider these tips:
- Blend different materials for visual variation — they cost the same in terms of performance (except for water).
- Toggle on
Workspace/StreamingEnabled|StreamingEnabledas outlined above.
One light with high brightness is cheaper than many intersecting lights with lower brightness, and it’s more optimal to use non-moving, non-shadow-casting lights. Also, the ShadowMap lighting technology causes all objects to cast shadows by default, so consider Voxel lighting if your game doesn’t require distinct shadows.
Models placed inside certain storage containers are replicated to the player’s local client — even if they don’t exist in the 3D world — meaning they occupy memory even if the player can’t see them. It may help to keep infrequently-used models in
ServerStorage until they need to be placed in the game world.
Level-of-detail for a
/articles/Mesh Parts|mesh or
/articles/3D Modeling with Parts|solid-modeled part defines how detailed it appears in proximity to the camera. If a place has a large number of detailed meshes or solid-modeled parts, you can improve performance by setting each instance’s
enum/RenderFidelity|RenderFidelity property to Automatic.
|Distance From Camera||Render Fidelity|
|Less than 250 studs||Highest|
|500 or more studs||Lowest|
Anchor all non-moving objects, as anchored objects are more efficient in terms of rendering/physics. Do not simply rely on a large object’s mass to keep it in place.
If an object will be in close proximity to moving objects or players, but it never needs to collide with them — for instance a “ghost” wall — set
BasePart/CanCollide|CanCollide to false. Do not, however, take time to set this property on distant objects that will never collide with anything, as it will not improve performance.
Use partial object
BasePart/Transparency|Transparency sparingly, as semi-transparent objects inhibit a lot of internal rendering optimizations. If you require transparency on several
BasePart|BaseParts, attempt to merge them using solid modelling (a transparent union is more optimal than a group of 10 smaller transparent parts).
Materials / Texturing
BasePart|BaseParts, use built-in
enum/Material|Materials in favor of
Texture objects, as materials are more efficient in regards to replication and rendering. For
MeshPart|MeshParts, however, a texture applied via its
MeshPart/TextureID|TextureID is equally efficient to setting its material. That said, textures occupy more memory than materials, so you should monitor the GraphicsTexture value in the Memory tab of the
/articles/Developer Console|Developer Console.
Both solid-modeled and
MeshPart objects have a
enum/CollisionFidelity|CollisionFidelity property which controls the “detail” of the object’s collision bounds. The following options are ordered from most performant to least performant.
|Box||Use this option if the object looks like a block or collisions with it can be approximated by a box that spans its bounds.|
|Hull||Use this option for simplified collision bounds on convex objects like balls and traffic cones.|
|Default||Use this option for the most accurate collision bounds which match the object's physical appearance.|
If you’ve enabled the ShadowMap lighting technology, all objects will cast shadows by default. If a specific object doesn’t need to cast distinct shadows, disable its CastShadow property.