i have a 2-d fruit ninja style iOS (swift 3) game where an animal eats the "enemy" sprite.
currently i can detect a collision between the mouth and the enemy and cause the enemy to disappear with an animation.
however, i would like to implement a more realistic effect where the enemy sprite disappears into the mouth by occluding an increasing portion of the enemy as it moves further into the mouth.
i tried using combinations of masks and layering, but they were hacky and compromise the UX. what would be the most elegant approach to achieving this effect?
current/non-preferred example:
ideal/preferred example:
Related
I am making a game in Swift(SpriteKit) and when the character in the game picks up a power-up, I want him to get an outline in purple so the player can see that his power-up is ready to use. I want the outline to hug all the curves of the player exactly. Is there any way to draw an outline around a sprite node that isn't a basic shape(like circle or square) but to outline a complex shape?
Here is an example of a shape similar to my sprite node:
And here is another example of the player with the visual outline that I want to add in SpriteKit(I just sketched it but I want it to be exact obviously):
They player also has his legs animating by flipping through an atlas of the animation, and preferably the outline would stay around the legs when the walking animation is happening. Is this possible?
To be clear, I just want an outline for visual purposes, so the player knows their "power up" shield is active so if they get hit it won't damage them.
I haven't dabbled with SpriteKit for a few years, and if memory serves me correctly perfect collision detection while animating is not available out of the box.
After checking the documentation I see that SKPhysicsBody has a init(texture:size:) initializer. This should at least get you a bit closer.
This guide from Apple is probably worth a read. (Pixel perfect collision detection is expensive).
I've started learning sprite kit and I think I've got the basics but now I'm struggling with something.
I want to create a game that has a 'Streets of rage' type feel to it whereby the user can move up and down, but isn't jumping, they're still on a 2D plane. But I also want them to be effected by gravity e.g stairs etc. like the following picture.
Am I right in assuming that I should have my background image with colliders around the blue and brown edges, and then create a physicsbody collider located at the feet of my player/players so that it looks like they can move against the background, but when their feet reach the top it would stop?
Could I then place other obstacles like rocks etc on that path that they would be able to collide into, but that could also sit over the path and the sky? How would I handle the fact that these could be constantly colliding depending on the position?
I appreciate there isn't any code here, but I'm trying to understand the concept around this before I jump in coding a solution.
Thanks
I would use a categoryBitMask to separate the different planes of objects.
And I would play with collisionBitMask/contactTestBitMask depending from the plane the player is in, in addition to the z-order.
Thus you can have a rock that collides your player if they are both in the same line else the player would walk behind/front.
I have a particle emitter and I would like to detect it when the particles collide some physics bodies.
Is there a native way to do that in the SpriteKit API or do I need "to cheat" ?
Individual particles can not collide. Not with physics, not any other way. You do not even get any information about an individual particle - you can't access it's position, rotation, velocity .. nothing.
If you wanted to "cheat" you'd have to emulate the particle emitter using sprites, and animate the sprites with actions or manually. However keep in mind that this is much less efficient than a particle emitter.
In addition, if we're talking "particles" which often means dozens or even hundreds of them on screen, the amount of physics processing and collision detection quickly becomes prohibitively expensive if you were to model them using sprites with physics bodies attached. Do a performance test before you go down this path.
Particles do not have physics bodies, so they don't collide with Sprite Kit's physics engine
You can set the physics body of the particle emitter the same way you set it for any sprite node. Then you can set the category bit mask property and the contact test bit mask. The method didBeganContact can detect the collision afterwards.
didBegan contact is called whenever two bodies contact each other . Here is the apple reference link for how this method works:
Click [here](https://developer.apple.com/library/ios/documentation/SpriteKit/Reference/SKPhysicsContactDelegate_Ref/Reference/Reference.html#//apple_ref/occ/intfm/SKPhysicsContactDelegate/didBeginContact:"Apple iOS developer library")!
I have two sprites, a ball and a wooden plank. If the ball falls off of the wooden plank the ball is supposed to simulate falling.
My problem is, how do I determine if the ball isn't touching the wooden plank? Should I just created edges around the plank and if the ball collides with them then it scales the ball?
There are multiple planks that are attached together.
Does anyone have an idea on how to accomplish this?
Edges around the plank would work but a simpler way would be to use the collision callback's EndContact to determine when the ball and plank separate. However if the ball is allowed to bounce a bit while still over the plank and not be considered to have fallen off, you will need to check the position of the ball as well. If that is the case then placing some other sensors in the fall region might be more reliable.
What's the best method for pulling back to show more of a view in a 2D OpenGL iPhone game? For instance, in Tiny Wings, when the bird flies toward the top of the screen the bird and the scenery pull back to simulate the bird going higher in the sky. Would this effect be better achieved by scaling all the sprites proportionally, or by using glOrthof? In any case, I'm assuming that the zoom-out factor is inversely proportional to the player's y position.
You almost certainly want to use glOrthof so all you're changing is how the camera sees the scene. This avoids recomputing all the normals and such in the scene, saving quite a bit of work. It's also easier for you to implement.