Seeing a target and being allowed to attack it can depend on different rules. A visible target might be beyond weapon range, behind an obstruction that blocks the shot, or unavailable because the selected unit lacks ammunition or action points. Check which condition failed before spending movement to fix the wrong problem.
A greyed-out attack button is a small thing that can stop a tactical turn completely. You can see the opponent. You have selected the right soldier. So what exactly is missing?
The answer should help you choose another action. Here is an invented example that separates the checks instead of treating every unavailable shot as a line-of-sight problem.
How can a target be visible but out of range?
A unit's sight range can be longer than its weapon's attack range. In that case, seeing the target supplies information without supplying permission to shoot it.
Imagine a straight corridor with numbered positions from zero to eight. Our hypothetical soldier stands at zero and can see up to eight tiles away. Its weapon has a maximum range of six tiles, measured as the difference between positions along this corridor. There are no obstacles, hidden enemies or range bonuses in this example.
A target at position seven is visible but beyond weapon range. The visibility check passes; the range check fails. Moving to position one would reduce the distance to six, which meets the range requirement. Nothing about that alone guarantees the attack is now available, because other conditions still need checking.
This original diagram uses invented distances along a straight corridor. It illustrates one failed condition, not the rules of a particular game.
Why might moving into range still leave no shot?
The move can solve the distance problem while consuming resources needed for the attack. Check the complete sequence, including movement, ammunition and any rule that ends the turn.
Give the soldier two action points. In this invented system, moving one tile costs one point and firing costs two. Actions do not automatically end the turn, but there are no free attacks or ways to gain points during it. The weapon is loaded.
From position zero, the target at seven is out of range. Move one tile closer and it is now in range, but only one point remains. The soldier still cannot fire. The interface should now explain an insufficient-points problem rather than continue reporting an out-of-range problem.
| Position and budget | Target distance | Range check | Attack-cost check |
|---|---|---|---|
| Position zero, two points | Seven tiles | Fails: maximum six | Enough points to fire |
| Position one after moving, one point | Six tiles | Passes | Fails: firing costs two |
| Position one with a fresh two-point budget | Six tiles | Passes | Passes, if other conditions remain unchanged |
The last row is conditional. Waiting gives other actors an opportunity to change the situation, so it is not a promise that the target will remain available. Our action-budget guide develops this kind of whole-turn arithmetic further.
Can an obstacle block a shot without hiding the target?
It can if a game's visibility and attack rules evaluate different paths or obstacles. That is a possible design choice, not a universal explanation for every awkward corner.
For example, a hypothetical game could test visibility from a unit's viewpoint but test a projectile from a different origin. A narrow opening might satisfy one test and fail the other. Another game could deliberately let sight pass through an object that its weapon rules treat as a barrier.
Red Blob Games' grid-line guide shows several ways of tracing lines through tiled space, including variants that account for the cells a line crosses. Its visibility demonstrations explore how obstacles restrict a visible region. These are geometric references; they do not establish which implementation a particular game uses.
Before blaming geometry, read the actual blocked-shot explanation. Moving around a corner will not help if the real issue is an empty magazine.
Does seeing an enemy through a teammate allow an attack?
Shared squad information does not necessarily give the selected soldier a valid firing path. Check whose observation reveals the target and whether the chosen attack permits using that information.
Imagine one teammate watching a room while another stands behind a solid wall. The player can see the room through the first unit's observation. The second unit may still have no legal direct shot, even though the enemy is drawn on the player's screen.
Some games provide actions with different targeting conditions, so the action description matters. Our fog-of-war and line-of-sight explanation covers the distinction between player knowledge and an individual unit's view. Attack eligibility adds another layer on top of that information.
What should a blocked-attack preview explain?
It should identify the condition preventing the selected action and, where possible, show what a proposed move would change. A specific reason gives the player a next question to investigate.
In the corridor example, “seven tiles away; maximum range six” explains the starting problem. A destination preview could then show “in range; one point remains; attack needs two”. That would expose the second problem before the player commits to moving.
If several checks fail, showing only the first can lead to repeated surprises. A compact list of relevant restrictions may help, provided it stays readable. These are interface suggestions, not claims that every game must present targeting in the same way.
What should I check before reporting a targeting bug?
Compare the result with the game's stated rule or preview, then record the positions and conditions needed to reproduce the mismatch. A frustrating result can still follow the rules; a clear report helps distinguish the two.
- Is the target currently observed, remembered or revealed by a teammate?
- Is the correct weapon or ability selected?
- Are range, ammunition and remaining action points sufficient?
- Does an obstacle or status effect prevent this particular action?
- Did the preview promise an attack that the committed move did not allow?
If something still appears inconsistent, include the version, relevant settings and a capture or save where appropriate. Our feedback guide explains how to separate an observation from a suggested fix.
We like interfaces that turn “why can't I do this?” into an understandable choice. Join the studio conversation on Discord to share the tactical games that explain those choices well.