Hierarchy Rules
Introduction
The hierarchy relationship between GameObjects is a powerful tool for organizing and managing GameObjects within a scene. GameObjects are displayed in a parent-child structure in Unity's hierarchy view.
Axis builds upon this familiar structure to create more complex and specialized relationships described in this article, offering enhancements that maintain the ease of use and intuitive interface developers are used to, while providing powerful new tools for creating dynamic and interactive environments. This modular approach makes it faster for developers to assign, modify, and visualize these relationships within the editor.
- Intuitive Visualization: Utilize the familiar Unity hierarchy to visualize complex relationships.
- Layered Gameplay Mechanics: Implement nested NavObjects for deeper and more strategic gameplay.
- Modular Abilities: Assign ObjAction objects within NavObjects to easily add or modify functionalities.
- Efficient Management: Streamline the process of managing and changing relationships between GameObjects.
Hierarchy Coloring
Axis hierarchy coloring is a feature that allows developers to visually organize and rapidly differentiate GameObjects in the hierarchy window using color coding and visual cues. This is particularly useful for complex scenes with numerous GameObjects, as it helps to quickly identify and manage various elements and their relationships.
Click here for more detailed information about hierarchy coloring.
NavmeshMatrix > Colliders
In Axis, the NavmeshMatrix object is crucial for grid generation within your game. It uses all colliders within its hierarchy to shape the grid.
Click here to learn more about the rules related to NavmeshMatrix children colliders
NavObjects > NavObjects
One of the key features introduced by Axis is nested NavObjects. In this setup, a parent NavObject can contain multiple child NavObjects that remain unavailable and invisible until its parent is broken. This hierarchical dependency allows developers to create mechanics where the destruction or interaction of a parent object reveals new objects.
For example, an enemy spaceship (parent NavObject) might hide smaller drones (child NavObjects) that only become active once the main ship is destroyed or damaged. This adds depth and strategy to gameplay, benefiting from the familiarity of hierarchy window for easy visualization and management.
Examples of Nested NavObjects Pairs
Parent NavObject | Child NavObject | Description |
---|---|---|
Enemy Spaceship | Smaller Drones | Drones become active once the spaceship is destroyed. |
Treasure Chest | Gold Coins | Coins are revealed when the chest is opened or broken. |
Boss Character | Minions | Minions appear and attack when the boss character takes damage or is defeated. |
Explosive Barrel | Shrapnel Pieces | Shrapnel is released when the barrel explodes. |
Hidden Door | Secret Passage | Passage becomes accessible once the hidden door is opened. |
Tree | Falling Leaves | Leaves fall when the tree is chopped down or shaken. |
Castle Gate | Guard NPCs | Guards emerge when the castle gate is breached. |
Rock Formation | Gems | Gems are revealed when the rock formation is mined or broken. |
Iceberg | Floating Ice Chunks | Ice chunks appear when the iceberg is struck or melts. |
In Unity, the chain of relationships between NavObjects is virtually infinite, allowing for deeply nested structures where one NavObject can be contained within another, which in turn can be inside yet another, and so on. This flexibility enables complex, multi-layered gameplay mechanics. Example: Enemy Spaceship > Smaller Drones > Gold Coins
Important
Nesting Inside vs Spawners: When a NavObject is destroyed or damaged, its hidden child objects are revealed and moved out of the parent, ensuring they appear in the game world at the moment of destruction only once. If the destroyed NavObject is recycled, it returns empty because the child objects have already been released. This prevents repetitive spawning, maintaining gameplay balance.
For reusing these objects and maintain spawning after every destruction see Spawners within NavObjects below.
NavObjects > ObjActions
Another use of the hierarchy system in Axis is the incorporation of Action game objects within NavObjects. Action objects grant specific abilities or behaviors to the NavObjects they are child of.
In Axis, actions within NavObjects grant those NavObjects specific abilities or behaviors that can be triggered to interact with the environment and other NavObjects. Various functions such as moving, attacking, collecting items, or triggering events. Actions allow developers to create dynamic and interactive gameplay elements that respond to player inputs and game conditions.
Action Disabling/Enabling
All action objects can be made available or unavailable by switching the active state of the GameObject, or enabled state of the ObjAction component, as shown in the example below.
New Actions
New actions can be added to any NavObject through some of the 'learning' processes:
- Cloning another action object
- Collecting a NavObject that contains learnable actions
NavObjects/ObjAction > MarkRenderer
MarkRenderer is a useful tool for rendering visual cues in the scene anchored to specific GameObjects/Colliders.
Click here to learn more about AxisMarkRenderer;
NavObjects > Spawners
In Axis, spawners within NavObjects are specialized components designed to instantiate new objects within the game environment under specific conditions. When embedded within a NavObject, these spawners are always initialized in a disabled state, ensuring they do not activate prematurely. Their primary function is to execute their spawning configuration immediately upon the destruction of their direct parent NavObject. If parent NavObject is reused and enabled again, the process is repeated indefinetly.
Example: One example of a spawner within a NavObject is a bomb that spawns zones of fire and damage. When the bomb explodes, the spawner activates and creates these fiery damage zones in the game world. After the explosion, the bomb can be recycled and reused from the object pool.
When reused, the spawner will once again generate the same zones of fire and damage upon the bomb's destruction (and this spawners can even reuse previously instantiated pooled zone objects), ensuring consistent and predictable gameplay behavior. This method allows for efficient reuse of objects while maintaining their intended effects.
Spawners within NavObjects are configured to manage and dynamically change various aspects of the spawning, such as their type, quantity, and initial state. This configuration can be tailored to suit different gameplay scenarios.
Spawners > Transforms
All spawnable GameObjects must be direct children of the AxisSpawner GameObject.