koobas.hobune.stream
Click strategy
Hello,
I work with Unity for a long time now, and I there is still a concept that bothers me: the click strategy.
What strategy do you use when it comes about player interactions?
When player clicks on the scene do you have a high entity that will receive the input, do the raycast to check on what part of the screen the player has clicked, and throw the click information to a lower component according to the clicked object ?
When player clicks on the scene do you make all your "clickable" entities check if the click was for them (that means a raycast per clickable entity) ?
When player clicks on the scene do you use magic?
When player clicks on the scene do you treat UI and interactive game object differently? How?
My problem is either to have to many raycast made or not being fully able to handle specific situations like non-interactive objects when the game is supposed to be paused...
I can't find any documentation about what strategy is the best so I wonder how you do that kind of click management logic. Thanks for your help.
@D$$anonymous$$G rofl now when you say magic, are you speaking of an existing input management system called magic? Or just flat out magic?
Here's a simplified version of the current method I'm using for my game (which is a 2D point and click game written in javascript):
Click Script + Input Manager
I have an empty game object with 2 scripts attached, ClickScript and InputManager.
Click script basically sends a raycast out from the main camera and when it hits a box collider it sends the raycast info to the input manager like this:
if (Input.GetMouseButton(0))
{
// A function that does one raycast and returns a raycast hit.
raycastHit = GetRaycast();
// Call the function OnLeftClick on the inputManager and send the raycastHit as a parameter
inputManager.OnLeftClick(raycastHit);
}
And in the InputManager:
function OnLeftClick(raycastHit : RaycastHit2D)
{
// If you've clicked a person...
if (raycastHit.collider.CompareTag("Person"))
{
TalkToPerson();
}
// If you've clicked an exit...
else if (raycastHit.collider.CompareTag("Exit"))
{
Exit();
}
}
And so the tag of the game object you click on determines what happens. It took me ages to work out this method and I've found that it is very flexible and very quick to work with and to add new features into the game.
If its a 2D game youre making I can direct you to a couple of handy sites/ scripts for Unity.
Thanks for your answer. Yes, it's a 2D game and I'd appreciate the link you were talking about.
However, about your answer, don't you end with a gigantic Input $$anonymous$$anager script full of if/elseif ?
I've had success doing it this way:
Tag each object that you want as clickable with a "clickableObject" tag in the inspector.
Code:
Ray clickRay;
float distance; //need to put in some value depending on what you need
...
...
//the following would usually go in Update()
clickRay = mainCamera.ScreenPointToRay(Input.mousePosition);
if (Input.GetAxis("Fire")
{
if (Physics.Raycast(clickRay.origin, out objHit, clickRay.direction * distance))
{
if (objHit.collider.tag == "clickableObject")
{
//do something that you can only do on a clickable object
}
}
}
Cool, but how do you manage object that already have a tag? How do you manage different clickable object? With a test after your collider.tag test?
If an object already has a tag, I may look at creating a subcategory. This would go back to the planning phases of game design. You can create a ton of different tags (I've never run out) and they do not seem to impact the game. As for once it is deter$$anonymous$$ed that an object is clickable, I do use additional tests to find more specifics of the object clicked on. You could go so far as to check for a unique object ID using getInstanceID() which will return an int. I built a horror game demo where you had to go around and collect specific objects (like Slenderman). When the player clicked on the object, I displayed a message stating "you have found the", name.
That's my usual approach. I'd also suggest to try and get all of the game mechanics down before actually working on the game. "Feature creep" can break any project, sending you back to the drawing board over and over again...
