So this can be seen as an Interactive voice and sound controlled game. Initially this was mostly intended as a “toy” game for very small kids, where you simply sing something, play an instrument or make noise to make things happen on the screen. Now, perhaps it could also be suitable for people with motor and cognitive disabilities. Most people can control their voice and create different types of vocalizations.
(If someone here has a person in its proximity with special needs that would like to try it, you can P.M me.)
The game is intentionally for those reasons really simplistic. You can sing or make sound with your voice, hit a drum, play something on an instrument. (You don’t need to be able to play well.) All you need is a microphone to the pc.
The game is developed in HDRP and the VFX graph is explored pretty much. There were a lot of new methods to learn for the HDRP pipeline but I think it’s worth it. HDRP is heavy yes, but trying to keep it down and make it playable on low end machines as well.
More info at Mixxus Studio - Play Us Interactive Game
New Video
Edit:
Old video below, keeping this for comparison related to comment on Rigidbody fix in post below.
Closing in now and have been doing some optimizations for the low quality option so at least the game doesn’t need to crash if you like to try it on a low end machine. (Which it sometimes did before the oversight.)
In one outdoor scene (Car race), physically based sky is used and apparently this is heavy on the initial phase in loading a scene. Since it is a car race scene there were many objects to load, the track itself, waypoints etc. Found out that instead of loading all at once, using a coroutine that initialized objects step by step with some pause between and using the simple version of physically based sky solved the problem with loading crash on the low end PC (with only intel integrated graphics). After the scene is loaded the car now drives fast and smooth even with cinamachine cameras on.
I’m also using a separate volume and camera when low quality HDRP asset is used, with less heavy settings, camera have custom frame settings and also ticked of post process completely. Could do a post with this in more detail later.
Its nice to see an orig idea like this, best of luck with it 
Finally made a working UWP build so the game should now move on to Microsoft Store. Going to try to make a post or tutorial on some of the experience with VFX and HDRP. Also more on controlling Rigidbody with both Addforce and moving the transform (you know, the thing you never should do, but I seem to always need to do just that). Anyway the Rigidbody jitter of the car in the preview video has been taking care of.
Worth mentioning here is that when running the uwp version in Visual Studio an error occured when loading a new scene (only from a specific scene). This was not noticeable in Unity editor version or stand alone. Found the error was in either lacking some Lighting asset in Lighting Settings or a lightmap. Removed a lightmap and made new correct references in Lighting window (availble under Window - Rendering). The conclusion is that the HDRP pipeline is sensitive and quite difficult because you really need to pay attention to where all references the Volumes, HDRP and Lighting assets are pointing to. A debugging tip; since this was a heavy scene with lot of objects there were a million things you could suspect to be problematic, so I made a copy of the scene, removed everything and had just some dummy objects and the problem remained which then pointed to some problem with the scene settings itself.
