I really hope someone understands what the effect is that I am asking for. Have you ever played the games where a character is sliding one way and when you try and change the characters direction it is not immediate as they need to slow down in the initial direction before they can start sliding the other way? The new game on the App Store 'Swing Copters' by the maker of Flappy Bird is exactly the effect I am talking about. Can someone please help me create this effect in SpriteKit. I have already tried achieving it by applying different forces but I am either not doing it correctly or the effect isn't possible with forces.
Thanks in advance!
Maybe you want to try working with some acceleration-stuff.
Let's think about the gravity on the earth (a = 9.81 metres/s²). If you throw a ball straight to the sky, the Ball is starting with a velocity of: lets say 5metres per second(positive velocity).
After a short time, the gravity is pulling the velocity of the ball down to 0, so the ball can't get any higher. Right after this, the gravity pulls the ball down until it hits the ground. (Negative velocity)
If we're talking about this in a game, where the ball doesn't move up or down but from left to right, you can use something like this. The moment when you throw the ball, is the moment in the game where you send the command to change the direction. The ball keeps going in the direction where it used to go, gets slower, stops, changes the direction and finally gets faster and faster until you send another command to change the direction again(Or it hits the Wall/the ground). In that case you have to inverse the acceleration you want to use, so the whole thing repeats in the other way.
If the ball should move to the right, positive acceleration,
if the ball should move to the left, negative acceleration.
As formula you can use something like
v = (int) (a * t + v0);
v0 = v;
v is the next velocity, a is the acceleration you want to use, t is the spent time and v0 is the current velocity. t should count the nano-time since the last direction-change. (int) casts the whole thing to an integer, so you can use this directly to move the ball/graphics on the screen.
Repeat this each frame.
For the direction change you can use
t = 0;
a = a * (-1);
t has to be 0 again, otherwise it gets buggy.
I hope this was helpful.
Related
i'm new in the development of swift ios game using spirtekit and i need help. I want to develop a vertical 2d endless run, where with a swipe you are able to move the player in direction and if there is an obstacle, it is created in a position calculate with the position of the player. Once create the obstacle i would like to make it falling down but alway with the same relation with the player (this means that it has to move only on y axis).
Can you suggest me some ideas on how to manage this?
This book teaches you exactly how to make what you are looking for:
https://www.amazon.com/Getting-Started-SpriteKit-Jorge-Jordan-ebook/dp/B01891X7TM
This is the end product:
https://itunes.apple.com/lr/app/inside-the-hat/id1076967804?mt=8
You can get it for free here (with trial):
https://www.packtpub.com/application-development/getting-started-spritekit
The source code for this is around somewhere on the web, but I forgot where :( I bought the book a year ago and can't find it now.
Basically, you have a long background that is .moveTo .. in .update you check the position of the background, then reset it based on its XY position (it basically just goes all the way down, warps to the top position, then falls)
Also in .update you check for score, or a timer, or just a random check, then spawn an enemy, obstacle, etc. You give the enemy / obstacle SKActions to move towards the player, and let .didBegin(contact:) handle scoring, sound effects, death, etc.
I have made a game using SpriteKit and Swift 3 and have figured out all aspects of the game except the speed of the ball node in the game. Im confused with the different function applyImpulse() and ball.physicsBody.velocity, as I have tested both and don't seem to really understand what the speed I'm actually programatically settings is. Any clarification on what I should be using would be great?
Also whilst testing (by printing the ball's velocity to the console every collision) I would see sometimes the ball's speed would simply go to some long and random decimal value when it hit other nodes such as a paddle which I hadn't specifically coded anything to happen with the ball's speed in the case of a collision with it.
In summary I would appreciate:
Just general clarification regarding speed of the ball in SpriteKit and how I should approach it (what method/function I should use)
How I would make it so the ball's speed doesn't got to these very long random decimals
Thanks
In regards to the values, there is not really a set rule of what the values are for impulses and forces. It depends on how big your sprites physics body are etc. An impulse of 80 might be a perfect jump value for 1 sprite size, but than make it half the size and that 80 is suddenly way to high. There are also factors such as gravity, mass etc than can have an effect on this.
So you usually just play around with the values until you get the desired result.
In regards to the collision with the paddle, you need to check your bit mask values and your dynamic properties. SpriteKit by default sets collisions to all objects, so if you dont specifically tell your paddle/ball to ignore each other they will collide.
There are also things such as restitution, friction, damping etc that can have an effect on how you sprites behave when colliding.
There are loads of tutorials on google about SpritKit physic/collisions or read the apple documentation.
In regards to the difference between velocity and impulses/forces, as per apples documentation
"First, you can control a physics body’s velocity directly, by setting its velocity and angularVelocity properties. As with many other properties, you often set these properties once when the physics body is first created and then let the physics simulation adjust them as necessary. For example, assume for a moment you are making a space-based game where a rocket ship can fire missiles. When the ship fires a missile, the missile should have a starting velocity of the ship plus an additional vector in the direction of the launch.
When a body is in the simulation, it is more common for the velocity to be adjusted based on forces applied to the body. Another source of velocity changes, collisions, is discussed later."
https://developer.apple.com/library/content/documentation/GraphicsAnimation/Conceptual/SpriteKit_PG/Physics/Physics.html
So basically the general rule of thumb is this:
1) Only set the velocity property when you create the physics body. I never needed to do this for my games yet.
The only time I really use the velocity property is for things such as double jumping where I need to set it to 0 to have a consistent double jump
...velocity.dy = 0
...applyImpulse(
2) When you are playing the game already than
a) If you are trying to continuously move your ball you should use
applyForce...
in something like the update method of your SKScene.
b) If you want to make your ball jump, so basically a short 1 time thing, you should use
applyImpulse...
Hope this helps
So I'm making a brick break style game using "Ray Wenderlich's amazing tutorial" in Spritekit/Swift, just like the tutorial.
I successfully have a ball bouncing around the screen using a SKSpriteNode() and SKPhysicsBody() and I've been tweaking values for the impulses used to begin the ball bouncing around the screen forever.
However, I stumbled upon a problem which I hope to find a solution.
Sometimes, in my game, the Sprite will bounce around and become "Wall Locked" bouncing almost Perpendicular (or straight) between two walls, (give or take a few pixels)! So ends up Zig-Zagging across the whole screen between two said walls for ages.
What I want to do is, should this happen and the ball get "Wall Locked" to introduce a new impulse to get it moving again...
How can this be done? For example, if it has bounced between the top and bottom walls 10 times, then it's time to adjust it's angle/introduce a new impulse.
Could the last 10 positions be stored in an array, then test if their almost perpendicular somehow?
If you inspect the velocity property of your Sprite, you could detect when either of its values is close to zero and then make them something that is not so close to zero. This would stop it getting stuck moving just horizontally or vertically.
I am making a game using cocos2d and SpriteBuilder. There is a hero sprite and coins, that should be collected by him. That's a horizontal scrolling game, so every time hero touches a coin, this coin changes it's x-coordinate 2000px to the right and new y-coordinate is generated at random. Using update method I move it to the visible area as a "new" coin. But when hero flyies by and doesn't collect it ,coin must change coordinates only when it's already off the screen, so I tried this solution:
-(void)update:(CCTime)delta{
_coin.position=ccp(_coin.position.x - delta * scrollSpeed, _coinY);
if (CGRectIntersectsRect(_hero.boundingBox,_coin.boundingBox)) {
_coinY=arc4random() % 801 + 100;
_coin.position=ccp(_coin.position.x + 2000.f,_coinY);
}
else if(_hero.position.x >= _coin.position.x + 150){
_coinY=arc4random() % 801 + 100;
_coin.position=ccp(_coin.position.x + 2000.f,_coinY);
}
It works,but after that I found a small bug(I am not sure, whether it's related to this code) : sometimes, when hero touches coin, hero is like pushed away to the left. I have no idea why.
How to fix it?
Is that way, that I am using for coin ,right?
I see 2 issues with your approach:
1. Hero bounces of the coin.
To fix this you need to make your coin a sensor. This way you will still be notified about collisions, but the hero will simply pass through the coin without actually hitting it.
I'm not sure if you can set this in SpriteBuilder, but probably you can enumerate all coins after loading the scene and set sensor property to YES:
coin.physicsBody.sensor = YES;
Things like this is one of the reasons I believe you first need to learn pure Cocos2D and only then use tools making your life easier such as SpriteBuilder. Which is a great tool, but in some cases you still need know what happens behind the scenes.
2. You're mixing physics with things like CGRectIntersectsRect
If you're using physics engine you need to detect collisions via collision delegate and not by checking CGRectIntersectsRect in update:.
It is hard to explain how to do this in a few sentences, so here is a nice tutorial that shows how to detect collisions in Cocos2D v3 and of course there is a chapter about this in my book.
By the way you shouldn't use update:at all when manipulating physics nodes, use fixedUpdate: instead.
I hope this will help you to solve your issue.
I have tried many different techniques of applying a realistic looking gravity feature in my game but have had no luck so far. I plan on offering a 100 point bounty on this for someone who can show me or (share) some code that applies gravity to a CCSprite in Cocos2D.
What I have done so far has just been ugly or unrealistic and I have asked in many different places on what the best approach is but I just have not found any good looking gravity techniques yet.
Anyway, can anyone offer some tips/ideas or their approach only applying gravity to a CCSprite in Cocos2D without using a physics engine?
Thanks!
A effective approach without having to explicitly use any physics engine is to step the velocity and position of your sprite manually in your update loop. This is essentially Euler Integration.
// define your gravity value
#define GRAVITY -0.1
// define a velocity variable in the header of your Game class/CCSprite Subclass (neater)
float velocity_y;
-(void) update: (ccTime) dt
{
// Step the y-velocity by your acceleration value (gravity value in this case)
velocity_y += GRAVITY *dt; // drop the dt if you don't want to use it
// Step the position values and update the sprite position accordingly
sprite.position.y += velocity_y* dt; // same here
}
In the code snippet above, I defined a velocity_y variable to keep track of my sprite's current velocity along the y-direction. Remember to initialize this value to 0 in your init method.
Next comes the crux of Euler. At every time step:
Advance your velocity by your acceleration (which is your gravity) multiplied by dt to find your new velocity.
Advance your position by your newly computed velocity value multiplied by dt to find your new position.
You can experiment whether using delta-time or not (see LearnCocos2D's excellent comment on the cons of using it) works for your game. While multiplying by delta-time allows your object motion to more accurately take into account varying framerates, as LearnCocos2d pointed out, it might be wise to avoid using it in a real-time game where system interrupts (new mail, low battery, ads pop-out) can occur and subsequently cause the game simulation to jump forward in an attempt to make up.
So if you are dropping the dt, remember to tweak (scale down) your GRAVITY value accordingly to retain the right feel, since this value is no longer multiplied by the value of delta-time (which is ~ 1/60).
Aditional Tip: To apply an impulse to move the sprite (say via a swipe), you can affect the velocities directly by changing the values of velocity_x (if you have this) and velocity_y.
I have used this approach in my games, and it works very well. hope it helps.
This isn't trivial matter, you should try to see other posts. I'm sure other poeple already had this issue. Try to look at :
How to simulate a gravity for one sprite in cocos2d without a physics engine?
Cocos2D Gravity?
Or try our good friend google :
http://www.gamedev.net/page/resources/ -> got to Math and Physics and then A Verlet based approach for 2D game physics
http://www.rodedev.com/tutorials/gamephysics/
In any case here are some tips :
Step 1, calculate the effective direction vectors
Step 2, calculate velocity
Step 3, project this velocity onto the two effective directions.
Step 4, generate an equal and opposite force for the two direction and call this the “response force”.