What is the best way to change an sprite's position inside a GO?

Questions
#1

Hi guys!
I have some game objects with more than 1 sprite each.
i want to move and rotate some small sprites (flares) without changing the GO position.
What do you think is the best option for me?

thanks a lot!

1 Like
#2

You’re actually not able to change the sprite components position at run-time. It’s better if put each sprite in a single game object and move them individually.

#3

I was looking for a way to move a spinemodel inside a game object. Since sprite and spinemodel are both components I’ll just assume the same rules apply. Trying to rotate a spinemodel or a bone inside a spinemodel.
Rotating the spinemodel being rulled out, is there any way to spine.rotate_bone? Or maybe in future development? Besides the spine manual and api, where else (source?) should I be looking for ways to have bones rotate?

#4

You can rotate the go which contains it, perhaps creating a new nested go for this purpose if necessary.

#5

I started with a pre-made Game Object initially. It contained the spinemodel, script and some extra sprites that were planted in place. I then too realized I need a nested Game Object but the menu showed no such option! Had to read a bit through the manuals to see how they made the orange peanut character with shield and realized the solution is to use a pre-made collection as it allows for nested Game Object and pretty much everything we need.
So this is def a way to manipulate parts of a contraption or complex characters!

1 Like
#6

Yeah, having to use a collection is a bit unintuitive, but should work just fine.

The alternative is to spawn the nested go at runtime using a factory but a collection is probably better for your purposes.

#7

Indeed. Collections are used to organise hierarchies of game objects and they have no additional runtime cost.

#8

In fact, we’ve talked about deprecating game object files before…

4 Likes
#9

GOs would be useful if they could contain other GOs within .go files, but only .collections can do that. Collections make more sense to use as raw files for organization nearly always (I can’t think of a reason to use GOs as raw files other than that they are an option, libraries often use .go files as the thing included and are meant for you to add to your project as a user of the library, I rarely see .collections used in that way) because they keep hierarchy and relative addressing easily possible while using a raw GO approach encourages less efficient patterns. I would not be against merging the ideas of Collections and Game Objects, but within Collections the distinction between Collection hierarchy space and Game Objects hierarchy space can still be useful.

Maybe an option for the sprite concern that repeatedly comes up would be to add a checkbox to sprites which would allow them to have transforms possible as if they were a child of GO, it’s just done behind the scenes for you. Then so much extra hierarchy is not required in sprite situations.

2 Likes
#10

That’s what the collection is for, and there’s imho no need for two file formats for that.

1 Like
#11

So as a feedback:

The solution was there for me to use, being failry new at Defold and working with Flash and HTML5 in the past (OO vs Modular), I expected Game Objects to be a sort of a Sprite in Flash (both a display object and container).

So what I would suggest to the new commer is to check the available tutorials on YouTube and manuals thoroughly then progress to understand the API (plain google it really). It ain’t rocket science, not dummy proof simple either. It’s just that Defold does things this way for a good reason. At the end of the day we get free mem management and performance for the cost of learning the Defold way.

I think I’ll write a more detailed message in a fresh thread once I’m done with this, initial project and give my full feedback and comparison to other ways of making games. So far my gut tells me I’m on the right track. I still have some unknowns to go through but all in good time.

2 Likes