#The limits of resources over packed scenes

1 messages · Page 1 of 1 (latest)

green falcon
#

Simple question on the surface but quite specific.
At which point would you rather use a packed scene over a resource?

I like resources because it allows to very easily create new elements, edit, and it's more explicit and strict in code.
However, I sometimes feel like i might be over using it, or that I miss some other workflow subtleties.

Typically, I have a very modular weapon system, where every smallest logic or visual component is an independant resource that can be branched on some other components.

Sometimes, it feels like packed scene would be more intuitive, typically for in space element like a model or hand position to do some invert kinematics. Each weapon might be placed at a different base position.
I could store an offset position in a resource, but it's quite unituitive to edit, you would rather directly edit it in the scene.

Some of the issues question i run into with this subject also comes from the fact that I try to never use assignation through tree lookup. I feel like it is quite error prone, not so explicit, and might be costly. So i always either export the fields, or have them being initialized through a parent node that has the required data exported.

I would love to hear about some workarounds or opinions and experience on this subject.

blazing nacelle
#

I'd argue this is just a "code-first vs. configuration-first" approach, with the normal pros and cons for each.

The code-first approach (custom resources) tends to permit faster development and evolution of the codebase, and makes things easier for developers because they don't have to write any boilerplate, they just write code as it will execute in-game.

The configuration-first approach (PackedScenes) tends to permit faster design at the cost of slower development. It's usually easier to tweak small values, and it's definitely easier to edit things like transforms in 3d as compared to doing it in code.

In this particular situation, I see no reason not to combine both? Ultimately a PackedScene is just a subclass of Resource. Use a PackedScene to configure your nodes in 3d when that's useful, and then use custom resources for stuff like custom gun colors, different trigger behaviors, bullet patterns, that kind of thing.

green falcon
#

It seems like a pretty good approche yeah
Yesterday I expérimented on a new workflow while working on a new feature, before i commit to reworking the whole code base
So i tried to really separate data and Logic, with data just holding helper methods to generate the proprer associated nodes

#

I still feel like it'll be a little more complicated in some specific cases, typically, i was mentionning some hand positionning

#

I should be able to reference these easily, but if they are hidden in a packed scene, it will be a little mess to connect to the node responsable for the invert kinematics

#

But it's still quite blurry in my head for now so i'll worry about this when i will start implementing it