Question about Sprite Collisions

Questions about Thunkable
,
1

I am trying to make my own maze game like the one found on the documentation Gaming section. (https://x.thunkable.com/projects/5d841c3942b03968327aa3b9/23cdf6a7-4c61-46d5-ae84-810e7ba9e3d4/designer)

I am not very experienced in coding. I made my own maze.png file with transparent background. I didn’t make it with individual pieces as in the Thunkable provided version because I would like to have different maze backgrounds so that the player can progress to the next maze when successful. The pumpkin does move around on the background, but when it collides with the maze, it doesn’t return to start. Can anyone spot what my problem is? Here is my file. https://x.thunkable.com/projects/5d87a0f488f93d0b9c855bb4/791401cc-ad9d-4302-ad41-8fb5d5522f39/canvas

Thanks for any help you can provide!

Debbie

1 Like
2

That is because your pumpkin is never seen to collide with the maze.
The reason the example was made with different, individual sections is that each is a sprite that can be identified, and each is collectively part of the overall “WallType” class. That is, if the ball touches any one of those, then a collision with the wall is detected, and the return to the start can be performed.

What you did with your version is one big drawing without actual walls, with walls outline painted on the floor. There is no logic triggered when passing over a change of colour, the edges of your maze sprite are the edges of the whole canvas. In essence, there isn’t anything for your pumpkin to collide with, and therefore never any collision.

1 Like
3

So what you’re saying is that the only way to do it is to make each piece of wall a separate sprite? Wow that would make it a lot more difficult to add different mazes. I thought that by making the maze walls one sprite, it was still a sprite (it is not part of the background). That doesn’t make a lot of sense to me in how the program is set up, but thank you so much for the help.

Debbie

4

A sprite is defined only by its external edges, what is inside (picture) is irrelevant.
If you have your maze one large sprite that covers everything, it is still a sprite, but the collision zones are only the extreme top, bottom, left and right edges. If the other sprite is already inside, it is not touching the edges, so there is no collision.

You could even have completely invisible sprites if you wanted (by making them the same colour as the background), the edges would still be there so collision could be detected (that, in itself, could be useful for some games).

And it DOES make sense. Suppose that the wall had a texture, instead of being a uniform colour, it is like a brick wall. Now, the system would have to detect if you are touching the red brick part of the image, or the grey ‘mortar’ part of the image. That would quickly go out of hand, particularly if your sprite had bits of it that would be the same colour as the red brick. Would it then fail to detect collision owing to the fact there isn’t a colour change between the mobile sprite and the fixed obstacle sprite?
A smartphone screen typically has one million pixel resolution, and each pixel can have any of 16 million different colours. Can you imagine how much processing would have to take place if collision was based on colour chage? You would only get 10 frames per minute!
Instead, each sprite is defined by its edges. If the edges X,Y coordinates of one sprite (a few hundred pixels only) happen to be the same as one of the X,Y coordinates of the edge of another sprite (again, only a few hundred points to check) then there is a collision.
And if the system is very smart, it checks first to see if any X coordinates happen to match, that way it can completely avoid checking the Y for a mach, thus saving computing power for the processing of the rest of the game.

That said, there is value in having each wall a different sprite, because colliding with different wall can have different effect. You can make colliding with one wall return you to the start. Or you can make colliding with a different wall “stick” for a while, making you lose time in a beat the clock maze run.
It could make colliding with a special end wall bring a “you won!” banner that would load stage 2.

If all the walls could never be any different from another, then all you could ever do is a maze. Now, you can make some other sprites work like walls that simply remove the motion in X but keep it going in Y; or ones that reverse the direction, turning them into bumpers that bounce back; you can make some of the sprites mobile, reacting to a button press, and you just got yourself a pinball game!

2 Likes
5

Thank, you it is working when I make the walls individually. I guess what I did not understand is that even if an image has a transparent background, that does not work with sprites because the sprite is the whole image regardless. I wasn’t trying to make it react with color per se, I simply didn’t understand that the sprite included everything up to the edges. Even though I made it transparent in background with blue gradient walls and then added a blue background color to the canvas, it was still seeing the transparent part as a part of the background. Thanks so much for explaining! I really appreciate it.

Debbie

6

The reaction with colour is what you perhaps how you though it would handled behind the scene, by the system. That is the assumption you could have had, as this is the only way it could detect or define its edge.
If you check the properties of sprite, they are define by their X and Y location, a width and height, and an angle. This means that even the ball that appears round is actually a square, and that if the (invisible) corner of this square touches the wall, you are still officially colliding with the wall, even if it looks like the rounded edge of the image of the ball appears clear.

It seems that actual sprites are restricted to only rectangle shape. More complex shapes have to be built up using several small components regrouped into one class.

7

More complex shapes have to be built up using several small components regrouped into one class.

And this is a no-go… for me at least. Using transparency to define the sprite’s perimeter is a must and makes total sense. Otherwise, it appears to me that we can only have square sprites with terrible collision detection. I just started looking at the canvas and I hope I can find an example demonstrating a viable workaround.

K.

8

The problem with a complex geometry is that it massively increases the processing required. If you only deal with rectangle, you only need to check if the X and Y coordinates of an edge fall within the range of the X and Y coordinates of whatever it is you want to see if it collided with.
You could even have a simpler sequential system that first check the distance from the center of the objects and add their characteristic dimension (radius) to see if you are well clear or in need of more accurate ‘close but no cigar’ evaluation process – that is the approach I used 35 years ago when I was designing the algorithm for stores clearance calculation on the F-18 – the difference is that it was in 3D so a tiny bit more complex. But the point is that this was absolutely required to avoid the immense computational cost of having to check the gap between thousand of points (forming the outside contour of a jettisoned fuel tank or ordinance) and a few more thousand points that formed the airframe.
Having a complex geometry means either that you have a very clever “clear” and “not sure, let’s check in more detail” process, or else you are going to take all your performance away checking everything every tenth of a second.