What would be the best way to go about adding collision to my application. Right now I have a lot of jagged walls and a couple of weird shapes that I wanna make collision for but am not sure which is the right path to get the job done. What would you guys do if you had a room full of walls with different shapes and sizes that needed collision implemented ?
I would read a set of articles on collision detection. Paul Nettle used to write about the topic (PDF) and has a nice library for free.
This document will describe a
collision technique that allows you to
move an ellipsoid (a sphere with three
different radii, one for each axis)
through a world that not only properly
detects collisions, but also reacts in
a way that gamers would expect from
the common first person shooter.
This technique also allows for sliding
along surfaces as well as easy
implementation of gravity, which
includes sliding downhill when
standing stationary. This technique
also allows automatic climbing of
stairs and sliding over bumps in walls
(like door frames) and any other
randomly oriented “stair-like
topography”.
You can use Chipmunk physics engine, which has a very good physics + collisions.
Or even Cocos2d-iphone library - 2d game engine with Chipmunk inside. Here are examples of games, created with it.
Related
So, I'm working on a game and I've run in to the problem that.. I'm trying to detect the collision of two objects, and at first I assumed I needed two colliders. Then I found out I needed a rigid body, now I've come to find both object need a rigid body and this is a lot of cpu usage and the rigid bodies serve only to detect these collisions. It vastly limits how many objects I can have in a scene.
The only solution I can thin of is to be cast small rays from each side. Are there any other industry standard solutions that are more optimal?
Thanks in advance
There's no way to do exactly what you want. As you did not describe what you are planning to do (not even if 2D or 3D), here's a generic solution:
1) Attach a Rigidbody to only to one of the objects (out of two which could collide)
2) Tick in IsKinematic on Rigidbodyso it won't react on Physics
3) Tick in isTrigger on the other object's Collider (so it won't need a Rigidbody yet fires away trigger events when hits another object with a non-trigger(!!!) collider (and a Rigidbody)
(Or use Rigidbody on all your GOs, yet tick in IsKinematic on all of them)
As of your own collision detection, see #Hellium's comment.
I would add that, if you code your own collision detection, at the end of the day you'll most probably end up with a code eating more calc. time (and probably being at least a bit more sloppy).
Simply because you'll code in script, not C++ and the engine's Collision Detection is C++. (Your .net script will compile to native via il2cpp, so not a native implementation == must be slower than the code having similar nature, yet supported by the engine, i.e. coded in c++)
Side note: If you find your app. running slow, that's not necessarily because of collision detection. It's not impossible it's your code, what you do when you detect collision is running slow.
I highly recommend using the profiler to see what slows things down in your application.
If it really is your code, post a question on how to make that run faster.
I read that using a physics engine can be the cause of many problems in programming platformer type of games.
I am making something similar to the platformer game(not a classic platformer).
Game will have a platforms, but not many.
Game will not have moving platforms
Game will not have slopes
Game will have ladders
Hero can shoot the enemies
Hero can jump
Hero can access ladders from the air
I have to choose between physics engine and tile tehnique...
The first problems I can think of are:
problem with physics engine and the ladders because physics rules are applied to hero and his movement,so I guess it would be hard to get him on the ladders while his physicsBody.dynamic property is set to YES.
problem with the tile tehnique - how to make hero falling from the ledge(while running) with an realistic arc (when we use physics this is done by engine itself...)?
And the main problem, based on the type of the game I am making, is, sholud I combine tiles tehinque(let's say for hero's moving) and physics engine for collision detection, and shooting enemies?
I know there are a lot of questions about this subject, but I must start from something...
Tnx in advance
I would recommend the physics engine. It is very straight forward... what you expect is generally what happens.
Run, Jump, Shoot, Fall, etc. - Very easy to do using the physics engine.
Ladders will be problematic but you could set a bool flag that lets you know when the ladder and hero are touching, therefore allowing you to exhibit different behaviors depending if this bool is true or not. Ex. Make hero not affected by gravity if touching a ladder.
It is very smart that you are planning this out ahead of time and have outlined all of your core requirements. IMHO, the rest of the requirements will be so easy using the physics engine that it will outweigh additional time spent on the harder part with ladders.
I would advise against using a physics engine unless you have some complex physical interactions that would be difficult to code by hand, i.e. not just collision detection and basic movement but things reacting realistically to collisions, mechanical objects made of many moving parts and joints, etc. I'm not sure what you mean by a "tile technique", but you can easily code by hand things like a character accelerating towards the ground while maintaining forward momentum (i.e. tracing an arc).
i want to detect collision detection two times in same row.
for example:-(see the below image)
the ellipse and rectangle or detcted. after that my ellipse will travelling in the straight line path to down and detect the another rectangle.
first one is( travelled in trajectory path ) working fine. second one i want to pass in straight line to down for collision detection.
how to do this process.
Use the Box2D physics library for collision detection. It is by far the best option in your case and elegantly supported in Cocos2d.
See here: http://www.raywenderlich.com/606/how-to-use-box2d-for-just-collision-detection-with-cocos2d-iphone
As i know cocos2d have no collision detection of sprites because it's not a phys engine. If you want the collision be detected automatically use Box2D or chipmunk physics engine, supported by cocos2d.
If the number of object you want to check for collision is small you can just run over your object and check if some of them (or only one if it's enough for you) overlaps with the others.
Making more complex collision detection will bring you for writing a collision detection part of a physics engine. It's much simpler to use en existing one
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)?
I'm attempting to build a Lunar Lander style game on the iPhone. I've got Cocos2D and I'm going to use Box2D. I'm wondering what the best way is to build the floor for the game. I need to be able to create both the visual aspect of the floor and the data for the physics engine.
Oh, did I mention I'm terrible at graphics editing?
I haven't used Box2D before (but I have used other 2D physics engines), so I can give you a general answer but not a Box2D-specific answer. You can easily just use a single static (stationary) Box if you want a flat plane as the floor. If you want a more complicated lunar surface (lots of craters, the sea of tranquility, whatever), you can construct it by creating a variety of different physics objects - boxes will almost always do the trick. You just want to make sure that all your boxes are static. If you do that, they won't move at all (which you don't want, of course) and they can overlap without and problems (to simulate a single surface).
Making an image to match your collision data is also easy. Effectively what you need to do is just draw a single image that more or less matches where you placed boxes. Leave any spots that don't have boxes transparent in your image. Then draw it at the bottom of the screen. No problem.
The method I ended up going with (you can see from my other questions) is to dynamically create the floor at runtime and then draw it to the screen.