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 !
Related
Hi guys i was wondering how to create a shape adjustment with two objects which specifically could be described as the independent cells, one of which is static, and the second one is dynamic and surrounded by "plasma". The movement of the active object must be controllable by the user (WSAD). Collision of the active object with the static one causes the static object to be swallen, though doesn't change it's position stays in place all the time. As the active object moves, passes the swallen object and troughts it out.
See the image below:
Player character
When it comes close enough to pink enemy it's starting to swallow it (surround by yellow thing)
Pink enemy is completely sourrounded when red circle is in the centre of both.
When it leaves enemy it takes off the yellow thing
I was wondering what is the simplest way to do it. I've been thinking about cloth, physics joints, mesh substraction (is it even possible?), some kind of animation... I don't have much time to do it. Can you show me the simplest way. Which tools and approach should i use? I'm not asking for full code or full solution only for some tips.
Tim Hunter mentioned a wonderful way, most perfect in 3D.
You can use another approach in 2D :
Inside OnCollisionEnter2D try finding hit points using Collision2D.contacts . See this reference .
Create some particle effect there.
Disable the enemy
Now play swallowing animation of the player.
At animation end, enable enemy again.
Maybe calculation is little tricky, still efficient.
Im not sure how to approach this and looking for suggestions - I have a moving box (moved by the user) with paths cut into it, and a character that traverses the paths. The moving box moves as well as rotates.
At all times, I need the character to follow the paths (NOT walk thru walls) to get back to a point on the box that is
facing the screen (even when the box rotates)
Middle of the screen (even as the box moves up/down)
Here the circle scribble is the character:
What would this be called/any approaches? Is this a waypoint system or something more complex?
A nav mesh would be better if you wish to make a more complex AI for the other character say if you wanted the character to chase the player. If your route is predefined then using waypoints will be the most efficient way of creating what you want in this scenario. Here is a good tutorial by Brackeys of how to implement waypoints.
https://www.youtube.com/watch?v=aFxucZQ_5E4
I'm currently working on a narrative game and don't know how to accomplish something. The game is a 2D platformer so everything is build with sprites. I have a scene with trees and the trees have eyes, I want the eyes to follow the player along, but the "pupils" need to stay within the "holes" of the tree. I have made separate sprites for both the hole in the tree as well as the pupils of the eye's. I would prefer to write it in c# :).
I have also added a concept screenshot, so you can get an impression about what i'm trying to accomplish.
http://imgur.com/pGCV8Uy
Many thanks to the person who can explain to me how to accomplish this!
Well I suppose you could use a joint to restrict the yellow pupils to stay within the holes of the eyes.
Then you could use C# to calculate the relative Vector between the character and the pupil. Guide the pupil to go in the direction of the Vector, and it will be restricted by the joint to stay in the eye. The would result in the pupil always pointing in the direction of the character while staying in the eye, which is what you want.
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.