Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
quick:design [2018/11/15 10:39] – [In Behavior Bricks efficiency matters] pedro | quick:design [2023/11/16 19:50] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | < | ||
# Quick Start Guide | # Quick Start Guide | ||
Line 26: | Line 27: | ||
- Create the _navitation mesh_ that will be used by both the enemy and the player for pathfinding. Select the floor, go to Window - Navigation and press the _Bake_ button. If you have not yet saved your scene, Unity will ask you to do so now. | - Create the _navitation mesh_ that will be used by both the enemy and the player for pathfinding. Select the floor, go to Window - Navigation and press the _Bake_ button. If you have not yet saved your scene, Unity will ask you to do so now. | ||
- | {{ : | + | , moving parallel to the upper floor edge. | Our first step will be to make the enemy go to a fixed position, in (-20, 0.5, 20), moving parallel to the upper floor edge. | ||
Line 49: | Line 50: | ||
- Click on the new node to select it (a yellow border appears when selected) and click on the `Node` tab in the Behavior Bricks inspector. This tab shows the propoerties of the selected node in the canvas. In this case you will find the _input parameters_, | - Click on the new node to select it (a yellow border appears when selected) and click on the `Node` tab in the Behavior Bricks inspector. This tab shows the propoerties of the selected node in the canvas. In this case you will find the _input parameters_, | ||
- | {{ : | + |  in order to mimic the initial configuration. | - Change the value to (-20, 0.5, 20) in order to mimic the initial configuration. | ||
- | {{ : | + |  is the root of the behavior tree and will be executed in the first place. In fact, `GetRandomInArea` will _not be_ executed at all. In order to create a behavior with _two_ actions, we need to _compose them_. | The action marked with an _R_ (`MoveToPosition`) is the root of the behavior tree and will be executed in the first place. In fact, `GetRandomInArea` will _not be_ executed at all. In order to create a behavior with _two_ actions, we need to _compose them_. | ||
Line 121: | Line 122: | ||
- Right click on the canvas an add a composite `Sequence Node`. The concrete position is unimportant: | - Right click on the canvas an add a composite `Sequence Node`. The concrete position is unimportant: | ||
- | {{ : | + |  as its size. | - Select the `Floor` game object, and add it a Box collider. Set (10, 0, 10) as its size. | ||
- Select the `Enemy` game object, and drag and drop the `Floor` into the `wanderArea` parameter. | - Select the `Enemy` game object, and drag and drop the `Floor` into the `wanderArea` parameter. | ||
Line 157: | Line 161: | ||
Conditions are nodes that, when reached, end immediately and inform their parent nodes whether they were evaluated as `true` or `false`. In behavior jargon, when a node returns `false` it is said to _fail_, and to _succeed_ if returns `true`. The distinctive feature of the internal composite nodes (`Sequence`' | Conditions are nodes that, when reached, end immediately and inform their parent nodes whether they were evaluated as `true` or `false`. In behavior jargon, when a node returns `false` it is said to _fail_, and to _succeed_ if returns `true`. The distinctive feature of the internal composite nodes (`Sequence`' | ||
- | |||
- | <!-- | ||
- | In a behavior, any node can prematurely end and _fail_. Imagine a situation where a buggy behavior asks an NPC to move to an unreachable area. In that case, the `MoveToPosition` action will not be able to locomete the game object to that position and just ends and _fails_. | ||
- | |||
- | Ideally, behaviors should not be buggy and actions will never fail. Instead, this feature is used for _conditions_, | ||
- | |||
- | Keep in mind that, from the behavior point of view, actions and conditions are _exactly the same_. But, when creating behaviors it is clarifying think about them as different concepts. Behavior Bricks uses in fact different colors for actions and conditions, and the Collection keeps them in different branches. As a rule of the thumb: | ||
- | |||
- | - __Actions__: | ||
- | - Change the environment. | ||
- | - Usually last more than one game loop. | ||
- | - Hardly fail. | ||
- | - __Conditions__: | ||
- | - Perceive the environment. | ||
- | - Usually last just one loop. | ||
- | - End with success or failure depending on the environment state. | ||
- | --> | ||
In this section we will use the built-in `CheckMouseButton` condition that test if the user has just pressed one of the mouse buttons and ends with success in that case. | In this section we will use the built-in `CheckMouseButton` condition that test if the user has just pressed one of the mouse buttons and ends with success in that case. | ||
Line 190: | Line 177: | ||
- Add a `Repeat` node so the sequence loops again and again and the user can move around to different positions. | - Add a `Repeat` node so the sequence loops again and again and the user can move around to different positions. | ||
- | {{ : | + | . Therefore when a `Priority` node is connected to a `MoveToGameObject` node, a default `AlwaysTrue` condition is automatically added to guard the `MoveToGameObject` action node. | - Create a connection from the `Priority` to the `MoveToGameObject`. Note the yellow node that appears on top of the `MoveToGameObject` action. Every child of a priority must be a guarded node composed of a condition plus an action (or behavior). Therefore when a `Priority` node is connected to a `MoveToGameObject` node, a default `AlwaysTrue` condition is automatically added to guard the `MoveToGameObject` action node. | ||
- | {{ : | + | . | - Add a new `MoveToPosition` node and make it the second child of the priority, becoming the fall-back behavior. This time instead of first creating the action and then connecting it to the priority, click on the bottom connection area of the priority, then click on an empty point in the canvas, and finally select `MoveToPosition` in the drop-down menu. Set the `MoveToPosition` `target` parameter to the constant value (-20, 0.5, 0). | ||
- | {{ : | + |  child of the `Priority`. | - Make the `Wander` node the fall-back (`AlwaysTrue`) child of the `Priority`. | ||
- | {{ : | + |  are you getting, 50 in the example shown in the figure. | Once the enemies have been spawn you can check the scene stats, by pressing the `Stats` button in the `Game` pannel, and see how many frames per second (FPS) are you getting, 50 in the example shown in the figure. | ||
- | {{ : | + | ![]( : |
One way to increase the performance without decreasing the number of spawns or making modifications to the behavior tree is to modify the field `Max Task Per Tick` of the `Behavior Executor` component of the `Enemy prefab`, by default its value is 500. Set it to `1`, play the scene again and see how it affects performance. In this case our frame rate increases up to 65 FPS without apparently affecting the observed behavior of the enemies. | One way to increase the performance without decreasing the number of spawns or making modifications to the behavior tree is to modify the field `Max Task Per Tick` of the `Behavior Executor` component of the `Enemy prefab`, by default its value is 500. Set it to `1`, play the scene again and see how it affects performance. In this case our frame rate increases up to 65 FPS without apparently affecting the observed behavior of the enemies. | ||
- | {{ : | + | ![]( : |
## What's next? | ## What's next? | ||
Congratulations! You've just finished the first Behavior Bricks tutorial. You have learned the basics of the editor, and the main concepts: actions, conditions, blackboard, internal nodes, and reusability. If you want to test your newly acquired knowledge, you can, for example, improve the player behavior. Currently, once a position has been selected, it cannot be changed until the player avatar has reached it. It would be great if the player could select a different position using the mouse to overwrite the previous one. Using a priority selector it is easier that it sounds! And it you need some inspiration, | Congratulations! You've just finished the first Behavior Bricks tutorial. You have learned the basics of the editor, and the main concepts: actions, conditions, blackboard, internal nodes, and reusability. If you want to test your newly acquired knowledge, you can, for example, improve the player behavior. Currently, once a position has been selected, it cannot be changed until the player avatar has reached it. It would be great if the player could select a different position using the mouse to overwrite the previous one. Using a priority selector it is easier that it sounds! And it you need some inspiration, | ||
+ | |||
+ | </ | ||