First, I added an Area2D node as a child to the 2D Sprite node. Then, I added a CollisionShape2D node as a child to the Area2D node. I set the shape of the CollisionShape2D node to RectangleShape2D and created a rectangle that matches the texture area of the Sprite2D.
Then, I created a RayCast2D node and wrote this script:
extends RayCast2D
func _unhandled_input(event):
if event is InputEventMouseButton:
if event.button_index == MOUSE_BUTTON_LEFT and event.pressed:
target_position = get_global_mouse_position()
force_raycast_update()
if is_colliding():
var parent: Sprite2D = get_collider().get_parent()
get_parent().spawnFish(parent)
I havenât done some checks, but this doesnât work quite right. The RayCast2D sends a ray from its position to the mouse position, meaning it also selects 2D Sprite objects that are between RayCast2D and the mouse position, even if there are other Area2D objects in between.
How can I improve this code so that when I click with the mouse, it selects only one 2D Sprite object?
[âŚ] meaning it also selects 2D Sprite objects that are between RayCast2D and the mouse position, even if there are other Area2D objects in between.
Iâm not sure I understand fully what youâre trying to achieve, because what you describe is precisely what raycasts are made for: given a start position and a direction, trace a ray detecting anything on its path. So yes, if an Area2D is located on the ray, it will be detected, and thatâs normal.
How can I improve this code so that when I click with the mouse, it selects only one 2D Sprite object?
I donât understand this question either. If you want to âselect an object when you clickâ, it sounds like raycast isnât the way to go, you just want mouse cursor detection.
Can you send a screenshot of your scene so that itâs easier to understand what youâre trying to achieve?
I want to achieve this: when I click with the mouse, the Sprite2D object I click on should be selected.
Since I donât think itâs a good idea to add a listener to every object, I wanted to use a single RayCast2D node to be able to select multiple different objects.
Okay, then you definitely donât want a raycast for that, theyâre not meant for this kind of system.
If you want to select a Sprite2D, you can use this script attached to the sprite:
extends Sprite2D
func _unhandled_input(event):
if event is InputEventMouseButton and event.pressed and event.button_index == MOUSE_BUTTON_LEFT:
if get_rect().has_point(event.position):
print('Clicked!')
However, itâs using the sprite rect, meaning your actual selection hitbox is a rectangle and may not fit the sprite visible shape.
For a detection with more control, you can attach the script to the Area2D node. The Area2D comes with a shape, as you know already, so you can control precisely how the detection is done. The script would look something like this:
extends Area2D
func _input_event(viewport, event, shape_idx):
if event is InputEventMouseButton:
if event.button_index == MOUSE_BUTTON_LEFT and event.pressed:
print("Clicked!")
Then, once click is detected (i.e. where I wrote print('Clicked!')), you can replace with your own selection behaviour.
But letâs say I have 100 Sprite2D objects in my scene, and each one has an Area2D child. Would it be the right approach to add this listener to each of them?
Alternatively, there would be only a single RayCast2D object, and the listener would only be on the RayCast2D object.
You will see that the print is called only for one Area2D at a time, not all of them, due to how the engine works (you will also see a lot of prints because hovering the area is an input event by itself, but itâs fine too, donât worry about that).
Using the sprite approach I wrote, it would indeed be worse regarding performances, as the _unhandled_input function would be called on all of them, which would result in event position in sprite rect shape, times the number of sprites.
Now, if we ignore the _unhandled_input method, there will be 100 Area2D nodes in the scene, and each Area2D node will has a listener. Total 100 listener. Wouldnât this be bad for performance? Would it cause any issues?
Iâve seen worse haha. Also Iâm not an english native speaker either so I can understand
there will be 100 Area2D nodes in the scene, and each Area2D node will have 100 listeners. Wouldnât this be bad for performance? Would it cause any issues?
Two things:
1/ I donât see any other way of doing that anyway. You can detect a click, and then loop through all your sprites, check the position, etc. That would be a one time thing, but the loop itself would be terrible for performance, and honestly, thatâs just not how you want to do that. The input signals are designed for this kind of feature.
2/ If youâre concerned about the performances of 100 objects, try with 1000 and see how it goes. I cannot assure you anything as Iâve never done exactly what youâre doing, but Iâm confident 100 objects is actually not so much to handle if itâs only a mouse click detection. Physics engines and mouse detection are stuff that can be optimized a lot using different techniques, I donât know how it works precisely in Godot, but Iâm pretty sure you donât have to worry too much for ~100 areas.
I believe that using a single listener and accessing other objects through Raycast2D could be a more performant solution. This is because as the number of objects in the scene increases, there will only be one listener.
Well, I donât like to base my game development opinions on beliefs, so Iâd say you should try and see how performances go. If you try with 1000 objects, and your solution works fine and is performant, then thatâs perfect, and there would be nothing more to say!
However, as I said, raycasts are just not designed for this purpose, so you should not use them. It would be like knocking in a nail not using a hammer, but a wrench. It would work, but itâs obviously not the right way to solve the problem. Also, not using the right tool could cause some problems (not only related to performances).
Besides, I donât think raycasts would be better for performances anyway. But again, you can just test that if you really want to.
Also, keep in mind that 100 may sound like a large number, but for a computer, handling 100 objects is not that much (always depend on what you do with them, of course, but detecting mouse click seems like a piece of cake for a game engine to handle efficiently).
I know this is something thatâs done in Unity, using methods like Camera.ScreenPointToRay or something (donât know if youâve been using Unity but just in case).
To be honest, I now think I misunderstood what you had in mind, I thought you were talking about a raycast going across the scene on the XY axis but it seems you were talking about a raycast starting from the mouse, going through the depth of the scene, right?
In that case, I actually donât know how it would work in Godot (regarding both performances and code readability/flexibility), as its Z axis behaviour seems very different than Unityâs.
Iâve done quick researches before answering your initial question and I stumbled upon solutions that were only mentionning input event functions, which is why I recommended that. But Iâd be curious to see how the code looks in the approaches you found on internet!
I was using this on the Unity3D side. My intention is not to praise or criticize. From my perspective, I find Godot more understandable and I like it more.
RaycastHit2D hit;
[SerializeField] Camera cam;
void Update()
{
if (Input.GetMouseButtonDown(0))
{
hit = Physics2D.Raycast(cam.ScreenToWorldPoint(Input.mousePosition), Vector2.zero);
if (hit.collider)
{
Debug.Log(hit.collider.name); // or hit.collider.gameObject.name
}
}
}
Well, in Unity, this is indeed something thatâs done a lot (I donât even remember if thatâs like the best solution, but I know this is very common).
In Godot, I donât think the raycast technique is so relevant, but Iâm not experienced with mouse detection in Godot to confirm anything.
What I would do is go for the input event functions as it seems to be the way to go (especially since your initial post was about the raycast not working), and remember that you can still change your system later on if you find it inefficient for some reason.
What do you mean by listeners? Do you mean implementing _input_event in your Area2D? In this case, no, you probably wonât have any performance issues, even with hundreds of nodes. At least not because of handling the input.
You might run into problems for having too many nodes/collision objects.
But since you need them also with the ray-cast approach, there is no difference.
Listener: Listening for user interactions from within the _process method or the input method means observing user actions. Thatâs what I meant.
So, why is there no difference?
Wouldnât accessing Area2D objects from a single central point, like Raycast2D, be a logical and correct approach? Only one listener will be active. That means when we click the mouse, the input listener script will run only once since it is attached to a single object.
Otherwise, each Area2D object will have its own listener. This means that if we click the mouse once, 100 objects will process the input separately.
I think listeners are costly. They have an impact on performance, so they shouldnât be overused.
The topic wasnât that anyway; it was about selecting an Area2D with Raycast2D and the mouse. But I couldnât do it.
I have never heard (or experienced) that handling user input (i.e, implementing _input and the likes) has noticeable performance implication.
If you use _input_event in the Area2D as @sixrobin mentions, it is only called for areas where the mouse intersects (assuming object picking is enabled). In fact, under the hood it uses a ray-cast to determine this (in 3D, in 2D itâs âconceptuallyâ the same) - see point 8 here: Using InputEvent â Godot Engine (stable) documentation in English.
Thank you. I will examine the sources. I tried to do something as a result of the information I got from other programming languages. Although I sometimes focus on performance, I actually do not know Godot completely and I am trying to learn.
Well, I definitely wonât blame you for being attentive to performance, but if youâre just learning the engine, you should maybe not worry too much about that.
My personal opinion is that when youâre starting, you should not worry about performances and just try to build something cool to play and learn how the engine works. And if your game starts to run slowly, you can still optimize it, itâs not needed to optimize everything as soon as possible (in some cases it can even be a waste of time).
Iâd even say that working on optimization later in a game production is a good way of learning how to optimize: whatâs a better way of learning how to optimize a game, than having an actual case that needs optimization?
Anyway, these are just my thoughts.
Also thanks @pmoosi for the doc link with the under the hood raycast, I didnât know that though I guess itâs not that surprising!
