Search Unity

[Solved] Transfer force applied to rigidbody to the parent game object

Discussion in 'Scripting' started by Deleted User, May 5, 2015.

  1. Deleted User

    Deleted User

    Guest

    I have a game object like this:
    Root
    - Child 1
    - Child 2
    - etc.
    All child game objects are just containers / folders to help me organize my behaviours.
    Child 1 contains all components related to collision, including the rigidbody. I'd like that when the rigidbody is moved, it also moves the parent(s) accordingly. How can I achieve this?
     
  2. hamsterbytedev

    hamsterbytedev

    Joined:
    Dec 9, 2014
    Posts:
    353
    Do you really have that many scripts to attach to the same object that you need to create children to attach them to? I feel like you are making unnecessary overhead here...

    My advice - Do away with that approach entirely and never revisit it; every object consumes memory and it seems like bad practice to just make GameObjects whose sole purpose is to hold scripts you don't want to attach to the parent for aesthetic reasons.

    I'm not even sure what you are describing can be done, but I'm sure that if it can it will create lots of garbage, be detrimental to the efficiency of your code, and ultimately stifle the performance of your game. I could be wrong about this, maybe there is some sort of elegant solution that fits exactly what you are describing, but I can't see it. This is what I've considered:

    1. Add a rigibody to the parent and mirror the movement from the child; you'd have to cancel out the movement of the child while simultaneously applying that movement to the parent. Seems hacky when you consider that the rigidbody has already done and applied the calculation and you are going to translate that effect to another object?

    2. Do something similar to what I mentioned above, but use transform.translate. Again, unnecessary garbage and scripting.

    If you must use this approach of having nested GameObjects to store your scripts then put your rigidbody on the parent object. This will affect all the children attached without having to do anything hacky. I hope this helps. Good luck in all your future endeavours! If you have any more questions just ask :)
     
    Deleted User likes this.
  3. hamsterbytedev

    hamsterbytedev

    Joined:
    Dec 9, 2014
    Posts:
    353
    Look into rigidbodies. More specifically rigidbody.addforce. That should get you in the right track. Also going to want some ray casting
     
  4. Deleted User

    Deleted User

    Guest

    Create your own thread, you high-jacker lol.

    @Hamsterbyte.LLC , yeah it's less efficient but not by much. GameObjects don't do much by themselves. I'd like to keep the system though, as 1 GameObject will have at least 4 components: Sprite, Animation, Rigidbody, and Collider.
    I'll look into what options are available to me. Maybe I'll create a Rigidbody wrapper or do just code the few functions I need. All I really need is AddForce and one or two more functions.
    If you have any more ideas, let me know. ;)
     
  5. hamsterbytedev

    hamsterbytedev

    Joined:
    Dec 9, 2014
    Posts:
    353
    I don't think it is the extra GameObjects that are going to create the overhead; it's the fact that you are going to have to execute code twice to do the same thing. I do a lot of development on mobile and I can say for sure that if I were trying to optimize code, the first thing I would do is scrap a system like yours in favour of something more concise and lightweight. I wish you the best of luck with it of course, but I foresee a future full of gremlins you are going to have to deal with.

    If I can put everything on one GameObject I will. Perhaps this approach isn't as clean in the inspector, but it's a hell of a lot easier when you are scripting. You are going to have to find the object, find children of the object, and then get the components attached to those specific children. Just seems a little cumbersome. Might look cleaner, but you are making it harder on yourself in the end. It would be so much easier to just have one object that all of this stuff was attached to.

    When you say 'less efficient but not by much' it makes me think you really don't care about efficiency at all. You're making a 2D game(I know this because you said you were going to use a sprite) and 2D games are most commonly developed for mobile platforms. Code for mobile platforms has to be efficient; everything matters. There are certain things that you wouldn't think would matter, but they absolutely do.

    For example, a for loop iterates over an array twice as fast as it iterates over a list of the same size, so you would use arrays wherever you could instead of using lists.

    My point is, keep optimization and efficiency in mind from the start. Don't do things just because they may seem easier; instead do them because they are the best and most efficient. The end user is never going to appreciate all the extra time you wasted organizing your characters into a special hierarchy and coding custom wrappers. They just want to play games; trust me, they don't care. haha

    So my idea still stands; ditch the hierarchy and wrappers and stick it all on one object. It will be more efficient, easier to code for, and run smoother across multiple platforms. Best of luck! ;)
     
    Deleted User likes this.
  6. Deleted User

    Deleted User

    Guest

    lol your post made me smile. :) You guessed pretty much everything, Detective Hamster.
    But about my system--I have a function that gets all the game objects and components from them and caches them so then I can easily call "GetComponentInShelled<>()" and do stuff. Just like the Unity GetComponent.

    Code only runs once though, right now.

    Anyway, maybe you're right. I will soon start profiling my game and see where I can optimize stuff. If I see I'm losing a lot of performance due to it, then I won't hesitate to change it.
     
    hamsterbytedev likes this.
  7. hamsterbytedev

    hamsterbytedev

    Joined:
    Dec 9, 2014
    Posts:
    353
    Definitely, the profiler is a great thing. I use it often as I always have optimization in mind. I have an insatiable penchant for shaving milliseconds off my processing times :p
     
  8. HumptyDumpty

    HumptyDumpty

    Joined:
    May 3, 2015
    Posts:
    1
    Hamsterbyte.LLC , I've tried to write own scripts with rigidbody.AddForce but neither works, also I copied exact scripts from the web, like the one in the video and I'm being shown that all errors must be fixed to enter play mode. Can you write me a script please ?
     
  9. Deleted User

    Deleted User

    Guest

    No, create your own thread and write your own script. If you need HELP writing it, then people will help you but you have to write it yourself.
     
    hamsterbytedev likes this.
  10. hamsterbytedev

    hamsterbytedev

    Joined:
    Dec 9, 2014
    Posts:
    353
    Make a new thread @HumptyDumpty . I'm sure I'll see it and help you out if you still need my help. You are going to have to write the script yourself. You're not going to learn anything if I just write it for you and I'm pretty sure you don't want to pay me to write it for you, so you are going to have to get your hands dirty.

    rigidbody.AddForce() definitely works to move things around; I use it often. I suspect if you are getting errors it is probably because of bad coding practices or improper syntax.

    OH, and don't hijack threads from other people. You are unlikely to get the answer you are looking for because the thread is for a completely unrelated problem. Also, it's kind of rude. Best of luck!
     
    Deleted User likes this.