local me = "Brandon" -- Comment can refer to local x = 2 function namedFunction(param) print(param) end namedFunction(me)
A successful Roblox game should run smoothly across all supported platforms including mobile devices and tablets. One key to performance is proper management of memory usage. Memory is particularly important on mobile devices. If a game uses up too much memory on a phone, it will cause the game to crash.
Terrain, parts, graphical effects, scripts, physics simulations, sounds, and more can all contribute to total memory usage. The Studio Performance widget displays metrics on a place’s memory usage which can be used to identify places that use too much memory.
There are two tools that can be used to observe the memory usage of a game. The first is the Developer Console which can be opened in both Studio and Client. The second is the Studio Performance Widget.
The developer console displays the current memory usage of the running place in the Memory tab:
The console can be opened on Mac and PC (both Client and Studio) by pressing F9.
|Platform||How to open Dev Console|
|Mac and PC (both Studio and Client)||Press F9|
|Mobile (tablet and phone)||Enter the message "/console" into the chat|
|Console||Select Developer Console from the in-game settings menu|
The Studio Performance widget has a section that displays the memory usage of place. This widget can be opened by navigating to the View tab and clicking on the Performance button.
When the Roblox client is running a place it takes some amount of system memory. This is referred to in Roblox as “Total Memory”. This value shows the sum of memory used by both internal Roblox processes (Core Memory) and place specific elements (Place Memory). This number is measurable through the Performance widget, but is also viewable through OS tools such as the Task Manager on PCs or the Activity Manager on Macs.
There is some amount of memory that will always be used by the basic infrastructure of the Roblox client. No matter how small or simple a Place is, some memory will be used for some processes built into the engine that are common to all Roblox games (such as networking, avatars, user interface elements, etc). All of this memory is called “Core Memory”.
Place Memory is essentially everything but the Core Memory. Place Memory is effectively:
(Place Memory) = (Total Memory) - (Core Memory)
Place Memory is the memory that scales as a direct result of choices made as a Place is built. The Studio Performance widget breaks down this memory into “Developer Tags” which can be used to identify how each type of element of a game is affecting the game’s memory footprint.
All Place Memory is assigned a Developer Tag to help associate that memory with a particular design choice. Following is a table of all Developer Tags, along with suggestions on how to optimize memory associated with each tag.
|GraphicsMeshParts||Graphics for Mesh parts.||Use fewer or simpler Mesh parts.|
|GraphicsParticles||Graphics for particle systems.||Use fewer particle systems or produce fewer particles with shorter lifespans.|
|GraphicsParts||Graphics for parts.||Use fewer or simpler parts.|
|GraphicsSolidModels||Graphics data to render Solid Model objects.||Use fewer or simpler Solid Models.|
|GraphicsSpatialHash||General rendering.||Use fewer parts, particles, lights -- anything that contributes to rendering.|
|GraphicsTerrain||Graphics for terrain.||Use less terrain.|
|GraphicsTexture||Texture memory.||Use fewer or smaller textures.|
|GraphicsTextureCharacter||Texture memory for characters.||Use fewer unique character appearances.|
|HttpCache||Assets (images, meshes, etc.) loaded from Roblox servers and now held in a cache in memory.||Load fewer or smaller assets.|
|Instances||Instances in the Place.||Use fewer instances. Everything in the data model (all of the objects in the Explorer widget) is an instance (e.g. parts, scripts, lights, etc).|
|LuaHeap||Heap memory for both Core scripts (scripts that ship with Roblox client) and custom scripts.||Write memory-efficient scripts.|
|PhysicsCollision||Collision data for physics simulations.||If a part doesn’t need to move set Anchored to true. If a part never needs to collide with anything (including Avatar), set CanCollide false.|
|PhysicsParts||Physics geometry and kinetics.||Use simpler, smaller, or fewer parts.|
|Script||Lua Scripts.||Use fewer or shorter scripts.|
|Signals||Signals that fire between Instances: an event fires on one Instance to trigger an event on some other Instance.||Use fewer event connections between instances.|
|Sounds||In-memory sounds.||Use fewer or smaller sounds.|
|StreamingSounds||Streaming sounds.||Use fewer streaming sounds.|
|TerrainVoxels||Terrain voxels.||Use less terrain.|
|TerrainPhysics||Terrain physics.||Use CanCollide set to false , and/or Anchored true for objects close to terrain.|
When working with memory analysis tools, it is important to note that Studio will use more memory per place than Client. This is because:
- Studio supports undo/redo so it may have multiple versions of certain objects in memory.
- Studio keeps separate data models for “edit” and “player” purposes as this makes it easier to clean up after running a simulation of a game.
Since Studio’s increased memory is mainly a matter of scale (objects being counted multiple times), while the numbers in Studio aren’t reliable in absolute terms, it can still be useful to consider then in relative terms. For example, if the “Sounds” developer tag has a much larger value than other tags, it is fairly safe to assume that Sounds should be optimized first. If changes result in a lowering of the value of the tags, then those changes should also be reflected in Client.
Again, this caveat only applies to Studio - any place memory measurements in Client will be accurate.