Hey everyone,
Whenever I approach game design, it seems like the first hurdle that trips me up and causes me to lose many days of progress and sleep is collisions. Collision detection, how to handle collisions after they've been detected, etc.
Right now I'm working on a top down dungeon crawler in unity that works in only 2d. They way I do this is I have 2d planes at different layers of depth (for detail in the level design) that use 3d collision objects (which basically stretch to the max and min Z coord along where the camera can see). I've managed to detect a collision just fine. However, once detected I'm pulling a bit of hair out over how to make the character hug the wall as if stopped so that they won't go through. One of the problems I've reached is that I got the character to stop, but they now jitter at the wall instead of just stopping.
Wondering what might be the best practice with this.
Right now I have it so that basically the game:
1) Triggers the collision (using function OnTriggerStay)
2) Figures out which direction the collision came from (top, bottom, left, or right)
3) Calculates depth of collision
4) Resets player to be touching the wall, rather than inside it.
As I said before, the problem occurs that as the player continues pushing into the wall, they will jitter rather than gracefully stopping against it.
I guess my main problem is that I usually can't find any good collision tutorials close to what I'm looking for. A lot of the collision tutorials for specifically Unity deal with the physics engine (which I'm not really interested in at the moment), and I find a lot of times on forums people give blanket statements like "There's a lot of ways you can handle collision, be more specific".
I guess I'm hoping this time I'm specific enough. Top down dungeon crawler wall behavior. Thanks~
P.S. I'm not really interested in seeing code so much as finding a good algorithm, unless it turns out the problem I'm having is something specifically related to Unity.
Problems With Collision (Unity 3.5)
Well I can't be 100% sure of what exactly your code is doing but I'm guessing it looks something like:
-Player presses movement key
-Move player X units per second *** Here is the issue
-Check for collision *****
-If collision occurs move the player back
If you want to fix that jitter you need your code to look ahead, BEFORE the collision occurs. So when the player presses his movement key check to see if the new position of the player will collide with anything. If the new position does collide don't move the player forward X units per second. The key is that you project the objects position and check BEFORE actually moving the object.
-Player presses movement key
-Move player X units per second *** Here is the issue
-Check for collision *****
-If collision occurs move the player back
If you want to fix that jitter you need your code to look ahead, BEFORE the collision occurs. So when the player presses his movement key check to see if the new position of the player will collide with anything. If the new position does collide don't move the player forward X units per second. The key is that you project the objects position and check BEFORE actually moving the object.
In my opinion theres nothing wrong with moving checking then moving back in a simple 2D game its still an ok way to do it as long as theres no drawing involved inbetween or other object are moving on a different thread (which you generally wont do). If you have a gitter then it means you have drawing at some point ( the drawing function is probably not right in-between it could be your code might not be reacting how you expect ).
Normally your loop wants to follow something like this
Events Handled
Objects Updated
Draw
Some sample code would also help ;)
Normally your loop wants to follow something like this
Events Handled
Objects Updated
Draw
Some sample code would also help ;)
One approach I have used in the past ( for a spaceship racing games ) : Once detected a collision against a wall , the object changes its state to a mode in wich it goes out the wall , following the normal vector of the wall surface at the point of collision .It does only this , until no more collisions are detected. The result is the object going back only the necessary distance to barely touch the wall. Than the state changes back to the mode where the player has the control of the object.
Easiest way would be just to use unitys built in rigidbody object. Really, why do you want to this yourself?
Alright, I think I found the problem. As for what MaxFire said in Unity the draw functions are late in the order of calls, so that would never be a problem. The problem comes from the fact that physics calls (which would include collision detections like the OnTriggerEnter() and OnTriggerStay()) happen before Update(), which is where the code to move the player is. So basically every frame (or about every frame) it checks for the collision, but then there's a chance for the player to move into the collision and have it drawn that way; i.e. why the jitter occurs.
I'm guessing I'll have to find a way to either call it later (i.e. as part of the player's move function) or send some sort of reference of the collision's result to the player so I can update the move function.
I am using a rigidbody component for the player, that's how I'm able to use OnTriggerStay().
I'm guessing I'll have to find a way to either call it later (i.e. as part of the player's move function) or send some sort of reference of the collision's result to the player so I can update the move function.
Easiest way would be just to use unitys built in rigidbody object. Really, why do you want to this yourself?
I am using a rigidbody component for the player, that's how I'm able to use OnTriggerStay().
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement