I have a quick question. If anyone can answer me, I will be grateful. I want to make an animation for about 117 cubes. I know that I don't need to do it one by one. I can simply make a prefab for the cube and duplicate it, but the problem is I just want to make it for the z-axis. However, the animation applies it for all the position properties. So how can I make an animation for the z-axis without affecting y and x? Thank you.
The problem is that you are animating the cubes based on the world position, so it is teleporting everything even for x axis and y axis.
You can easily avoid this by adding your prefab with the animation inside an empty gameObject, you can save it as a prefab too. In this way when you instantiate the empty with inside the cube, the child object (your cube) will move based on the empty position, so y and x will be the x and y of the empty one.
So
1 animate your cube
2 add the cube to an empty game Object
3 set your empty as prefab and duplicate it
If your animation is not sprite based, only transform based, you can use TWEENING Libraries. LeanTween is in the Unity Asset Store as free asset. It is far much faster than builtin unity animation. It is really easy to use. I used it in over 100 UI objects and it didn't even used any remarkable resource at all (FOR 2D Object). I believe that will solve your problem easily.
Related
I have made a smoke particle effect that I instantiate everytime the player shoots, its working but can not be seen with the background. If I delete the background it's visible, I've tried changing the ordering layer, creating a new layer and putting it above the default, but no matter what it's still below the background. Any ideas?
Assuming you are developping a 2D game, you can use the z axis to set the distance of the elements to the camera (what will be the equivalent to the order of render)
Usually in a 2D game you will have the main camera at -10 in the z axis. So moving in the inspector the backgroun to, lets say z=5 or z=10, and keeping in you particle system in z=0 should solve your problem.
Try this easy trick and let me know if you are still facing problems.
You can check the second half of this video for a better understanding
Also, if you are making a 3D game you can go to the material of the particles and make sure that render face is set to both. I just had that problem and it was annoying me. but that fixed it.
I have 5 gameobjects on my scene, all having a collider attached to it.
Now I don't know why - but my first top layer (a starBtn) sometimes fail to detect a mouseClick?
It's in 2d.
I detect all raycastHits and store the hits in an array - I then check all layers of all of them and return the one at the top layer. The one I need to call anaction/function from. My top layer is a square sprite.
Is there a best practice for this or a way to ingnore a collider area if an object in from of it is overlapping?
Cheers
Ps: I willadd code to this question in an hour or so.
Ok. What I had to do to solve this was to add a z-value to each object with a collider.
Then cycle through each objects' z-value - storing the highest value. Although this is 2d.
How do I make so when I move the camera(with touch) it doesn't go beyond the scene borders?
How do I move the camera with touch so it moves strictly with scene parts, like slides(swipe-first slide, another swipe-another slide) with not going beyond the borders of the scene?
The game I'm making has a camera like in Disco Zoo game for android (I'm a newbie)
Technically, the scene doesn't really have a border. You'll need to define the border somehow within your game, then constrain the camera's position with something like Mathf.Clamp(value, min, max) in an Update() function on the camera.
How can you define the border? It's up to you. Some ideas:
Hard-code the values in the script that clamps the camera. Probably the quickest option, but not flexible
Make public parameters on the camera script that let you set min and max positions in the X and Y directions
If you have a background image: use the extents of that to define your camera's extents
Create empty objects in your scene that define the minimum and maximum extents of the scene. Put your "min" object at the top-left, and the "max" object at the top-right. Connect it to the camera script, then use those positions to see if you've gone too far in any given direction. The main reason to do this is that it's visual.
(Slower, but dynamic) If everything in your scene uses physics, you could search the entire scene for every Collider component, then find the furthest extents in each direction. However, this is probably going to be pretty slow (so you'll only want to do it once), it'll take a while to code, and you'll probably want to tweak the boundaries by hand anyway.
I have a problem with AABB collision resolution.
I resolve AABB intersection by resolving the X axis first, then the Y axis.
This is done to prevent this bug: http://i.stack.imgur.com/NLg4j.png
The current method works fine when an object moves into the player and the player has to be pushed horizontally. As you can see in the .gif, the horizontal spikes push the player correctly.
When the vertical spikes move into the player, however, the X axis is still resolved first. This makes "using the spikes as a lift" impossible.
When the player moves into the vertical spikes (affected by gravity, falls into them), he's pushed on the Y axis, because there was no overlap on the X axis to begin with.
Something I tried was the method described in the first answer of this link.
However the spikes and moving objects move by having their position changed, not velocity, and I don't calculate their next predicted position until their Update() method is called.
Needless to say this solution didn't work either. :(
I need to solve AABB collision in a way that both of the cases described above work as intended.
This is my current collision source code: http://pastebin.com/MiCi3nA1
I'd be really grateful if someone could look into this, since this bug has been present in the engine all the way back from the beginning, and I've been struggling to find a good solution, without any success. This is seriously making me spend nights looking at the collision code and preventing me from getting to the "fun part" and coding the game logic :(
I tried implementing the same collision system as in the XNA AppHub platformer demo (by copy-pasting most of the stuff). However the "jumping" bug occurs in my game, while it doesn't occur in the AppHub demo.
[ jumping bug: http://i.stack.imgur.com/NLg4j.png ]
To jump I check if the player is "onGround", then add -5 to Velocity.Y.
Since the player's Velocity.X is higher than Velocity.Y (refer to the fourth panel in the diagram), onGround is set to true when it shouldn't be, and thus lets the player jump in mid-air.
I believe this doesn't happen in the AppHub demo because the player's Velocity.X will never be higher than Velocity.Y, but I may be mistaken.
I solved this before by resolving on the X axis first, then on the Y axis. But that screws up the collision with the spikes as I stated above.
Why not resolve on the Y-axis first for vertical spikes, and on the X-axis first for horizontal spikes?
Nice graphic, by the way.
As I understand it, you're handling movement and collision something like this:
Move all objects.
For each object O, test for intersection between the player and O, and if necessary, eject the player horizontally or vertically so that it is no longer intersecting with O.
If the player is still intersecting with some object, then (something).
This means that when you come to step (2), you have forgotten which way the object O was moving, so you can't tell if it is trying to push the player upwards or sideways.
Solution: in step (1), store for each object the direction it is moving. When you find the player intersecting with an object, you can look to see whether the object is moving up, down, left or right, and that will tell you which way to perform the ejection.
As Gareth Rees already said, the issue is after a collision is detected, you need more information (both current location and either direction came from or last position) to perform the collision response.
It gets quite complicated if both objects are moving. Instead, choose one object to be the frame of reference and subtract its velocity from everything else.
A straight forward solution might be to create line segments for the movement/delta of the non-frame-of-reference object. Then intersect those segments with the 4 AABB edges. This gives the time of intersection and the normal at the point of intersection. Then you can apply the same response you have now.
One possible solution I found is sorting the objects before resolving based on the velocity of the player.
I am writting a collision detection engine for my game and I have some problems.
Indeed, since I have several fixed rectangle and one moving (the player), I need to know which side of the fixed one was collided at first by the player, to replace him correctly.
The fixed rectangle are NOT in a grid so they can be placed anywhere on the map and they can have diffents size. They are not rotated.
The player class stores it's direction vector.
Any idea?
KiTe
In a nutshell:
You'll compare the Y and X components of the bounding rectangles to eachother to check for a collision. If the top(Y) of the player is less than the bottom of an enemy then you don't need to check anymore because it's not possible that they're colliding. If the right(X) side of the player is less than the left side of the enemy then they can't be colliding. It would help to define top, right, bottom, left of each object you intend to check inside the class. This will allow you to know which side is hit also. This should be enough to get you thinking and experimenting.
Have fun!
The name is "Axis-Aligned Bounding Box" collision detection.
Now you know the name, you can Google for the rest.
thanks to both of you for your help.
I've heard about AABB, but at first sight it didnt seem to fit to my needs (since I didn't understand it well).
But after writing down everything on papper, the solution I found appeared to be exactly the same as AABB !