Logic Best Practices

This section covers the best practices Build A Rocket Boy recommends following when building content using the node system. Although logic nodes are designed to be simple and efficient, it is important to plan and organize your logic well so that it can still be maintained and developed when growing in complexity.

For practical examples of the best practices, please refer to the Gamemode Templates Stamps.

Sequencing

Logic linking is very flexible, and most output events will allow you to link to multiple other nodes, splitting the execution into many branches. However, the order of execution of these branches is not guaranteed and it could create unpredictable results.

If some piece of logic requires that nodes are executed sequentially in a specific order, the Sequence Node allows you to structure it in a “first this, then that” format. This node also helps with keeping logic clean and more readable, avoiding excessively long chains of logic.

Events

Event Nodes are designed to allow creators to easily break their logic down into multiple parts which communicate together. Instead of having a long continuous chain of logic, it’s generally good to split into functional units which can be called from anywhere using the events. You should find plenty of examples of events in the Templates Stamps.

Note: Please be mindful when naming your events to not use very generic names, any event of a specific name will call all the other nodes sharing it!

Isolating Features

Building complex games can be a lengthy process. When many features are added, it starts becoming difficult to find the origin of specific problems, and a lot of time can be spent trying to find the cause of an issue.

When creating new features to add to your game, it is recommended to create them in isolation, in a new arc, so they don’t get affected by the other features of your main game, and it becomes easier to isolate and fix issues. It is very quick and easy to create new arcs, so we recommend creating your features independently of your main game, then creating a stamp from it, and integrating in all your arcs which could benefit from it.

Testing and Fixing Issues

The difficulty of finding and fixing problems can vary greatly if you’re in a single player environment, or in multiplayer. We recommend following a step-by-step approach to testing your features:

• Testing Single Player. You have access to the Write to Log Node which allows you to get precise information about your logic. Testing in a single player is much simpler as you only have to care about a unique player doing actions. Your feature should work flawlessly in this mode before moving to the next step.

• Testing in Multiplayer, but with only one player on the gamemode. This will allow you to check that your system still works when you’re in a client-server environment, even if you still have only a single player in the game.

• Testing in Multiplayer, with multiple players on the server. This is the real test to see if your system is working. You should leverage the social features from Arcadia to invite your friends to your arc and help you testing before you publish your game.