I’m making a 2d top-down game where there are sprites that are in the group “Sided Blocks”, it’s made so when you run the game, the “blocks” check if there are blocks next to them and change their texture accordingly.
When I run my game it gets stuck on the 2nd frame of the 1st animation.
Before:
After:
Scene Events:
External Events:
Can anyone try to help me find out what I did wrong?
There’s a few issues with these events. The main problem is the conditions for the checker.
Conditions act as an object filter. Each event starts with all objects included. Conditions filter out those objects by eliminating the ones that don’t fulfill the condition. So let’s go through your checker conditions:
Checker is in collision with TestBlock
This condition is TRUE for all cases where Checker is colliding with TestBlock. Neither of these objects (or groups) have been subject to filtering, so the condition is looking at ALL Checkers and TestBlocks.
(Inverted) Checker is in collision with TestBlock
This is the “not colliding” condition. But wait… this condition is TRUE for all cases where Checker is not colliding with TestBlock. Again, there are no conditions before this that would filter these objects, so we’re checking ALL checkers against ALL TestBlocks.
Can you see the issue here? This condition will almost always be true! The only way for it to be false is if the Checker is colliding with every TestBlock in the scene!
Instead, you would either need to use the NOT condition, or just use a local variable like this:
(empty condition) | set FoundBlock = 0
--------------------------------------------------------------
Checker is in collision with TestBlock | set FoundBlock = 1
| change Side.whatever to true
--------------------------------------------------------------
variable FoundBlock = 0 | change Side.whatever to false
Now on to the rest of it… while not necessarily “wrong” there are a number of ways that the events could be structured better.
You should only have ONE “repeat for each” for the entire auto-join process. Within each iteration you can check all 4 directions and change the animation before moving on to the next tile.
There should be ONE Checker object that already exists on the scene. Instead of creating and destroying them, just change its position for each check.
Deciding the animation to use could be done using bitflags, eliminating the need for this long set of repetitive events. Unfortunately GD doesn’t support bitwise operators but for this you don’t really need it as it can be done with simple addition.
Basically, you would just assign to each direction the numbers 1, 2, 4, and 8. Instead of setting an array of variables, you’ll only have a single number variable which starts at 0. When a neighboring tile is detected, add the number of that direction. So if you decided that left = 1, when a tile is found on the left then you add 1 to the variable.
The result is a unique number for every combination of neighbors. You can name the animations the appropriate number, or use an array or structure to associate the numbers with animation names.
Let’s say 1 = Left, 2 = Up, 4 = Right, and 8 = Down
3 = neighbors to the left and up
6 = neighbors to the right and up
7 = left, up, and right
15 = all sides have neighbors
Thank you so much! I couldn’t understand why other people were using numbers like 1, 2, 4 and 8 when doing this, so now I understand how it works.
Yeah, theoretically you can use any values that would produce unique combinations, but these are the smallest ones that do so. If you look at it in binary it becomes more apparent:
0001 (= 1)
0010 (= 2)
0100 (= 4)
1000 (= 8)
1 + 4:
0001 (1)
0100 (4)
…
0101 (= 5)
If you consider 0 to be FALSE and 1 to be TRUE, then basically what you have here is your list of true and false values (Side.Up etc) condensed into singular binary bits.
The advantage of bitwise operators is that you can then do things like read or change a specific bit. So for example if I needed to go back and ask “does this tile have an UP neighbor”, I could just check the UP bit directly. Getting that information using the total value and arithmetic is a bit tricky… but unless you need to do that like thousands of times per frame, you can probably get by with just using the checker object again 
I tried, but I couldn’t figure out what you meant by checking all directions in one “repeat for each”, like do I have to use sub events or is there some other way?
Yes, it would be structured like this:
repeat for each tile
check UP
check DOWN
check LEFT
check RIGHT
change texture
This way, you are only doing one loop over the tiles, which will be better for performance as well as event organization.
