Side Scrolling Game Demo 'Flappy Bat'

[Scott Ferguson]

Changes log 2014-06-19:

Removed Timer block to increase Canvas size to 1440 px. 

Thanks to Hal and the team for fixing that issue.

Video has not been updated, so keep that in mind.

YouTube video: http://youtu.be/lIOAJeyRizE

Itook a long time to understand is that the Canvas GetPixelColor block does not work for Android v4.0.x Ice Cream Sandwich

As soon as that block is executed the Canvas shifts up and left-aligns on the screen - hiding any component blocks above it in the process.

I was able to get it to work properly with the stock emulator (Android 2.2?) and on a Monster 7" tablet (Android 4.1 Jelly Bean)

So if you are testing this with a device running Android v4.0.x it will not work properly.

The object of the game is simple.

Drag the bat up and down by placing your finger anywhere on the screen and moving it up and down.

Avoid the cave walls and the owl.

The Canvas Dragged operation is not very responsive and somewhat unpredictable.

I could not find a way to improve it's operation.

The most interesting thing about this project was that I could fill a 480 px area with a set of two scrolling ImageSprites.

Each ImageSprite is 480x270px.

The first imagesprite starts at 960 and scrolls to the left util it reaches 480.

At that point the second imagesprite is moved to 960 and it follows the tail of imagesprite1.

When Imagesprite 2 reaches 0, then it jumps to position 960 and the process repeats.

To the user, the cave is continuous - no swapping is seen.

The swapping is hidden behind two 480x270px grey mask imagesprites on the left and right of the canvas.

The Canvas GetPixelColor block tests the color at it's x,y position -- which includes colors on Balls and ImageSprites.

That position is always at the center-right edge of the bat.

As the cave imagesprites scroll to the left, their backgrounds are black, but the cave walls are other colors.

By testing the color at the leading (right) edge of the bat ImageSprite, a collision with the cave walls or the owl can be detected.

A collision is indicated by the title bar text "*** OUCH! ***"

So, I am not using a CollidedWith block here at all, just the Canvas GetPixelColor block.

---

Scott

 

[M. Hossein Amerkashi]

Nice one Scott.

-Hossein.

On Sat, Mar 8, 2014 at 9:16 AM, Scott Ferguson <scottfr...@gmail.com> wrote:

This demo is an experiment with setting the Canvas Width to a value larger than the maximum of 999 allowed in the Designer Canvas Width property TextBox.

In order to get this to work, I had to use Screen1.Initialize and a Clock Timer block to force the width to 1440 then wait for it to update before moving my ImageSprites into their starting positions.

This is, of course, is an unacceptable workaround and I have requested that the MIT AI developers modify the property textbox to allow larger values.

Another issue that took a long time to understand is that the Canvas GetPixelColor block does not work for Android v4.0.x Ice Cream Sandwich

As soon as that block is executed the Canvas shifts up and left-aligns on the screen - hiding any component blocks above it in the process.

I was able to get it to work properly with the stock emulator (Android 2.2?) and on a Monster 7" tablet (Android 4.1 Jelly Bean)

So if you are testing this with a device running Android v4.0.x it will not work properly.

The object of the game is simple.

Drag the bat up and down by placing your finger anywhere on the screen and moving it up and down.

Avoid the cave walls and the owl.

The Canvas Dragged operation is not very responsive and somewhat unpredictable.

I could not find a way to improve it's operation.

The most interesting thing about this project was that I could fill a 480 px area with a set of two scrolling ImageSprites.

Each ImageSprite is 480x270px.

The first imagesprite starts at 960 and scrolls to the left util it reaches 480.

At that point the second imagesprite is moved to 960 and it follows the tail of imagesprite1.

When Imagesprite 2 reaches 0, then it jumps to position 960 and the process repeats.

To the user, the cave is continuous - no swapping is seen.

The swapping is hidden behind two 480x270px grey mask imagesprites on the left and right of the canvas.

The Canvas GetPixelColor block tests the color at it's x,y position -- which includes colors on Balls and ImageSprites.

That position is always at the center-right edge of the bat.

As the cave imagesprites scroll to the left, their backgrounds are black, but the cave walls are other colors.

By testing the color at the leading edge a collision with the cave walls can be detected.

A collision is indicated by the title bar text "*** OUCH! ***"

So, I am not using a CollidedWith block here at all, just the Canvas GetPixelColor block.

---

Scott

 

--
(you have received this message from the App Inventor Developers Library)
---
You received this message because you are subscribed to the Google Groups "App Inventor Developers Library" group.
To unsubscribe from this group and stop receiving emails from it, send an email to app-inventor-develope...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kevin Chen]

Hi Scott,

This is a really nice tutorial! I was trying to find a side-sliding game and couldn't figure out how to do this. Your posts provided a great hint to me! Thanks!

However, if I want to see different caves scrolling into the screen every time, how should I do that? Should I upload like 50 different caves images into the library?

Kevin

On Saturday, March 8, 2014 10:16:35 PM UTC+8, Scott Ferguson wrote:

Changes log 2014-06-19:

Removed Timer block to increase Canvas size to 1440 px. 

Thanks to Hal and the team for fixing that issue.

Video has not been updated, so keep that in mind.

YouTube video: http://youtu.be/lIOAJeyRizE

Itook a long time to understand is that the Canvas GetPixelColor block does not work for Android v4.0.x Ice Cream Sandwich

As soon as that block is executed the Canvas shifts up and left-aligns on the screen - hiding any component blocks above it in the process.

I was able to get it to work properly with the stock emulator (Android 2.2?) and on a Monster 7" tablet (Android 4.1 Jelly Bean)

So if you are testing this with a device running Android v4.0.x it will not work properly.

The object of the game is simple.

Drag the bat up and down by placing your finger anywhere on the screen and moving it up and down.

Avoid the cave walls and the owl.

The Canvas Dragged operation is not very responsive and somewhat unpredictable.

I could not find a way to improve it's operation.

The most interesting thing about this project was that I could fill a 480 px area with a set of two scrolling ImageSprites.

Each ImageSprite is 480x270px.

The first imagesprite starts at 960 and scrolls to the left util it reaches 480.

At that point the second imagesprite is moved to 960 and it follows the tail of imagesprite1.

When Imagesprite 2 reaches 0, then it jumps to position 960 and the process repeats.

To the user, the cave is continuous - no swapping is seen.

The swapping is hidden behind two 480x270px grey mask imagesprites on the left and right of the canvas.

The Canvas GetPixelColor block tests the color at it's x,y position -- which includes colors on Balls and ImageSprites.

That position is always at the center-right edge of the bat.

As the cave imagesprites scroll to the left, their backgrounds are black, but the cave walls are other colors.

By testing the color at the leading (right) edge of the bat ImageSprite, a collision with the cave walls or the owl can be detected.