thanks for taking the time to read my question.
I'm writing a 2d top-down shooter game. It is currently using Box2d as a physics engine. The thing is, it isn't really using Box2d to it's fullest potential, just for collision detection and the underlying velocity/rotation update loop. Any plans to add real physics would simply be eye-candy, not a game changer.
Now I chose Box2d because I went through 2 other physics engines, and they just couldn't handle the types of collisions I'm detecting. I'm creating several 'bullets' with very high velocities, and I do not want them to be instant hits on their targets. JigLib and Flixel both had the same problem - bullets were not overlapping enemies at the time of the frame update, and thus were not detected as collisions (i.e. the bullets passed through enemies because they moved to fast).
I moved to Box2d because of it's iterative collision sampling, as well as the SetAsBullet method on bodies. And it works great! But now Box2d is giving me troubles too - generating several bullets per second, or at the same time, is severely lowering my fps.
So I removed Box2d to confirm that it was not a rendering limitation... added my own velocity/rotation system, and I can fire hundreds of bullets per second. Great! But its lacking any sort of collision detection.
So the questions:
1) Should I write my own iterative collision engine?
2) Should I give Box2d a try again, perhaps with some tweaks to make adding new bodies faster?
3) Is there some other alternative, maybe a lightweight physics engine that specializes in this?
4) Do you know of any other techniques or design patterns that could be of use?
Thanks so much for your help!
Edit: I should note, there are not just bullets, but larger, slower projectiles as well. I considered ray casting a line segment to the projectile's previous position, and catching intersections, but that won't work for the larger objects :(
It depends on how complex your situation can become, If you are good at math and physics you can rollout a fast engine that can handle simple collisions more faster than you can learn using box2d, but why should anyone invent the bycicle if there are plenty of them already invented so choose one you like a try using it, i recommend using box2d
Related
I'm hoping to simulate the movement of a train along a fixed path. The path itself is representable by a CGPath.
So far, I've found SKPhysicsJointSliding, which seems close, but appears to only work along a fixed axis, and since my path has curves that seems like a deal breaker.
I know I could use a series of SKActions to accomplish the movement, but in my case it's far preferable to have the physics engine handle the movement for me.
My question is basically whether or not this is something the SpriteKit physics engine can accommodate via something I've missed in the documentation (or if I'm somehow misunderstanding the sliding joint)?
Why is "physics" more preferable? Once you're on rails, you aren't really utilizing the physics engine. If you're looking for semi-realistic y-axis yaw as it rumbles down the track, try doing a random rotation about that axis.
You could also try utilizing the SKNode.physicsBody as well. According to Apple's docs, your SKNode doesn't participate in physics simulations until you attach one.
https://developer.apple.com/documentation/spritekit/sknode/1483117-physicsbody
Giving it mass and other physical properties could simulate slowing down, speeding up, etc.
Otherwise, you will have to do a lot of complicated math to apply physical forces in the direction you want the train to go.
I have found out thanks to this article: http://blog.element84.com/comparing-sprite-kit-physics-to-direct-box2d.html and personal experience that Sprite Kit is not deterministic when using physics simulations. However I was wondering if the collision logic actually deterministic when handling the node's position in a deterministic way. i.e. Repeatability works fine but my position handling.
Thanks!
UPDATE: Added more detail
In SpriteKit, physics simulations don't seem to be deterministic since they are evaluated in the game loop and depending on the frame rate of the device they can be executed at different rates. My question, is collision detection (such as the didBeginContact method) for physics bodies independent from the loop and called right after the position of the node has changed. I am trying to use only the collision properties from Sprite Kit to achieve repeatability in 2 instances that might perform at different frame rates.
Just in case this could help someone, I just found out that all collisions happen in the Sprite Kit loop, therefore they are not repeatable nor deterministic for that matter.
So.
After many years of iOS development I said it's time to try to do a little game for myself. Now I chose to do it using Apple's SceneKit since it looks like it provides everything I need.
My problem is that I've stumbled upon a huge problem (for me) and searching on Google doesn't yeld any results.
Any idea how do I go about having an object (a sphere for that matter) that deforms itself, say, because of a gravitational force. So basically it should squash on impact with the ground.
Or, how do I go about deforming it when it collides with other spheres, like a soft beach ball would?
Any starting point along those lines would be helpful.
I can post my code here, but I'm afraid it has nothing to do with my problem since I really don't know where to start.
Thanks!
Update
After doing a bit more reading I think that what I want could be doable with Vertex Shaders. Is that a right path to follow?
For complicated animations, you'll generally be better off using a 3D modeling tool like Blender, Maya, or Cheetah3D to build the body and construct the animation. Those tools let you think at a higher level of abstraction. Then you can export that model to Collada (DAE) format and then import it into SceneKit.
https://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro/Basic_Animation/Bounce has a tutorial on building a deforming, bouncing ball using Blender.
SceneKit only does physics using rigid bodies. If you want something to deform, you would have to do it yourself.
It is probably because SceneKit has no way of knowing how an object should be deformed. Should it just compress, should it compress in one direction and expand in all others to preserve it's volume, should only part of the model compress and the rest stay rigid (like the tires on a car).
What you could try is wait for a collision to occur and do the following
calculate and store the velocity after the bounce
disable collision checking on the object
run an animation for the "squash"
enable collision checking on the object
apply the calculated velocity
It will be entirely up to you how real or cartoony you want to make the bounce look.
Note: I am rather new to programming, even more-so game programming, so I apologize if my question is rather broad but it's hard to find a tutorial for this topic.
Description of Project
A simple endless side-scrolling runner similar to Canabalt where the player may tap on the screen to make the character jump. The only movement allowed to the character sprite is along the y axis.
What I Have...
A scrolling parallax background.
What I Want...
A character sprite that has a bounding box
A ground sprite that has a bounding box
A way to tell when either is touching/intersecting
A means to keep them from continuing to intersect
What I've Tried...
Ray Wenderlich's Tutorial (semi-outdated, also is tile-based which I didn't like very much and seemed quite prone to buggy-ness)
There are really two parts to my question:
For a beginner to physics, is it recommended to just stick with an API like Chipmunk or Box2D?
if first question == FALSE
What is the best way to go about building my own physics engine given the above information?
Thank you in advance for any tips/advice you may share. :)
Might I suggest using Chipmunk. Like you, I too wanted to build a game with a minimalist but efficient collision detection and force manipulation system. After loads of frustration and days wasted trying to implement some basic physics, I gave up and decided to learn an engine. Chipmunk, though intimidating at first glance, is actually very simple to learn. I have been able to use it in projects for just simple, efficient collision detection, as well as full-fledged physics-simulations.
There are a couple different versions of chipmunk (chipmunk pro, studio, etc.) that are arguably even easier to use than the original. I managed to get bye with the basic chipmunk after reading through a few code examples provided within chipmunk. Additionally, SpaceManager is a wrapper for chipmunk in obj-c that allows you to ignore all the c-based functions. It provides a lot of convenient methods for building spaces, adding bodies and sprites, and manipulating objects. It can be found here: http://code.google.com/p/chipmunk-spacemanager/
Unless you are very, very well versed in many areas of physics, don't try implementing your own engine.
I am wondering how beautiful is "Contre jour" game for IOS.
Especially i like elastic "tentacles",shown in this video on 2 min 20 seconds:
http://www.youtube.com/watch?v=ptdTdJarWLw
How can I implement such effects?
I know that there is technic called "Verlet integration" and even implementation of "verlet rope" for drawing ropes in cocos2d, but how to make such nice elastic effects to "tentacle" sprite?
I have experience of box2D usage, and may try to implement physics for this effect, but cann't find a solution how to draw sprite with such elastic morphing.
Can anybody help me or give some hints?
Just even explanation of technics, that can help me?
I have a little of experience in opengl, great cocos2d experience, so I plan to use cocos2d.
Sorry for bad english, I hope, you will understand my problem:)
If you use Box2D, you could try a distance joint with the frequencyHz and dampingRatio options set to non-default values. Perhaps a low frequency of around 4-6, and a damping of around 0.5-0.7 could be a good point to start from. You could think of frequency as how many times per second the joint tries to correct the distance, and damping as how well the distance is corrected each time. Setting the damping to a value lower than 1 will means the joint will be slower to correct the distance, and it will have a springy/rubbery behavior.
As for rendering, you could indeed use verlet integration for this. Take the two anchor points of the distance joint as the endpoints of the 'rope', and put a handful of points (doesn't look like too many would be necessary) in between them in an evenly spaced line. Every timestep, the points in between will simply move towards the average of the two points on either side of themselves. You could make the rope look tighter or looser by adjusting how far the inbetween points move to the target position each time step.
The final texture/sprite rendering would then take its position from the current location of the verlet points.