Learn how you can improve the performance of your game.
While Makinom is already optimized for performance, you can use additional tweaks and techniques to further improve your game’s performance. Naturally, this depends on how you’re using Makinom’s features and on other factors, like your target platform.
It’s recommended to use Unity’s profiler (Unity menu: Window > Profiler or Window > Analysis > Profiler) to check which optimizations are beneficial for your game. Keep in mind that the profiler can also influence the outcome.
Creating objects (e.g. game objects or data holding structures) and freeing their memory after use is costly – preventing this through pooling can improve the performance of your game.
Pooling Game Objects #
Instantiating and destroying game objects can decrease the performance of your game, especially when happening often. This can be reduced by using pooling.
It’s not a good idea to pool every game object – e.g. level architecture or other game objects that are only needed once in the scene. Pooling is only useful for game objects that are often used (instantiated and destroyed), like particle effects or bullets.
Pooling of game objects is set up in Base/Control > Game Object Pools and added to scenes using the Pool component.
Learn more in the pooling documentation.
Pooling Lists #
Lists are widely used in Makinom, e.g. changing and checking game variables often involves a list of the used variable handlers, or using game objects in schematics also often involve lists of game objects. Creating lists and freeing their used memory after use can also influence performance, particularly when done very often each frame frame.
Makinom automatically reuses lists where possible – i.e. once a list is no longer needed, it’ll be returned to a pool of lists and reused at another time. This improves performance, but also increases the required memory.
You can change the list pooling settings in the Makinom editor (Game > Game Settings > Performance Settings). To disable pooling, set the pool size of the individual lists to 0.
Use the Trim Excess option with caution – while this frees the memory occupied by larger lists to reduce the total amount of allocated memory of your game, this will have an impact on performance if it happens often. Only use this option when you’re running into a problem with using too much memory (or reduce the number of pooled lists). Trim Excess is by default disabled.
Machines and Schematics #
Starting schematics through machines or schematic nodes is optimized for fast and performant execution, but can still have a large impact on performance when starting a lot of machines at the same time (e.g. using a Start Machine node). While Makinom does a lot of optimizations under the hood, there are some things and settings to consider on your end to further improve the performance.
Please note that the influence of these tips on the performance largly depend on your use of Makinom’s features and your target platform. In a simple or light setup without many machines running at the same time, you’ll barely notice the improvements – but when starting/running hundreds or thousands of machines at the same time, you’ll notice the impact these settings can have.
Sharing Local Variables #
When starting machines/schematics from a schematic using a Start Machine or Start Tagged Machine node, you can optionally share the local variables of the running schematic with the started schematics/machines. Unless there’s a reason not to do this (e.g. they’re using the same variable keys but you don’t want the started schematics to override the running schematic’s variables), it’s recommended to share the local variables. Otherwise each started machine would have their own variable handling, which impacts performance.
If none of the involved schematics use local variables, this can be ignored, as the local variable handler of a schematic is only created upon using variables.
Sharing Local Selected Data #
Like local variables, selected data lists of the running schematic can be shared with the started machines/schematics when using a Start Machine node. This also improves performance and is recommended, unless you don’t want the selected data to be shared (e.g. to prevent interference between the schematics).
If none of the involved schematics use selected data, this can be ignored, as the local selected data handler of a schematic is only created upon using selected data.
Repeat Schematic Node #
The Repeat Schematic node is very useful for schematics/machines that repeat execution every frame, e.g. Tick Machines or Auto Machines using Repeat Execution. Starting a machine is more costly than repeating a running schematic.
This node will repeat executing the running schematic from the start in the next frame (or FixedUpdate depending on the machine’s update type). This will perform far better than having a Tick Machine start the schematic each frame. If the machine should only run under certain conditions, you can use the Auto Stop settings in the machine component to stop the schematic when the conditions aren’t valid any longer. Additionally, you can use a Check Start Condition node in the schematic to check the machine’s starting conditions.
Single vs Multi #
The Execution Type of a machine (and machine starting nodes) can also impact performance. Single execution will perform better than Multi execution, because Multi needs it’s own instance of the schematic for each simultaneously running machine.
If the used schematic doesn’t involve anything with time (e.g. a Wait node or waiting for a node to finish), all nodes will be executed within the same frame, making Multi execution not neccessary (because the schematic already finished executing before the next machine could start).
E.g. starting 1000 machines using a Start Machine node will perform far better with Single execution than it would with Multi execution.
The Blocking execution type is the same as single (but preventing other Blocking machines from executing).
Limit Nodes per Tick #
The Limit Nodes per Tick setting in the schematic’s Settings node can optionally limit the number of nodes that will be performed in a single frame. Once the number of nodes is reached, the schematic will wait until the next frame before continuing with the next node’s execution. Naturally, any node involving wait times will reset the node counter.
Executing many nodes per frame means more impact on the overall processing and can impact performance. If you’ve got some task-heavy schematics, it might help limiting the nodes per frame to reduce the stress on the system.
This can also help when starting a lot of machines/schematics in Multi execution type. Keep in mind that the node limit is per executing schematic, i.e. it should be low enough to actually limit the used nodes per frame.