Yes, I know what you're talking about but it would be very difficult to replicate something as accomplished as Tiny Wings in GS without massive processor load.
Theoretically - let's take TW as an example - you'd need to do something like this to generate procedural environments. It would still use bitmaps.
Step 1: Make dozens of different hill sprites. Step 2: Create actors in gamesalad for each hill. Position them way above the screen. Give them move behaviours to move right relative to the player's "speed" attribute. The player (bird sprite's) horizontal position would remain fixed, but the moving hills would give the illusion of motion. Step 3: Create a behaviour that randomly positions a hill just off the right of the screen every x seconds, where x is a variable related to the player's speed. The speed would have to be essentially the speed of the hills, and friction/collision from the bird would slow them down.
This would only work if a) all the hill sections tesselated perfectly and b) they were all the same size. It WOULD be possible to use different width hills, but that would require behaviours and math so convoluted it makes my head explode.
Of course, the real problem with doing TW in GS is that the physics engine does not support curves. You would have to constrain multiple invisible collision rectangles to every hill sprite to fake a polygonal line.
Simple answer - If you want to make a TW clone in GS, it would be astonishingly difficult (although I'd be impressed if someone proves me wrong). If you want to make procedural/partially procedural graphics, more power to you. Don't forget the capabilities of procedural graphics tools within GS either, like particles, resize, colour and opacity.
Comments
if not, I don't understand what you are asking
Theoretically - let's take TW as an example - you'd need to do something like this to generate procedural environments. It would still use bitmaps.
Step 1: Make dozens of different hill sprites.
Step 2: Create actors in gamesalad for each hill. Position them way above the screen. Give them move behaviours to move right relative to the player's "speed" attribute. The player (bird sprite's) horizontal position would remain fixed, but the moving hills would give the illusion of motion.
Step 3: Create a behaviour that randomly positions a hill just off the right of the screen every x seconds, where x is a variable related to the player's speed. The speed would have to be essentially the speed of the hills, and friction/collision from the bird would slow them down.
This would only work if a) all the hill sections tesselated perfectly and b) they were all the same size. It WOULD be possible to use different width hills, but that would require behaviours and math so convoluted it makes my head explode.
Of course, the real problem with doing TW in GS is that the physics engine does not support curves. You would have to constrain multiple invisible collision rectangles to every hill sprite to fake a polygonal line.
Simple answer - If you want to make a TW clone in GS, it would be astonishingly difficult (although I'd be impressed if someone proves me wrong). If you want to make procedural/partially procedural graphics, more power to you. Don't forget the capabilities of procedural graphics tools within GS either, like particles, resize, colour and opacity.
Just thinking out loud.