Layout structure of a symmetric arena 🤔 (SOLVED)

[Ragetto]

Hi guys!

In my first project, I have a symmetric arena with “wall blocks” on both sides (and other similar objects but I focus on wall blocks here to make it clearer):

Same wall blocks on the right as on the left: same sprites & collision shapes, but flipped.
=> Technically it’s ok, as explained by @Britzl here:

Scaling on Y in collection different ingame vs in editor (#3215)

Thanks! I’ll try to avoid the second solution if possible (for the reason you mentioned), but… If I flip the sprite, what will happen to the collision object (since they are at the same level in the hierarchy)? ex: [image] Will it keep its original orientation or will I need to flip it too? (if so, how? Is there a way to flip a collision shape?)

In terms of collection structure, my first (super naive) idea was to duplicate the main game object “goal_left” (on the left - containing the wall blocks - I mentioned them in particular because they’ll be the only “physical” game object with a collision shape, the others are just cosmetic stuff) to create “goal_right”.

Then I decided to flip the “wall blocks” sprite by using a one-frame flipped animation directly in the atlas (as recommended by Britzl) . It worked as intended, but since all my “wall block” game object instances were sharing the same unique sprite… when flipping the wall blocks on the right, I was also flipping the wall blocks on the left (which makes perfect sense, I know at this moment I felt a bit retarded).

So I thought that maybe I could detect in runtime whether a block is on the left/right side (based on its position), and flip the sprites/collision shapes when the game starts… same for the script, they could share it but some conditions would define different behaviors (ex: the walls blocks are pushed back when a ball / bullet bounces on it)… but… fundamentally, isn’t there a less “complicated” / more elegant/smart/clean way to do it?

How would you structure & organize this collection/game objects to make sure that:
1/ you can share sprites/scripts etc. between left/right blocks?
2/ if you add game objects in the “goal_left” (main object), the changes are also applied to “goal_right” (but maybe “duplicating” the main object is not the solution at all … Would you have done it?)

Please let me know

[britzl]

Since you have a script on each goal_block.go perhaps the script could have a script property with a checkbox that can be used to indicate if the block is left or right?

-- goal_block.script
go.property("is_right", false)

function init(self)
	sprite.set_hflip("#sprite", self.is_right)
end

Or maybe check if go.get_world_position() is towards the left or right in the script and flip accordingly?

[Ragetto]

Since you have a script on each goal_block.go perhaps the script could have a script property with a checkbox that can be used to indicate if the block is left or right?

-- goal_block.script
go.property("is_right", false)

function init(self)
	sprite.set_hflip("#sprite", self.is_right)
end

Wow thanks @britzl Amazing! Adding properties in the editor may seem super obvious for most Defold users (so I must look silly right now), but for me this is a huge discovery… Recently I was wondering how to define object parameters / values directly in the editor… Seems like I have my answer!

Note: I remember having read the description when going through the documentation (before launching Defold for the very 1st time), but at this moment it didn’t make real sense to me…
https://defold.com/ref/go/#go.property:name-value

Maybe you could add at least 1 little screenshot (showing the created field/checkbox) to make it crystal clear for everyone (including noobs). Someone like me (would knew absolutely nothing about Defold but has visual memory) would have kept this precious info in mind forever, even without needing it in the short term…

---

Anyway, getting back to my “issue”…

Following your recommendation, I created a “right_side” script and assigned it to all the game objects that could be flipped based on whether they’re on the left or on the right…

Technically speaking, flipping the sprites worked as intended but the flipped objects kept their relative positions in the main game object (from the original one on the left), which looks… weird. I realized that flipping thing in runtime would make the arena setup pretty painful…

I ended up duplicating of the objects composing the left part of the arena.
(xxx_L.go => duplicate => xxx_R.go)

Pros:
1/ I can easily/pixel-perfectly position both sides in the editor without having to launch the game.
2/ Both sides share the same atlases and scripts (with the go.property thing, it should be easy to make them behave based on their side)

Cons:
1/ Each time I add a child on the main object on the left, I’ll have to do it on the right… but this is not so much work after all. I don’t know if there is a “perfect” solution anyway.

Do you think this approach is viable / “clean enough”?
If so, you can consider this issue solved and thank you again for the answer(s)!

[britzl]

Maybe you could add at least 1 little screenshot (showing the created field/checkbox) to make it crystal clear for everyone (including noobs).

The API reference is generated from comments in the source code so adding images to the API reference will be tricky. But we do show it in the manual:

Script component properties

[britzl]

Technically speaking, flipping the sprites worked as intended but the flipped objects kept their relative positions in the main game object

Yep, this makes placement tricky unless you position the sprite without any offset from 0,0.

Do you think this approach is viable / “clean enough”?

If it’s not something you come back to and have to work with almost every day then I’d say it is good enough! Don’t fall into the trap of trying to perfect everything and Create the best setup ever seen in a game ™, You will spend all your time perfecting this instead of creating a game!

[Ragetto]

Maybe you could add at least 1 little screenshot (showing the created field/checkbox) to make it crystal clear for everyone (including noobs).

The API reference is generated from comments in the source code so adding images to the API reference will be tricky. But we do show it in the manual:

https://defold.com/manuals/script-properties/#defining-a-script-property

Oh ok… Now that I’m a bit more familiar with Defold, I should (and will) take a second/deeper look at the manuals. I’ll probably find tons of useful information and tips.

[Ragetto]

Do you think this approach is viable / “clean enough”?

If it’s not something you come back to and have to work with almost every day then I’d say it is good enough! Don’t fall into the trap of trying to perfect everything and Create the best setup ever seen in a game ™, You will spend all your time perfecting this instead of creating a game!

100% agree…!!

I wanted to avoid being trapped by my own setup (making some stuff trickier to implement in the future), but I also think it’s ok now, considering how the game will work.