How do I tell if an object is connected to the base object?

Greetings!

So what I am trying to do is make a kind of 3D game where your body (made of cubes) is fully breakable (like robocraft). I am not sure how I would tell if an object is disconnected from the main piece. For example, if I break the piece next to the base, it just falls off no big deal. But if I break the piece between the base and said piece, then how do I know it is disconnected?
I am using blender to model and animate the character, and I am going to have all the pieces' parent be the base piece.

Thanks!
-JupiterSky

 

I don't know anything about robocraft, but I have some thoughts that may help.

Are you reponsible for breaking the pieces? If so, you'll know because you did it.
If it can somehow happen to you, otherwise.. well, what determines if it breaks?

You could maybe use this? https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnTransformParentChanged.html

If you provide some more details, perhaps a better solution can be offered.

 

Ah, thank you, but breaking is no problem at the moment.
It is like when you take a stick, and remove a section of the middle, how do I know the side are separated if all I did was remove the center?

 

Trace debug line between connected part, if line is not there, it's not connected.

 

How many pieces are you talking about, say for a leg? Just to get an idea ...

 

From 3 to around 100. What have you got in mind?

 

https://docs.unity3d.com/ScriptReference/Transform-root.html

if two transforms have the same return value they're in the same hierarchy, if they're different they aren't... ?

 

I'm not sure you understand what I meant, but that's okay... I am having a hard time explaining it
If you have ever played a game where you can build your own uh, whatever you are able to build, it is usually breakable. Robocraft is a great example, if you break a piece that has stuff connected to it, how do you tell the pieces connected to that piece that they are now disconnected? Same with the other stuff down the chain.

 

You will have to maintain a data structure that hold the relationship, generally you will have a core object that will act as the parent and main control dispatcher, which will have reference to all part, part that broke off the core are just remove from the core reference structure (for exemple a list or a tree). Another way is to use the transform hierarchy and parent accordingly, you will then just have to check if parent object exist, if not it's broken, so you can just remove the parent reference to break apart.

 

I was thinking of using parenting, but I decided that that would be inefficient for my needs. When organizing the structure and different pieces, that will be a pain to look around in. Also, destroying/breaking stuff works just fine, it removes the core as the parent.

 

I was thinking about a parenting or node setup. 100 pieces to make a leg, wow. In that thought process, for example, you're breaking out someone's leg part way (say the knee), does the bottom fall off when the knee is gone or greater than 60% of the knee, etc? I don't know if that could maybe be helpful.

 

You'll need to create some sort of connection graph and traverse it every time a part is destroyed to test the integrity of the object. Using your stick example, the left cube would have a reference to the middle cube. The middle cube would have a reference to the left and right cubes and the right cube would have a reference to the middle cube. Whenever an object is destroyed, each cube would evaluate its connections and if they're no longer valid, detach itself from the object and begin its own physics simulation.

You're going to run into issues with defining integrity though. Take for example a T shaped object whereby the bottom middle cube is destroyed -- does that render the whole thing useless or not?

You can simplify the problem by creating "core" components and binding everything to those. If at any point the chain of objects is not connected to any core object or a core is not connected to another core, break the whole thing off. That might make the most sense from a gameplay sense too if we're not looking at simulating things such as buildings.

 

Hey there!
That's around about what I was thinking, but structures don't have a core. They have... the ground? I'm not sure how to handle that, but with separated parts the "core" piece is the last piece that was connected to the core (the closest to the break) so that shouldn't be much of a problem.

The way something is controlled is the core, if a structure piece have a core it just can't be controlled.

 

I think it would be helpful if I posted a picture of my creation... There is no "health" function, only the physical damage to an object. An object has to be connected by even one little cube to stay connected.

 

Say hello to the scavenger! I had to turn down the quality of the image because it was too large, but it should be good now.

 

You'll probably have to repurpose some pathfinding algorithms like A* - treat each cube like a pathfinding "node", try to pathfind from A to B; if there's no route, it's broken. Unfortunately it's just different enough that you likely won't be able to really use any off the shelf implementation of A*, but hopefully if you follow some A* tutorials you'll be able to see how the algorithm can be adapted for your purpose.

 

In your example image, you have clear 1:1 links between objects (the skinny joints), so you just need to store references from one link to the connected object. It simplifies traversing the graph significantly.

 

