Multiple sprites in one factory?

#1

Hello all, I am finally back with another game dev venture. My first question to you is asking if it is at all possible to have multiple sprites coming out of one factory. My idea is similar to a candy crush concept with rows of factories dropping random sprites at a constant rate. If factories are not the way to go for this can anyone provide some ideas?
Thank you very much for your time, it is greatly appreciated. If you need more details to help better answer the question please let me know!
Thanks!
V

0 Likes

#2

If I understood correctly, one factory is enough. You can change it is sprite on runtime by changing sprite.play_flipbook .
You can check out Emthree as an example

2 Likes

#3

Ah, thank you very much! I will thoroughly look into this method! Thank you again!
V

1 Like

#4

Hey @Vgreen ,

I didn’t look through Emthree to see what’s happening there, but the way i do this is just with a property on the factory.create.

On the GO’s script put a property “sprite” = 1

Have a table of the animation names of your atlas/tilesheet:

Self.anims = { “red”, “blue”, “whatever” }

And on init() you have sprite.play_flipbook(self.anims[self.sprite])

Something like that, anyway.

1 Like

#5

Ah thank you very much. I see that sprite.play_flipbook is the main part of this. What would the self.anims end up being?
Thanks again!
V

0 Likes

#6

The way i like to do it, described above self.anims is a table of all the possible “animations,” or in your case possibly just single sprites, that a particular GO can have (named inside the tilesheet or atlas). When you create a GO with a factory you pass it a property value (a simple integer) that looks up that position in the self.anims table and uses that particular sprite or animation when creating the object. (So in the above example “1” is the red tile, “2” the blue tile, etc).

The above is “pseudo-code” to an extent. I believe animation/sprite names maybe need a hash() in front?.. I’m not at my computer at thr moment…

This method might be overkill, a more experienced defolder could chime in as to that, but it’s the way i like to organize things, and for me makes iteration easier if/when you want to change sprites/animations and only need to rename in one place (the GO’s self.anims table)

1 Like