Currently, when I shoot a bullet is instantiated at the muzzle of my gun. Then rotated to aim at a point x distance in front of the camera. I imagine this will result in a convergence effect as shots are fired further distances resulting in extremely offset aiming.
Surely this is not the correct way to instantiate bullets in an FPS so what is the standard?
You have two options:
For very fast/instant shots- you should just check if the player "clicked" on the opponent (probably with a Raycast from the player's POV), without generating the actual shots (maybe generate something only for graphics), this way no room for mistakes in aim.
For real bullets with calculated physics- the bullet should be instantiated from the POV of the player, even one step further (or displayed when far enough) so it won't appear too big on the player's screen. About aiming, now it won't have any offset since it shot from where the player sees the crosshair, not the actual gun. You can keep the shooting animation so it "feels" like it shot from the gun.
Related
So I've made this game right here: https://youtu.be/OxJEeOTldcM
And I'm facing an issue with the maze wall's colliders where, in certain levels (not just the one I'm showing in the video below), the ball goes through the walls when it's being forced against the wall by the movement.
Here you can see what I'm talking about: https://youtu.be/dVU3LWKuXJ0
I've already dealt with this and compromised by making the maze's rotation speed a lot slower than I initially intended to. I wanted the maze to rotate as fast as the player's movement, but that made the ball go through every single wall.
So the way I'm creating these levels is this: I have these pre-made PNG mazes, I import them into the level and I apply a Polygon Collider 2D on them. But it seems like that Polygon Collider alone can not properly deal with my game's collisions.
More than this, I started layering some empty game objects with box colliders on some of these walls, trying to make them stronger. This does work, but it's still not enough, and the ball keeps going through some of them.
The ball, as well as the walls, have rigidbodys on them, and I've set their Collision Detection to Continuous, based on some answers I've seen online regarding bad collision detection. Still doesn't fix it.
I've also tried making those maze's walls thicker in Photoshop, but I can't go thicker than they're right now without ruining the space the ball should be moving in, as well as distorting the maze's look.
There has to be a way in which I can fix this bad collisions of Unity. I need the ball to stop going through walls, as this is obviously an essential part of my game.
I also want to be able to set the maze's rotation back to being as fast as the player's movement, without having to limit its speed, but honestly I'd be happy if I can just fix this collision problem with the current speed.
The most frequent cause of "clipping through walls" is not bad collisions. It's usually due to poor understanding of Unity's separation of Physics and Frames.
Unity calculates collisions and physics on a fixed update cycle, and generates frames on a dynamic update cycle based on CPU resources. These are often explicitly leveraged by FixedUpdate() and Update() in Monobehaviours.
Everything in Unity happens on one of these 2 cycles. Frame based logic like changes to a transform happen on the dynamic update cycle, and physics logic like collisions happen on the fixed udpate cycle.
You are likely rotating your puzzle using the transform. This rotation to the transform happens outside of any physics calculation, and if you rotate fast enough you can end up clipping through walls before the physics calculation has a chance to run and generate a collision. This is very noticeable when you have very high FPS (like the uncapped FPS of the inspector). However, locking your FPS only masks the issue, and the bug can still occur.
To fix your issue, I implore you to make your rotation changes to the Rigidbody2D itself instead. Something like this should work:
public class SimpleRotation: MonoBehaviour
{
Rigidbody2D rigidBody2D;
void Start()
{
rigidBody2D = GetComponent<Rigidbody2D>();
}
void FixedUpdate()
{
if(rotateRight)
rigidBody2D.rotation += 1.0f;
if(rotateLeft)
rigidBody2D.rotation -= 1.0f;
}
}
Something else important to note is that Unity only updates input on the frame, so if you read your input during the FixedUpdate(), you may double read your input (or miss it completely). It is a good idea to read your input on the Update() cycle, and set a variable to transfer logic between the methods.
So, I've made a very simple game, which all you basically do is glide through the terrain and avoid the obstacles (I haven't implemented obstacles yet). And I've encountered a very strange problem. When ever I hit the fifth chunk, the player starts to flip:
Can anybody help me find what the problem is and how can I fix it?
Edit: I solved it by using creating a physics material with 0 friction annd applied it to both the chunk and the player.
This could be an issue with your colliders being just a tad too big. check the dimensions of your player's box collider and see if it is bigger than your player. If so make it fit to just inside the outer edges of the player box. Also, unless you ever plan to flip the player intentionally, You could always just apply a constant downward force (Rigidbody + gravity usually will suffice) to keep this from happening. Hope that helps!
I am making a Multiplayer FPS using this tutorial by Brackeys and am using a rigidbody for Player movement.
If i move forwards on computer 1, then there is about a half second delay until the player stops on computer 2.
I don't know if this is normal or if it stops when you start using paid servers.
Thanks.
Play around with linear drag and drag on your player's rigidbody and see what fits your needs. Usually 999 linear drag and 1-5 drag does the job for me. Also, you should change physics material on your player's collider according to current state - if he is moving set it to zero friction, and when he is not moving - switch to max friction.
For the player you should use a CharacterController instead.
For that very reason.
The traditional Doom-style first person controls are not physically
realistic. The character runs 90 miles per hour, comes to a halt
immediately and turns on a dime. Because it is so unrealistic, use of
Rigidbodies and physics to create this behavior is impractical and
will feel wrong. The solution is the specialized Character Controller.
It is simply a capsule shaped Collider which can be told to move in
some direction from a script. The Controller will then carry out the
movement but be constrained by collisions. It will slide along walls,
walk up stairs (if they are lower than the Step Offset) and walk on
slopes within the Slope Limit.
The Controller does not react to forces on its own and it does not
automatically push Rigidbodies away.
I am making a 2D Brick Breaker game in Unity.
I have an issue with the scenario when ball hits in between two bricks. I have BoxCollider2D attached to all bricks and a CircleCollider2D attached to the ball. When the ball hits between 2 adjacent bricks, it bounces back in the same direction as if it hit the edge of the brick. There is no edge in between, but two adjacent bricks form a continuous surface. So, the ball should bounce off of the surface (in other direction) instead of bouncing back.
Anyone knows of any solution to tackle this problem? I asked this in the Unity Physics forums but didn't get any answer, so checking if anywhere here might have had this issue.
Thanks,
Mukul
I am guessing this could be the problem:
When your ball is hitting the bricks with a strong force, There is a chance it might move one of the bricks by a very very slight distance, even if the mass of the brick is much heavier.
This movement might cause an uneven surface, which is why the ball bounces back in the same direction.
Try adding a Rigidbody Component on every brick (if you have not done it already), and set its isKinematic property to true.
Let me know if this solves it.
Way 1:
Use one box collider for the wall, but not for every single brick.
This will fix your issue + will optimize your project.
Way 2:
You need to build wall programmaly and colliders in this case must be without spaces between them. This must fix the issue.
Way 3:
Make your own hitting wall logic.
OnColliderEnter you need to get balls velocity.
OnColliderEnd you need to set manually velocity.
Hello everyone I an very new to cocos2d, so I apologize if this is a simple question. I would like to create to sprites that collide when they hit each other.
For instance, one sprite, spriteA, is in a fixed position on the screen. And another sprite, spriteB, is moving around the screen. SpriteB will collide with spriteA. If that doesn't make sense or you don't understand it, tell me and I will elaborate further. Any help is appreciated. Thank YOU!
Try using Chipmunk or Box2d physics systems. These are included with Cocos2d and work by having a physics simulation that updates with every time the graphics change on screen.
The physics simulation will tell you if two objects are overlapping, and will provide physical attributes like weight, slipperiness (friction), speed and direction, which creates reactions like bouncing, sliding, realistic loss of speed and changes of direction on impact.
If you are new to physics simulation, here's a 30 second run down:
Create "bodies" in the physics simulation that represent each graphical sprite
Bodies are usually defined more simply than their graphical counterparts, like a circle, square or simple polygon shape
In order to update the graphics on the screen accurately, first you establish a pixels to meters ratio. Meters are notional (i.e. made up) measurement that is used in the physics sim
Each time the physics simulation "ticks", you update the graphics on screen accordingly
So if a body in the physics sim moves 1 meter, you might transform the pixel sprite 32 pixels
Here's a good tute on collision detection using Box2d.
http://www.raywenderlich.com/606/how-to-use-box2d-for-just-collision-detection-with-cocos2d-iphone
enjoy
Its actually very simple:
Just schedule a timer: [self schedule:#selector(checkForCollision:)];
Specify the method: - (void)checkForCollision:(ccTime)dt {}
In the curly braces, make CGRects for each sprite using CGRectMake.
Then in the same method, just call: if (CGRectIntersectsRect) {}
That easy!
Well technically speaking when the 2 sprites interact, or share at least one common point, then they are colliding. I'm a little confused by your question. Are you asking for direction on how to make the sprite move on screen, or are you asking how to handle the actual collision(such as calling a method if they collide)?