Best Practices
Last updated
Last updated
Behavior nodes have a 1:1 relationship with their associated inputs/outputs within the behavior tree. Cause nodes should adhere to the Single Responsibility Principle, a vital part of the SOLID object-oriented design practices. If done correctly, the Cause node will be individually responsible for solely evaluating specific conditions. Similarly, using this principle with effect nodes means each node executes a single action.
Coupling between nodes in code can lead to brittle behavior. Nodes should only communicate through input and output sockets; they should not depend on each other in code. This allows for easy modification and extension of the behavior tree without affecting other system parts, thereby conforming to the Open/Closed Principle.
Behavior nodes cannot be Unity MonoBehaviors. They are Plain Old C# Objects (POCO). This practice of using POCOs creates a more structured application architecture that makes nodes platform-agnostic, performant, reusable, easier to control, and easier to troubleshoot. While MonoBehaviors are tightly coupled with Unity's lifecycle and primarily used for GameObject components, behavior tree nodes operate independently of Unity's GameObject architecture. To leverage Unity's lifecycle events, the SparkSDK offers the Lifecycle class.
When adding an "Interacted" or "Grabbed" Behavior Node to a Spark, ensure that the "Is Interactable" trait is checked. It is common for new creators to overlook this step, leading to confusion about the inability to grab or interact with Sparks.
When configuring UI buttons, make sure the Sort Order of the button is set higher than other UI elements within the same container (such as a Billboard or Screen Space UI) if symbols or elements overlap the button, as shown in the image. This ensures the button stays on the top layer, making it clickable and fully functional.
If no other UI elements overlap the button (like in the image below), having the same Sort Order is fine and should work as expected.
