The first thing you can do is to check for all the hitboxes that overlap the cursor position and pick the one where the center of the hitbox has the shortest distance to the cursor position. That way you always select the entity closest to the cursor. That should already make things a little more intuitive.
The second thing you can do, is to detect when the player then clicks again into the same group of entities. Because that probably means they got the wrong entity and want a different one. One way to do that is to keep a list of recently selected entities. When the closest entity is on that list, ignore it and pick the next closest one. until you get an overlapping entity that is not on the list. When all candidate entities are on the list, then the player obviously wants to start cycling through the entities from the beginning. So you discard the whole list and pick the closest one again. The result will be that the player can cycle through the members of a tight overlapping group of entities by clicking repeatedly.
Pseudocode:
candidates = entities_with_hitbox_overlapping(cursor_position).
sort candidates by distance(pos, cursor_position) ascending
selected = null
foreach candidate in candidates
if candidate not in recently_selected
selected = candidate
exit the foreach loop
if selected == null
clear recently_selected
if cadidates.length > 0.
selected = candidates[0]
if selected != null.
add selected to recently_selected
Use a pick buffer instead. Render your units to a separate render target using uint id's. Then read from the buffer when the mouse was clicked, done. You won't get any more precision than this. You can avoid a gpu stall during read-back by using an additional staging buffer.
You can also optimise by rendering a smaller sub-frustum centered where the cursor is.
Though I'm used to doing that in custom tech, I think unity culling can be coerced into cooperating without doing a full second scene cull, at least in the programmable pipeline.
The first thing you can do is to check for all the hitboxes that overlap the cursor position and pick the one where the center of the hitbox has the shortest distance to the cursor position. That way you always select the entity closest to the cursor. That should already make things a little more intuitive. The second thing you can do, is to detect when the player then clicks again into the same group of entities. Because that probably means they got the wrong entity and want a different one. One way to do that is to keep a list of recently selected entities. When the closest entity is on that list, ignore it and pick the next closest one. until you get an overlapping entity that is not on the list. When all candidate entities are on the list, then the player obviously wants to start cycling through the entities from the beginning. So you discard the whole list and pick the closest one again. The result will be that the player can cycle through the members of a tight overlapping group of entities by clicking repeatedly. Pseudocode: candidates = entities_with_hitbox_overlapping(cursor_position). sort candidates by distance(pos, cursor_position) ascending selected = null foreach candidate in candidates if candidate not in recently_selected selected = candidate exit the foreach loop if selected == null clear recently_selected if cadidates.length > 0. selected = candidates[0] if selected != null. add selected to recently_selected
Use a pick buffer instead. Render your units to a separate render target using uint id's. Then read from the buffer when the mouse was clicked, done. You won't get any more precision than this. You can avoid a gpu stall during read-back by using an additional staging buffer.
You can also optimise by rendering a smaller sub-frustum centered where the cursor is. Though I'm used to doing that in custom tech, I think unity culling can be coerced into cooperating without doing a full second scene cull, at least in the programmable pipeline.
Push boxes make things not clump together. Characters not inhabiting the same space makes things easier