I have only just discovered Snap and I like it a lot! Have got some experience with Scratch, but I like Snap better.
I am in the process of developing a game which will be quite complex when it's finished. Now I wonder how I best set up the game to optimise its performance.
My main question is whether it makes any difference if you include (say) 10 sprite variants OR use 10 different costumes instead.
Example:
I need a pivoting arrow that turns back and forth by 10 degrees on a dial. I have worked out a well-running solution by using 20 separate sprites for all the arrows.
I tried to use costumes, but I had difficutlties keeping the correct position of the arrow on the dial. But I didn't give it a lot of try because the solution with the separate arrow sprites was easy to establish and works well. But now I wonder: Does the overall number of sprites infuence the speed/performance/loading time for a project? There are other situations in which I could apply both, separate sprites (again, easier to program) or different costumes of ONE sprite.
Could you not just turn the ARROW by using "turn __ degrees" command, instead of creating 20 separate sprites ?
Rotation point is controlled by the cross-hairs tool in painter.
Yes, of course I could have, but there are some cross-references with the arrow (influencing other factors) and simple rotating it would have made this more difficult. If I had had different costumes I could have linked the aboved mentioned cross-references clearly to one costume (just like I linked them now to the different sprites).
I am not saying that there wouldn't have been a way using the rotating sprite, but the other approach seemed more straightforward/easier to programm.
If 20 separate sprites are required, then even 20 clones is much faster than 20 individual sprites. But of course, not knowing the big picture, I am just addressing to the "speed" issue.
Not knowing what the sprites are doing, it is hard to answer performance questions. However, my experience is 20 sprites is nowhere near any limit for performance concerns.
And yes, clones are super fast and definitely worth investigating. For one thing, they share properties of parent and also allow individualised customizations. So in you case 20 clones could start off from one and adjust their directions for each individual one, as soon as they spawn off. This only addresses one property, but others can be adjusted easily as well. Combining these capabilities with the feature of sprite-specific variables will allow very nimble handling of all these objects.
SNAP! manual is a very good resource explaining clones and their behaviors.
Welcome to SNAP!, by the way.
Indeed, welcome to Snap!. If I'm understanding correctly that 19 of the 20 sprites are hidden at any moment, then they're not so very costly. If they were temporary clones, then they wouldn't have thumbnails in the sprite corral and they'd be even faster.
Snap! is going to get way faster when Jens is ready to release the new version he's working on. We're hoping for beta test by summer.
You should learn about clones! A clone is like a copy of a sprite, but instead of literally copying everything and then having two independent sprites, a clone shares information with its parent, which is great because, for example, if you fix a bug in the parent sprite, all the clones get the new code. (If you change something in the clone, that value becomes separate from the parent; otherwise, for example, all the clones would have to be in the same place on the stage as the parent.) Check out the Reference Manual: click on the Snap! logo in the top left corner of the window to download a copy.
