Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(4 edits)

Hi there I tried your game during my playtesting stream you can watch the playthrough here https://www.twitch.tv/videos/2384636708?t=00h41m23s

I completely failed to understand you had to grab the balls with just the trigger so I kept grabbing the world and getting utterly confused, until some time during the playthrough when I finally got it.

I was still unsure if I succeeded in solving the puzzles but I think I did. Cool concept, bit “out-there” but in a nice way. First time I interact with a VR game like so. Got a bit motion-sick, I gotta get my body/brain used again to weird ones like that. And very nice visuals and music!

(1 edit)

Oh by the way I’m curious about how you implemented the particle streams specifically the collisions. For my game I first wanted to detect collisions with the flame particles, but it didn’t seem possible to get some sort of collision info from the GPUParticles3D, understandable since this runs as GPU code it can be hard to get this back to the CPU. So I just tweened an Area3D mimicking the visuals.

I glanced over your code under scenes/collisions but it’s a bit late, I’m too tired to properly understand something that complex 😅 You compute some sort of collision area based on the positions of the particles? I’ll take a look at the project tomorrow it’ll probably make more sense with the full picture.

(+1)

https://forum.godotengine.org/t/more-efficient-gpuparticles3d-collision-detectio... has the high level approach (the game code expands on it a bit, but it's essentially the same). I did spend a lot of time thinking of ways to get the data off the GPU efficiently, and even poked through the godot source a bit. I think it'd be ideal if you could read out the internal particle system storage buffer into a compute shader rather than abusing the fixed function pipeline, but I have done very little compute shader programming so I dunno if practically it's any faster than e.g. the alpha blending in fixed pipeline which the game uses. If anyone who knows godot internals and gpu programming better than I do is reading this, I hope my naive approach inspires you to post something better :^)

I like your funny magic words man. No more seriously I think I get the idea thanks for the post and details.

I’m a noob at shaders and GPU programming too. Have you looked at Github issues on the Godot repo? And maybe opening a new one. It would get you ideas and answers from people with the required knowledge I think. We aren’t the only people who want/need this data from GPUParticles. The official Discord server also is active.

Thanks for playing. Sorry you got motion sick. I had hoped the world grab movement was actually better than most forms of artificial movement (it's used in e.g. OpenBrush/TiltBrush for that reason), but I think it might require some more "grounding" in the scene. That and the XR-Tools implementation of world grab is a bit janky; I had to add a low-pass to the scaling part of it or it'd oscillate horribly.