If the sprites are animated C2 will make spritesheets out of them put into a power of 2.

The most important thing to take into account is the weight of the graphics on the performance. Using a bigger sprite and reducing it's onscreen size give better results than using a smaller one and scaling it up, if you want it to look crisp. A disadvantage of this is that bigger sprites will take up far more VRAM and on less capable devices (Mobiles and older desktops) could be your bottleneck in performance.

There are many topics about this on the forums.

-Try to re-use sprites as much as possible.

-Use tiled backgrounds if possible.

-Use your VRAM wisely.

Could you be more specific?

Do you have a list of names you want to randomly pick one of?

Would you like to generate the name from random syllables?

Is "Q1hm5z&" an acceptable name?

Maybe you could try temporarily pinning the objects to eachother and unpinning when rotation has finished, that is when you want them all to rotate around a specific point. If you just want to rotate each and every one on their own using families would be better.

Found this topic using the search future of the forum

You could just start the shoot while walking animation at the same animationframe as the walk a animation to make it fluid or like you suggested use two sprites for upper and lower body, depends on the complexity of the animations, really.

It would have probably been better to create the intro in Construct2.

I dont know how big the png's are pixel-width times pixel-height, but that times 4 times 400 is how much VRAM-bytes it will use, and I guess that's the issue. Animations made with flash can almost certainly be recreated inside Construct2, albeit sometimes in a different manner.

PNG size isn't important while playing. VRAM usage is:

To figure out how much VRAM an image will use, you multiply the width and height together, multiply that by 4 to get bytes, then divide that by 1024 to get kilobytes. So a 32 x 32 image would be:

(32 * 32 * 4) / 1024 = 4KB

Transparency doesn't matter when considering VRAM, as the images are stored uncompressed.

Also keep in mind that most video cards will store the image in a texture that is rounded up to the nearest power of 2 size, so for example, a sprite that is 280 x 280 pixels would be stored in a texture that is 512 x 512, taking up a much larger amount of VRAM.

I would recommend using system scroll to action instead of scrollto behaviour. This gives you far greater control over what happens onscreen.

Adding conditions for what happens when ship is further than the camera sprite.

In the event sheet you can use the animationframe as a condition.

On object clicked - sprite: compare frame

or if you are using different animations:

On object clicked - sprite: is playing "animationname"

What do you mean with mainly code?

While making a game in construct 2 almost everything can be done and adjusted through events.

Yes, the object is given "mass" by it's size. Density will not take away mass.

To make the object immovable, set it to immovable in physics-proporties.

The most important change I made was setting the isactive off when attached, so it wouldn't try re-attaching all the time.

The "rope" is just for show, it doesn't actually do anything but show the rope connection that is made. (sometimes it goes to another animalballoon, but this has no actual effect)

With every balloon attached right now the gravity on the animalballoon becomes 20 less, so after 2 balloons it's already -15, but because the falling speed it will take some time for the animalballoon to slow down and start to rise.