this sound really easy to me. put this script on every block peace. If the parent object changes then all children object will fall off too.

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. public class BlockPeace : MonoBehaviour
5. {
6.     private GameObject parent;
7.     private bool isAttached = true;
8.    
9.    
10.     void Start()
11.     {
12.         parent = transform.root;
13.     }
14.    
15.     void Update()
16.     {
17.         if(isAttached)
18.         {
19.             if(transform.root != parent)
20.             {
21.                 isAttached = false;
22.                 OnDetach();
23.             }
24.         {
25.     }
26.    
27.     //when the block falls off
28.     void OnDetach()
29.     {
30.         transform.parent = null;
31.     }
32. }

 

Nice to see someone got it, but I'd probably have gone with "rootPart" or something as the name; it makes line 19 look a bit... odd at first glance as it is

 

I think A* (or some sort of pathfinding algorithm) is my only hope, not sure how it will know the structure of the object but it shan't be hard to create that bit.

 

The joints are not too much of a problem, when generating the 3D matrix of the structure that will be linked.
As StarManta stated, it would probably be best to just to use a pathfinding algorithm (particularly A*).

 

That was my thought originally, but then I found some problems with that. If you have a long strand of cubes that is only one cube wide with the core on one end, then you detached the piece right in the center, how would the cubes on the other end from the core know that they have been disconnected?

*piece

 

You should tell the direct children that you've been disconnected (you: the piece). They can tell theirs, etc..
This has kind of been talked about.
If you had more than 1 object holding a link together, perhaps a list of parent nodes would work, in that case.
Perhaps even with a value for how many are required to hold it together (but you did say earlier even 1 could maintain a link).

 

I think it would be best for me to use a pathfinding algorithm, thanks for your help though! I don't really like the parenting system because I can see that getting messy real quickly, and that is a lot of relationships that have to happen and I don't think that unity would like that.
Instead of every cube having a parent, every cube will have one parent. If said parent is not the core, then check if it is connected through a joint to a piece that is.

 

Sure, well whatever you think will work best

 

With my code. Every block has this script running on it. So every block is checking for the root gameobject.
Updated script. created a video

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. public class BlockPiece : MonoBehaviour
5. {
6.     private Transform parent;
7.     private bool isAttached = true;
8.  
9.  
10.     void Start()
11.     {
12.         parent = transform.root;
13.     }
14.  
15.     void Update()
16.     {
17.         if (isAttached)
18.         {
19.             if (transform.root != parent)
20.             {
21.                 isAttached = false;
22.                 OnDetach();
23.             }
24.         }
25.     }
26.  
27.     //when the block falls off
28.     void OnDetach()
29.     {
30.         transform.parent = null;
31.         gameObject.AddComponent<Rigidbody>();
32.     }
33. }
34.  

 

Now I just have to write a system that can convert any blender model, and turn it into a working, readable text file. It shan't be hard seeing that, every natural "parent" cube has a bunch of little underlings, we can see that, but how do we know they are all connected? So, run a check to see if they are all connected to the main parent, the ones that aren't will be separated under their own parent cube. For parents in parents, it should make a "joint" connection and call it good. That joint will act as a bridge for the pathfinding algorithm.

 

I tried to put the script in, but it gave me this error:
The referenced script on this Behaviour (Game Object 'Cube') is missing!
Also, I don't want to use the parent chain because, well, it's very hard to look at, and making a parent chains for 2000-3000 cubes is gonna take forever.

 

You said that if it gets disconnected from the core it is automatically unparented from it? then, assuming all pieces have a different name, when you want to check if it's connected you could use:
myCore.transform.find(this.name)

myCore you will get in the awake function, when this piece is still connected to the core.

transform.find only looks for children (it's very different from GameObject.find). If it does not find anything, then it's disconnected.

 

Thanks, I'll have to check out this function!

 

A* seems like overkill given the number of object, especially when graph traversal is like trivial, if you have a graph with a root you will have parent, it doesn't matter how it is implemented.

 

you appear to be suffering from project creep already

 

Well, I started to think about what people might create with my game, and what I will create. It will be more than the Scavenger, much, MUCH more.

 

But the graph will be changing so much, this is a physics simulation capable of handling massive battles, I want some way to update the graph every time something happens to it. Later on there will be power conduits running through the cubes... I just don't see how this is overkill.

 

How big do you expect the graph to be? it seems like you are moving from simple automata to full army, it does not make sense.. Each automata should be shallow graph, and you can certainly concatenate redundant node further (ie have only one parent and one children).