To Be Or Not To Be ... An Independent Child Object Transform

Hello folks,

I need to pick some ideas over here. So this is the situation:

I have a scene (RPG View - Not Top Down, think Chrono Trigger) with a guy, who’s got a parent playerObject, and two child objects, Player (for the sprite), Shadow(Feet). The Player and Shadow are just sprite renderers without rigidbodies. The Shadow has a box collider with a trigger set on.

Currently, the parent object has it all - the playerController, the necessary box colliders, rigidbody2D, except for a sprite renderer.

So far I have managed to get my guy running, even JUMPING (I am so excited about this since I figured this one out by my self),attack animations what not. Last night I came up with a “Falling” Logic.

This was all possible because I can animate the sprite in Player independent of the shadow (Just move the transform.position.y +/-, while checking for the object’s localPosition relative to the parent), and similarly, the falling logic as well - keep the shadow still down, move the Parent Object down relative to the shadow.

However with that second one, the falling logic, I cannot move the shadow up and down (but I can make it move left and right) because to keep the shadow still in its y axis and NOT move with the parent as the parent moves down towards it.

Here’s my thought right now: What if I remove the rigidbody2d from the parent, remove the colliders, and script, and move the rigidbody2d to the Player and Shadow children, put the big colliders in the Player, and necessary one for Shadow to prevent NOT colliding with anything, and then move these two children independent from each other by placing a Movement script that can be used by either of them, a Jump script for the Player object, a fall script for the Player/Shadow and NOT have anything on the parent? But if I do this, disadvantage would be that I would need to make sure Player and Shadow transforms are in sync.
Advantage would be the jumping and falling logic would be easily maintained by keeping them in separate scripts.

In most tutorials they have one giant playerController script that handles everything of a player object.
Is it realistic to separate the controller script into chunks for movement,jumping,falling,attacking and allocate them to necessary Objects? This would make them re-usable right? But why don’t tutorials encourage this?

[Sorry for the long thread, I’ve been losing sleep for the last few days because of this so I want to pick your brain on this.Thank you.]

In that case, what do you need the parent for? You could just make the player and the shadow two separate objects.

Very much so, if that’s what you need.

Tutorials are short. Tutorials are usually meant to teach one specific thing in isolation. If they tried to go and make everything modular and scalable that would distract from the main focus of the tutorial. You should always consider tutorials as the simplest, most bare-minimum, stripped-down example of how to do something just to illustrate the concept. They’re never going to be a realistic example of how a real game would work.

Edit: Just to add to my tutorial rant- putting all of your movement in to a single script is not necessarily even the wrong way to to do it. There’s no single right or wrong way to organize your movement code for any type of game. It all depends on your specific requirements.

The reason being, in the event I would require colliders in the parent object to interact with other objects in the world? Would that make sense?I was thinking it from the approach that the parentObject, is the vessel for the sprite(the body), and the shadow(the ground upon which the body SHOULD stay upon).

I 100% agree that tutorials are not an implication of what a real game should work like. I understood this as I was working with coming up with the jump mechanic. It’s almost non existent online, the algorithm to get a jump in a top down properly work. But I thought “controller” scripts are always that, controller scripts that constituted everything belonging to an object with a movable property. But the more I work with these objects for “Depth sorting” “Triggering transparency of objects when player/other objects are behind others” etc, I was finding it easier to write them in separate scripts and attach those scripts to whatever object required that “property of physics”. I was just wondering then why they don’t have a tutorial on displaying such a workflow. I am having to come up with my own work flow which is why I decided to come here finally. To see others’ perspective how they organized their scripts/objects.

I thought you said you were moving the colliders to the player. Are you anticipating the need for both the player and the parent to have colliders?

Right, so let me think this… the reason I had a parent before was the children depended on the parent’s rigidbody, so the colliders in the Player and Shadow were irrelvant, since the parent’s collider would collide objects around to prevent further movement. But now if I have colliders for collision detection and rigidbodies in the children…I’m trying to think if there would be a scenario to have a collider in the parent object. Maybe for trigger events for other objects? Wouldn’t it be easier if I tagged the Parent object with its own “MainObject” tag to trigger certain things with the parent as a whole that would impact the children, right?Maybe I’m thinking this wrong.
If not, I think it would still be nice to have a parent object for organizational purposes anyway, wouldn’t you agree?