I watched Basic Platformer Game tutorial for Unity where presenter created coin pick-up script that he attached to Coin prefab. I want to know if the pick-up script should be attached to the Player or Coin GameObject.
Let's say we have a game with pick-upable objects. They do nothing more than incrementing the score (or affecting the player in another way) and destroy themselves on collision.
I was wondering that what is the preferred approach to this problem.
I've come up with two approaches:
Approach A
Have one ObjectPickup script on the player game object. This script would do whatever is required depending on the type of collided object.
private void OnTriggerEnter2D(Collider2D other)
{
if (other.gameObject.CompareTag("Coin"))
{
IncrementScore();
Destroy(other.gameObject);
}
else if (other.gameObject.CompareTag("SuperSpeed"))
{
IncreasePlayerSpeed();
Destroy(other.gameObject);
}
}
Approach B
Have CoinPickup script on every coin and SuperSpeedPickup script on every super speed powerup.
private void OnTriggerEnter2D(Collider2D other)
{
if (other.gameObject.CompareTag("Player"))
{
other.gameObject.IncrementScore();
Destroy(gameObject);
}
}
And other script:
private void OnTriggerEnter2D(Collider2D other)
{
if (other.gameObject.CompareTag("Player"))
{
other.gameObject.IncreasePlayerSpeed();
Destroy(gameObject);
}
}
Is Approach A more efficient then Approach B? If so what is the rough number of GameObjects when Approach A becomes preferable?
Or is it always better to work with Approach B as it seems to be cleaner (when we have a number of different pick-upable objects)?
In your example, "approach a" would be more efficient than the other because the OnTriggerEnter2D is called once. With "approach b", OnTriggerEnter2D is called twice on two different scripts. It's slower for Unity to make callback calls let alone on two different scripts + the player. Also, OnTriggerEnter2D is sent to disabled MonoBehaviours which makes "approach a" more efficient choice. The main reason for the slow event call is because the call is made from native C++ side of the code to the Unity's C# API side and this is costly.
Note that it really doesn't matter that much. This is just an attempt to answer your question for which one is more efficient but what you're doing is a micro-optimization.
The thing that should play big role in this decision is the behavior of the coin after the trigger.
If the coins behave the-same then use "approach a" and do the detection on the player's side.
If the coins have different behavior like coins with different score values, color and action(animation) when they are collected then do the detection on the coins side and handle each coin. This is the reason why scripts are attached to GameObjects in the first place. You don't need different tags for each different coin. Use enum to distinguish their action in the OnTriggerEnter2D function. It would be awful to use "approach a" to handle this in this case.
Considering you can create a prefab for every coin and for every super speed power up with the second approach script already attached to it AND considering you can spawn them very easily from anywhere in the code I'd really stick to the second approach, making it more sensible, clean and clearly understandable from everyone.
I don't like (and I wouldn't absolutely use) the first approach for this specific purpouse mainly because the OnTriggerEnter2D is very likely to be fired a very large number of times since it's put on the player and the player is moving around colliding with stuff everywhere.
I should use the B, cause it's more like how object-programming works (at least on my head!) even if it's more expensive.
But Method A do not split interactions, so imagine that you can collide with 2 different pickable objects, and you collide with bouth at the same time. If you use Method A, it will use allways the same collision-order, which can be desired or not!
But clearly with Method B you don't really know which object will be picked first (in this concrete case!)
Approach A sounds a bit more performant, also it would work with multiplayer. If you have n players, local or online, you'd need to check the player id on the coin. Otherwise you'd need a lot of tags. No need to do that if the players detect item collisions themselves.
Related
Unity already manages the collisions and triggers well but I would like to know if I can optimise triggers to only react to a layer ?
Currently if I have many different objects with colliders in a scene I need to do :
void OnTriggerEnter (Collider other) {
if (other.gameObject.layer == myLayer) {
// do stuff here
}
}
But this means that the collisions where calculated with ALL of the colliders witch does not seem efficient.
If I want a trigger to react to the player and to the player only, is there a way to tell it to ignore all of the other layers to avoid unnecessary computing ?
Yes, using the Collision Matrix as described in the manual here.
Add a new layer mask (or just use the one you already have)
Uncheck all of the layers it can collide with except the "Player" layer
Change the game object's layer to the new modified layer
Now that object can only collide with the player, and only get triggered by the player (provided one of them has a rigid body component)
I'm spawning a prefab on MotherSpawner gameObject and I want to spawn that prefab again on positionWhereObjectSpawn gameObject.
What I'm planning to do is get the position of positionWhereObjectSpawn gameobject using GameObject.Find, then spawn on that position, but they say it's inefficient.
What's the efficient way to do this?
Something like this should work:
var posGo = GameObject.Find("positionwhereobjectspawn");
Instantiate(myPrefab, posGo.transform.position, posGo.transform.rotation);
One thing that's inefficient here is the GameObject.Find. If you do it at every spawn, yes, it is inefficient. If you find it once and simply place it into a variable in your class to be used later, it's efficient. Like so:
GameObject posGo;
Start() {
posGo = GameObject.Find("positionwhereobjectspawn");
}
Update() {
if(Input.GetKeyDown(KeyCode.SPACE)) {
Instantiate(myPrefab, posGo.transform.position, posGo.transform.rotation);
}
}
Next step to improve efficiency is to get rid of the Instantiate and use an object pool. You create game objects in advance, hide them, and use them when needed. For that, you should Google unity object pooling and use one of the options.
If this is static and you wont change the number of spawns you can do is make public fields and store the Transform of both the spots where you want to spawn a prefab just by making 2 public Transform fields OR if you want to increase the number of spawns you can simply store these positions in a collection and use that to spawn objects, and yea Gameobject.Find is inefficient, this method searches through your whole hierarchy so think how much time will it take to look through everything.
I'm coding a game in XNA and I have two subclasses (Character and Enemy). I wanted to create a method that would lower an enemy's health by the character attack score. How would I do that? I'm having issues with having classes interact with each other.
Would it be possible to do something similar to a constructor, where I could type in something like:
Attack(player.attack, enemy.health);
And if the player's attack score was 2, and the enemies health was 10, after invoking the method the enemy would have 8 health left.
Probably cleaner to make Attack a method on the enemy class, then you can Attack the enemy using your player:
enemy.Attack(player);
The code in the Attack method on the enemy will look at the player.attack property, and decrement its own health accordingly.
You might consider splitting this up a little. Example:
// Method on each player, which in turn calls the method below.
// This is called when myPlayer attacks enemyPlayer.
myPlayer.AttackPlayer(enemyPlayer);
// Called from within the AttackPlayer method which was called on
// myPlayer. The parameter <damage> is a (private?) property in myPlayer:
enemyPlayer.ReceiveAttack(damage);
This should make it fairly clear what is happening, and let you handle different aspects in a flexible way, in case you might want to expand this later.
Example: The player receiving the attack might behave differently in different situation (eg. receive less damage if he has armour, etc), without the attacker having to take this into consideration.
I'm trying to detect collision between the characterController and a platform (a rigidBody + boxCollider) in an Unity project.
I know that I can use this function at the characterController object:
void OnControllerColliderHit(ControllerColliderHit hit) {
// [...];
}
But I would strongly rather to detect it in the platform object, in order to try to maintain the code clearer. Something like this:
void OnCollisionEnter(Collision c) {
Debug.Log(c.gameObject.tag);
}
But it is not working! I searched in Unity forums and apparently the only way to detect a collision is to set the boxCollider's property isTrigger as True and using .OnTriggerEnter(Collider c) method instead. However, doing it will cause the player to fall through the platform, which obviously can't happen.
Alright, so my question is: is there another way to do it - whithout setting isTrigger as True - and detecting the collision in the platform object?
Thank you!
The way I handled a similar problem with a platform and a character controller, is by adding a child object to the platform with a trigger collider set to a larger size than the platform itself (think of it like an invisible box surrounding your platform). What this does is allow you to know if your player is going to hit the platform, the direction he's coming from etc. Then it's a simple matter of sending a message to the platform, with an necessary information parentPlatformObject.SendMessage(params)
I would like to suggest something very similar to what Steven Mills suggested, but may make things easier in the long run.
Add a child object to the player, that has a trigger collision box the size of the player (or just around it's feet if that's what you care about), but has a specific layer only for itself. In the project physics settings, make said layer only interact with the platform's layer. This means you won't trigger if this box hits anything else except for the platforms (like the rest of the player). Since the non triggers had not changed, the player and the platform will behave as you expect (just as with Steven's solution) but if you add new types of objects that you wish to land on/hit, and want them to work in a similar manner, you will not need double the prefabs/make 2 objects, just 1 with the correct layer assigned.
I have an object with a mesh collider and a prefab with sphere collider. I want the instance of the prefab to be destroyed if the two collide.
I wrote the following in a script:
private void OnCollisionEnter(Collision c)
{
if (c == target)
Destroy(transform.gameObject);
print("something"); // Doesn't get printed
}
But it is not working. I have tried toggling isTrigger on both the objects.
I had the same problem of OnCollisionEnter not being called and found this question.
For me, the problem was that I was making a 2D game so the answer is to use the OnCollisionEnter2D function instead.
Have a look at this table
If you want your OnCollisionEnter to be called make sure:
(a) Both objects have a collider attached.
(b) None of the objects is a trigger collider (this will issue OnTrigger function & not OnCollisionEnter)
(c) One of the objects (doesn't matter which of them) is a rigid, non kinematic & non static object (the second don't have to be a rigid body).
(d) Due to computational difficulties MeshCollider might have hard times colliding with other mesh collider, use them with caution.
(e) Make sure both the objects are in the same layer (or at least that they collide in scene settings).
(f) If you are working in 2d - OnCollisionEnter2D will be called, rename your function.
Make sure one of them has a non-kinematic rigidbody attached. Taken from the Unity docs:
When a collision between two Colliders occurs and if at least one of them has a Rigidbody attached, three collision messages are sent out to the objects attached to them. These events can be handled in scripting, and allow you to create unique behaviors with or without making use of the built-in NVIDIA PhysX engine.
From here: Unity3D MeshCollider
I had a similar problem. The box collider wasn't as big as the collision object. Setting the x and z values to 2 units fixed the problem!
Have you tried using the OnTriggerEnter() method and setting a collider on the object to a trigger?
If it doesn't need to tell what object its colliding with you could do a simple
void OnTriggerEnter(){
Destroy(transform.gameObject);
}
Edit:
Also I have done OnCollision like this
private string hitobject;
void OnCollisionEnter(UnityEngine.Collision hit)
{
hitobject = hit.gameObject.tag;
if(hitobject == "Plane")
{
isgrounded = true;
}
}
None of the objects are triggers and they don't need rigid bodies to work.