New answers tagged

-1

Also, you can use CompareTag. Firstly, you must to add tag your game objects. Then: public class PlayerClass : MonoBehaviour { void OnTriggerEnter2D(Collider2D other) { if (other.CompareTag("OtherGameObjectTagHere")) Destroy(other.gameObject); } } } Please check this out https://docs.unity3d.com/ScriptReference/Component....


1

One approach to a multilayered map would be an array (or 2-dimensional array) of linked lists or vectors holding tile objects. So your tile struct would either hold a pointer to the next tile above it, or you would have "stacks" of tiles of varying heights spread across the grid. Essentially that creates a 3D array. A nice, albeit old article on ...


0

I fail to see what your problem is with making child objects. Just make two objects as children of your "body" object, make a script saying: public GameObject body; OnTriggerEnter2D(Collider2D other) { body.characterInQuicksand = true; } Attach it to whichever of the children is supposed to have it, assign the variable body in the inspector and you'...


-1

I think you can use GetComponent<Collider2D>().name to determine the current collider being used in OnTriggerEnter. I did a quick test with this Debug.Log(other.name + "hit" + GetComponent<Collider>().name); and it seemed to work ok as long as the triggers did not overlap.


1

You might have some success checking the Collider2D.IsTouching method in your OnTriggerEnter. void OnTriggerEnter2D(Collider2D col) { if (weaponCollider.IsTouching(col)) { /* Weapon */ } if (sightCollider.IsTouching(col)) { /* Sight */ } } IsTouching is polled against the last physics update so it should be pretty light weight. However, if your ...


-3

A grid. Implementation is more simple and often times superior in performance. Edit: Hu, why the downvotes? This was more of a follow up info to the accepted answer. The OP asked for alternatives. You can find grid vs. quadtree discussions everywhere. Bottom line is a quadtree doesn't deliver a better performance (often times it's slower) than a simple grid ...


0

You can solve it easy by making additional rectangle above the rectangle attached with it, and respond differently for each rectangle, by this way you can control the collision


1

The algorithm you are using right now has a runtime of O( n^2 ). A tree structures can help you get that runtime lowered. Quadtrees have O( log(n) ) From that you can calculate if you will benefit from a quadtree.


0

I would try making sprites, but if your new to pygame and python that can be a complicated idea. What I wuld do then is draw a rect around your paddles that have the same position as your paddles so the rects will follow the paddle. Afterwords Id put a rect around the ball. Then make a collision detection that sais. if ball_rect.collidepoint(x,y): ...


0

I fixed this issue as I noticed a simple mistake that I made when I was trying to fix this myself. Here is the whole piece of code. using UnityEngine; using System.Collections; public class DestroyObject : MonoBehaviour { public GameObject ObjectToDestroy; public GameObject TheObject; public GameObject Player; void OnCollisionEnter(Collision col) { ...


0

So you could create a combined collision box for each entity, wich creates a polygon. This polygon is combined from a entity pos now and the pos after the move.


2

Generally game mechanics should not behave differently depending on whether or not the player observes the event. The player expects that the game mechanics outside of their field of view behave exactly as those inside their field of view. It is very immersion-breaking when they leave an area, enter it again shortly afterwards and apparently in the mean-time ...


0

I think I've seen some of your other posts as I followed the same tutorial myself here years later. You've tried to "correct" the logic of the original algorithm by using //Find which axis has the biggest penetration ;D Vector2 fixnormal; if (xExtent > yExtent){ But that's not the original tutorial's logic ...


1

In Alto's Adventure, the terrain is dynamically generated over time, by concatenating prefabricated patterns (for example the super steep slope where you can perform a triple backflip, or any other soft slopes) in a randomic way to keep the game various from play to play. A possible implementation can be treating these "pieces" of terrain as vertices, from ...


0

Get the Rigidbody component. Then change the velocity value. Rigidbody rb; void Start() { rb = GetComponent<Rigidbody>(); } void ChangeSpeed() { rb.velocity = new vector3(x,y,z); //place your value in xyz } For further reference: Unity Physics Rigidbody Velocity


1

Set the new Physics Material on the object you are colliding with. Make sure you set the friction to 0. http://docs.unity3d.com/Manual/class-PhysicMaterial.html


0

The method I would choose for this is to just use your existing map for as much as possible. This is essentially your first approach. Yes, you will need to figure out the IDs of trees (and other relevant objects), but on the plus side you don't need to make any changes to how you're creating maps, storing them, loading them, rendering them... Regarding ...


0

Collisions are always calculated in the game loop, but you can do some things to just check collisions between a bunch of items instead of checking the interactions between all the objects array (n^n). First of all, i strongly recommend you to research/implement a quadtree based collision technique (great doc here), limiting in this way the number of ...


1

Almost everything happens in the game loop somewhere, so that distinction is a bit moot. What you seem to be asking is "when you change the position of an object, do you check for collision there, or do you check for collision later." It depends on the specific needs of your game, but in general it's probably better to do the calculation later. Code that ...


6

It shouldn't have any impact. You should not be implementing zoom by scaling or otherwise messing with 'the Z factor' (whatever that is) of your objects in the world. You should be implementing zoom by adjusting properties of the camera and projection (field of view, camera position). The camera and projection properties only come into play when you ...


0

When working with direction and speed, if you change the value of the former you don't need to update the value of the latter, as GM:S automatically updates hspeed and vspeed in order to reflect the changes on the speed vector upon its separate components. Also, you can change the value of speed making it both greater or smaller than zero, but if you only ...


0

I was searching for an answer because I had the exact same problem, and I thought of a great and light workaround. When you create your method of what happens to your B2D Body after the collision, just create an object and assign it to the obects' .getUserData. Then when the collision is called again, you can "save yourself" with an "if statement".Example: ...


3

A rational approach might be to simplify your problem. This is a game, so most of the time there is no need for 100% accurate physics. Instead of tracking every single component that makes your ship, you can instead prepare several damaged ship models and swap then on the fly as it gets more and more damage. When you swap the models, you could spawn some ...


0

You are not using collisionBitMask The class reference can be found Here A example of code is Here which also explains very well how collisionBitMask works


1

Check broad-phase collision detection. Example link That would reduce the collision detection cost. Then figure out WHAT causes your performance drop. Virtual method calls themselves are not that expensive - 1000 of them in a frame will definitely NOT cause a slideshow. Perhaps the message system is slow? The message creation copies data by value? etc etc.



Top 50 recent answers are included