Play game
Syneed's itch.io pageResults
| Criteria | Rank | Score* | Raw Score |
| Fun factor - How much fun was the entry to play. | #2 | 4.000 | 4.000 |
| Originality - How original was the entry. | #4 | 4.462 | 4.462 |
| Audio - Did the entry make good use of audio? | #5 | 4.077 | 4.077 |
| Overall | #5 | 3.705 | 3.705 |
| User experience - How well was the user interaction implemented. | #6 | 3.692 | 3.692 |
| Haptics - Did the entry make good use of haptics? | #9 | 2.615 | 2.615 |
| Theme incorporation - How well did the entry fit the theme. | #16 | 3.385 | 3.385 |
Ranked from 13 ratings. Score is adjusted from raw score by the median number of ratings per game in the jam.
Godot version used
4.3
Leave a comment
Log in with itch.io to leave a comment.
Comments
A lovely exploration into particles and field manipulators!
A very interesting and artistically beautiful game.
Wow, Beautiful game! The puzzles where fun and I love the music grew as you solve parts. Really great work!
Awesome, and looks beautiful!
Could be a full game, and a really challenging one.
Thanks for playing! I'll once again point to the original inspiration if you want more of the same (in 2d) https://en.wikipedia.org/wiki/Auditorium_%28video_game%29 .
Really cool concept, and amazingly visuals and audio. Those particle streams! This is such a zen experience with a fun sandbox to play in. :-) I definitely think this could be built out into a very interesting full game. Great job!
Thanks for playing! If you want more I definitely recommend the game I took heavy inspiration from https://en.wikipedia.org/wiki/Auditorium_%28video_game%29 . the flash game is dead sadly (even if emulated in ruffle, it seems to be broken), but I think the steam version still works.
This is beatifull. envolvent audio, pretty aestetic, great concept and great execution.
Things I didn't like:
- Grab is hard because I needed to poke the ball with only one finger
- Just two levels T_T
- Menu always visible in the back, this could be opened with some button.
- I would swap the instruction of how to grab the world and change the scale in tutorial 2 with tutorial 1, to avoid the need to walk in tutorial 1 and grab the ball. (because this experiencie is a great seated experience)
Thanks for playing! I took, uh, heavy inspiration from the original https://en.wikipedia.org/wiki/Auditorium_%28video_game%29 . I definitely recommend it if you want more of the same (in 2d).
A more "desk size" world scale by default for the puzzles definitely would be better than the scale it is currently; When I was playtesting I'd always scale out until it was that size anyway; plus it'd avoid needing artificial movement entirely to those with enough room.
Took me very long time to figure out how to play, but it is a good concept
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!
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.
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.
I don't think this was the intended solution because the particles pass through the pipe, but I tried very hard.
This is the same idea -- but far prettier -- to my first godot xr game jam entry: Smoke on the Wirral by goatchurch for Godot XR Game Jam - itch.io
How did you detect the particles had hit their targets? I had to do it by placing low-resolution cameras on them and reading the pixels.
Thanks for playing! Hmm, maybe I should've increased the resolution on the GPUParticlesCollisionSDF3D. The scenes in the project have the manipulators in the final positions for my intended solution, but also I didn't have time to do a lot of searching for alternate solutions.
For detection, I did something similar to the cameras: I used a special shader to draw a copy of the particles in a separate SubViewport, which passed in bounding boxes to my targets as uniforms and just checked the position of every particle against them, outputting a pixel to the buffer if they collide. You can see the shader in the source for details. I also asked about it on https://forum.godotengine.org/t/more-efficient-gpuparticles3d-collision-detectio... hoping somebody would get sniped into thinking up a better solution, but didn't get any bites.