Best Practice for Slight Variations to Instanced Scenes

Question

Is it considered bad practice to tweak instanced scenes' child nodes via checking the "Editable Children" option of the root node? Or should I be exposing and "passing up" variables that the children use to their parents so all the configurable vars are accessible from the root node? Or something else entirely?

The first option seems cleaner to me, but considering the "editable children" are greyed out, it almost seems like a debug option, or one that should be used sparingly.

Here's the scenario I'm working with as an example:

I made a super basic boost zone that accelerates a rigidbody2D as an exercise:

The above picture is the main scene tree with one instance of the boost zone in use. The BoostZone has the "Editable Children" property checked, accessible by right-clicking on its node. The boost zone uses another simple scene called "ScrollingSprite" that, as the name suggests, scrolls a texture in a direction configurable by two exported vars:

Note how, in the first image, ScrollingSpriteV2's child animation node, "AnimationPlayer", is not visible, as I have not checked ScrollingSpriteV2's "Editable Children" property.
I want to make the boost zone easily configurable so I can have multiple zones with different colors, different sprites, or different speeds/directions at whim. But in order to affect the sprite and its scrolling direction, I need to access the ScrollingSpriteV2 child of the BoostZone parent. I'm coming from a Unity background where, to solve this, I'd have a script component that scrolls the required Image sprite component attached to the GameObject. Then I'd have a separate script on the same GameObject that handles the acceleration of any entering object.

Is checking "Editable Children" the best way to do this? Should I be saving multiple slight variants of the same scene? Should I keep the ScrollingSprite and Area2D that detects RigidBody2Ds as separate scenes entirely and manually place them and line them up in my Main scene? Is there a cleaner way that's more standard-practice?

Thanks in advance.

Answer 1

The best practice is the one that saves time and simplifies organization. It is rarely possible to do both. I think the rule is simple - You need to think what is going to be more tedious : tweaking multiple properties of single scene every time You add it, or creating dozens of slightly different scenes just once. You need to imagine how many variations of the scene can there be in future for your project, and so how tedious can both of these sollutions get later. The more elasticity project requires, the better it is to choose 1st sollution above the 2nd.

changing "editable children" by itself is not problematic sollution, but I can imagine it being tedious to choose this option every time before making your changes. You can set texture of a sprite children in main script ready() given exported texture, and so on for every property of every child.

Comments

This is a good answer, thank you. I think a problem I'm having is the opposite of the usual idiom, "missing the forest for the trees"; I'm seeing the forest, but not looking at any of the trees. I should try multiple different organizational methods over various small projects to get a feel for it. A goal of mine one day is to participate in a game jam, but the level of knowledge required to pump out an idea in ~72 hours is still far away. I need to fail quickly and fail often, so they say.

---

to be honest I believe gamejams are overrated as a game design learning tools. I have learned the most while doing huge scope-creeping projects. If I did millions of small projects I would be able to make new games fast, but I would have no idea about complex coding challenges. I guess one needs to find a balance :). I definetely recommend taking a few months to do a cripple of a dream game, just to learn about deep structural issues, at least once in learning lifetime :)

---

Well, game jams are more of an opportunity for you to, first and foremost, to enjoy the experience and challenge but also to broaden your skills into areas you might not have been exposed to before. Plus, you get quicker and more productive. Also, just starting afresh often means you start better and starting a project on a good note can't be overrated.

But yes, I agree with you that engaging in a proper project exposes you to the full beast that is game dev where dipping your toe doesn't necessarily.

ps. am I confusing you with someone else but weren't we discussing linear algebra - oh, maybe a year back or so? Apologies if I've confused you with someone else.

---

@Inces
Very good points. My interest in godot was sparked when a couple friends approached me about making a game together for the third time (but this time it's different, promise!). The project we're planning on making is definitely lofty and I suspect we'll only accomplish a fraction of what we want, but I bet that's where my big project experience will come from first. Participating in a game jam is more aspirational than anything else, I just think it'd be fun! And being able to submit a game, no matter how simple, in such a short time would be a huge item checked off my bucket list.

---

@DaddyMonster

You are not confusing me, that is the same person :)
I might have sounded like some game dev pro perspective in this comment, I consider myself intermediate, these are just thoughts of what I experienced so far, I am glad You share some of these ;)
What You say is true, without developing frequent small projects I always have a strong procrastination with finalizing projects, UI layout and graphical choices. Gamejams would definetely teach me some good habits about those.