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).
Related
I've done some research and it seems the consensus is that two particle systems can't collide in unity.
Is there a creative work around or solution to have the effect of having two particle systems collide? I want it to behave like two "streams of water" colliding where each stream is a particle emitter. I can't think of a great solution besides making my own particle emitter, but even then it would be hard to mimic Unity's particle system behavior. I feel like there has to be a way to make that effect though.
Any ideas appreciated, thanks
Create a GameObject--the emitter--that spawns other GameObjects--the water particles--that have Rigidbody/Rigidbody2D and appropriate Collider components. The exact components you will need will depend on the shape of the spawned object.
To avoid performance loss related to instantiating and destroying many objects, you may want to use object pooling for the water particle GameObjects.
In these water particle GameObjects you'll want to implement OnCollisionEnter or OnCollisionEnter2D to handle the interaction between them. You can check for whether the collision is with another water particle inside of OnCollisionEnter*, and interact appropriately.
I am working on a 2D game that involves many blocks that stack and collide on eachother and the player. I am currently using Rigidbody2D on the blocks for dynamic collisions but I am not a fan of how the dynamic physics include the "bounciness" in the elastic collisions. Also, there is an inherent push-force as well as other unfavorable push physics that are too "realistic".
I am wondering what is the best way to handle my predicament to remove the bounciness and push elements of the rigid bodies. I've tried adjusting the block's masses and bounciness physics but no luck. Is there a way to set them all as kinematic or disable these realistic effects somehow and still have them collide via rigidbodies? (Kinematic would be great if they were able to collide with each other) Or will I have to create some sort of raycast based block physics handling script? Or is there an even better solution to creating this very primitive physics structure that I am not seeing?
Thanks for any and all help!
The only way I could think of solving your problem, such that you have complete intuitive accuracy, is to write your own Rigidbody controller. Of course you can still reuse the Box colliders.
Once you've decided on a collision detection method and manifold generation working (raycasting maybe), this link details the impulse resolution you need.
I am currently using SpriteKit to create a Flappy Bird style game. I want the game to speed up under certain conditions, to make the game more difficult. At the moment, I am doing this via incrementing self.speed.
This works well for speeding up the game, but the issue is that the physics on the main character do not change, so if the character jumps up, they jump and fall the same as they would before the speed up.
This means the rest of the game-world is swept beneath their feet at high speed, allowing them to clear several obstacles on the path much easier than before.
Effectively, I need a way to change the physics, so that as it speeds up, the character's jump-arc stays relative to the objects on the screen.
Any advice on this would be great, thanks.
Use the physicsWorld .speed property to adjust the timing of your engine.
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.
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.