Im making small 2D game and i would like how should, theoretically work jumping and standing on objects.
For jumping should there be some kind of gravity?Should i use collision detection?
Good example of what i want to undestand is jumping in Mario.
I think for jumping it would be best to create some simple model which use "game time". I would personally create some physical model based on gravity, but you can go for whatever you want.
If you want your character to "stand" on object, you will have to create some collision detection. Good start is to approximate object by one or more circles (or lines) compute collision of them and in case the approximation collides determine the final state by some more precise method.
In terms of should there be gravity and collision detection - personally for such a thing I'd say yes and yes! It doesn't have to be complicated but once you have those things in place the pseudocode for the "main loop" becomes relatively simple:
if not colliding with object underneath, apply gravity
if user presses jump key and not colliding with surface //i.e. if we're in the air already, don't jump again
apply upward velocity
That is of course oversimplified and there are other corner cases to deal with (like making sure when you're coming down after jumping, you don't end up embedded or potentially going through the floor.
You might want to take a look at Greenfoot which handles a lot of things like all the Java2d stuff, collision detection etc. for you. Even if you don't stick with it it'd be a good platform for building a prototype or playing around with the ideas talked about.
Standing on objects implies collision detection, you can approximate the characters and the environment objects with primitive shapes (rectangles, circles etc.).
To check if to shapes are colliding, check axis one by one (X and Y axis in your case). Here is an explanation of the "separating axis theorem" (Section 1).
Related
I wasn't sure if this was the correct forums to post this on; I was considering the Game Development site.
I'm developing a game in LibGDX (Java) and I've set up a btKinematicCharacterController to control the player. This handles the jumping, walking, and everything else.
However, I've come across a problem. Imagine that the character is standing on a slope -- even a very gradual one. The character will slowly slide down the slope, which is very annoying for the purpose of my game (and, I imagine, most.) This is because if a player wants to just stand on a slope, they can't.
I think this is happening because of the collision detection resolution. The player may very slightly fall through the floor, and since it's on a slope, would then be pushed out along the normal of the slope. This would mean, simply, they'd be pushed along slightly.
My actual player model is a capsule, and I use a ghost object for the btKinematicCharacterController.
So how can I make sure that my character doesn't slide down slopes? Of course, it needs to still have physics so that it can jump, and collide with other objects.
One of the popular approach is to disable gravity when there are >=1 platforms under the character's foot.
It can be done by :-
sensor (setSensor(true) + collision callback)
For more information about collision callback : http://www.bulletphysics.org/mediawiki-1.5.8/index.php/Collision_Callbacks_and_Triggers
ray test : http://bulletphysics.org/mediawiki-1.5.8/index.php/Using_RayTest
Another approach is to hard code it (link to a short discussion - 2D Metroid related), but it is a hard work and heavily depend on the stage design.
This video may help. It is Unity, not related to Bullet, but seems applicable.
I am also very interested in this problem. Please don't accept if it doesn't solve.
To reader, if there are better answers, feel free to share.
My question is mostly related to the theory behind it. I make a 2D game for a project and i detect collisions by using the .overlaps method in the Rectangle class and the collisions are handled beautifully. First of all , is that considered to be a continuous or discrete collision technique. As i'm reading the theory i say it is discrete ,however i'm reading in online articles that the major disadvantage of discrete is that it detects collision after it actually happened. So,my question is the following : is it actually discrete and if it is why i see no disadvantages?
Thanks
This is discreet because we only know if two bounding boxes collided after we check if the imaginary/invisible boxes intersected meaning they already overlapped. So by the time you take action (update) due to that collision, the objects are not in the collided position. Worse case, if they are not in relative speed, they can pass through. Think of the classic helicopter game where you dodge obstacles by going up and down. Say you put the velocity of the chopper on x really high, depending on your frame rate which depends on the hardware, you will see different positions of actual collision. For continuous, one object has to be aware of the physics properties of the other objects it may collide with to predict possible collision.
In reality, for 2d games like the helicopter game I mentioned, it really doesn't matter much. You can simulate the result of the collision by doing changes on an object's rotation, velocity, gravity and through some nice animations. If your game objects have abstract shapes, you should use something like box2d. There's a good Intersector class as well.
Also, you can experiment with different bounding box sizes (bounds) of an object rather than creating the bounding box of the object equal to its width and height.
I'm trying to make it so when a sprite which is attached to a physics body overlaps another sprite on the level something happens. The second sprite is NOT attached to a physics body.
More specifically when the two sprites are overlapping I want the game to constantly check to see if the distance between the centers of the sprites is less than a certain amount or not. Then if the distance is small enough something will happen.
I'm trying to use collision checking as a way of optimizing the game so it doesn't have to constantly check distances between every single object of type A and B even if they're not even close. It will only check the distance when they're close enough to be overlapping.
Now what I am wondering is how can I do this? Is there a way to check collisions between sprites as part of AndEngine? Or would it be easier to attach a physics body to the second object also and then just use physics collision detection? But then if I do that can I make it so the collision will be detected but they won't actually physically "collide"?
Yes, see CollisionDetectionExample.java. I suggest you download the whole examples package, it is very useful in the absence of any documentation for AndEngine. Please note that collision detection is not pixel perfect, so it will still detect collisions of transparent parts of the Sprites. There is a library for that, but I am afraid it is outdated.
For starters, how can I use defineCollisionRectangle API?
I've done some research about it and I think it doesn't have any use at all.
True that I can just use collidesWith() to check if 2 sprites collide.
But what I want to use a sprite that has parameters like house with a backyard fence around it.
I tried using the defineCollisionRectangle() in a condition, set it in the constructor but I don't know how to use it.
I can just use object.getX/gety and object.getWidth/getHeight, to make a Parameter around the sprite.
What does defineCollisionRectangle really do and how do I use it?
To detect collision for objects like house with a fence around it I would start with defining two Sprite objects - one for fence, another for house - each with its own collision rectangle.
To render a house with fence around it, I'd draw houseSprite over fenceSprite like at the sketch below:
With this approach it would be really easy to tell whether collision happened with fence or with house - simply because each defines its own collision rectangle.
Generally, when you find out that single collision rectangle doesn't do what you need, you invent a way to decompose things to more rectangular sub-elements so that when combined, these elements simulate / approximate desired behavior.
End users just don't care how many Sprite objects are there behind the scene. They're happy as long as end result feels about like house with a backyard fence around it.
So I'm currently working on some FPS game programming in OpenGL (JOGL, more specifically) just for fun and I wanted to know what would be the recommended way to create an FPS-like camera?
At the moment I basically have a vector for the direction the player is facing, which will be added to the current player position upon pressing the "w" or forward key. The negative of that vector is of course used for the "s" or backward key. For "a", left, and "d", right I use the normal of the direction vector. (I am aware that this would let the player fly, but that is not a problem at the moment)
Upon moving the mouse, the direction vector will be rotated using trigonometry and matrices. All vectors are, of course, normalized for easy speed control.
Is this the common and/or good way or is there an easier/better way?
The way I have always seen it done is using two angles, yaw and pitch. The two axes of mouse movement correspond to changes in these angles.
You can calculate the forward vector easily with a spherical-to-rectangular coordinate transformation. (pitch=latitude=φ, yaw=longitude=θ)
You can use a fixed up vector (say (0,0,1)) but this means you can't look directly upwards or downwards. (Most games solve this by allowing you to look no steeper than 89.999 degrees.)
The right vector is then the cross product of the forward and up vectors. It will always be parallel to the ground plane since the up vector is always perpendicular to the ground plane.
Left/right strafe keys then use the +/-right vector. For a forward vector parallel to the ground plane, you can take the cross product of the right and the up vectors.
As for the GL part, you can simply use gluLookAt() using the player's origin, the origin plus the forward vector and the up vector.
Oh and please, please add an "invert mouse" option.
Edit: Here's an alternative solution which gets rid of the 89.9 problem, asked in another question, which involves building the right vector first (with no pitch information) and then forward and up.
Yes, thats essentially the way I have always seen it done.
Yeah, but in the end you will want to add various other attributes to the camera. To spell it n00b: keep it tidy if you want to mimic Quake or CS. In the end might have bobing, FoV, motion filtering, network lag suspension and more.
Cameras are actually one of the more difficult parts to make in a good game. That's why developers usually are content with a seriously dull, fixed 1st/3rd person ditto.
You could use Quaternions for your camera rotation. Although I have not tried it myself, they are useful for avoiding gimbal lock.