I am developing yet another mobile game and I’ve done this before a thousand times but every time I start a new project I have to make tons of changes to my “moving” mechanics of characters and this time around I want to make something a little more robust and adaptable so I can recycle it a lot easier.
I have a lot to think about yet, but the first thing that came to mind is this: what is the most inexpensive way to know if a character/object/whatever is actually grounded?
I know this can be done with a sphere cast downwards, with “oncollisionenter” and the solution I’ve been using so far, a small trigger by the character’s feet which only collides with the ground, and OnTriggerStay grounded = true, which works perfectly.
However, which of these solutions is the one with the lowest overhead? Is there another solution to this problem?
Is the ground static? If so you could record the height that is ground at each x,y and then you have a constant time lookup to see if you are grounded. This will take up memory though, which might be worse than using CPU on a mobile device.
You might also have to store multiple heights if there can be multiple levels of ground - like a two story house. So then x,y would map to a list of heights.
Im actually using that solution to a game with tons of fake physics, because it has about 40+ enemies simultaneously on screen… but I was looking for something more expansive. That solution might be ultra light weight but doesnt allow for any kind of slopes which is kinda lame
Aren’t you already using 3D colliders? these will give you collision enter/exit messages when they collide. I don’t understand the requirement for the redundant spherecast or raycast.
In my “solution” for that game I am only storing “groundY = 0.5f;” and thats it lol, how can I make slopes with that, using absolutely no unity physics/collisions?
Hippocoder, honestly, until you’ve asked that, I supposed that if I simply dont use the events (such as Update, OnCollisionEnter…) somehow there is no overhead on those (or less overhead). Isnt that the case? Also, with the collision method you kind of have to filter the results based on layer/tag/name/whatever to know if the collision is in fact with the ground… to be honest I tried using only OnCollisionEnter/Exit for some time, if it collided with the ground its grounded, if it ceased colliding, its not grounded… but, I had many bugs with it… sometimes it was grounded but was not marked as grounded… it wasnt reliable at all… thats why Im using OnTriggerSTAY for my last projects… its obviously worse performance wise but at least it always work… =/
I can’t find the original Answers where I got this code from, but here is what I’ve been using:
public bool isGrounded(){ // Check if in contact with ground
groundCheck = Physics.Raycast (transform.position, -Vector3.up, distToGround);
return groundCheck;
}
(Originally JS I believe, I converted to C# like this) (groundCheck was supposed to be there as a) a quick check and b) because I couldn’t get the return to work properly, so feel free to declare that variable only there)
And you can use it like this so that it checks ONLY when you wish to jump:
if (Input.GetButton ("Jump") isGrounded ()) {
rigidbody.velocity = new Vector3(0,jumpSpeed,0);
}
Not sure if the original guy meant it to be even more efficient as to be checked only when the button is pressed, but this works quite fine this way.
Other than this, not so sure what would be more efficient. What do you guys think?
EDIT: distToGround was from earlier, where it got the distance of the object to the ground in the Start()… Actually, here’s the link:
All I did was just use 0.5 as I have a ball, I know the exact dimensions, and I don’t need the extra 0.1 error margin (or such) as the game isn’t that complicated where I’d need it (yet)
I’ve done a few platformers now. ;') The following suggestions are for 2D games, but can be generalized to 3D as well.
I personally like RayCasting, but to do it correctly it takes multiple RayCasts. Check out the Sonic image on this page to see what I mean. Basically, I would suggest raycasting from the edges of the player, not from the center. You can then tell if the player is going up slopes, or if they’re partially over a cliff, etc.