That's great! I will be attentive your posts as I'm also interested on how that works hahaha. Good luck!

Thank you!! 🥰

Wow! Congrats!!

ahhh yes, the sweet opportunity to pay a small one-time fee to tell the world I'm 18+! 😀

I had a game like this on my TODO list hahaha. Congrats man! I wish you the best on the release! It looks awesome 🥰

Wow, thank you very much! Super encouraging words! 😁

Sooo, what do you think about the challenges and this approach? Would you do it differently? Why?

Honestly I'm open to more ideas! If there is a better way to do things, why not?

#indieDev #gameDev #devlog #gamedevlog #brickotori #log

Players can enable/disable this feature individually using a button for convenience. This will effectively "hide" the effect from such player only, so he will not see through the bricks, nor other players will see him.
A bit hard to explain with words lol.

This was a nice experiment! And even tho I am not a big fan of see-through effects, I do see the benefits. There are multiple ways of making it, but this is the way I found that "solves" all those questions. Specially the multiplayer related ones.

And that's basically it! But no! Wait! It doesn't end here!

Since my bricks are already using a shader, I needed to combine all of this with that shader. And because it was not a shaderGraph, everything needed to be done using shader code, particularly hlsl.
Which I didn't know before lol.

Both areas are calculated based on the size of the shape in screen space, not world space! And in relation to the camera's view angle.

All pixels within the minimum and maximum area gets their alpha blended between 1 and 0. Leaving 1 for those outside the max area, and 0 for those below the min.

Lastly, (or well, in-between), we need to consider the maximum area we will have for our see-through effect, which means at which distance we will start to hide bricks.

As well we need to have a minimum area, which means at which distance the pixels will have 0 alpha.

Then those translated coordinates are used together with the pixel's position being rendered and its distance from the player to determine how much should we "hide" its color (in other words, change it's alpha value).

And then, I update a bunch of variables on the bricks' shaders. Such as the closest player's position, and its size.

On the shader I did a bit of math magic to translate those world coordinates (position and size) to the screen coordinates (Now that I am thinking about it I might move that to C# 🤔)

So, for handling all this I'm using a combination of shader code and regular C#.

Through C# and a simple collisions I get the bricks between the player and the camera. Group them by closest player, Filter them by height (so, ignoring those below the player)

Alas, Besides all that, we still have another problem.

Problem 8:
- What about performance? Maybe we have a great idea, but if it is too complex or heavy we wouldn't be able to implement it...

And I'm pretty sure I'm forgetting more considerations... but let's go to my experimental approach

Problem 7:
- Multiplayer. Well, having split-screen local-coop brings a whole set of problems.
Should all players see each other with the see-through effect?
If yes, what if the effect on player 1 annoys player 2?
What happen if two players are close to each other? Should they be able to hide?

Problem 6:
- Animations, maybe?. When changing the selected brick, an animation is played on them that affects their scale. This is not really a problem, but a matter of taste?

If we abruptly change the size of the see-through window, then it looks abrupt. Which doesn't feel "right".