I'm trying to create simple game where you jump around with ropes hooking to flying islands. I want islands to just float and when hooks himself to this island he begins to pull it to himself, but he is also able to swing on it. After he releases the rope islands slows down and stops (but I guess this is done by the rigidbody drag). Can you tell me how this script could work because I don't have any good idea of doing this.
You should disable gravity for the islands' rigidbody, first of all. That way, they will float, but things like inertia will still apply.
If you want your character to pull the islands to himself when grabbing them with a rope, you could use Rigidbody.AddForce(Vector3 vec3) and pass the vector opposite to the direction the rope is aimed at as a parameter (you should use Vector3.Reflect() to do that.)
This will get you started, but there are more ways to improve the effect, such as making the islands gradually slow down after pulling them. I'd suggest multiplying the island's velocity by a fraction of 1, in that case, but there are other ways to do it.
Related
I'm creating a penny pusher (like the game machines you find in arcades) game in Unity in my spare time and obviously that means I need to populate the shelf with coins so the player's spawned coins actually have function.
My issue is I haven't worked out how to spawn that many coins in an elegant way which won't either slow the game down with spawning so many objects at once or result in a lumped pile of coins rather than the neat spread I need.
I even tried speeding up the simulation by several times and dropping a pile of coins on the pushing shelf so they would "settle" before the player input was enabled. It didn't work.
So I ask if there's a good way to do this as part of the initialisation of the game and any Unity or C# function which would have the intended effect.
Thanks in advance.
If I understand your request correctly it really does dependent. The problem is that your game will be lagging when you have to many physic interactions. So even if you spawned them without alot of physic interactions, once u move one coin it will start lagging.
I would look for an alternative way then physics to handle them. Maybe you can think of a more simple calculation you do your self where you have less interactions going on each frame.
That beeing said a way to spawn the coins would be to calculate a random position at a fixed height (max height) and then find out what the lowest point is where the coin can sit on (so it does not share space with another coin). Now place it there. Even better would be to calculate if it could actually be placed there without instanly falling.
I think the best way would be having predefined "Coin Towers" (prefabs of them) where you have like 10 variations and then place them at different positions but do not allow to spawn any "Coin Towers" on another one. This would result in less physic interactions when spawned too.
May be helpful too: https://www.youtube.com/watch?v=pTz3LMQpvfA
I am experimenting with the terrain tools. The app has a cube (0.2x0.2x0.05) that flies around representing a quadcopter. It has a collider (not set as trigger) and rigidbody. It is controlled by addforce() etc - ie its position and rotation are not changed directly.
It works quite reliably in scenery constructed from primitives (cubes, spheres etc).
I am now trying out the Unity terrain tools package (I'm using editor 2019.3) and have a simple test terrain (500x500m) with rock, scree and sand layers.
What I find is that sometimes when flying it directly into the terrain just to check what happens, it goes straight through. Often it collides OK, but not always, maybe 50:50.
The FixedUpdate() rate is the standard 20mS.
I'm not sure if there is any step I have missed? I am just using all default settings on the terrain. It has the standard mesh collider. It isn't set up just as a trigger or anything (anyway, mostly it works OK).
Is this something I've done / not done, or is this a known issue - is there a workaround?
STOP PRESS: Testing still in progress, but have a feeling this may be to do with the collision type selected in the rigidbody - see answer below.
Testing still in progress, but it strongly appears this is be to do with the collision type selected in the rigidbody. Default is discrete, but there is information in the Unity docs that with fast moving bodies, it may be necessary to use continuous (at some CPU cost) to avoid missing some collisions.
The problem has not happened since the type was changed to continuous.
The quadcopter is after all, quite a fast moving body, up to 150 kph, and small.
I've put together a little Git repo to share with you some scripts from the Unity 2D platformer I've been working on. I have written some basic WASD movement control in the Movement.cs script (under Scripts/Character in the repo) and it is working really well. It does everything I need it to do, and while it is basic, I intend to polish it up a bit over the course of the development of the game. However, I've been noticing that every time I build the game, every moving entity moves at a faster speed. The "AI" (yes I use the term very loosely) that I programmed into enemies like the Chompas and BadBirds seems to be far too fast or far too slow, as are user-controlled movements and animated powerup bubbles.
Now, I believe I've traced it back to the way I create translations; I add vectors to Transform.Position whenever I need to move an object or entity. These vectors accept float values as their parameters, and seeing as I'm not entirely clear on what those values represent, I feel that may be where the issue lies. Are these distance values representative of some dynamic system of measurement that might be changing between builds? If so, how might I standardize my distances? Am I totally off the mark? Lol. Any and all help is greatly appreciated.
To be perfectly clear, this issue occurs every time I hit play, regardless of whether or not changes have been made. Thanks again!
Git repo
Try multiplying your movement by Time.deltaTime.
If you don't do this (which it doesn't look like you are), then all your GameObjects will move at inconsistent speeds. The reason for this is that void Update() get's called once every frame, and the amount of frames that get drawn every second is variable (sometimes your game will run a little faster than at other times), and so your speed will be variable if you don't multiply it by Time.deltaTime (Time.deltaTime is the amount of time that has passed since the last frame, see the documentation)
Another option is to use Unity's built in physics system with FixedUpdate(), which get's called at a fixed rate.
I would strongly recommend to follow online tutorials for how to make a platformer controller etc., such as this one. Doing this will help teach you good practices and how to avoid common errors.
I have a custom mesh I've created for a game object. I want to do some actions when it touches itself. I tried attaching the collider and the script to the mesh. However the script is called only when colliding with other objects. How can I detect colliding with itself?
In a game physics engine, such as PhysX: there is no meaningful sense in which a collider can collide with itself.
Note that, in games and 3D engineering, "things" almost always have more than one collider.
For example, a doggie might be made of, oh, seven or so colliders (you can imagine one for the torso (perhaps a sphere there), four legs (probably capsule or just rectangle), one for the head (spehere again), and if relevant in the game one for the tail (probably just a rectangle - or maybe two small spheres). For a car, you might have say three boxes for the overall shape of the body, and you likely have individual colliders for "where you need to know what hit" ... eg, the bumpers, maybe the doors if you expect it to be bashed there, and so on.
Now,
regarding your question, it looks like you have -- for example -- a humanoid, which would have a number of colliders as described in the previous paragraph.
It could be that, for example, the arm collider can hit the leg collider, and you want to know that.
It is impossible to help you with your question, unless, you explain what your scene is in general terms...
--
If you're making a snake or perhaps rope, do what Gunnar said. The simplest solution is a number of sphere colliders.
Quite simply say your snake is 10 centimeters thick. Say your snake is 2 meters long. Quite simply have sphere colliders about 9-10 cm in size. Separate them so they are not touching one another but a bit spaced. So for 2m you might have about 15 of them. That's all there is to it.
Please note that engineering ropes / snakes is far from easy.
I encourage you to glance at the AssetStore and look at the may excellent rope/snake packages available.
Realise that it can take man-years of engineering to develop a perfect rope system.
Understand that an everyday aspect of Unity (or game engineering in general), is that you have to use an existing, often well-known solution, for the problem at hand. Good luck.
Here's my problem. I'm creating a game and I'm wondering about how to do the collisions. I have several case to analyze and to find the best solution for.
I'll say it beforehand, I'm not using any third party physics library, but I'm gonna do it in house. (as this is an educational project, I don't have schedules and I want to learn)
I have 2 types of mesh for which I have to make the collisions for :
1) Static Meshes (that move around the screen, but does not have ANY animation)
2) Skinned/Boned Meshes (animated)
Actually I have this solution (quite hacky :|)
First of all I have a test against some bounding volume that enclose the full mesh (capsule in my case), after :
1) For the static meshes I divide them manually in blocks (on the modeler) and for each of these blocks i use a sphere/AABB test. (works fine, but its a little messy to slice every mesh :P) (i tried an automatic system to divide the mesh through planes, but it gives bad results :()
2) For the animated mesh ATM i'm dividing the mesh at runtime into x blocks (where x is the number of bones). Each block contain the vertex for which that bone is the major influencer. (Sometimes works, sometimes gives really bad results. :|)
Please note that the divide of the mesh is done at loading time and not each time (otherwise it would run like a slideshow :D)
And here's the question :
What is the most sane idea to use for those 2 case?
Any material for me to study these methods? (with some sourcecode and explanations would be even better (language is not important, when i understand the algorithm, the implementation is easy))
Can you argument why that solution is better than others?
I heard a lot of talk about kd-tree, octree, etc..while I understand their structure I miss their utility in a collision detection scenario.
Thanks a lot for the answers!!!
EDIT : Trying to find a K-Dop example with some explanation on the net. Still haven't found anything. :( Any clues?
I'm interested on HOW the K-Dop can be efficiently tested with other type of bounding volumes etc...but the documentation on the net seems highly lacking. :(
Prior to doing complex collision detection you should perform basic detection.
Using spheres or rectangles as bounding volumes is your best bet. Then if this detects a collision, move onto your more complex methods.
What I'm getting at is simple is often better, and quicker. Wrapping bounding volumes and splitting meshes up is costly, not to mention complex. You seem to be on the right track though.
As with game programming there are multiple ways of collision detection. My advice would be start simple. Take a cube and perfect your routines on that, then in theory you should be able to use any other model. As for examples I'd check gamedev.net as they have some nice articles. Much or my home made collision detection is a combination of many methods, so I can't really recommended the definitive resource.
The most common approaches used in many current AAA games is "k-DOP" simplified collision for StaticMeshes, and a simplified physical body representation for the SkeletalMeshes.
If you google for "kDOP collision" or "discrete orientation polytopes" you should find enough references. This is basicly a bounding volume defined of several planes that are moved from outside towards the mesh, until a triangle collision occurs. The "k" in kDOP defines how many of these planes are used, and depending on your geometry and your "k" you can get really good approximations.
For SkeletalMeshes the most common technique is to define simple geometry that is attached to specific bones. This geometry might be a box or a sphere. This collision-model than can be used for quite accurate collision detection of animated meshes.
If you need per-triangle collision, the "Separating Axis Theorem" is the google-search term of your choice. This is usefull for specific cases, but 75% of your collision-detection needs should be covered with the above mentioned methods.
Keep in mind, that you most probably will need a higher level of early collision rejection than a bounding-volume. As soon as you have a lot of objects in the world, you will need to use a "spatial partitioning" to reject groups of objects from further testing as early as possible.
The answering question comes down to how precise do you need?
Clearly, sphere bounding boxes are the most trivial. On the other side of the scale, you have a full triangle mesh-mesh collision detection, which has to happen each time an object moves.
Game development physics engine rely on the art of the approximation(I lurked in GameDev.net's math and physics forums years ago).
My opinion is that you will need some sort of bounding ellipsoid associated with each object. An object can be a general multimesh object, a mesh, or a submesh mesh. This should provide a 'decent' amount of approximation.
Pick up Christer Ericson's book, Real-Time Collision Detection. He discusses these very issues in great detail.
When reading articles, remember that in a real-world game application you will be working under hard limits of memory and time - you get 16.6ms per frame and that's it! So be cautious of any article or paper that doesn't seriously discuss the memory and CPU footprint of its algorithm.