--- title: Battle Components url: "https://orkframework.com/guide/ork4/ork4-documentation/ork4-components/battle-components/" updated: "2026-08-05" category: Components --- # Battle Components Learn more about battle-related components. # Battle Component The *Battle* component is used to place a battle at a specific location in your scene. The battle can either be started directly by the component via various start types (e.g. *Trigger Enter* or upon *Interaction*) to fight the enemies that are defined in it, or the component can be used to pre-place battles for *Combatant Spawner*, *Add Combatant* or *Random Battle Area* components. [![](https://orkframework.com/wp-content/uploads/BattleComponent-Icon-1.png)](https://orkframework.com/wp-content/uploads/BattleComponent-Icon-1.png) The [battle spots](https://orkframework.com/guide/ork4/ork4-documentation/section-battles/ork4-battle-spots/) defined in **Battles > Battle Spots** are used to place the combatants participating in battle based on the location of the *Battle* component’s object. Optionally, the battle spots can be overridden in the *Battle* component to manually place them using objects in the scene. Additionally, *Battle* components can override some default battle settings, e.g. the used battle system, battle start/end schematics or player/enemy advantages. E.g. overriding the battle start schematic allows you to have a special battle intro for a bossfight. ## Setup for none-start use If you want to use a *Battle* component to place battles for other components, set them up with the following things in mind: - don’t use a *Scene ID* - don’t add combatants - don’t use any start type, e.g. click on the *None* button in the *Start Settings* Basically, you don’t want the battle to start on it’s own or mark itself as finished after a battle. # Random Battle Area Component Use a *Random Battle Area* component to add random encounters to your scenes. Random encounters can happen while the player moves within the area of the component’s object. **Unity**: The area is defined using a collider with *Is Trigger* enabled. [![](https://orkframework.com/wp-content/uploads/RandomBattleArea-Icon-1.png)](https://orkframework.com/wp-content/uploads/RandomBattleArea-Icon-1.png) You can define minimum and maximum distances between battles as well as the random encounter chance. Additionally, the random encounter rate is influenced by the *Random Battle Factor* (set up the [battle system settings](https://orkframework.com/guide/ork4/ork4-documentation/section-battles/ork4-battle-systems/)), which can be changed through various things (e.g. equipment, status effects and option menus). ## Battle position The battle takes place at the position the player is when a random encounter happens – this’ll automatically generate a *Battle* component (on an empty object). Optionally, *Random Battle Areas* can also define an object with a *Battle* component or use the nearest *Battle* object. This allows to have battles take place at specific locations or override some default battle settings via the *Battle* component. # Real Time Battle Area Component The *Real Time Battle Area* component is used to create an area for fighting real time battles. Not using an area will use the whole scene **Unity**: The area is defined using a collider with *Is Trigger* enabled. [![](https://orkframework.com/wp-content/uploads/RealTimeBattleArea-Icon-1.png)](https://orkframework.com/wp-content/uploads/RealTimeBattleArea-Icon-1.png) A real time battle area doesn’t use battle spots or battle start/end schematics. All combatants (set up for real time battle) within the area or scene will participate in the battle. # Battle Grid Component The *Battle Grid* component is used to create and place a battle grid at a specific location in your scene. The battle grid must be set up in the scene before it can be used in a battle. [![](https://orkframework.com/wp-content/uploads/BattleGridComponent-Icon-1.png)](https://orkframework.com/wp-content/uploads/BattleGridComponent-Icon-1.png) The component only defines the battle grid, to use it in battle you still need to involve a *Battle* component. ## Battle Grid Generation The grid is generated based on the defined number of *rows* and *columns*. The *position anchor* defines which part of the grid (e.g. the *middle center*) will be placed at the position of the *Battle Grid* component. ### Cell Settings Define the grid cell type that should be used for your regular cells, as well as an *empty* cell type for cells that couldn’t be placed (e.g. no ground). You can optionally use a *blocked* cell type to use cells that can’t be moved on based on the ground’s slope. Placing cells can also optionally use the slope of the ground for their rotation, to align them with the ground below them. ### Raycast Settings Finding cell positions on the ground uses raycasting. Define the *layer mask* that’ll be used – you should only include layers your ground is placed on to not have other parts of the scene interfere with the grid cell creation. You can optionally use separate layer masks for *blocked* and *empty* cells, i.e. if the raycast hits something on those layers, a cell will use the blocked or empty cell type you defined in the cell settings. This check uses a spherecast, i.e. you can define the cell size that’ll be checked for. E.g. a rock is placed in the scene and should create blocked cells. Using a *cell size factor* of *0.8* will consider a cell blocked if the rock is reaching more than 20% into the cell. The raycast is fired downward from the position/height of the grid’s object for each individual grid cell. You can use the *source offset* to add an additional offset to that position, e.g. firing from higher above. Either make sure your grid’s object is high enough to not be below any ground in your scene, or use the *source offset* for that. If you end up with *empty* cells where there shouldn’t be some, try creating the grid from a higher position. Raycasting for the grid generation (and grid battles in general) uses the *horizontal plane* you defined in the [battle grid settings](https://orkframework.com/guide/ork4/ork4-documentation/section-battles/battle-grid-settings/). This defaults to the *Default* horizontal plane, i.e. what’s defined the [system settings](https://orkframework.com/guide/ork4/ork4-documentation/section-system/system-settings/). The horizontal plane determines if this is a 2D or a 3D game by defining which is the horizontal axis. For raycasting, this decides which direction the raycast is fired to hit the ground. This all might sound more complicated than it is – all you need to keep in mind is to use the correct layers in your layer mask. The *horizontal plane* is usually a one-time setup for the entire framework. ### Generating Click the *Generate Grid* button to generate a grid with your settings. If you don’t like the grid, you can also remove it via the *Remove Grid* button, or just click *Generate Grid* again to create a new grid (destroying the old). In case you want to keep your old grid but update the grid positions, enable *Keep Old Cells* before using *Generate Grid*. This’ll only update the cell positions based on raycasting, but keep the previous setup of all cells. After your first grid generation, you’ll probably not see much – this is because you don’t see the individual cell prefabs yet. ## Grid Setup The grid setup is used to manipulate the grid, e.g. paint new cell types, change connections or move cells around. If you enable *Auto Show (Scene Load)*, the grid will be automatically show it’s cells when the scene is loaded in-game. Otherwise you need to manually show the grid, e.g. in the battle start schematic using the *Show Battle Grid* node. ### Editor Setup The editor setup lets you define when to show the grid in the editor. If you want to see the grid and the cell prefabs at all times in the editor, enable *Show Grid (Editor)*, *Show Prefabs (Editor)* and *Show Unselected (Editor)*. If you only want to see it when the grid is selected, enable the first 2 (show grid/prefabs). ## Manipulating the Grid The *Mode* in the grid setup settings of the *Battle Grid* component defines which mode you currently use to interact with the grid. ### Select Allows selecting the individual cells. The setup of the selected cell can be changed (see below in the *Battle Grid Cell Components* for details). Since the grid cells are objects, you can use the usual ways of manipulating/changing the position, rotation or scale. You can also select individual cells by simply selecting their objects in the scene. The cells are child objects of the grid’s object. ### Move Allows moving the individual cells. It’s recommended to use this mainly for changing the height of the cell (i.e. Y-axis of the position). Using this to swap cells or rearranging will result in unexpected behaviour in battles, since highlighting, ranges and movement will still rely on the row/column index of the cells. ### Rotate Allows rotating the individual cells. This can be used to further adjust a cell’s alignment with the ground. ### Paint Allows painting cell types on the grid. You can paint a selected cell type directly on the cells by holding down the left mouse button and dragging the mouse over the cells you want to paint on. A 2nd cell type can be painted by holding shift while using the left mouse button. Holding **CTRL** (**CMD** on Mac) when clicking on a cell will pick the cell type as the paint cell type. Holding **Shift + CTRL** (**CMD** on Mac) will pick the cell type for the shilft cell type. You can change the size of the used brush (measured in cell size). ### Connections Allows changing the connections between cells. You can change connections by dragging a connection arrow holding down the left mouse button. Drag the arrow on the cell itself to remove a connection, or drag it on another cell to connect it to that cell. [![](https://orkframework.com/wp-content/uploads/ork3_battle_grid_connections.gif)](https://orkframework.com/wp-content/uploads/ork3_battle_grid_connections.gif) Connections are one-way, e.g. you can block moving into one direction, but allow moving the other way. Additionally, connections don’t need to go to neighbouring cells. E.g. use this to connect far away cells to create things like teleports, shortcuts, etc. You can also use this to create multi-layered grids. E.g. to create a 10×10 grid tower with 3 layers, create a 10×30 grid. Remove connections between the individual 10×10 blocks and move each block on top of each other. Connect parts of the 3 blocks, e.g. to build staircases or lifts between the layers. ## Using Battle Grids Using a battle grid for a battle can be done in different ways. ### Battle Components The *Battle* component that’s starting the battle determines if a *Battle Grid* component is used. - **No Grid**No *Battle Grid* component is used. I.e. the battle isn’t a grid battle. - **Nearest Grid**Uses the nearest *Battle Grid* component. I.e. the object with a *Battle Grid* component that’s closest to the battle. - **Defined Grid**Uses a defined *Battle Grid* component. By default, battles use the *Nearest Grid*. If you want a different setup in situations where you don’t use a *Battle* component (e.g. when using *Combatant Spawner* components), you can set up a *Battle* component for none-start use to define the settings of a battle. ### Schematics Schematics can set the battle’s grid using the *Set Battle Grid* node. If the battle grid isn’t using *Auto Show* to automatically spawn the cell prefabs when the scene loads, you need to use a *Show Battle Grid* node, e.g. in the battle start schematic. You also use this node to hide the grid again, e.g. in the battle end schematic. ### Scripting You can also set the battle’s grid via scripting: ``` ORK.Battle.Grid = gridComponent; ``` The *gridComponent* is the *Battle Grid* component you want to use. Or to remove the grid: ``` ORK.Battle.Grid = null; ``` # Battle Grid Cell Component Each grid cell of a battle grid has a *Battle Grid Cell* component attached when it’s created. **You’ll never manually add this component.** You can use the component’s settings to change the cell type and other settings of the cell. ## Deployment Optionally override the deployment settings of the cell’s grid cell type. This has the same deployment settings available as the [battle grid cell types](https://orkframework.com/guide/ork4/ork4-documentation/section-battles/battle-grid-cell-types/). ## Spawn Rotation Optionally define the rotation for the spawned combatant. [![](https://orkframework.com/wp-content/uploads/ork3_battle_grid_spawn_rotation.png)](https://orkframework.com/wp-content/uploads/ork3_battle_grid_spawn_rotation.png) In the scene, the spawn rotation is indicated with a small yellow arrow. ## Blocked Settings Optionally override the *blocked* settings of the cell’s grid cell type. E.g. set a cell to be blocked, but *passable* during movement. # Battle Grid Cell Positions Component The *Battle Grid Cell Positions* component is used to define combatant placement positions for player/ally and enemy combatants. This is mainly used when allowing more than 1 occupant on a cell. # Damage Dealer Component *Damage Dealer* components are added to the prefabs of your combatants or equipment (e.g. a sword), or added to other things that should deal damage, e.g. a prefab used by a fireball spell. They deal damage when interacting with a *Damage Zone* component. **Unity**: Needs a collider (either as collider or trigger, depending on the damage dealer’s setup) to be able to damage something. [![](https://orkframework.com/wp-content/uploads/DamageDealer-Icon-1.png)](https://orkframework.com/wp-content/uploads/DamageDealer-Icon-1.png) Damage dealers have to have an action set and be activated (e.g. via schematics animating an action) and enough time before getting deactivated to actually hit something. ### Start Type The *Start Type* defines how the damage dealer can cause damage on a damage zone: - **Trigger Enter**When a damage zone enters the damage dealer’s trigger. - **Trigger Exit**When a damage zone exits the damage dealer’s trigger. - **Trigger Stay**While a damage zone stays the damage dealer’s trigger. - **Collision Enter**When a damage zone starts colliding with the damage dealer’s collider. - **Collision Exit**When a damage zone stops colliding with the damage dealer’s collider. - **Collision Stay**While a damage zone is colliding with the damage dealer’s collider. - **Custom**By calling the damage dealer’s *CustomDamage* function. **Unity**: The *Trigger* start types require the collider to have *Is Trigger* enabled, the *Collision* start types require it to be disabled. ### Environmental Damage (Always On) Damage dealers can be used on their own to create environmental hazards, e.g. a trap or damaging area. You can also use it to cause contact damage on combatants, e.g. the player running into an enemy can damage the player. To use it that way, enable the *Always On*setting – you have to define the ability that’ll be used for the calculations. The combatant used by the damage dealer has to know the ability and able to use it (e.g. use costs). The combatant that’ll be used to deal damage (i.e. user of the ability) can either be on the damage dealer’s object or parent object, or defined in the damage dealer’s settings. For environmental hazards, you’ll set a combatant in the damage dealer’s settings – for contact damage, just add the damage dealer to the combatant’s prefab (root or a child object). ### Destroy Settings A damage dealer can automatically be destroyed, either after a defined amount of time or on dealing damage. E.g. a projectile will be destroyed on after *5* seconds and when dealing damage. ### Damage Settings When hitting an object (via it’s collider) that doesn’t have a *Damage Zone* component attached, the damage dealer can optionally search in child or parent objects of the hit object. The damage dealer can also be limited to only dealing damage one time or only hitting one target. E.g. swinging a sword can damage a combatant only once per use, but hit multiple combatants in one swing. ### Activation Settings Define which actions can activate a damage dealer. A base attack, counter attack and defined abilities and items can activate it. You can also use *activation tags*, instead of defining a specific action. E.g. all sword equipment prefabs have damage dealers with the tag *weapon* added to them. Any ability using the *weapon* tag in their damage dealer setup will be able to activate the damage dealer. Additionally, using the damage dealer can be limited to defined battle systems. ## Activating Damage Dealers Damage dealers need to have an action set and be activated to be able to deal damage. Only an action matching the damage dealer’s setup can be set to it, i.e. either set up for that action or via activation tags. Activating a damage dealer is generally handled by schematics, either automatically while a schematic runs, or manually by the *Activate Damage Dealer* node. Keep in mind that the schematic needs to have some wait time between activation and deactivation, or the damage dealer has no time to hit anything. Abilities and items also have *Damage Dealer Settings* to define activation tags they’ll use, as well as a sound and prefab that’ll be used when the damage dealer hits a damage zone. Additionally, abilities and items can also use battle animations (schematics) to animate the damage dealer’s use. They’ll be used when the damage dealer hits a damage zone. When animating damage dealers, you need to use a *Calculate Action* node in the schematics to calculate the action’s results. ### Auto Activation Auto activation can be used to automatically activate damage dealers on the user of an ability or item. This includes equipment displayed on the combatant (via *Equipment Viewer* components). The *Battle Animation* settings of abilities and items can use auto activation via the *Auto Damage Dealers* setting for the individual schematic added to them: - **None** Doesn’t use auto activation. - **Set Action** Sets the damage dealer’s actions when starting the schematic and removes it at the end. Only sets the action, but doesn’t activate it (e.g. can be activated via animation events, scripting or the *Activate Damage Dealer* node). - **Activate** Activates the damage dealer (and sets it’s action). This’ll activate the damage dealer at the start of a schematic and deactivate it at the end. ### Set Damage Dealer Action Node The *Set Damage Dealer Action* node is used in schematics to set a damage dealer’s action without activating it. Requires the schematic to be started by an ability or item, otherwise it doesn’t have an action available to set. ### Activate Damage Dealer Node The *Activate Damage Dealer* node is used to manually activate and deactivate a damage dealer. This is used for prefabs spawned by an action (e.g. a fireball’s damage dealers) or when you need to have more control over when the damage dealer is active. The node can also set the action (default setup) of the damage dealer, in which case it has to be used in a schematic animating an ability or item, or it doesn’t have an action available. Activation without setting the action is always possible, but requires the damage dealer to already have an action set. You can define additinal activation tags, as well as use a different sound or prefab than defined by the ability or item. ### Animation Events (Unity) You can also activate/deactivate damage dealers via animation events. If the damage dealer already has an action set and the animation is running directly on the damage dealer, you can use the *SetDamageActive(bool active)* function to activate (true) or deactivate (false) it. Otherwise, you can add the *Combatant Animation Events* component to your combatant prefabs to activate/deactivate damage dealers on the combatant: - **CalculateCurrentAction()** Calculates the combatant’s current action outcome. Same as using a *Calculate**Action*node. - **CalculateCurrentAction(float damageFactor)** Calculates the combatant’s current action outcome with the provided damage factor. Same as using a *Calculate**Action*node. - **ActivateDamageDealers()** Activates all *Damage Dealer* components on the combatant. The damage dealers need to have an action set before activation (e.g. via *Set Damage Dealer Action* node used in a schematic animating an ability or item). - **DeactivateDamageDealers()** Deactivates all *Damage Dealer* components on the combatant. - **CurrentActionActivateDamageDealers()** Activates all *Damage Dealer* components of the combatant’s current action (have to be set up for auto activation). - **CurrentActionDeactivateDamageDealers()** Deactivates all *Damage Dealer* components of the combatant’s current action (have to be set up for auto activation). # Damage Zone Component *Damage Zone* components are added to the prefabs of your combatants or equipment (e.g. a shield). A combatant needs at least one damage zone to receive damage from damage dealers. [![](https://orkframework.com/wp-content/uploads/DamageZone-Icon-1.png)](https://orkframework.com/wp-content/uploads/DamageZone-Icon-1.png) You can add multiple damage zones and create vulnerable spots  by using the *Damage Factor* setting. The damage factor determines how much damage on a damage zone will do by multiplying the damage by the defined factor, e.g.: - 1 is 100 % damage - 0.5 is 50 % damage - 1.75 is 175 % damage Optionally, you can also *block* the damage completely – e.g. adding a blocking damage zone to a shield will allow a combatant to block attacks with the shield. Additionally, damage zones can display flying texts caused by the calculations at the damage zone’s object instead of the combatant’s object. They can also play an audio clip or a sound type (on the damage zone’s combatant, i.e. using it’s sound assignments) when receiving damage. ### Schematics Damage zones can use a schematic when they receive damage. The schematic will use the user of the attack (i.e. the combatant the damage dealer came from) as *Machine Object* and the damage zone’s object as *Starting Object*. ## Use Damage Zone Node Schematics used to animate an ability or item can also directly use a *Damage Zone* component without using a *Damage Dealer* component. The *Use Damage Zone* node will use a damage zone on a defined object. This can be used in combination with a *Raycast* node to select an object, e.g. below the cursor or the center of the screen (crosshair) to implement a FPS shooting mechanic. # Damage Zone (Schematic) Component Similar to the regular *Damage Zone* component, the *Schematic* variant is not required to be placed on a combatant or it’s equipment. [![](https://orkframework.com/wp-content/uploads/DamageZone-Icon-1.png)](https://orkframework.com/wp-content/uploads/DamageZone-Icon-1.png) This component works on it’s own and only starts the schematic that’s set up for it. Can optionally check the action it was attacked with (e.g. being a base attack, a defined ability or of a defined content type). E.g. use this for things like evironmental destructions.